[issue1898] Doesn't build on IA64
New submission from Christian Marillat maril...@free.fr: ffmpeg doesn't build on ia64 since at least one month. http://fate.multimedia.cx/ I don't understand what is exactly broken. -- messages: 10231 nosy: marillat priority: normal status: new substatus: new title: Doesn't build on IA64 type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1898
[issue1899] rtsp mov could not find codec parameters
compn te...@twmi.rr.com added the comment: more rtsp mov samples : http://wiki.multimedia.cx/index.php?title=RTSP some work, some dont. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1899
[issue1816] FFmpeg does not use lib4vl
Mans Rullgard m...@mansr.com added the comment: Kevin Kofler iss...@roundup.ffmpeg.org writes: lucabe72 wrote: So, I believe this is not a bug but a feature request. It's a bug. libv4l is REQUIRED for ALL v4l-using apps in current GNU/Linux. Bullshit. The kernel interface is well-documented, and libv4l is open source. How can you claim using this specific library is a requirement? There are no secrets in there. If a webcam uses an unsupported colorspace, I believe the best option is to add support for such a colorspace in libswscale. It's not just the colorspace, it's the precise encoding (e.g. there are 18 different ways to encode YUV used in video capture devices!) and the compression for those devices which use one. Good luck implementing all the possible device-specific compression algorithms within FFmpeg. You'll just be reinventing the wheel. libv4l does it all for you. It's there for a reason. FFmpeg already supports 68 different pixel formats. Adding a few more is no big deal. Besides, the libv4l code is pretty poor performance-wise. We'd do it better. FFmpeg always does it better. Older drivers did decompression in the kernel, but the kernel developers decided that it has no business being in the kernel and must be done in userspace. Thus all userspace apps need to handle all the compressed formats they can get, and libv4l was written to allow that to happen. FFmpeg is in userspace. FFmpeg is designed to handle a plethora of compressed formats. What do we need libv4l for? Alternatively, one can think about a libv4l-based input device (which does not break the video4linux 2 input device). Accessing v4l2 directly just does not make sense as per the v4l2 spec, the driver can send you any format it wants. Only libv4l knows how to decode the formats you get, I just read the source code of libv4l. Now I know it too. and it's regularly updated as new kernel drivers using new formats get added. The days where you were able to request RGB (or YUV or whatever) format directly from any kernel webcam driver are gone! Most drivers will NOT be able to fulfill such requests. You need libv4l to handle the conversion for you. You're still not getting it, are you? _We_ can do the conversion ourselves. It's what we do. Now please stop changing the priority of this. If you want support for a specific device, send patches for that, or send someone such a camera so they can do it. -- priority: normal - wish type: bug - feature_request FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1816
[issue1816] FFmpeg does not use lib4vl
Kevin Kofler kevin.kof...@chello.at added the comment: But implementing support for bayer (or whatever is the pixel format used by modern webcam drivers) is a better solution. It's not just that one format. (But hey, you can start with that one (V4L2_PIX_FMT_SGRBG8). And then all the other formats you'll get bug reports for...) I really don't see the point of reinventing the wheel here. Why does FFmpeg insist on reinventing the wheel all the time? I can understand it if the code has licensing issues (and in fact I think it's a very good idea to have a Free reimplementation in those cases), but here the library is LGPLv2+. You'll also need to be prepared for many additional bug reports such as this one, a new one each time a new webcam with yet another format pops up, each time asking you why you don't just use libv4l. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1816
[issue1899] rtp doesn't demux audio/X-QDM and video/X-SV3V-ES
Luca Barbato lu_z...@gentoo.org added the comment: Worth mentioning that an rtsp url gives you as container either -standard rtsp/rtp -real rtsp dialect -other and points an abstract resource, the name can be as misleading as possible. -- title: rtsp mov could not find codec parameters - rtp doesn't demux audio/X-QDM and video/X-SV3V-ES topic: +avformat, rtsp FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1899
[issue1816] FFmpeg does not use lib4vl
Reimar Döffinger b...@reimardoeffinger.de added the comment: On Tue, Apr 27, 2010 at 01:32:47PM +, Kevin Kofler wrote: I really don't see the point of reinventing the wheel here. Why does FFmpeg insist on reinventing the wheel all the time? In addition to what Måns said: libv4l and v4l2 (as in the kernel API) are two different things. That you want the former does not make it a bug that we have the latter. If someone had written a patch for libv4l support and it was rejected then you might have a point. And I wouldn't mind having a libv4l input available in addition, though it seems to me not any more likely someone will care to implement it than it is likely that someone will implement more format support. Of course alternatively why don't you ask the libv4l developers why _they_ reinvented the wheel? libswscale has existed long before them and for the formats it supports probably has vastly better performance. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1816
[issue1899] rtp doesn't demux audio/X-QDM and video/X-SV3V-ES
Ronald S. Bultje rsbul...@gmail.com added the comment: Josh will hopefully implement these two as part of GSoC. Antique patches (by me) available at: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073511.html http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073826.html FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1899
[issue1894] Error number -2 occured
Víctor Paesa wzr...@arsystel.com added the comment: It works fine for me on Cygwin 1.7. Was it built on Cygwin for Cygwin, or built on Cygwin for MinGW? Please provide full uncut output of uname -smorv and ffmpeg -i nofile Like this: $ uname -smorv CYGWIN_NT-6.0 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin $ ./ffmpeg -i nofile FFmpeg version SVN-r22960, Copyright (c) 2000-2010 the FFmpeg developers built on Apr 27 2010 23:53:09 with gcc 4.4.3 configuration: --disable-shared --enable-static --enable-gpl --enable-avfilter --enable-avfilter-lavf --enable-pthreads --enable-avisynth --enable-bzlib --enable-libmp3lame --enable-libx264 --enable-zlib --cc=gcc443 --cpu=core2 --extra-cflags=-DX_DISPLAY_MISSING libavutil 50.14. 0 / 50.14. 0 libavcodec52.66. 0 / 52.66. 0 libavformat 52.61. 0 / 52.61. 0 libavdevice 52. 2. 0 / 52. 2. 0 libavfilter1.19. 0 / 1.19. 0 libswscale 0.10. 0 / 0.10. 0 nofile: No such file or directory -- nosy: +wzrlpy status: new - open substatus: new - needs_more_info FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1894
[issue1894] Error number -2 occured
ami_stuff ami_st...@o2.pl added the comment: Argh sorry my bad. It happens with mingw32 build, not cygwin (the same problem happens also under amigaos). http://ffmpeg.arrozcru.org/autobuilds/ C:\ffmpeg.exe -i nofile FFmpeg version SVN-r22976, Copyright (c) 2000-2010 the FFmpeg developers built on Apr 27 2010 06:09:22 with gcc 4.4.2 configuration: --enable-memalign-hack --cross-prefix=i686-mingw32- --cc=ccache -i686-mingw32-gcc --arch=i686 --target-os=mingw32 --enable-runtime-cpudetect --e nable-avisynth --enable-gpl --enable-version3 --enable-bzlib --enable-libgsm --e nable-libfaad --enable-pthreads --enable-libvorbis --enable-libtheora --enable-l ibspeex --enable-libmp3lame --enable-libopenjpeg --enable-libxvid --enable-libsc hroedinger --enable-libx264 --enable-libopencore_amrwb --enable-libopencore_amrn b libavutil 50.14. 0 / 50.14. 0 libavcodec52.66. 0 / 52.66. 0 libavformat 52.61. 0 / 52.61. 0 libavdevice 52. 2. 0 / 52. 2. 0 libswscale 0.10. 0 / 0.10. 0 nofile: Error number -2 occurred FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1894
