Incorrect color range

[Snowknight26]

I noticed a couple of years ago that x264 seemed to be converting color ranges incorrectly.

Using a Fraps sample (YV12, full range) from this zip (http://stfcc.org/misc/x264%20range%20test.zip), I ran a few conversion tests with x264, only changing input and output color ranges between tests. The following screenshots were taken with MPC-HC.

original.avi
http://stfcc.org/pics/i/5fb562a02831375243475b34851afbe6_th.jpg (http://stfcc.org/pics/i/5fb562a02831375243475b34851afbe6.png)

input range=pc, output range=pc
http://stfcc.org/pics/i/7638d69bf21b48c5c78372c2e3b34add_th.jpg (http://stfcc.org/pics/i/7638d69bf21b48c5c78372c2e3b34add.png)

input range=pc, output range=tv
http://stfcc.org/pics/i/614ff8c65c3abda5b7a0357eeb40cc6c_th.jpg (http://stfcc.org/pics/i/614ff8c65c3abda5b7a0357eeb40cc6c.png)

input range=tv, output range=pc
http://stfcc.org/pics/i/21d0a5c84925632123afc4b256cec53a_th.jpg (http://stfcc.org/pics/i/21d0a5c84925632123afc4b256cec53a.png)

input range=tv, output range=tv
http://stfcc.org/pics/i/5c549f6c5ccd5b9ff2286744abb59021_th.jpg (http://stfcc.org/pics/i/5c549f6c5ccd5b9ff2286744abb59021.png)

ffmpeg detects the pixel format of original.avi as yuvj420p and it can correctly convert it to Huffyuv without the problematic color range, so libavformat can be ruled out.

At first I thought it was because video_full_range_flag wasn't set, but both video_signal_type_present_flag and video_full_range_flag were set to 1 in the output H.264 streams' SPS headers when specifying '--range pc.'

It's clear that only the 2nd encoded sample has the correct color levels, but shouldn't only the first one (and last?), seeing as the input's color range is 0-255 and I'm specifying 0-255 as the output?

Because of all this, a few browsers render the samples with the wrong color ranges. In them, the first and last sample are displayed correctly, the 2nd's levels are washed out and the 3rd's are too dark. The depressing part is that that doesn't match how players such as MPC-HC display the samples. So what on earth is going on?

[Dark Shikari]

Are you sure that your player is handling PC range correctly? Given that input=pc/output=pc input=tv/output=tv look identical, I'm guessing it's not honoring the PC range flag.

[Snowknight26]

Are you sure that your player is handling PC range correctly? Given that input=pc/output=pc input=tv/output=tv look identical, I'm guessing it's not honoring the PC range flag.

Even Elecard StreamEye displays it that way.

[vivan]

Even Elecard StreamEye displays it that way.Then it doesn't support fullrange too.

madVR + LAV decoder:
original.avi: http://5.firepic.org/5/images/2013-06/13/69fldfsxtr9n.png
in=pc,out=pc.mp4 (fine, as expected): http://5.firepic.org/5/images/2013-06/13/xu9sh4rfzgz5.png
in=pc,out=tv.mp4 (fine, as expected): http://5.firepic.org/5/images/2013-06/13/98ortcejsyps.png
in=tv,out=pc.mp4 (wrong, as expected): http://5.firepic.org/5/images/2013-06/13/fd1b9z4g0uwo.png
in=tv,out=tv.mp4 (wrong, as expected): http://5.firepic.org/5/images/2013-06/13/t5cwkwcj1l8t.png

[Snowknight26]

You're right. madVR doesn't have any issues. I really hope this isn't yet another AMD driver issue.

[Warperus]

Fraps codec supports only sRGB output naturally as vfw codec. That is, it only supports full range RGB output.
Default h.264 output is YUV 4:2:0 BT.709 tv range.
So, input range=pc, output range=tv is proper option for encoding. Unfortunately, it might produce not exact output anyway. Take a look at this thread, please: http://forum.doom9.org/showpost.php?p=1632128&postcount=3

As far as I know, attempts to load fraps file as raw YUV through ffmpeg/ffdshow can twist colors. Using avisource is safe, but you have to have fraps installed and its natural codec being used. Handbrake is supposed to be ok for fraps YUV mode, but people say it twists colors for fraps in lossless RGB mode. I witnessed some artifacts in handbrake-processed fraps footages.

The proper way to encode fraps footage I use sometimes (rarely, to be honest, as rendering into .mp4 (h264 video stream) file directly in NLE is quite enough for uploading to youtube) is to write avisynth script with avisource and conversion into YV12 with BT.709 matrix.

[Snowknight26]

That's not true. The sample in the zip file was recorded using Fraps' 'non-lossless' mode, which captures video as YUV 4:2:0. Lossless mode captures video as 24-bit BGR. Regardless of which mode you choose both are full range.

As vivian showed, 'input range=pc, output range=pc' and 'input range=pc, output range=tv' should both display correctly (albeit the latter will have less information because the color range has been compressed). I just have to figure out why my drivers are broken, causing applications to ouput with whichever color range the moon is currently aligned to.

As far as proper color space goes, that's not something I'm concerned about.

[Snowknight26]

Only old video renderer and madVR seem to display the first two encoded samples correctly. The first sample is too dark on all other renderers. Would that mean that my GPU drivers are set to the wrong color range?

Strangely, if I set my GPU drivers to output 0-255, the first sample is too dark in most renderers, but if I do 16-235, the 2nd sample is too bright. Sounds like a driver bug?

Might be more appropriate to move this to a different section of the forums.. now that I've ruled x264 out.

[SeeMoreDigital]

Snowknight26,

Your topic reminds me of this x264 rgb vs i444 - What's the difference? (http://forum.doom9.org/showthread.php?t=168027) topic...