On Wed, 16 Jan 2013 22:52:52 +0100 Luca Barbato <lu_z...@gentoo.org> wrote:
> 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. Hard to blame anyone without more info nor a description of the problem, it can even be a too quick analysis before dismissing it. > >> 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. meaning bug #447838 ??? are you kidding ? > > 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. Fortunately we're not debian and do not like when people impose their choice on us. > > 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. mplayer2 is a good player but unfortunately for me it doesn't come with a mencoder2. Being the one that did most of the porting to the recent APIs of libav* for xbmc, I can assure you that any help is very welcome to have a sane support for libav. > > 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. It's probably the fault of the current trend of tagging most of the crashes as sec. issues. The problem here is that a crash fix is almost invisible, while a CVE gets very high visibility, and leaving time to malicious people for reinventing an attack is bad. > The problem with the "published vulnerabilities" had been usually us > being prevented from accessing the example vectors, now the situation > is way better. This is news to me, but good it improved. [...] A.
