Hi, Le 18 mai 2024 21:55:04 GMT+03:00, Cosmin Stejerean via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> a écrit : > > >> On May 18, 2024, at 7:04 AM, Nuo Mi <nuomi2...@gmail.com> wrote: >> >> This happened many years ago. See the discussion here: >> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201221060710.12230-6-nuomi2...@gmail.com/#60589 >> Now that we have an internal vvc decoder, we can focus on improving it. >> As for the encoder, it is far more complex than the decoder. Reasonable to >> wrapper other libraries just like libx264 and libx265... > >I'm all for improving the internal decoder, and I agree that the internal >decoder should be preferred and be used by default, but it's not clear why >that should preclude adding an external decoder as an option.
Adding a disabled-by-default decoder is adding bloat, if there is not a specific known reason why that is needed. This is especially true for video decoders, where the external decoders typically will have no or worse optimisations for DSP functions, no thread support (or not accessible via libavcodec), and no integration with hwaccel. The later point has become a problem even with dav1d... >Sometimes bugs are found in the internal decoders Providing a non-default choice is a poor excuse for a bug. Most users won't know how to do that, and many FFmpeg reverse dependencies don't even allow it. > or some functionality may be missing, and having the option to fallback to an > external decoder as a workaround is very useful in practice. That I can agree, but what do you find missing in the VVC decoder compared to libvvcdec? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
