Modify Color Space Flag

[chris319]

There may be progress with Firefox AVC. Good luck getting Chrome, Chromium and Opera to follow suit. They're sure to need handholding when we get into 2020 and 2100. Clearly they don't do proper QC in the video realm.

As I said earlier, bt.601 was never intended for computer video. God knows why they even use it.

In broadcast we take measurements (as does the U.S. FCC).

[chris319]

A lot of people erroneously believe YouTube resampling/re-encoding is the source of color errors but my testing shows this not to be the case. My 709 test pattern uploaded to YouTube and viewed with Edge or IE, which apparently default to 709, have correct colors. So YouTube appears not to be the culprit.

As you know, the luma coefficients are floating-point numbers so we get rounding error. I figure some values are off by 1 in the encoding process and off by 1 in the decoding process, which adds up to +/- 2.

[poisondeathray]

A lot of people erroneously believe YouTube resampling/re-encoding is the source of color errors but my testing shows this not to be the case. My 709 test pattern uploaded to YouTube and viewed with Edge or IE, which apparently default to 709, have correct colors. So YouTube appears not to be the culprit.

In the general case, that's true - youtube just passes through YUV video in the re-encode. It's the display setup (browser, gpu, driver , settings) that determines if you what you see is acceptable or way off, in addition to which version you're actually streaming.

But to confirm that definitively if youtube is the culprit or not - you have to download the streamed version of the video , not just look at browser results. Because if YT did some wrong processing e.g. 601, but browser XYZ also display it incorrectly e.g .601, then it could look "correct" even though underlying video is not. ie. 2 wrongs can make a "right" as illustrated the 2nd case below. But if browser XYZ displays the 601 converted video with 709, then it looks wrong

But there are other (fairly common) cases where youtube behaviour is the culprit for an undesireable change in color (and possibly levels). One group is when source has full range flag. For example, some cameras record in a MOV container with a full range flag ON. Many Canon and Nikon DSLR's do this. Youtube will clamp the output of the re-encode and that will change levels and color. This is another case where you might want to use roozhou or golgol patches to strip the full range flag if you were uploading original camera files that were properly exposed. YT didn't used to do this, only within the last few years.

The other is uploading RGB formats. Maybe direct video game RGB captures, or maybe RGB screen captures for tutorials that sort of thing. The YT RGB=>YUV conversion uses 601. Regardless of dimensions . So the actual video will be converted incorrectly by convention if for HD (not just the display) - but in this case for AVC, "2 wrongs make a right" and it looks right for HD on YT when streaming AVC on browsers like firefox , but wrong in IE/edge. The YT streamed VP9 version will look wrong in the default HTML5 player for firefox, when it was "right" for the generic case for VP9. Downloading the actual streamed AVC video will show the 601 improperly converted version.

Of course there are workarounds you can do prior to uploading, but joe public /layman might not know this stuff they just upload the files as is.

[chris319]

Note that my test pattern colors are confined to studio swing (16 - 235).

If YouTube, Vimeo, Dailymotion, et al. muck around with the colors in some cases and not in others, I don't suppose there's much we can do. If browsers are defaulting to 601 we can try to be the squeaky wheel as I have started to do with Mozilla. Maybe Chromium could be persuaded to default to 709, but Opera? Who knows?

[chris319]

I can't test VP9. The .webm files output by ffmpeg with VP9 encoding are corrupt. Neither VLC nor Firefox can play them.

I got the latest ffmpeg build from zeranoe.

ffmpeg also gets the colors all messed up when encoding H.265.

[poisondeathray]

I can't test VP9. The .webm files output by ffmpeg with VP9 encoding are corrupt. Neither VLC nor Firefox can play them.

I got the latest ffmpeg build from zeranoe.

ffmpeg also gets the colors all messed up when encoding H.265.

Everything works on windows here for VP9 and HEVC. I'm using ffmpeg from zeranoe too , but about a month old (shouldn't matter)

Default HTML5 player in firefox won't be able to play HEVC, only VP9. VP9 looks correct to me now (it was wrong maybe half a year ago)

A media player like VLC will depend on how you have it configured.

You can verify if actual YUV data is correct by controlling the RGB conversion for display in something like avisynth or vapoursynth by specifying the matrix . So ffmpeg doesn't mess up anything if you feed it correctly. Maybe you inadvertently did a conversion in ffmpeg ? Or maybe not displaying properly ?

libx265 can use flags like libx264 (not that it really matter, most setups ignore anyways. madvr is about the only renderer that reads them) . But I still can't find any info or documentation on VP9 colorimetry flags

[chris319]

What is your vp9 command line?

Remember, I'm trying to encode an RGB bmp image in a loop. It works just fine with H.264/AVC/mp4.

Default HTML5 player in firefox won't be able to play HEVC

I never said I was using Firefox to play 265. Just VLC.

[poisondeathray]

I use avisynth to control the RGB=>YUV conversion . But you can use -vf scale to do it too. Eitherway in 8bit you're going to get +/- 2 deviation

for vp9 using libvpx

ffmpeg -i input.avs -c:v libvpx-vp9 -crf 18 -b:v 0 -an libvpx-vp9.webm

for hevc using libx264

ffmpeg -i input.avs -c:v libx265 -crf 18 -x265-params colorprim=bt709:transfer=bt709:colormatrix=bt709 -an libx265.mp4

Here are the reference RGB png from wikipedia , libx265, libvpx-vp9 encode from ffmpeg . I've verified encodes are correct (with the expected rounding errors) . If colors appear "way off", it means the viewing method has a problem

avs

ImageSource("SMPTE_Color_Bars_16x9.svg.png")
converttoyv12(matrix="rec709")
assumefps(30000,1001)
showframenumber()
showtime()
trim(0,300)

Upload is timing out for some reason, won't accept attachment
Another host
https://www.mediafire.com/?u6s81sbghxiu6aq

[chris319]

I used your code to encode my .bmp image and the colors are majorly screwed up. At least the webm file opens with Chrome.

ffmpeg encodes RGB to H.264 just fine.

 bin\ffmpeg -i test_pattern709.bmp -c:v libvpx-vp9  scale=out_color_matrix=bt709           -crf 18 -b:v 0 -an libvpx-vp9.webm

[poisondeathray]

I used your code to encode my .bmp image and the colors are majorly screwed up. At least the webm file opens with Chrome.

ffmpeg encodes RGB to H.264 just fine.

 bin\ffmpeg -i test_pattern709.bmp -c:v libvpx-vp9  scale=out_color_matrix=bt709           -crf 18 -b:v 0 -an libvpx-vp9.webm

You forgot to specify -pix_fmt , so you will be encoding gbrp because of RGB input. out_color_matrix only applies if sw_scale is called to do RGB<=>YUV conversions.

VP9 supports many pixel formats and bit depths, but browsers can only play a subset. Both FF and chrome support 8bit 4:2:0, even 4:4:4. But only chrome supports 10bit4:4:4. YT actually has some HDR streams in 10bit4:2:0

h264 using libx264 worked for you before, because in ffmpeg libx264 RGB is called using -c:v libx264rgb (ie. you have to explicitly call it) , so it automatically converts to YUV 4:2:0 if you use -c:v libx264 or even omit it (libx264 is the default encoder now)

ffmpeg -r 30000/1001 -loop 1 -i input.bmp -vf scale=out_color_matrix=bt709 -pix_fmt yuv420p -frames:v 300 -c:v libvpx-vp9 -crf 18 -b:v 0 -an output.webm

[chris319]

That code does not generate an output file at all.

ffmpeg -r 30000/1001 -loop 1 -i input.bmp -vf scale=out_color_matrix=bt709 -pix_fmt yuv420p -frames:v 300 -c:v libvpx-vp9 -crf 18 -b:v 0 -an output.webm

[poisondeathray]

That code does not generate an output file at all.

ffmpeg -r 30000/1001 -loop 1 -i input.bmp -vf scale=out_color_matrix=bt709 -pix_fmt yuv420p -frames:v 300 -c:v libvpx-vp9 -crf 18 -b:v 0 -an output.webm

It does for me

I hate to ask this but did you get your paths/ inputs correct ? Is your bmp called "input.bmp" ?

I put the files below, the input bmp is zipped up.

F:\_DOWNLOADS>ffmpeg -r 30000/1001 -loop 1 -i SMPTE_Color_Bars_16x9.svg.bmp -vf
scale=out_color_matrix=bt709 -pix_fmt yuv420p -frames:v 300 -c:v libvpx-vp9 -crf
18 -b:v 0 -an output.webm
ffmpeg version N-86482-gbc40674 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 7.1.0 (GCC)
configuration: --enable-gpl --enable-version3 --enable-cuda --enable-cuvid --e
nable-d3d11va --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --
enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-li
bfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug -
-enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enabl
e-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-li
bsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolam
e --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx
--enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable
-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-zlib
libavutil 55. 66.100 / 55. 66.100
libavcodec 57. 99.100 / 57. 99.100
libavformat 57. 73.100 / 57. 73.100
libavdevice 57. 7.100 / 57. 7.100
libavfilter 6. 92.100 / 6. 92.100
libswscale 4. 7.101 / 4. 7.101
libswresample 2. 8.100 / 2. 8.100
libpostproc 54. 6.100 / 54. 6.100
[bmp_pipe @ 0000000001d62cc0] Stream #0: not enough frames to estimate rate; con
sider increasing probesize
Input #0, bmp_pipe, from 'SMPTE_Color_Bars_16x9.svg.bmp':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: bmp, bgr24, 1920x1080, 25 tbr, 25 tbn, 25 tbc
Stream mapping:
Stream #0:0 -> #0:0 (bmp (native) -> vp9 (libvpx-vp9))
Press [q] to stop, [?] for help
[libvpx-vp9 @ 0000000001d648c0] v1.6.1
Output #0, webm, to 'output.webm':
Metadata:
encoder : Lavf57.73.100
Stream #0:0: Video: vp9 (libvpx-vp9), yuv420p, 1920x1080, q=-1--1, 29.97 fps
, 1k tbn, 29.97 tbc
Metadata:
encoder : Lavc57.99.100 libvpx-vp9
Side data:
cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
frame= 26 fps=0.0 q=0.0 size= 0kB time=00:00:00.03 bitrate= 102.1kbits/s
frame= 37 fps= 34 q=0.0 size= 0kB time=00:00:00.40 bitrate= 8.7kbits/s
frame= 45 fps= 27 q=0.0 size= 0kB time=00:00:00.66 bitrate= 5.2kbits/s
frame= 54 fps= 25 q=0.0 size= 0kB time=00:00:00.96 bitrate= 3.6kbits/s
frame= 63 fps= 23 q=0.0 size= 0kB time=00:00:01.26 bitrate= 2.7kbits/s
frame= 72 fps= 22 q=0.0 size= 0kB time=00:00:01.56 bitrate= 2.2kbits/s
frame= 81 fps= 21 q=0.0 size= 0kB time=00:00:01.87 bitrate= 1.9kbits/s
frame= 90 fps= 21 q=0.0 size= 0kB time=00:00:02.17 bitrate= 1.6kbits/s
frame= 99 fps= 20 q=0.0 size= 0kB time=00:00:02.47 bitrate= 1.4kbits/s
frame= 107 fps= 20 q=0.0 size= 0kB time=00:00:02.73 bitrate= 1.3kbits/s
frame= 115 fps= 19 q=0.0 size= 0kB time=00:00:03.00 bitrate= 1.2kbits/s
frame= 123 fps= 19 q=0.0 size= 0kB time=00:00:03.27 bitrate= 1.1kbits/s
frame= 132 fps= 19 q=0.0 size= 0kB time=00:00:03.57 bitrate= 1.0kbits/s
frame= 141 fps= 19 q=0.0 size= 0kB time=00:00:03.87 bitrate= 0.9kbits/s
frame= 150 fps= 19 q=0.0 size= 0kB time=00:00:04.17 bitrate= 0.8kbits/s
frame= 156 fps= 18 q=0.0 size= 8kB time=00:00:04.37 bitrate= 15.8kbits/s
frame= 166 fps= 18 q=0.0 size= 8kB time=00:00:04.70 bitrate= 14.7kbits/s
frame= 175 fps= 18 q=0.0 size= 8kB time=00:00:05.00 bitrate= 13.8kbits/s
frame= 184 fps= 18 q=0.0 size= 8kB time=00:00:05.30 bitrate= 13.1kbits/s
frame= 193 fps= 18 q=0.0 size= 8kB time=00:00:05.60 bitrate= 12.4kbits/s
frame= 202 fps= 18 q=0.0 size= 8kB time=00:00:05.90 bitrate= 11.7kbits/s
frame= 211 fps= 18 q=0.0 size= 8kB time=00:00:06.20 bitrate= 11.2kbits/s
frame= 219 fps= 18 q=0.0 size= 8kB time=00:00:06.47 bitrate= 10.7kbits/s
frame= 228 fps= 18 q=0.0 size= 8kB time=00:00:06.77 bitrate= 10.2kbits/s
frame= 236 fps= 18 q=0.0 size= 8kB time=00:00:07.04 bitrate= 9.8kbits/s
frame= 245 fps= 18 q=0.0 size= 8kB time=00:00:07.34 bitrate= 9.4kbits/s
frame= 254 fps= 17 q=0.0 size= 8kB time=00:00:07.64 bitrate= 9.1kbits/s
frame= 263 fps= 17 q=0.0 size= 8kB time=00:00:07.94 bitrate= 8.7kbits/s
frame= 272 fps= 17 q=0.0 size= 8kB time=00:00:08.24 bitrate= 8.4kbits/s
frame= 281 fps= 17 q=0.0 size= 16kB time=00:00:08.54 bitrate= 15.8kbits/s
frame= 288 fps= 17 q=0.0 size= 16kB time=00:00:08.77 bitrate= 15.4kbits/s
frame= 298 fps= 17 q=0.0 size= 16kB time=00:00:09.11 bitrate= 14.8kbits/s
frame= 300 fps= 16 q=0.0 Lsize= 21kB time=00:00:09.97 bitrate= 17.2kbits/
s speed=0.538x
video:19kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing ov
erhead: 12.232400%

[chris319]

did you get your paths/ inputs correct ?

Nit-picky details like that do help make it work

It encoded but the colors are still screwed up in Firefox. They're closer in Edge but are +/- 4 instead of +/- 2.

https://www.youtube.com/watch?v=rq8wEUXbkcI&feature=youtu.be

[poisondeathray]

did you get your paths/ inputs correct ?

Nit-picky details like that do help make it work

It encoded but the colors are still screwed up in Firefox. They're closer in Edge but are +/- 4 instead of +/- 2.

https://www.youtube.com/watch?v=rq8wEUXbkcI&feature=youtu.be

You can't judge anything by youtube, remember it re-encodes the file. You have to specify which version you are watching. VP9 isn't even up yet on your video. You're watching AVC . You can right click => stats for nerds in the youtube player to get info on what is being streamed

Open the file directly in firefox and it will look correct . File=>open file. That indicates VP9 is working correctly in the default HTML5 browser player

F:\_DOWNLOADS>youtube-dl -F https://www.youtube.com/watch?v=rq8wEUXbkcI
[youtube] rq8wEUXbkcI: Downloading webpage
[youtube] rq8wEUXbkcI: Downloading video info webpage
[youtube] rq8wEUXbkcI: Extracting video information
[youtube] rq8wEUXbkcI: Downloading MPD manifest
[youtube] rq8wEUXbkcI: Downloading MPD manifest
[info] Available formats for rq8wEUXbkcI:
format code  extension  resolution note
139          m4a        audio only DASH audio   56k , m4a_dash container, mp4a.4
0.5@ 48k (22050Hz)
140          m4a        audio only DASH audio  138k , m4a_dash container, mp4a.4
0.2@128k (44100Hz)
134          mp4        640x360    DASH video   19k , avc1.4d401e, 30fps, video
only
136          mp4        1280x720   DASH video   43k , avc1.4d401f, 30fps, video
only
160          mp4        256x144    DASH video  108k , avc1.4d400b, 30fps, video
only
133          mp4        426x240    DASH video  242k , avc1.4d400c, 30fps, video
only
135          mp4        854x480    DASH video 1155k , avc1.4d4014, 30fps, video
only
17           3gp        176x144    small , mp4v.20.3, mp4a.40.2@ 24k
36           3gp        320x180    small , mp4v.20.3, mp4a.40.2
18           mp4        640x360    medium , avc1.42001E, mp4a.40.2@ 96k
22           mp4        1280x720   hd720 , avc1.64001F, mp4a.40.2@192k (best)

[chris319]

You can't judge anything by youtube

YouTube is what the public watches That's the point of this exercise

The .mp4 file has accurate colors on YouTube using Edge. YouTube shouldn't be mucking up the colors that badly.

Opening the local webm file with Firefox, the colors are still screwed up. Same with VLC, whether hw acceleration is activated or not.

Opening the local webm file with Chrome, the colors are within tolerance.

I waited some time and the colors on YouTube are still messed up.

If you have an eyedropper/color checker you can check these colors yourself.

[poisondeathray]

You can't judge anything by youtube

YouTube is what the public watches That's the point of this exercise

The point is to find out what is going on and determine some facts based on observations . Why do some videos look fine on some setups but not others ? Most of the time chrome works fine. But firefox only sometimes. The answer right now seems to be VP9 (to be clear, that's the streamed version, not necessarily what you upload)

YT streamed VP9 versions look correct (now) in firefox. They didn't before maybe 6 months/ 1 year ago

The .mp4 file has accurate colors on YouTube using Edge. YouTube shouldn't be mucking up the colors that badly.

In that specific case where you upload VP9, it's not youtube's fault, it's firefox's fault with AVC playback . Remember your thread on the mozilla forum about AVC ? That's what it's all about

Opening the local webm file with Firefox, the colors are still screwed up.

Problem and discrepancy there. What version of firefox ?

Badly screwed up or the expected +/- 2 ?

Same with VLC, whether hw acceleration is activated or not.

Choice of renderer has an effect too . VLC is a terrible player. It plays many files but maybe with the wrong colors.

Opening the local webm file with Chrome, the colors are within tolerance.

Chrome always seems a few steps ahead. Even supports 10bit444 with VP9 . Should be perfect color no rounding errors, but I still get 1 off...

I waited some time and the colors on YouTube are still messed up.

Because VP9 version is still not up. And the AVC in firefox HTML5 issue still isn't fixed. You're still getting AVC

Recall back a few posts I was commenting on why some people get VP9 treatment, but other videos don't. Your video from March still doesn't. It still looks wrong in FF.

[poisondeathray]

There is more error in ffmpeg's RGB=>YUV conversion compared to avisynth (some values are 3 off with ffmpeg) . There is a slight hue shift when using the -vf scale out_color_matrix method. There are other ways to convert in YUV to YUV as a colormatrix operation too (eg. using zlib, or colormatrix filter) , but all RGB<=>YUV conversions in ffmpeg go though swscale. No other choice. Technically it will always be worse in ffmpeg because you undergo 2 conversions (RGB to YUV using Rec601 using swscale (no other option) , then YUV to YUV adjusting as if it had used Rec709) , compared to a 1 operation LUT

I attached screenshots as PNG of what I see in Firefox 54.0.1 , and the video files. These results correlate with other vpx spec compliant decoders, so the higher error is actually there in the ffmpeg RGB=>YUV converted encode. Everything else was the same (avs was fed to ffmpeg using same encoding settings). But at least VP9 looks correct now (not way off as in wrong matrix)

[chris319]

In that specific case where you upload VP9, it's not youtube's fault, it's firefox's fault with AVC playback .

Are you talking about H.264 or VP9? Please be more clear.

In terms of local files, Chrome gets vp9 right.

I can't open a local .mp4 file using Edge or IE on Windows 10. It wants to use VLC.

What version of firefox ?

Badly screwed up or the expected +/- 2 ?

Firefox updates automatically, so "the latest".

+/- 2 is not "badly screwed up". "Badly screwed up" is much worse than that.

Are you using a color picker/eyedropper or just eyeballing it? I'm not interested in eyeballing.

VP9 version is still not up.

It's been up for over an hour.

And the AVC in firefox HTML5 issue still isn't fixed. You're still getting AVC

I'm getting what I'm getting. I'm not going to wait for whatever to get fixed.

VP9 in Firefox (hint: green usually shows the most error).

Green patch:
R 16 -> 28
G 235 -> 208
B 16 -> 21

As I said earlier, if the video host, YouTube or whatever, is screwing with the colors there's not much we can do.

[poisondeathray]

In that specific case where you upload VP9, it's not youtube's fault, it's firefox's fault with AVC playback .

Are you talking about H.264 or VP9? Please be more clear.

You uploaded VP9, you're playing back AVC. Look at the available files. VP9 is not there. Look at stats for nerds. It will say AVC .

Does that make sense ?

Youtube re-encodes everything. You're not seeing the same version you uploaded. One reason why people get variation is they are watching different versions.

This is why details are important.

Chrome actually preferentiallly gets VP9 (when available) on YT . Some people prefer AVC (more people have HW accel) , and force AVC with various methods.

What version of firefox ?

Badly screwed up or the expected +/- 2 ?

Firefox updates automatically, so "the latest".

+/- 2 is not "badly screwed up". "Badly screwed up" is much worse than that.

Are you using a color picker/eyedropper or just eyeballing it? I'm not interested in eyeballing.

Color picker. When you use avspmod for avisynth, you can load several versions in several tabs and flip with number keys. Hovering over can give you readout in YUV and RGB values. Since you use keyboard shortcuts, the cursor is placed over same pixel in each version.

But if it's wrong matrix, most people don't have to use a color picker, it's way off.

VP9 version is still not up.

It's been up for over an hour.

It's been over 3 months for your other video uploaded in March and there still is no VP9...

I'm getting what I'm getting. I'm not going to wait for whatever to get fixed.

VP9 in Firefox (hint: green usually shows the most error).

Green patch:
R 16 -> 28
G 235 -> 208
B 16 -> 21

As I said earlier, if the video host, YouTube or whatever, is screwing with the colors there's not much we can do.

Is that VP9 locally in firefox ?
If locally, that is way different than what I'm getting. It's reported as fixed on the tracker.... It seems that way to me... but you're getting different results

There is a lot you can do. You can take control over the player and version streaming instead of taking what they give you and using default player. I don't just take what they give me. If you know one version is "wrong" and there is a "right" version do you take the wrong version ? I take control over color accuracy. I calibrate my display. I don't know about you, but I'd rather have correct colors. That why some people "force" certain versions or install mods or use custom players. Others do it because of acceleration only with some formats (less CPU usage)

The first part is identifying what is causing the problem. Details matter.

[chris319]

That's the file I encoded as webm just this morning and now YouTube says it's mp4.

Let's leave YouTube out of the equation and only look at local files. YouTube is too much of a wild card.

[poisondeathray]

That's the file I encoded as webm just this morning and now YouTube says it's mp4.

Let's leave YouTube out of the equation and only look at local files. YouTube is too much of a wild card.

But what happened to "YouTube is what the public watches" ...

Ok let's leave YT for now...




Open the file locally in FF, what colors to you see ? It should only be +/-2 (or 3 if using ffmpeg to do the RGB=>YUV conversion) compared to the RGB source. It should be same as chrome now. Not 20-30 off in a channel

[chris319]

But what happened to "YouTube is what the public watches" ...

I upload a webm file and it magically morphs into an mp4 file. So **** 'em.

Seriously, if YouTube is going to pull those shenanigans, it's probably a waste of our time chasing them.

I am at work now and will look later. As I recall, working with local webm files only, Chrome was the only one with acceptable colors. Firefox was messed up locally as well.

I need to get Microsoft Edge to open local files and not have it pass them off to VLC. I have a feeling Edge can't handle webm but it should handle mp4.

What OS are you using?

[poisondeathray]

But what happened to "YouTube is what the public watches" ...

I upload a webm file and it magically morphs into an mp4 file. So **** 'em.

Seriously, if YouTube is going to pull those shenanigans, it's probably a waste of our time chasing them.

But that has happened for years. Youtube always re-encodes . 10 years ago it "morphed" into a FLV using h263 compression. You never, ever, received the exact same file you uploaded. They are always re-encoded. Upload a MKV or TS and it "morphs" into a MP4 or Webm now. Even if you upload a MP4 and stream a MP4, it's a *different* MP4 than the one you uploaded .

I am at work now and will look later. As I recall, working with local webm files only, Chrome was the only one with acceptable colors. Firefox was messed up locally as well.

Chrome, I'm not worried about. Google is the one behind webm. They are a few generations ahead on that development

But can you double check on FF when you get a chance ? Because that would mean it's not fixed, at least on 1 computer. I can't reproduce the "bad" results on recent FF

When everyone can produce the same bug on different OS's, different versions, that adds a lot of weight to a bug report.

Details matter here, browser versions, specific os version, etc... if you're using default html5 configuration, or 3rd party addon player etc...

I need to get Microsoft Edge to open local files and not have it pass them off to VLC. I have a feeling Edge can't handle webm but it should handle mp4.

For IE or Edge, Neither WebM in VP8 or VP9 flavours are supported in default HTML5 configuration
https://html5test.com/compare/browser/ie-11.html
https://html5test.com/compare/browser/edge-15.html
https://en.wikipedia.org/wiki/HTML5_video#Browser_support

If you're having difficulty opening MP4, you can load it as a HTML5 page, provided the MP4 uses AVC (MP4 is just a container, if it held HEVC, it won't play, neither will chrome or FF without hacks or 3rd party players) . Also it might be some security settings preventing you from playing in-browser, try relaxing them

What OS are you using?

Mostly Windoze . Only linux on VM for testing

[chris319]

Chrome, I'm not worried about.

Maybe not for vp9, but it's still defaulting to 601 for h.264/mp4. I will double check this later.

But can you double check on FF when you get a chance ? Because that would mean it's not fixed, at least on 1 computer. I can't reproduce the "bad" results on recent FF

As I've said, they know they have a problem. Unless they fixed it over the weekend, it's not fixed yet. What I haven't said is that they're going to have a meeting on it this week. Sotaro Ikeda started to write code to address these color problems which he never finished and hasn't worked on for a long time. He needs to get the hardware acceleration to do bt.709.

I got emails from some Mozilla people last week.

We know that Chrome plays local webm files with correct colors.

Edge plays h264 from YouTube with correct colors. Is it possible that YouTube isn't resampling uploaded mp4 files?

If I upload a webm file to YouTube and a Windows user tries to view this webm video with Edge, it isn't going to play. That explains why YouTube resamples to mp4. The question is, are they resampling to the 601 color space?

I need to configure Windows 10 to play mp4 files locally.

[poisondeathray]

Chrome, I'm not worried about.

Maybe not for vp9, but it's still defaulting to 601 for h.264/mp4. I will double check this later.

Yes for 601 AVC in HTML5 player.

But can you double check on FF when you get a chance ? Because that would mean it's not fixed, at least on 1 computer. I can't reproduce the "bad" results on recent FF

As I've said, they know they have a problem. Unless they fixed it over the weekend, it's not fixed yet. What I haven't said is that they're going to have a meeting on it this week. Sotaro Ikeda started to write code to address these color problems which he never finished and hasn't worked on for a long time. He needs to get the hardware acceleration to do bt.709.

Seems fixed here. I only looked at the tracker briefly but there are commits that show it's fixed. I was surprised as hell (!)

HW acceleration does not work for firefox and webm, that's a long standing issue too. It might be that eventually HW accel breaks things - because it certainly did for flash. Everyone , the GPU, driver people, coders etc... have to be on the same page and work together

Edge plays h264 from YouTube with correct colors. Is it possible that YouTube isn't resampling uploaded mp4 files?

YT always re-encodes the version end user watches. You can download and check and the filesize will be different, metadata will be different. It's always been like that and probably always will be like that (bandwidth, compatibility reasons)

If you play h264 locally in IE it plays correctly too

If I upload a webm file to YouTube and a Windows user tries to view this webm video with Edge, it isn't going to play. That explains why YouTube resamples to mp4.

That could be one reason.

But YT re-encodes to webm too. It re-encodes dozens of different versions and resolutions, different types of audio too. Lots of developing countries have older HW and legacy OS's that aren't even on HTML5 yet . Still flash. That' s why all web masters that use video on their sites generally code a tiered system where you get webm, fallback on mp4. Mp4 can be streamed on HTML5 player on youtube, but there still is a YT flash player as well. You can force flash (still) with various methods and plugins . Flash means you always get the AVC version on YT.

People have various reasons for doing so. Just like people have various reasons for "wanting" VP9 version selectively. Proper color would be one of them, but VP9 gets on average 20-30% more bitrate than the AVC versions on YT . Many people think the quality is higher. (VP9 is supposed to be better at the same bitrate). Some people think there is a conspiracy to force AVC out, especially with the fees - there is probably some truth to that. AVC/MP4 is fast becoming the "legacy" format. IMO IE/Edge should get with the program and support VPx natively unless they want to become the next Netscape. FF has more market share than IE now (!)

The question is, are they resampling to the 601 color space?

Not if you upload YUV. On YT - the uploaded file is re-encoded for viewing. Always. End of story, no arguments. This is verified fact ever since day 1.

YUV is still YUV. YUV gets passed through as YUV (the one exception is if there is a full range flag, but then the output is clamped, it's still YUV). If you download the actual file that is streamed there is no evidence of other colorspace conversions. "601" only applies when there has been a YUV<=>RGB conversion, or if you 're applying a filter to emulate "as if" an alternate matrix was used (e.g. colormatrix in YUV) . Up to and directly after the YT re-encoding point there is no YUV<=>RGB conversion - so the idea of "601" is irrelevant. It's the next step(s) that are the problem - The conversion for RGB for display is a completely separate issue - because how and when that occurs is the basis for all these problems (e.g. If it occurs in HTML5 vs, specific player itself, vs. GPU , vs. renderer) .

I need to configure Windows 10 to play mp4 files locally.

I'm not on 10, but you should be able to do it with a HTML file (eg. make a simple HTML page embedding the video) . That's what you have to do for IE11 too, otherwise it spawns whatever default media player you have selected for that file type (it sounds like VLC for MP4 for you)

[poisondeathray]

https://bugzilla.mozilla.org/show_bug.cgi?id=1210357

VP9 colorspace BT.709 is not respected

"resolved fixed in firefox 52"
Status:
RESOLVED FIXED


If it's not fixed for you, it's important to investigate farther (details are important) . If there really is an issue then report it with the specific details.

[chris319]

We agreed we were going to leave YouTube out of the discussion.

VP9 colorspace BT.709 is not respected

"resolved fixed in firefox 52"
Status:
RESOLVED FIXED

As I said this morning, I was getting inaccurate colors on Firefox with WEBM. I'll check it again later. More accurately and more likely it's defaulting to 601. Maybe this bug isn't really fixed. I suspect they're not doing the quality control I am.

If you would get an eyedropper program you could check this yourself.

http://instant-eyedropper.com/

In Windows, DXVA2 sets the color space for hardware acceleration. They need to set it to default to 709.

[poisondeathray]

If you would get an eyedropper program you could check this yourself.

I don't think that eyedropper would give different values than avspmod's eyedropper ?

As I mentioned above I already checked it, colors are correct in FF within expectations (larger errors with ffmpeg conversion than avs). I posted the source , videos, screenshots. It's fixed here.

If you are still experiencing different results maybe you should file a bug report with relevant details

[chris319]

LOCAL Windows files: vp9 coded to bt.709

Chrome: colors accurate +/- 2

Opera: colors accurate +/- 2

Firefox: colors not accurate +/- 2 (+/- 9)

LOCAL Windows files: h.264 coded to bt.709

Chrome: colors accurate +/- 2

Firefox and Opera will not play due to corrupt(?) file output by ffmpeg.

[poisondeathray]

LOCAL Windows files: vp9 coded to bt.709

Chrome: colors accurate +/- 2

Opera: colors accurate +/- 2

Firefox: colors not accurate +/- 2 (+/- 9)

some bizarre result for firefox

+/- 9 ? You would expect larger deviation in some colors if it was 709/601 mismatch. Maybe you used non standard colors to test ? or Typo?

Did you try hw accel on/off? In FF for vp9 it's media.wmf.vp9.enabled => true/false

After you double check everything, if you get the same results, can you upload your bmp, vp9 encode, command line used

LOCAL Windows files: h.264 coded to bt.709

Chrome: colors accurate +/- 2

Firefox and Opera will not play due to corrupt(?) file output by ffmpeg.

Every html5 browser can play 8bit 4:2:0 AVC in Mp4 .

What does mediainfo (view=>text) say about the file ?

I suspect some error in making the file. Since chrome plays it as expected suggests it's not completely corrupt. Probably non standard (not 8bit 4:2:0 AVC)

Same here - if after you double check everything if you get the same results, can you upload your bmp, AVC encode, command line used