ffdshow tryouts project: Discussion & Development

[leeperry]

the only thing I am convinced about is that rec709 and sRGB are one and the same.
indeed, but don't mix the Rec.709 decoding matrix, and the Rec.709 gamut...these are 2 separate things. we usually call the Rec.709 gamut HDTV or sRGB to avoid confusion.
And that we need to find a way to simulate CRT on full-range displays when converting to RGB.
only a 3D LUT gamut conversion can do that, and you have to use the actual display primaries coordinates...no generic stuff can work here.
I'm trying to find a solution for my problem which is:
Ati videocard with DVI to HDMI cable connected to a limited range full-hd tv that is calibrated for 709/sRGB 16-235 D65
I need accurate desktop 0-255 and accurate video 16-235 without the need to change any settings when I switch.
so your display offers the proper options to move the primaries/secondaries coordinates ? if so, it's really spot-on the HDTV gamut ?
because windows will only output 0-255 no matter what, your only option is to convert your movies from TV to PC range, and revert to TV range in your display OSD by setting the brightness to +16 and the contrast to -17....provided that it works internally in 10 or 12 bits, that shouldn't create any additional banding :cool:

you can use this test pattern to check for banding :

http://pix.nofrag.com/3/b/a/110906e5911ab646a62a0477330b6t.jpg (http://pix.nofrag.com/3/b/a/110906e5911ab646a62a0477330b6.html)

sunsets photos also work fine.

alternatively, you could use a hdmi/hdmi cable + ATi dvi adapter, and select limited RGB output....but god knowns if it works in 10 bits :D

[clsid]

Just tried it and ffdshow works fine here for decoding Xvid video in Media Player Classic. Only if I disable it in ffdshow, the MS MPEG-4 DMO decoder gets used.

The H.264 decoder in Win7 seems to be usable only with WMP because it uses Windows Media Foundation (WMF).

[Dark Eiri]

Just tried it and you're right, works with MPC flawlessly, but any other players are being forced to use MS codecs.
I'll just stick with MPC then! Thank you clsid!

[yesgrey]

Thanks everybody, I've learned a new thing today.
Current dialog is designed to select the type of input material.
I think we need separate option to select the type of user's display, right?
I don't think so. I have also considered that idea, but it will give some possible combinations which doesn't make sense, like converting Y:0-255 to RGB:16-235.
I think the current dialog is correct, and has everything, but it's not very intuitive, because it mimics how the conversion is mathematically performed.
The Y:16-235, UV:16-240, RGB:16-235, RGB:0-255, are not limits, are just correlation points, nothing more.
And since with YUV the correlation points are always Y: 16-235, UV: 16-240, I think that's how it should appear.
I know it may looks a bit strange, but this is my suggestion for the dialog.
Reference Black and Reference White
* PC (Y: 16 -> RGB: 0,0,0; Y: 235 -> RGB: 255,255,255)
* Video (Y: 16 -> RGB: 16,16,16; Y: 235 -> RGB: 235,235,235)
* Custom (Y: 16 -> RGB: ?,?,?; Y: 235 -> RGB: ?,?,?)
The chroma cut-off slider and the interlock chroma button should be removed. The chroma should be always interlocked internally with Y.


How else do you explain that some displays can be switched between two different RGB "interpretations".
My previous post had one error. I already corrected it. The real problem is the gamma curve. When a display switch between two modes what it's doing is just changing the gamma curve to apply to the values. Think of it, if your display gamma curve is 2.22 starting at RGB[0,0,0] and ending at RGB[255,255,255] how do you think it will look when you feed it a signal with black at RGB[16,16,16]? Washed out.;)

Are you serious? Do you really expect me to recalibrate my LCD computer monitor every time I switch between doing internet browsing and watching videos!? I'm sorry, but this is just crazy from a usability point of view!! And besides: I can't lower brightness on my LCD computer monitor far enough to hide BTB.

Of course I am not expecting you to recalibrate your LCD computer monitor. It's enough correcting the gamma of the output signal. The conversion of video to PC levels is only a workaround. I know it gives good results, that's why I also use it sometimes, but I am trying to make it working in the correct way: correcting the gamma.

This is a new problem we are facing. Several years ago, we watch each thing in it's own display. PAL Video in a PAL TV, NTSC Video in a NTSC TV, Computer stuff in a computer monitor, etc. Now, with the advances in computer technology, we are able to watch everything in the same display. If everything was in the same format, it would be ok, but it's not. So, we need to find a way to convert our single display in a multiformat display. This is possible with ICC profiling, but unfortunatelly it has to be supported at the applications level, and is not. Only some professional image processing applications do it.
To overcome all this, I suggested a solution in 2007, and, with the cooperation of JohnAd and other people, we have created a PS to use with mpc-hc (it has pixel shader support). More recently, tritical with it's ddcc and rgb3dlut avisynth functions also allows it.
We are still working on it, but the idea would be: knowing the source format, convert from YUV->RGB, remove the gamma accordingly with the source format, correct the primaries, reapply gamma accordingly with your display, and that's it. Since all this operations would be done with a 3D LUT, it should be very fast, and is just creating in ffdshow the possibility of selecting the 3D LUT you should use accordingly with the source format. You have to calculate all 3D LUTs you would need accordingly with your displays, but that is done only one time.

However, the cost of this is that you lose any DXVA hardware acceleration.
Well, you should be able to use ffdshow with CoreAVC CUDA, which will give us hardware acceleration...

I'm trying to find a solution for my problem which is:
Ati videocard with DVI to HDMI cabld connected to a limited range full-hd tv that is calibrated for 709/sRGB 16-235 D65
I need accurate desktop 0-255 and accurate video 16-235 without the need to change any settings when I switch
I see no solution to your problem. Your display will always clip the <16 and >235 of your desktop.

[Jong]

I'm trying to find a solution for my problem which is:
Ati videocard with DVI to HDMI cabld connected to a limited range full-hd tv that is calibrated for 709/sRGB 16-235 D65
I need accurate desktop 0-255 and accurate video 16-235 without the need to change any settings when I switchSorry, I have looked for your original post on this problem and did not find it. What exactly are you looking for? If you have a limited range display why do you want the desktop displayed @0-255 as all photos will suffer from serious black crush? The ATI drivers do a good job here now. Tell them you want limited RGB output and you get video @16-235 and desktop compressed to 16-235 so both look right and no need to recalibrate. You do lose BTB/WTW from the video but since this happens post all processing it does not have a noticeable impact on video quality.

[dandy]

@clsid

I have a problem with your latest icl10 build rev 2608
changing presets in VFW-Interface brings up XP's "Data Exception Prevention - Run a DLL as an App"
other builds didn't have this

thanks

[turbojet]

For anyone/all involved in ffdshow-mt development, thanks for the fix in build 2600. It fixed the issue I was having with a 480i avc clip and 1080i mpeg2 clip.

[leeperry]

The ATI drivers do a good job here now. Tell them you want limited RGB output and you get video @16-235 and desktop compressed to 16-235 so both look right and no need to recalibrate.
the "pixel format" selection in the ATi drivers only works if you have a hdmi/hdmi cable with their dongle, no soup for you if you got a dvi/hdmi cable...they prolly assume that your display is PC range :rolleyes:

[tetsuo55]

SNIP!!

Thats exactly what i was thinking but a lot better explained


the "pixel format" selection in the ATi drivers only works if you have a hdmi/hdmi cable with their dongle, no soup for you if you got a dvi/hdmi cable...they prolly assume that your display is PC range :rolleyes:


Maybe its just a register setting.
If someone with the dongle could find the key all dvi-hdmi users could have the setting

[leeperry]

Maybe its just a register setting.
If someone with the dongle could find the key all dvi-hdmi users could have the setting
no it's a "feature" :D
so ppl with DVI PC displays don't mess with it.

at this point, your only option is to output PC levels and revert to TV in your display :o

my nvidia card lets me select either YUY2 or RGB for the output, but not TV/PC range(except for software video renderers, but I use HR anyhow)

[netwolf]

What do you think about my earlier suggestion to define output levels separately for both monitors? That would allow ffdshow to automatically adjust RGB output type, depending on which monitor the media player is currently running... This is surely not *necessary*, but it would save me from switching the "output levels" option all the time, since I usually watch shorter video clips on monitor 1 (computer type LCD display) and full movies usually on monitor 2 (plasma TV). But as I said, this is not really necessary, it would just be the icing on the cake...
That would indeed be very much appreciated!
Like many other people, I also watch short clips on my LCD laptop display, while longer movies are being watched on my Plasma-TV.
So an option to output PC levels on the (primary) PC display and TV levels on the (secondary) TV display would be great :)

Also I think the most important part of the conversion settings page will be the "Auto" part, as the whole RGB conversion topic is something that only
a very small percentage of ffdshow users actually know enough about to make the right decisions manually.

Just look at the last 3 pages of this thread and count the various confusions, even among experts in this area ;)

[Inventive Software]

@clsid: downloaded what i thought was 2609, turns out to be ffdshow-mt, and the kerneldeint dll for that now works! About 323KB and smooth as a baby's bottom! Would suggest using that one for future builds. ;)

[clsid]

@clsid

I have a problem with your latest icl10 build rev 2608
changing presets in VFW-Interface brings up XP's "Data Exception Prevention - Run a DLL as an App"
other builds didn't have this

thanks
Well, I have no idea how to fix that.

Did you change the DEP settings to AlwaysOn? If so, change it back to Optin.

[Jong]

Maybe its just a register setting.
If someone with the dongle could find the key all dvi-hdmi users could have the settingI did that here (http://www.avsforum.com/avs-vb/showthread.php?p=15138209#post15138209), but never got any feedback.

[yesgrey]

What do you think about my earlier suggestion to define output levels separately for both monitors? That would allow ffdshow to automatically adjust RGB output type, depending on which monitor the media player is currently running... This is surely not *necessary*, but it would save me from switching the "output levels" option all the time, since I usually watch shorter video clips on monitor 1 (computer type LCD display) and full movies usually on monitor 2 (plasma TV). But as I said, this is not really necessary, it would just be the icing on the cake...
Like many other people, I also watch short clips on my LCD laptop display, while longer movies are being watched on my Plasma-TV.
So an option to output PC levels on the (primary) PC display and TV levels on the (secondary) TV display would be great :)
My suggestion of adding the screen resolution to the presets autoload condition should solve this, or are you using the same resolution in both displays?... I don't.

[netwolf]

I just can speak for myself, but I do not have to same resolution on both displays.
So for me it wouldn't make a difference if there is a "Display 1 / Display 2" setting or a "Resolution x / Resolution y" kind of setting,
I just have never used presets so far.

Talking about resolutions (slightly off topic): my desktop is 1280 x 800, my Plasma TV has a native reoslution of 1024 x 720, but as the Catalyst driver doesn't offer this I
feed it with 1280 x 768.
The TV is running in Extended mode with Theatre mode set to fullscreen, so I can have a small player window on the desktop while the movie is shown
in fullscreen on the TV.

Do know how I can achieve that movies have the correct AR on both displays?
I use ZoomPlayer with AR set to Derived. I played a little with the "Source relative stretch" option of ZP, but the results are still far from great,
and also 4:3 material is always stretched to fill the TV screen, no borders right and left as on the desktop.
Any help greatly appreciated.

[bur]

Sorry if this was answered before, but I couldn't find anything useful using the search...

I saw there is now an experimental mt build and read it makes all decoders multithreaded. I don't have issues with skipped frames with any videos besides some high-res H264, so that's where I'd need some more CPU power. But I think I remember that the h264 decoder of ffdshow already uses 2 cores, even in the non-mt builds.

So in that case will it do me any good to use the mt builds? The reason I'm asking is that they might be a little buggy or so I heard and if the common ffdshow h264 decoder is just as fast on a 2-core-system as the mt one, I needn't bother with the experimental builds.

[jmartinr]

Do know how I can achieve that movies have the correct AR on both displays?
I use ZoomPlayer with AR set to Derived. I played a little with the "Source relative stretch" option of ZP, but the results are still far from great,
and also 4:3 material is always stretched to fill the TV screen, no borders right and left as on the desktop.
Use ffdshow to resize everything to your TV's resolution (or AR). See
http://www.jillesvangurp.com/2006/11/06/nvidia-tv-out-aspect-ratio-trouble-workaround/#comment-19816 for an explanation.

[madshi]

I don't think so. I have also considered that idea, but it will give some possible combinations which doesn't make sense, like converting Y:0-255 to RGB:16-235.
Why does it not make sense? If my plasma is calibrated to get RGB black at 16 and if I want to play a FRAPS video, then isn't converting Y:0-255 to RGB:16-235 exactly what I need?

I think the current dialog is correct, and has everything, but it's not very intuitive, because it mimics how the conversion is mathematically performed.
The Y:16-235, UV:16-240, RGB:16-235, RGB:0-255, are not limits, are just correlation points, nothing more.
And since with YUV the correlation points are always Y: 16-235, UV: 16-240, I think that's how it should appear.
I know it may looks a bit strange, but this is my suggestion for the dialog.
Reference Black and Reference White
* PC (Y: 16 -> RGB: 0,0,0; Y: 235 -> RGB: 255,255,255)
* Video (Y: 16 -> RGB: 16,16,16; Y: 235 -> RGB: 235,235,235)
* Custom (Y: 16 -> RGB: ?,?,?; Y: 235 -> RGB: ?,?,?)

That would be alright with me, but I would suggest using "output levels" instead of "reference black/white", because that's the term used by other DirectShow filters, too. And I'd suggest changing the description slightly. E.g. for "PC" I'd write: "Y: 16-256 -> RGB: 0-255". That's basically the same thing, but much shorter and IMHO easier to read/understand.

I'm still not sure why you argue against having "input levels" and "output levels" controls? Ok, by far most content is "Y: 16-256". And the rare content which is "Y: 0-255" could eventually be auto detected (and converted to "Y: 16-235") by looking at the codec. Is that your line of reasoning? If so, then I'm fine with that.

[yesgrey]

my Plasma TV has a native resolution of 1024 x 720, but as the Catalyst driver doesn't offer this I
feed it with 1280 x 768.
Can't you create custom resolutions with Catalyst driver? I think that when I had an ATI card that was possible... if not, try using powerstrip to create a resolution that match your plasma TV.

Why does it not make sense? If my plasma is calibrated to get RGB black at 16 and if I want to play a FRAPS video, then isn't converting Y:0-255 to RGB:16-235 exactly what I need?
No. For a FRAPS video with that display you should use Y:16-235 to RGB:16-235
Note that PC and Video black and white reference values are only different in RGB. In YUV, the Black is always at 16 and the White at 235.
If FRAPS is encoding RGB:0 at Y:0 and RGB:255 at Y:255, then it's going against the standards.

That would be alright with me, but I would suggest using "output levels" instead of "reference black/white", because that's the term used by other DirectShow filters, too. And I'd suggest changing the description slightly. E.g. for "PC" I'd write: "Y: 16-256 -> RGB: 0-255".
I know "output levels" and that kind of description is more used, but it's misleading, because would make people think that only the values inside will be used, and that's not the case.
As I said, IMHO The Black and White points are just correlation points between YUV and RGB to create a conversion matrix. Then, all YUV values from 1 to 254 could be used if we want (by the way, I referred Y:0-255, which is wrong. The values 0 and 255 are reserved values, never used).
This way would be a little shorter...
Reference Black/White
* PC (Y:16->RGB:0; Y:235->RGB:255)
* Video (Y:16->RGB:16; Y:235->RGB:235)
* Custom (Y:16->RGB:?; Y:235->RGB:?)

I'm still not sure why you argue against having "input levels" and "output levels" controls?
I think they are not levels, but correlation points, and the input correlation points are always defined as Y:16 and Y:235. So, we should avoid the confusion of thinking that other Y correlation points are allowed...

[jackiehcs]

Excuse me, I would like to make a suggestion, wondering if anyone has brought up it before.

I use the resizer integrated in ffdshow to resize my videos' resolution to the screen resolution while playing them

That way, I could always watch them in a full screen with a more satisfied quality.

However, I've found that there are potential improvement of setting options available in the resizer filter.

While I appreciate the option of "Specify horizontal size", I think it is a good idea to add a option of "Specify vertical size".

Taking my laptop as an example, it has a 16:10 screen with resolution of 1680x1050, so I have to set 1680 as the horizontal size in order to get videos' resolution resized to fit the full screen without broaders -- as the graphic driver would always add necessary broaders to the videos to maintain the correct aspect ratios.

So now, problems come when the videos with aspect ratios lower than 16:10 are being played. Since I've specified the horizontal size as 1680, videos, say with a aspect ratio of 4:3, are resized to 1680x1260, which exceeds both dimensions of my screen resolution and causes unnecessary quality reduction provided that I am watching them in the full screen mode.

In fact, I could use "Resize to screen resolution" to solve the over-resizing-problem, but it leads to another problem which is broaders are added automatically to maintain the aspect ratio.

I would definitely prefer resizing without adding broaders, which leads to the problem of subtitling at wrong positions, while fitting the screen resolution well by making videos' resolution meeting either size of dimensions while not making the other dimension exceeding the screen's one.

In conclusion, I suggest adding an option of "Specify vertical size" as mentioned above and another option of "Resize to screen resolution without adding broaders" which may be achieved by automatically specifying either the horizontal size or the vertical size depending on the video's aspect ratio (with PAR processing done) as well as the screen's aspect ratio.

Thank you for your kind attention, and sorry for any confusion and mistakes.

[Jeff Flowerday]

jackeihcs: Couldn't you just handle your situation with different ffdshow profiles that are driven by the source video size?

[jackiehcs]

jackeihcs: Couldn't you just handle your situation with different ffdshow profiles that are driven by the source video size?

I could if there was an option to specify the vertical size. Then, I would be able to have either the horizontal size specified when the video was >=16:10 or the vertical size specified when the video was <16:10, automatically by having set up two profiles.

Actually, I think there are some ways to make it with an avs written in ffdshow; however, I more appreciate it if ffdshow itself provides such options.

[tetsuox]

So in that case will it do me any good to use the mt builds? The reason I'm asking is that they might be a little buggy or so I heard and if the common ffdshow h264 decoder is just as fast on a 2-core-system as the mt one, I needn't bother with the experimental builds.

There's certainly no harm in trying the MT builds. If you have problems with it, you can always install the vanilla version over it without any problems. Even though they're labeled 'experimental' they are all quite stable.

[madshi]

I think they are not levels, but correlation points, and the input correlation points are always defined as Y:16 and Y:235. So, we should avoid the confusion of thinking that other Y correlation points are allowed...
Ok. But then why list "Y:16" and "Y:235" in the control labels at all, if they are always the same, anyway?

No. For a FRAPS video with that display you should use Y:16-235 to RGB:16-235
Note that PC and Video black and white reference values are only different in RGB. In YUV, the Black is always at 16 and the White at 235.
If FRAPS is encoding RGB:0 at Y:0 and RGB:255 at Y:255, then it's going against the standards.
As far as I understand, FRAPS is encoding black at Y:0. This may be against the standard. If so, that's one reason more not to interpret the current ffdshow "contrast" section as defining the *input* format, if the input should always have black at Y:16, anyway.

I know "output levels" and that kind of description is more used, but it's misleading, because would make people think that only the values inside will be used, and that's not the case.
As I said, IMHO The Black and White points are just correlation points between YUV and RGB to create a conversion matrix. Then, all YUV values from 1 to 254 could be used if we want (by the way, I referred Y:0-255, which is wrong. The values 0 and 255 are reserved values, never used).
This way would be a little shorter...
Reference Black/White
* PC (Y:16->RGB:0; Y:235->RGB:255)
* Video (Y:16->RGB:16; Y:235->RGB:235)
* Custom (Y:16->RGB:?; Y:235->RGB:?)

I understand that you want to have it labeled scientifically correct. But I think it's more important to make the controls as user friendly and easy to understand as possible, because after all that's what a GUI is supposed to be like. The scientifical correctness should be done by the code in the background. So what would the average ffdshow user understand better? Let me list some variations:

=====================================

POLL


(1) yesgrey3 suggestion

Reference Black/White
* PC (Y:16->RGB:0; Y:235->RGB:255)
* Video (Y:16->RGB:16; Y:235->RGB:235)
* Custom (Y:16->RGB:?; Y:235->RGB:?)

(2) similar to CoreAVC and Haali Renderer

output levels
* TV (RGB: 16-235)
* PC (RGB: 0-255)
* Custom

(3) used by some experts, also e.g. by Sony Vegas

RGB format
* Studio RGB (16-235)
* Computer RGB (0-255)
* Custom

(4) similar to DVD players, Xbox360 and PS3

RGB format
* Standard RGB (16-235)
* Extended RGB (0-255)
* Custom

(5) maybe the easiest to understand for dummies/newbies?

monitor type
* Computer Monitor (RGB: 0-255)
* TV / Projector (RGB: 16-235)
* Custom


Please everyone name your favorite!

[bur]

There's certainly no harm in trying the MT builds. If you have problems with it, you can always install the vanilla version over it without any problems. Even though they're labeled 'experimental' they are all quite stable.Okay, thanks. Then I'll install one of those builds.

Does anyone know though if they offer any advantage in regard to h264 deocoding on 2-core-systems?


editI just read you are discussing what description to use for YV->RGB conversion in a GUI. Maybe you want some end-user input... :) I'd like a GUI best were proper descriptions are used, but along with a easy to understand description. For example:

Reference Black/White
* PC (Use this if playing on computer monitor - RGB: 16-235)
* Video (Use this if playing on your TV - RGB: 0-255)
* Custom

That way someone who really understands what's happening knows what references you use (0/16 and 235/255) but also someone who has no idea of YV/RGB knows what option to choose.

On the other hand it all depends on towards which kind of users your GUI is directed. If it's meant to be used by semi-professionals you can leave out the "use this if..." part, ff it's specifically designed as an easy-to-use newbie software you definitely need those.

[Mark_A_W]

POLL


(1) yesgrey3 suggestion

Reference Black/White
* PC (Y:16->RGB:0; Y:235->RGB:255)
* Video (Y:16->RGB:16; Y:235->RGB:235)
* Custom (Y:16->RGB:?; Y:235->RGB:?)

(2) similar to CoreAVC and Haali Renderer

output levels
* TV (RGB: 16-235)
* PC (RGB: 0-255)
* Custom

(3) used by some experts, also e.g. by Sony Vegas

RGB format
* Studio RGB (16-235)
* Computer RGB (0-255)
* Custom

(4) similar to DVD players, Xbox360 and PS3

RGB format
* Standard RGB (16-235)
* Extended RGB (0-255)
* Custom

(5) maybe the easiest to understand for dummies/newbies?

monitor type
* Computer Monitor (RGB: 0-255)
* TV / Projector (RGB: 16-235)
* Custom


Please everyone name your favorite!

POLL




(6) Mark's suggestion

Reference Black/White
* Levels Expanded (Multi-use PC monitor, WTB/BTB cropped) (Y:16->RGB:0; Y:235->RGB:255)
* Levels Retained (Dedicated Video display, WTW/BTB retained) (Y:16->RGB:16; Y:235->RGB:235)
* Custom (Y:16->RGB:?; Y:235->RGB:?)


I find the Haali and CoreAVC names completely counter-intuitive.

I watch on a dedicated projector, and I want my levels retained, black at 16 and white at 235. Yet I pick "PC" for my RGB conversion level to get the right result. It's just WRONG.

[madshi]

I find the Haali and CoreAVC names completely counter-intuitive.

I watch on a dedicated projector, and I want my levels retained, black at 16 and white at 235. Yet I pick "PC" for my RGB conversion level to get the right result. It's just WRONG.
FWIW, Haali interprets his controls as "input" controls, not "output" controls. That's why it's exactly backwards in the Haali Renderer. The CoreAVC controls work correctly, though, I think.

[tetsuox]

Does anyone know though if they offer any advantage in regard to h264 decocoding on 2-core-systems?

Yes, the MT versions are faster. There are already some benchmarks done by forum members. :search: You can also do it yourself using Haali's timecodec.exe It's in the FAQ (http://ffdshow-tryout.wiki.sourceforge.net/FAQ)

Could someone add a link to the FAQ to ffdshow-tryout's sf.net homepage?

[tetsuo55]

There should not be any cropping

The conversion to RGB causes values to drop below 16 and rise above 235/240

For Video output nothing is changed references stay at 16 and 235.
For PC display a gamma ramp must be applied to push 16 to 0 and 235 to 255, the values will still be there for calculalations, the image will still be valid as cropped values would be empty anyway.

Does FFdshow use this method of conversion at the moment?, and does it account for overal luminance(to make BTB/WTW visable when needed on PC monitors)?

So an accurate discription should contain:
-The conversion is about reference black/white
-PC levels are converted using a gamma ramp, there is no cropping of visable data
-Luma and chroma have different reference white-points
-We should use industry accurate naming for both spaces
*Studio RGB for "limited range"
*For "extended range" Computer RGB and Full RGB seem to be used just as often

Mock example:

Input:
Reference Black/White(luminance scale)
-Studio RGB ( Y : 16-235, chroma: 16-240 )
-Full RGB ( Y : 0-255, chroma: 1-255 )
*Black/White point is adjusted using a gamma ramp(forced).
-Auto-Detect


Output:Reference Black/White(luminance scale)
-Studio RGB ( Y : 16-235, chroma: 16-240 )
-Full RGB ( Y : 0-255, chroma: 1-255 )
*Black/White point is adjusted using a gamma ramp(only when input and output do not match).

[mark0077]

My feeling is that for alot of users, all of these words like Studio and Full, althought might be accurate, might confuse the user.

I agree there should be distinct input and output settings.

Input:
I think there should be two areas here, one for rec.601/rec.709 and one area for input levels.

1) I think PAL Rec.601, NTSC Rec.601 and Rec.709 should be here, with user friendly words like DVD\Blu-Ray\etc
I would like an auto setting here, and maybe a second option on what to default to if auto isn't sure......

So my selection here would be "Input Type -> Auto" and "Default To -> Rec.601/DVD..."

2) For input levels, 0-255 or 16-235 etc, I think some keywords should be there to help guide the user, like DVD/Blu-Ray/(can't think of many words to describe 0-255 content as I don't think I have any).
I would like an auto setting here, and maybe a second option on what to default to if auto isn't sure......

So my selection here would be "Input Type -> Auto" and "Default To -> DVD/Blu-Ray/16-235"

Output:
For output if for the output options was to have the keywords PC Monitor/HDTV/Standard TV in their somewhere as a guide, it might allow some people to make better decisions also.

To aid the user for output, there could be a small maybe 200x200 pixel simple video playing which could be used to test the difference between the settings.

Also when rgb32hq is not selected, an interface to control the graphics card output settings (maybe even just ATI and Nvidia) would be great. This would keep all of the colorspace options in one place.

I think in any case, it should be clear what is doing the conversion to rgb32, ffdshow, or the graphics card. The output video test could be used by the user to quickly test the quality of the conversion, maybe a black background with some red diagonal lines to really show off the differences.

So my settings here would be

ffdshow conversion area would be highlighted (because I would have selected rgb32hq), it should be greyed if I select anything else like yv12

The conversion output would be "PC Monitor/HDTV" and I could verify in the output test box that the chroma levels look good.

Summary Of My Opinions
Two Input Areas with keywords for normal users like DVD/Blu-Ray/etc
Auto Settings with default to x setting, with maybe the auto setting showing the currently detected input type when a video is playing.

Output Area with keywords for normal users like TV/PC Monitor/HDTV/etc
Some form of sync / control over the gfx cards setting, so nvidia and ati to start with wouldn't be too difficult I feel.
A small video clip which can play which could be used to test the output levels, maybe with two shades of grey, which should both be visible if correctly configured maybe...
Make it clear from the interface layout what is doing the rgb conversion, ffdshow, or something else like the graphics card....

[tetsuo55]

Something like this maybe?

By default all Displays use "limited range" or Studio RGB
By default PC monitors over VGA/DVI are the only exception, they operate purely in "full range" or Computer/Full RGB

I think the settings should teach the user the right terms but also help him choose the correct setting.


Output:
Reference Black/White(luminance scale)
-Studio RGB ( Y : 16-235, chroma: 16-240 )(This is the default setting for all displays except PC monitors)
-Full RGB ( Y : 0-255, chroma: 1-255 )(PC monitors (If your Display device has an option to use Full-RGB in the manual than this setting will match your displays capabilities if both are enabled))
*Black/White point is adjusted using a gamma ramp(only when input and output do not match).

[mark0077]

Well alot of HDTVs accept 0-255 so I wouldn't put it like "This is the default setting for all displays except PC monitors". I think having a little test box is the only way for 99.9% of users to be happy they selected the right output option.

[Mark_A_W]

FWIW, Haali interprets his controls as "input" controls, not "output" controls. That's why it's exactly backwards in the Haali Renderer. The CoreAVC controls work correctly, though, I think.

Not from my testing/setup. CoreAVC is the same as Haali. I have to pick "PC" to retain levels unmolested in both.


Testing with a proper test disc (or extract thereof, so I don't have to battle the stupid menu...thanks for that!), is the only way to get this right.

It's messy...

[yesgrey]

Ok. But then why list "Y:16" and "Y:235" in the control labels at all, if they are always the same, anyway?
To help all users know about it, and let the more "scientific" users know that ffdshow is doing it right.;)

As far as I understand, FRAPS is encoding black at Y:0. This may be against the standard.
I will try to test this and see how it works...

This may be against the standard. If so, that's one reason more not to interpret the current ffdshow "contrast" section as defining the *input* format, if the input should always have black at Y:16, anyway.
Yes, I agree that calling it input is not a very good idea, because the input we are referring to are the input values used during the conversion from YUV->RGB, and not the input source format, which the current naming may suggest.

I understand that you want to have it labeled scientifically correct. But I think it's more important to make the controls as user friendly and easy to understand as possible, because after all that's what a GUI is supposed to be like. The scientifical correctness should be done by the code in the background. So what would the average ffdshow user understand better?
Well, scientifically correct would be:
Reference Black/White
* Computer RGB (YUV:16,128,128->RGB:0,0,0; YUV:235,128,128->RGB:255,255,255)
* Studio RGB (YUV:16,128,128->RGB:16,16,16; YUV:235,128,128->RGB:235,235,235)
* Custom (YUV:16,128,128->RGB:?,?,?; YUV:235,128,128->RGB:?,?,?)
:D
But I understand your point, and am also very sensitive to it.
As a software developer, I always like to make the things intuitive and easy to understand by the user.
So, how about this:
RGB Reference Black | White
* Computer (RGB: 0 | RGB: 255)
* Video (RGB: 16 | RGB: 235)
* Custom (RGB: ? | RGB: ?)
And in ffdshow's wiki we can explain it more detailed. The average user only wants things working right. The more scientific users, could take a look at the wiki and see how the things are done. I can offer myself to write the wiki about this, but since english is not my native language I think it would be better someone native to correct me after...
Let me list some variations:

Well, we could always create a custom labels option, so each user could name it at his will...:D

[tetsuo55]

Well alot of HDTVs accept 0-255 so I wouldn't put it like "This is the default setting for all displays except PC monitors". I think having a little test box is the only way for 99.9% of users to be happy they selected the right output option.

Keep in mind that the 0-255 is always disabled by default.

It just occurd to me that some people will be using a VGA cable to the HDTV, the image will vary depending on what the HDTV is capable of. That unique situation will have to be tested by each user individually

I agree that we need a better method of testing range capabilities and configuring reference white and black.
Almost everyone here is using a videocard connected to some form of digital panel. So we can digitally set these values. That also means a slightly different configuration approach.

[yesgrey]

There should not be any cropping

I agree, that's why I keep calling them correlation points.
Like in a vinyl record player. You set up the stylus (when using an axial arm) making it tangent to the record grooves in two middle points, but when you play it, you always play the entire record...;)

[mark0077]

Here is a sort of visual representation of what I would think would be a starting point for the output settings / rgb conversion. Its only what I would like, you guys may disagree. So there are three areas within the rgb conversion, ffdshow Conversion, Graphics Card Conversion, and Testing Area.

============================================================
Output - RGB Conversion
============================================================


============================================================
Tickbox To Enable/Disable this area - ffdshow Conversion (if rgb32hq improves we could have a recommended here)
============================================================
Output Color Spaces: rgb32 (recommended), rgb24 etc

Output Display Type: Show controls for selecting between these

High Quality RGB Conversion Option (on by default?)
============================================================

============================================================
Tickbox To Enable/Disable this area - Graphics Card Conversion
============================================================
Output Color Spaces: yv12, yuy2, etc

Output Display Type (Greyed out): These settings are available in your graphics cards settings.
OR
Output Display Type: Show controls to allow changing of graphics card driver settings.
============================================================

============================================================
General Settings
============================================================

Select closest matching colorspace
etc
etc
============================================================

============================================================
Testing Area
============================================================

This area can be used to ensure your output settings above above are correct. Please select from one of your available output types below, and select a renderer. Different renderers can produce different results depending on graphics card and drivers. The renderer can often be changed within the video player you are using. Check your player settings. (or maybe smartly detect what the last renderer used was to even help people along more?).

If your output is correct you should see bla bla, and the diagonal edge should be smooth like in the comparison image.

[Dropdown here to select from yv12/rgb32, or whatever the options they have chosen in the above two sections. This would be fantastic.
[Dropdown here to select a renderer for testing, only applicable when yv12/yuy2 etc are chosen, not ffdshow conversion methods so this can be greyed out in those situations]

[Video Displayed Here For Testing Using Above Settings] ---- [Image Here For comparison of smooth edge]

============================================================

Not sure how the video test could be used reliably, some combinations of decoders / renderers cause different results with some graphics cards. Maybe a renderer option in there? Its really the only way to give the user a way to test things easily though, is to give them this ability to see what they will get.

[tetsuo55]

looks good mark.

Actually there is an alternative solution.
Tooltips!

We can have both the technically accurate and the end-user naming. We just have to decide on which one to be always visable and which one to hide in the tooltip

[Thunderbolt8]

POLL


(1) yesgrey3 suggestion

Reference Black/White
* PC (Y:16->RGB:0; Y:235->RGB:255)
* Video (Y:16->RGB:16; Y:235->RGB:235)
* Custom (Y:16->RGB:?; Y:235->RGB:?)

(2) similar to CoreAVC and Haali Renderer

output levels
* TV (RGB: 16-235)
* PC (RGB: 0-255)
* Custom

(3) used by some experts, also e.g. by Sony Vegas

RGB format
* Studio RGB (16-235)
* Computer RGB (0-255)
* Custom

(4) similar to DVD players, Xbox360 and PS3

RGB format
* Standard RGB (16-235)
* Extended RGB (0-255)
* Custom

(5) maybe the easiest to understand for dummies/newbies?

monitor type
* Computer Monitor (RGB: 0-255)
* TV / Projector (RGB: 16-235)
* Custom


Please everyone name your favorite!

I have no clue what all that means. I only know that I mostly watch HD and sometimes SD content with ffdshow, but that I alternate between computer screens and TV monitor. I guess this might be the same in the future, so I'd go along with that method which causes less work & trouble here, which at best does adapt automatically to input video format and output source tv/monitor

[nautilus7]

They are just different "displaying formats". The coding is the same/already exists.

I go for 2 or 4.

[clsid]

To be consistent with other DS filters I prefer:

Input levels
* TV [RGB: 16-235] (Almost all video formats)
* PC [RGB: 0-255] (Fraps video)
* Custom

Output levels
* PC [RGB: 0-255] (VGA/DVI/HDMI output)
* TV [RGB: 16-235] (S-VIDEO/Component output)
* Custom

[tetsuo55]

To be consistent with other DS filters I prefer:

Input levels
* TV [RGB: 16-235] (Almost all video formats)
* PC [RGB: 0-255] (Fraps video)
* Custom

Output levels
* PC [RGB: 0-255] (VGA/DVI/HDMI output)
* TV [RGB: 16-235] (S-VIDEO/Component output)
* Custom

That is not completely accurate
-AVCHD can be 0-255
-Fraps can be transcoded to any other format and will still be 0-255
-HDMI does not guarantee 0-255.
The option needs to be enabled in both the sender(videocard) and the reciever(display)
When not using the dongle, ati cards default to 0-255 regardless of what the panel is capable of

[clsid]

There will always be exceptions...

Ok, so make it just this then:

Input levels
* TV [RGB: 16-235]
* PC [RGB: 0-255]
* Custom

Output levels
* PC [RGB: 0-255]
* TV [RGB: 16-235]
* Custom

[mark0077]

But input "TV", doesn't easily translate in peoples minds to..... DVD / Blu-Ray etc....

And output "PC" doesn't easily translate in peoples minds to HDTV (my Samsung Series 9 for example was set to accept 0-255 by default so "PC" here wouldn't be the natural option).

Whatever is decided upon for output, I think some sort of test would be great.

How about

Input Levels
Full Range Content (Some PC created material)
Limited Range Content (Most DVD's/Blu-Rays)
Auto Detect Content - Default To Limited

Output levels
Full Range Devices (PC's, TV's/Projector's with Full-Range support/option selected)
Limited Range Devices (Standard TV's/Projecters)

[madshi]

I get the impression that it will be hard to find a solution which everybody will be happy with. At least I think we all agree that there needs to be a change. Any suggestions on how we can decide on a final solution? Maybe we should leave the final decision to the programmer who implements it (whoever that will be)? Or not?

One thing we might still have to discuss is whether there is any need for "input" controls. If FRAPS is really the only source where black is at "Y:0" then maybe we can drop input controls and change the FRAPS decoder to internally "fix" the decoded video data?

[leeperry]

If FRAPS is really the only source where black is at "Y:0" then maybe we can drop input controls and change the FRAPS decoder to internally "fix" the decoded video data?
except that most FRAPS video will be reencoded to WMV/AVI, so you won't be able to ID them anymore :D

reason why I suggested that ppl add a tag to FRAPS videos, so ffdshow knows that they are 0-255 :o

I think all that is required is :
1)-untouched levels
2)-TV>PC conversion
3)-PC>TV conversion(0-255 videos on a 16-235 display)

so if you got a TV display, you use 1) all the time, and set a rule to use 3) for your FRAPS stuff.

if you got a PC display, you just use 2) all time, and 1) for FRAPS stuff.

[yesgrey]

To be consistent with other DS filters I prefer:
Input levels
* TV [RGB: 16-235] (Almost all video formats)
* PC [RGB: 0-255] (Fraps video)
* Custom

This could be consistent, but IMHO it would be wrong. The input is YUV, and is always Y:16-235. The input should not be selected.

Maybe we should leave the final decision to the programmer who implements it (whoever that will be)? Or not?
I agree with this. It was haruhiko who have implemented the current method, so I think the last word should be his. I think he has enough information here already to decide which would be the better option.

[clsid]

@clsid: downloaded what i thought was 2609, turns out to be ffdshow-mt, and the kerneldeint dll for that now works! About 323KB and smooth as a baby's bottom! Would suggest using that one for future builds. ;)
That was a GCC build. I will use that from now on.

[netwolf]

IF there is a way to auto-detect the input format based on the displayed material, there should be a (default) Auto option.

As a programmer (nothing video related) and end-user of ffdshow I'd vote for the most user-friendly wording when it comes to output.
As I guess it's not possible to detect automatically, an option to choose on which display (1/2) which device is attached.
So e.g. you only have to tell ffdshow that your display one is PC (e.g. the LCD display of your laptop) and display 2 is a CRT TV, a computer monitor or a Plasma/LCD HDTV device.
Maybe there's even a way to get this information from the driver of the graphics card?

More technical descriptions are of course very welcome, but what the average user wants is IMO either an automatic option or if that's not possible a question he can easily answer.