Neverending battle: Youtube and MPEG4-AVC

[Kein]

Original video:
http://www.youtube.com/watch?v=PsQzjhQ2Mko

HTML5player - Chrome:
http://i.imgur.com/J1LZ2hG.png

Flash player - Opera/Firefox:
http://i.imgur.com/v3iKtrB.png
http://i.imgur.com/2bSGJAA.png

For some reason HTML5 player in Chrome displays it with TV range levels, which makes no sense, because I especially told the encoder to:

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.0
Format settings, CABAC : Yes
Format settings, ReFrames : 6 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1mn 16s
Bit rate : 12.1 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 60.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.097
Stream size : 110 MiB (98%)
Writing library : x264 core 116 r2074 2641b9e
Encoding settings : cabac=1 / ref=6 / deblock=1:0:0 / analyse=0x3:0x133 / me=hex / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=6 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=300 / keyint_min=30 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 1970-01-01 00:00:00
Tagged date : UTC 1970-01-01 00:00:00
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Color range : Full

This is some nonsense. What makes Chrome do that?

Now, what is really interesting is that if you take a look at this video:
http://www.youtube.com/watch?v=uDt-5mLafqk
(skip to 0:57 to find similar frame)

it looks good in Chrome! There is slight change in reds between HTML5 player and Flash Player, but the color range is correct and the details in dark preserved (opposite to if you do the range correction through some filters in Avidemux/Vdub). How did they pull out such magic trick?


But that's not all yet! Here is another absolutely weird thing: if you try to do the same comparison on CRT monitor - there will be NO difference. That's right, I did that before. There was only slight pushing green color, but just a bit, not even noticeable.


http://i.imgur.com/6ArqWWK.jpg


I always thought that AVC/H.264 in MP4 container was the best choice for YT. Guess it is time to look for something else but what :<

[vivan]

For some reason HTML5 player in Chrome displays it with TV range levels, which makes no sense, because I especially told the encoder to:TV? It's brighter so it's PC. Which is strange because youtube, flash and html5 players don't care about flags (that served video doesn't even have).

Actually served video is tv range (at least 720p mp4 version). This is how it supposed to look: TV (http://i.imgur.com/9KmrXP8.png). This is how it looks with forced PC range (http://i.imgur.com/MmS4PCO.png). This is how it looks with TV and BT.601 (http://i.imgur.com/rttkXqC.png) (of course it's retarded and should never happen, but that what fake opera (chrome based) does).

I always thought that AVC/H.264 in MP4 container was the best choice for YT. Guess it is time to look for something else but what :<The best choice is not trying to do anything smart. Most of the media players ignore all flags (at best), and both flash and html5 players are worse than any media player.

Use TV-range BT.709 and don't even try to estimate how bad youtube is - it's so bad that it's unhealthy.

[Kein]

Which is strange because youtube, flash and html5 players don't care about flags
I'd say youtube does not care about a lot of things, not just that.

Use TV-range BT.709 and don't even try to estimate how bad youtube is - it's so bad that it's unhealthy.

It is not that simple, unfortunately:
Original video: [193Mb, Dxtory YV12 (yuvj420p), full range, 1920x1080p @ 60FPS]
http://www21.zippyshare.com/v/NPBCpeBf/file.html
http://www.youtube.com/watch?v=ORDJ8kiWb60

Different uploads (see title of the video):
http://www.youtube.com/watch?v=HQu__Q1CBRQ
(no matrix specifications were selected, full range samples mentioned through encoder)

http://www.youtube.com/watch?v=wJ1iQiiRqYc
(same as above but this time I decided to do not specify "Full Range Samples" through encoder)

http://www.youtube.com/watch?v=aI5oPOMoFqU
(same as above but I used AviSynth filter for avidemux to specify matrix rec709 and color range change PC->TV)

http://www.youtube.com/watch?v=WbewmAWvhHA
(matrix, color primaries, transfer prim and full raneg sampel suggestions through encoder but no matrix specification through AviSynth filter and TV->PC range conversion)


Tested on:
Chrome 42.0.2311.50
Opera 12.17
Firefox 36.0


No dice. Closest good result in Chrome was with this one (http://www.youtube.com/watch?v=wJ1iQiiRqYc) but Flash version in Firefox/Opera looks horrible dark.

[Kein]

Okay, figured it out. Chrome seems to be at fault:
Proper colors on a screenshot: http://i.imgur.com/O9us5TU.png
Chrome with HW acc. ON: http://i.imgur.com/avcIGeS.png (tv range on a pc full range display)
Chrome with HW acc. OFF: http://i.imgur.com/DTNHJh3.png (bt.601 assumed)

[Kein]

kekity:
https://code.google.com/p/chromium/issues/detail?can=2&start=0&num=100&q=color%20youtube&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=&id=333619

if you follow the chain or use the search there are SHITLOADS of similar or the same issues reported, dating a year back. It is one of these problem that never will be fixed in "best web browser!"

What a joke.

[Anteys]

Noticed the same about the colours in Chrome looking washed out when I first started switching to HTML5-playback.

If you have an Nvidia card you can remedy the problem by going into the Nvidia Control Panel->Adjust video colour settings->With the Nvidia settings->Advanced->Dynamic Range: Full (0-255)->Apply.

Not sure about AMD since I haven't used one lately.

[vivan]

Google doesn't know anything about video. Hell, android has BT.601 harcoded - so every HD video on every device in every player (there're few exceptions that do color conversion on cpu, but they slow and also use nearest neighbor for chroma upsampling) is displayed wrong (and also with shifted chroma and huge amount of banding).

Anyway, this is how this video (original_small.avi) is supposed to look: madVR (http://i.imgur.com/CMBQCHK.jpg) (which supports all flags).
Downloaded video (from the first post) looks the same, so youtube encoded it properly (they did pc -> tv range conversion, so now it has TV range). So they do respect range flag (probably because they're using ffmpeg which does it for them). So browsers should display it properly unless broken, which is a real problem - because they're broken.

What they should do is to add support for external renderers. Using madVR in browser, what could be better? :)

[Kein]

Anyway, this is how this video (original_small.avi) is supposed to look: madVR (http://i.imgur.com/CMBQCHK.jpg) (which supports all flags).
That's correct.

Downloaded video (from the first post) looks the same, so youtube encoded it properly (they did pc -> tv range conversion, so now it has TV range). So they do respect range flag (probably because they're using ffmpeg which does it for them). So browsers should display it properly unless broken, which is a real problem - because they're broken.
The encoded into MPEG4-AVC video (mp4 container) was just like the original RAW video - full range. So I uploaded full range and specific flag for full range as well:
http://i.imgur.com/xl0v4Q6.png

However, that's AVC/H.264 720p video. Google Chrome uses different players and received VP9 encoded one through DASH. I have no idea how to dump properly such video.

[Anteys]

Jdownloader 2 can get .webm-files from Youtube, iirc they had to implement muxing from DASH (for both .mp4 and .webm) after downloading to get anything above 720p after Youtube changed their way of delivering content.

However it seems like it can't parse the 60 fps-.webm, only the 30 fps one even thought I have 720p/1080p 60 fps .webm ticked on to parse in my settings.
I think that's the case on all videos for now, since I only ever saw 60 fps files as .mp4 - so it might be an issue with the program currently.

[sneaker_ger]

However, that's AVC/H.264 720p video. Google Chrome uses different players and received VP9 encoded one through DASH. I have no idea how to dump properly such video.
http://rg3.github.io/youtube-dl/

[vivan]

Hm, yesterday it didn't list HD webm versions but now it does (and 60fps VP9 version was there for sure - I've seen it in fake opera).
http://i.imgur.com/D0LfMt3.jpg
Yeap, same as H.264 - it was encoded properly (BT.709 + TV range).

[Kein]

http://rg3.github.io/youtube-dl/

I said properly. There are bunch of way to dump it, but the question is how to get 100% consistent raw video that it serves. DASH is a complex bitch.

[sneaker_ger]

What errors did you find? I never experienced anything that would have led me to believe it does not work "properly".

[Kein]

How did you validate then the received sum of parts?

[sneaker_ger]

I don't but youtube-dl will tell you exactly how big the resulting file will be before you download. If you are paranoid you can do multiple downloads and compare them.

[Kein]

I'm not "paranoid" since there is no security risk involved. I know I can download MPEG4-AVC encoded mp4 file from YT's Video manager panel and it is as close to the streamed one (through flash) as it gets (which you can then compare to any MP4 snatched by SaveFrom, for example). There is no way to tell how correct the VP9 one received through 3rd party tools in the end. I'd be wary make any absolute statements since you can't back them up with anything weighty besides assumption.

[colours]

I'm not sure how you guys don't see a disconnect between recommending the BT.709 colour matrix when encoding for YouTube and the fact that VP8 and its successors explicitly mention only the BT.601 colour matrix.

In case everyone suddenly got amnesia, Google owns VP8/VP9/etc., so it shouldn't be any surprise if videos uploaded to YouTube get treated as BT.601 rather than BT.709.

I've tried to search for documentation regarding what colours to use for YouTube videos a few years back and got nothing, so the safest assumption is clearly to use TV-range BT.601, regardless of whether the video is HD. In lieu of any documentation stating otherwise, I'm not sure how anyone can decide that anything else is reasonable.

The situation was murkier in the past (before VP8 on YouTube was a thing), but it seems pretty clear-cut to me now.

[Kein]

But what the point to encode into TV range bt601 if YT does it anyway?

[vivan]

I'm not sure how you guys don't see a disconnect between recommending the BT.709 colour matrix when encoding for YouTube and the fact that VP8 and its successors explicitly mention only the BT.601 colour matrix.Mention? VP9 is so "open" that it doesn't even have a specification.
And there're mentions of BT709 in libvpx (https://github.com/webmproject/libvpx/search?q=709).

In case everyone suddenly got amnesia, Google owns VP8/VP9/etc., so it shouldn't be any surprise if videos uploaded to YouTube get treated as BT.601 rather than BT.709.No, they're treated in a "we don't know what we're doing way" - colormatrix tag is ignored, served video is not tagged, all resolutions use the same colormatrix (so either SD or HD will be broken for sure).

I've tried to search for documentation regarding what colours to use for YouTube videos a few years back and got nothing, so the safest assumption is clearly to use TV-range BT.601, regardless of whether the video is HD.Yeah, nice suggestion - lets break our video for the sake of one broken browser.

[TheSkiller]

Despite colours' reasonable arguments regarding Bt.601 on YouTube I cannot confirm this. If you upload any video (regardless of HD or SD) that uses 709 it will look correct upon playback in Flash. If you use 601 it will look wrong.

Maybe the following changed when YouTube started reading (some) flags but they used to never touch the colorimetry of the source file, so 709 always remained 709 and 601 remained 601 but the latter was/is displayed wrong.

[sneaker_ger]

The VP8 specs (http://datatracker.ietf.org/doc/rfc6386/?include_text=1) only know BT.601. As you say, it's hard to find anything like that for VP9. Google just does not seem to care enough.

[nevcairiel]

VP9 might support BT.709, however, YouTube doesn't tag colors in VP9, so if you want to test if your video looks good and you don't use 601, then make sure you don't use VP9.
So if you are encoding specifically for YouTube, you should keep this in mind, and not just put your head in the sand and say "YouTube is broken, its not my fault". Sure, it may be broken, but its also your fault for not uploading a video that will result in the desired outcome.

Blaming it on the browser is nice and easy, but what you are probably seeing is that Chrome is the only browser that actually gets VP9 served, and that will then look wrong.

[Kein]

nevcairiel
Go on, don't let me stop you here. Tell us the "proper way to upload on Youtube" since nor YT nor Chrome is clearly at no fault according to your opinion.

[vivan]

So if you are encoding specifically for YouTube, you should keep this in mind, and not just put your head in the sand and say "YouTube is broken, its not my fault". Sure, it may be broken, but its also your fault for not uploading a video that will result in the desired outcome.Chrome is not the only browser that could be used for Youtube.

There's no way to get desired outcome in all browsers (and on all devices).
Out of 2 options, supporting the one that is broken (and might get fixed) is worse, no?

[nevcairiel]

nevcairiel
Go on, don't let me stop you here. Tell us the "proper way to upload on Youtube" since nor YT nor Chrome is clearly at no fault according to your opinion.

From what I can see, Chrome seems to work fine. It may just look broken because its the one browser where YouTube serves VP9, which doesn't convey color information.
So start with comparing apples and apples, then decide which browser is behaving which way.

[vivan]

It may just look broken because its the one browser where YouTube serves VP9, which doesn't convey color information.neither do their H.264 encodes.
So, you're saying that all video renderers (that assume BT.709 for HD) and LAV filters (that does the same if forced to do RGB conversion) are broken and should add a special workaround for a format that doesn't even have a specification?

So start with comparing apples and apples, then decide which browser is behaving which way.He is comparing it to flash (see first post), that does it properly.

[nevcairiel]

He is comparing it to flash (see first post), that does it properly.

But flash is not decoding VP9.

[colours]

Mention? VP9 is so "open" that it doesn't even have a specification.
And there're mentions of BT709 in libvpx (https://github.com/webmproject/libvpx/search?q=709).

My bad; I was being lazy in my research and only checked VP8's spec. I'd assumed VP9 was the same in using only BT.601.

No, they're treated in a "we don't know what we're doing way" - colormatrix tag is ignored, served video is not tagged, all resolutions use the same colormatrix (so either SD or HD will be broken for sure).

Yeah, nice suggestion - lets break our video for the sake of one broken browser.

True, and I agree that YouTube should be doing something other than ignoring tagged colour matrices, but the very notion that using the BT.601 matrix for untagged HD video is "broken" is entirely unfounded. Just because using BT.709 for untagged HD videos is the de facto standard among most media players doesn't mean that it's wrong for a media player to choose an alternative standard. (For that matter, "HD" isn't even a well-defined threshold, if you want to be all anal about it.)

If multiple browsers differ in how exactly they display YouTube videos, it's obvious that Chrome's rendering should be treated as the reference, what with using a Google browser to watch a video encoded in a Google format on a Google website. Nothing else makes as much sense, and it's disingenuous of you to claim that Chrome is "broken" here. You'd only be correct (that HD should be BT.709 by default on YouTube) if there were documentation or specification stating so, and guess what, there isn't!

[vivan]

But flash is not decoding VP9.But flash is decoding and displaying H.264 that youtube also encoded from the same perfectly valid source.

Just because using BT.709 for untagged HD videos is the de facto standard among most media players doesn't mean that it's wrong for a media player to choose an alternative standard.Displaying wrong colors is wrong. If video is untagged you don't know what colors are right, but you can guess it with 99.9% probability. If you do the opposite - you'll get player that can't do what it supposed to do 99.9% of the time, which makes it useless and broken.

If multiple browsers differ in how exactly they display YouTube videos, it's obvious that Chrome's rendering should be treated as the reference, what with using a Google browser to watch a video encoded in a Google format on a Google website. Nothing else makes as much sense, and it's disingenuous of you to claim that Chrome is "broken" here. You'd only be correct (that HD should be BT.709 by default on YouTube) if there were documentation or specification stating so, and guess what, there isn't!OPs uploaded video is a perfectly valid and uses BT.709, as 99.9% of other videos. And it can't be displayed correctly in enviroment completely controlled by google. Something is broken - either their encoder or decoder/renderer.
If their youtube encoder is broken and supposed to do BT.709 -> BT.601 conversion - then you have millions of broken videos. Also they've screwed all other people that might've used their format (like 2 of them... or maybe 2.5).
And if their decoder/renderer is broken... fixing it it trivial. Do you honestly believe that if Chrome supported H.264 it will display it correctly? Look at Android as an example of another enviroment completely controlled by google.

Sure, in their small imaginary world they could do the hell they want. They could even invert video and say that this is how it's supposed to look. But if they want broad adaptation (or at least not being pain for those 2.5 other people that use it) they have to follow industry standarts instead of being "special".

UPD: I've checked FF, it does the same thing with VP9... and H.264 too (even when BT.709 is explicitly set. Vimeo, the only proper video streaming site, does it). Which proves that it's just equally broken.

[nevcairiel]

But flash is decoding and displaying H.264 that youtube also encoded from the same perfectly valid source.

But that doesn't tell you then if YouTube screws up VP9 encodes, or Chrome renders it wrong. Unless you handle the exact same file in both situations, the comparison is not going to give you clear information.

[vivan]

I've checked VP8 "specs (http://datatracker.ietf.org/doc/rfc6386/?include_text=1)". It mentions "601" onceThe color space type bit is encoded as follows:

o 0 - YUV color space similar to the YCrCb color space defined in
[ITU-R_BT.601]

o 1 - Reserved for future useDamn, it's just so... ugh. Is BT.709 similar?
So even VP8 specification doesn't give a clear answer.

[huhn]

The scope of the terms Y'UV, YUV, YCbCr, YPbPr, etc., is sometimes ambiguous and overlapping. Historically, the terms YUV and Y'UV were used for a specific analog encoding of color information in television systems, while YCbCr was used for digital encoding of color information suited for video and still-image compression and transmission such as MPEG and JPEG. Today, the term YUV is commonly used in the computer industry to describe file-formats that are encoded using YCbCr.
http://en.wikipedia.org/wiki/YUV

and i'm pretty sure you know that bt 601 is not the same as bt 709.

[vivan]

and i'm pretty sure you know that bt 601 is not the same as bt 709.I'm pretty sure that you know that "similar" and "same" have different meaning.

[huhn]

http://www.glennchan.info/articles/technical/rec709rec601/rec709rec601.html

some would say they are similar some wouldn't.

[vivan]

Exactly. So what the point of spec saying "similar" instead of doing what H.264 spec does (that clearly says that value 1 means BT.709 and 5/6 means BT.601, and then gives all numbers and formulas)?
The answer is: they don't care and they don't want to hold any responsibility for their own mistakes (e.g. since youtube doesn't perform any color conversions they use BT.709 for all SD videos, even VP8 ones, that were uploaded as HD).
Youtube doesn't follow VP8 spec, even their VP8 software doesn't follow VP8 spec (http://x264dev.multimedia.cx/archives/486#more-486).

Now we have VP9 that doesn't even have a spec and Google makes same mistakes. Do you believe that those mistakes define new standart? I don't.

[huhn]

in the end a VP8/9 encoder doesn't do a colorspace conversation. so the encoder is not at fault for the wrong color it is the renderer or a conversation filter before the encoder. HTML5 video renderer/player are pretty new and if they use bt 601 for everything than it's there fault. it's like VLC that uses this for years and maybe still doing this...

[Warperus]

I'm pretty sure that you know that "similar" and "same" have different meaning.
It might be not so "same" in primary colors, since BT.601 and BT.709 define different primary colors.