Re: [gentoo-dev] Chromium system ffmpeg

[Alexis Ballier <aballier@gentoo.org>]

On Tue, 15 Jan 2013 21:10:12 -0800
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> On 1/15/13 4:55 AM, Alexis Ballier wrote:
> > On Mon, 14 Jan 2013 20:34:42 -0800
> > ""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:
> >> I'm trying to make Chromium be more compatible with more versions
> >> of ffmpeg:
> >> <https://groups.google.com/a/chromium.org/d/topic/chromium-dev/fm5Oe_AC3Sc/discussion>
> >> (although not stated there, that includes libav).
> > 
> > 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.
> 
> Alright:
> 
> 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?
> 
> 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.
> 
> 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).
> 
> > 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)
> 
> 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.
 
> > 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.
> 
> 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.
> 
> 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.
> 
> 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=vlc.git;a=blob;f=modules/codec/avcodec/avcodec.h;h=8c8dd20ed3400527cab84265f4442bf06eb06f8d;hb=HEAD
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.