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 22nd March 2007, 12:35   #441  |  Link
Leak
ffdshow/AviSynth wrangler
 
Leak's Avatar
 
Join Date: Feb 2003
Location: Austria
Posts: 2,441
Quote:
Originally Posted by KillerZero View Post
What do you mean by inconsistent luma? I really have no idea what should I imagine. And I think that current colorimetry behavior is quite correct.
I guess she meant that whole "TV levels" vs. "PC levels" brouhaha...
__________________
now playing: [artist] - [track] ([album])
Leak is offline   Reply With Quote
Old 22nd March 2007, 16:28   #442  |  Link
KillerZero
Registered User
 
Join Date: Dec 2005
Posts: 26
What TV/PC level has to do with graphic driver? It always expect luma to start with 16 as black and end with 235 as white. Never did other way. What is inconsistent on that?
AFAIK, PC levels are used only in JPEGs.
KillerZero is offline   Reply With Quote
Old 22nd March 2007, 17:14   #443  |  Link
Leak
ffdshow/AviSynth wrangler
 
Leak's Avatar
 
Join Date: Feb 2003
Location: Austria
Posts: 2,441
Quote:
Originally Posted by KillerZero View Post
What TV/PC level has to do with graphic driver? It always expect luma to start with 16 as black and end with 235 as white. Never did other way. What is inconsistent on that?
IIRC Overlay Mixer uses one and VMR7/9 uses the other, thus making both look different...

np: The Remote Viewer - Take Your Lights With You (Let Your Heart Draw A Line)
__________________
now playing: [artist] - [track] ([album])
Leak is offline   Reply With Quote
Old 22nd March 2007, 18:42   #444  |  Link
KillerZero
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.
KillerZero is offline   Reply With Quote
Old 22nd March 2007, 19:33   #445  |  Link
KillerZero
Registered User
 
Join Date: Dec 2005
Posts: 26
It should be possible to set color matrix:

http://msdn2.microsoft.com/en-us/library/ms796493.aspx

Last edited by KillerZero; 22nd March 2007 at 19:35.
KillerZero is offline   Reply With Quote
Old 23rd March 2007, 01:49   #446  |  Link
Alain2
Registered User
 
Join Date: May 2005
Posts: 236
Quote:
Originally Posted by KillerZero View Post
Alain2: I meant that there is no difference in encoding/decoding process. All can encoder do is to write given colorimetry info and decoder read it and give it to YV12/RGB convertor.
I am not sure of that.. I always use avisynth for encoding, and I really doubt that avisynth is keeping a colorimetry flag throughout the filters process, therefore to me the colorimetry flag is reset by the encoder used. That's why I said earlier that xvid/x264 were rec601 and CCE rec709, and that the source had to be dealt with accordingly... maybe avisynth devs can confirm / disapprove what I just said ?

Quote:
Originally Posted by KillerZero View Post
Also, I don't understand what do you mean with that.
I don't know why should I use ffdshow's RGB conversion, if there is no difference from HW and it is much slower. +RGB output works correctly only to 960xsomething resolution.
Quote:
Originally Posted by KillerZero View Post
What TV/PC level has to do with graphic driver? It always expect luma to start with 16 as black and end with 235 as white. Never did other way. What is inconsistent on that?
AFAIK, PC levels are used only in JPEGs.
Like Foxyshadis, I personnally disabled yv12 output in ffdshow and only enabled rgb32, with the yv12>rgb hq conversion option enabled. This is to get the full PC scale as I do want 0-255 on my lcd screen. Usual DVD software players / AvsP preview / vdub scale 16-235 over 0-255 (histogram("levels") indicate values in 16-235, whereas it is clearly displayed in 0-255 as black is true black), so I think it is what most people want on their computer... Only ffdshow yv12 output keep the output level to 16-235
Alain2 is offline   Reply With Quote
Old 23rd March 2007, 02:02   #447  |  Link
KillerZero
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.
KillerZero is offline   Reply With Quote
Old 23rd March 2007, 05:39   #448  |  Link
foxyshadis
ангел смерти
 
foxyshadis's Avatar
 
Join Date: Nov 2004
Location: Lost
Posts: 9,175
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.
__________________
There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. ~ Ed Howdershelt

Last edited by foxyshadis; 23rd March 2007 at 05:51.
foxyshadis is offline   Reply With Quote
Old 23rd March 2007, 12:46   #449  |  Link
G_M_C
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)
Would you guys do the ...
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 )
G_M_C is offline   Reply With Quote
Old 23rd March 2007, 13:45   #450  |  Link
KillerZero
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.
KillerZero is offline   Reply With Quote
Old 23rd March 2007, 14:10   #451  |  Link
G_M_C
Registered User
 
Join Date: Feb 2006
Posts: 1,076
Quote:
Originally Posted by KillerZero View Post
1)How do you know it is PCscale? use script with just AVCSource and ColorYUV(analyze=true) and check loose min luma.
Did that, and thats how i know.

Quote:
Originally Posted by KillerZero View Post
1)2) why are you converting it to YUY2? why don't you leave it in YV12?
Converting to MPEG2 using CCE (to be precise: Replace the crappy PQ of the video-track of one of my backups with a new and better one)

Quote:
Originally Posted by KillerZero View Post
1)3) Why fft3D? Denoising ?
Yes, to help compression + it is needed (using low sigma-values, after resizing from HD to SD).

Quote:
Originally Posted by KillerZero View Post
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.
Read all about it on doom9's forum, only not here but here:
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:
Originally Posted by KillerZero View Post
1)4)
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.
Thx for this answer; But how do you think it works best on more colors ?

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.
G_M_C is offline   Reply With Quote
Old 23rd March 2007, 16:23   #452  |  Link
KillerZero
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.
KillerZero is offline   Reply With Quote
Old 23rd March 2007, 17:37   #453  |  Link
G_M_C
Registered User
 
Join Date: Feb 2006
Posts: 1,076
Quote:
Originally Posted by KillerZero View Post
1) its strange, as it must look very dark in every player, that is why I'm asking.
Yes actually it does, thats when i discovered it (assumed that it would be TV scale on my first try). Dark tones are way to dark, and light tones are "overshined". The whole image looked like I turned up contrast to the max on my TV.

But thx for the help, i think i'll use option 1)

G_M_C is offline   Reply With Quote
Old 24th March 2007, 02:02   #454  |  Link
Alain2
Registered User
 
Join Date: May 2005
Posts: 236
Quote:
Originally Posted by KillerZero View Post
What is your graphic card?
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:
Originally Posted by KillerZero View Post
You definitely not using avisynth for encoding, only for decoding.
Yes ok, was tlaking fast. I use avisynth to pre-process my input (read by dgdecode for instance) with filters and send the resulting raw yv12 to the encoder (lagarith first, then x264).
Quote:
Originally Posted by KillerZero View Post
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.
Ok, I see your point, but still, my input is being processed by avisynth filters before being sent to the encoder, and I very much doubt that you would get a colorimetry info in the raw yv12 output of avisynth. Thus if you have a yv12 with no colorimetry sent to the encoder, ok you say it encodes it, and maybe add a colorimetry flag as well for the driver that will convert to rgb. That is this colorimetry flag I was thinking about: aren't xvid and x264 supposed to add by default rec601 flag whereas CCE is choosing rec709 be default ? In any case, you have to treat your yv12 stream according to this colorimetry flag of the encoder, meaning if it's not the same than your initial source, then a convertion as per colormatrix is necessary...

Last edited by Alain2; 24th March 2007 at 02:04.
Alain2 is offline   Reply With Quote
Old 24th March 2007, 13:41   #455  |  Link
KillerZero
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.
KillerZero is offline   Reply With Quote
Old 27th March 2007, 03:50   #456  |  Link
tritical
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.
tritical is offline   Reply With Quote
Old 27th March 2007, 06:43   #457  |  Link
IanB
Avisynth Developer
 
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,168
Quote:
...default for dest/mode to change to Rec.709 when the input has HD res?
I think that might be a bad idea.

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.
IanB is offline   Reply With Quote
Old 13th April 2007, 07:27   #458  |  Link
wozio
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.
wozio is offline   Reply With Quote
Old 14th April 2007, 03:38   #459  |  Link
Dr.Khron
Registered User
 
Dr.Khron's Avatar
 
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:
DGDecode_mpeg2source("D:\Ripping\S03E01.d2v", info=3)
ColorMatrix(hints=true, interlaced=true)
When I preview the file in AvsP, I see no difference at all when I add and remove the ColorMatrix line. From what I've gathered from reading this thread, this has to do with how I've got my FFDshow setup (I'm running a recent install of the CCCP). What can I do to change my FFDshow settings so that I can properly preview the changes that ColorMatrix makes to my AVS output?

Or should I just assume that fixes something, and use it for all of my .d2v content?

Thanks for any advice.
Dr.Khron is offline   Reply With Quote
Old 14th April 2007, 04:33   #460  |  Link
Adub
Fighting spam with a fish
 
Adub's Avatar
 
Join Date: Sep 2005
Posts: 2,685
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.
__________________
FAQs:Bond's AVC/H.264 FAQ
Site:Adubvideo
Adub 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 13:32.


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