Correct color coefficients (601 v 709)

[madhatter300871]

Hi all

I hope this is the correct place for this thread.

The avisynth wiki page for the ColorMatrix filter states the following :-

.....This filter recalculates the YUV values (using the default mode = "Rec.709->Rec.601") assuming the coefficients which are used by AviSynth/VDub/DivX/XviD, with the consequence that your final encoding (MPEG-2 or MPEG-4) is displayed correctly......

I think I may have been missing the point on color coefficients Rec.601 and Rec.709 so I would like to ask some simple questions :-

1. Does Xvid/DivX/VDub/Avisynth only ever process/encode using Rec.601 coefficients (regardless of resolution). ?

2. If yes, does this mean that both an SD and an HD Xvid encode will always be using Rec.601 coefficients ?

3. If yes again, does this mean that when playing back an HD Xvid encode it is quite likely that Rec.601 coefficients will be used when the renderer (or whatever) converts to RGB for the final output to the screen ?

So far I have been doing this.

A. If my source is HD I am presuming that its YUV data is stored using Rec.709 coefficients.
B. If my source is SD I am presuming that its YUV data is stored using Rec.601 coefficients.
C. When I re-encode I have been using "ColorMatrix(mode="Rec.709->Rec.601")" when converting HD to SD.
D. I am presuming anything of 719 or less vertical resolution is classed as SD and therefore has YUV data stored using Rec.601 coefficients (although I have recently learned that another forum member thinks for Windows based PC playback this is 674 vertical lines whilst another thinks this is 577 vertical lines, so I am willing to be swayed either way but you get my point.)

And so to the final point I suppose, and where I now have new confusion :-

1. When working with HD resolution video (lets say 720p and above for the sake of argument) should I always use colormatrix to change coefficients to Rec.601 if I am encoding with Xvid/Divx, even if I am encoding to HD resolutions ?

2. Or is it the case that you should always be aware of what coefficients are used in the source and what is required for the final encode, and if in doubt just assume 709 for HD and 601 for SD (both in the source and the final encode).

I have only done the conversion from 709 to 601 when my final encode is going to be of SD resolution, have I been wrong all this time ?

I know it is subjective and there will never be one definite rule to follow because there are so many factors involved and so many places where colour can get screwed. BUT ... what do you guys use as a rule of thumb that most of the time gives you predictable results regarding colour reproduction ?

Thanks for any help offered.

[Mr VacBob]

When using ASP the color coefficients will be ignored by everything except the video renderer, which does the YUV->RGB conversion. The only variable you have to worry about for coefficient choice is the video resolution.

x264 lets you store colormatrix tags, but ASP encoders don't.

[madhatter300871]

But surely when I am converting my video, the decoder will use either Rec.601 or Rec.709 coefficients when decoding the colour information of the source and so I think my question remains ...

1. Does Xvid (for example) expect Rec.601 colour coefficients and therefore I must convert from 709 to 601 when re-encoding a HD source to Xvid regardless of the final resolution ?

[poisondeathray]

But surely when I am converting my video, the decoder will use either Rec.601 or Rec.709 coefficients when decoding the colour information of the source and so I think my question remains ...

1. Does Xvid (for example) expect Rec.601 colour coefficients and therefore I must convert from 709 to 601 when re-encoding a HD source to Xvid regardless of the final resolution ?

No, xvid doesn't "expect" anything

The matrices only are used for Y'CbCr<=>RGB conversions

When you encode to xvid (properly*), you are passing Y'CbCr=>Y'CbCr

ie. no color space conversion is occurring

So, as Mr VacBob says, the only variable you have to worry about for coefficient choice is video resolution



* I say "properly" because some software might do an RGB intermediate conversion

[madhatter300871]

Hi

OK, understood. So colour coefficients only come into play when doing a YUV-RGB conversion. Final rendering does this, and video editors may also do this if they do any intermediate converting.

I read a lot online about xvid/divx etc. "expecting" Rec.601 video, I always struggled to understand this so thanks for both of you just giving the blunt answer of "no it doesn't".

OK, so ...

I have been trying out overlay, VMR and Haali renderer. They definitely produce subtly different results but I'm not quite sure what's going on.

1. Can any one shed any light onto which renderers define which resolutions as HD and SD (and use Rec.601/Rec.709 accordingly) and which ones convert 16-235 levels to 0-255 levels (if any).

2. Is bluray video encoded at source with 16-235 levels, or as I have read in a few places 0-255. I am thinking its 16-235 but would like clarification.

Thanks.

[poisondeathray]

I have been trying out overlay, VMR and Haali renderer. They definitely produce subtly different results but I'm not quite sure what's going on.


Yes, all the renderers seem produce different results

"overlay" would depend on your graphics card settings (most have 2 sets of settings, one for desktop, one for graphics overlay)



1. Can any one shed any light onto which renderers define which resolutions as HD and SD (and use Rec.601/Rec.709 accordingly) and which ones convert 16-235 levels to 0-255 levels (if any).


Not sure about each renderer, but both Rec601/709 stipulate a conversion from Y' 16-235 to RGB 0,0,0 - 255,255,255



2. Is bluray video encoded at source with 16-235 levels, or as I have read in a few places 0-255. I am thinking its 16-235 but would like clarification.


Y' is defined from 0-255. Both blu-ray and DVD use Y' 0-255, but "legal range" is Y' 16-235. Those values <16 and >235 are for undershoot and overshoot. That is, most of the content should lie within "legal range" but small excursions are perfectly acceptable.

Many retail blu-ray or DVD have small excursions, you can see this for yourself when looking at waveform monitor

[madhatter300871]

Thanks again.

So, it is a good general rule to accept the following (understanding, off course, that there are always exceptions) :-

1. SD video is authored using Rec.601, 16-235.
2. HD video is authored using Rec.709, 16-235.
3. An encoder has no "awareness" of Rec.601/Rec.709, it just encodes what its given.
4. An encoder has no "awareness" of 0-255/16-235, it just encodes what its given.
5. The renderer makes a conversion from YUV to RGB for display.
6. The renderer maps 16-235 levels to 0-255 levels for display.
7. The decoder can also do the conversions if desired, ffdshow for example, but the user should be aware what renderers work with what inputs.
7. ASP codecs do not have the capability to store colour matrix tags.
8. X264 does have the capability to store colour matrix tags. **
9. The decoder / renderer may or may not pay any attention to the colour matrix tags if they are present.
10. The renderer will use either Rec.601 or Rec.709 coefficients when converting to RGB based on the vertical resolution of the video.
11. The cut off point for SD/HD is debatable, but the general consensus seems to be 720 and above for HD, 719 and below for SD. (Other users have done a lot of experimentation and one should perform his own tests with his own system and combination of decoder/renderer for a definitive answer).

Thanks.

** I know X264 is an AVC codec and this area is for ASP codecs, I mention it only for understanding.

[hello_hello]

It's probably semantics, but technically anything with a higher resolution than standard definition is considered to be high definition. To quote Wikipedia:
http://en.wikipedia.org/wiki/High-definition_video
"High-definition video or HD video refers to any video system of higher resolution than standard-definition (SD) video, and most commonly involves display resolutions of 1,280×720 pixels (720p) or 1,920×1,080 pixels (1080i/1080p)."

So in NTSC-land I guess anything with more than 480 vertical lines is technically high definition. It's really just the HD "standards" which jump from standard definition's 480p, to 720p and 1080p.

Where a playback device switches colorimetry is a different story. It'll probably switch somewhere between 480 and 720 vertical lines, but it's probably also not solely dependant on vertical resolution.

ffdshow for example, when converting to RGB, uses R.709 if the horizontal resolution is greater than 1024 OR the vertical resolution is greater than 599. So it could actually use R.709 if the video has less than 480 vertical lines, but in reality that's probably not too likely.
I'm still convinced the WMR9 renderer uses R.709 if the width is 1200 or more AND the height is 578 or more. I don't know for sure if the other Windows renderers do it differently and I have no idea what would be standard for a standalone device, if they do tend to conform to some sort of standard.

Personally, I think I'd be perfectly happy if renderers chose colorimetry based solely on width. If R.709 was used for any video with a width greater than that of a DVD (which is basically how ffdshow does it) I don't think I'd mind at all.

[madhatter300871]

Yes, I would be happy with that as well. Anything over 1024 would be fine by me. To be honest, I really wouldn't care too much how the decision was made, as long as it was well documented and adhered to, you know !

I myself will be using Rec.709 for encodes of anything that is greater than 1024 in width (regardless of height) and will just have to be aware of this during playback.

[pandy]

some HD stream are 960x1080 (half Y resolution) - maybe better is use that SD is everything up to 720x576 and ED+HD are everything over 720x576 - also calculating number of pixels in 1 sec can help to create border between SD and HD (ED) ie X*Y*fps - ie anything that have more than 10368000 pixels in 1 sec is HD(ED) and probably it is BT.709

[madhatter300871]

Hi Pandy

Yes, there are many different resolutions that are strictly speaking HD, and encoded with Rec.709. Problem is there doesn't seem to be a definitive list of what's what.

I do like your idea of pixels per second, could be a good idea.

We are off course still guessing though aren't we.

[Ghitulescu]

Yes, there are many different resolutions that are strictly speaking HD, and encoded with Rec.709. Problem is there doesn't seem to be a definitive list of what's what.

What is an industrial standard has no issues at all with the colorimetry. Each SMPTE standard for video also has a chapter describing the colorimetry. The same goes for EBU, for EIJ, for AES, for ECMA, and so on.

If you're talking about the so-called HDTV/BRrip files flooding the internet, well, I agree, there's a problem, but this is not allowed to be discussed here, other than for learning purposes. I mean here: a BRrip of 1280x544 is a perfect example of how not to do a transcode. It is what EBU considers still to be SDTV.

Bottom line: if one is in the "transcoding business", then s/he must know what s/he's doing.

[hello_hello]

If you're talking about the so-called HDTV/BRrip files flooding the internet, well, I agree, there's a problem, but this is not allowed to be discussed here, other than for learning purposes.

No, we're not talking about the so-called HDTV/BRrip files flooding the internet, we're talking about encodes we make ourselves.

I mean here: a BRrip of 1280x544 is a perfect example of how not to do a transcode. It is what EBU considers still to be SDTV.

Rubbish. What the EBU considers is largely irrelevant as long as the encode is played back correctly. Take a survey here and ask all the other forum members whether they crop the black bars when encoding and see how many people you can find who don't.
What if we're encoding for playback on a portable device? Should we encode to an "industry standard" for playback on a device with a resolution that's 640 pixels wide? Copy protection is an industry standard, should we all apply copy protection to our encodes too?
We're not all handcuffed to a particular industry standard, we encode in ways which are practical, and as was pointed out by myself in a similar thread, it's fairly easy to use ffdshow to resize an encode back to an "industry standard" on playback (effectively just having it restore the black bars) ensuring the correct colorimetry. You've offered no logical reason for not saving bits when encoding by cropping the black bars.

Bottom line: if one is in the "transcoding business", then s/he must know what s/he's doing.

Given the point of threads such as these is for posters to learn what they're doing your comment seems rather superfluous. It is of course important to know what you're doing when encoding, but it's just as important to know what your playback device will do. Hence threads such as these.
Are you a champion for "industry standard" encodes because you know your playback device will play 1280x544 encodes using incorrect colorimetry, or is it simply because you have no idea which colorimetry it'd use?

[Ghitulescu]

My point was that the industrial standards have a clear description, unless the politics mix in (the BD case). There is a professional jargon that is used there - words like may shall mandatory have sometimes a different meaning than in the current life. Refining the general to the particular issue of colorimetry, all SMPTE standards I've seen (some 200) contain a chapter describing the colorimetry, directly or by reference to a colorimetry standard.

There's only one reason for doing reencodes for PC: a boring life. There's no reason to spend $/€/£ on electricity to save storage space half worthing that money (unless one doesn't pay for electricity). There's no reason to "improve" animes, I own both NTSC and PAL original DVDs, they are far superior to what is described, when played on TV using an average or better player; they look bad on PC, indeed. Also I see no reason to downconvert Blu-ray movies, why?, to get reupscaled back on TV? Come on.

So, the utility of this thread is to assure what colorimetry is used in whatever device?
First, there should be a developer that would explain what colorimetry s/he programmed in the codec/encoder, both for playing/decoding and encoding. This goes only so far as freeware is involved.
Secondly, a HW developer should also explain the same. I very doubt s/he will ever have the permission to explain this, providing s/he knows the internal transformations inside the chip (also confidential).
So much for this utility.

PS: there's no 1280x544 standard, so I don't care about. Let the one who produced it care about this. It will give him/her the illusion of doing something useful in his/her life, the quest for the holy grail of colorimetry.
As for 720p, there is a given and definite colorimetry, I've said it earlier this year.

PS2: encoding for a different device, like the iPad, would make more sense. However, the colorimetry information, unless publicly disclosed, remains unknown.

[kypec]

There's only one reason for doing reencodes for PC: a boring life. There's no reason to spend $/€/£ on electricity to save storage space half worthing that money (unless one doesn't pay for electricity). There's no reason to "improve" animes, I own both NTSC and PAL original DVDs, they are far superior to what is described, when played on TV using an average or better player; they look bad on PC, indeed. Also I see no reason to downconvert Blu-ray movies, why?, to get reupscaled back on TV? Come on.

I'd say there's no reason for you to reply in this thread ever again if that's all you can offer as helpful comments to us = fellow and passionate encoders using this forum for rather constructive discussions.

[Ghitulescu]

It's always interesting to see how people take statements out of their context.

I said that is known what colorimetry a standardised video has (a consumer has legal access only to standardised videos). It's no need to guess or to make assumptions.
It should also be clear enough what colorimetry an encoded video has, provided one did this himself.
What else can be more constructive than this?

Out of the context - replies to off-topic issues.

[pandy]

I know at least one case when MPEG-2 encoder doesn't insert sequence_display_extension ie color primaries/description is UNKNOWN ie some assumption must be taken to deal with such content... i think that this is quite common practice on some broadcasters (sounds strange but life is life)

[hello_hello]

I'd say there's no reason for you to reply in this thread ever again if that's all you can offer as helpful comments to us = fellow and passionate encoders using this forum for rather constructive discussions.

Pity there's not a rule. ;)
Kind of makes you wonder why someone who claims there's no need to make re-encodes for a PC spends so much time in a forum dedicated to re-encoding video, especially spouting the same nonsense in threads such as this one over and over. Ironically, I think that's a much better example of having a boring life.

[hello_hello]

My point was that the industrial standards have a clear description.....

We understand your point. Now all you've got to do is explain how your point, such that it is, is relevant to the discussion. We all know about industry standards, we're just not all handcuffed to them like some.

I own both NTSC and PAL original DVDs, they are far superior to what is described, when played on TV using an average or better player; they look bad on PC, indeed.

Maybe you should learn how to re-encode video. My anamorphic DVD encodes look identical to the original regardless of what device I use to play them. Plus they're neatly cropped, unlike many DVDs. And they'll play using several portable devices, By all means, try inserting a DVD into your smartphone to play it.

First, there should be a developer that would explain what colorimetry s/he programmed in the codec/encoder, both for playing/decoding and encoding. This goes only so far as freeware is involved.

I'm fairly sure it only goes so far as your imagination will take it. Since when does a codec have "colorimetry"? And even though it's been explained to you before, colorimetry generally has nothing to do with encoding as such unless you're converting from RGB.

PS: there's no 1280x544 standard, so I don't care about. Let the one who produced it care about this. It will give him/her the illusion of doing something useful in his/her life, the quest for the holy grail of colorimetry.
As for 720p, there is a given and definite colorimetry, I've said it earlier this year.

So if you don't care about it, how about refraining from posting in threads about it and not taking them off on tangents to fit your own agenda?
The one who produced it is the one who cares about it, I've said that earlier this thread. You don't have to care about it, nor comment on something you don't care about.

I said that is known what colorimetry a standardised video has (a consumer has legal access only to standardised videos). It's no need to guess or to make assumptions.

Well the general consensus seems to be DVDs can be either R.601 or R.709 so that's probably wrong to begin with. The "legal access" argument is further irrelevant because nobody's discussing anything other than converting video to which they have "legal access".

It should also be clear enough what colorimetry an encoded video has, provided one did this himself.
What else can be more constructive than this?

Well aside from a statement of the obvious being anything but constructive, are you claiming every person who encodes a video they made themselves knows what colorimetry it uses, because that'd be total nonsense.

This thread is about colorimetry on playback of encoded video and whether color conversion should be used etc. If you want to discuss the necessity of re-encoding legally owned video, by all means start your own flame thread.

[madhatter300871]

Hi all

As the initial author of this thread I would like to say I don't have a boring life, I have quite a fulfilled life actually. I "play around" with media, video and audio, as a hobby. I like it. It interests me. I find great therapeutic value in engaging myself in my hobby and I do enjoy being involved in this forum and engaging with like minded individuals.

I don't download illegal content, I never have. You probably think I say that because I should, but actually it really is the case. I am one of the few I think lol

I transcode my video's for two reasons :-

First to have a backup to act as the one that I will actually play in my home cinema so as to keep the DVD or Bluray in perfect condition, after all my collection has cost me a lot over the years.

Second I like doing it. Plain and simple, like I say it interests me and keeps me entertained.

I could search the internet and find out all the information myself, read up on industry standards and the like, but where is the fun in that. I would much rather talk with the guys here so we can talk about it, discuss it, pass around thoughts and ideas, generally just engage myself with you guys and be part of this on line community.

I hope this is ok and I look forward to many more discussions on here, hopefully keep it light hearted and interesting and not get too bogged down with standards and what I should/shouldn't do. It's just my hobby !

Long live encoding .....

[kypec]

@hello_hello: thanks for your awesome comments - you smashed him in the most impressive way there can possibly be, I've almost choked on my biscuit reading this: :DBy all means, try inserting a DVD into your smartphone to play it.
@madhatter300871: My sentiments exactly - you expressed just how I feel about whole audio/video encoding & processing on amateur level too! ;)

[Ghitulescu]

Guys, first learn to read then talk:

There's only one reason for doing reencodes for PC:

[hello_hello]

Guys, first learn to read then talk:

Maybe you should follow your own advice?

Kind of makes you wonder why someone who claims there's no need to make re-encodes for a PC spends so much time in a forum dedicated to re-encoding video....

Maybe you should have also read the opening post properly before talking, because nowhere was it implied the discussion is about encoding solely for PC. Then maybe you wouldn't have come across like you were trolling.