Introduction.
For higher compression rate, video encoders usually use methods of representation of each video frame as 3 separate channels: one for luminosity and two for color. This allow to compress color info separately from the luminance. Special math and quantization of this channels bring to us YUV (Y - luma, like "luminance"; U and V - chroma, like "color").
Human eye is less sensible to color than to brightness of the visual signal, thus chroma info (UV) require less detail...
From the next OBS Studio build (v22.0.0 expected), mp4 files recorded with the YUV Color Space: 601 will be marked about the used matrix too (up to v21.1.2, files lacks this info). The guide's video sample files was recorded by v0.15.4, thus the info of used matrix is missing. And actually, I doubt to update some of this sample files to new one, because:
the standard (BT.601) is obsolete
BT.601 has no info about 4:2:0 chroma subsampling usage
when info is missing - it is big chance that the movie file was created with the standard that had no alternatives at that time (and thus it is BT.601)
Anyway, after new release, if needed, you may create your own new test files with OBS Studio - the charts are the same.
@Banyarola can you playback the I444 bt709 at 1920x1080 videos that is part of the test movies? Only if you have the 1920x1080 display of course. Try proper player (like mpv) to see the 4:4:4 sign during playback. I want to know what color has background of the 4:2:2 sign (that is on the left). It seems to be that the test movie has color planes shift after first ~25 rows. If the background is pink (or purple) that means that the video is broken and should be replaced from the tests movies. This also means, that at least on my system the OBS Studio has unresolved bug.
While precision of the planes conversion was increased in OBS Studio v24.0.0 and thus the test charts videos needs update. But with the v24 of OBS Studio new chroma sampling offset was applied to 4:2:0 ( https://github.com/obsproject/obs-studio/pull/1995 ). And this change made some test not valid any more. I wasn't aware of sampling techniques that exist in programming (and recommended for usage during chroma subsampling) when first created the charts - this caused encoding matrix test to fail with the OBS Studio v24, always...
Yeah, this chart were created "as is" but before I will find proper solution (or suitable solution) the error that present in the charts should be described more.
The encoded image (see above) displayed back on the screen with any other chroma subsampling applied should produce robust result in this test because the final pixels will be completely desaturated. This was possible only if two nearby pixels are combined into one horizontally (2 to 1 reduction). But in programming, to scale down images very fast, the technique of texture sampling with linear filter may be used. That means that each new pixel calculated just for needed (final) amount of output pixels and new values calculated as average of two nearby pixels (usually weighted by distance). It sounds almost similar, isn't it? So, what's wrong? The place from what points are samples will be taken is the main question! And there is difference. It is not like cubic or lanczos filter is used for chroma planes scale down. Previously OBS Studio does this sampling as follow (4:2:0):
Code:
simplification: R'G'B' to Y'CbCr first, 4:4:4 (then subsampling of CbCr):
Y' Y' Y' Y'
Y' Y' Y' Y'
Y' Y' Y' Y'
Y' Y' Y' Y'
Cb Cb Cb Cb
Cb Cb Cb Cb
Cb Cb Cb Cb
Cb Cb Cb Cb
Cr Cr Cr Cr
Cr Cr Cr Cr
Cr Cr Cr Cr
Cr Cr Cr Cr
4:2:0 from previous Y'CbCr to be sampled as:
Y' Y' Y' Y'
Y' Y' Y' Y' no changes, just copy/reuse
Y' Y' Y' Y'
Y' Y' Y' Y'
Cb Cb Cb Cb
CB CB calculate new pixel color (CB) if it was lie in center of 2x2 area
Cb Cb Cb Cb
Cb Cb Cb Cb
CB CB
Cb Cb Cb Cb
Cr Cr Cr Cr
CR CR calculate new pixel color (CR) if it was lie in center of 2x2 area
Cr Cr Cr Cr
Cr Cr Cr Cr
CR CR
Cr Cr Cr Cr
this is common technique for the JPEG images (when encoder uses 4:2:0).
Now, in OBS Studio v24.0.0, samples are taken from the points shifted to the left by half pixel:
Code:
subsampling of CbCr to 4:2:0:
Y' Y' Y' Y'
Y' Y' Y' Y' no changes, just copy/reuse
Y' Y' Y' Y'
Y' Y' Y' Y'
Cb Cb Cb Cb
CB CB calculate new pixel color (CB) if it was lie in between of 2x2 area vertically
Cb Cb Cb Cb and aligned to each odd column
Cb Cb Cb Cb
CB CB
Cb Cb Cb Cb
Cr Cr Cr Cr
CR CR calculate new pixel color (CR) if it was lie in between of 2x2 area vertically
Cr Cr Cr Cr and aligned to each odd column
Cr Cr Cr Cr
CR CR
Cr Cr Cr Cr
this is common technique for the MPEG2 (when encoder uses 4:2:0).
This was recommended technique because hardware supports limited number of display algorithms during decompression, and simple, fast, good quality image produced with the Catmull-Rom interpolation ( https://docs.microsoft.com/en-us/wi...video-rendering#converting-420-yuv-to-422-yuv ). Yeah, the 4:2:0 is needs to be restored back to 4:4:4 before display, and it can be done in two steps - 4:2:0 to 4:2:2 and then 4:2:2 to 4:4:4 using just one algorithm. Robust and simple. And many devices already had support for the 4:2:2 to 4:4:4 when 4:2:0 and BT.709 only begins its way to our display devices.
In both cases the resulting image for NV12 looks as:
So, each new chroma pixel in v23.0.0 of OBS for the mentioned test is like (current_pixel + next_pixel) / 2
each new chroma pixel in v24.0.0 of OBS for the mentioned test is like (previous_pixel / 2 + current_pixel + next_pixel / 2) / 2
(here calculations based on image that has square pixels and all sides multiply of 32)
This new calculations (technically sampling with the linear filter) was the info that I miss during the creation of the test. While chroma subsampling detection marks were designed by me to survive the 1, 2, 3 and 4 pixels shift both horizontally and vertically (4:2:2 and 4:1:1 even has two shifted tables because of this), the encoding detection wasn't, so it fails now.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.