VQ Test for H.264 Encoders

[FranceBB]

VQ Test for H.264 Encoders

Broadcast Encoder : Francesco Bucciantini (FranceBB)
Senior Video Editor : Livio Aloja (algia)

The files analysed are named “Test9” as we did several tests and they are aimed to
encode files from lossless masters for internal usage as mezzanine files.

1) Input file and encoding target
2) Comparison between encoders
3) Results and final thoughts

For this test, the original masterfile is an Apple ProRes 4K UHD (3840x2160) 10bit lossless, progressive at 50fps 4:2:2 planar.
The target is an XAVC Intra Class 300, which is basically an H.264 with all the frames encoded as Intra, 4K UHD (3840X2160), 10bit lossy, progressive at 50fps, 4:2:2 planar.
The source file includes SDR contents encoded with the BT709, HDR PQ contents encoded with the BT2100 and HDR HLG BT2020nc, but since there wasn't a way to include all of them as metadata in the source file, both the source and the encode have been flagged as “BT709”.
During the encoding, no transformations have been applied (i.e the color-matrix has been left untouched and they have been encoded as they are).
This actually allowed us to check the output using objective metrics.

2) Comparison between encoders

In this test, we're gonna compare x264 and the built-in encoder of Vantage developed by Telestream which is supposed to be a paid encoder for professional usage which costs a lot of money, while x264 is a totally free and open source solution as we all know.



The first graph shows that x264 performed way better than Telestream on almost every scene, with just a few exceptions on a very limited number of frames.



PSNR pretty much confirms what is shown by SSIM, in other words, it shows that x264 performs significantly better than Telestream on almost every scene, but compared to SSIM, it gave credit to Telestream on a few more frames.

SSIM Individual Charts (From best to worse):




x264 scored a total of 378143 in SSIM, while Telestream scored a total of 345587.
In other words, x264 outperformed Telestream by 8.61%.

PSNR Individual Charts (From best to worse):




x264 scored a total of 787135 in PSNR, while Telestream scored a total of 760927.
In other words, x264 outperformed Telestream by 3.33%.

3) Results and final thoughts

As we expected, x264 outperformed Telestream on pretty much every scene, with only a few frames every now and then that ended up getting a better score on Telestream.
Grain retention was greatly better on x264 even without the –-tune grain or any other particular settings, while banding wasn't an issue thanks to the 10bit precision. Overall, the quality was pretty much clear without any particularly noticeable artifacts. Not only Vantage is a paid solution developed by Telestream which costs a lot of money, but their performance is far worse than x264 which is free, open source and supports Avisynth input. For this reason, we've been using x264 for years to encode H.264 files and we'll keep encoding in H.264 using x264 as we consider it one of the best (if not THE BEST) H.264 encoder.

[Blue_MiSfit]

Seems odd to me - AFAIK Telestream uses x264 under the hood. They certainly use x265 for HEVC encoding.

http://www.telestream.net/vantage/va...ultiscreen.htm

Maybe they have multiple AVC encoders available, not sure. In any case, good to see x264 performing well here, but this is of course only part of the picture. Vantage is a great workflow tool, enabling a lot of things that would require custom software development otherwise (adaptive workflows, lots of custom broadcast metadata / container handling).

Not that I'm a Telestream shill, but Vantage definitely has a lot of value for shops that need to process video at scale into specialized formats, but who can't / won't invest in their own custom software

Also, how can your source be both SDR and HDR PQ? I understand how using HLG kind of combines SDR and HDR, but I don't understand how you could have a single ProRes source file that's both SDR and HDR with PQ. That would require unique sources AFAIK. Maybe I'm missing something / misunderstood something?

Are you quite certain that both of your test code paths are doing the same thing with your levels and colors? If something unexpected happened in the Vantage pipeline that would explain the consistently better performance with plain x264.

[excellentswordfight]

What settings/software did you use to create an valid XAVC-I Class300 file with x264?

We are using XAVC-I Class300 as well as our DI 2160p50 house format. What were your subjective opionion of the format? Imo its has a lot of blocky tendencies (at least from most encoders I've seen), not enough to cause issues during normal viewing scenarios, but not really good enough for a "mezzanine" format. But the bitrate compared to other formats and the good format-support in the broadcast world still makes it an top contender.

[FranceBB]

Originally Posted by Blue_MiSfit

Seems odd to me - AFAIK Telestream uses x264 under the hood. They certainly use x265 for HEVC encoding.

http://www.telestream.net/vantage/va...ultiscreen.htm

Maybe they have multiple AVC encoders available, not sure.

Yes, they do have x264 inside along with other AVC encoders according to which one you choose. There's also the legacy 32bit one. The reason why they implemented their own encoder was to make it compatible with their dedicated processing units which make use of GPU and claim to be faster. My aim was to test that encoder and I noticed that it was definitely faster than x264, but the quality was far worse.

Originally Posted by Blue_MiSfit

Also, how can your source be both SDR and HDR PQ? I understand how using HLG kind of combines SDR and HDR, but I don't understand how you could have a single ProRes source file that's both SDR and HDR with PQ. That would require unique sources AFAIK. Maybe I'm missing something / misunderstood something?
Are you quite certain that both of your test code paths are doing the same thing with your levels and colors? If something unexpected happened in the Vantage pipeline that would explain the consistently better performance with plain x264.

Well, I know; there's no way to tell a decoder how it should dynamically decode different color curves, however the idea was to let it preserve the input exactly as it was, without clipping/removing/modifying anything and without turning on any HDR optimization. In other words, we simply included three different curves: PQ, HLG and linear and we wanted it to maintain them exactly as they were without touching levels and outputting PQ, HLG and linear. It would be like Shooting in a logaritmic curve and asking the encoder to keep the curve: sure, you'll lose metadata, but scenes-related metadata was static, so it wasn't a big deal. The reason for that was to make sure that it wasn't "cheating" (i.e it wasn't turning on any HDR-related filters aimed to better deal with HDR sources).

Originally Posted by excellentswordfight

What settings/software did you use to create an valid XAVC-I Class300 file with x264?

We are using XAVC-I Class300 as well as our DI 2160p50 house format. What were your subjective opionion of the format?

x264 does support AVC-Intra Class (50, 100, 200) with the --avcintra-class command, however it doesn't officially support AVC-Intra Class 300. There's a patch which has been submitted in 2017, but it has never been approved and merged, therefore support is "unofficial". In order to make a compliant stream from Avisynth, I used the following settings:

avs4x264mod.exe "\\BOXSVR\Share_Windows_Linux\AVS Script.avs" --x264-binary "x264-10b.exe" --input-depth 16 --preset medium --profile high422 --keyint 1 --bitrate 500000 --vbv-maxrate 500000 --vbv-bufsize 500000 --deblock -1:-1 --overscan show --colormatrix bt709 --range tv --log-level info --thread-input --transfer bt709 --colorprim bt709 --videoformat component --nal-hrd cbr --output-csp i422 --output "\\BOXSVR\Share_Windows_Linux\raw_video.h264"

and I've been feeding avs4x264mod with a 16bit interleaved stream.
x264 dithered it down to 10bit itself in the best possible way.
By forcing keyint to 1, you are gonna have all frames as intra, and by setting the bitrate to 500Mbit/s profile 4:2:2 10bit, you are gonna have what pretty much is the Intra Class 300 preset.

Format XAVC intra (Class 300)
Level/Profile High 4:2:2 Profile @ Level 5.2
GOP I-frame only
Chroma Sampling 4:2:2
Bit Rate 500 Mbit/s
Constant Bit Rate Yes
Picture Size (active) 3840 x 2160
Aspect Ratio 16:9
Frame Rate 50fps
Scan Type Progressive
Bit depth 10 bit
Timecode in GOP header Not in use




As to my opinion about this standard, well, I gotta say that when we had to decide which format use for 4K (both BT709 SDR and HLG HDR), I was thinking about H.265 HEVC and definitely not about H.264. Sure, H.264 is a very mature codec that has been stable over the years, however it wasn't designed for such an high resolution and it doesn't have specific tools to handle HDR unlike H.265. Besides, we're still using MPEG-2 for SD and HD/FULL HD even now in 2019, so when we were discussing which codec to use for 4K in 2017 my fear about H.264 was that we were going to be stuck over the years with it while the whole world would have been moving forward, repeating the whole MPEG-2 XDCAM Scenario. Anyway, we didn't really have many option as my boss really liked it. The other codecs we were discussing were AppleProRes and AVID DNxHR. Although our whole system is AVID-Based, with DNxHR we would have been too limited as it doesn't really have compatibility other than inside AVID. As to the AppleProRes, I'm not really a fan of Wavelet-based codecs and not only the bitrate would have been extremely high, but since it was designed by Apple (which isn't exactly a company known for liking Windows), encoding it on Windows would have been extremely slow with softwares that support it and also not supported by AVID Media Composer which is our NLE. In the end, we opted for H.264 for merely practical reasons and also because it's supported everywhere by pretty much everything. Besides, by having everything encoded as Intra, we don't even have errors caused by the GOP, which is extremely useful if we receive a feed and something fucks up. With the MPEG-2 long GOP required by XDCAM, I've seen horrible slice-errors too many times due to a satellite feed which didn't arrive correctly or a feed received via fiber that failed for whatever reason or a defective support and so on. All in all, I think that H.264 is a very mature codec which has been designed in such a good way that it's still relevant nowadays as it scales well enough for UHD resolutions for which it wasn't originally designed for. It's widespread and it will still be for years to come, therefore I think that XAVC-Intra Class 300 may not be the best format of the world, but overall, is a nice format to have and it's better compared to many other professional options.

[excellentswordfight]

Originally Posted by FranceBB

x264 does support AVC-Intra Class (50, 100, 200) with the --avcintra-class command, however it doesn't officially support AVC-Intra Class 300. There's a patch which has been submitted in 2017, but it has never been approved and merged, therefore support is "unofficial". In order to make a compliant stream from Avisynth, I used the following settings:

avs4x264mod.exe "\\BOXSVR\Share_Windows_Linux\AVS Script.avs" --x264-binary "x264-10b.exe" --input-depth 16 --preset medium --profile high422 --keyint 1 --bitrate 500000 --vbv-maxrate 500000 --vbv-bufsize 500000 --deblock -1:-1 --overscan show --colormatrix bt709 --range tv --log-level info --thread-input --transfer bt709 --colorprim bt709 --videoformat component --nal-hrd cbr --output-csp i422 --output "\\BOXSVR\Share_Windows_Linux\raw_video.h264"

and I've been feeding avs4x264mod with a 16bit interleaved stream.
x264 dithered it down to 10bit itself in the best possible way.
By forcing keyint to 1, you are gonna have all frames as intra, and by setting the bitrate to 500Mbit/s profile 4:2:2 10bit, you are gonna have what pretty much is the Intra Class 300 preset.

I'm aware of the settings and specifications of the h264 stream in xavc-i, and that x264 can be used to create it. I was more intrested in creating an compliant mxf with all necessary metadata and flags, so that the material can be used for XAVC-I compliant equipment (EVS, Videoservers etc). Cause without those tools it I dont really see using free software and x264 as an viable option professionally.

And tbh, I think XDCAM 50 for 1080i is still fine, and the number of substitutes of an standardized format suitable for an broadcast company house format that doesnt increase the datarate is still almost non existant.

[FranceBB]

I see...
Well, I do actually use EVS as well and as a matter of fact I'm using it in this very moment Link but in XDCAM.
Anyway, when I sent the file to our other department, I remember that I muxed with ffmpeg the .h264 file encoded with x264 and I made sure to flag correctly all the audio channels encoded in PCM 24bit.
Our system did actually accept it. Can you try to encode a few seconds with the settings I posted above, mux it in .mxf via ffmpeg and then play it in your system? I think it should be able to play it.

[kolak]

Vantage uses x264 libraries, but older than current ones.
Other libraries are Mainconcept. They have some bits shifted to GPU, but I found that it's not really faster than native x264 (I think this patch is publicly available).
Telestream doesn't have any own code for any established encoder (it's all licensed) as far as I know. Same apply to muxers.

[benwaggoner]

I'm skeptical of any comparison that doesn't document the parameters used.

Also, SSIM is simply not that well subjectively correlated. Using --tune ssim worsens subjective quality even though it improved SSIM scores. And its correlation is even worse in HDR.

There still isn't any substitute for subjective testing, especially if comparing subjectively high quality variants. Even VMAF is not very sensitive to differences without obvious artifacts.