Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > VapourSynth

Reply
 
Thread Tools Search this Thread Display Modes
Old 11th March 2019, 09:41   #1  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,657
Do we still need to convert colorimetry of DVD source in vapoursynth?

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

Quote:
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.
lansing is offline   Reply With Quote
Old 11th March 2019, 11:52   #2  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,100
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.

Last edited by TheFluff; 11th March 2019 at 11:56.
TheFluff is offline   Reply With Quote
Old 11th March 2019, 16:45   #3  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,657
Quote:
Originally Posted by TheFluff View Post
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?

Quote:
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?
lansing is offline   Reply With Quote
Old 11th March 2019, 20:31   #4  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,100
Quote:
Originally Posted by lansing View Post
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.

Quote:
Originally Posted by lansing View Post
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.

Quote:
Originally Posted by lansing View Post
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.

Last edited by TheFluff; 11th March 2019 at 20:50.
TheFluff is offline   Reply With Quote
Old 11th March 2019, 20:59   #5  |  Link
_Al_
Registered User
 
Join Date: May 2011
Posts: 348
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)

Last edited by _Al_; 11th March 2019 at 21:12.
_Al_ is offline   Reply With Quote
Old 12th March 2019, 03:22   #6  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,657
Quote:
Originally Posted by TheFluff View Post
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?
Code:
clip = core.std.SetFrameProp(clip, prop="_Matrix", intval=5)

Last edited by lansing; 12th March 2019 at 03:24.
lansing is offline   Reply With Quote
Old 12th March 2019, 04:19   #7  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,516
Quote:
Originally Posted by lansing View Post
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?
Code:
clip = core.std.SetFrameProp(clip, prop="_Matrix", intval=5)

Quote:
Originally Posted by lansing View Post
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?
Code:
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
poisondeathray is offline   Reply With Quote
Old 12th March 2019, 09:09   #8  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,657
Quote:
Originally Posted by poisondeathray View Post
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.

Quote:
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.


Quote:
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?

Code:
dvd_clip = blah
hd_clip = bleh

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

dvd_clip + hd_clip
lansing is offline   Reply With Quote
Old 12th March 2019, 15:28   #9  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,516
Quote:
Originally Posted by lansing View Post
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 ?


Quote:
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?

Code:
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
poisondeathray is offline   Reply With Quote
Old 13th March 2019, 00:02   #10  |  Link
lansing
Registered User
 
Join Date: Sep 2006
Posts: 1,657
Quote:
Originally Posted by poisondeathray View Post
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.
lansing is offline   Reply With Quote
Reply

Tags
colorimetry, colormatrix, conversion

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 19:03.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.