Posted: 3/16/2012 12:38 AM
Post subject: Youtube and chroma placement
Quote
natt
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Lossless h264 4:2:0 in mkv with chromaloc VUI flag. Other than differences in chromaloc flag, the actual video content is identical chromaloc 0 (mpeg2\mpeg4) Link to video chromaloc 1 (jpeg\mpeg1) Link to video What it "should" look like, more or less: Doesn't really matter to anything though. Chroma placement is so unreliable as it is. Edit: Did a similar test loading mp4 with the chromaloc positions into JWplayer, and it gave the same results (always JPEG/MPEG1, regardless of bitstream flag).
Posted: 3/16/2012 2:43 PM
Quote
Lex
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
So youtube ignores the chromaloc flag, preferring to align the chroma properly?
Posted: 3/16/2012 4:36 PM
Quote
natt
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Lex wrote:
So youtube ignores the chromaloc flag, preferring to align the chroma properly?
I agree that MPEG1 placement makes more sense than MPEG2 placement, but when so many other things assumes MPEG2 placement... it can be a problem.
Posted: 3/16/2012 4:37 PM
Quote
Lex
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
Things like what?
Posted: 3/16/2012 4:46 PM
Quote
natt
Editor, Emulator Coder, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Lex wrote:
Things like what?
Well, this would be getting more into downloadable primaries and _512kb, since our youtubes already "avoid" the issue by massively oversizing everything. If you scale 4:4:4->4:2:0 in avisynth without using chromainplacement parameter, you get MPEG2 chroma siting. If you then play that back in flash player as the _512kb, you get MPEG1 chroma siting, which means relative to how it should be, your chroma will be shifted half a pixel to the right. If you scale 4:4:4->4:2:0 with swscale, you get ??? To be honest I never really noticed it much. FWIW: vlc assumes MPEG1, mpc-hc with evr-cp assumes MPEG1, mpc-hc with madvr assumes MPEG2. Seems like no one is actually reading the bitstream flags.