[FFmpeg-devel] [PATCH] avcodec: libdav1d AV1 decoder wrapper

[James Almer]

On 9/29/2018 10:14 AM, Hendrik Leppkes wrote:
> On Sat, Sep 29, 2018 at 3:02 PM Devin Heitmueller
> <dheitmueller at kernellabs.com> wrote:
>>
>> On Sat, Sep 29, 2018 at 6:04 AM Rostislav Pehlivanov
>> <atomnuker at gmail.com> wrote:
>>> I'd much rather go with the original intent which was to merge the decoder
>>> into lavc.
>>
>> Ronald can correct me if I'm wrong, but I suspect a key goal behind
>> the decoder was to have a standalone library which could be shared
>> across a variety of projects (both open and closed source).  Merging
>> it in directly will create a maintenance headache as the two source
>> trees diverge.  It also makes unit testing more difficult, since
>> Ronald/VideoLAN can write unit tests for the library (which will
>> presumably be consumed by a number of projects/products) and be
>> confident that those same unit tests apply to the version that is used
>> by ffmpeg.
>>
>> I don't think having libx264/libx265 out of tree hasn't been a
>> nightmare for anyone.  I don't think this case would be any different.
>>
> 
> Decoders and encoders are quite a different type of beast. For one
> decoders are ultimately "finished" at some point, where the number of
> changes drastically reduces over time, and decoding is the bread and
> butter of avcodec, which would give immediate av1 support to hundreds
> if not thousands of applications out there, without any further
> developer intervention.

I'm guessing LGPL is a deterrent for some potential users VideoLAN
wanted for this decoder, hence the 2-Clause BSD license in libdav1d.

> 
> Additionally, I can already name an important key area where not
> having an internal decoder will be a nightmare: hardware decoding.
> Our hardware decoding framework heavily relies on having a decoder
> that does all the header parsing, frame management, and whatnot, and
> the hardware acceleration hooks just by-pass the actual slice decoding
> then. If we don't have an internal decoder, we would have to either
> build half decoder just to hook up hwaccel, or dav1d would have to
> give us extremely detailed bitstream information and slice-level
> bitstream hooks, which I don't think is very practical either.
> 
> A new mainstream codec without hardware acceleration support is not
> going to make it, no matter how fast you make the decoder.

Yeah, this is one of the main reasons to have it as an internal decoder.
But considering actual hardware capable of decoding AV1 will not come
out until like late 2019 at the earliest, there's time for libdav1d to
mature before porting it becomes a must.
At some point it will be "complete" and development pretty much halted,
much like vp9 currently is (not counting some missing assembly), so the
argument about extra maintenance of separate codebases will not apply
anymore.

And to be honest the extra maintenance argument is not too strong to
begin with, considering all the time lost having to NIH a lot of
standard features already available in libavutil, like memory allocator
wrappers and reference counted buffers, or muxer/demuxers to use with
their CLI, all already available in libavformat, because they can't link
to either of them.

> I'm still a
> bit annoyed that this wasn't even a consideration when it was decided
> to move it into a separate library, but its not like they actually
> asked for arguments.
> 
> - Hendrik