On Sat, Sep 29, 2018 at 3:02 PM Devin Heitmueller <dheitmuel...@kernellabs.com> wrote: > > On Sat, Sep 29, 2018 at 6:04 AM Rostislav Pehlivanov > <atomnu...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
