x264 change colorimetry based on output resolution

[turbojet]

Would it make sense for x264 to automatically adjust, if need, color to bt.601 limited range when the output width is <= 720 and bt.709 full range when width is >720?

I don't mean just --colormatrix --colorprim, etc. but also physical colorimetry like colormatrix.dll does. Tags are only useful with madvr as far as I know, not sure about hardware players. An override would be needed but it would make for more accurate encodings users who don't know or want to mess with settings.

[J_Darnley]

Well, if we're going to talk about accurate colour matrix flags, we should forcibly set 601 whenever x264 converts RGB->YUV. As for forcing a change of colour matrix, I'm not in favour of doing that. Anyway, you'd need a port of ColorMatrix() first. Lastly, Since when is HD full range? The colour matrix is independent from the range of values and 709 can be just as limited as 601.

[turbojet]

Would colormatrix from libavfilters be more appropriate?
You are right about range it shouldn't be adjusted at all. According to SD/HD video standards there's a huge gray area between 721-1279 pixels wide where's the dividing line? Not sure if those should be touched at least until all video renderers are tested thoroughly to find the dividing line, which could be a huge task that I would take up if there was a reason to. I'm under the assumption few upscale SD while many more downscale HD to something less than 1280 pixels wide. The problem is currently all HD->SD encodes with --colormatrix bt709 display wrong colors in every software player that's not using madvr and that's something that could be avoided.

[hello_hello]

Over 1024 seems to be a good width to move from bt.601 to bt.709. That's what ffdshow does when converting to RGB. That way anything over PAL 16:9 DVD "display width" uses bt.709. ffdshow will also use bt.709 if the height is greater than 600, so it probably gets it right 99% of the time.
Mind you is there much video which uses a width between 1280 and 720? Aside from DVD encodes which are resized "up" while encoding and would always be bt.601, usually it's either 1280 or 720.

I do know the WM9 renderer uses an odd formula which causes it to get it wrong sometimes. I can't remember the width it uses off the top of my head but I think the height needs to be greater than around 670 for it to use bt.709 (regardless of width). As a result all those 1280x544 720p encodes display using the wrong colorimetry. I haven't checked to see what other renderers do.

You're right about all those 480p encodes taken from HD sources displaying incorrectly despite the bt.709 --colormatrix, but to my way of thinking that's only to be expected and therefore it's the wrong way to do it, and even if it worked correctly in most players, it still leaves the equivalent Xvid encode displaying incorrectly. My way around it is to use the bt.601 -> bt.709 shader in MPC-HC. It gets those SD encodes displaying correctly, and even those 1280x544 encodes if you're using the WM9 renderer. Only catch is you need to remember to enable it or disable it manually.

Alternatively you could use ffdshow to decode and convert to RGB. According to it's tooltip it'll obey the colorimetry in h264 streams, but I've not tested it myself.

[turbojet]

There's all sorts of ways to fix it if you know the source in some software players. But what if you don't know the source or using a software that doesn't allow for changing matrix or using external filters or a hardware player. Could avoid all this with a proper encode. Also while minor, the correct colormatrix does seem to reduce crf file size by a little.

According to http://avisynth.org/mediawiki/Colorimetry VMR7/9 switches at 720 height, which may have made more sense when it was decided for fullscreen cropped 720p then it does now.

Petrakeas2 tested --colormatrix on some software players the results weren't very positive: http://forum.doom9.org/showthread.php?t=164378