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. |
22nd March 2007, 17:14 | #443 | Link | |
ffdshow/AviSynth wrangler
Join Date: Feb 2003
Location: Austria
Posts: 2,441
|
Quote:
np: The Remote Viewer - Take Your Lights With You (Let Your Heart Draw A Line)
__________________
now playing: [artist] - [track] ([album]) |
|
22nd March 2007, 18:42 | #444 | Link |
Registered User
Join Date: Dec 2005
Posts: 26
|
VMR7 also uses correct values, only VMR9 uses wrong colors.
edit: and VMR7 renderless is also wrong, so only overlay and VMR7 windowed is correct. But why? Edit2: really strange, it seems that VMR9 selcts color mode randomly... Edit3: I got it, VMR7 renderless and both VMR9 modes render colors correctly only with resolution < 720 lines. For 720p or higher, they really expect PC scale. Maybe bug in drivers? I'll try upgrade to newest catalyst. Last edited by KillerZero; 22nd March 2007 at 19:03. |
23rd March 2007, 01:49 | #446 | Link | ||
Registered User
Join Date: May 2005
Posts: 236
|
Quote:
Quote:
|
||
23rd March 2007, 02:02 | #447 | Link |
Registered User
Join Date: Dec 2005
Posts: 26
|
For me, YV12 also results in 16 as black. There is no visible difference between RGB32 with HQ RGB conversion and YV12. What is your graphic card?
You definitely not using avisynth for encoding, only for decoding. And it is nothing contradicting to what I said - only what encoder can do is write colorimetry info to stream and all what decoder can do is to give colorimetry info to next filter if it's present in stream, but in encoding/decoding process itself is no slightest difference. It's only relevant for YV12<-->RGB conversion, so if we want it to be played properly ffdshow must be able to pass colorimetry info to graphic card. If not, default value is used, which is Rec601 for all resolutions below 720p. I'm not sure if you understand - if you have raw YV12 data there is no way how to tell which colorimetry is it. If you have no colorimetry info in stream, all you can do is just guess what looks more correct to you. Another question is if xvid writes colorimetry info to stream. Probably not, but at least MPEG2 playback could be correct. X264 has option to set colorimetry info. use X264.exe --longhelp Last edited by KillerZero; 23rd March 2007 at 02:32. |
23rd March 2007, 05:39 | #448 | Link |
ангел смерти
Join Date: Nov 2004
Location: Lost
Posts: 9,558
|
As I've said many times, it pretty much randomly changes based on your drivers. For a few driver versions it'll be "TV" levels, then it'll slide back to "PC" levels, fullrange conversion, sometimes only for some streams and not others. At least nvidia opened up a registry option that can be used to change the output levels, after being pestered, because some people actually use and prefer PC-levels, although I understand this stopped working or became unreliable last year. (I gave it up some time back.)
I'm surprised that anything changes for you when the size of the output reaches 720p. In my case, it's the same, with pretty recent cat, but an x1400 mobility. On the other hand I usually can't tell the difference between 601 and 709, so maybe it's just slipping by me. I've been putting up with it for two years, once I figured out what caused it, filing occasional support requests, and the flip-flopping in the drivers and the steady stream of posts by other people with the same problem have just grated on me. So I'm a little more annoyed at them than I should be. That's the reason I suspect that instead of honoring any colorometry flag, they will just use one and ignore the stream. As in your case, they pick one flag for SD and one flag for HD - that's simply wrong, hardly any better than forcing one all the time. Last edited by foxyshadis; 23rd March 2007 at 05:51. |
23rd March 2007, 12:46 | #449 | Link |
Registered User
Join Date: Feb 2006
Posts: 1,076
|
Regarding the YUv PC/TV-scale; I've got a H264 clip wich comes out PC scale after opening throught AVCSource().
Currently I'm using a AVS-script like this: Code:
AVCSource("bond.dga", deblocking=false).ConvertToYUY2() Trim(xxxxx,xxxxx) AssumeFPS(25,1,false) Spline16Resize(720,426) FFT3DGPU(...{bunch of options}...) AddBorders(0,74,0,76) 1) ColorYUV("PC->TV") just before the ConvertToYUY2() 2) ColorYUV("PC->TV") just before the FFT3DGPU ? 3) Doesnt matter sh*t, there wont be a difference What would you guys do ? PS: (G_M_C is trying hard to circumvent the "what's best" question ) |
23rd March 2007, 13:45 | #450 | Link |
Registered User
Join Date: Dec 2005
Posts: 26
|
1)How do you know it is PCscale? use script with just AVCSource and ColorYUV(analyze=true) and check loose min luma.
2) why are you converting it to YUY2? why don't you leave it in YV12? 3) Why fft3D? Denoising? 4) where can I get AVCsource plugin? Is it faster than DirectShowSource? 5) I don't know AVCSource and I cant google any relevant page, but if deblocking=false disables deblocking even if clip uses in-loop deblocking, this can lead to catastrophic results. I think there won't be any significant difference, but maybe would be better put it after FFT3D, so it will work with more colors. |
23rd March 2007, 14:10 | #451 | Link | ||||
Registered User
Join Date: Feb 2006
Posts: 1,076
|
Quote:
Quote:
Yes, to help compression + it is needed (using low sigma-values, after resizing from HD to SD). Quote:
http://forum.doom9.org/showthread.php?t=122598 No catastrophic results known, and it is not relevant in this case. In other words: I know what i'm doing, so above tips are known to me. Quote:
My hypothesis for option 1 was was because i do not know if luma getss "cut off" or otherwise broken when i use ConvertToYUY2() on PC-scale input. If the conversion wont give those problems, than i wanted to use option 2 because any rounding-off errors or other noise (if any) that comes with the conversion gets corrected, and rest of the script can use the as much luma/chroma information i can give it (The FFT is needed anyway). In the end i want to lose as less color/luma info as possible before giving it to CCE. In other words: The higher the quality the better (=Didee-like encoding quality-standards ) Last edited by G_M_C; 23rd March 2007 at 14:30. |
||||
23rd March 2007, 16:23 | #452 | Link |
Registered User
Join Date: Dec 2005
Posts: 26
|
1) its strange, as it must look very dark in every player, that is why I'm asking.
ConverttoYUV2 just upsamples chroma, so it shouldn't cut off anything. Nearly every filtering works best if it has highest bitdepth possible, i dont know why should be fft3D different. Thx for link, but I still think that turning deblocking off is bad idea, though it may work on some streams. It's definitely not worth speed gain. |
23rd March 2007, 17:37 | #453 | Link | |
Registered User
Join Date: Feb 2006
Posts: 1,076
|
Quote:
But thx for the help, i think i'll use option 1) |
|
24th March 2007, 02:02 | #454 | Link | ||
Registered User
Join Date: May 2005
Posts: 236
|
X1600pro, using catalyst 06.8, media player classic output VRM9 renderless. Using the default / overlay renderer I do get yv12 displayed with the 0-255 scale, it's in VRM9 (that I want to use) that it is kept at 16-235 if ffdshow outputs yv12, but converted to 0-255 if ffdshow outputs rgb.
Quote:
Quote:
Last edited by Alain2; 24th March 2007 at 02:04. |
||
24th March 2007, 13:41 | #455 | Link |
Registered User
Join Date: Dec 2005
Posts: 26
|
Strange, I have 9600XT and it uses 16-235 --> 0-255 RGB even with VMR9 renderles, if video isn't higher than 720 lines...
I don't know about XVID, but X264 leaves it undefined by default. I bet that xvid does the same, Rec601 is just default for SD video, so it is chosen by graphic driver if it's not specified. Last edited by KillerZero; 24th March 2007 at 21:51. |
27th March 2007, 03:50 | #456 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
I've made a new version that fixes the source==dest error when using d2v or hints, and that removes the 'scaling' parameter and replaces it with a boolean 'clamp' parameter (true will use limiter before and after, false wont). I read through the last 4 pages and I'm not sure whether anyone wanted the default for dest/mode to change to Rec.709 when the input has HD res? If so speak up, or if there are other changes wanted speak up also... otherwise I am just going to leave everything else as is.
|
27th March 2007, 06:43 | #457 | Link | |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
Quote:
Having behaviour change depending on image dimensions is poor. Besides where do you set the threshold, H>576, W>720, H>=720, W>=1280, half way between, .... If it is an issue that require fundamental thought then it probably should not have a default, i.e. the parameter must always be specified. |
|
13th April 2007, 07:27 | #458 | Link |
Registered User
Join Date: Apr 2005
Location: Krakow, Poland
Posts: 141
|
To clarify some things about yuv->rgb conversion whn using VMR9 on ATI.
This is really up to drivers how this color conversion is done. Decoder has nothing to tell here unless he outputs rgb data. Now ATI drivers uses two color matrixes depending on resolution of incoming image, if images has 720 lines or more then hd matrix is used, otherwise sd matrix. You can see comparision how it looks like here: http://forum.doom9.org/showthread.ph...268#post988268 It looks very similar between ffdshow's yuv->rgb conversion and ati's vmr9 sd color matrix but difference to vmr9 hd matrix is bigger. It would be great that decoders would pass color information to VMR9 using mentioned DXVA_ExtendedFormat but it is unknown how it is supported in drivers. As far as I see decoders have this information from stream. At least from version 7.3 of drivers ATI started to extend all yuv inputs into PC scale. I don't know how it looks like on nvidia cards. |
14th April 2007, 03:38 | #459 | Link | |
Registered User
Join Date: Oct 2006
Location: Gotham City, USA
Posts: 389
|
Sorry to drag down the level of the discourse, but I've got a noobie question...
Ok, so I started inserting ColorMatrix into my AVS files... I'm working on some TV episode DVDs, so this is my syntax: Quote:
Or should I just assume that fixes something, and use it for all of my .d2v content? Thanks for any advice. |
|
14th April 2007, 04:33 | #460 | Link |
Fighting spam with a fish
Join Date: Sep 2005
Posts: 2,699
|
Maybe your original video was already rec.601, although it is doubtful. Also, depending on the size of your preview in AvsP, it may be hard to tell the difference. I usually can see the difference if I load the avs file into MPC and play it at fullscreen. Just look for parts of the video that should be black and compare them to the borders that are automatically inserted by MPC, if they are the same level of black, then it worked correctly, if not, you have some more work ahead of you.
|
Tags |
colormatrix |
Thread Tools | Search this Thread |
Display Modes | |
|
|