Log in

View Full Version : Chroma subsampling : 4:2:0 (Type 1 / Type 0)

tonemapped
3rd September 2021, 07:22
I've been experimenting with DVDFab for Blu-ray to x265 (I'm happy with a CLI but find tools with GUIs fun to play around with, like Staxrip - never Handbrake as it's horrible) conversion and found - annoyingly, after converting about a dozen films - an oddity with the output.

For some reason, the blacks are washed out and I believe it's down to the chroma subsampling it's using.

Partial mediainfo output (I know it's 8-bit which I wouldn't normally choose for HEVC).


ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L4@Main
Codec ID : V_MPEGH/ISO/HEVC
Color space : YUV
Chroma subsampling : 4:2:0 (Type 1 / Type 0)
Bit depth : 8 bits
Color range : Full
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709


I believe the part marked in bold is the cause of the problem. I've never encountered an issue with 4:2:0 Type 1/0 so not entirely sure what's going on. Is this something that can be fixed without encoding the Blu-rays again (e.g. a flag in mkvmerge)? As I don't seem to have this issue with x264, is it related to that in some form?

Here's a simple demonstration of the issue - the grey area should be black.
https://i.ibb.co/6Wky4yx/dvdfab-output-colour-chroma-issue.png (https://ibb.co/jrS8L82)
Direct link to png: https://i.ibb.co/CHfwnwZ/dvdfab-output-colour-chroma-issue.png

Any thoughts on the matter are much appreciated.
Boulder
3rd September 2021, 19:18
I think color range should be limited instead of full. If it's encoded with the wrong settings, it needs to be redone to correct it.
SeeMoreDigital
3rd September 2021, 19:35
For 4K UHD I recommend that you always encode in 10-bit, not 8-bit...

But as with any re-encoding it all depends on your characteristics of your source content.
tonemapped
4th September 2021, 00:07
I think color range should be limited instead of full. If it's encoded with the wrong settings, it needs to be redone to correct it.

Yep, how silly - totally missed that. Cheers for pointing it out.
Balling
16th September 2021, 09:50
This is a latest experiment from myself and Jan in ffmpeg: we pass through chroma location. So if you have a jpeg image that (all jpeg does) uses center location it will pass through center to chroma loc in hevc VUI in SPS. Alas it looks like it effs up on R'G'B' JPEGs.
benwaggoner
17th September 2021, 19:00
This is a latest experiment from myself and Jan in ffmpeg: we pass through chroma location. So if you have a jpeg image that (all jpeg does) uses center location it will pass through center to chroma loc in hevc VUI in SPS. Alas it looks like it effs up on R'G'B' JPEGs.
Well, R'G'B' doesn't have chroma positions, so it should be a straightforward fix.

And excellent progress! This will be a very welcome feature.
Balling
19th September 2021, 10:21
Well, R'G'B' doesn't have chroma positions, so it should be a straightforward fix.

And excellent progress! This will be a very welcome feature.

First of call R'G'B' can be subsampled in JPEG, yeah. In many, many different ways. https://trac.ffmpeg.org/ticket/8930#comment:4 Second of all it just always assumes center since that is the only way for jpeg, it is globally tagged, even for not subsampled R'G'B', which is wrong of course.