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

Nuo Mi nuomi2021 at gmail.com
Wed Feb 1 16:02:18 EET 2023

On Sat, Jan 14, 2023 at 11:52 PM Ronald S. Bultje <rsbultje at gmail.com>

> Hi,
> On Sat, Jan 14, 2023 at 10:16 AM Nuo Mi <nuomi2021 at gmail.com> wrote:
> > On Sat, Jan 14, 2023 at 10:28 PM Ronald S. Bultje <rsbultje at 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.)

Hi Ronald,
Before I go too far, could you help me review the current code? I hope the
direction is right.

I am adding highbd functions under the dsp functions. This will avoid
bytefn propagating to callers.
Current dav1d has 16 bytefn, some are really big, I guess it will double
the code size for these functions.

> 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".

More information about the ffmpeg-devel mailing list