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

[Nuo Mi]

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

> 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.)
>
> 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".
>
Hi Ronald,
It's hard to find a main 12 or main 16 clips now.  But it's a very
good suggestion.
Will ping you on IRC after I read the da1vd code and do some feasibility
analysis.
Record it as https://github.com/ffvvc/FFmpeg/issues/14 in case I missed it.