As
[1840] SGB Pokémon: Blue Version "Gotta Catch 'Em All!" by p4wn3r & Mukki in 3:20:46.17 was being published, it was noted that one of the candidate streaming encodes had noticeably different colour relative to the original input.
After some experimentation, I have reason to believe this is due to the use of the PC.601 colour conversion matrix in the most widely used AVISynth scripts we are using.
The following is the methodology I used to deduce this.
First, I created a simple (RGB) colour bars image using the following AVISynth one-liner, and used VirtualDub to capture one frame of the image:
ColorBars().Trim(0,60).PointResize(1920,1440)
(Note that I'm using the large resolution to ensure that when I upload these to YouTube for casual viewing that it processes them to the best of its ability.)
Here's the resulting file.
I then losslessly (qp/crf 0) encoded five test files using x264:
- One was using an mencoder chain using -sws 9 and -vf format=yv12,scale to create a raw yv12 input to x264.
- The remaining four were done using the following AVISynth script as an input, with only the colourspace settings changing:
ColorBars().Trim(0,60).PointResize(1920,1440)
ConvertToYV24(chromaresample="point",matrix="xxx")
ConvertToYV12(chromaresample="point",matrix="xxx")
The four respectively used Rec601 (AVISynth's default), PC.601 (what we currently use), Rec709, and PC.709 as settings. In the latter two cases, I also specified --colorprim bt709 --transfer bt709 --colormatrix bt709 to x264.
The results are
here, or you can see them uploaded to YouTube:
At a glance, it seems that YouTube (and the media players I'm using) are expecting Rec601 input for colour to be displayed properly. One of the best points of comparison that I can see is the set of three grey bars below the large red bar - the contrast is much more visible using Rec vs. PC. (The mencoder chain I'm using also seems to be outputting rec.264.)
As such, I think the setting should be changed to get videos to display with colours as close as possible to the original input.
(I should note that the header settings I passed to x264 appeared to have no effect on en-/decoding in the case of 709; neither does specifying --fullrange, as far as I can tell.)
EDIT: Apparently, after further processing at this resolution, Rec709 turns out to appear correct for YouTube purposes. It would probably be best that Rec709 be used for YouTube large resolution encodes, Rec601 used for downloadable encodes (until we can test for greater player compatibility), and PC.601 for 512s.
