From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A20C11384F0 for ; Wed, 16 Jan 2013 21:31:25 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BA83B21C132; Wed, 16 Jan 2013 21:31:21 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9E3B621C12C for ; Wed, 16 Jan 2013 21:31:20 +0000 (UTC) Received: from localhost (unknown [200.89.69.133]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 1F12233D806 for ; Wed, 16 Jan 2013 21:31:18 +0000 (UTC) Date: Wed, 16 Jan 2013 18:31:10 -0300 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild Message-ID: <20130116183110.403ea209@gentoo.org> In-Reply-To: <50F70FE8.6000507@gentoo.org> References: <20130116124002.B9FA22171D@flycatcher.gentoo.org> <20130116170907.6ee31e7d@gentoo.org> <50F70FE8.6000507@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.14; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: f3973ddb-f92b-4acc-b0b0-7a219dcd08da X-Archives-Hash: 69a273b95cd3e73fa180293f55fac4f2 On Wed, 16 Jan 2013 21:39:04 +0100 Luca Barbato wrote: > On 16/01/13 21:09, Alexis Ballier wrote: > > More seriously: Why ? Who decided this ? > > I never pushed my weight over it before since as you are involved in > FFmpeg directly, I am involved in Libav directly. I don't know what you mean by involved directly, but ffmpeg happens to be what I use and care about, hence I have a couple of commits there but their number is quite ridiculous in comparison. [Actually, I should be honored that you compare my involvement with yours :)] > Thus anything I say on this topic has a clear bias. Same goes for you. ... but I admit I have some bias, however, I'm rather a consumer than a developer when it comes to ffmpeg and believe we need to think as consumers as a downstream distro. > Tomas is not related to libav beside one of his core project using it > by transition, so I would expect him to be less biased than us. > > > Let's be realistic, both upstreams claim they're better than the > > other in one way or another, and let's think like serious > > downstreams, not like upstream playground. > > VLC uses it since ffmpeg doesn't work with rtmp properly last time > they checked and other interesting situations. 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. > 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 > ubuntu and debian just use Libav. 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' :) > > As a downstream, I can see plenty of reasons against, but none in > > favor of this change: > > - There are still a couple of non-trivial packages that need to be > > fixed to work with libav while I don't know any that works with > > libav but not ffmpeg. > > See above for the other way round. 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. > > - All (but the one discovered in Nov. 2012) of the security issues > > fixed by libav 0.8.5, released on Jan. 13 2013 were fixed in May > > 2012 (!!) for ffmpeg according to the website... 8 months before... > > The security game is fun. Given the number of "additional features" > the surface impact is bigger in FFmpeg and currently all but one of > the bugs claimed as security issues originate from the same guy he > claim to fix them (sometimes the fix doesn't address the underlying > issue but just _that_ specific sample). 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. > I'd rather avoid having another mud sliding contest. > > I stopped caring about FFmpeg since somebody gave a sample of his > humor wishing my death. This is getting personal :) 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. Alexis.