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 B65B61384DD for ; Wed, 16 Jan 2013 11:54:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 00009E06D9; Wed, 16 Jan 2013 11:54:36 +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 09805E0687 for ; Wed, 16 Jan 2013 11:54:35 +0000 (UTC) Received: from localhost (pc-119-46-101-190.cm.vtr.net [190.101.46.119]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 4793233DA43; Wed, 16 Jan 2013 11:54:34 +0000 (UTC) Date: Wed, 16 Jan 2013 08:54:28 -0300 From: Alexis Ballier To: gentoo-dev@lists.gentoo.org Cc: phajdan.jr@gentoo.org Subject: Re: [gentoo-dev] Chromium system ffmpeg Message-ID: <20130116085428.7103a2a3@gentoo.org> In-Reply-To: <50F63634.50701@gentoo.org> References: <50F4DC62.1010500@gentoo.org> <20130115095506.6e033640@gentoo.org> <50F63634.50701@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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: b48a5309-9eb7-46d7-a9a2-17001cf07714 X-Archives-Hash: ef5a5b522474d35a76b04b257ef58b10 On Tue, 15 Jan 2013 21:10:12 -0800 ""Pawe=C5=82 Hajdan, Jr."" wrote: > On 1/15/13 4:55 AM, Alexis Ballier wrote: > > On Mon, 14 Jan 2013 20:34:42 -0800 > > ""Pawe=C5=82 Hajdan, Jr."" wrote: > >> I'm trying to make Chromium be more compatible with more versions > >> of ffmpeg: > >> > >> (although not stated there, that includes libav). > >=20 > > I've done quite a lot of work for various packages among the past > > years on that side, so if you have specific questions, feel free to > > ask. >=20 > Alright: >=20 > 1. What's the difference between libav and ffmpeg? Do the projects > merge each other's changes? If not, in what direction do patches flow? ffmpeg merges daily from libav; for libav, better ask Luca or Diego I think, but I've seen they manually port some patches from ffmpeg from time to time. > 2. What are API compatibility policies for ffmpeg and libav? There's no policy AFAIK. For what I understood, libav doesn't care; ffmpeg tries to be API and ABI compatible with libav (ie: provide the same API and ABI + their additions) > 3. Same as above for making releases (i.e. how frequent they are, how > much they change, and how much released libav and ffmpeg are in sync > with each other in practice). libav release schedule is independent; in the last years, ffmpeg releases have been more frequent and there's always been a ffmpeg release on par with a libav release (now we have libav-9 and ffmpeg-1.1 that should be on par) > 4. What are typical incompatibilities (if possible), and usual ways to > deal with them? For most of the API, there's none, but because of the above, during the years, small incompatibilities have accumulated and you can see them between the supposed to be on par releases. For example, libavfilter differs a lot between the two; the major/minor/micro versions are completely different between the two (usually you do #if version < foo conditions which become messy if you want to support both). > 5. Do you think it's possible / worth trying to convince upstream > ffmpeg / libav to have a more stable API over time? Which one could > be possibly more willing to listen and why? It is already the case for both: once a symbol / API is deprecated at major release N, it's still there at major N+1 and removed at major N+2. That's why I told you if you build without any deprecation warning, you should be safe for some time :) [...] > > What is the min. version it works with? >=20 > Currently, for masked system-ffmpeg USE flag for chromium, it's > ffmpeg-1.0. And what is the problem with, say, 0.10.6 ? > > As a distro we have two options: > > 1) patch chromium to add #if's for older ffmpeg versions and be > > compatible: this may or may not be accepted by upstream, supporting > > older versions is just garbage code for them. >=20 > I'm pretty sure upstream won't accept "trench warfare" #ifdefs (I'm > also an upstream dev). I'm also not enthusiastic about having an > out-of-tree Gentoo-side patch for a fast-moving project like that. > The additional cost on each version bump is also something to take > into account (fixing incompatibilities is one thing, but I'm also > thinking about like merge conflicts on the patches). >=20 > > 2) (preferred) coordinate the other packages to be compatible with > > newer versions and unmask latest (we should be very close to be > > able to unmask ffmpeg-1) and make chromium require this version > > (this require chromium upstream to figure out what is the min. req. > > version) >=20 > What when chromium upstream uses code more recent than latest ffmpeg > release and it doesn't compile against latest release? Blame them, it's stupid to break support for the latest release. Usually, it's quite trivial to maintain compatibility and you should probably lobby upstream to get this as a rule, it'd make life simpler for everyone. Or just patch releases not to use too bleeding-edge code (see mplayer for example). > Now what about libav? At one time I could compile against latest > masked ffmpeg in tree but couldn't compile against latest masked > libav (or any other version of it I think). Ideally I would like to > make it compilable against both. Does that sound like much more > difficult? It depends what the problem is: it may be just some missing #includes, some CODEC_ID present in ffmpeg but not in libav in which case you'd have to #ifdef its usage out, or more complicated if you use an API from ffmpeg not in libav like some libavfilter stuff. =20 > > we should probably do something in-between 1 and 2 in order not to > > hold off sec. stabilizations of chromium because dozens of stable > > packages do not build with latest ffmpeg. >=20 > Yup. Just note there is just ~6 weeks before each stable release. > That's not a very long time for most projects, and I think we won't > get other packages into shape that quickly. Probably, unfortunately. We could do like for mplayer then, patch it so that it builds with current releases. [...] > > Usually, if you build with the latest ffmpeg release and don't see > > any deprecation warning, you are safe for ~1 year or more. >=20 > Somehow I don't think that'll work. Chromium pulls from ffmpeg trunk > frequently, so it's also a moving target. It doesn't imply chromium uses bleeding edge API not present in older releases: you told me that ffmpeg-1.0 is fine while we have ffmpeg-1.1 now :) > > IMHO a compatibility layer like you suggest on your link will be a > > pain, #if's are easier to handle. >=20 > I could make a leightweight compatibility layer, don't underestimate > how nicely invented it can be. :) What if I say #define > ffmpeg_function wrapper_ffmpeg_function for chromium code, and then > have wrapper_ffmpeg_function do something smart depending on actual > ffmpeg version? It really depends on the problem; most of the time, the API breaks are not just simple function renaming :) See eg: http://git.videolan.org/?p=3Dvlc.git;a=3Dblob;f=3Dmodules/codec/avcodec/avc= odec.h;h=3D8c8dd20ed3400527cab84265f4442bf06eb06f8d;hb=3DHEAD that tries to provide such a compatibility layer when possible, but there are #if in other parts of the code when not possible. It could be even worse if you want to go backward: usually deprecated functions are replaced by new more powerful ones. It's easy to map the old one to the new one (just set some arguments to 0) but the other way may be more tricky. Alexis.