Jan 2, 2024, 14:01 by nuomi2...@gmail.com: > On Mon, Jan 1, 2024 at 10:50 PM Lynne <d...@lynne.ee> wrote: > >> Jan 1, 2024, 15:16 by nuomi2...@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? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".