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

[Hendrik Leppkes]

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.

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