On 16/01/13 22:31, Alexis Ballier wrote: > interesting, did they report it? OTOH, they switched _after_ the 2.0.5 > release which happens to be the latest one. Since vlc is probably the > ffmpeg/libav interface the most popular in the world (due to their > windows and mac builds), I'd like to see an actual release with it and > see if there is any regression before claiming they use libav.
Reported, dismissed as bug on their side IIRC. >> gst-ffmpeg/gst-libav works only with libav as per upstream desire >> (thus the rename) > > you mean use libav internally? because 'per upstream desire' > gst-ffmpeg or gst-libav always only worked with the internal libs :) > it also appears to build and work fine with ffmpeg-0.10 To be more clear, latest gst-libav release does not build with latest ffmpeg release, same said for the gst-libav backport. > Speaking about bias, the maintainer happens to be part of libav core > developers and was even part of what is known as the 'ffmpeg coup' :) Meanwhile I preferred let people pick their poison since it is easy to switch from one to another, in retrospect would had been better if I just removed ffmpeg from the tree from day 0. > None of what you cited is a problem for a downstream distribution, > except maybe vlc+rtmp which should be fixed regardless. > xbmc and mplayer did not build last time I tried. xbmc will be a pain > because it uses some libavfilter features not in libav. mplayer2 works decently here. I didn't try to look at xbmc yet. > I don't want to verify this and will trust you there, but I still > don't consider 8 months to be a correct delay for handling a published > vulnerability, whatever its origin may be. Crashes are always bad, we fix a lot of them every day, we obviously introduce few new since we aren't perfect, calling all of them security problems is a tad extreme in my opinion. The problem with the "published vulnerabilities" had been usually us being prevented from accessing the example vectors, now the situation is way better. > I'm sure the fork didn't happen because > some day some devs woke up angry because they didn't have had their > coffee. However, I'm also sure the fork is a pain for downstream > distros and a lot of upstreams. The rationale is on libav.org/about.html, I spent about 3 months trying to prevent it. I failed. lu
