[gentoo-dev] Chromium system ffmpeg

[gentoo-dev] Chromium system ffmpeg

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

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).

Now the initial response there is not enthusiastic (which doesn't
surprise me), but do you think there are some points useful for the
discussion I'm not aware of?

What are the main challenges of keeping up-to-date with latest ffmpeg
API changes? How do other projects deal with that?

If there is anything else you want to share/say about this, please do.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Chromium system ffmpeg

[Alexis Ballier]

Hi,

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.

> Now the initial response there is not enthusiastic (which doesn't
> surprise me), but do you think there are some points useful for the
> discussion I'm not aware of?

I don't get what is the problem: chromium uses an internal version
corresponding to ffmpeg git master and doesn't build with older ones?
What is the min. version it works with?
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.
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)

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.


> What are the main challenges of keeping up-to-date with latest ffmpeg
> API changes? How do other projects deal with that?

Specify a min. supported version, use #if for what remains.
It may be easy or quite a lot of work, depending on what part of the
API is used. ATM, being compatible with ffmpeg 0.10 up to git master
isn't _that_ heavy on #if's (see eg:
http://dev.gentoo.org/~aballier/distfiles/xbmc-11.0-ffmpeg-1.0-compat-1.tar.bz2
) but may require a lot of changes.
Usually, if you build with the latest ffmpeg release and don't see any
deprecation warning, you are safe for ~1 year or more.

IMHO a compatibility layer like you suggest on your link will be a
pain, #if's are easier to handle.

Alexis.

Re: [gentoo-dev] Chromium system ffmpeg

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 4697 bytes --]

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?

2. What are API compatibility policies for ffmpeg and libav?

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).

4. What are typical incompatibilities (if possible), and usual ways to
deal with them?

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?

>> Now the initial response there is not enthusiastic (which doesn't
>> surprise me), but do you think there are some points useful for the
>> discussion I'm not aware of?
> 
> I don't get what is the problem: chromium uses an internal version
> corresponding to ffmpeg git master and doesn't build with older ones?

Generally yes. It periodically pulls directly from git master (often
ahead of any release) and that usually breaks build with older ffmpegs.

> What is the min. version it works with?

Currently, for masked system-ffmpeg USE flag for chromium, it's ffmpeg-1.0.

> 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?

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?

> 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.

>> What are the main challenges of keeping up-to-date with latest ffmpeg
>> API changes? How do other projects deal with that?
> 
> Specify a min. supported version, use #if for what remains.
> It may be easy or quite a lot of work, depending on what part of the
> API is used. ATM, being compatible with ffmpeg 0.10 up to git master
> isn't _that_ heavy on #if's (see eg:
> http://dev.gentoo.org/~aballier/distfiles/xbmc-11.0-ffmpeg-1.0-compat-1.tar.bz2
> ) but may require a lot of changes.

I will take a look at that patch later to see how possible changes look
like.

> 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.

> 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?

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Chromium system ffmpeg

[Alexis Ballier]

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.

Re: [gentoo-dev] Chromium system ffmpeg

[Rich Freeman]

On Wed, Jan 16, 2013 at 6:54 AM, Alexis Ballier <aballier@gentoo.org> wrote:
> On Tue, 15 Jan 2013 21:10:12 -0800
> ""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:
>>
>> 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).

While I agree in principle, that is much easier said than done.  I
think upstream is more likely to consider the concept of a linux
distro broken than their code.

The unpacked chromium distfile is 1.1G, of which 694M is third party
source-code.  The chromium team has done an excellent job of disabling
much of that, but the upstream attitude clearly is to cherry-pick
their dependencies.  This is pretty typical for Google projects from
what I've seen - ChromeOS basically is a fork of Gentoo with many
packages being fairly dated, and Android does just about everything
its own way, typically releasing third-party code into production
before any upstream packages have access to it.

Of course, we should encourage upstream to improve its practices.  I
just wouldn't count on it, so I think we need to give the chromium
team discretion on just how much patching they think they can handle.
They're obviously pretty good at it already.

Rich

Re: [gentoo-dev] Chromium system ffmpeg

[Luca Barbato]

On 15/01/13 05:34, "Paweł Hajdan, Jr." 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).
> 
> Now the initial response there is not enthusiastic (which doesn't
> surprise me), but do you think there are some points useful for the
> discussion I'm not aware of?
> 
> What are the main challenges of keeping up-to-date with latest ffmpeg
> API changes? How do other projects deal with that?

I guess it had been stated there, but is worth noting again that
chromium has a specific fork of ffmpeg and they merge and adapt/fix as
they need.

As Libav we try to see what they are doing and when possible either
import their fix or redo it in a more general way if it doesn't fit
normal consumption (see our review process policy for more details).

Their API usage is quite normal nowadays (after we convinced them to use
AVIO instead of the deprecate URLProtocol, for our and their respective
pleasure since it resulted in slashing a good chunk of cruft)

Feel free to nag me if something breaks with a system libav.

lu

Re: [gentoo-dev] Chromium system ffmpeg

[Luca Barbato]

On 16/01/13 12:54, Alexis Ballier wrote:
> 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.

Libav has defined review rules so patches get hand picked and discussed
as any other contributions, there isn't any kind of fast track.

If somebody wants something in ffmpeg, ffmpeg-chromium,
${personal_libav_fork} and such, can just pick the patch and send over
the mailing list.

>> 2. What are API compatibility policies for ffmpeg and libav?
> 
> There's no policy AFAIK. For what I understood, libav doesn't care;

As said above our development policy is quite simple. Regarding API
changes they get discussed as for any other patch, new API can land on
the master, old api gets removed after a major release deprecating it.

>> 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).

In general we aim to have a major release per season, depending on how
involving the update is we postpone till downstream catches up.

Point releases happen when enough bugfixes are piled up. Usually we keep
one or two major release in maintainance mode (releases and fixes) while
we develop the next one.

For the release 9 branch I'm trying to keep the fixes in sync so people
doesn't have to backport them in mass.
Release branches 0.8 and 0.7 are synced more seldom.

>> 4. What are typical incompatibilities (if possible), and usual ways to
>> deal with them?

Use only the common subset, e.g. Do not use swresample and use avresample.

>> 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?

Libav API is evolving but you have about 1/2 year or more to update.

>> What when chromium upstream uses code more recent than latest ffmpeg
>> release and it doesn't compile against latest release?

They will gladly tell you that the patches they use are available and
you should nag upstream.

Jokes aside, tell us and in a way or another you'll have something working.

>> 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.

Usually Libav does not expose private API and depending on the release
timing you might find software not updated fully (see about about the
6-8 months of grace time)

>> 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.

If then need arises I think we can snapshot, a monthly point release
might be coordinated if enough people need it.

>> I could make a leightweight compatibility layer, don't underestimate

Better nag me till your problem isn't solved on our side, chromium is
huge and making changes on the media part of it is gorier than you'd expect.

lu

Re: [gentoo-dev] Chromium system ffmpeg

[Alec Warner]

On Wed, Jan 16, 2013 at 4:59 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Jan 16, 2013 at 6:54 AM, Alexis Ballier <aballier@gentoo.org> wrote:
>> On Tue, 15 Jan 2013 21:10:12 -0800
>> ""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:
>>>
>>> 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).
>
> While I agree in principle, that is much easier said than done.  I
> think upstream is more likely to consider the concept of a linux
> distro broken than their code.
>
> The unpacked chromium distfile is 1.1G, of which 694M is third party
> source-code.  The chromium team has done an excellent job of disabling
> much of that, but the upstream attitude clearly is to cherry-pick
> their dependencies.  This is pretty typical for Google projects from
> what I've seen - ChromeOS basically is a fork of Gentoo with many
> packages being fairly dated, and Android does just about everything
> its own way, typically releasing third-party code into production
> before any upstream packages have access to it.

Google generally prefers agility. Particularly when machines have gobs
of memory (so bundling is not as big of a deal as it was previously)
and they can staff security fixes for all their bundled libs. This is
quite a pervasive attitude there. Coming from a distribution
background it can be weird to see the different priorities (and
terrible systems that build the packages that work on $DISTRO, ew.)

-A

>
> Of course, we should encourage upstream to improve its practices.  I
> just wouldn't count on it, so I think we need to give the chromium
> team discretion on just how much patching they think they can handle.
> They're obviously pretty good at it already.
>
> Rich
>

Re: [gentoo-dev] Chromium system ffmpeg

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

On 1/16/13 8:40 AM, Alec Warner wrote:
> Google generally prefers agility. Particularly when machines have gobs
> of memory (so bundling is not as big of a deal as it was previously)
> and they can staff security fixes for all their bundled libs. This is
> quite a pervasive attitude there. Coming from a distribution
> background it can be weird to see the different priorities (and
> terrible systems that build the packages that work on $DISTRO, ew.)

Bundling is not a problem because of build time, memory usage of disk
space concerns (they are to some degree, but that's _not_ the primary
reason).

The biggest problem are incompatible forks (which we have in chromium
tree), which actually hinder agility.

For example, system ICU is more recent than the bundled one. Same for
several other bundled libraries. A lot of effort goes into maintaining
the forks and cherry-picked patches - that effort could be spent on
something else.

People often speak about the cost of unforking/unbundling, but
forking/bundling has its cost too. Because of Windows and Mac, some
libraries have to be bundled, but there should be no reason to fork (at
least not long-term).

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Chromium system ffmpeg

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

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.

Oh, one more thing: is there an easy way to check whether e.g.
CODEC_ID_OPUS is defined? I just realized it's not a pre-processor
symbol but an enum value so #ifdef wouldn't work.

I could always check the version #defines, but it requires checking
version control to see when it was introduced. It would be great to just
have a way to more simply exclude code that requires CODEC_ID_OPUS.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Chromium system ffmpeg

[Luca Barbato]

On 19/01/13 20:10, "Paweł Hajdan, Jr." wrote:
> have a way to more simply exclude code that requires CODEC_ID_OPUS.

Exclude in chrome or in libavcodec?

The latter is a matter of adding --disable-decoder=opus and/or not
--enable-libopus in the configure.

lu

Re: [gentoo-dev] Chromium system ffmpeg

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

On 1/20/13 1:46 AM, Luca Barbato wrote:
> On 19/01/13 20:10, "Paweł Hajdan, Jr." wrote:
>> have a way to more simply exclude code that requires CODEC_ID_OPUS.
> 
> Exclude in chrome or in libavcodec?
> 
> The latter is a matter of adding --disable-decoder=opus and/or not
> --enable-libopus in the configure.

Exclude in chrome, in case old ffmpeg/libav does not support it.

Paweł



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Chromium system ffmpeg

[Alexis Ballier]

On Sun, 20 Jan 2013 10:08:27 -0800
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:

> On 1/20/13 1:46 AM, Luca Barbato wrote:
> > On 19/01/13 20:10, "Paweł Hajdan, Jr." wrote:
> >> have a way to more simply exclude code that requires CODEC_ID_OPUS.
> > 
> > Exclude in chrome or in libavcodec?
> > 
> > The latter is a matter of adding --disable-decoder=opus and/or not
> > --enable-libopus in the configure.
> 
> Exclude in chrome, in case old ffmpeg/libav does not support it.


yes in this case you need some #if VERSION < foo conditions (git blame
& cie are your friends to obtain the version in which it appeared). it
becomes messy when you realize minor/micro versions within ffmpeg and
libav are not at all the same.

vlc has some macro for this:

http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/avcodec.h;h=8c8dd20ed3400527cab84265f4442bf06eb06f8d;hb=HEAD

/* LIBAVCODEC_VERSION_CHECK checks for the right version of libav and
FFmpeg 282  * a is the major version
* b and c the minor and micro versions of libav
* d and e the minor and micro versions of FFmpeg */
#define LIBAVCODEC_VERSION_CHECK( a, b, c, d, e ) \
     (LIBAVCODEC_VERSION_MICRO <  100 && LIBAVCODEC_VERSION_INT >=
     AV_VERSION_INT( a, b, c ) ) || \ 
     (LIBAVCODEC_VERSION_MICRO >= 100 && LIBAVCODEC_VERSION_INT >=
     AV_VERSION_INT( a, d, e ) )


_MICRO is >= 100 in ffmpeg so that you can distinguish between the two.


Another option could be to check for the enum member at configure
time.


Alexis.