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. |
![]() |
#1 | Link |
ekTOMBE STUDIOS
Join Date: Dec 2005
Location: Cuba
Posts: 257
|
colormatrix with bluray source, yes or no?
When doing conversions using dgdecode with DVDsources to xvid/x264 i always used color matrix.
The same applys to bluray -> x264 ? Im serving my source like this: Code:
v=LWLibavVideoSource("H:\TORA\ch1\00000.m2ts.lwi", stream_index=-1) a=LWLibavAudioSource("H:\TORA\ch1\00000.m2ts.lwi", stream_index=1) AudioDub(v,a) Spline36Resize(1280,720) Do i need to put anything on the x264 command line (like coheficients, color transfer or anything like that)? Or just serve and encode? I used search but the only information i found was about using colormatrix when scaling and downsizing. thanks.
__________________
So, it works or not??? |
![]() |
![]() |
![]() |
#2 | Link |
契約者
Join Date: Jun 2008
Posts: 1,576
|
Assuming your source is bluray, Colormatrix is only needed if you do a resize from HD to SD.
If your source is not bluray, you only want to use colormatrix if you for some reason are not happy with original colorimetry or do a resize from SD to HD So the answer is no. Yes. Always. Regardless of whether you use colormatrix or not. If this info is not present, the player or other software must guess it. Which is fine, usually, but not always. Once new 4K BDs will be out, this is will likely be even more important. If you specify that, you don't have to actually use colormatrix at all (assuming the player/renderer will obey this information). But converting (if needed) AND specifying it is a safest choice. Last edited by Keiyakusha; 12th August 2015 at 22:20. |
![]() |
![]() |
![]() |
#3 | Link | |
ekTOMBE STUDIOS
Join Date: Dec 2005
Location: Cuba
Posts: 257
|
Thanks for your help:
according to media info from mpchc the m2ts reports nothing (maybe there is a better tool to extract info from m2ts stream) the source is bluray i have doubts with these options: videoformat -> undef / unknown fullrange -> on? colorprim ->bt709? (do al the bluray discs use bt709?) transfer ->bt709? (do al the bluray discs use bt709?) colormatrix->bt709? (do al the bluray discs use bt709?) chromaloc = 0? nal-hrd->none? i found this info, dont know if its accurate: Quote:
__________________
So, it works or not??? |
|
![]() |
![]() |
![]() |
#4 | Link |
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,598
|
I think youi'll probably want Full range samples to be off. As I recall "On" is the default and is usually wrong (as YUV video should have Y in the 16-235 range). It trips me up all the time, and I end up with lower-contrast videos.
|
![]() |
![]() |
![]() |
#5 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,981
|
The way I understand it:
colormatrix = the method for converting the video to RGB on playback. It should always be bt709 for HD. transfer = the gamma curve. bt709 & bt601 use the same gamma curve. colorprim = once the video is converted to RGB, it'd display most accurately on a monitor calibrated to.... ie bt709 or bt601 primaries. I think HD displays are supposed to be bt709. The Video Usability Info has absolutely no effect on how the video is encoded. it's just information written to the video stream. As far as I know you'd probably only want to specify colormatirx when encoding, unless you can obtain the other info from the video stream, but I doubt any player would pay any attention to anything but colormatrix anyway. Fullrange = off (default). Pretty much all video is limited range (with the exception of formats such as mjpeg and maybe DV) Chroma sample location. I don't touch it myself. http://git.videolan.org/?p=x264.git;...;f=doc/vui.txt nal-hrd http://www.chaneru.com/Roku/HLS/X264...gs.htm#nal-hrd From the DGIndex manual: Colorimetry - Displays the colorimetry scheme used by the stream. Note that if the stream does not declare the colorimetry, then ITU-R BT.709* is reported for HD video, and ITU-R BT.470-2* is reported for SD video. The * character indicates that the stream did not declare the colorimetry From the colormatrix manual: hints: DGDecode v1.20 or newer can output colorimetry hints in the video stream which ColorMatrix can read in order to automatically determine the source coefficients. To enable this, set info=3 in mpeg2source() and set hints=true in ColorMatrix() as shown below: The way I understand it, by default Colormatrix will convert bt709 to bt601, which you want it to do for standard definition but not for high definition. For standard definition you'd normally use it in combination with DGDecode like this: Mpeg2source("D:\video.d2v", info=3) ColorMatrix(hints=true) Which I'm pretty sure would be the same as: Mpeg2source("D:\video.d2v", info=3) ColorMatrix(hints=true, mode="Rec.709->Rec.601") For HD video I think you'd need to use it like this so it'll convert to bt709 when the source isn't bt709, but when it is bt709, it'll leave it alone. Mpeg2source("D:\video.d2v", info=3) ColorMatrix(hints=true, mode="Rec.601->Rec.709") I generally don't use colormatrix at all and just assume HD is bt709 and SD is bt601 and re-encode it as is. If I'm downscaling (or upscaling) I'd manually convert the colours and set the x264 colormatrix option accordingly. That'd be regardless of the format of the source video (mpeg2 or h264 etc) ie for downscaling HD to SD: ColorMatrix(mode="Rec.709->Rec.601", clamp=0) Last edited by hello_hello; 14th August 2015 at 14:32. |
![]() |
![]() |
![]() |
#7 | Link |
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633
|
always a pain in the ass when "color" stuff gets to be the problem
converting "matrix" alone is, not very correct more or less "matrix" "transfer" and "primaries" are a set of interactive parameters work together as one to represent a certain part of colors from CIE 1931 (the very first color standard covering every single visible color to human vision, and device independent of course, kind like the royal of all color related stuff) primaries = how red exactly is the red here (green, blue likewise), it decides the coordinates of 3 elementary colors (cannot be represented as some mixed stuff of other colors, they are the purest thing here, they get to mix each other to produce other colors) on CIE system transfer = a function that connects physical intensity and perceived intensity (aka gamma) matrix = a matrix to separate luminance and chrominance so, see, HDTV got a different "matrix" not because "oops, the old bt.601 sucks ass, I don't like it, let's make some crazy new crap", "709" matrix is there because HDTV picks different primaries from SDTV, so a new matrix is needed to separate luminance and chrominance of the image based on this new primaries. pointless to apply "709" matrix on clips with "601 NTSC/PAL" primaries cuz you can't get correct luminance and chrominance with this matrix, the "luminance" is not the exact luminance and so is the chrominance, the "matrix" does not serve as it's supposed to, and "601" matrix on "709" primaries, likewise if you are that desperate to change the color system, don't just convert the matrix, convert to CIE 1931 and apply a whole new set of different color system. |
![]() |
![]() |
![]() |
#8 | Link | |||
契約者
Join Date: Jun 2008
Posts: 1,576
|
Quote:
Quote:
This might be different for HDTV mpeg2 captures though. I'm not sure if they have proper Rec.709 flags and what happens in this case, but it would be very bad to convert it to Rec.601 and if DGDecode is doing this, that would be a serious bug/flaw. So getting rid of ColorMatrix entirely seems like a good idea. Only use it for SD<->HD conversions. Quote:
DVDs whatever don't have colorimetry specified or do have it specified. In 1st case you assume "601" and set x264 accordingly, in second you take whatever is specified and specify it in x264. In either case you don't need to convert anything (unless you do a SD-HD resize). So if ColorMatrix(hints=true) is converting something, whatever output you get is wrong, Edit: only if you want to convert video to RGB somewhere inside the avs script, you must specify correct colorimetry. But you don't need colormatrix for that either, avisynth's ConvertTo*** functions have a way to deal with that. Perhaps this was not always the case. Last edited by Keiyakusha; 13th August 2015 at 19:36. |
|||
![]() |
![]() |
![]() |
#9 | Link |
ekTOMBE STUDIOS
Join Date: Dec 2005
Location: Cuba
Posts: 257
|
Every time i see something about colormatrix or color representation it becomes a discussed topic, the information is very unclear / obscure most of the time.
Fullrange: Histogram("classic") on avisynth confirms that the video is in fact limited so: Fullrange -> off (default) Colormatrix: DGAVC Index reports BT709* (undetermined-> assumed) so i dont know what to put here , BT709 because "all HD Streams are with bt709" or leave it undefined" As far as i remember the problem with colormatrix and SD sources was the fact that MPEG4 always assumed BT601 so you have to convert BT709 to BT601 BUT with h264 you can specify whatever you want, so no need for colormatrix if you are converting to h264. BUT AGAIN: Since most of the time BT601 is expected on SD streams and BT709 is expected on HD streams (and some renderers expect it like that) you need to use color matrix for resolutions changes. So basically: BT709 for SD-> HD output (convert if source is not) and flag to x264 BT601 for HD-> SD output (convert if source is not) and flag to x264 (nothing to do if using xvid). HD -> HD: BT709 -> Do nothing and flag to x264 BT601 -> Convert to 709 and flag to x264 Unspecified -> ????? Do nothing at all or flag to x264 Please correct me if im wrong
__________________
So, it works or not??? |
![]() |
![]() |
![]() |
#10 | Link | ||
契約者
Join Date: Jun 2008
Posts: 1,576
|
Videos on TV/DVD/BD and likely every official streaming service are never fullrange. Only if you'll do it yourself. They could be technically PC range but that would be some noise or other garbage most of the time.
That is what you'll see for most HD streams. Set it to 709 in x264. Quote:
Edit: in fact if a DVD player strictly follows the spec and the stream is flagged as 709, it is supposed to refuse to play it. True that MPEG4/ASP (divx/xvid) does not have colorimetry information, but if this info is not present, assumption is made by the player/renderer based on resolution, not format. MPEG4 itself does not assumes anything. Quote:
For unspecified, assume that all DVD are 601, all Blurays are 709 and specify accordingly (note that 4k blurays will use yet another colorimetry) Last edited by Keiyakusha; 13th August 2015 at 21:55. |
||
![]() |
![]() |
![]() |
#12 | Link | |||
ekTOMBE STUDIOS
Join Date: Dec 2005
Location: Cuba
Posts: 257
|
Thanks to all.
I remember all the avisynth examples about using color matrix with dgdecode for converting to Xvid, and the reasons were not very clear to me. But now i have two final questions: What was the point of color matrix (before the hdtv/bluray existence)? An mpeg2 stream with BT709? From where? TV capture? This: http://forum.doom9.org/showthread.php?t=82217 mentions Quote:
Keiyakusha: Quote:
Is there any proper way of converting from one to another on avisynth (without using colormatrix), i know this would imply converting to and from RGB but i want to know. Quote:
__________________
So, it works or not??? |
|||
![]() |
![]() |
![]() |
#13 | Link | |
I'm Siri
Join Date: Oct 2012
Location: void
Posts: 2,633
|
Quote:
and you'll need a 3D expression to go from RGB to XYZ, something like mt_lutxyz, but with higher precision, like floating point you can do it with std.Expr in vaporsynth, and, I don't really know if there is an "avisynth Expr" out there |
|
![]() |
![]() |
![]() |
#14 | Link | |||
契約者
Join Date: Jun 2008
Posts: 1,576
|
Quote:
"corrects the colors of mpeg2 streams of dvds" - there's nothing to correct "encoded using a different set of coefficients as used by AviSynth's color conversion routines" - What different set? What routines? Avisynth is not converting anything. This is only matters when you convert from YUV to RGB, and you don't. And even if you do, avisynth supports both conversions, Rec601 and Rec709 Quote:
ConvertToRGB32(matrix="Rec601").ConvertToYV12(matrix="Rec709") But this is more destructive than using colormatrix. Last edited by Keiyakusha; 14th August 2015 at 07:01. |
|||
![]() |
![]() |
![]() |
#16 | Link | |||
Registered User
Join Date: Mar 2011
Posts: 4,981
|
Quote:
Quote:
Quote:
The colormatrix docs might only mention DVDs but the DGDecode docs mention HD video too. Colorimetry - Displays the colorimetry scheme used by the stream. Note that if the stream does not declare the colorimetry, then ITU-R BT.709* is reported for HD video, and ITU-R BT.470-2* is reported for SD video. The * character indicates that the stream did not declare the colorimetry. So if you're using DGDecode's hints with colormatrix, I see no reason why it shouldn't work exactly as I described for HD video. Mpeg2source("D:\video.d2v", info=3) ColorMatrix(hints=true, mode="Rec.601->Rec.709") That should convert to bt.709 if the source isn't bt.709, and leave the colors alone if it's already bt.709. Personally, I don't think it's worth bothering with. Just as DVDs all seem to be bt.601, all HD video is BT.709, so colormatrix won't be doing anything. Except of course for the plethora of x264 standard definition bt.709 encodes in existence that were encoded from HD sources without converting the colours, but aside from the sins committed by some people when downscaling and re-encoding, HD should always be BT.709 and SD should be bt.601. Last edited by hello_hello; 14th August 2015 at 17:10. |
|||
![]() |
![]() |
![]() |
#17 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,981
|
Quote:
It's not completely accurate to say MPEG4 (ie Xvid) or x264 "expect" bt.601, because while that's true, it's only when the encoder input is RGB. Then the encoders have to decide which colorimetry to use when converting to YV12. If you're re-encoding a YV12 Bluray/DVD video though, the encoders just re-encode it. They're oblivious to the colorimetry required for playback, so it doesn't matter if it's bt.601 or bt.709. In the case of Xvid, it can't write the colorimetry info to the video stream as x264 can, so ideally you should ensure it's correct (bt.709 for HD and bt.601 for SD) because the player will pick the colorimetry based on resolution. So converting bt.709 to bt601 when downscaling is a good idea. In the case of x264, it can write the colorimetry info to the video stream and in a perfect world all players would use the written colorimetry. In the real world though, I doubt that's always the case. Depending on how you're playing video using a PC.... the player and renderer etc.... and assuming the video card drivers work correctly and/or don't interfere, there's still a pretty good chance the colorimetry info written to the stream will be completely ignored and the choice will be made based on resolution. If I remember correctly the DVD spec and the mpeg2 spec don't always agree. Even though DVDs contain mpeg2 video. DVDs are supposed to be bt.601, but for standard definition mpeg2, if there's no colorimetry written to the video stream the spec says you're supposed to assume bt.709, not bt.601. So the difference there might account for it. If you search through old threads here, you'll find posts where it's claimed a DVD is bt.709. Originally, DGDecode reported bt.709 if there was no colorimetry info written to the video stream, because the original consensus was DVD video should be bt.709. That's long since changed, and DGDecode now reports bt.601 for DVDs when there's no colorimetry info written to the stream. Most of the early posts on colorimetry and colormatrix here are before my time, but you may still find screenshots indicating VirtualDub displays DVD video with the wrong colorimetry.... or something along those lines. I don't know why the consensus changed, but I suspect DVD video hasn't changed and crappy video card drivers were causing the wrong colorimetry to be used in the early days. That's just my theory..... There was an Avisynth page containing a list of video card drivers explaining when those drivers get things wrong, but I can't find it at the moment. It may have been removed. The info would be very out of date. By the way, if you do convert to RGB and back to YV12 during encoding, by default Avisynth and VirtualDub and their filters all convert to RGB using bt.601. That's fine, even for HD, because by default they'll all convert the RGB back to YV12 using bt.601 as well. It's one of those times when two wrongs does make a right. If you convert to RGB and back using the same colorimetry each time, the colors won't change, even if it's not the same colorimetry that'll be used to convert to RGB on playback. ![]() Last edited by hello_hello; 14th August 2015 at 15:44. |
|
![]() |
![]() |
![]() |
#18 | Link |
Registered User
Join Date: Mar 2011
Posts: 4,981
|
I have a question... while I'm thinking about it. Good old AutoGK has two colour correction options in it's settings. When colour correction is enabled you can choose between "accurate" and "fast". AutoGK comes with colormatrix, so I assume that's what it uses for colour "correction" if required (in combination with hints from DGDecode), but I've never known what the difference is between the two colour correction options. Does anyone know?
|
![]() |
![]() |
![]() |
#19 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
|
|
![]() |
![]() |
![]() |
#20 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,981
|
Quote:
If I didn't convert the colours and simply wrote bt.709 to the video stream, on the occasions I'm using a media player that pays attention to the colorimetry info, in what way would the video display differently?. The original required bt.709 when converting to RGB on playback, while the encode now requires bt.601 because I converted the colours. Maybe I'm missing something but I thought bt.601 and bt.709 used exactly the same gamma, and even if the colorprim parameter wasn't generally ignored by players, why wouldn't it still be correct? If the source video displays as it should on a bt.709 calibrated display, shouldn't the downscaled version also display the same way? The original video probably looks like this: Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.709 After I convert the colours and downscale I normally only tell x264 to write the matrix coefficients, but if I was more enthusiastic, or I always knew the correct values, I'd get it to write all three like this: Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.601 Why wouldn't the encode display exactly like the source given I've only changed the matrix coefficients to reflect the change in colorimetry? Last edited by hello_hello; 14th August 2015 at 17:07. |
|
![]() |
![]() |
![]() |
Tags |
blu-ray, color, colormatrix, correction, h264 |
Thread Tools | Search this Thread |
Display Modes | |
|
|