Versatile Video Coding (VVC) / H.266: HEVC successor

[Gravitator]

You can download > Test_VVC_AV1_x265 (https://files.videohelp.com/u/227452/Test_VVC_AV1_x265.rar)
AV1 gives clearer textures on dark areas (lines and ship skin).
VVC:
-s 1920x1080 --framerate 23.976 --preset slower -q 29
AV1:
--cpu-used=0 --target-bitrate=1000 --max-partition-size=64 --sb-size=64 --input-bit-depth=10 --bit-depth=10
x265:
--output-depth 10 --profile main10 --qg-size 64 --opt-cu-delta-qp --tu-intra-depth 4 --tu-inter-depth 4 --hme --hme-search star,star,star --subme 4 --rect --amp --max-merge 2 --no-early-skip --rskip 0 --tskip --opt-ref-list-length-pps --bframes 6 --ref 4 --rc-lookahead 150 --bitrate 1100 --crf-min 0.00 --crf-max 0.00 --qpfile GENERATED_QP_FILE --limit-refs 0 --rd 5 --psy-rd 1.00 --rdoq-level 1 --psy-rdoq 10.00 --aq-strength 2 --sao-non-deblock --limit-sao --psnr --range limited --colormatrix bt709

[benwaggoner]

Is this a question or a statement? If the latter it's very much debatable because from what I've seen VVC is much much better than AV1 while being a lot less computationally expensive.
Do you mean a lot less computationally expensive for encode or decode?

[birdie]

Do you mean a lot less computationally expensive for encode or decode?

Both.

[birdie]

AV1 gives clearer textures on dark areas (lines and ship skin).


x265 has seen many years of refinements and improvements. x266 hasn't even been released yet. We are talking about proof of concept encoders.

Also, I've no idea how to play VVC.vvc. Please just upload PNGs to imgsli or something.

[Gravitator]

Also, I've no idea how to play VVC.vvc.
A temporary solution...
Convert to Ut Video/lossless video format:
vvdecapp.exe -b c:\VVC.vvc -o c:\VVC.yuv && ffmpeg -video_size 1920x1080 -framerate 23976/1001 -pix_fmt yuv420p10le -i c:\VVC.yuv -c:v -acodec -vcodec utvideo -color_primaries 1 -color_trc 1 -colorspace 1 с:\VVC.mkv && del c:\VVC.yuv
Play it via FFplay:
vvdecapp.exe -b с:\VVC.vvc -o - | ffplay -f rawvideo -s 1920x1080 -pix_fmt yuv420p10le -

FFplay hot key control:

- q / ESC - exit
- f - full screen mode
- f / Space - pause
- m - on / off sound
- 9 / / - volume -
- 0 / * - volume +
- s - frame by frame
Rewind:
- left / right arrows - rewind 10 seconds
- up / down arrows - rewind 1 second
- Page up / Page down - rewind to the previous / next part or by 10 minutes

[Jamaika]

x265 has seen many years of refinements and improvements. x266 hasn't even been released yet. We are talking about proof of concept encoders.

Also, I've no idea how to play VVC.vvc. Please just upload PNGs to imgsli or something.
For amateurs. VVC codec isn't created for converting bt709 PNG images to 10/12bit bt2020 fullrange images. Despite the HDR image, there is no desire to develop HDR for JPEG2000 or HEIF. JPEG XS is to have new possibilities, but no one has seen it. The new JPEG and VVC codecs are to have much greater data protection in the fight against piracy. Yes, not every file we open. Is VVC photo codec? Not. Can raw images from Canon apertures be converted to VVC. I failed. Converting CR2 to TIFF Adobe RGB is already lossy. In theory, it is possible. When we have converter suitable for yuv files and VVC codec with HDRtools functions. FFmpeg doesn't convert raw camera files to yuv bt2020. Problem with how to convert photos to yuv and then play back on TV. After all, TVs today hasn't VVC decoder and home monitors are 8bit bt709.

ffmpeg.exe -loglevel error -i 111.png -an -f rawvideo -frames 1 -vf scale=1280:720:in_color_matrix=bt709:in_range=full:out_color_matrix=bt709:out_range=full,format=yuv420p 111.yuv

EncoderApp.exe --SummaryVerboseness --InputFile=111.yuv --BitstreamFile=image.vvc --SourceWidth=1563 --SourceHeight=1558 --FrameRate=25.000 --InputBitDepth=8 --OutputBitDepth=10 --MSBExtendedBitDepth=8 --MatrixCoefficients=0 --InputColorPrimaries=-1 --LMCSSignalType=2 --ConformanceWindowMode=1 --FramesToBeEncoded=1 --HashME=1 --IBC=1 --DecodingRefreshType=1 --Profile=auto --InputSampleRange=1 --AspectRatioInfoPresent=1 --ChromaLocInfoPresent=1 --MaxCUWidth=16 --MaxCUHeight=16 --CTUSize=32 --MaxBTLumaISlice=32 --MaxBTChromaISlice=32 --MaxBTNonISlice=32 --MaxTTLumaISlice=32 --MaxTTChromaISlice=32 --MaxTTNonISlice=32 --CostMode=lossless --InputChromaFormat=444 --ChromaFormatIDC=444 --QP=0 --BDPCM=1 --ColorTransform=1 --VideoFullRange=1 --ChromaTS=1 --DepQuant=0 --LMCSEnable=0 --RDOQ=0 --RDOQTS=0 --SBT=0 --ISP=0 --MTS=0 --LFNST=0 --JointCbCr=0 --LoopFilterDisable=1 --SAO=0 --TransformSkip=1 --TransformSkipFast=1 --TransformSkipLog2MaxSize=5 --SAOLcuBoundary=0 --Log2MaxTbSize=5 --ALF=0 --CCALF=0 --BIO=0 --PROF=0 --InternalBitDepth=0 --IntraPeriod=1 --GOPSize=1 --SearchRange=64 --QpInValCb="17 22 34 42" --QpOutValCb="17 23 35 39" --BCW=0 --BcwFast=0 --BIO=0 --CIIP=0 --Geo=0 --AffineAmvr=0 --LMCSUpdateCtrl=1 --LMCSOffset=0 --DMVR=0 --SMVD=0 --PROF=0 --ISPFast=1 --FastMIP=1 --FastLFNST=1 --FastLocalDualTreeMode=0 --AffineAmvrEncOpt=0 --MmvdDisNum=8 --OnePictureOnlyConstraintFlag=1 --GciPresentFlag=1 --Level=15.5 --Tier=high --RateControl=0 --SubpicDecodedPictureHash=1 --MaxLayers=1 --CbQpOffset=1 --CrQpOffset=1 --TemporalSubsampleRatio=1 --LCTUFast=1 --TemporalFilter=0 --DualITree=1 --MinQTLumaISlice=8 --MinQTChromaISliceInChromaSamples=4 --MinQTNonISlice=8 --MaxMTTHierarchyDepth=3 --MaxMTTHierarchyDepthISliceL=3 --MaxMTTHierarchyDepthISliceC=3 --MMVD=1 --Affine=1 --SbTMVP=1 --MaxNumMergeCand=6 --LMChroma=1 --IMV=1 --MRL=1 --IBC=0 --AllowDisFracMMVD=1 --MIP=1 --PBIntraFast=1 --FastMrg=1 --AMaxBT=1 --HadamardME=1 --FEN=1 --FDM=1 --VerCollocatedChroma=1

[birdie]

For amateurs.

:eek::eek::eek:

I was talking about converting VVC to PNG which must be a lossless conversion :)

[Jamaika]

And here's the problem. Fraunhofer VVC Encoder isn't lossless. Is HDRtools enough for the image? Who knows that.

[birdie]

And here's the problem. Fraunhofer VVC Encoder isn't lossless. Is HDRtools enough for the image? Who knows that.

I was talking about a lossy encode by Gravitator which would be easier for everyone to check without using console. Could you calm down a bit? :cool:

[Jamaika]

Lossy coding. Fraunhofer VVC only has basic functions. For me it is codec advertisement and an attempt to catch up with the competition. The codec is lagging behind in development.
Why is it free. I do not know. It is not the only company with vvc technology.
VVC has nothing to compare with x265 presets. The first HEVC Mainconcept codecs were also underdeveloped and the quality compared with x265 was deliberately poor. Whoever made movies in Sony Vegas at low bitrates knows what it looked like.
It changed when there was youtube.
Today Fraunhofer HEVC/VVC is trying to do something with these features and that's not just a challenge. It will take time to fine tune the presets and fix the bugs. In addition, it is trying to convert the codec from c++11 to c++20 with new features, which will also take some time.

[benwaggoner]

:eek::eek::eek:

I was talking about converting VVC to PNG which must be a lossless conversion :)
PNG is natively a full range RGB format. So you still have a color space and range conversion in the process. Normally it's fine going from 8-bit YUV to 8-bit RGB, with the inverse much more lossy. But it's still not lossless.

[benwaggoner]

Lossy coding. Fraunhofer VVC only has basic functions. For me it is codec advertisement and an attempt to catch up with the competition. The codec is lagging behind in development.
Why is it free. I do not know. It is not the only company with vvc technology.
VVC has nothing to compare with x265 presets. The first HEVC Mainconcept codecs were also underdeveloped and the quality compared with x265 was deliberately poor. Whoever made movies in Sony Vegas at low bitrates knows what it looked like.
It changed when there was youtube.
Today Fraunhofer HEVC/VVC is trying to do something with these features and that's not just a challenge. It will take time to fine tune the presets and fix the bugs. In addition, it is trying to convert the codec from c++11 to c++20 with new features, which will also take some time.
It's quite normal for a variety of companies to offer their own encoder implementations in the early stage of a codec's market introduction. They've needed to build their own for internal testing, and might as well share them to promote market acceptance.

[birdie]

PNG is natively a full range RGB format. So you still have a color space and range conversion in the process. Normally it's fine going from 8-bit YUV to 8-bit RGB, with the inverse much more lossy. But it's still not lossless.

Slight changes in the color palette are barely perceivable however the loss of detail is what people will notice right away, so comparing codecs after converting their results to PNG is still valid. Besides, codecs work with the same color space which means converting them to PNG will affect them equally.

[hajj_3]

VTM 14.0 is out.

[Gravitator]

The reason for the encoder's refusal to assign an I-frame for frame №60 (scene change) ?
Themselves encode and check.

VVenC v1.1.0/VVdeC v1.1.2:
ffmpeg -i c:/raw_1080p30.mkv -pix_fmt yuv420p -f rawvideo - | vvencapp.exe -s 1920x1080 --framerate 30 --threads 2 --preset medium -q 30 -i - --output c:\test.vvc && vvdecapp.exe -b c:\test.vvc -o c:\VVC.yuv && ffmpeg -video_size 1920x1080 -framerate 30 -pix_fmt yuv420p10le -i c:\vvc.yuv -c:v -acodec -vcodec utvideo -color_primaries 1 -color_trc 1 -colorspace 1 c:\final.mkv && del c:\vvc.yuv
Download source video file (305.6MB) > raw_1080p30.mkv (https://files.videohelp.com/u/227452/raw_1080p30.mkv)
https://i.ibb.co/x5bjJkh/I-59f.jpg (https://ibb.co/kcT8Q7K)

[Balling]

Haha, wow. https://thenextweb.com/news/h266-vvc-video-codec-streaming-standards

First H.266 streamer.

[Balling]

The reason for the encoder's refusal to assign an I-frame for frame №59 (scene change) ?
Themselves encode and check.



Not all I frames are key frames. /Facepalm

[Gravitator]

Not all I frames are key frames. /Facepalm
I corrected it to the number 60. What's the difference? The encoder did not catch the change - it did not allocate the necessary bitrate. It turned out correctly on x265.

[Funky080900]

What do you mean VVenC did not allocate necessary bitrate? You encoded with constant QP (-q 30). If you want to use rate control, specify a bitrate E.g. -b 1000000. And there's no scene change detection in VVenC currently, so keyframes get placed in regular intervals.

[rwill]

Damn, guys...

I just remembered some test of VP3 where someone compared VP3 to DivX 3.11 and he set the keyframe period to 9999 sec or frames, can't remember, in VP3 and then continued to complain about quality and seek times. Now DivX 3.11 was (hacked?) to place keyframes on scenecuts but VP3 just did what it was told. Didnt serve it well to take user input literally.

@Gravitator: Would you complain about broadcast too ? Because most broadcast encoders do not insert I frames on scene change as well. They rather run with a large fixed open gop because they do not care about the screen content.

[Gravitator]

What do you mean VVenC did not allocate necessary bitrate? You encoded with constant QP (-q 30).
Cropping did not reveal the problem in -q 30:
ffmpeg -ss 00:00:02 -t 00:00:06 -i c:/raw_1080p30.mkv -pix_fmt yuv420p -f rawvideo - | vvencapp.exe -s 1920x1080 --framerate 30 --threads 2 --preset medium -q 30 -i - --output c:\test.vvc && vvdecapp.exe -b c:\test.vvc -o c:\VVC.yuv && ffmpeg -video_size 1920x1080 -framerate 30 -pix_fmt yuv420p10le -i c:\vvc.yuv -c:v -acodec -vcodec utvideo -color_primaries 1 -color_trc 1 -colorspace 1 c:\final.mkv && del c:\vvc.yuv
The problem is --rskip (artifacts to the left of the tree).
And there's no scene change detection in VVenC currently, so keyframes get placed in regular intervals.
That's the news!:o

[ksec]

How the H.266 video standard will help stream content way faster

https://thenextweb.com/news/h266-vvc-video-codec-streaming-standards


While MX Player prefers to stream its content on H.266, depending on the device and network conditions, it might have to fall back to other standards such as AV1 or H.265 on some devices, until playback support for the new standard is baked into chips that are used in those gadgets. Other streaming players will also face this challenge and have to follow suit for a while.

Mantri said that the company has been servicing content through H.266 standard to almost 20% of its customer base and it has received no complaints.


MXplayer in India are already serving 20% of their content with H.266?

Just Wow. It seems they uses Tencent software decoding [1] [2] within their Apps. And the paper [3] did a test and despite it is still early version 0.01, an Apple A12 used in iPhone XR and XS managed to decode with 30fps. Not sure anyone wants to do that due to battery issues but nevertheless it works.

Interesting.

[1] https://github.com/TencentCloud/O266player

[2] https://multimedia.tencent.com/news/202102011

[3] https://arxiv.org/pdf/2103.03612.pdf

[excellentswordfight]

Damn, guys...

I just remembered some test of VP3 where someone compared VP3 to DivX 3.11 and he set the keyframe period to 9999 sec or frames, can't remember, in VP3 and then continued to complain about quality and seek times. Now DivX 3.11 was (hacked?) to place keyframes on scenecuts but VP3 just did what it was told. Didnt serve it well to take user input literally.

@Gravitator: Would you complain about broadcast too ? Because most broadcast encoders do not insert I frames on scene change as well. They rather run with a large fixed open gop because they do not care about the screen content.
Large? Most broacasters I've come across uses a short interval (good for channel switching) DVB recommendations for AVC/HEVC is to have an RAP interval of 2s... Closed GOPs are rather common as well. But yes, its rather common to use fixed GOP without scene cut detection.

[birdie]

Speaking of MX Player: it only allows to stream VVC files, it won't play local VVC files.

[benwaggoner]

I corrected it to the number 60. What's the difference? The encoder did not catch the change - it did not allocate the necessary bitrate. It turned out correctly on x265.
Reference encoders may not do dynamic IDR detection by default. Lots of evaluation processes are done with fixed GOP durations.

[rwill]

Large? Most broacasters I've come across uses a short interval (good for channel switching) DVB recommendations for AVC/HEVC is to have an RAP interval of 2s... Closed GOPs are rather common as well. But yes, its rather common to use fixed GOP without scene cut detection.

Ye, I meant large hierarchical GOPs, with like 4 or 5 hierarchies. Something like 15 or 31 B-Pictures. So a RAP interval of 32 or 64 depending on framerate.

[FranceBB]

Large? Most broacasters I've come across uses a short interval (good for channel switching) DVB recommendations for AVC/HEVC is to have an RAP interval of 2s... Closed GOPs are rather common as well. But yes, its rather common to use fixed GOP without scene cut detection.

Yep and with keyframe = framerate generally, so every second you're able to get one.
Switching across channels would be a pain otherwise, so you're right. ;)

Speaking of MX Player: it only allows to stream VVC files, it won't play local VVC files.

Ah... I see...

[benwaggoner]

Ye, I meant large hierarchical GOPs, with like 4 or 5 hierarchies. Something like 15 or 31 B-Pictures. So a RAP interval of 32 or 64 depending on framerate.
Yeah, some professional live encoders do some amazingly complex b-frame reference layering.

Obviously one can't have more B-frames than frames in the GOP, but these can get pretty complex even in 25 or 30 frames.

Are any live encoders using RADL yet? Those should be helpful for fixed GOP durations.

[rwill]

Yeah, some professional live encoders do some amazingly complex b-frame reference layering.

Obviously one can't have more B-frames than frames in the GOP, but these can get pretty complex even in 25 or 30 frames.

Are any live encoders using RADL yet? Those should be helpful for fixed GOP durations.

I think live encoders go with RASL/CRA to avoid the slight quality "flash" you get with RADL. RADL is more for bitstream splicing. I have not seen many streams from live encoders though so I don't know really.

[contemporarymind]

I think live encoders go with RASL/CRA to avoid the slight quality "flash" you get with RADL. RADL is more for bitstream splicing. I have not seen many streams from live encoders though so I don't know really.

RADL considerably affect overall coding efficiency compared to RASL depending on GOP size and intra period. Now that VVC allows for reference picture resampling, you can do bitstream splicing/http streaming also with RASL pics. check https://arxiv.org/pdf/2103.06675

[ksec]

RADL considerably affect overall coding efficiency compared to RASL depending on GOP size and intra period. Now that VVC allows for reference picture resampling, you can do bitstream splicing/http streaming also with RASL pics. check https://arxiv.org/pdf/2103.06675

VVC continues to surprise me.

[LigH]

So welcome on board, contemporarymind https://cosgan.de/images/smilie/froehlich/a010.gif

[benwaggoner]

VVC continues to surprised me.
Yeah, takes years before all the interesting nooks and crannies of a new codec get understood, and how the different parts interact with different kinds of content and use cases.

There's still stuff that HEVC that I seen thoroughly explored and optimized, like adaptive SAO parameters.

[FranceBB]

Avisynth Script:

ColorBars(1920, 1080, pixel_type="YV12")

ChangeFPS(23.976)

trim(0, 100)


VVEnc:


ffmpeg.exe -i "AVS Script.avs" -strict -1 -an -f yuv4mpegpipe - | vvencapp.exe -i - --preset medium --format yuv420 --bitrate 250000 --profile auto --level 5.0 --passes 1 --output "VVC.h266"

pause


VVDec:


vvdecapp.exe -b "VVC.h266" -o "VVC.yuv"

ffmpeg.exe -video_size 1920x1080 -framerate 24 -pix_fmt yuv420p -i "VVC.yuv" -c:v ffvhuff -color_primaries 1 -color_trc 1 -colorspace 1 -y "final.mkv"

pause



Final decoded result:

https://i.imgur.com/XYCpmAr.png


So it looks as if somewhere it gets converted and it's no longer yuv420p 8bit.
What happened?

[Gravitator]

So it looks as if somewhere it gets converted and it's no longer yuv420p 8bit.
What happened?
Dec YUV > -pix_fmt yuv420p10le

[Funky080900]

So it looks as if somewhere it gets converted and it's no longer yuv420p 8bit.
What happened?

VVenC wants raw yuv not y4m. Also, you should tell VVenC the frame rate (-r 24), especially when you use rate control. VVenC defaults to 60 fps, so unless you tell VVenC the frame rate, 250 kbps specified would give you ~ 100 kbps for a 24 fps input (250kbps/60×24=100kbps).

ffmpeg -i "AVS Script.avs" -pix_fmt yuv420p -f rawvideo - | vvencapp -s 1920x1080 -r 24 -c yuv420 --internal-bitdepth 8 --preset medium -b 250000 -p 1 -rs 10 -o VVC.266 -i -

vvdecapp -b VVC.266 -o - | ffmpeg -s:v 1920:1080 -framerate 24 -pixel_format yuv420p -f rawvideo -thread_queue_size 64 -i - -c ffvhuff -color_primaries 1 -color_trc 1 -colorspace 1 final.mkv -y

[benwaggoner]

A curse upon all video tools that support .yuv without supporting .y4m!

[rwill]

A curse upon all video tools that support .yuv without supporting .y4m!

I like .yuv more and .y4m is somewhat dated. I dont know if it even supports more than 8 bit officially.

With .yuv you can cut out a snippet very precisely just by skipping and copying blocks of bytes with a fixed size. Like with the Unix tool 'dd'. Cant do that with .y4m. And what does one save by using .y4m ? No need to specify size and fps ?

[birdie]

A paper on H.266 > H.265:

https://arxiv.org/pdf/2109.06555.pdf

[Balling]

"So it looks as if somewhere it gets converted and it's no longer yuv420p 8bit."

This is nv21 or nv12, i.e. semi-planar
ffplay.exe -video_size 1920x1080 -framerate 24 -pix_fmt nv21 -i file

You can also try yuv420p10 and p010le!


"y4m is somewhat dated"

Heh, we just updated it to support more stuff, i.e. ffmpeg color range extension!

See https://code.videolan.org/videolan/x264/-/merge_requests/69/diffs

[ksec]

A paper on H.266 > H.265:

https://arxiv.org/pdf/2109.06555.pdf

In addition, we demonstrated that the participants had noted a difference between uncompressed 4K and 8K at a viewing distance of 0.8H for most of the tested sequences.

0.8H is approximtely 0.8m, for an 85" TV

[Jamaika]

So it looks as if somewhere it gets converted and it's no longer yuv420p 8bit.
What happened?
https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/merge_requests/2119/diffs

[benwaggoner]

0.8H is approximately 0.8m, for an 85" TV
80mm from a 219mm screen? My geometry is pretty rusty, but wouldn't that would put the viewing angle to the edges of the screen at quite a bit more than >45 degrees! Not a comfortable or plausible viewing distance for entertainment content as it exists.

Maybe one could shoot with lots of surround to fill the peripheral vision, and used a curved screen or something...

[benwaggoner]

I like .yuv more and .y4m is somewhat dated. I dont know if it even supports more than 8 bit officially.
I certainly have plenty of 10-bit .y4m files that work perfectly with a variety of tools. And avoid the myriad issues of messing up some little parameter for input and getting a garbage encode. Height, width, chroma subsampling, bit depth, fps, there's a lot of different variables that aren't always documented.

With .yuv you can cut out a snippet very precisely just by skipping and copying blocks of bytes with a fixed size. Like with the Unix tool 'dd'. Cant do that with .y4m. And what does one save by using .y4m ? No need to specify size and fps ?
Well, with .y4m one could figure out where to cut frames like that without having to specify all the stream parameters. I think you'd just need an offset from the header.

[FranceBB]

During this comparison I've been encoding a 3840x2160 23.976fps progressive 4:2:0 yv12 8bit planar masterfile lossleslly captured from a 90s film: Goodfellas. The target encode bitrate has been CBR 25 Mbit/s with the very same GOP for all codecs.

MPEG-1 (https://i.imgur.com/jKCAyef.png) - MPEG-2 (https://i.imgur.com/NmIPHJw.png) - XVID (https://i.imgur.com/STfIWR4.png) - H.264 (https://i.imgur.com/3M8hHop.jpg) - H.265 (https://i.imgur.com/rViChT4.jpg) - H.266 (https://i.imgur.com/RSeraMH.jpg)

SSIM result in a 200 frames scene picked as a reference:

https://i.imgur.com/kdKRvrC.png

https://i.imgur.com/f0wW8Tz.png

https://i.imgur.com/csh5yCO.png

If we're gonna analyze H.265 and H.266 only, we're gonna have:

https://i.imgur.com/VlVDJpk.png

Aside from some particular frames, the overall H.266 score is greater than the H.265 one, so it has a better fidelity in terms of image representation compared to H.265. On the other hand, the difference between the two is shortened by the fact that x265 has been around for quite some time, while VVEnc for H.266 is still very fresh, very new, but despite this the score obtained by H.266 is higher. If we're gonna include H.264 in the graph, we're gonna get:

https://i.imgur.com/h5WX9w9.png

As we can clearly see from the image, H.264 gets much closer to H.265 than it gets to H.266, in fact in some frames H.264 gets an even higher score than H.265 as it prefers edge preservation and grain retention (which could create some artifacts at the edges of the transform blocks) compared to H.265 which prefers a cleaner yet more blurry image. Anyway, in general, H.265 is still performing better than H.264 and it gets a better overall score. Going towards inferior and older codecs like XVID, the difference with a new codec capable to handle high resolutions like H.266 widens:

https://i.imgur.com/b7unMbf.png

XVID, at the same bitrate as H.266, achieves way lower scores in almost every scene, but on the other hand it wasn't meant to handle resolutions as high as UHD and with bitrates as low as 25 Mbit/s.

https://i.imgur.com/NmVOEN3.png

Same goes for MPEG-2 which doesn't seem to be able to keep the pace of H.266 and this point is just as valid for MPEG-1.

https://i.imgur.com/MfIcQM1.png

Therefore with the new coding tools implemented in H.266, despite the increase in the computational cost, it's possible to achieve better performances in terms of compression compared to older codecs (or, seen in another light, it's possible to achieve an higher quality at the same size) and this difference gets wider and wider as we move towards older codecs.

If you're looking for the tables, I can share them as well.

Cheers,
Frank

[rwill]

If you're looking for the tables, I can share them as well.


I am looking for the encoders used with exact version, their configuration and the source file.

[FranceBB]

I am looking for the encoders used with exact version, their configuration and the source file.

I'll post those once I get back to the computer, but from my mobile I can tell you that I used BBMpeg1 v1.4, FFMpeg MPEG-2 ('cause x262 doesn't allow any frame size larger than FULL HD), xvid 1.3.7, x264 r3065, x265 3.5+16-7955046, VVEnc 1.1.0.

The source file is analogue as I stated.
Since I don't have any real lossless masterfiles from cameras (the best I can do is UHD in LogC HDR at 1 Gbit/s in Apple ProRes 12bit), I decided to use the lossless v210 UHD capture through a black magic decklink card connected via SDI of a 90s film stored safely in a humidity and temperature controlled environment 2 floors downstairs protected from any light source. I resized the chroma inside Avisynth and I dithered down with the Floyd Steinberg error diffusion to 8bit yv12 before feeding each encoder. The source was supposed to be interesting because it's really losslessly captured and because it's supposed to have lots of grain which is supposed to be preserved.

Side note: one of the main reasons why x264 and x265 performed so good (on top of having being around for such a long time) is the --tune ssim.
On top of that, I feel like VVEnc has still a long way to go, but the principles work in the sense that it is performing better than an H.265 encode via x265, even if by a tiny fraction.

[VoodooFX]

MPEG-1 (https://i.imgur.com/jKCAyef.png) - MPEG-2 (https://i.imgur.com/NmIPHJw.png) - XVID (https://i.imgur.com/STfIWR4.png) - H.264 (https://i.imgur.com/3M8hHop.jpg) - H.265 (https://i.imgur.com/rViChT4.jpg) - H.266 (https://i.imgur.com/RSeraMH.jpg)


That XviD screenshot is quite unfortunate. ;)

[FranceBB]

That XviD screenshot is quite unfortunate. ;)

Yep. Overall it's not so bad on the I frames, but that one looked bad and far worse than other ones.
They were all encoded with single pass, so I think the lookahead of xvid somehow screwed up there xD

[Jamaika]

A piece of good work but for me this test isn't very troublesome for the competition. How does AV1 vs VVC vs EVC compare?
Google codecs are updated all the time. VVC appears to be finished.