Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-2 Encoding

Reply
 
Thread Tools Search this Thread Display Modes
Old 15th July 2019, 22:18   #1  |  Link
FranceBB
Broadcast Encoder
 
FranceBB's Avatar
 
Join Date: Nov 2013
Location: Germany
Posts: 620
VQ Test for MPEG-2 Encoders

VQ Test for MPEG-2 Encoders

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

The files analysed are named “Test4” 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) The impact of Dithering on objective metrics
3) Comparison between encoders
4) Results and final thoughts
5) Bibliography

1) Input file and encoding target

For this test, the original masterfile is an Apple ProRes, FULL HD (1920x1080), 10bit,
4:2:2 planar BT709 Limited TV Range with both progressive and interlaced contents at
25fps. The target is an XDCAM50 lossy mezzanine file for broadcast usage, which is an MPEG-2,
FULL HD, 50Mbit/s, 8bit, 4:2:2 planar (yv16), BT709 Limited TV Range, closed GOP, with both
progressive (flagged as interlaced) and interlaced contents at 25fps.
The test reel has different types of contents to test how encoders behave.

2) The impact of Dithering on objective metrics

Internally, whenever we get an high bit depth source, we apply Dithering in order to
avoid to introduce banding while bringing it to 8bit. In particular, we use the Floyd-Steinberg
error diffusion.
The algorithm achieves dithering using error diffusion, meaning it pushes (adds) the residual
quantization error of a pixel onto its neighboring pixels, to be dealt with later. It spreads the
debt out according to the distribution (shown as a map of the neighboring pixels):



The pixel indicated with a star indicates the pixel currently being scanned, and the blank pixels
are the previously-scanned pixels. The algorithm scans the image from left to right, top to
bottom, quantizing pixel values one by one. Each time the quantization error is transferred to
the neighboring pixels, while not affecting the pixels that already have been quantized. Hence, if
a number of pixels have been rounded downwards, it becomes more likely that the next pixel is
rounded upwards, such that on average, the quantization error is close to zero.
The original lossless masterfile for this test is 10bit, but the encoded file has to be 8bit due to
the XDCAM specifications, so we were wondering whether Dithering has a positive or a negative
impact on objective metrics compared to truncation.

We tried to run some internal tests with three different types of dithering:

– Serpentine Floyd-Steinberg error diffusion
– Stucki error diffusion
– Atkinson error diffusion

When we compared each test, we noticed that the Serpentine Floyd-Steinberg error diffusion is
a well-balanced algoritm (which confirms the reason why we use it internally), the
Stucki error diffusion looks “sharp” and preserve light edges and details well and the Atkinson
error diffusion generates distinct patterns but keeps clean the flat areas. Unfortunately, though,
even if they look “better” to the human eye, this is strictly subjective, as they only look “different”.
As a matter of fact, on both SSIM and PSNR, each dithering method has got a lower score
compared to truncation.
The interesting fact, though, is that it didn't get a lower score in every single frame, as there are a
very few frames in which dithering algorithms managed to get an higher value compared to
truncation, but overall truncation outperformed dithering algorithms by 1.51% in SSIM and 0.3%
in PSNR, that's why we decided not to include Dithering as reference.

3) Comparison between encoders

In this part, we are going to compare the following encoders: Ateme, AWS, Selenio, Telestream and x262.
For the reason already explained above, the file encoded with x262 has been encoded without any dithering algorithms and just using truncation.




The first graph represents how the different encoders behave during the whole video.
Since SSIM goes from 0 to 1 with many digits after the 0, we re-scaled it in order to make it more human readable. From the tests, AWS performed better than other encoders, with a score of 289921, followed by Ateme by a very narrow margin (289639). At the third position, with a rather significant quality drop, we have Telestream with 281010, followed by Selenio with 279577.
At the bottom, we have x262 which scored 276854 and which is outperformed by 4.51%.




PSNR pretty much confirms what is shown by SSIM.
AWS performed better than all the other encoders and scored 733272, followed by Ateme by a narrow margin with 731639. At the third position, there's Telestream with 729195, followed by Selenio which scored 722449. At the bottom, there's x262 with a total score of 720755.
According to PSNR, though, Selenio is closer to the quality reached by x262 rather than the one reached by Telestream.

SSIM Individual Charts (From best to worse):







PSNR Individual Charts (From best to worse):






4) Results and final thoughts

AWS managed to achieve a better score compared to all the other encoders, but its advantage is only because it had a slightly higher spike on a few scenes, while overall it had pretty much the same performance as Ateme. In particular, grain retention was pretty much fine on both, but when random noise recorded by the camera came into the equation, AWS managed to handle it slightly better than Ateme, but again, overall, they performed pretty much the same, that's why the margin was really narrow. At the third place, Telestream performed worse compared to Ateme by a not-so-high margin, but still, it was worse. Even though Telestream performed worse, it's still closer to the upper part of the chart rather than to the lower part of the chart, however it didn't quite manage to get to the same level of Ateme on too many scenes, that's why it ended up being third. At the fourth position there's Selenio that performed significantly worse than AWS and Ateme and worse than Telestream by a still significant margin. At the bottom of the table, there's x262, which apparently is the worse MPEG-2 encoder among those at such an high bitrate and its performance was pretty low overall and on top of that, it struggled to encode sport properly. On the other had, x262 is free and open source, while all the other encoders are closed source, need to be purchased, their cost is very high and they don't support Avisynth input, so we would still choose x262 over those other encoders. We're already using x262 and we're not planning to change anytime soon.

Bibliography

–Visgraf (Vision and Graphic Laboratory) Mathematics, FS algorithm
–Proceedings of the Society of Information Display (adaptive algorithm)
__________________
Broadcast Encoder
LinkedIn

Last edited by FranceBB; 15th July 2019 at 22:20.
FranceBB is offline   Reply With Quote
Old 16th July 2019, 19:07   #2  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,393
AWS is an ex Elemental encoder, no?
I also found FS dithering been the best, but I also kept adding tiny amount of noise (this was for Blu-ray encoding though).
kolak is offline   Reply With Quote
Old 17th July 2019, 00:27   #3  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,512
Fascinating

I was always impressed with Elemental's MPEG-2 encoder, so I'm not surprised to see it doing so well here. Particularly when doing low bitrate 15 Mbps CableLabs compliant 1080i it absolutely crushed my go-to at that point - Harmonic ProMedia Carbon aka Rhozet Carbon Coder.

Any particular reason you left Harmonic out of the mix?

Last edited by Blue_MiSfit; 17th July 2019 at 06:33.
Blue_MiSfit is offline   Reply With Quote
Old 17th July 2019, 11:03   #4  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,393
Is it that good?
Rhozet was a reference for interlaced content for me.
kolak is offline   Reply With Quote
Old 18th July 2019, 02:46   #5  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,512
Rhozet was fine, and WAY better than Digital Rapids (now Imagine's Selenio product line), but at low bitrates (15 Mbps for 1080i) it had a lot of blocking that totally went away with Elemental. Plus, the latter was WAY faster

Gosh I haven't thought about this in awhile, It's been years since I've done any MPEG-2 encoding.
Blue_MiSfit is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 15:37.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.