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

[Ronald S. Bultje]

Hi,

On Sat, Jan 14, 2023 at 8:32 AM Nuo Mi <nuomi2021 at gmail.com> wrote:

> On Sat, Jan 14, 2023 at 9:13 PM Nuo Mi <nuomi2021 at gmail.com> wrote:
> > I am happy to send out the first draft of vvc decoder.
> > It's not ready for upstream yet, but it's a good base ground for review
> > and future improvement.
> >
> > It has the following features:
> > * C only
> > + Fast. On a 4 cores laptop, it can get 30~35+ fps for 10bits 1080P.
> > + Support traditional features I, P B frames, 8/10 bits, chroma 400,420,
> > 422, and 444,
> > + Support VVC new tools like MIP, CCLM, AFFINE, GPM, DMVR, PROF, BDOF,
> > LMCS, ALF
> > -  Not support RPR, PCM, IBC, PALETTE, and other minor features yet.
> >
> > Please help review the attached patch and provide your valuable comment.
>

The custom threading framework (Executor, Task) - can you elaborate on this
further? If this is meant to be used outside (since it lacks VVC prefix),
it should be properly namespaced (FF, AV). It seems like you're trying to
combine row/col/frame threading from vvc_thread.c. These (frame, col/row)
are fairly common in FFmpeg and there already is existing API for that
(although you can't combine them; ask kurosu who IIRC has a private branch
doing this for hevc :-) ). This probably needs some further discussion
depending on what the rest of the community wants. Right now, this adds VVC
private functionality to enable combination of "slice" (row/col) and
"frame" threading, which other codecs wouldn't have. This is probably not a
desirable end state.

Some functions contain av_assert calls, e.g. chroma_mc_bi or
get_luma_weight. Are these not yet implemented or impossible because of
bitstream coding constraints? If former, please use
avpriv_report_missing_feature() so the user is informed of the incomplete
decoding. If the latter, please add a comment and remove #if 0 code. For
other cases of missing features (e.g. PCM), don't silently return 0, but
use avpriv_report_missing_feature() so the user is informed.

How come vvcdsp has only 8/10 bits/component code but vvcpred has 8/9/10/12
bits/component code?

Not a lot of comments other than references to the spec...

Is any of the code (e.g. tools such as sao dsp) shareable with HEVC? This
would reduce the total implementation requirement for arch-specific code.

Ronald