[FFmpeg-devel] [PATCH v9 07/13] vvcdec: add inv transform 1d

Lynne dev at lynne.ee
Tue Jan 2 17:55:45 EET 2024


Jan 2, 2024, 14:01 by nuomi2021 at gmail.com:

> On Mon, Jan 1, 2024 at 10:50 PM Lynne <dev at lynne.ee> wrote:
>
>> Jan 1, 2024, 15:16 by nuomi2021 at gmail.com:
>>
>> > + */
>> > +void ff_vvc_inv_dct2_4(int *coeffs, const ptrdiff_t stride, const
>> size_t nz)
>> > +{
>> > +    const int a = 64, b = 83, c = 36;
>> > +    const int x0 = coeffs[0 * stride], x1 = coeffs[1 * stride];
>> > +    const int x2 = coeffs[2 * stride], x3 = coeffs[3 * stride];
>> > +    const int E[2] = {
>> > +        a * (x0 + G2(+x2)),
>> > +        a * (x0 + G2(-x2)),
>> > +    };
>> > +    const int O[2] = {
>> > +        b * x1 + G2(+c * x3),
>> > +        c * x1 + G2(-b * x3),
>> > +    };
>> > +
>> > +    coeffs[0 * stride] = E[0] + O[0];
>> > +    coeffs[1 * stride] = E[1] + O[1];
>> > +    coeffs[2 * stride] = E[1] - O[1];
>> > +    coeffs[3 * stride] = E[0] - O[0];
>> > +}
>> >
>>
>> Is that how the transforms are specified (matrices)?
>>
> Yes, a, b, c are matrix coeffs.
>

Awful codec design carried over from HEVC.
Whatever.


>> Also, why are you not adding the transformed residual *directly* to the
>> input.
>> This is how all our other decoders do this, because it skips a copy. This
>> isn't
>> something you can quite optimize later on.
>>
> It is possible, but it's a bit more complicated than other codecs.
> For chroma, we need to perform lmcs_scale_chroma before adding it to the
> residual.
> Let's track it with https://github.com/ffvvc/FFmpeg/issues/177, and fix it
> later.
>

At the resolutions VVC is designed to deal with, a fully memory copy
can add significant overhead, and this could be tricky to do later on.
It would also block SIMD code from being added.

I wouldn't mind templaing the transforms for luma and chroma,
and integrating lmcs_scale_chroma directly in the transforms.
Would that help?


More information about the ffmpeg-devel mailing list