[FFmpeg-devel] To be or not to be working with libav (was: [PATCHv3] On2 VP7 decoder)

wm4 nfxjfg at googlemail.com
Sat Apr 5 19:13:26 CEST 2014

On Sat, 5 Apr 2014 18:31:14 +0200
Vittorio Giovara <vittorio.giovara at gmail.com> wrote:

> On Tue, Apr 1, 2014 at 5:11 PM, wm4 <nfxjfg at googlemail.com> wrote:
> > On Tue, 1 Apr 2014 16:44:20 +0200
> > Vittorio Giovara <vittorio.giovara at gmail.com> wrote:
> >
> >> > Keep in mind that not everyone targets his applications to run on Linux
> >> > distros. So they will just pick one project and stick with it. And if
> >> > that is FFmpeg (which generally has slightly more features and slightly
> >> > fewer bugs),
> >>
> >> Can we go past this FUD? There are bugs and features in both projects,
> >> one could even state that a review-less project like ffmpeg could
> >> introduce more bugs, but it's really not worth discussing it.
> >
> > Complaining about FUD, and calling FFmpeg a "review-less project" just
> > a sentence later...
> Well you yourself complained about the horrible hack of adding 1024
> bytes padded after a static avframe went through without review,
> slowing down performances while stating the opposite in the commit
> message.

Actually there was review. It's a horrible hack, but it solved the
problem at hand without creating a massacre in all of mpegvideo and
h264, so considering effort and effect of the two possible solutions,
it wasn't too bad.

(The real issue is that AVFrame should have never be used this way, or
that it was used this way while sizeof(AVFrame) was declared not to be
guaranteed by ABI. Whatever the history of the code is, Libav messed up
this one. Now I don't want to play the "shifting the blame" game,

> But I had really hoped that we could use this thread for something
> more constructive than "you did this to me", "I don't like you because
> you smell" and other childish troll attempts.
> I believe that we could really find some possible common points of
> cooperation rather than blaming each other projects for all world
> evil.

Yes, we should.

> As I stated in my original email, maybe we could start at looking at
> the API and avoid some of the AV_PIX_FMT_ABI_GIT_MASTER in the future.

The main problem here is that while Libav can append fields or enum
constants just fine without breaking ABI, adding them obviously breaks
FFmpeg's ABI. As a result FFmpeg does weird stuff trying to avoid

How can this fixed without requiring FFmpeg developers to send patches
to Libav for API extensions? I have no idea. Maybe they just should
send those patches to Libav. But, working on two extremely similar yet
subtly different projects simultaneously obviously causes stress, so
it's possible that FFmpeg devs prefer braindead ABI hacks over this.

> If anyone prefers to contact me off list, please don't hesitate.
> Cheers,

More information about the ffmpeg-devel mailing list