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. |
15th July 2019, 22:18 | #1 | Link |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,883
|
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) Last edited by FranceBB; 15th July 2019 at 22:20. |
Thread Tools | Search this Thread |
Display Modes | |
|
|