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 > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 18th March 2007, 22:25   #401  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
Quote:
I must admit I don't understand this entirely. Previewing with VDub didn't give me any artefacts typical for 4:2:0 colour compression, because it defaults in options to RGB24. I assume DGIndex does very similar or even exactly the same thing, so no colour bleeding nor stair-stepping.

Yet while decoding MPEG-2 (most of them are YV12 for compression's sake) or MPEG-4 ASP (Divx, XviD) I always get the mentioned artefacts, no matter what player and decoder I use. How could it be a clip is converted to RGB upon display and keeps artefacts typical for chroma sub-sampling (as in JPEGs)? The only thing I can do then is to use ffdshow and force either YUY2 output colour space or the already mentioned HQ YV12=>RGB conversion, again as output colour space. Only then the artefacts disappear (I made dozens of screen-shots once).
It all depends on how the YV12 is upsampled (when converting to RGB) upon display. In many cases the missing chroma is just doubled (ie the same as what pointresize or nearest neighbour resizing does), resulting in stair-stepping. In some cases (AviSynth, VirtualDub, HQ conversion in ffdshow, huffyuv, some others ...), the missing chroma is interpolated instead of being doubled.
Wilbert is offline   Reply With Quote
Old 18th March 2007, 22:29   #402  |  Link
canuckerfan
Registered User
 
Join Date: Jul 2005
Posts: 317
other than dgindex, what other method is there for determining a streams colorimetry?
canuckerfan is offline   Reply With Quote
Old 18th March 2007, 22:34   #403  |  Link
HeadBangeR77
Registered User
 
HeadBangeR77's Avatar
 
Join Date: Dec 2006
Location: Heidelberg (DE), Kraków (PL)
Posts: 519
Quote:
Originally Posted by Wilbert View Post
It all depends on how the YV12 is upsampled (when converting to RGB) upon display. In many cases the missing chroma is just doubled (ie the same as what pointresize or nearest neighbour resizing does), resulting in stair-stepping. In some cases (AviSynth, VirtualDub, HQ conversion in ffdshow, huffyuv, some others ...), the missing chroma is interpolated instead of being doubled.


Now it's clear.
__________________
"Only two things are infinite: the universe and human stupidity, and I'm not sure about the former."
HeadBangeR77 is offline   Reply With Quote
Old 18th March 2007, 23:23   #404  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
Quote:
other than dgindex, what other method is there for determining a streams colorimetry?
GSpot (as mentioned in the documentation). I'm not aware of any other utilities which show the colorimetry.
Wilbert is offline   Reply With Quote
Old 19th March 2007, 01:52   #405  |  Link
KillerZero
Registered User
 
Join Date: Dec 2005
Posts: 26
Decoder doesn't assume anything. MPEG4 decoder just decodes MPEG4 to YV12. Conversion to RGB is done by graphic card, not by decoder. (except you force RGB24 output, if decoder supports it) So it is up to your graphic card and driver to select proper colorimetry. Decoder doesn't have anything to do with it. And at least Ati cards select correct colorimetry according to resolution. (Rec601 for SD, Rec709 for HD) I don't have nvidia card, so I can't test it but I think it will do it corectly too.

You are doing wrong when you are comparing screenshots from MPC, because MPC does conversion by itself when grabbing screenshots and does it wrong. You have to compare just paused video, not captured screens.

BTW X264 has these settings, but I've never tested it and I'm not sure what exactly they will do. I think that it is better to leave it "undef":
--colorprim <string> Specify color primaries ["undef"]
- undef, bt709, bt470m, bt470bg
smpte170m, smpte240m, film
--transfer <string> Specify transfer characteristics ["undef"]
- undef, bt709, bt470m, bt470bg, linear,
log100, log316, smpte170m, smpte240m
--colormatrix <string> Specify color matrix setting ["undef"]
- undef, bt709, fcc, bt470bg
smpte170m, smpte240m, GBR, YCgCo

Last edited by KillerZero; 19th March 2007 at 02:24.
KillerZero is offline   Reply With Quote
Old 19th March 2007, 09:30   #406  |  Link
HeadBangeR77
Registered User
 
HeadBangeR77's Avatar
 
Join Date: Dec 2006
Location: Heidelberg (DE), Kraków (PL)
Posts: 519
Quote:
Originally Posted by KillerZero View Post
You are doing wrong when you are comparing screenshots from MPC, because MPC does conversion by itself when grabbing screenshots and does it wrong. You have to compare just paused video, not captured screens.
I can reassure you they look the same - I've done thousands of them in my life and never marked any difference between the paused video screen and a screen grab. Recently I've also compared MPC's, Nero ShowTime's and PowerDVD's still frames, and guess what, they all looked the same, no matter what application/decoder was used. It applies at least to MPEG-2, MPEG-4 ASP and x264 encodes.

Quote:
BTW X264 has these settings, but I've never tested it and I'm not sure what exactly they will do. I think that it is better to leave it "undef"...
Now this might be really interesting ... Why not to make a short samples with those parameters?

cheers,
HDBR77
__________________
"Only two things are infinite: the universe and human stupidity, and I'm not sure about the former."
HeadBangeR77 is offline   Reply With Quote
Old 19th March 2007, 10:38   #407  |  Link
HanSolo00
Registered User
 
Join Date: Mar 2004
Posts: 59
I've just found some 'interesting' behaviour with a simple test on 4 different MPEG-2 clips. The problem with DGindex+ColorMatrix hints only seems to occur for me with HD MPEG-2; in all the other cases, the hints passed do as I expect with ColorMatrix. It does a Rec.709->Rec.601 on a Rec.709 Interlaced NTSC clip, but does not on a Rec.709 Progressive Film clip. On a SMPTE 170M Progressive Film clip, it also changes nothing. In those 3 cases, the DGindex shown frames match the output avs played back in MPC, with ColorMatrix(hints=true).

Where it does not match, is when you open a Rec.709 NTSC Interlaced Transport Stream. When you playback the TS in DGindex, and compare the frame colors to MPC playing back the same source frames, the colors match--but when you allow ColorMatrix to use DGindex hints, the colors are changed in the output. IMHO, this is improper--the HD Transport Stream, even though it is NTSC Video Type, should be left alone because HD is supposed to be Rec.709. When I let ColorMatrix change the colors to Rec.601, all the reds turn unnaturally orange, and this is what is happening when DGindex passes the hints as 'Rec.709' and 'NTSC Video Type'. So, the problem appears to be DGindex reporting hints to ColorMatrix that tells it to change the color on the Transport Streams, when it shouldn't.

In a nutshell: DGindex internally is leaving a HD Transport Stream alone, as Rec.709, as you can see when you play it in DGindex (which is correct.) But as soon as you pass hints 'NTSC' video type to ColorMatrix, it goes and does a Rec.709->Rec.601 because it isn't differentiating between SDTV NTSC video and HDTV NTSC video. This must be wrong, because if you open a SDTV NTSC clip into DGindex and play it, it internally changes the color to Rec.601.

I can't post more details or samples just yet as I must get some sleep--full work day tomorrow.

Last edited by HanSolo00; 19th March 2007 at 11:05. Reason: clarification
HanSolo00 is offline   Reply With Quote
Old 19th March 2007, 13:48   #408  |  Link
KillerZero
Registered User
 
Join Date: Dec 2005
Posts: 26
Quote:
Originally Posted by HeadBangeR77 View Post
I can reassure you they look the same - I've done thousands of them in my life and never marked any difference between the paused video screen and a screen grab.
Yes, they look same for SD video, but for high resolution they are wrong. Try it. Make one clip resampled to 640x360 and one resampled to 1280x720. Do one screenshot in vdubmod from avisynth script with ConvertToRGB24() and one with ConvertToRGB24("Rec709"). Then compare them. You will see that SD clip will look as first screenshot and HD clip as second screenshot, but when you capture screens from MPC, they will look both as first one.
You must not have set ffdshow to output RGB of course, you must have set it to output directly YV12. And I have set output to system default in MPC, but I don't think that VMR will change anything about that.
KillerZero is offline   Reply With Quote
Old 19th March 2007, 13:57   #409  |  Link
HeadBangeR77
Registered User
 
HeadBangeR77's Avatar
 
Join Date: Dec 2006
Location: Heidelberg (DE), Kraków (PL)
Posts: 519
Quote:
Originally Posted by KillerZero View Post
Yes, they look same for SD video, but for high resolution they are wrong. Try it. Make one clip resampled to 640x360 and one resampled to 1280x720. Do one screenshot in vdubmod from avisynth script with ConvertToRGB24() and one with ConvertToRGB24("Rec709").
Now, it's much clearer and more precise. Btw. VDub (if VDubMod, I have no idea) converts to RGB24 by default (check video => colour depth). So only in case of Rec.709 the additional conversion is needed, imo. I've never encoded anything with horizontal resolution higher than 1024, so I haven't marked what you've found out.

Quote:
Then compare them. You will see that SD clip will look as first screenshot and HD clip as second screenshot, but when you capture screens from MPC, they will look both as first one.
You must not have set ffdshow to output RGB of course, you must have set it to output directly YV12. And I have set output to system default in MPC, but I don't think that VMR will change anything about that.
VMR can only add the TV-scale bug, if one is unlucky. I get it, gonna try with some QT trailers I've got. Could it be in any way related to the problem that HanSolo00 is having atm?

cheers,
HDBR77
__________________
"Only two things are infinite: the universe and human stupidity, and I'm not sure about the former."
HeadBangeR77 is offline   Reply With Quote
Old 19th March 2007, 14:28   #410  |  Link
KillerZero
Registered User
 
Join Date: Dec 2005
Posts: 26
Quote:
Originally Posted by HeadBangeR77 View Post
Now, it's much clearer and more precise. Btw. VDub (if VDubMod, I have no idea) converts to RGB24 by default (check video => colour depth). So only in case of Rec.709 the additional conversion is needed, imo. I've never encoded anything with horizontal resolution higher than 1024, so I haven't marked what you've found out.
When you use fast recompress, vdub(mod) passes YV12 directly to encoder. I hope that noone is so stupid to use full processing when encoding to xvid! I hope you didn't misunderstand me, that conversion to RGB in avisynth is good only if you make screenshots, you should leave it in YV12 for reencoding!


Quote:
Originally Posted by HeadBangeR77 View Post
Could it be in any way related to the problem that HanSolo00 is having atm?
I think that only problem HanSolo have is confusion caused by DGindex's TV/PC scale settings and this filter... For HD only Rec709 is used and everything expect Rec709 when playing HD video, so Colormatrix shouldn't be used. If you use it, colormatrix changes it to 601, but when playing it is handled as 709. So it is like if you would use colormatrix twice, and it of course causes orange faces.

Last edited by KillerZero; 19th March 2007 at 15:00.
KillerZero is offline   Reply With Quote
Old 19th March 2007, 14:44   #411  |  Link
HeadBangeR77
Registered User
 
HeadBangeR77's Avatar
 
Join Date: Dec 2006
Location: Heidelberg (DE), Kraków (PL)
Posts: 519
Quote:
Originally Posted by KillerZero View Post
When you use fast recompress, vdub(mod) passes YV12 directly to encoder. I hope that noone is so stupid to use full processing when encoding to xvid!
I've always been using fast recompress, was it Nandub ages ago, was it VDubMod or is it the latest VDub. Yet the application defaults to full processing mode when you open it, so I use it for previewing & taking screenshots (if necessary, e.g when asked by Wilbert, normally AVSP would suffice).
__________________
"Only two things are infinite: the universe and human stupidity, and I'm not sure about the former."
HeadBangeR77 is offline   Reply With Quote
Old 19th March 2007, 14:56   #412  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
Quote:
Originally Posted by KillerZero View Post
I think that only problem HanSolo have is confusion caused by DGindex's TV/PC scale settings and this filter...
I suspect that is the case as well.
Guest is offline   Reply With Quote
Old 19th March 2007, 17:14   #413  |  Link
HanSolo00
Registered User
 
Join Date: Mar 2004
Posts: 59
Quote:
Originally Posted by neuron2 View Post
I suspect that is the case as well.
The problem I'm seeing is not Luma related, it's the fact that DGindex passes hints to ColorMatrix telling it to Rec.709->Rec.601 on HD MPEG-2 NTSC Transport Stream. Of course it is easy to simply exclude ColorMatrix from HD encoding altogether, but that sort of defeats the whole purpose as I understand it of passing color hints and determining any color adjustment for the user automatically.

To simplify: if Rec.709 HD NTSC Transport Stream were supposed to appear with Rec.601 color, why then does DGindex not do so internally/visually in playback, when it does do this for SD NTSC material? (of course it doesn't because this would be incorrect.)

Quote:
Originally Posted by KillerZero View Post
For HD only Rec709 is used and everything expect Rec709 when playing HD video, so Colormatrix shouldn't be used. If you use it, colormatrix changes it to 601, but when playing it is handled as 709. So it is like if you would use colormatrix twice, and it of course causes orange faces.
This is proving out what I just posted above. ColorMatrix should not change HD source color from Rec.709. So then, why can't DGindex pass hints telling it to not change anything? It would make things a lot more simple and less confusing for the end user. And after all, I thought the whole point of passing hints in the first place was to allow DGindex+ColorMatrix to always get the color right irregardless of what the scripter needs to know.

Last edited by HanSolo00; 19th March 2007 at 18:02. Reason: simplification
HanSolo00 is offline   Reply With Quote
Old 19th March 2007, 18:19   #414  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
Quote:
Originally Posted by HanSolo00 View Post
The problem I'm seeing is not Luma related, it's the fact that DGindex passes hints to ColorMatrix telling it to Rec.709->Rec.601 on HD MPEG-2 NTSC Transport Stream.
DGIndex does not pass hints to anyone or anything. I will guess that you are meaning to say "DGDecode passes hints." Precision is important.

Second, DGDecode does not "tell" ColorMatrix to do anything. It simply reports the colorimetry detected in the stream. That may sound like a fine point to you, but it determines where a fix for your claimed bug should be located.

Quote:
To simplify: if Rec.709 HD NTSC Transport Stream were supposed to appear with Rec.601 color, why then does DGindex not do so internally/visually in playback, when it does do this for SD NTSC material? (of course it doesn't because this would be incorrect.)
DGDecode does not treat SD and HD differently, as there is nothing in the MPEG2 specification that requires it to do so. Any observed difference will be due to different stream specification of the colorimetry.

Furthermore, there is no hint specifying "NTSC video" as you alluded to in an earlier post. It simply does not exist. You wrote:

"this is what is happening when DGindex passes the hints as 'Rec.709' and 'NTSC Video Type'"

There is a hint that reports the progressive_frame flag, but I don't know if ColorMatrix uses it.

Quote:
This is proving out what I just posted above. ColorMatrix should not change HD source color from Rec.709. So then, why can't DGindex pass hints telling it to not change anything?
DGDecode reports the detected stream colorimetry via hints. That is all. If there is a problem, you need to focus on the downstream filter. If you can demonstrate that DGDecode is not correctly reporting the colorimetry, then you will have my attention.

Last edited by Guest; 19th March 2007 at 18:28.
Guest is offline   Reply With Quote
Old 19th March 2007, 18:27   #415  |  Link
KillerZero
Registered User
 
Join Date: Dec 2005
Posts: 26
Quote:
Originally Posted by HanSolo00 View Post
To simplify: if Rec.709 HD NTSC Transport Stream were supposed to appear with Rec.601 color, why then does DGindex not do so internally/visually in playback, when it does do this for SD NTSC material? (of course it doesn't because this would be incorrect.)
You are still missing fact that HD is played with Rec709 matrix, not with 601 matrix. Hints tell colormatrix only what colorspace is source, not to what colorspace it should convert. Colormatrix changes colors to 601, so it is obvoius that it will seem wrong when it will be played with rec709 matrix. Good solution would be to change Colormatrix to default to rec709 when resolution is HD. But best would be to not use Colormatrix for HD at all, as you won't find HD in any other colorspace than Rec709, so it is never needed to convert it in any way.

Last edited by KillerZero; 19th March 2007 at 18:34.
KillerZero is offline   Reply With Quote
Old 19th March 2007, 18:40   #416  |  Link
HanSolo00
Registered User
 
Join Date: Mar 2004
Posts: 59
Quote:
Originally Posted by KillerZero View Post
You are still missing fact that HD is played with Rec709 matrix, not with 601 matrix.
No, I understand that just fine.
Quote:
Originally Posted by KillerZero View Post
Good solution would be to change Colormatrix to default to rec709 when resolution is HD.
This is the solution that makes the most sense to me since a lot of encoders simply trust that ColorMatrix(hints=true) will produce the right result with all MPEG-2 sources.
HanSolo00 is offline   Reply With Quote
Old 19th March 2007, 18:45   #417  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
Quote:
Originally Posted by KillerZero View Post
Good solution would be to change Colormatrix to default to rec709 when resolution is HD.
That is not a good solution, because it doesn't follow the MPEG2 spec. HD means nothing; you can have interlaced HD: 1080i.

If ColorMatrix is keying off the progressive hint, I'd like to know why. Wilbert should explain whether it uses it and why.

I do know that it is not uncommon for streams to set the progressive_frame flag incorrectly.
Guest is offline   Reply With Quote
Old 19th March 2007, 18:55   #418  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
I just looked at the source code of ColorMatrix and it does not use the progressive hint. If you can point me to your stream that has a "problem" I will look at it and tell you exactly why the 709->601 conversion is being triggered (if in fact it is being triggered).

So, the ball is in your court to provide a sample stream.

Last edited by Guest; 19th March 2007 at 19:01.
Guest is offline   Reply With Quote
Old 19th March 2007, 19:00   #419  |  Link
KillerZero
Registered User
 
Join Date: Dec 2005
Posts: 26
Quote:
Originally Posted by neuron2 View Post
That is not a good solution, because it doesn't follow the MPEG2 spec. HD means nothing; you can have interlaced HD: 1080i.
What are you talking about? Yes you can have intelaced HD, but what it have to do with fact that HD always use Rec709 colors and when you play anything with HD resolution (even in PC) it will be played back with Rec709 matrix? Colorimetry and interlacing are two completly separate things.

Last edited by KillerZero; 19th March 2007 at 19:05.
KillerZero is offline   Reply With Quote
Old 19th March 2007, 19:13   #420  |  Link
Guest
Guest
 
Join Date: Jan 2002
Posts: 21,901
There is nothing in the MPEG2 spec that says an HD stream must use 709. That is my point. The reference to interlacing was due to Han's claims.

The conversion is being triggered simply because the stream reports 709 and ColorMatrix by default does 709->601 conversion.

If in practice HD streams always use 709, then I suppose it might make sense to change the default mode of ColorMatrix. I don't care about that. I see a potential for just a different form of user confusion, though.

I got involved only because people started saying DGMPGDec is doing something wrong and needs a fix.

Carry on, I'm outta here.
Guest is offline   Reply With Quote
Reply

Tags
colormatrix

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 20:49.


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