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. |
14th April 2007, 16:03 | #461 | Link | |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
Quote:
|
|
17th April 2007, 21:53 | #462 | Link |
Registered User
Join Date: Jul 2005
Posts: 317
|
for special cases of deinterlacing, as in repal... should cm be used before with the interlaced paramatre set to true (this won't handle the odd progressive frame correctly) or use it after repal with it set to false (now that all frames are progressive)? I've tried both and they seem to work, even the hints seem to survive after repal.
|
18th April 2007, 19:05 | #464 | Link | |||
Registered User
Join Date: Oct 2006
Location: Gotham City, USA
Posts: 389
|
Update to my earlier issues:
Ok, so now I better understand how ColorMatrix works. The reason I wasn't seeing a difference is becuase, as Merlin7777 suggested, the source material was already in Rec.601; see the OutputDebugString below: Quote:
However, my research has brought up two new questions. First, what does the the "interlaced" parameter do? According to the documentation, "if your video is YV12 and is interlaced you need to set this parameter to true." In my experimentation, adding it and removing it made no difference. Second, adding the "hints" parameter to my DGDecode line appears to screw up the de-interlacing, adding in artifacts. Quote:
Quote:
Why do the hints effect the de-interlacing? Are the hints being passed to the wrong filter? EDIT: To reiterate, adding or removing the "interlaced=true" parameter to either of the above srcripts DOES NOT change the output. Last edited by Dr.Khron; 19th April 2007 at 02:25. |
|||
18th April 2007, 22:53 | #466 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
All the interlaced parameter does is internally invoke Separatefields() before colormatrix and invoke weave() afterwards. The reason for doing this is that colormatrix has to get u/v values for every y value. In progressive yv12 luma lines 0/1 share chroma line 0, luma lines 2/3 share choma line 1, etc... However, in interlaced yv12 luma lines 0/2 share chroma line 0, luma lines 1/3 share chroma line 1, etc... So using interlaced=false on interlaced yv12 will result in some luma lines using chroma values from a different field. That will be fine as long as there isn't motion, but in moving areas it will be bad. That's why it is better to accidently use interlaced=true on progressive frames than to accidently use interlaced=false on interlaced frames.
Next question is is it better to use colormatrix before or after an interlaced->progressive conversion. Theoretically, if your conversion is perfect, it would be better to run colormatrix afterwards on the progressive frames. In practice, you probably couldn't tell the difference. I will say that in the case of ivtc it's probably better to run colormatrix afterwards if only for the fact there will be fewer frames (so less processing time will be required). Now about hints. The hints from dgdecode are stored in the least significant bit of the first 64 pixels in the Y plane (or just the first 64 pixels for yuy2) of the image. Whether or not they will survive a specific filter or function depends entirely on whether or not that filter alters those 64 pixels. Most of the time you'd just have to try and see. If you set hints=true in colormatrix, and colormatrix doesn't detect any valid hints then it will throw an error. So if you don't get any error messages it should be fine. @Dr.Khron Could you show us the debug output from colormatrix in both cases (with/without hints). Also, if you are using colormatrix before ivtc and dgdecode is outputting yv12 then you must use interlaced=true or things will definitely get screwed up. |
19th April 2007, 02:28 | #467 | Link |
Registered User
Join Date: Oct 2006
Location: Gotham City, USA
Posts: 389
|
@Tritical:
Ok, I edited my previous message to include the debug output. Yes, I am using it before IVTC, but as I mentioned, adding or removing the "interlaced=true" parameter doesn't seem to effect the output. Seems to me the best way to pass info to the ColorMatrix filter is to use the .D2V arguments... when I fooled around with that it never caused any issues, just the "hints=true" syntax. |
19th April 2007, 07:52 | #469 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
One quick way of keeping the hints:
Mpeg2Source() o=last .... # do things MergeHints(o) ColorMatrix(hints=true) Mergehints is part of... Decomb, I think? I don't think hints can totally survive a framerate conversion, since pieces of different frames (which may have different matrices) are merged; but accepting that such transitions are quite rare, a simple Mergehints(o.ChangeFPS(framerate)) should be sufficient. |
19th April 2007, 13:08 | #470 | Link | |
Registered User
Join Date: Oct 2006
Location: Gotham City, USA
Posts: 389
|
What is the rest of your script?
Here ya go. Notice that it has no ColorMatrix, since this video doesn't need it. Quote:
The clip come out just fine. Could you post a small clip so that I can duplicate the behavior? You mean like a D2V file for a small piece? Wouldn't you need the entire VOB for that? |
|
21st April 2007, 06:59 | #472 | Link |
Registered User
Join Date: Jul 2005
Posts: 317
|
upon frameserving (via mpc), the results WITHOUT colormatrix is favourable (at least in my eyes) to the one WITH colormatrix. if this clip were to be fed through CCE, would not using cm keep the reults favourable? or am I missing something?
oh and just in case... Code:
ColorMatrix(mode="Rec.601->Rec.709",opt=0,hints=true,threads=0) |
21st April 2007, 12:06 | #473 | Link | |
Registered User
Join Date: May 2005
Posts: 236
|
Quote:
To save some cpu time (for encoding ^^) I stopped outputting rgb32 but keep yv12 in ffdshow, and uses ffdshow resizer in bicubic mode to 1600 x 0, which gives me a nice output on my lcd, and do the convertion as you mentionned to pc levels (funny to see that ticking / unticking the resize in ffdshow changes the levels to TV/PC realtime). vertical dimension 720 is the hardlimit apparently (1280x718 keeps TV levels, 1280x720=PC levels). It apparently also changes the color decoding as well from my tests; it looks like <720 --> rec601, and >=720 --> rec709... What a mess ! (WinXP, MPC, VRM9 renderless, X1600pro with ATI catalyst 6.8, ffdshow Mar 22 2007) |
|
21st April 2007, 21:55 | #474 | Link |
Registered User
Join Date: Feb 2002
Location: Charlotte, NC USA
Posts: 1,984
|
You'll see similar problems with automatic imposition of chroma range limiting. IMNSHO, this is all ill-conceived idiot-proofing for analog TV output.
I've gone to Flash video for computer playback of anything with a computer-based component such as a pure white background or scanned images because the "helpful automatic conversions" you've mentioned really screw things up.
__________________
Reclusive fart. Collecting Military, Trains, Cooking, Woodworking, Fighting Illini, Auburn Tigers |
23rd May 2007, 21:11 | #475 | Link |
Straight to video
Join Date: Jun 2005
Posts: 637
|
Tritical posted here on the 26th of March about a new version that fixes the source==dest error. Is that available for download anywhere? The most recent Colormatrix .ZIP on his site is dated January of this year.
Edit: and it doesn't have the "source==dest" error fixed. Last edited by kumi; 28th May 2007 at 00:22. Reason: Tested january version for source==dest error |
24th May 2007, 07:18 | #477 | Link |
Registered User
Join Date: Mar 2003
Posts: 128
|
Alright I read this whole thread because to be honest this filter and its uses are very confusing; and the documentation and the people in this thread do not make it clear.
What is unclear here and further muddied from the last few pages is the all important question of When is this filter supposed to be used and how? There are a few competing opinions here, also further confused by the 0-255/16-235 PC/TV issue. One party claims it doesn't matter what the source colorimetry, or what you convert to, if the resolution is below 720 then the 601 coefficients will be used to display the picture, this chosen by the video card, if it is above, then the 709 coefficients will be used. This would imply no other possibilities exist for PC playback. The other party says that the colorimetry must be converted based on what you are converting to. If it is MPEG-4, the decoders will use the 601 coefficients by default and thus a problem arises from 601 coefficients being used on what is supposed to be using 709 coefficients. If MPEG-2 is the destination format, then you want to match the colorimetry that the encoder will place in the stream. Resolution does not affect it in any way. Am I correct in my summary? If so, then the correct filter applications would be thus: ** If Party1 is correct: - If destination resolution is < 720 AND source colorimetry is not Rec.601 THEN convert to Rec.601. - If destination resolution is >= 720 AND source colorimetry is not Rec.709 THEN Convert to Rec.709. - Else Leave it be? ** If Party2 is correct: - If destination format is MPEG4 AND colorimetry is not 601 THEN Convert to Rec.601. - If destination format is MPEG4 AND colorimetry is Rec.601 THEN Do nothing. - If destination format is MPEG2, convert colorimetry based on what encoder will place in MPEG2 stream by default; if it places nothing (CCE), then use Rec.709 as per specs. - If destination format is OTHER, ???. Hope I'm not further confusing things, I'm attempting to make sense of the discussion in the last 20 pages. /MLS |
24th May 2007, 12:56 | #478 | Link |
Registered User
Join Date: Oct 2006
Location: Gotham City, USA
Posts: 389
|
Well... Since I had problems with using the filter when it wasn't needed, this is what I do: I test each source with the Debug flag.
I add ColorMatrix using the D2V option, and add Debug=true. Then I fire up DeBugView, and put a few frames through AvsP. The text in DeBugView tells you EXACTLY what the colors for the source material are, and wether or not you need to use the filter. If I don't need it, I remove it. Pretty simple. |
24th May 2007, 20:58 | #479 | Link | ||
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
@MLS,
Quote:
I used to think that Party2 is correct, and that's how it's described in the docs. However, as KillerZero pointed out: Quote:
Consider the following example which shows the problem: Suppose we encode to mpeg-2 with CCE and source is Rec.709. CCE writes Rec.709 is the header of the mpeg-2 stream (or more correctly, it leaves the colorimetry empty like you say). The problem is that since you are encoding to 720x480/576, Rec.601 is used by your graphics card to covert the decoded YV12 stream to RGB for display. This implies that it is displayed incorrectly. (Btw, i'm not sure that this also happens with software dvd-players which are not based on DirectShow.) If want to avoid this we should encode "correcting for Rec.601". But in this case the encoding (with CCE) contradicts with the header of mpeg-2, which clearly says that Rec.709 should be used for decoding. I do not like doing this. Perhaps others can share their mind about this ugly problem. |
||
28th May 2007, 07:19 | #480 | Link |
Registered User
Join Date: Sep 2004
Location: Near LA, California, USA
Posts: 1,545
|
All H.264/AVC and VC1 videos on HD-DVD's and Blu-Ray are BT.709 colorimetry.
__________________
Pirate: Now how would you like to die? Would you like to have your head chopped off or be burned at the stake? Curly: Burned at the stake! Moe: Why? Curly: A hot steak is always better than a cold chop. |
Tags |
colormatrix |
|
|