Improved Browser Color Rendition

[chris319]

I don't know what's changed, but the color rendition on Mozilla Firefox, Chrome and Opera has improved greatly on both local files and YouTube videos.

These browsers used to have grievous color errors on both local and streaming videos. VLC, Windows Media Player and Microsoft Edge still have serious color errors -- not so with the three browsers. mentioned.

I am surprised that the videos still look good on YouTube, considering all of the resampling they do. The errors are down to +/- 2, within rounding error for floating-point calculations. For example, my test pattern contains a yellow patch consisting of R = 180, G = 180, B = 16. The three browsers mentioned give R = 178, G = 180, B = 15, not perfect but a great improvement over, say, a year and a half ago. I am using Windows 10 but I'm inclined to think the improvement is not due to the change from Windows 7 to Windows 10, or we would be seeing improved color rendition on VLC, Edge and Windows Media Player. That we get different results on different video players suggests that the errors are on the decoder side rather than the encoder side.

Here is a link to the test pattern I used. The colors can be checked with any "eyedropper" color checker.

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

[jagabo]

Media players usually use video overlay to display video. In that case the graphics card is responsible for the YUV to RGB conversion. The graphics card's conversion is controlled by its setup applet in Control Panel, in the Media or Video section, not the Desktop section.

Browsers use Windows GDI to display video. They perform the YUV to RGB conversion internally then give the RGB video to Windows to display.

Your video at youtube is encoded incorrectly. It is flagged as rec.709 (normal for HD video) but the YUV video is encoded as rec.601. Also, the levels are wrong if you intended the 7 bar to be super-black and the background to be black. And if you meant for the color bars to be fully saturated the 16's should all be zero. Ie, fully saturated RGB red is R=180, G=0, B=0 (though R=192 is commonly used in colorbar patterns).

[chris319]

Your video at youtube is encoded incorrectly. It is flagged as rec.709 (normal for HD video) but the YUV video is encoded as rec.601.

What tool did you use to determine this?

the levels are wrong if you intended the 7 bar to be super-black and the background to be black. And if you meant for the color bars to be fully saturated the 16's should all be zero.

Why guess about my intentions?

[jagabo]

Your video at youtube is encoded incorrectly. It is flagged as rec.709 (normal for HD video) but the YUV video is encoded as rec.601.

What tool did you use to determine this?

I downloaded the mp4 video from youtube and examined it with MediaInfo. It showed the video was flagged as rec.709 (I believe Youtube flags all YUV video as rec.709 when the re-encode). But if you convert the video to RGB using a standard rec.709 matrix you get the wrong colors. If you convert to RGB using a rec.601 matrix you get the right colors (within a few units on each of the RGB primaries).

the levels are wrong if you intended the 7 bar to be super-black and the background to be black. And if you meant for the color bars to be fully saturated the 16's should all be zero.

Why guess about my intentions?

Because the RGB colors you used imply you were trying to make a standard colorbar chart (including super-blacks and 3/4 intensity RGB bars) using limited range RGB. But you converted the RGB to YUV as if it was full range RGB.

[chris319]

The .bmp file was encoded here: http://www.online-convert.com/

then it was uploaded to YouTube. I suspect that site may be an on-line front end for ffmpeg.

I'm installing MediaInfo now and can then check the local file. What YouTube does with the file after I upload it is out of my hands.

the RGB colors you used imply you were trying to make a standard colorbar chart (including super-blacks and 3/4 intensity RGB bars) using limited range RGB. But you converted the RGB to YUV as if it was full range RGB.

The colors are straight out of RP 219; nothing wrong with that. How should I have encoded it? I can use ffmpeg but what would the correct ffmpeg parameters be? One exception: I don't like the RP 219 pluge so I use a -4% box (3.5 IRE) at digital 7, emulating the ECR1-1978 pluge.

I have done this test in the not-too-distant past using the same procedure and the colors were much further off in the browsers, so it appears something has changed somewhere.

[chris319]

Here is the output from MediaInfo for the local file. What would be the proper way to encode this? Should it be encoded as rec 601?

General
Complete name                            : C:\Users\User\Videos\Test Pattern.mp4
Format                                   : MPEG-4
Format profile                           : Base Media
Codec ID                                 : isom (isom/iso2/avc1/mp41)
File size                                : 433 KiB
Duration                                 : 15 s 0 ms
Overall bit rate                         : 236 kb/s
Writing application                      : Lavf57.57.100

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : Baseline@L3.1
Format settings, CABAC                   : No
Format settings, ReFrames                : 3 frames
Format settings, GOP                     : M=1, N=30
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 15 s 0 ms
Bit rate                                 : 235 kb/s
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 25.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.010
Stream size                              : 430 KiB (99%)
Writing library                          : x264 core 148
Encoding settings                        : cabac=0 / ref=3 / deblock=1:0:0 / analyse=0x1:0x111 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=30 / keyint_min=3 / scenecut=40 / intra_refresh=0 / rc_lookahead=30 / rc=crf / mbtree=1 / crf=21.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

[jagabo]

Limited range RGB isn't meant for viewing. It's a special editing RGB mode that lets you work with super-blacks and super-whites. The standard colorbars should look like this when viewed properly:


[Attachment 40873 - Click to enlarge]

The background is pure black (0,0,0) the white patch is full white (255,255,255), and the color primaries in the colorbars are either 0 or 191. The super-black patch (7) is no different than the background because monitors can't produce super-blacks. It would require them to suck photons out of your eyes.

When encoded properly with rec.709 colors you will get something like the attached video. When you view that video it should look like the above image, aside from rounding errors in the RGB->YUV->RGB conversion.