[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