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

[Vittorio Giovara]

On Sat, Apr 5, 2014 at 7:13 PM, wm4 <nfxjfg at googlemail.com> wrote:
> 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.

The easiest solution would be to stop the daily merge and let the two
projects live on their own -- that would definitely prevent ABI
breakage on this side.

Since this is not gonna happen any time soon, there could be an
initial effort on bringing the API offer on par, at least on the most
sensible parts: eg. it's not necessary that both projects have the
same functions but enums, structs and typedefs probably could be
aligned in most cases.
Then (theoretically) patches could be forwarded to both projects (from
both sides) or kindly ask to append a --cc option when api-breaking
patches are sent.

The real hard part would be how to convince one project that a given
feature addition/removal is necessary and how to deal the situation
when there is disagreement.
-- 
Vittorio

On Sat, Apr 5, 2014 at 7:13 PM, wm4 <nfxjfg at googlemail.com> wrote:
> 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...)
>
>> 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
> breakage.
>
> 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,
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



-- 
Vittorio