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).
+ Reply to Thread
Results 31 to 60 of 75
-
-
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. -
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.Last edited by poisondeathray; 30th Jul 2017 at 01:35.
-
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? -
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 -
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 HEVCLast edited by chris319; 30th Jul 2017 at 19:50.
-
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
Code:ffmpeg -i input.avs -c:v libvpx-vp9 -crf 18 -b:v 0 -an libvpx-vp9.webm
Code: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
Code:ImageSource("SMPTE_Color_Bars_16x9.svg.png") converttoyv12(matrix="rec709") assumefps(30000,1001) showframenumber() showtime() trim(0,300)
Another host
https://www.mediafire.com/?u6s81sbghxiu6aqLast edited by poisondeathray; 30th Jul 2017 at 20:17.
-
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.
Code: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)
Code: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%
-
did you get your paths/ inputs correct ?
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
Code: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)
-
You can't judge anything by youtube
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. -
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.
Opening the local webm file with Firefox, the colors are still screwed up.
Badly screwed up or the expected +/- 2 ?
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.
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. -
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) -
In that specific case where you upload VP9, it's not youtube's fault, it's firefox's fault with AVC playback .
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 ?
+/- 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.
And the AVC in firefox HTML5 issue still isn't fixed. You're still getting AVC
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. -
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 ?
+/- 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.
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.
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.
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. -
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 -
But what happened to "YouTube is what the public watches" ...
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? -
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.
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.
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? -
Chrome, I'm not worried about.
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
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. -
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
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?
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.
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?
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.Last edited by poisondeathray; 31st Jul 2017 at 21:27.
-
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. -
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
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. -
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 -
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.Last edited by chris319; 1st Aug 2017 at 04:39.
-
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
Similar Threads
-
Avisynth FFmpegSource2 wrong color space
By Veggav in forum EditingReplies: 3Last Post: 10th Apr 2016, 09:47 -
Media for DCP Color space xyz or res709
By singhasubhajit.i in forum EditingReplies: 4Last Post: 7th Mar 2016, 23:17 -
Video is not YV12... color space
By Mark22 in forum Video ConversionReplies: 3Last Post: 6th Mar 2015, 12:41 -
How to change the color space of output video in MPC-HC?
By Stears555 in forum Software PlayingReplies: 7Last Post: 16th Jul 2014, 07:56 -
mencoder -> ffmpeg -> color space mix-up
By Selur in forum Video ConversionReplies: 9Last Post: 12th Jul 2013, 11:23