I just noticed that the gst-plugins-ffmpeg-0.10.4-r1 uses the system ffmpeg. Please revert that. Its broken in debian and ubuntu, and will break in Gentoo. First problem I found after just a few minutes is that system ffmpeg can contain theora support based on libtheora. So it creates a ffenc_libtheora element that competes with theoraenc in autoplugger (like farsight2) and crashes when you try to use it. This bug also appears in Debian and Ubuntu... As the upstream developer of Farsight2 (and a co-worker of the debian maintainer of gst-ffmpeg), I'm in the process of getting that fixed in debian too..
Taking this bug, since I've been bumping the last two times.
Using system ffmpeg is really not a sane option; better try to fix the real bug instead. Any clue why ffenc_libtheora crashes ? got a backtrace ?
ffenc_theora shouldn't exist and isnt supported by upstream gst-ffmpeg. For GStreamer, one should use theoraenc/dec. If you insist on using system ffmpeg, then we need to modify gst-ffmpeg to whitelist codecs to only the ones supported by upstream. And also, we should probably make sure that we run a full "make check" against EVERY version of ffmpeg that a release of gst-ffmpeg could be used against. But it sounds like a recipe for small, hard to detect brokenness...
(In reply to comment #3) > ffenc_theora shouldn't exist and isnt supported by upstream gst-ffmpeg. For > GStreamer, one should use theoraenc/dec. If you insist on using system ffmpeg, > then we need to modify gst-ffmpeg to whitelist codecs to only the ones > supported by upstream. Why shouldn't it exist ? Whitelisting things in gst-ffmpeg would fix this but will make you lose the new ffmpeg codecs as long as gst-ffmpeg won't have added them to that whitelist I think. This doesn't sound a good long term usage of the ffmpeg api. Blacklisting could also be an option, but I'd really prefer to fix the real bug, ie what causes the crash, than going that route. I don't know how gst works internally, but isn't there any kind of priority thing such that gst-ffmpeg could be put low priority and gst would take the native gst libtheora wrapper instead of the gst-ffmpeg wrapper to the ffmpeg libtheora wrapper ? Please explain me a way to make it crash with ffenc_libtheora. > And also, we should probably make sure that we run a full "make check" against > EVERY version of ffmpeg that a release of gst-ffmpeg could be used against. But > it sounds like a recipe for small, hard to detect brokenness... I do run tests and use ffmpeg trunk as system lib... though I don't rebuild gst-ffmpeg often.
The gst-ffmpeg already has a rank of 0 (ie the lowest rank), but thats only for decoding. For encoding autopluggers (like farsight2), even if we had ranks, it wouldn't help, because gst-ffmpeg encoders often accepts wider input caps then the good quality native plugin (which would be preceded by the proper conversion element). The real solution is to disable plugins that shouldn't exist. In Farsight2 (one of the only encoding-side autopluggers), we already have to add to the FAQ to remove debian's gst-ffmpeg package because it uses system ffmpeg and fails. Also, picking up new plugins that don't exist in the upstream gst-ffmpeg is just asking for problems. Let the upstream developers first test it and make sure it works (they have an extensive test suite), before we unleash it onto our poor users. Trying to be smarter than upstream will just give us a bunch of subtle and nasty bugs.
Also, please read this carefully: media-plugins/gst-plugins-ffmpeg/files/0.10.5/system-ffmpeg-warning.patch I'm not sure what more I can say. The only other solution I can think of is to use the version of ffmpeg inside gst-ffmpeg as the system ffmpeg (but that will annoy every other ffmpeg user). Well, or the right solution, accept that ffmpeg is not security critical software, that if you have anything security related that uses ffmpeg, you're doing something extremely wrong, and let each ffmpeg user have its own copy.
(In reply to comment #6) > Also, please read this carefully: > media-plugins/gst-plugins-ffmpeg/files/0.10.5/system-ffmpeg-warning.patch > > I'm not sure what more I can say. The only other solution I can think of is to > use the version of ffmpeg inside gst-ffmpeg as the system ffmpeg (but that will > annoy every other ffmpeg user). I'm more concerned about things like bug #241136 or bug #231834 Using a bundled fixed and statically linked version of ffmpeg is just hiding bugs under the carpet. (In reply to comment #6) > Well, or the right solution, accept that ffmpeg is not security critical > software, that if you have anything security related that uses ffmpeg, you're > doing something extremely wrong, and let each ffmpeg user have its own copy. This will never happen: lots of media players use ffmpeg, lots of them even accept reading stuff from the web. Think about what will happen if someone sends you a link saying "hey watch this video, its damn cool". Anything that reads files is security critical. (In reply to comment #5) > In Farsight2 (one of the only encoding-side autopluggers), we already have to > add to the FAQ to remove debian's gst-ffmpeg package because it uses system > ffmpeg and fails. I suppose I should give it a try then... > Also, picking up new plugins that don't exist in the upstream gst-ffmpeg is > just asking for problems. Let the upstream developers first test it and make > sure it works (they have an extensive test suite), before we unleash it onto > our poor users. If the wrapper is correct it should just work fine with ffmpeg default options. Adding special cases in gst-ffmpeg for it will just allow better options from gst I think. > Trying to be smarter than upstream will just give us a bunch of subtle and > nasty bugs. Yes... and what about ffmpeg upstream supporting only trunk ? The bundled version in a gst-ffmpeg release could very well have a bug in the foo decoder that has been fixed in our ffmpeg package. I agree this could and will probably lead to subtle and nasty bugs but then that means something has to be fixed (and for now, apart ffenc_libtheora these are only possible future bugs); ffmpeg by itself is heavy maintainance, doubling it isn't a viable option imho, better coordinate with the ffmpeg maintainers to have everything working nicely.
Now, how to make it fail: gst-launch-0.10 videotestsrc ! ffenc_libtheora ! fakesink Clearly, you haven't tested. Anyways, I'll be spending the weekend with the gst-ffmpeg maintainer and I'll see if we can come up with a solution.
(In reply to comment #8) > Now, how to make it fail: > > gst-launch-0.10 videotestsrc ! ffenc_libtheora ! fakesink > > Clearly, you haven't tested. I never said I did, heck I asked for a way to reproduce the error... According to my debugging, it feeds the libtheora encoder with a wrong pixel format, PIX_FMT_YUYV422, while the encoder expects only PIX_FMT_YUV420P, hence the failure. This sounds like a bug in gst-ffmpeg that could very well happen with other encoders enabled by default and will crash in the same way, using the bundled version or not.
Created attachment 169468 [details, diff] try to use only valid pixel formats And this patch fixes the segfault here. It was trying to use any available pixel format for building the caps and none of the tests were checking if they were valid for the selected encoder... This patch makes it try to use only the pixel formats supported by the encoder, and in libtheora's case this is YUV420P and that's all.
Please make sure this gets upstream, so it'd actually get fixed..
Bug Filed upstream : http://bugzilla.gnome.org/show_bug.cgi?id=564105
Hi. I just saw this bug and for my information want to know best to handle it. I have (foolishly?) reported a bug upsteam with gst-ffmpeg but they will not support system ffmpeg. There is no option/flag to use the supplied ffmpeg. So should I re-create the bug report in Gentoo's bugzilla or am I SOL with this issue?
Albert, if you pay attention to when you emerge gst-ffmpeg using the system-wide ffmpeg you will notice that a big fat warning is displayed for 15s telling you WHY we do not support gst-ffmpeg using a different version [1] than the one we ship with gst-ffmpeg. If you want support from upstream you will have to emerge gst-ffmpeg without that use flag. [1]: well they don't make releases, but you get the point P.S. I was the one who closed the bug upstream, did you try emerging without the system-wide ffmpeg ? Did it solve your issues ? You should open a different bug if you still have issues.
Alexis, your proposed fix was implemented (in a slightly different way) 2 months ago and should be available in 0.10.6. Can you check that version and confirm it solves your problem ?
(In reply to comment #14) > Albert, if you pay attention to when you emerge gst-ffmpeg using the > system-wide ffmpeg you will notice that a big fat warning is displayed for 15s The gentoo ebuild patches out that warning....
(In reply to comment #16) > (In reply to comment #14) > > Albert, if you pay attention to when you emerge gst-ffmpeg using the > > system-wide ffmpeg you will notice that a big fat warning is displayed for 15s > > The gentoo ebuild patches out that warning.... > <insert 15mins of french bloke swearing loudly at whomever removed that warning>
(In reply to comment #17) > <insert 15mins of french bloke swearing loudly at whomever removed that > warning> At your service.
It seems that hell has frozen over and the ffmpeg tree too and they're gonna make a release, and gst-ffmpeg will use that and it will be just like any other regular package and we will all live happily in harmony!
any updates on this one? seems to me as if the gst-plugins-ffmpeg ebuild is still using it's own ffmpeg. and what about libav support?
Recent versions of gst-ffmpeg actually use their own copy of libav, not of ffmpeg
