x264 - Color Matrix settings

[zerowalker]

I have been wondering about what to use when it comes to these.

There are 3 that seem to interviene with one another.

Matrix, Transfer and Primaries.

I have no idea what to make of these, and i have tried searching and reading, but there doesn't seem to be any easy explanation of the settings i am interested in, which is,

Rec.601 and Rec.709.

Now as far as i can tell, bt.709 is Rec.709, but i have no idea if i am to pu it on all 3 settings for it to work or if expects something else.

As for Rec.601, i am guessing it's the bt470 from reading about it, that however seems a bit more complicated.

It seems PAL and NTSC has different matrixes when it comes to this, and x264 doesn't support both, didn't get the grasp of it all, but i guess someone here does.

So well, question is pretty much, explanation of these settings to help people to understand what to use, and such.

Many Thanks

[turbojet]

Work in what application?

--colormatrix alone is enough for madvr to detect beyond that so few things support it that I know of, much better to convert colorspace, if needed, while encoding.

bt470bg = PAL 601
smpte170m = NTSC 601

[foxyshadis]

Transfer characteristics is the gamma, essentially, although most standards aren't pure gamma ramps. You can use linear light this way and let the renderer apply your monitor gamma (if any could), although even at 10bit you're looking at a lot of banding at the low end. (And everything ignores it.)

Color primaries are the RGB points that define the gamut, which is mostly only useful if you have a calibrated monitor. (And all but Quicktime ignores it.)

The matrix is the basic conversion between RGB and YUV. This is the only one you need to care about. Since smpte170m=bt470bg=Rec.601 in H.264, it doesn't matter which one you use, the choice is only there if you want to differentiate between NTSC & PAL sources.

For some background info: bt470bg is PAL, bt470m/fcc is NTSC, smpte170m is really old NTSC, smpte240m is a pre-709 HD standard that is rarely if ever seen.

Now, the SD standards are weird as hell, with real color primaries of smpte170m actually being more common on DVD and broadcast than bt470m, so needing accurate colors is a pipe dream (especially for Never Twice the Same Color), but that should get you started.

Starting at page 252 of the h.264 spec (http://www.itu.int/rec/T-REC-H.264), you can find way more than you probably wanted to know.

[zerowalker]

So, if i understand things correctly.

Transfer = Gamma ramps, and should only be used if you know what your monitor uses (if the video source if from it?).
Primaries = the gamut, used for more precise colors, need a calibrated monitor (Will differ between monitors, making it only useful for your own?)

Matrix = The Color Matrix itself, bt470gb,fcc,bt470m = Rec.601, with just the names differing as an indication for what the source could be.
bt.709 = Rec.709, and smpte240m = not really useful except for the rare cases where it's used (already encoded sources?)

Now, the SD standards are weird as hell, with real color primaries of smpte170m actually being more common on DVD and broadcast than bt470m, so needing accurate colors is a pipe dream (especially for Never Twice the Same Color), but that should get you started.

Not really sure what you mean here.

You say that smpte170m is used more on DVD and broadcast than bt470m which is Rec.601.

i am guessing the other is a phrase in which you say "It's hard to get the accurate colors from DVD,Broadcasts cause of this, especially for NTSC (took a while till i understood the naming, any reason you call it that?).


Hope i got most if it correct, as you put it out quite nicely, and turbojet also wrote the same about those 2, except one of them was a "middleground.

[foxyshadis]

I just mean that you won't ever get "real" NTSC colors with H.264 approximations, which only matters for analog (television shows or VHS), and real NTSC has interactions between luminance and saturation, too. The further you go back, the less standardized it was, thus "Never Twice the Same Color." Real SD NTSC also uses SMPTE 170M color matrix but BT.470M color primaries. (Or vice versa, I forget now.) I got to know all about this when I used to do analog conversions.

You can ignore all of that unless you're on a quest to accurately recreate the experience of watching 20th century TV, and just use smpte170m or bt470bg for SD. It'll look decent.

If you encounter FCC or 240M on a DVD, which I've seen, it might be best to convert to 601 or 709 in AviSynth, since most renderers only understand those two.

[Asmodian]

Transfer and Primaries should not be set for your display, rather you can use them to specify what they are supposed to be. This info could then be used to display the video correctly on a particular display but nothing actually reads them so they are of limited value atm. They could be nice for Media Info users to differentiate between NTSC & PAL. I set them correctly just in case they can be used in the future, they use the same names as the matrix tag.

Matrix "should" be bt470m for most NTSC content but because of randomness and not caring NTSC content produces often use(d?) the "wrong" matrix for the RGB -> YUV, such as smpte170m. The comical naming is because of this; it is almost impossible to use the correct matrix for NTSC content because you don't know which one was used originally. PAL is similar but is more likely to have used the correct bt470bg.

edit: wow I am slow, foxyshadis beat me to it.

[zerowalker]

Ah, that does explain it, and well i myself live in a PAL country, but can't say that it's much better here, the analog era was robust yes, accurate no.

Currently i would say no, however i do sometime capture PAL videos, but in that time i will ask more about that kind of research, i am quite fanatic when it comes to accuracy,
though my experience are severely lacking, but you always learn something on your quest through the unknown;)


If i am not completely mistaken, doesn't DVD actually use flags for the matrixes?

and FCC, wasn't that Rec.601, like , bt470gb,bt470m and also smpte 170m?
I thought all were the same, except the PAL/NTSC difference (But that was only in naming sense, the colors are the same).

Hope i didn't completely twist things up know, quite a lot of names here, and all look pretty similar;S

[zerowalker]

I set them correctly just in case they can be used in the future, they use the same names as the matrix tag.

I am quite interested in this.
What are the correct ones, how can i know of them?

As i agree with you, better have the info if you can have it, making it future proof in a sense, then just ignore it.

It's one of those things that have made a mess out of videos in the past, as you both say, PAL and NTSC is a mess cause you don't know what is what.

[Asmodian]

I believe HD is always bt709. For everything else I think you need to know whoever did the mastering to be sure. :p

I use bt470m for NTSC and bt470bg for PAL. I probably should have put correctly in quotes.

[zerowalker]

Are you talking about Matrix now or Transfer/Primaries?

[Asmodian]

Transfer/Primaries

[zerowalker]

So, you use the same as Matrix for all 3 in HD, i am guessing you mean Bluray and such?

Also, i have been wondering, what is to be set if you record on your PC, like Game Capture?
Matrix is of course whatever you choose, and most likely it will be Rec.709.

Transfer and Primaries however, how can you determine that?

[cyberbeing]

BT.601 NTSC Primaries are usually expected to be SMPTE 170M (SMPTE-C). BT.470 M (NTSC 1953 primaries) is considered an obsolete specification, but you may find it randomly on older DVDs.

BT.601 Matrix is identical between BT.470 B/G (PAL) & SMPTE 170M (NTSC)

BT.601 Transfer curve is identical between BT.470 B/G (PAL), BT.470 M (NTSC), SMPTE 170M (NTSC), BT.709

I believe that the Blu-ray spec states that SD NTSC is expected to be SMPTE 170M for Primaries, Matrix, and Transfer.

[Asmodian]

Thanks
So I should use:
SMPTE 170M for all three - SD NTSC
BT.470bg for all three - SD PAL
BT.709 for all three - HD

Hmm looking at a few of my old DVD copies I actually used smpte170m. I think I followed this Wikipedia (http://en.wikipedia.org/wiki/RGB_color_space) page but remembered it wrong. :o

For games I would use resolution based, if < 720p use NTSC/PAL based on frame rate. > 720 use BT.709.

[zerowalker]

It seems fairly stable then, though really it's very complex as there isn't any concrete rule for all this.
But HD and SD in Videos seems to be fairly solved.

For games I would use resolution based, if < 720p use NTSC/PAL based on frame rate. > 720 use BT.709.
However for games, or rather "Screen Capture" to be correct, is something i really doubt use the "Resolution Based" conversion.

Your PC produces RGB, which means you yourself can choose what Matrix you want to use, this will most likely be Rec.709.

But, the Primaries and Transfer is another story, but i guess those are determined by your monitors color profile or something?

[Reino]

For games I would use resolution based, if < 720p use NTSC/PAL based on frame rate. > 720 use BT.709.Practise shows it's more like ≤576p: BT.601, >576p: BT.709.
You can see for your self:
FFVideoSource("FPS1(yuvj420p)_720p30_sample.avi",cache=false)

#Spline36Resize(1056,594).ColorMatrix(dest=0,clamp=0,inputFR=true) #PC.709->TV.709
Spline36Resize(1024,576).ColorMatrix(clamp=0,inputFR=true) #PC.709->TV.601

[foxyshadis]

Primaries are dependent on camera, film stock, processing, and grading... things are supposed to be graded on screens calibrated to a standard, which will display the exact same way on any other screen calibrated to the same standard. (Or calibrated to another standard and the proper conversion applied.) Transfer is similar. Given that consumer monitors are rarely calibrated, that's probably why only Quicktime even reads those fields.

If you're specifically speaking of video games, I bet some of the people who've examined those systems in great detail can probably identify the exact RGB->YIQ conversion going on in the chips, since I doubt it's 100% any standard. That's an interesting idea, though you can't actually do much about it without being able to include a full ICC profile. (Is this possible in, say, Matroska? That would be the closest to a perfect solution and eliminate all this matrix/primary/transfer nonsense.)

[Asmodian]

Practise shows it's more like ≤576p: BT.601, >576p: BT.709.

Good point, you have to allow for cropping after all.

[Warperus]

Your PC produces RGB, which means you yourself can choose what Matrix you want to use, this will most likely be Rec.709.Some screen capture software (e.g. bandicam) uses BT.601 color matrix regardless of settings.
Some use BT.709 color matrix (e.g. shadowplay).
Some can use windows vfw RGB->YUV filter that depends on your config.

the Primaries and Transfer is another story
Since origin is in sRGB, which defines them, primaries and transfer are set as BT.709 regardless of color matrix.

[zerowalker]

So, if the Matrix is BT.709, everything will be BT.709?

I however noticed that Open Broadcast Software seem to use:

Color primaries : BT.709
Transfer characteristics : sYCC
Matrix coefficients : BT.709

However that Transfer can't be found from what i can see.
Any thoughts on this, i am thinking of asking why they use it, i thought it may be correct until you wrote this.

[benwaggoner]

Color primaries are the RGB points that define the gamut, which is mostly only useful if you have a calibrated monitor. (And all but Quicktime ignores it.)
I happen to know that the PS3 also will use them, and I presume the PS4 as well.

Getting this stuff right is really important when doing adaptive streaming. Getting 709 v. 601 wrong isn't that bad when it's applied to a whole title. But if playback switches between those every time it crosses the SD/HD boundary, it is quite noticeable.

So, for example, a set of encodes that span sub-SD to 1080p, you'd want to use Rec. 709 input for all of them and flag all the streams as that. If a player assumes 601 for lower resolutions, Bad Things happen.

[benwaggoner]

Practise shows it's more like ≤576p: BT.601, >576p: BT.709.
And Silverlight uses 709 if width >1024 OR height >576, otherwise NTSC. Which I made up on the spot ~6 years ago. Sorry PAL.

I still can't believe I never got them to actually just use matrix values, but that feature got cut every release...

My thinking was to capture 1024x576 as square pixel PAL 16:9 as SD, and still capture 960x720 and 1280x544 as HD.

The only reason Smooth Streaming worked was because it wouldn't reevaluate the matrix after video playback got started, or else it would have had the stream switching issue. It just defaults to whatever the frame size of the first fragment played was.

[foxyshadis]

So, if the Matrix is BT.709, everything will be BT.709?

I however noticed that Open Broadcast Software seem to use:

Color primaries : BT.709
Transfer characteristics : sYCC
Matrix coefficients : BT.709

However that Transfer can't be found from what i can see.
Any thoughts on this, i am thinking of asking why they use it, i thought it may be correct until you wrote this.

That's the MP4 value, the H.264 value might be unspecified or might be 709 just to confuse everyone. MP4 also supports xvYCC and BT.1361.

sYCC is a standard sRGB colorspace that has absolutely nothing to do with BT.anything. It seems weird that they'd use the matrix from 709 but the gamma from sRGB, but you'll have to ask them why they did that.

[Warperus]

It seems weird that they'd use the matrix from 709 but the gamma from sRGBAs I see it, sRGB does not define matrix coefficients for this case, since it's not designed for RGB<->YUV conversions. You put matrix used in encoding phase to do proper reverse transformation.

So, if the Matrix is BT.709, everything will be BT.709?Strictly said, no.
H262 and H264 do not force you to use BT.709 in one value if you use it in another value. So, file with linear gamma, BT.709 matrix and BT.601 PAL color primaries is legal.

[zerowalker]

As I see it, sRGB does not define matrix coefficients for this case, since it's not designed for RGB<->YUV conversions. You put matrix used in encoding phase to do proper reverse transformation.

Strictly said, no.
H262 and H264 do not force you to use BT.709 in one value if you use it in another value. So, file with linear gamma, BT.709 matrix and BT.601 PAL color primaries is legal.

I think i wrote it a bit wrong there.
I simply meant, If the video is from sRGB, and the Matrix conversion was Rec.709, then all settlings would be BT.709.

I think you thought i meant it as a general rule (If matrix is Rec.709 everything is, which was not my intention).

[foxyshadis]

As I see it, sRGB does not define matrix coefficients for this case, since it's not designed for RGB<->YUV conversions. You put matrix used in encoding phase to do proper reverse transformation.

sYCC (an appendix to sRGB) defines both a matrix and transfer function, though.

[Warperus]

zerowalker
Yes, you are right.

foxyshadis
And since they can't be coded on stream level I think "does not define matrix coefficients for this case" is still valid.
Substitution for transfer function is common practice and as I remember it was directly mentioned in sRGB specification.

[huhn]

sYCC is a standard sRGB colorspace that has absolutely nothing to do with BT.anything. It seems weird that they'd use the matrix from 709 but the gamma from sRGB, but you'll have to ask them why they did that.

709 and srgb have the same gamut. so if the gamma from sYCC is sRGB gamma the result is sRGB. as far as i know it is not possible to set sRGB in x264. so well done?

[cyberbeing]

Not just gamut, BT.709 also has the same matrix flag as sYCC in h264. Only the sRGB/sYCC transfer curve of 'IEC 61966-2-1' is different from BT.709.

http://i.imgbox.com/Grg7Mz14.png

sRGB/sYCC:
x264 --colorprim bt709 --colormatrix bt709 --transfer iec61966-2-1

[huhn]

i can't follow you 100%.
but this means open broadcaster software doing it right. right?

[cyberbeing]

but this means open broadcaster software doing it right. right?
If the intention was sRGB/sYCC, then yes it does.

[foxyshadis]

Well, that makes sense then. The name IEC 61966-2-1 should have triggered in my head, thanks for clearing that up!