On 16/01/13 12:54, Alexis Ballier wrote:
> On Tue, 15 Jan 2013 21:10:12 -0800
> ""Paweł Hajdan, Jr."" <phajdan...@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...@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
