Do we still need to convert colorimetry of DVD source in vapoursynth?

[lansing]

I have this confusion on the colormatrix filter in avisynth for years now. According to its documentation, the reason for its creation was that commercial mpeg2-encoded dvd were encoded using rec709, while the old avisynth was using rec601. So to correctly display the color in avisynth, it has to convert the dvd color to rec601. From my understand, this was a workaround for avisynth's inability to correctly display rec709?

But then in this documentation, it was saying a complete different thing and usage of the filter:
http://avisynth.nl/index.php/Colorimetry

In general, it is safe to assume that Rec.601 is used for Standard Definition content and Rec.709 for High Definition content upon playback

What??

And then what about vapoursynth? Do we still need to do this conversion? I'm so confuse.

[TheFluff]

Rec.601 was typically used for standard definition broadcast content back in the day, that part is correct, and probably for DVD's originating with broadcast content, as well as older movie DVD's (before HDTV became common). It was never really consistent though, AFAIK. These days you shouldn't need to guess colorimetry if you have an actual DVD or broadcast source - there will almost certainly be metadata that specifies the colorimetry.

That being said, the main reason for converting to Rec601 wasn't that Avisynth didn't handle it (it doesn't matter as long as you're working in YUV, it's only relevant if you're converting to RGB), it was that pretty much all video players and renderers assumed Rec601 colorimetry, so colors would look kinda off when viewing if you kept Rec709 unchanged. These days though you should usually not need to convert colorimetry between SDR colorspaces - just make sure the metadata is kept intact and any decent player will do the right thing when converting to RGB for display.

Vapoursynth (or rather zimg) behaves similarly and will use colorimetry metadata when converting to RGB, if available. I believe zimg will actually throw an error if it can't figure out the colorimetry and you haven't specified it explicitly.

[lansing]

Originally Posted by TheFluff

Rec.601 was typically used for standard definition broadcast content back in the day, that part is correct, and probably for DVD's originating with broadcast content, as well as older movie DVD's (before HDTV became common). It was never really consistent though, AFAIK. These days you shouldn't need to guess colorimetry if you have an actual DVD or broadcast source - there will almost certainly be metadata that specifies the colorimetry.

That being said, the main reason for converting to Rec601 wasn't that Avisynth didn't handle it (it doesn't matter as long as you're working in YUV, it's only relevant if you're converting to RGB), it was that pretty much all video players and renderers assumed Rec601 colorimetry, so colors would look kinda off when viewing if you kept Rec709 unchanged.

So basically the entire description of the official colormatrix documentation is wrong?

These days though you should usually not need to convert colorimetry between SDR colorspaces - just make sure the metadata is kept intact and any decent player will do the right thing when converting to RGB for display.

Does that mean there would still be a rec601->rec709 conversion but it would be taken care by the player automatically? So if I am to encode a dvd into x264 and playback on my computer, I shouldn't be doing the rec601->rec709 conversion in the script? But then how would the player knows what colorimetry to use on playback?

[TheFluff]

Originally Posted by lansing

So basically the entire description of the official colormatrix documentation is wrong?

It's from like 2004, of course it's wrong. You always need to check metadata to see what the input colorspace is, and that has always been true. Avisynth's ConvertToRGB has supported both rec601 and rec709 input for a long ass time now too.

Originally Posted by lansing

Does that mean there would still be a rec601->rec709 conversion but it would be taken care by the player automatically?

No. Again, Rec601/709 define what a set of YUV values translates to in RGB. The vast majority of computer monitors are fed with (s)RGB, so to correctly convert the encoded YUV to RGB for display, you need to know which YUV variant/colorimetry to use. In the bad old days, players would always assume Rec601 because that was the NTSC and PAL SDTV standard (they were in fact slightly different, bt470bg for PAL and bt470m/fcc for NTSC if you want to be pedantic about it, but I don't think anyone cares). If you had Rec709 YUV, you couldn't easily convert that to RGB correctly on playback, so people would use Colormatrix to convert their perfectly good YUV to slightly different YUV that would look correct when converted to RGB by something that assumed Rec601 colors.

This has not been necessary for least a decade now, since better video players and renderers that could handle both conversions (YUV/601->RGB and YUV/709->RGB) started to appear and effectively solved the problem. For the last few years the problem has instead been converting HDR to SDR on playback in a reasonable way, since most computer monitors can't really display HDR properly, but that's an entirely different story.

Originally Posted by lansing

So if I am to encode a dvd into x264 and playback on my computer, I shouldn't be doing the rec601->rec709 conversion in the script? But then how would the player knows what colorimetry to use on playback?

No, you should not. Instead you should set a metadata flag in the video stream that tells the decoder/player what the YUV values mean in RGB. Both DGSource and ffmpeg can show you similar metadata flag from your DVD's video stream, so you can tell what the source colorimetry is and carry it over through the conversion. If you're using an Avisynth script as input to x264 this won't be done by default since Avisynth doesn't have a way to output colorimetry metadata, so you need to use the --colormatrix option manually. If you're using a video file as input x264 can usually pick up the metadata automatically. There won't be a YUV-to-YUV conversion, but there will be a conversion to RGB for display, using the proper constants.

For DVD's/SD content in general that's good enough; for HDR or other more exotic colorspaces you need more metadata.

Here's an old thread I quickly googled up if you want some more info about the x264 options.

e: forgot to mention - if the video stream doesn't have any colorimetry metadata, some (many?) players will do a quick-and-dirty guess about the input colorimetry and assume Rec601 if the video's vertical resolution is SD-ish (less than 600 pixels tall, or so), and Rec709 if it's more than that.

[_Al_]

While doing this in Vapoursynth, I'd keep an eye on what matrix you have in prop loaded in Vapoursynth:
frame = clip.get_frame(0)
clip = core.text.Text(clip, str(frame.props))
# print(frame.props)
if _Matrix=2 , unknown , you'd need to specify matrix_in_s='something' (but anyway you should flag it in an encoder) for conversions or even change it if you do not trust your source:
clip = core.std.SetFrameProp(clip, prop="_Matrix", intval=5)
or if you want to simulate colormatrix in Avisynth:
clip = core.resize.Bicubic(clip, matrix_in_s='709', matrix_s='470bg')
or
clip = core.resize.Bicubic(clip,matrix_s='470bg')
if Vapoursynth is aware of input matrix in prop, _Matrix=1 (that is '709' or some proper value)

[lansing]

Originally Posted by TheFluff

If you're using an Avisynth script as input to x264 this won't be done by default since Avisynth doesn't have a way to output colorimetry metadata, so you need to use the --colormatrix option manually.

I think we have to do the same for vapoursynth? Because I did a test on my dvd video, I intentionally set the frame property matrix to rec709, the vs editor preview window showed the color changed. But when I encoded it into x264, it was still playing back as rec601 color. Or am I setting the matrix in the wrong place on the script?

clip = core.std.SetFrameProp(clip, prop="_Matrix", intval=5)

[poisondeathray]

Originally Posted by lansing

I think we have to do the same for vapoursynth? Because I did a test on my dvd video, I intentionally set the frame property matrix to rec709, the vs editor preview window showed the color changed. But when I encoded it into x264, it was still playing back as rec601 color. Or am I setting the matrix in the wrong place on the script?

clip = core.std.SetFrameProp(clip, prop="_Matrix", intval=5)

Originally Posted by lansing

I think we have to do the same for vapoursynth? Because I did a test on my dvd video, I intentionally set the frame property matrix to rec709, the vs editor preview window showed the color changed. But when I encoded it into x264, it was still playing back as rec601 color. Or am I setting the matrix in the wrong place on the script?

clip = core.std.SetFrameProp(clip, prop="_Matrix", intval=5)

Generally things within the vapoursynth environment will pay attention to the prop setting. It can affect how many filters work, and vsedit too

When you pipe data out, it's just YUV data , with Y4M header (or in the case of raw data, no header) , which do not convey color matrix info . The recieving application does not see the "prop" data or anything. Only things like fps, dimensions, pixel format are conveyed by Y4M

For x264 (and x265) those VUI flags you set such as --colormatrix do not change the actual YUV data, they are just flags or labels. Some players read the flags and adjust, some do not. But nothing is automatically set by the pipe or Y4M header in terms of matrix/transfer/primaries



So for SD to SD, you don't have to do anything, unless the source video had something set incorrectly (e.g. it was flagged incorrectly somewhere along the way), because that might affect some of the operations you do (filters) . If you're not filtering or anything, you don't have to do anything differently

For example, a fairly common issue might be a progressive SD video, but encoded with interlaced flag. A PAL DVD for example. Or some types of progressive consumer AVCHD videos (which are not native progressive, but encoded interlaced). If you resized it, it would be resized in an interlaced manner by most filters, instead of progressive if you didn't set the props or explicitly override the filter.

It's a good idea to display the clip props to help prevent mixups like that

[lansing]

Originally Posted by poisondeathray

Generally things within the vapoursynth environment will pay attention to the prop setting. It can affect how many filters work, and vsedit too

When you pipe data out, it's just YUV data , with Y4M header (or in the case of raw data, no header) , which do not convey color matrix info . The recieving application does not see the "prop" data or anything. Only things like fps, dimensions, pixel format are conveyed by Y4M

Okay.

Some players read the flags and adjust, some do not.

I see, so that's why vlc was playing my dvd in a different color than other players.

So for SD to SD, you don't have to do anything, unless the source video had something set incorrectly

What happen if I want to encode my dvd in rec709? For example, I want to join my dvd footage and hd live footage together, so I would have to convert the dvd footage to rec709, and then add a "colormatrix" flag on the encoder indicating that the final encode is rec709?

dvd_clip = blah
hd_clip = bleh

dvd_clip = core.resize.Bicubic(dvd_clip , matrix_in_s='170m', matrix_s='709')

dvd_clip + hd_clip

[poisondeathray]

Originally Posted by lansing

I see, so that's why vlc was playing my dvd in a different color than other players.

maybe not set up correctly (renderer or gpu) ? maybe a bug or version issue ?

What happen if I want to encode my dvd in rec709? For example, I want to join my dvd footage and hd live footage together, so I would have to convert the dvd footage to rec709, and then add a "colormatrix" flag on the encoder indicating that the final encode is rec709?

dvd_clip = blah
hd_clip = bleh

dvd_clip = core.resize.Bicubic(dvd_clip , matrix_in_s='170m', matrix_s='709')

dvd_clip + hd_clip

Yes, it's similar to as you would do in avisynth .

The dvd upscale section needs to be actually converted to as if it had used 709 colors, which you are doing there (colormatrix filter might have been used in avisynth) . But you need to add the width= , height= args.

But if dvd_clip had interlaced TFF or BFF prop, it would resize as interlaced

[lansing]

Originally Posted by poisondeathray

maybe not set up correctly (renderer or gpu) ? maybe a bug or version issue ?

I remember something about vlc not displaying full range so that the darks are brighter. To counter that I followed some tutorial and set the renderer to use opengl and set my "nvdia setting->video color setting" to full range and then have it override vlc's setting.

And in that opengl setting in vlc, the display primaries was set to Bt.709, that's probably why all my videos are default to BT.709 despite having a colormatirx flag on the video.