Test Pattern on YouTube

[chris319]

Here is a test pattern I have made, mainly for checking color and luminance accuracy:

https://www.youtube.com/watch?v=G86FdE9XhqA

If using Firefox, pause the playback and use a program such as ColorZilla to check the color values in the color patches. The RGB readout (in hex) on ColorZilla should match the text in the color patch. They likely will not match in all cases.

The workflow for making this test pattern was:

bmp file -> online-convert.com to mp4 -> YouTube. I suspect online-convert.com may be an online front end to ffmpeg.

[pandy]

Use Avisynth and x264 with proper color space description...

[chris319]

Use Avisynth and x264 with proper color space description...

Could you please elaborate?

[Skiller]

Unless this behavior has changed recently, YouTube does not consider any color space description of the uploaded video. Use Rec.709 and it'll have correct colors on YouTube.

[chris319]

Is it not safe to assume that rec.709 is being used when a video is being encoded as an mp4 file, presumably using H.264 by, say, ffmpeg or Windows Movie Maker? What other color space might commonly be used for mp4?

I get color errors when the mp4 file is played back locally on different players such as Firefox, Chrome, I.E., Opera or VLC, bypassing any on-line server altogether.

When the unencoded bmp file is viewed locally on any of these programs, there are no color errors. This suggests errors in either the encoding or decoding process or both.

[pandy]

Use Avisynth and x264 with proper color space description...

Could you please elaborate?

It is quite clear - encode h.264 with x264, use proper colour space description i.e. bt709

When the unencoded bmp file is viewed locally on any of these programs, there are no color errors. This suggests errors in either the encoding or decoding process or both.

So download video from YT to local HDD and use proper decoder to decode video.

[chris319]

So download video from YT to local HDD and use proper decoder to decode video.

How many YouTube users download their videos prior to viewing in order to play them using a "proper decoder"?

Probably none.

[jagabo]

You should use rec.709 colors with youtube, not rec.601.

[chris319]

You should use rec.709 colors with youtube, not rec.601.

Are you saying ffmpeg and Windows Movie Maker use bt.601 for mp4 encoding by default?

[pandy]

So download video from YT to local HDD and use proper decoder to decode video.

How many YouTube users download their videos prior to viewing in order to play them using a "proper decoder"?

Probably none.

How you verify where is a problem? in video?, in YT transcoding? in your browser decoder? in browser renderer?

btw proper mean one that was verified as OK - easy to do this when source is available.

[jagabo]

You should use rec.709 colors with youtube, not rec.601.

Are you saying ffmpeg and Windows Movie Maker use bt.601 for mp4 encoding by default?

I don't know about WMM but ffmpeg will convert RGB to YUV with a rec.601 matrix by default.

[chris319]

I don't know about WMM but ffmpeg will convert RGB to YUV with a rec.601 matrix by default.

I've dusted off an old ffmpeg .bat file and I'm seeing that now, thank you.

[chris319]

Here is the command line I'm using to launch ffmpeg from my .bat file, and it works, but I'm not sure how to specify bt.709 color space. Does anyone reading this know how?

ffmpeg -y -loop 1 -i test_pattern.bmp -r 30 -t 10 -c:v libx264 -preset slow -crf 18 test_pattern.mp4

[jagabo]

I believe you need to add "-vf colormatrix=bt601:bt709" after specifying the input.

[chris319]

I believe you need to add "-vf colormatrix=bt601:bt709" after specifying the input.

Thank you very much for that.

Would it work to just add "-vf colormatrix=bt709", omitting the ":bt601"?

[jagabo]

Would it work to just add "-vf colormatrix=bt709", omitting the ":bt601"?

I don't think so. The command converts from one colorspace to the other so it needs both an input and output colormatrix. But why bother asking when it will only take you 10 seconds to try it for yourself?

BTW, I recommend you also specify the colormatrix in the x264 options by adding " -x264opts colormatrix=bt709" after specifying libx264. That will give you the highest probability of the video playing properly.

[chris319]

Would it work to just add "-vf colormatrix=bt709", omitting the ":bt601"?

I don't think so. The command converts from one colorspace to the other so it needs both an input and output colormatrix. But why bother asking when it will only take you 10 seconds to try it for yourself?

BTW, I recommend you also specify the colormatrix in the x264 options by adding " -x264opts colormatrix=bt709" after specifying libx264. That will give you the highest probability of the video playing properly.

Thanks again for the help. I understand now about needing an input and an output. I will try "-vf colormatrix=rgb:bt709" and see what happens, as I'm starting with an RGB .bmp file.

[chris319]

Encoding with the following command line:

ffmpeg -y -loop 1 -i test_pattern.bmp -t 10 -c:v libx264 -x264opts colormatrix=bt709 -vf colormatrix=bt601:bt709 -preset slow -crf 18 test_pattern.mp4

Still getting color errors when played back locally using VLC.

Color #942525 appears as #932623. Not the exact color but an approximation.

NOTE: The test pattern has been modified and has different colors than the one you see on YouTube.

[jagabo]

Color #942525 appears as #932623. Not the exact color but an approximation.

That's perfectly normal. The conversion from RGB to YUV and back to RGB will typically give 1 or 2 digit differences when dealing with 8 bit components.

[poisondeathray]

As jagabo says - there's going to be rounding errors and other lossess when converting 8bit RGB to 8bit YUV .

You can encode RGB with x264 as well. This will give you perfect color accuracy on test patterns locally. But if it's for youtube, it will get converted to YUV 4:2:0 .

And if your goal is youtube or other streaming platforms - then there are many other problems you will face. In addition to what YT does behind the scenes - there are problems such as browser type /configuration, OS, HW accel on vs. Off , If GPU on, then GPU settings (levels), HTML5 vs. Flash . You will never get 100% consistency across all client configurations. It's a bloody mess right now.

[chris319]

Color #942525 appears as #932623. Not the exact color but an approximation.

That's perfectly normal. The conversion from RGB to YUV and back to RGB will typically give 1 or 2 digit differences when dealing with 8 bit components.

I'm sure that's true but it needn't be. I've written code to go from RGB to YCbCr in bt.709 space and back to RGB. The math is quite straightforward and I get perfect colors every time.

It's possible that the programmers are taking shortcuts to speed up their code. That's understandable when you're doing real-time playback, but if you're encoding a file not in real time it's questionable.

[chris319]

You can encode RGB with x264 as well. This will give you perfect color accuracy on test patterns locally. But if it's for youtube, it will get converted to YUV 4:2:0 .

That's what I've been doing. Take a look at my command line and it's all encoded in x264 and bt.709, and still color errors on local playback.

But if it's for youtube, it will get converted to YUV 4:2:0.

I find it hard to believe that with millions of users, YouTube has the CPU capacity to re-encode everyone's home movies. I would suspect encoders and browsers first.

there are problems such as browser type /configuration, OS, HW accel on vs. Off , If GPU on, then GPU settings (levels), HTML5 vs. Flash . You will never get 100% consistency across all client configurations. It's a bloody mess right now.

You're right about it being a bloody mess. They probably aim to get the colors "close enough for home movies", quality be damned.

One of the Firefox programmers shared this with me:

When using hardware accelerated video decoding the conversion is left to the GPU and we don't control it.

We will use hardware accelerated video decoding for H264 when available but not for VP8/VP9

[poisondeathray]

You can encode RGB with x264 as well. This will give you perfect color accuracy on test patterns locally. But if it's for youtube, it will get converted to YUV 4:2:0 .

That's what I've been doing. Take a look at my command line and it's all encoded in x264 and bt.709, and still color errors on local playback.

Nope, you 're converting to YUV444 using Rec601, then converting again to Rec709 but in YUV with that commandline . Also, there is a double conversion because of the colormatrix filter (there would be "less" loss converting only once to YUV using 709 directly, because it's only 1 8bit conversion)

RGB using libx264 in ffmpeg would use "-c:v libx264rgb -pix_fmt rgb24"

ffmpeg -y -loop 1 -i test_pattern.bmp -t 10 -c:v libx264rgb -pix_fmt rgb24 -preset slow -crf 18 test_pattern_rgb.mp4

But if it's for youtube, it will get converted to YUV 4:2:0.

I find it hard to believe that with millions of users, YouTube has the CPU capacity to re-encode everyone's home movies. I would suspect encoders and browsers first.

Sure they do. In fact, each video gets converted to about a dozen different versions, including different video formats and audio formats. Different browsers and OS's can preferentially call a specific type. For example Chrome typically gets VP9 recently, not h264

Color #942525 appears as #932623. Not the exact color but an approximation.

That's perfectly normal. The conversion from RGB to YUV and back to RGB will typically give 1 or 2 digit differences when dealing with 8 bit components.

I'm sure that's true but it needn't be. I've written code to go from RGB to YCbCr in bt.709 space and back to RGB. The math is quite straightforward and I get perfect colors every time.

It's possible that the programmers are taking shortcuts to speed up their code. That's understandable when you're doing real-time playback, but if you're encoding a file not in real time it's questionable.

99.99% of distribution video is currently 8bit YUV. This includes streaming content, DVD, Blu-ray. There is no way to go back to original 8bit RGB values with 8bit YUV . In addition, 99.99% of distribution video is chroma subsampled (4:2:0) so there is no way to get exactly the same RGB values.

(But consumer 10bit video is right around the corner being more commonplace with HEVC, for example UHD BD supports it)

[jagabo]

Color #942525 appears as #932623. Not the exact color but an approximation.

That's perfectly normal. The conversion from RGB to YUV and back to RGB will typically give 1 or 2 digit differences when dealing with 8 bit components.

I'm sure that's true but it needn't be. I've written code to go from RGB to YCbCr in bt.709 space and back to RGB. The math is quite straightforward and I get perfect colors every time.

Not with 8 bit integer RGB and 8 bit integer YUV you didn't. Especially not with limited range YUV. There are only about 1/6 as many YUV values that map to RGB values. So 16 million RGB colors map to about 2.5 mllion YUV values. So several RGB values will map to the same YUV value and most colors will be changed on the round trip from RGB to YUV to RGB.

[jagabo]

(But consumer 10bit video is right around the corner being more commonplace with HEVC, for example UHD BD supports it)

Yes, 8 bit RGB can be converted to 10 bit YUV and back without losses. I posted ANSI C code that does it here:

https://forum.videohelp.com/threads/376996-Lossless-Workflows-using-Premiere-Pro-Virtua...=1#post2446709

That's rec.601 but rec.709 isn't too different in that respect.

[poisondeathray]

@jagabo - yes, I saw that. I don't understand the math or the code, but it sure looks pretty Nice to get another confirmation as others have shown the mathematical proof as well with matlab . Hopefully things will shape up better when 10bit becomes more common for end user

But in current reality, in most professional video programs, you do get losses with 10bit and higher precision conversions. I think it's primarily from dithering for bit depth conversions - there is no way to turn it off or adjust it.

[chris319]

ffmpeg -y -loop 1 -i test_pattern.bmp -t 10 -c:v libx264rgb -pix_fmt rgb24 -preset slow -crf 18 test_pattern_rgb.mp4

Perfect colors all around, but only VLC plays it. None of the browsers (Firefox, Opera, Chrome, IE) can handle it.

[poisondeathray]

ffmpeg -y -loop 1 -i test_pattern.bmp -t 10 -c:v libx264rgb -pix_fmt rgb24 -preset slow -crf 18 test_pattern_rgb.mp4

Perfect colors all around, but only VLC plays it. None of the browsers (Firefox, Opera, Chrome, IE) can handle it.

heh - that's why YT (and other streaming sites like vimeo, etc...) convert everything to a format that is "playable" in a browser. Namely 4:2:0 either h.264 for flash or HTML5, or VPx for HTML5

[poisondeathray]

At least with the old flash (not HTML5), you had some resemblance of control if you hosted your own webpage (not a re-encoding site like YT, which discarded flags and didn't put new ones in). Because flash player payed attention to flags embedded in the stream that governed the YUV back to RGB trip - it was a predictable system that you could work with all client configurations , browsers, OSes to get consistent results. HW on meant Rec601 was used. Always. ; HW off meant user flag, otherwise Rec709. Always.

Now it's a bloody mess. There are 100's of different permutations, and not just Rec601 vs 709

For example YT pays attention to the full range flag now, and clamps the re-encode to 16-235

[chris319]

Not with 8 bit integer RGB and 8 bit integer YUV you didn't.

Ach! You found the fly in the ointment! It works with 16-bit words but not 8 bit.

That explains a lot.