uvg266 VVC encoder released

[a.ok.in]

@LigH and @Jamaika

I have now the opposite problem :D, those last Kvazaar and uvg266 builds you shared don't output 8-bit video. Even with 8-bit input I get 10-bit video.
Anyway, for now it doesn't matter, I can have two of each encoder for 8 and 10 bit encoding.

[Jamaika]

I have now the opposite problem :D, those last Kvazaar and uvg266 builds you shared don't output 8-bit video. Even with 8-bit input I get 10-bit video.
Anyway, for now it doesn't matter, I can have two of each encoder for 8 and 10 bit encoding.
You get 8bit video on output when you use the 8bit codec. When you use the 10bit codec you get 10bit video.

ffmpeg_avx2.exe -v verbose -i "input.mp4" -f yuv4mpegpipe -vf scale=1920:1080:in_range=limited: out_range=limited -frames:v 500 -pix_fmt yuv420p - | uvg266_08bit_avx2.exe -i - -o uvg266_yuv420p08le.vvc --input-file-format y4m --input-res 1920x1080 --input-format P420 --input-bitdepth 8 --preset medium --input-fps 30000/1001 --bitrate 1200000 --period 256 --no-info --threads auto --range tv

[LigH]

The 8 or 10 bit are not the resolution of the color channels in the YUV video. They are the precision of frequency domain parameters describing how the colors are spread over a small video area.

[Fador]

kvaazar and uvg266 are just unfinished commercials for me. Very few updates and it is not known whether this is the end of the initiative.

We are still working to make both better, but we are just a university research team with very limited resources to use for video encoders :)
Basically only one or two people in our group are trying to use work time to improve things. That's also the reason why 10bit support is not very good and in uvg266 it is actually untested. Our optimizations are mostly tied to 8bit since moving to 10bits means we have to use 16bit pixel values and would have to rewrite the optimizations to handle that.

But we have used the past 13 years to improve Kvazaar and will continue to do so even with limited resources, uvg266 is our priority since it's mostly unfinished in many ways and we have many ideas (i.e. research topics) on what to improve.

YUV 422 and 444 support has been in our list for a long time but we have many things hardcoded to 420 so it's going to take a while longer :D

Thank you all for the support!

[LigH]

@Fador: Very appreciated! Your results already have some good use.

:thanks:

[LigH]

New upload:

uvg266 0.8.1-61f7404 (https://www.mediafire.com/file/4o5n75k7nc703sc/uvg266_0.8.1-61f7404.7z/file) [GNU 15.1.0]

Fixed inter-frame coding in extreme conditions (preset placebo), issue 28 (https://github.com/ultravideo/uvg266/issues/28)

[Nania Francesco]

Sorry to butt in. I wanted to do an experiment with UVG, using ffmpeg and of course my own modified program to test 40 image files, I first converted to y4m unfortunately 420p and then I compressed with uvg --qp 28, and even if it exceeded (21MB) the limit imposed for the other codecs of 20,000,000 compressed bytes compared to the 2 GB of the bmp files to be tested, it's still fine. I needed the experiment to verify both the goodness of the h266 DCT management technique and to see the status of my SIC codec. I did the same thing with vvenc, which is a little slower but with only 18.7 MB look what it gets. Here are the results compared to other SSIMULACRA2 codecs:

1) VVenc turns out to have a weighted average: 67.40711574

2) JXL turns out to have a weighted average : 65.8556781

3) AVIF turns out to have a weighted average : 62.9328596

4) SIC turns out to have a weighted average : 60.8457124 (next version)

5) UVG(H266) turns out to have a weighted average : 60.783080643846

6) SIC turns out to have a weighted average : 58.30881121 (v. 104 Latest official release)

7) Webp turns out to have a weighted average : 53.34261722

8) JPEG turns out to have a weighted average : 37.8871165


Of course all images have been modified to be multiples of 8 even if other codecs do not require this imposition. UVG is uvg266 0,8,1-61f7404 [GNU 15.1.0]

[benwaggoner]

Here are the results compared to other SSIMULACRA2

SSIMULACRA2 is a still image metric, though, and calibrated against still images, not video. I don't expect it would have a particularly high correlation to subjective MOS given the lack of any temporal comparison. Image-only metrics have never done all that well and are actually dropping in subjective correlation as encoders increasingly adopt temporal masking techniques and other temporal psychovisual optimizations.

Unless someone has actually tested and calculated a correlation coefficient for video scenarios I wouldn't assume it was any better than VMAF.

[Fador]

then I compressed with uvg --qp 28, and even if it exceeded (21MB) the limit imposed for the other codecs of 20,000,000 compressed bytes compared to the 2 GB of the bmp files to be tested, it's still fine.

Thanks for including uvg266 in the testing even though it does not yet represent a full VVC encoder, and I would also use something like --preset veryslow for this kind of tests.

Just a bit about the methodology since you seem to only compare one quality/bitrate point but the standard way of doing any image and video comparisons currently is Bjontegaard Delta-Rate (BD-rate).
There you have (at least) 4 different quality and bitrate points fitted to a curve and then integrated (with either the quality of bitrate axis, you get either BD-PSNR or BD-rate).
The integrated values are then compared against another curves to get the difference in the curve areas. You can use PSNR/SSIM/VMAF or whatever as the quality metric but this way you get the overall compression efficiency against something else.

I hope this helps!