[FFmpeg-devel] [PATCH] avcodec: libdav1d AV1 decoder wrapper
atomnuker at gmail.com
Sun Sep 30 00:47:24 EEST 2018
On Sat, 29 Sep 2018 at 15:19, James Almer <jamrial at gmail.com> wrote:
> 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
> >>> 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.
On the other hand the 2-Clause BSD is a deterrent for me to write some
assembly and just generally pour work on it.
> 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.
Considering the code style and some parts of the internal API are quite
close I reckon the wrapper won't survive for more than a few months, and
will definitely be gone by January.
I'd agree to the wrapper if it didn't make it to 4.1, since it won't be in
4.2. No point in adding a non-default decoder that users may need to
specify (not sure how precedence works with both libaomdec and libdav1id).
Especially knowing how long cargo cult command lines and API usage lasts.
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
Given the license difference, the preference of everyone involved with it
for LGPL (its only BSD and a separate library because money) I think
chances are people/companies will sooner abandon it to work on their fork
than use the base version as-is (or in case of companies contribute).
More information about the ffmpeg-devel