Re: [FFmpeg-devel] Let us review and collebrate on vvc native decoder.

["Ronald S. Bultje" <rsbultje@gmail.com>]

Hi,

On Sat, Jan 14, 2023 at 10:16 AM Nuo Mi <nuomi2021@gmail.com> wrote:

> On Sat, Jan 14, 2023 at 10:28 PM Ronald S. Bultje <rsbultje@gmail.com>
> > How come vvcdsp has only 8/10 bits/component code but vvcpred has
> 8/9/10/12
> > bits/component code?
>
> I will remove it.
>

Not sure how applicable this is, but for AV1 (dav1d), most high-bitdepth
(non-8 bits/component) code has the same container type requirements (e.g.
"fits in int16_t"), so we add a "limit" (analogous "bitdepth") argument to
relevant functions and then only have to implement it once for all non-8
bits/component implementations. This is different from *_template.c
versions, because the binary size is actually significantly reduced. A
further advantage is that implementing hand-written arch-specific
implementations (asm) for one higher bitdepth automatically works for all.
Best of all: there's no runtime penalty. Maybe you want to consider that
for vvc also. (It's probably too late to fix ffh264/hevc/vp9.)

I can elaborate further if you're interested (maybe IRC?). The more complex
the codec gets (vvc > hevc > h264 > mpeg, and av1 > vp9 > vp8), the higher
the (binary) codesize gains from such an implementation choice. FFmpeg is
already huge so it's worth trying to trim its fat a bit.

Ronald
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".