ffdshow tryouts project: Discussion & Development

[leeperry]

calibrate the display to 16-235/240, the result is that the desktop will be clipped.
oddly enough, neither m$/nvidia or ati allow you to output 16-235 from the desktop natively.
the ati will let you pick it for "limited RGB"(16-235), but it's a lossy conversion done after the RGB32 mixer and before the TMDS encoding(prolly in 8 bits too) :

http://img.techpowerup.org/081113/Capture003.jpg

and it only works if you use a hdmi/hdmi cable + ATi adapter...no soup for you if you use a hdmi/dvi cable :rolleyes:

[clsid]

The VS2003 settings are the correct ones. I shall apply them to the VS2008 project and make a fresh build.

[_xxl]

I''ll commit soon fix for ffmpeg-mt branch.

[jos99]

BBC's one works at rev 2598.
Luxe TV's sample, this is more difficult.
I guess MPC's splitter fails to parse access units (or send two or more access units at a time).
In that case, ffdshow has to parse access units to use ffmpeg-mt.
Is MPC splitter used in MPC-HC as I do not get the distortion line problem with either Luxe TV HD or BBC HD files using DXVA in MPC-HC.

[_xxl]

ff_kernelDeint compiled with VS2008 + ICL11 just crashes for me on AMD XP.

[clsid]

ICL10 build seems to be ok. Try my 2602 build.

[_xxl]

ICL10 is working ok.
Can you compile x64 versions?

[yesgrey]

the current expansion method is flawed in several ways
I don't agree. It's not complete, but it's not flawed.

(1) Either you have a display which wants to have PC levels (typically a computer monitor).
(2) Or you have a display which wants to have video levels (typically a TV or projector).
Depending on (1) or (2) the *only* correct way to convert YCbCr to RGB is to define "black" to be at either "0" or "16".
I don't agree. The black level is not defined by the display, it's defined by the source material.
For video material, the black will always be RGB[16,16,16]. In a TV set expecting it, no problem, everything is calibrated. In a computer monitor, you have to decrease brightness to compensate for it.
Only for PC material the black is RGB[0,0,0], and, because of this, you have to set different brightness levels in your pc monitor, according to the material you are seeing. The YUV->RGB conversion should not change.
For video material, it should always be YUV[16,128,128]->RGB[16,16,16] and YUV[235,128,128]->RGB[235,235,235]
For computer material, it should always be YUV[16,128,128]->RGB[0,0,0] and YUV[235,128,128]->RGB[255,255,255]
The problem is that this way the images look washed out, because the display is expecting the black to be at [0,0,0] and the white at [255,255,255], so we need to correct the gamma.

The option tells ffdshow type of input source.
Not completelly right, IMHO. The option tells ffdshow if we want to use values outside of the YUV standard values. The Y values should always be between 16 and 235 and UV values between 16 and 240, to all sources.


(1) I want to play a Blu-Ray on my monitor 1 (20" Dell LCD monitor). This LCD wants to have black sent as RGB(0, 0, 0).
The LCD wants black as RGB[0,0,0] for computer images. For video images it should be RGB[16,16,16], and you should decrease brightness until you can not distinguish it from the RGB[15,15,15]. That's why you need the blacker than black bars.

No display takes RGB(16,16,16) as black, as far as I know.
Are you sure about this?
Some TV displays do.

The only problem I see here is that using input levels as reference to decide which option one should use, this is not optimal and has never been done that way in every other application I know of.
I agree with the current method, I only think it's incomplete and not clear enough.
That page is about what ffdshow outputs, not what the input is.
Yes, the page is about what ffdshow outputs, but depending of what's the input we want it to consider.;)

Thanks to the rec wikipedia articles i think i understand the whole luminance range issue better now.
!!EVERY display expects and accepts 0-255!!
The only difference is how it treats this signal:
Some of you are mixing up YUV->RGB conversion with brightness levels and gamma curve, and these are different things. Some people like to convert it wrongly to avoid correct the gamma, but it's not the right way of doing it.

Here is a great thread about all this levels thing, where I have learned almost all that I wrote here. Read the posts from dmunsil and sspears, they know what they're talking.
http://archive2.avsforum.com/avs-vb/showthread.php?t=416292

As far as correct option is selected, the output level is always 0-255, full.
What else should I use other than input?
That page is how RGB conversion is done, including RGB->YUV conversion.

I think the dialog is correct, only not clear enough.
I would draw and suggest a new dialog for this, not too different, just more clearer...

[clsid]

ICL10 is working ok.
Can you compile x64 versions?
I use MinGW64 for all 64-bit stuff. When I used ICL some time ago for 64-bit builds some people complained that it didn't work properly.

[alexins]

I use MinGW64 for all 64-bit stuff. When I used ICL some time ago for 64-bit builds some people complained that it didn't work properly.

When is built tomsmocomp into mingw x64, construction is passed normally. When is built kerneldeint into mingw x64, construction completes by the error:

szl@BEST /c/work/ffdshow2602x64/src/imgfilters/kerneldeint
$ make CC=gcc 64BIT=yes
x86_64-pc-mingw32-gcc -c -I. -I../.. -L/sdk/lib/x64 -I/sdk/Include -mno-cygwin -mdll -mthreads -pipe -fno-common -DWIN64 -D_WIN64 -msse -mfpmath=sse -DNDEBUG -UDEBUG -fno-rtti -fno-exceptions -O3 -fomit-frame-pointer -m64 -MMD -o ff_kernelDeint.o ff_kernelDeint.cpp
In file included from ../../simd.h:20,
from ff_kernelDeint.cpp:27:
../../simd_instructions.h:1: error: conflicting specifiers in declaration of 'paddb'
../../simd_instructions.h:1: error: conflicting specifiers in declaration of 'paddb'
../../simd_instructions.h:1: error: conflicting specifiers in declaration of 'paddb'
../../simd_instructions.h:2: error: conflicting specifiers in declaration of 'paddsb'
../../simd_instructions.h:2: error: conflicting specifiers in declaration of 'paddsb'

... etc.
... etc..
... etc..

ff_kernelDeint.cpp: In member function 'void TkernelDeint::Deinterlace_0(int, int, int, KernelDeintMask*, unsigned char**, stride_t*) [with int SHARP = 0, int TWOWAY = 0, int PITCH_MOD = 8, int COLORSPACE = 1]':
ff_kernelDeint.cpp:197: instantiated from here
ff_kernelDeint.cpp:2282: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp:2295: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp: In member function 'void TkernelDeint::Deinterlace_0(int, int, int, KernelDeintMask*, unsigned char**, stride_t*) [with int SHARP = 0, int TWOWAY = 1, int PITCH_MOD = 8, int COLORSPACE = 1]':
ff_kernelDeint.cpp:199: instantiated from here
ff_kernelDeint.cpp:2282: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp:2295: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp: In member function 'void TkernelDeint::Deinterlace_0(int, int, int, KernelDeintMask*, unsigned char**, stride_t*) [with int SHARP = 1, int TWOWAY = 0, int PITCH_MOD = 8, int COLORSPACE = 1]':
ff_kernelDeint.cpp:201: instantiated from here
ff_kernelDeint.cpp:2282: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp:2295: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp: In member function 'void TkernelDeint::Deinterlace_0(int, int, int, KernelDeintMask*, unsigned char**, stride_t*) [with int SHARP = 1, int TWOWAY = 1, int PITCH_MOD = 8, int COLORSPACE = 1]':
ff_kernelDeint.cpp:203: instantiated from here
ff_kernelDeint.cpp:2282: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp:2295: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp: In member function 'void TkernelDeint::Deinterlace_0(int, int, int, KernelDeintMask*, unsigned char**, stride_t*) [with int SHARP = 0, int TWOWAY = 0, int PITCH_MOD = 8, int COLORSPACE = 0]':
ff_kernelDeint.cpp:210: instantiated from here
ff_kernelDeint.cpp:2282: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp:2295: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp: In member function 'void TkernelDeint::Deinterlace_0(int, int, int, KernelDeintMask*, unsigned char**, stride_t*) [with int SHARP = 0, int TWOWAY = 1, int PITCH_MOD = 8, int COLORSPACE = 0]':
ff_kernelDeint.cpp:212: instantiated from here
ff_kernelDeint.cpp:2282: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp:2295: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp: In member function 'void TkernelDeint::Deinterlace_0(int, int, int, KernelDeintMask*, unsigned char**, stride_t*) [with int SHARP = 1, int TWOWAY = 0, int PITCH_MOD = 8, int COLORSPACE = 0]':
ff_kernelDeint.cpp:214: instantiated from here
ff_kernelDeint.cpp:2282: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp:2295: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp: In member function 'void TkernelDeint::Deinterlace_0(int, int, int, KernelDeintMask*, unsigned char**, stride_t*) [with int SHARP = 1, int TWOWAY = 1, int PITCH_MOD = 8, int COLORSPACE = 0]':
ff_kernelDeint.cpp:216: instantiated from here
ff_kernelDeint.cpp:2282: error: 'COPY_LINE' was not declared in this scope
ff_kernelDeint.cpp:2295: error: 'COPY_LINE' was not declared in this scope
make: *** [ff_kernelDeint.o] Error 1

[haruhiko_yamagata]

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?

Input level
* Standard ( Y : 16-235, chroma: 16-240 )
* Full range ( Y : 0-255, chroma: 1-255 )
* Custom (Y : 16-235, chroma: 16-240 )
[...]

Output level
* Computer monitor ( RGB : 0-255 )
* TV or projector ( RGB : 16-235 )

[haruhiko_yamagata]

Got a similar problem with recent builds (normal and MT, but not x64) when playing interlaced MPEG-2 and using Yadif.
With Yadif enabled (internal version -or- Avisynth version) I get "slow motion" playback, which disappears when the OSD is enabled!
Had a lot of private discussion with haruhiko_yamagata about that problem already, but no solution yet.

It came down to the following result:
* The time ffdshow spends in Yadif is always okay.
* When the slow motion happens, then ffdshow spends a very long time (much too long) in the "convert" function!
* The "convert" time is back to normal with OSD enabled.

Note that there was no such problem in rev2347, seems it started around rev2391 ...
Thanks to LoRd_MuldeR, rev 2577 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&sortby=date&revision=2577) has fixed this issue.

[STaRGaZeR]

I think the same happens with High quality YV12 to RGB conversion option in 64-bit builds. I say the same because it also goes away by enabling OSD (sometimes only) or by disabling the option, and also "slow motion" here means 1-2FPS.

[LoRd_MuldeR]

Well, haruhiko_yamagata was able to track my problem down to slow V-RAM access. If the V-RAM is accessed randomly (not sequentially), then the access becomes very slow on some graphics cards (obviously including mine). And that caused the "slow motion" effect I reported. The problem was triggered because the colorspace converter did write to V-RAM randomly. The OSD fixed that problem, because with OSD enabled the data is buffered in RAM before copied over to V-RAM. So OSD makes V-RAM access sequential again and thus resolved the "slow access" problem. Always buffering the data in RAM would be bad though, as it causes some overhead (which is unnecessary, if the graphics card has no problem with random V-RAM access). Therefore the "new" method will now benchmark V-RAM access and enforce sequential access only if "slow access" is detected. I guess this should work in x64 builds too. But only if your problem is the same one, of course ^^

[haruhiko_yamagata]

I wouldn't touch libmpeg2 flagging, remember the issue with DVB streams.Sorry, I knew you would object, but because you were the only one who objected, I have committed as rev 2606 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&sortby=date&revision=2606).

[TheShadowRunner]

well, doesn't this whole color space thing also revolve around what RENDERER you're using too?
Overlay will convert tv to pc level, VMR9 won't etc... so couldn't selecting "TV or projector for Output level in FFDShow" be wrongly interpreted if the user uses "overlay mixer"?
(he'd still get 0-255 on his display).
Later,

TSR

[STaRGaZeR]

But only if your problem is the same one, of course ^^

I guess it is, and I can remember clsid saying some users reported an insane stuttering when using that option in x64, just like I'm experiencing.

Sorry, I knew you would object, but because you were the only one who objected, I have committed as rev 2606 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&sortby=date&revision=2606).

:D

MatMaul comes to my mind, because of this he did the "Force bob" patch :p But it's fine if you like it that way, I can always use a profile and force deinterlacing for DVBViewer like applications.

[madshi]

I don't agree. The black level is not defined by the display, it's defined by the source material.
I'm not sure whether to agree or disagree with that. The display does not *define* the black level of the source. But the display usually does *expect* black to be set at a specific RGB value (either "0, 0, 0" or "16, 16, 16"). How else do you explain that some displays can be switched between two different RGB "interpretations". Some displays call it "standard vs. enlarged". Others "standard vs. extended". Others "studio vs. computer". There are multiple names for it. But there are a number of displays which support switching between two different RGB interpretations. And there are some source devices (e.g. PS3, Xbox360, some DVD players) which support switching between these two RGB formats, too. So if both (some) home cinema displays and (some) home cinema source devices support two different RGB formats, then so should ffdshow.

For video material, the black will always be RGB[16,16,16]. In a TV set expecting it, no problem, everything is calibrated. In a computer monitor, you have to decrease brightness to compensate for it.
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.

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?

Input level
* Standard ( Y : 16-235, chroma: 16-240 )
* Full range ( Y : 0-255, chroma: 1-255 )
* Custom (Y : 16-235, chroma: 16-240 )
[...]

Output level
* Computer monitor ( RGB : 0-255 )
* TV or projector ( RGB : 16-235 )
Yes, that would be great!

I'm not 100% sure about which names would be best for these options. Maybe we should try to match the names used by other DirectShow filters? E.g. CoreAVC has this:

http://img401.imageshack.us/img401/234/coreavche2.png

And the Haali Renderer uses "Luma Range" as a title and then also "TV (16-235)" vs. "PC (0-255)".

So maybe using "TV levels" vs. "PC levels" would make sense for both input and output levels? The detailed description in the brackets can stay as it is, I think (but please no space before the ":" :)).

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...

Thanks!!

[madshi]

well, doesn't this whole color space thing also revolve around what RENDERER you're using too?
No. Because the renderer only decides about this stuff if you let it do the YCbCr -> RGB conversion. If you feed the renderer (any renderer) RGB, it doesn't modify the levels, anymore. So if we activate YCbCR -> RGB conversion in ffdshow, all renderers should behave the same in terms of black level and BTB/WTW etc. E.g. the "TV/PC levels" option in the Haali Renderer has no effect, anymore, if you feed the Haali Renderer with RGB data.

However, the cost of this is that you lose any DXVA hardware acceleration.

[Jong]

I'm not sure whether to agree or disagree with that. The display does not *define* the black level of the source. But the display usually does *expect* black to be set at a specific RGB value (either "0, 0, 0" or "16, 16, 16"). How else do you explain that some displays can be switched between two different RGB "interpretations". Some displays call it "standard vs. enlarged". Others "standard vs. extended". Others "studio vs. computer". There are multiple names for it. But there are a number of displays which support switching between two different RGB interpretations. And there are some source devices (e.g. PS3, Xbox360, some DVD players) which support switching between these two RGB formats, too. So if both (some) home cinema displays and (some) home cinema source devices support two different RGB formats, then so should ffdshow.Definitely. Finally the video drivers for both ATI and Nvidia allow this, ffdshow must too.

It should be pretty rare to come across video that uses PC levels; the ffdshow options for this will be useful but barely used by most. But it is vital that ffdshow outputs the right level for you display. You might say why not calibrate the display appropriately but:

- Some displays (some TVs) can only be calibrated for video levels (cannot display below 16).

- Many HTPCs are routed through an AVR or HDMI switcher,so the HTPC has to be calibrated to match other devices sharing the same TV input, such as a STB.

- For use on an HTPC it is also often desired (although opinions do vary) to get levels for the desktop (photos etc.) consistent with video, so both can be displayed accurately without re-calibration.

We definitely need one option that says if we wish to expand video to PC levels (16->0) or leave black as 16. By default video black should be assumed 16 and white 235, but there should be another option that allows people to correct for video produced using PC levels.

[madshi]

@Jong, fully agreed.

[leeperry]

It should be pretty rare to come across video that uses PC levels
well FRAPS videos are, because games are 0-255 in the first place.
maybe it could use some detection scheme ? like "fraps" in the filename ?
Well, haruhiko_yamagata was able to track my problem down to slow V-RAM access. If the V-RAM is accessed randomly (not sequentially), then the access becomes very slow on some graphics cards (obviously including mine). And that caused the "slow motion" effect
hummm, I dunno what graphic card you're talking about...but I also had slow motion problems with YADIF. looking forward to trying it again, whenever clsid will make an ICL10 build that is :)

[tetsuo55]

Those Microsoft guys in that thread said a lot of interesting things, this is what they said in short.

-when you feed VMR9 with YV12 or NV12 the videocard does an accurate 16-235 > 0-255 conversion.
Simply calibrate the monitor using a test disc and both desktop and video should be correct

-Microsoft is pushing the PC industry into the 16-235 range, and this is the default value for all VMR9 operations

Basically all games made after 2005 and Windows after SP2 should be doing as much as possible in the 16-235 range.
they say most photography is 8-245, although there is also a push to 16-235.

-------------

So basically on any modern display:
Calibrate reference black at "16"
Calibrate absolute black at 0 or 1
Absolute white at 254 or 255

During the conversion to RGB clipping should take place at:
1 and 254 for Studio levels(TV)
0-255 for PC levels

This conversion is done in 10bit to reduce banding(and should even account for rgb primaries and gamut conversion)

[tetsuox]

well FRAPS videos are, because games are 0-255 in the first place.
maybe it could use some detection scheme ? like "fraps" in the filename ?
How many people that fraps and encode their gameplay footage actually put "fraps" in their filename? Not many I'm sure, I know I don't.

The best solution for gameplay footage is to convert them to TV levels before encoding. Of course that would be the "ideal" solution but I suspect most gamers will not even know what TV levels and PC levels are. :confused:

[leeperry]

How many people that fraps and encode their gameplay footage actually put "fraps" in their filename? Not many I'm sure, I know I don't.
well, look at it the other way around.
if you tell ppl that their fraps videos will be automatically played in 0-255 if they add "fraps" to the filename, they might very well start doing it :)

EDIT : well OK, they might as well make a profile with filename detection...still most ppl won't bother doing that :D

[littleD]

I think we all miss an "Auto" :) button when it comes to changing levels. FFdshow eventually could obtain, which value is set in input as true black and white: 16/235 or 0/255. The user would only thick yuv>rgb conversion and the output level range appropriate for his monitor. What do you think about that:confused:

[leeperry]

I think we all miss an "Auto" :) button when it comes to changing levels. FFdshow eventually could obtain, which value is set in input as true black and white: 16/235 or 0/255. The user would only thick yuv>rgb conversion and the output level range appropriate for his monitor. What do you think about that:confused:
it already exists, sort of.
use the "Seb BTB&WTW" automatic levels in the levels filter ;)

[clsid]

Since ffdshow is able to decoder Fraps video there is no need to do silly detection based on filenames (which is totally unreliable). It can just check what kind of video it is decoding (Fraps or something else).

So what we need is:
1) Auto option for BT.601/BT.709:
IF (height >= 720 or width > 1024) use BT.709 ELSE use BT.601
2) Auto option for input levels:
IF FRAPS use PC levels ELSE use TV levels
(if levels filter is enabled, use those settings?)
3) Options for output levels: Auto/PC/TV
4) Auto option for output levels:
IF monitor resolution equals PAL or NTSC res THEN use TV levels ELSE use PC levels
(if levels filter is enabled, use those settings?)

Edit: added width constraint

[leeperry]

Since ffdshow is able to decoder Fraps video there is no need to do silly detection based on filenames (which is totally unreliable). It can just check what kind of video it is decoding. Of course that does not work in case of raw video, but that is not important. In that case it should just assume TV levels as that is what 99% of the videos are encoded in.
all I was saying is that the only "proper" 0-255 videos ppl can have are output by fraps basically.
all detection schemes will be silly anyway, so the only way is that ppl put an indicator in the filename with an automatic profile in ffdshow IMHO :o
or maybe ask the FRAPS ppl to put a flag somehow..

Haruhiko's suggestion is good coz it would allow ppl with TV range displays to watch 0-255 movies properly....but it could also create some unwanted double conversions, and even triple conversions if the user has an ATi card with HDMI/DVI dongle..

[leeperry]

IF (height >= 720) use BT.709 ELSE use BT.601
[...]
IF monitor resolution equals PAL or NTSC res THEN use TV levels ELSE use PC levels
more like x<1024=601,x>1024=709, as 1280*544 movies would be decoded in 601 otherwise :o

humm, some ppl use 1280*720 in PC levels, some other in TV...and noone uses PAL or NTSC monitor resolutions....the HC910 has a 1024*576 panel yet it's DVI, so it's 0-255 levels ;)

[clsid]

or maybe ask the FRAPS ppl to put a flag somehow..Did you actually read my post? If ffdshow is decoding Fraps video, then it knows it is Fraps. And isn't that always PC levels?
and noone uses PAL or NTSC monitor resolutionsYes they do, and they are more commonly called CRT TVs. Which happen to like TV levels input.

[rack04]

Input level
* Standard ( Y : 16-235, chroma: 16-240 )
* Full range ( Y : 0-255, chroma: 1-255 )
* Custom (Y : 16-235, chroma: 16-240 )
[...]

Output level
* Computer monitor ( RGB : 0-255 )
* TV or projector ( RGB : 16-235 )

What is the difference in input levels and output levels?

[leeperry]

Did you actually read my post? If ffdshow is decoding Fraps video, then it knows it is Fraps. And isn't that always PC levels?
Yes they do, and they are more commonly called CRT TVs. Which happen to like TV levels input.
oh FRAPS has its own codec ?
well I guess FRAPS will let you choose the levels at encoding ? and is it 601 or 709 ? :D

right, but most graphic cards drivers will only output 640*480/800*600 on svideo/composite AFAIK(except w/ tvtool & legacy GPU's)....well I haven't plugged a PC to a CRT in a long time, can't really tell :D

but I don't see guessing the levels depending on the resolutions work at all :o

do as you wish, as long as this "auto" thingie can be disabled ;)

[littleD]

But it woud be nice to find the way to obtain real levels and color standard 601/709. There could be a fake 0-255 videos with real B&W at 16/235 and rare SD videos with itu 709, and reverse as well. We can nonintentionally compress that files.
If Levels sebs BTB WTW option in ffdshow do the job and now we only choose output range, then what is this discussion about? :)

[tetsuox]

it already exists, sort of.
use the "Seb BTB&WTW" automatic levels in the levels filter ;)
That's a good feature although the last time I use it, iirc it constantly readjusts BTB & WTW levels per frame for each frame. Ideally (in automatic mode) it should adjust to the lowest Black level and the highest white level for the entire file that has been detected during playback (I don't mean 1 pass or anything, I just don't want it to squeeze the levels when it comes to a frame that has narrower levels than the previous frame).

oh FRAPS has its own codec ?
well I guess FRAPS will let you choose the levels at encoding ? and is it 601 or 709 ?
Yes FRAPS uses it's own codec and afaik it records in almost lossless RGB 4:4:4. Not sure whether it is BT.601 or 709, I'm not an expert but don't those standards only apply to Luma/Chroma type color models?

In any case the native fraps file size is much too large for practical distribution, a user will always encode into a more transport-friendly codec (usually a WMV codec :( as they often use Windows Movie Maker and less commonly ASP or AVC) which will involve colorspace conversion to YV12.

2) Auto option for input levels:
IF FRAPS use PC levels ELSE use TV levels
(if levels filter is enabled, use those settings?)
Anyway, with regards to fraps content it is dependent upon the encoder. It is unlikely that a user will be watching gameplay footage or machinima in the fraps native codec. The only time I do is just to see what I've recorded.

This however could affect the encoding process if the user uses ffdshow to decode fraps instead of fraps' own directshow filter.

[LoRd_MuldeR]

hummm, I dunno what graphic card you're talking about...but I also had slow motion problems with YADIF. looking forward to trying it again, whenever clsid will make an ICL10 build that is :)

Mine is an ATI Readeon X1950 XT ;)

Recent ICL10 build can be found here:
http://www.xvidvideo.ru/content/view/567/30/

[leeperry]

Mine is an ATI Readeon X1950 XT ;)

Recent ICL10 build can be found here:
http://www.xvidvideo.ru/content/view/567/30/
ICL10 builds of the MT trunk, awesome! http://forum-images.hardware.fr/images/perso/d4buff.gif

I've got a G92 nvidia, and w/ the previous builds I couldn't get proper deinterlace on PAL/NTSC original DVD's...will try again :rolleyes:

[tetsuo55]

Basically all you have to do is test for 0 and 255, if the YCrCb stream has these values you know its PC based.

The FRAPS codec will always be 0-255 but you can choose to store as DIVX instead of the built in codec. So codec alone is not enough to find them.

----------------

We can have full and flawless auto-detection for levels, gamut and color primaries.
Only 24fps progressive HD content cannot have color primary autodetection

First check resolution for gamut:
x<1024=601,x>1024=709
Next check levels:
Are there any values lower/higher than Y : 16-235, chroma: 16-240 in YCrCb?
-If yes then assume 0 and 255 as reference black
-If no then assume 16 and 235/240 as reference black
Check FPS:
29,X;30;60 > assume NTSC primaries
25;50 > assume PAL primaries
24 > assume 709 primaries

--

When converting from YCrCb:
-Clip of 0 and 255 after conversion to RGB ONLY for TV level input
-Convert using 10bit of precision, then dither back to 8bit

----------------------------

Something else that thread revealed is:

A CRT that has been calibrated to 16 and 235 is still capable of displaying on screen 1-254
How it works is that brightness can be effected by what is being shows on the screen, causing overall luminance to rise or fall, thus revealing the lower than 16 and higher than 235 values.
On digital panels the overall luminance is always the same so when you set reference black to 16 everything else will always be clipped, same goes for 235.

We need to find a way(in the renderer, not ffdshow) to emulate the behaviour of the CRT(The MS employees in that thread say they have done so with VMR9 and supported players)

Overal luminance seems to be calculated per frame and when luminance would rise/fall enough for clipped values to appear the renderer would adjust the screen so they become visable until the luminance drops/rises again.

[leeperry]

Anyway, with regards to fraps content it is dependent upon the encoder. It is unlikely that a user will be watching gameplay footage or machinima in the fraps native codec. The only time I do is just to see what I've recorded.
indeed, it all depends on how the native FRAPS files get encoded then....prolly in 0-255 BT.601 for SD, and 709 >720p, dunno how WMV/XViD handle colorspaces :o

but that sounds like a lot of potential headaches :D

the whole point of Seb.26's levels thingie is to make sure that you actually get to see all the avaiable video data in the source.
either you can set a low threshold and long hold time, or the other way around....I personally don't like it as I believe that BTB/WTW is not supposed to be taken care of, and that some encoders actually put padding data there...which renders the whole thing pointless :o

levels auto-detection can't work IMHO.

[tetsuo55]

indeed, it all depends on how the native FRAPS files get encoded then....prolly in 0-255 BT.601 for SD, and 709 >720p, dunno how WMV/XViD handle colorspaces :o

but that sounds like a lot of potential headaches :D

the whole point of Seb.26's levels thingie is to make sure that you actually get to see all the avaiable video data in the source.
either you can set a low threshold and long hold time, or the other way around....I personally don't like it as I believe that BTB/WTW is not supposed to be taken care of, and that some encoders actually put padding data there...which renders the whole thing pointless :o

levels auto-detection can't work IMHO.

Fraps records in 0-255 sRGB, when choosing DIVX these values might be slightly changed in the form of clipping

This process will put values outside the 16-235 range in YCrCb, and as this is illegal for commercial content it should be very easy to detect
(we need examples to confirm this)

What helps is is that the levels rules for YCrCb and RGB are completely different.
It is illegal to have values lower than 16 and higher than 235/240 in YCrCb but its completely okay to have them in RGB (although 0 and 255 will be clipped on limited range devices because these should contain sync)

[leeperry]

First check resolution for gamut:
x<1024=601,x>1024=709
this is not the gamut, this is the YCbCr>RGB decoding formula ;)

EDIT : and guessing the media file native gamut won't get you anywhere....as it would require to also input the display native gamut primaries coordinates, and use a 3D LUT to transfer them :o

[tetsuox]

The FRAPS codec will always be 0-255 but you can choose to store as DIVX instead of the built in codec.

Fraps can only capture in it's native codec (FPS1) with PCM audio in an .avi container. There isn't an option to capture in divx or anything else. At least not in version 2.9.7 that I'm currently using.

[tetsuo55]

this is not the gamut, this is the YCbCr>RGB decoding formula ;)

EDIT : and guessing the media file native gamut won't get you anywhere....as it would require to also input the display native gamut primaries coordinates, and use a 3D LUT to transfer them :o

No, if you read the thread over at avsforums you will see that conversion to RGB should always result in sRGB primaries/gamut.
All videocards/HD displays work in this range. Although calibration levels and innacurate hardware causes the primaries to shift(sometimes very far) This is not a problem of the video-path.

To fix the 3D-LUT for a specific display a 2nd option is needed:
-I have the 3D-LUT for my display, please use this as the target instead of the default 701/sRGB

Fraps can only capture in it's native codec (FPS1) with PCM audio in an .avi container. There isn't an option to capture in divx or anything else. At least not in version 2.9.7 that I'm currently using.

Okay, i only read the fact and it was talking about possible DIVX errors. Thanks for confirming.

[leeperry]

No, if you read the thread over at avsforums you will see that conversion to RGB should always result in sRGB primaries/gamut.
All videocards/HD displays work in this range. Although calibration levels and innacurate hardware causes the primaries to shift(sometimes very far) This is not a problem of the video-path.

To fix the 3D-LUT for a specific display a 2nd option is needed:
-I have the 3D-LUT for my display, please use this as the target instead of the default 701/sRGB
ah well, I will leave you with your certainities I think ;)
Rec.601/709 are matrix decoding formulas, nothing to do with gamut....they give the formula to go from YV12/YUY2 to RGB.
you keep believing that a PC works in sRGB/REC.709/HDTV(different names/same thing) gamut....but only photos and HDV videos do, movies are either in SMPTE-C or EBU gamut.
besides your display is not in either of those, it's got its own native gamut.
look at this 20" LCD monitor gamut, you can hardly call it sRGB :
http://www.xbitlabs.com/articles/monitors/display/20inch-6_15.html
and there are much worse cases than that, eg wide gamut displays....generic gamut conversion is not possible, and very lossy.
but anyway I don't think ffdshow will ever offer gamut conversion, there's an avisynth plugin for that...it's called ddcc.
what yesgrey3 was asking Haruhiko for was to load the 3D lut's from ddcc in ffdshow...much simpler ;)

[tetsuo55]

I think we are talking past eachother with 2 different things.

What i have been trying to say is:

-theoretically all "digital" is using the sRGB gamut
-Factually the gamut for 709 matches sRGB exactly
-Factually Winxp SP2 and higher video operations are done using the sRGB gamut with limited level range
(although i have not confirmed this personally)
-Factually MS was aware of the gamut and primaries issues back in 2004, they seem to have been working on the problem by detecting what the content was and converting it to sRGB
-Factually it was decided a long time ago that everything in PC land was to use sRGB

Everyone is well aware that the real world does not come close to what i said above.
For this problem ICC profiles where introduced. These profiles are intended to correct the "any gamut/primaries" to the "actual gamut/primaries" of the display

Our players should support ICC, and all our displays should have correct ICC profiles.
This will correct the image to fit into the gamut/primaries of the display

If you feed ICC a sRGB image the conversion should be near lossless

[leeperry]

it was decided a long time ago that everything in PC land was to use sRGB

Everyone is well aware that the real world does not come close to what i said above.
For this problem ICC profiles where introduced. These profiles are intended to correct the "any gamut/primaries" to the "actual gamut/primaries" of the display

Our players should support ICC, and all our displays should have correct ICC profiles.
This will correct the image to fit into the gamut/primaries of the display

If you feed ICC a sRGB image the conversion should be near lossless
yeah a computer desktop(icons/whatever) is supposed to work in sRGB, but we happen to be watching movies too...and these are encoded and stored in REC.601/REC.709 on DVD/BD, but they are supposed to be watched in either SMPTE-C or EBU gamuts, depending on which part of the world they were mastered in(NTSC or PAL lands).
only digital photos and HDV consumer videos use the sRGB/REC.709/HDTV gamut.
there's no video renderer that's color managed, so they wouldn't know what to do with your ICC v4 file in the first place ;)
because all that stuff is 8 bits, conversions are very lossy..

I'll let yesgrey3 confirm my words, as you don't seem to believe me :D

[ikarad]

lpcm HD (from blu-ray) soundtrack doesn'y work with ffdshow audio
When I see a blu-ray which has mlp and lpcm soundtrack with mpc-hc and ffdshow audio, lpcm HD soundtrack are not available with ffdshow audio selected.
To listen lpcm HD (lpcm from blu-ray) soundtrack, I must disable ffdshow audio because MPc-HC decode very well lpcm Hd soundtrack but not ffdshow.

[tetsuo55]

yeah a computer desktop(icons/whatever) is supposed to work in sRGB, but we happen to be watching movies too...and these are encoded and stored in REC.601/REC.709 on DVD/BD, but they are supposed to be watched in either SMPTE-C or EBU gamuts, depending on which part of the world they were mastered in(NTSC or PAL lands).
only digital photos and HDV consumer videos use the sRGB/REC.709/HDTV gamut.
there's no video renderer that's color managed, so they wouldn't know what to do with your ICC v4 file in the first place ;)
because all that stuff is 8 bits, conversions are very lossy..

I'll let yesgrey3 confirm my words, as you don't seem to believe me :D

i'm sorry, it does look like we are fighting.
My only goal is to have the best possible result for users that know little about calibration and rgb
primaries.

I'm not convinced about anything I posted, they are just shortened quotes from various sources.

the only thing I am convinced about is that rec709 and sRGB are one and the same.
And that we need to find a way to simulate CRT on full-range displays when converting to RGB

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

[madshi]

Since ffdshow is able to decoder Fraps video there is no need to do silly detection based on filenames (which is totally unreliable). It can just check what kind of video it is decoding (Fraps or something else).

So what we need is:
1) Auto option for BT.601/BT.709:
IF (height >= 720 or width > 1024) use BT.709 ELSE use BT.601
2) Auto option for input levels:
IF FRAPS use PC levels ELSE use TV levels
(if levels filter is enabled, use those settings?)
3) Options for output levels: Auto/PC/TV
That would be fine with me.

4) Auto option for output levels:
IF monitor resolution equals PAL or NTSC res THEN use TV levels ELSE use PC levels
(if levels filter is enabled, use those settings?)
This is not good. Why would you default to PC levels with a HD display? Ok, PAL and NTSC displays almost always want video levels. But HD TVs and HD projectors usually also want video levels, while HD computer LCD displays usually want PC levels. With HD displays we can never know what they want. So I don't think it's possible to do a good "auto" mode for the output levels. And I don't think it's really necessary, either. Just a simple "TV" vs. "PC" switch should do.

[Dark Eiri]

Just installed Windows 7 beta and I must say I'm shocked.

It doesn't let me use ANY decoders besides the Microsoft DMO codecs!
Tried to force Zoom Player and KMPlayer to use ffdshow and this didn't work either. Mpeg-4 DMO are being used instead.

And worse: the Microsoft decoders are really bad for the time being, some XviD videos are totally glitched.
Any ideas how to fix this, guys? I think it's about the new codec model they're using for WMP12 (which is awesome, by the way, but this codec madness is really getting in my nerves).

If I missed any post regarding this, I'm really sorry.

EDIT:

OK... reinstalled it and now I seem to be able to play everything just fine with ffdshow decoding the audio.
Didn't find a way to use anything else for video, though.