ffdshow tryouts project: Discussion & Development

[STaRGaZeR]

Seeking using libavcodec on H.264 videos (r2583) sometimes gives horrible desync and crazily fluctuating frames per second till about 5-10 seconds in.. when it levels out and goes back to being synchronized.

But it no longer displays corrupted frames! No garbled frames with all renderers Haruhiko. The changes made in rev2579 and rev2580 have affected at all formats decoded by libavcodec. Xvid and DivX seeking is strange now, with a momentary freeze. This revision is both good and bad, so maybe this will give you some new ideas.

[cyberbeing]

Could someone add an option to FFDshow to override the output colorspace (on launch) to whatever the built-in Avisynth is outputting and just pass it through to the renderer unmolested? Is there already some global option for this that I am missing?

Currently FFDshow seems to ignore the Avisynth output colorspace and does color conversions and level fixes (for RGB), seemingly based on the input colorspace, to the lowest common denominator colorspace selected in the output panel.

As a separate, somewhat related question, does FFDshow currently take the built-in Avisynth output colorspace into account when it does its own output colorspace conversions?

[albain]

Are you really sure about that? MPCs Direct3D renderer doesn't really care which screen is the primary one - it'll go fullscreen without problems on any monitor...

np: Other People's Children - Suicide Common (A Number Of Small Things (Disc 2))

This is what MSDN says about this API. When you have multiple displays with extended desktop (so not in clone mode), you will be able to see the video only on one desktop right ?
At one time this is what happened. Maybe it has changed with new gpu drivers & chips.

Well, I want to use ffdshow to correct the primaries of my display.
See this (http://forum.doom9.org/showpost.php?p=1227911&postcount=5868) post a few pages back.

Currently, I have to use an Avisynth filter for it, but I already suggested the addition of the 3D LUT to ffdshow.
And each display have different primaries, so, for each display, I have to use a different 3D LUT. That's why I need the preset selection by the screen resolution... or I have to change it manually each time I switch between my monitor and my projector...:(

OK, but you would need to base your preset selection on both the resolution and the "current monitor" ?
Can you tell if the resize filter when set to "resize to screen resolution" changes automatically when you move the video window from one desktop to another (assuming that you have a different resolution between desktops) ?

[leeperry]

OK, but you would need to base your preset selection on both the resolution and the "current monitor" ?
Can you tell if the resize filter when set to "resize to screen resolution" changes automatically when you move the video window from one desktop to another (assuming that you have a different resolution between desktops) ?
he never uses two displays simultaneously, only one at a time.
having a screen resolution condition would indeed be very handy, like for SD upscaling to native res. depending on the display :)

[yesgrey]

OK, but you would need to base your preset selection on both the resolution and the "current monitor" ?
No. I just need the preset selection to be based on the resolution, I only use one display at a time, so, it's always the main display.
Can you tell if the resize filter when set to "resize to screen resolution" changes automatically when you move the video window from one desktop to another (assuming that you have a different resolution between desktops) ?
No. It keeps the opening resolution.

like for SD upscaling to native res. depending on the display :)
You already could do this with the resize to screen resolution option.;)

[leeperry]

You already could do this with the resize to screen resolution option.;)
ah great! I overlooked that one :rolleyes:
quite frankly, I don't think your feature req would help for proper gamut conversion.......as ffdshow won't know whether you're watching HDTV/EBU/SMPTE-C content.

what I've done is shortcuts in the start menu, and they unpack the right LUT to a ramdisk :

start /b /high Z:\Rar.exe e -y Z:\pj_SMPTE-C.rar Z:\

and then in ffdshow :

rgb3dlut(lutfile="z:\lut.txt",threads=4)

[haruhiko_yamagata]

But it no longer displays corrupted frames! No garbled frames with all renderers Haruhiko. The changes made in rev2579 and rev2580 have affected at all formats decoded by libavcodec. Xvid and DivX seeking is strange now, with a momentary freeze. This revision is both good and bad, so maybe this will give you some new ideas.
Good news that it fixed H.264 seeking for you. The mt branch may have difficulty though.
Sorry for insufficient testing, the regression bug was easy to fix.

[Leak]

This is what MSDN says about this API. When you have multiple displays with extended desktop (so not in clone mode), you will be able to see the video only on one desktop right ?
I always have a 1280x1024 and a 1680x1050 display connected to my first ATI Radeon 4850 (with my 800x600 (don't laugh) projector and the DVI->HDMI adapter for our TV on the second card) and whenever I check "Direct3D fullscreen" it'll go fullscreen on the screen the MPC-HC window is on - so the screen resolution could either be 1280x1024 or 1680x1050.

The "trick" with the D3D renderers is that MPC simply slaps the video as a texture on a fullscreen 3D surface in D3D exclusive mode, just like your vanilla 3D first-person shooter does with it's graphics... i.e. it's not using any overlay capabilities, but just uploads the video images as textures to video ram then draws them on whatever screen Direct3D fullscreen is running on, which can be any of the connected screens.

You can choose the monitor to go fullscreen on in MPC's settings, but somehow for me it always uses the screen it's window is on...

(NB: Despite all this, Reclock has no problems finding out which monitor the video is playing on, so it's definitely doable, probably by querying the filters in the graph - throw my projector and the TV into the mix and there's 4 devices the video could be playing on...)

np: The Orb - Turn It Down (Long Version) (Cydonia Versions)

[haruhiko_yamagata]

At rev 2587, I've cleaned all known issues of libavcodec MPEG-1/2.
Is there anything left?
Now libavcodec may surpass libmpeg2.

And I'm going to change libmpeg2 to flag interlacing like libavcodec.
Any objections?

Anyway, there is no reliable flag in most cases. It's just "how the stream was encoded", not "how it should be treated after decoding".

[mark0077]

Thanks for those updates haruhiko, I will update the dvd quality test results once the new version is up on xvidvideo.ru. Maybe analysis of the video stream can be done in a future release to detect interlaced / progressive. Some expensive hardware players seem to have great success using various techniques. I am sure it could be done in software given enough time. It looks like most of my PAL dvds are badly flagged so this detailed analysis may be the only way to get acceptible detection.

Also, as I havn't had a chance to try the new version, have you had a chance to check libavcodec's issues I mentioned with highlighted items in dvd menu's appearing a few pixels to the right, and few pixels too far down.

Last issue I have is with rgb32hq, in my testing on my nvidia card, nvidias own yv12 output seems to be of higher quality than ffdshows rgb32hq mode. Maybe some analysis could go into how ffdshows rgb32hq could be improved. This would be fantastic. Also I wonder could the conversion speed be increased by using a lookup table rather than millions of multiplications?

I LOVE ffdshow!

Thanks,

[MatMaul]

what about remove the RGB32HQ option in the output tab ?
it is a duplicate of the one in the RGB conversion tab.

EDIT : little bug in the install script : when I install over my previous ffdshow whith a new one the "MPEG in AVI" is reset to libmpeg2

[haruhiko_yamagata]

Thanks for those updates haruhiko, I will update the dvd quality test results once the new version is up on xvidvideo.ru. Maybe analysis of the video stream can be done in a future release to detect interlaced / progressive. Some expensive hardware players seem to have great success using various techniques. I am sure it could be done in software given enough time. It looks like most of my PAL dvds are badly flagged so this detailed analysis may be the only way to get acceptible detection.It is ideal, and I believe my CPU (Core2 Quad 6600) can do that. What matters is my skill :scared:.

Also, as I havn't had a chance to try the new version, have you had a chance to check libavcodec's issues I mentioned with highlighted items in dvd menu's appearing a few pixels to the right, and few pixels too far down.I'll try some reproduce test later.

Last issue I have is with rgb32hq, in my testing on my nvidia card, nvidias own yv12 output seems to be of higher quality than ffdshows rgb32hq mode. Maybe some analysis could go into how ffdshows rgb32hq could be improved. This would be fantastic. Also I wonder could the conversion speed be increased by using a lookup table rather than millions of multiplications?
Chroma has to be upscaled 2x for either horizontally and vertically. The difference of quality is the algorithm of upscaling. It is interesting to try swscale.

[mark0077]

I am sure your coding skills will be enough ;)

I will upload some screenshots of the misaligned menu highlights. Its hard to notice with some DVD's, more noticable with some. I have one dvd that shows it very clearly, its a simple red rectangle highlight over a grey rectangle background. If they are misaligned, the grey is visible. If they are aligned, only red is visible.

Regarding rgb32hq, are there any plans to update it in the near future?

Thanks!

[Inventive Software]

You can try xvidvideo.ru builds one by one to find where the problem is, thus localizing the problem if there is any.

ff_kernelDeint.dll is a separate Visual Studio project and is usually only recompiled once in a blue moon with Intel's compiler when anything in the Kernel Deint sources itself changes - which it hasn't for some time now.

So either something else in some other part of ffdshow changed recently that makes it run slow, or you're using a build/an installer where a ff_kernelDeint.dll compiled with debug settings was included instead of the ICL compiled one... :confused:

I'll try a recent build when I get home tonight - where did you get yours? xvidvideo.ru?

SF also has a few hundred old builds:
http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=199416&release_id=436746

Thank you for the suggestions, I will switch the older ff_kerneldeint.dll with the newer ffdshow install and see whether that cures the problem. If so, something's a bit broken since a revision. Haven't found it yet, but it was a couple hundred revisions ago. Got a way to go as yet!

[_xxl]

Thank you for the suggestions, I will switch the older ff_kerneldeint.dll with the newer ffdshow install and see whether that cures the problem. If so, something's a bit broken since a revision. Haven't found it yet, but it was a couple hundred revisions ago. Got a way to go as yet!
xvidvideo.ru builds use MinGW GCC compiled ff_kerneldeint.dll. I use Icl11 to compile it.

[Inventive Software]

xvidvideo.ru builds use MinGW GCC compiled ff_kerneldeint.dll. I use Icl11 to compile it.

I don't use xvidvideo.ru builds, I use clsid's builds. Something changed with ff_kerneldeint.dll, but I haven't yet figured it out. I'll be back later with dates!! The older one was from the end of March, I have no clue about the newer one yet.

[madshi]

A little request:

I've just spent an hour digging through this thread to understand what is meant exactly with the "contrast" adjustments in the "RGB conversion" tab. I find the names not very intuitive.

Let's think about what happens with a normal DVD or Blu-Ray source: As far as I understand it, using "Standard" stretches the YUV signal in such a way that black gets the RGB value 0, 0, 0. Right? While "Full range" doesn't stretch, instead black gets the value 16 and white the value 235. Right? Do you see where my confusion is coming from? "Standard" stretches black to "0", but the numbers in the dialog for "Standard" read "16-235". And "Full range" sets black to "16" and white to "235", but still the dialog mentions "0-255" for "Full range". Huh?

Or am I misunderstanding what these controls do?

Thanks!

P.S: I'd suggest the following controls to make things more intuitive:

Input/Source levels:
(1) Video levels. (alternatively: "TV-range YUV" or "16-235 YUV")
(2) PC levels. (alternatively: "full range YUV" or "0-255 YUV")

Output levels:
(1) Video levels.
(2) PC levels.
(3) Same as input.

This way everybody (who understands what "video levels" and "pc levels" are) knows what the controls mean and do. Defaults should be "video levels" for input and probably "Same as input" for output levels.

Also the name "contrast" doesn't really fit. It suggests some automatic intelligent image contrast enhancement algorithm. I'd suggest "Levels" instead of "Contrast".

[leeperry]

As far as I understand it, using "Standard" stretches the YUV signal in such a way that black gets the RGB value 0, 0, 0. Right? While "Full range" doesn't stretch, instead black gets the value 16 and white the value 235. Right? Do you see where my confusion is coming from? "Standard" stretches black to "0", but the numbers in the dialog for "Standard" read "16-235". And "Full range" sets black to "16" and white to "235", but still the dialog mentions "0-255" for "Full range". Huh?
if you select "full range" ffdshow keeps the levels untouched(useful to output 16-235 RGB32), if you set it to "standard" it will do a TV>PC levels conversion.

just like in HR, where "PC" doesn't do any conversion and "TV" does TV>PC conversion.

it's quite confusing, I agree :D

[yesgrey]

Also I wonder could the conversion speed be increased by using a lookup table rather than millions of multiplications?

Well, a few posts back I have suggested the addition of 3D LUTs to ffdshow. I only suggested RGB input, but i believe it could be a good idea to also support 3D LUTs with YUY2 input...
let's hope any of the developers find the time to do it. haruhiko already told he would do it if he finds the time... I also will try to learn how to do it, maybe it's not too hard...;)

[leeperry]

i believe it could be a good idea to also support 3D LUTs with YUY2 input
humm...3D RGB LUT's in YUY2 ? I'd like to see that working :D

[alexins]

xvidvideo.ru builds use MinGW GCC compiled ff_kerneldeint.dll. I use Icl11 to compile it.
I recently used ff_kerneldeint.dll and TomsMoComp_ff.dll, built in icl 10.1.029 (with a patch for AMD).

[STaRGaZeR]

Good news that it fixed H.264 seeking for you. The mt branch may have difficulty though.
Sorry for insufficient testing, the regression bug was easy to fix.

After rev2586 everything is back to normal plus no more garbled frames. Great work once again :)

At rev 2587, I've cleaned all known issues of libavcodec MPEG-1/2.
Is there anything left?
Now libavcodec may surpass libmpeg2.

And I'm going to change libmpeg2 to flag interlacing like libavcodec.
Any objections?

All seems good. libmpeg2 is a bit faster seeking with MPEG-2 Blu-ray's, but with SD resolution there is no difference between them.

I wouldn't touch libmpeg2 flagging, remember the issue with DVB streams.

[jos99]

There is a problem with ffdshow mt builds and BBC HD- there is a small line of distortion on the lower edge as shown here that does not occur with normal ffdshow.

http://i535.photobucket.com/albums/ee357/jacz3/bbchddistortionffdshowmt.jpg

[turbojet]

Is there a chance of a 64 bit ffdshow-mt build?

[_xxl]

I can't link pthread with MinGW GCC 4.4.0. Win64, waiting for this issue to be fixed...

[Inventive Software]

I don't use xvidvideo.ru builds, I use clsid's builds. Something changed with ff_kerneldeint.dll, but I haven't yet figured it out. I'll be back later with dates!! The older one was from the end of March, I have no clue about the newer one yet.

FOUND IT! The ff_kerneldeint.dll file sizes between 2 builds are completely different, the working one is about 200-odd KB, the other's 668KB, suggesting it's made as a debug-build. Dated end of November, around 2390-ish.

[Leak]

FOUND IT! The ff_kerneldeint.dll file sizes between 2 builds are completely different, the working one is about 200-odd KB, the other's 668KB, suggesting it's made as a debug-build. Dated end of November, around 2390-ish.
Well, the ff_kerneldeint.dll shipped with beta6 is 668kB, but looking at it in biew doesn't show any debug info, just lots and lots of unrolled loops...

[_xxl]

lots and lots of unrolled loopsMaybe some forced optimizations from Icl compiler?

[Leak]

Maybe some forced optimizations from Icl compiler?
Aren't optimizations the whole point of compiling with ICL? Unrolling loops is, after all, one of the basic optimization techniques, and unless the code gets big enough to not fit into the L1 or L2 cache it should speed things up, not cause a slowdown...

(Of course it would help knowing what Inventive Software's CPU is. But I still doubt it's the unrolling that's causing the slowdown here, unless it was an older AMD chip or a P4...)

[clsid]

I made a fresh build with ICL10 yesterday an it turned out as 600kb-ish. Does that one have the same problem?

[Inventive Software]

Aren't optimizations the whole point of compiling with ICL? Unrolling loops is, after all, one of the basic optimization techniques, and unless the code gets big enough to not fit into the L1 or L2 cache it should speed things up, not cause a slowdown...

(Of course it would help knowing what Inventive Software's CPU is. But I still doubt it's the unrolling that's causing the slowdown here, unless it was an older AMD chip or a P4...)

AMD Turion X2 TL-50 for the record. No problems (I repeat 0 [zero] problems) with earlier (2-3 months ago) builds of ff_kerneldeint.dll.

[clsid]

@xxl

1) Could you please rename the icl10 projects in ffmpeg-mt branch to icl11 and create new icl10 projects?
2) I noticed you updated the baseclasses. The copyright dates however seem to suggest that you replaced them with an older version.
3) Is it worthwhile to continue including x264 with ffdshow? For VFW there already is x264VFW and for DS encoding there now is a filter from RadScorpion: http://blog.monogram.sk/janos/
4) Shouldn't xvidcore also be updated in trunk?

[_xxl]

Could you please rename the icl10 projects in ffmpeg-mt branch to icl11 and create new icl10 projects?
Yes, I'll rename them.
I noticed you updated the baseclasses. The copyright dates however seem to suggest that you replaced them with an older version.
No, ffdshow's baseclasses were based on dxsdk_sum2004. All updates are from microsoft sdks v6.1. True date is 2001 for sdk v6.1.
Is it worthwhile to continue including x264 with ffdshow? Yes, there are people that are against to remove it.
Shouldn't xvidcore also be updated in trunk
I'll update soon, x264, xvidcore, libmpeg2, cpu detection code and some other updates could be merged to trunk.

[leeperry]

Yes, I'll rename them.
didn't you tell me yesterday that you had no plan for ICL10 ffdshow-MT versions ?
anyway that's great news :)

[clsid]

Yes, there are people that are against to remove it.The main reason for that was because there was no other way to encode using DirectShow. Now there is an alternative for that.

[_xxl]

The main reason for that was because there was no other way to encode using DirectShow. Now there is an alternative for that.I think that having an alternative for ffdshow's x264 encoding is ok.

[clsid]

I get this error during linking of libavcodec in ffmpeg-mt branch:
C:\MinGW32\bin/ld.exe: cannot find -lpthreadGC2

I have the standard pthreads API for MinGW32 installed. Do I need something else?

[_xxl]

Change to -lpthread. It should work now.

[jos99]

There is a problem with ffdshow mt builds and BBC HD- there is a small line of distortion on the lower edge as shown here that does not occur with normal ffdshow.

http://i535.photobucket.com/albums/ee357/jacz3/bbchddistortionffdshowmt.jpg
Any comment on this? This has been a problem since at least mt 2333, and is still there on mt 2576. It occurs on BBC HD and Luxe HD which are 1080i h.264. It doesn't exist on normal ffdshow.

AMD 64x2 5000+ 780G Catalyst 8.10 XP SP3

[clsid]

The last line is repeated to create a mod16 resolution. The MT builds are experimental and unfinished, so bugs like this are to be expected.

[Mercury_22]

It's just me or LPCM it's NOT working in FF ? :confused:

[haruhiko_yamagata]

Any comment on this? This has been a problem since at least mt 2333, and is still there on mt 2576. It occurs on BBC HD and Luxe HD which are 1080i h.264. It doesn't exist on normal ffdshow.

AMD 64x2 5000+ 780G Catalyst 8.10 XP SP3
Could you upload the sample video?

[STaRGaZeR]

It's just me or LPCM it's NOT working in FF ? :confused:

Not working for me neither.

[jos99]

The last line is repeated to create a mod16 resolution. The MT builds are experimental and unfinished, so bugs like this are to be expected.
Thanks, I guess I will stick with normal ffdshow for the moment.
Could you upload the sample video?
Sure, here is a 10MB sample of BBC HD (http://rapidshare.com/files/180886722/01-08_00-18-38_BBC_HD__NAR__BBC_HD_Preview.ts), a 5MB sample of Luxe HD (http://rapidshare.com/files/180886723/01-08_00-33-37_Luxe_TV_HD_Shopping.ts). The line of distortion is slightly wider in BBC HD than Luxe.

[Mercury_22]

Not working for me neither.

Can someone look at the LPCM ? PLEASE !
I'm thinking since MPC-HC's internal LPCM it's working maybe it's easy to fix ?! :helpful:

[haruhiko_yamagata]

Thanks, I guess I will stick with normal ffdshow for the moment.

Sure, here is a 10MB sample of BBC HD (http://rapidshare.com/files/180886722/01-08_00-18-38_BBC_HD__NAR__BBC_HD_Preview.ts), a 5MB sample of Luxe HD (http://rapidshare.com/files/180886723/01-08_00-33-37_Luxe_TV_HD_Shopping.ts). The line of distortion is slightly wider in BBC HD than Luxe.
Thanks. Haali's media splitter is OK, but MPC's splitter is not.
Anyway ffdshow (or ffmpeg-mt) is to be blamed.

[Inventive Software]

Aren't optimizations the whole point of compiling with ICL? Unrolling loops is, after all, one of the basic optimization techniques, and unless the code gets big enough to not fit into the L1 or L2 cache it should speed things up, not cause a slowdown...

(Of course it would help knowing what Inventive Software's CPU is. But I still doubt it's the unrolling that's causing the slowdown here, unless it was an older AMD chip or a P4...)

There appears to be something that's making the code about 3x bigger than it ought to be. The last working build of clsid's I have with the working DLL is 2364, dated 20081125. From 2373 (the next build) onwards it seems not to be working. I've yet to try a very recent build, but it might be the switch to ICL11 from ICL10 is breaking something...

[haruhiko_yamagata]

Change to -lpthread. It should work now.
And it also fixes compilation/link x64 version for me.
Did you get the latest binary of pthread by MinGW 64 project?
The touble is that it doesn't work properly.

[clsid]

There appears to be something that's making the code about 3x bigger than it ought to be. The last working build of clsid's I have with the working DLL is 2364, dated 20081125. From 2373 (the next build) onwards it seems not to be working. I've yet to try a very recent build, but it might be the switch to ICL11 from ICL10 is breaking something...I have never used ICL11, always ICL10 or GCC. Please try my latest build. If that doesn't work, then I will try GCC next time.

[Leak]

There appears to be something that's making the code about 3x bigger than it ought to be.
What makes you so sure it's "bigger than it ought to be"?

Loop unrolling as an optimization technique does exactly that - it duplicates code so the CPU needs to do fewer conditional jumps (which cost performance) at the expense of, well, more generated code. Maybe the old DLL just wasn't optimized that much?

Also, what happens if you copy the old DLL into ffdshow's installation directory after installing a recent build?

(By the way - is it possible the bigger DLL was compiled with ICL, but not patched to fix Intel's CPU ID check? That would explain why it would run like molasses on AMD hardware...)

[oddball]

Strange resizing bug when resizing is set to 16 by 9. I get these flickering line distortions down the sides on these encodes. A different encode from a different subbing group does not exhibit this issue.

Occurs with all recent builds.
http://i56.photobucket.com/albums/g190/deadman3000/gg_Toradora_-_01_E2AF98B516-31-35.jpg

[_xxl]

Did you get the latest binary of pthread by MinGW 64 project?
The touble is that it doesn't work properly.
No, I use my own compiled version. I had to modify pthreads source code to compile with MinGW GCC 64.

[jos99]

Sure, here is a 10MB sample of BBC HD, a 5MB sample of Luxe HD. The line of distortion is slightly wider in BBC HD than Luxe.
Thanks. Haali's media splitter is OK, but MPC's splitter is not.
Anyway ffdshow (or ffmpeg-mt) is to be blamed.
Did you mean to say ffdshow/ffmpeg is not to be blamed? I get the distortion with ffdshow mt in DVBViewer, it is not there with normal ffdshow + DVBViewer or playing the file in MPC-HC using DXVA.

[Inventive Software]

What makes you so sure it's "bigger than it ought to be"?

Loop unrolling as an optimization technique does exactly that - it duplicates code so the CPU needs to do fewer conditional jumps (which cost performance) at the expense of, well, more generated code. Maybe the old DLL just wasn't optimized that much?

Also, what happens if you copy the old DLL into ffdshow's installation directory after installing a recent build?

(By the way - is it possible the bigger DLL was compiled with ICL, but not patched to fix Intel's CPU ID check? That would explain why it would run like molasses on AMD hardware...)

Copying the older DLL means it works absolutely fine with no slowdowns; there's no dependencies on anything AFAICT.

@clsid: Downloaded 2588, I'll give it a try and report back tomorrow.

[Nazgulled]

Hi,

I just wanted to know if ffdshow is good enough to play DVDs, either as decoder for video and/or audio or do you recommend something else?

[Leak]

I just wanted to know if ffdshow is good enough to play DVDs, either as decoder for video and/or audio or do you recommend something else?
Uh... why WOULDN'T it be?

Anyway, I've almost exclusively been using it in conjunction with Media Player Classic for playing DVDs the last few years...

np: She & Him - Why Do You Let Me Stay Here (Volume One)

[Nazgulled]

Well, how does it compare with Cyberlink's decoders for instance? Everyone seems to say that Cyberlink's MPEG2 decoder has much better picture quality and allows hardware acceleration? And that's I'm wondering, how does ffdshow compare. I'm not simply asking if it plays MPEG2 files, I just want to know how good it is compared to Cyberlink's decoders for instance (which seems to be the best commercial one). Does ffdshow have better picture quality or worse? Does it use hardware acceleration or not? Is there something else that Cyberlink's decoders does that ffdshow can't or vice-verse?

[tetsuo55]

DVD playback is problematic.

There have been somw fixes lately

http://forum.doom9.org/showthread.php?t=143818

[Nazgulled]

So, you don't recommend ffdshow or what?

[tetsuo55]

It's not ready for daily use yet, but very close.

I recommend you DO use it and report bugs here when you run into them.

[Nazgulled]

Well, I'm actually using CCCP, I'm not sure it uses ffdshow tryouts but I think it does. Still, I won't always have the latest version like this. And besides, I don't watch that many DVDs, but sure, I'll report anything if I find anything out of the ordinary...

[Snowknight26]

It's normally best to have the latest version when doing bug finding/reports.

[Hypernova]

Hi. I hope this is the right place to ask.

I am using the builts from xvidvideo.ru. The problem I have is this: when I set ffdshow-mt to resize video to over ~2050 x (something), the player (I tested with every renderer from MPC-HC and WMP) always freeze. This does not occur with the non-mt built (neither x86 nor x64). Only the mt built can keep up with 1080p h264 for my machine, so I hope someone could help me with this.

My setting:
C2D E6550, 2g ram, ATi2600Pro, Windows 7 Beta x64 (yeah I know, but I really doubt this is the cause. I didn't test with any other OS though.)

[haruhiko_yamagata]

Well, how does it compare with Cyberlink's decoders for instance?I admit that Cyberlink's is better for most users. But does it decode DVD in media player classic? You need alternative MPEG-2 video decoder.

Everyone seems to say that Cyberlink's MPEG2 decoder has much better picture qualityThis doesn't seem to be true.
ffdshow doesn't use hardware acceleration.

Is there something else that Cyberlink's decoders does that ffdshow can't or vice-verse?I don't know how well Cyberlink's decoder handle closed caption. ffdshow handles it quite well.

[haruhiko_yamagata]

A little request:

I've just spent an hour digging through this thread to understand what is meant exactly with the "contrast" adjustments in the "RGB conversion" tab.
Why don't you press help button of the dialog page ;)

I find the names not very intuitive.
Anyway users have to have more than instinct to play with this option.

While "Full range" doesn't stretch, instead black gets the value 16 and white the value 235. Right?I think you are really confused. The dialog say "Full range ( Y: 0-255...".
"Y" means the input level.

Also the name "contrast" doesn't really fit. It suggests some automatic intelligent image contrast enhancement algorithm. I'd suggest "Levels" instead of "Contrast".
"Level" or "Contrast": As I'm Japanese, I don't know which is intuitive for English speaking people.

[haruhiko_yamagata]

Hi. I hope this is the right place to ask.

I am using the builts from xvidvideo.ru. The problem I have is this: when I set ffdshow-mt to resize video to over ~2050 x (something), the player (I tested with every renderer from MPC-HC and WMP) always freeze. This does not occur with the non-mt built (neither x86 nor x64). Only the mt built can keep up with 1080p h264 for my machine, so I hope someone could help me with this.

My setting:
C2D E6550, 2g ram, ATi2600Pro, Windows 7 Beta x64 (yeah I know, but I really doubt this is the cause. I didn't test with any other OS though.)
Why do you have to resize over 2050? It's not supported. Should be checked though.

[leeperry]

DVD playback is problematic.

There have been some fixes lately

http://forum.doom9.org/showthread.php?t=143818
I'm personally having problems with deinterlacing PAL/NTSC DVD's, apparently YADIF is your best option...but only in "double frame rate" mode...which I can't afford as it outputs 48 fps, and I got a big AVS script running that can't process so many frames :o

I use Gabest's MPEG2 decoder in YV12 btw.

[tetsuo55]

Why don't you press help button of the dialog page ;)

Anyway users have to have more than instinct to play with this option.
I think you are really confused. The dialog say "Full range ( Y: 0-255...".
"Y" means the input level.

"Level" or "Contrast": As I'm Japanese, I don't know which is intuitive for English speaking people.

the correct term is: "Luminance Range"
The values between blackest black and whitest white.

the current expansion method is flawed in several ways, i'm still thinking about a way to fix it.
According to the mpeg2 specification you can use almost every value between 0-255 and some samples do.
the spec also allows for different ranges for Chroma and Luma to make things even worse.

When i have more and better information about it i will start a new thread as it is very closely related to gamut and RGB conversion

[madshi]

Why don't you press help button of the dialog page ;)
Just did. And I have to say that the help is plain and simple incorrect.

Anyway users have to have more than instinct to play with this option.
Sure. But that doesn't mean that we shouldn't try to make the options as intuitive as possible, right?

I think you are really confused. The dialog say "Full range ( Y: 0-255...".
"Y" means the input level.
Look, the situation is this:

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

The current ffdshow logic and also the help seems to believe that all displays want to have PC levels. But that's simply not true. E.g. the help says:

> Some video clips have Y-values below 16 which
> represent "blacker" than black. If you want to take
> advantage of this gradation at the expense of
> contrast, use full range or custom mode.

With a computer monitor it is true that using the current "full range" option results in loss of contrast. But this is *NOT* true for a TV or projector which expects video levels. Actually, with a typical TV or projector using "full range" is the only option which produces correct results. Using "standard" with a typical TV or projector means that a lot of shadow detail and white detail is clipped away.

And it doesn't matter at all whether we're talking about a typical movie (which usually has no BTB and WTW information) or about a calibration disc (which usually has BTB and WTW information). With a typical TV or projector you always have to use the current "full range" option, or else shadow details is lost, because a properly calibrated TV/projector will not show any RGB values below 16 (or 15). So if you're using "standard" with a properly calibrated TV/projector, you're losing *15* steps of shadow detail with any DVD, broadcast or Blu-Ray!

[madshi]

Anyway users have to have more than instinct to play with this option.
I've just thought about it and I think we can easily rename the options in such a way that most users will know exactly which option is the right one for them to use. Just change the whole "Contrast" section to this:

Which kind of display do you have?

(1) Computer Monitor.
(2) TV / projector.

That's really all that is needed. Option (1) would do the same that the current "Standard" option does. And option (2) would do the same that the current "Full range" option does.

Maybe it would make sense to offer the possibility to define the type of display for every monitor? E.g. in my case my "monitor 1" is a "Computer Monitor" type display, which wants to have black sent as RGB(0, 0, 0), while my "monitor 2" is my plasma display which wants to have black sent as RGB(16, 16, 16)". So if ffdshow offered an option to define which monitor is which type, it could automatically adjust the RGB conversion correctly, depending on which monitor the video is currently being displayed at.

[Leak]

Well, how does it compare with Cyberlink's decoders for instance? Everyone seems to say that Cyberlink's MPEG2 decoder has much better picture quality and allows hardware acceleration? And that's I'm wondering, how does ffdshow compare. I'm not simply asking if it plays MPEG2 files, I just want to know how good it is compared to Cyberlink's decoders for instance (which seems to be the best commercial one). Does ffdshow have better picture quality or worse? Does it use hardware acceleration or not? Is there something else that Cyberlink's decoders does that ffdshow can't or vice-verse?
I've never used PowerDVD, but how is hardware acceleration for DVD decoding even a big deal anymore? Any of todays CPUs is more than capable to do it in software.

What PowerDVD (and hardware accelrated decoding in general) can't do is apply all the other filters ffdshow (and, in turn, AviSynth) supports to the image...

[haruhiko_yamagata]

Look, the situation is this:

(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).
I understood why you are confusing.
The option does not define the monitor to output.
The option tells ffdshow type of input source.

[madshi]

I understood why you are confusing.
The option does not define the monitor to output.
The option tells ffdshow type of input source.
The GUI doesn't say anything about "input source type" anywhere. The help doesn't, either. Furthermore I think even if GUI and help did explain what the options meant it's still a bad idea to define the "input source type".

Let me give you a simple example:

(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 only way I can realize that with the current ffdshow version is to change the input source type to "standard".
(2) I want to play a Blu-Ray on my monitor 2 (50" Panasonic Plasma). This plasma wants to have black sent as RGB(16, 16, 16). The only way I can realize that with the current ffdshow version is to change the input source type to "full range".

Do you understand that this is really bad usability? I have to change the *input* source type to make ffdshow behave correctly, although the input doesn't change at all, but instead the monitor type has changed! That makes no sense at all from a usability standpoint.

I think we should drop the option to define source type. Instead we should define the monitor type. That is much more important, and much more intuitive.

[clsid]

The Cyberlink MPEG-2 decoder works fine in combination with MPC. Closed captions are handled by MPC or the native windows line21 decoder.

[haruhiko_yamagata]

(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 only way I can realize that with the current ffdshow version is to change the input source type to "standard".
(2) I want to play a Blu-Ray on my monitor 2 (50" Panasonic Plasma). This plasma wants to have black sent as RGB(16, 16, 16). The only way I can realize that with the current ffdshow version is to change the input source type to "full range".

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

[STaRGaZeR]

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. That page is about what ffdshow outputs, not what the input is. This situation would be solved simply by changing the options name from Standard to Full range and viceversa, and specifying you're now setting the output instead of the input. You know your monitor uses 0-255, so you should be able to go to the RGB conversion tab and directly select output 0-255, instead of input 16-235, to transmit 0-255 to the monitor. Don't you agree?

[haruhiko_yamagata]

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.
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 about what ffdshow outputs, not what the input is.
That page is how RGB conversion is done, including RGB->YUV conversion.

This situation would be solved simply by changing the options name from Standard to Full range and viceversa, and specifying you're now setting the output instead of the input. You know your monitor uses 0-255, so you should be able to go to the RGB conversion tab and directly select output 0-255, instead of input 16-235, to transmit 0-255 to the monitor. Don't you agree?
No.
Please note that we have talk a lot about this before.
http://forum.doom9.org/showthread.php?p=1051116#post1051116

[tetsuo55]

Look, the situation is this:

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

this is almost correct, there are a lot of TV/projectors now that allow for "full luminance range". Usually you have a setting in the menu to enable/disable it.

What makes it worse is that every manufacturer has made up a different name for it..

For accurate display purposes ffdshow should ask:
1. My display expects Full luminance range (0-255) * typically PC monitors
2. My display expects Limited Luminance range (16-235) * Typically TV's and Projectors

Besides these 2 there is also the discussion on how to handle the input luminance range (which could be anything between 0-16 to 235-255 and different in both luma and chroma)

Currently the default convert 16-235 to 0-255 clips any data in the 1-15 and 235-255 range

[haruhiko_yamagata]

For accurate display purposes ffdshow should ask:
1. My display expects Full luminance range (0-255) * typically PC monitors
2. My display expects Limited Luminance range (16-235) * Typically TV's and Projectors
It's the level filter...
If you output YV12, this is valid.

That page is not supposed to do this. It converts to RGB. RGB is always 0-255.

By the way, is anyone willing to write for the wiki, in the Levels (http://ffdshow-tryout.wiki.sourceforge.net/Levels) page?

[rack04]

Let me give you a simple example:

(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 only way I can realize that with the current ffdshow version is to change the input source type to "standard".
(2) I want to play a Blu-Ray on my monitor 2 (50" Panasonic Plasma). This plasma wants to have black sent as RGB(16, 16, 16). The only way I can realize that with the current ffdshow version is to change the input source type to "full range".

In case (1) why wouldn't you set to "Full Range". Wouldn't that give you RGC(0,0,0). Maybe I'm just another example of someone that is completely lost with these settings.

[DigitalDeviant]

I've never used PowerDVD, but how is hardware acceleration for DVD decoding even a big deal anymore? Any of todays CPUs is more than capable to do it in software.

What PowerDVD (and hardware accelrated decoding in general) can't do is apply all the other filters ffdshow (and, in turn, AviSynth) supports to the image...

If you needed to you could still use ffdshow's raw video processing after CL since, as you say, hardware acceleration is pointless for DVD. My question is, is it possible for ffdshow to pass on the interlace flag because hardware deinterlacing isn't quite as pointless?

[haruhiko_yamagata]

@rack04, tetsuo55, STaRGaZeR
If you output YV12 (or any YUV formats) to the display, some may take 16-235 and others may take 0-255.
That page is not supposed to handle this.

If you output RGB, all the displays take 0-255.
That page defines how ffdshow should do YUV <-> RGB conversion.

[leeperry]

If you output RGB, all the displays take 0-255.
not really.
some projectors accept RGB24 over TMDS, yet they only accept 16-235 video content....or you have to use their internal brightness/contrast settings to revert from PC to TV levels.

in that case, the best option is to leave ffdshow to "full range" so you output 16-235 RGB32 :o

[haruhiko_yamagata]

Oh seems to play ok in ffdshow 2537 but not in ffdshow-mt 2548 from xvidvideo.ru could someone involved with ffdshow-mt take a look at it (http://www.mediafire.com/download.php?mvjnmva5kmn)?
I have fixed at rev 2600.

[haruhiko_yamagata]

not really.
some projectors accept RGB24 over TMDS, yet they only accept 16-235 video content....or you have to use their internal brightness/contrast settings to revert from PC to TV levels.

in that case, the best option is to leave ffdshow to "full range" so you output 16-235 RGB32 :o
I can hardly believe this, but maybe true...
Anyway, that page is not designed to handle this issue. What is wrong is not ffdshow, that projectors...

yesgrey3, could you comment on this?

[haruhiko_yamagata]

Sure, here is a 10MB sample of BBC HD (http://rapidshare.com/files/180886722/01-08_00-18-38_BBC_HD__NAR__BBC_HD_Preview.ts), a 5MB sample of Luxe HD (http://rapidshare.com/files/180886723/01-08_00-33-37_Luxe_TV_HD_Shopping.ts). The line of distortion is slightly wider in BBC HD than Luxe.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.

[Leak]

No display takes RGB(16,16,16) as black, as far as I know.
I'm pretty sure our 42" LG TV when connected via HDMI can be set to do this - that's more a "feature" (if you want to call it that) of home theater hardware than PC monitors...

np: Electric President - Good Morning, Hypocrite (Electric President)

[leeperry]

I can hardly believe this, but maybe true...
Anyway, that page is not designed to handle this issue. What is wrong is not ffdshow, that projectors...
well, at least for the Mitsubishi DLP projectors it's very much true :o

screenshot from the HC1100 user manual(identical to the HD1000/HC1500/HC1600) :

http://pix.nofrag.com/7/a/a/8d9920546229890662692ac3a0723.png

my HC3100 is a bit different, it works in 0-255 for 1280*768(computer resolution), but in 16-235 for 1280*720

actually, it might very well be mandatory for "HD Ready"/"HD1080p" official logo compliance to work in TV range for HD resolutions....regardless of RGB/YCbPr. it might also be the standard range for HDMI 1.0.

I think you should rename "full range" to "untouched levels" and "standard range" to "TV>PC levels conversion", "contrast/brightness" terms are fine as that's how they are called ;)

[Leak]

My question is, is it possible for ffdshow to pass on the interlace flag because hardware deinterlacing isn't quite as pointless?
If you check "Set interlace flag in output media type" it should, though you might have to force the colorspace to NV12 for the graphics card to do anything.

np: Electric President - Good Morning, Hypocrite (Electric President)

[madshi]

No display takes RGB(16,16,16) as black, as far as I know.
Are you sure about this?
I'm absolutely sure. Look here:

http://en.wikipedia.org/wiki/Rgb

Typically, RGB for digital video is not full range. Instead, video RGB uses a convention with scaling and offsets such that (16, 16, 16) is black, (235, 235, 235) is white, etc. For example, these scalings and offsets are used for the digital RGB definition in the CCIR 601 standard.

I think it can't be any clearer than this, can it?

There is "Studio RGB" and "Computer RGB". The first has black at "16, 16, 16", the latter has black at "0, 0, 0". The default for video is Studio RGB. Although some devices support both and offer an option to switch. E.g. both the PS3 and the Xbox360 can output either Studio RGB or Computer RGB. Also some Oppo and Denon DVD players support both. Also some Sony displays accept both. But when a TV/projector does not allow to choose between Studio RGB and Computer RGB, it usually wants Studio RGB. While a computer monitor usually wants Computer RGB.

And this all means that YCbCr -> RGB conversion absolutely needs a setting for whether output is supposed to be Studio RGB or Computer RGB. Or more intuitively, whether the display is a computer monitor or a TV/projector.

Also check out this:

http://www.hometheaterhifi.com/volume_12_2/denon-dvd-5910-dvd-player-4-2005-part-1.html

The digital set-up is another place to tweak in your DVI and HDMI configuration. This is where you’ll find the RGC mode set-up for DVI and HDMI which is very important. There are two settings for this, Normal and Enhanced. Normal sets the RBG of HDMI and DVI to Studio RGB levels (16-235). This allows for head and toe room in the digital gray scale, which gives you below-black and above-white data.

Video is referenced to a specific color balance when it is recorded. That reference happens to be an analog-based monitor made by Sony. Since the monitor is analog, it doesn’t have a hard clip point at pure black and white, so setting a hard clip point in the digital video domain won’t preserve the qualities of the reference. Studio RGB levels allow for this by setting black at digital 16 and white at digital 235 within the 0-255 digital spectrum. Enhanced mode uses PC RGB levels and moves the level of black to 0 and white to 255 and does not allow head or toe room for above white and below black information. This can easily be verified using test patterns on the Digital Video Essentials or AVIA Pro DVDs. We recommend always using the Studio RGB levels for video playback. That was how DVD was encoded and is the only way to properly display the material. However, there are some displays and projectors out there that are expecting PC RGB levels (Enhanced). Consult your owner’s manual or contact the manufacturing company for more information about your display’s setup.

[Mercury_22]

Is FLAC working for anybody ? Cause for me it's NOT working (tested with MPC-HC and oly MPC-HC's internal filter it's working FFD's is NOT working)

[clsid]

Are you trying to play a .flac file or is the audio stored in for example a Matroska file? ffdshow is only a decoder, it does not play .flac files, you need a source filter for that.

[STaRGaZeR]

Is FLAC working for anybody ? Cause for me it's NOT working (tested with MPC-HC and oly MPC-HC's internal filter it's working FFD's is NOT working)

You need a source filter, or mux FLAC in other containers. FLAC in MKV works OK with ffdshow.

EDIT: clsid beat me to it.

[Jong]

Sorry, I have not tested yet, because I don't have TheaterTek.Thank you for replying. There is a fully functional free trial on the TheaterTek site (http://www.theatertek.com/Products/original_tour.html). I am running on XP SP3 with VMR9.

With beta6 I just try to load the same DVD a few times. Normally within 5 attempts, certainly within 10, playback will start without video. TT says ffdshow video decoder is loaded (for post processing only), but the icon is not in systray, there is no video (black screen), but audio is fine.

[Inventive Software]

@clsid: tried your 2588 build, spotted the DLL's date on it, same size as the others, same problem. Replaced it with an older DLL built around March and it's fine. Is this what I gotta keep doing? What changed between then and now?

[clsid]

I will build it with GCC next time. Maybe that works for you.

[Inventive Software]

Don't know, can't remember what ffdshow said about the file! I think it says what built it and when, hang on 50 minutes... watching "The Closer". :D

[tetsuo55]

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:

-PC monitors and full-range TV's/Projectors treat 0 as reference black and 255 as reference white.
-Limit range TV's/Projectors clip 0 and 255(analog sync channels) and treat 16 as reference black , 235 as reference white for luma and 240 as reference white for chroma

This means that unless your display supports both limited and full range. Your reference black will be at either 0 or 16 and reference white at either 255 or 235/240

-------

Actions to take for both full and limited range displays:

calibrate the display to 16-235/240, the result is that the desktop will be clipped.
FFdshow would only have to compress 0-255 video to 16-235/240 and leave the rest alone(this means only pc-game videos need to be converted)

-------

In my specific case:
Compress everything the pc does from 0-255 to 16-135., Only when playing video content should the compression be disabled and the image output as-is

[Hypernova]

Why do you have to resize over 2050? It's not supported. Should be checked though.

Because my monitor is at 2560x1600, and I wante to have ffdshow handles the resizing instead of the GPU. Again, non-mt builts could resize to that resolution just fine. Only mt builts crashed the player.

[_xxl]

Looking at ff_kernelDeint_2008_icl11 I have that not all ICL release projects use same settings.
MSVC2003 + ICL:
http://i41.tinypic.com/52gqqo.jpg
MSVC2008 + ICL:
http://i39.tinypic.com/28872tz.jpg
Why was /Qip removed?

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

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

[Px]

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
For me, that scheme is better than other. My opinion - add Auto to both Input and Output, if possible, and move descriptions from () to tooltips, as someone mentioned earlier, and there give more detailed information about different modes. Also, make this dialog horizontal, so:

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

[tetsuo55]

Everyone can get what they want.

There only has to be a decision on what is displayed in the screen and what is hidden in the tooltip.

Still i vote for using accurate descriptions even for the non technical ones.

Display:
Reference Black/White
* Auto
* TV [RGB: 16-235]
* PC [RGB: 0-255]
* Custom

Tooltip:
Luminance levels (and a small explenation)
* (explains how it works)
* Studio RGB (followed by the accurate math)
* Computer/Full RGB (followed by the accurate math)
* (explains how it works)

It's time for haruhiko_yamagata to decide :)

[clsid]

I dislike the title "Reference Black/White". The values concern luma ranges, not colors.

But I fear this is a never-ending discussion.

[tetsuo55]

I dislike the title "Reference Black/White". The values concern luma ranges, not colors.

But I fear this is a never-ending discussion.

Luma is the difference between black and white so the naming is accurate.

But i agree that we end users will never agree.

[Leak]

Luma is the difference between black and white so the naming is accurate.
Luma is simply the brightness channel, but it's inherently not about color - it's as much the same difference between black and bright red, green or blue as it is between black and white...

[Octo-puss]

I just moved onto 64bit Vista and am curious how is the development of 64bit FFDS. Why is it considered unstable and experimental?

[Inventive Software]

This whole issue with luma levels has confused me no end, such that I reckon for the videophiles (yesgrey3 I'm looking squarely with no trapezium bend at you) we should cater for their picky needs, and for everyone else hide the option away and pick a default. Is that suitable or not?

[clsid]

I just moved onto 64bit Vista and am curious how is the development of 64bit FFDS. Why is it considered unstable and experimental?Because it is unstable. Mainly due to compiler bugs.

[Octo-puss]

damn :(
So I am better off with internal filters of MPC-HC then?

Compiler errors sounds like potential long waiting for authors to fix stuff...

[clsid]

MPC-HC internal filters have the same issues. ffdshow x64 works reasonably well at this moment.

But you should use the 32-bit MPC and ffdshow. Those work perfectly fine on Vista x64. In general, all 32-bit software runs fine on it.

[tetsuo55]

Luma is simply the brightness channel, but it's inherently not about color - it's as much the same difference between black and bright red, green or blue as it is between black and white...

The way i understand it is:
-Black represents the absence of light
-White represents the brightness of light

This is why its called reference white and reference black

PS black/White are not colors, using only the luma information and discarding chroma(colors) will give you a black and white image

[Octo-puss]

The question is why should I :)
But well, it might be that 64bit brings no advantages over 32 in such cases.

[STaRGaZeR]

Congrats for your recent optimizations Haruhiko, x64 working perfectly now and x86 faster than before! http://www.xtremesystems.org/forums/images/smilies/clap.gif

[avivahl]

Both x86 and x64 rev2614 (compiled by XvidVideo.ru) are working perfectly here on Vista x64. I don't really know why you guys are saying the x64 build is unstable. I use it daily w/ tons of videos (and subtitles; using the built-in subtitle filter) and it's working wonderfully. Good job guys.

[yesgrey]

Look, haruhiko asked my opinion, and it's what I have done. I'm just trying to help clarifying all this stuff, nothing more.
I know this is a bit confusing, and the other applications do not help either, with not very clear labels.
If you have the curiosity to learn more about this subject, read Charles Poynton's colorfaq about it. It was what I did a few times back, when I did not understood nothing of this.
Maybe I still do not understand...;)

[Thunderbolt8]

is normal ffdshow now faster than ffdshow-mt? got with my c2d 47dfps with normal rev. 2614 and with -mt rev. 2615 44dfps, but I have 80fps more with -mt than with normal ffdshow. which value is more important now, fps or dfps?
and whats the difference comapred to the sse_icl build again? they seem to be ~1fps slower than the non sse_icl versions

btw. when switching between the normal and -mt version here I get that nasty computer restart message, because explorer.exe wasnt added to the blocklist.

[Snowknight26]

dfps, which I'm guessing is displayed fps. Also, if I remember correctly, SSE ICL10 builds were built for optimizations for AMD processors, presumably with -arch:SSE.

[cyberbeing]

Thunderbolt8, if ffdshow-mt threading isn't working (very slow), I found that completely uninstalling ffdshow and then re-installing ffdshow-mt with settings reset fixed it for me.

Since it's been a week and nobody replied to my post, I guess it was somehow overlooked in this fast moving thread. Does anybody know the answer to my question(s), particularly the one on the bottom?
Could someone add an option to FFDshow to override the output colorspace (on launch) to whatever the built-in Avisynth is outputting and just pass it through to the renderer unmolested? Is there already some global option for this that I am missing?

Currently FFDshow seems to ignore the Avisynth output colorspace and does color conversions and level fixes (for RGB), seemingly based on the input colorspace, to the lowest common denominator colorspace selected in the output panel.

As a separate, somewhat related question, does FFDshow currently take the built-in Avisynth output colorspace into account when it does its own output colorspace conversions?

[haruhiko_yamagata]

Could someone add an option to FFDshow to override the output colorspace (on launch) to whatever the built-in Avisynth is outputting and just pass it through to the renderer unmolested? Is there already some global option for this that I am missing?

Currently FFDshow seems to ignore the Avisynth output colorspace and does color conversions and level fixes (for RGB), seemingly based on the input colorspace, to the lowest common denominator colorspace selected in the output panel.

As a separate, somewhat related question, does FFDshow currently take the built-in Avisynth output colorspace into account when it does its own output colorspace conversions?This is difficult. ffdshow does not know the output color space of the script on initialization.
Of course ffdshow knows it after processing the first image, it's too late. Video renderers usually do not accept the change of color space during the playback.

[bur]

It's not really clear in the FAQ that the mt builds are faster. I read the FAQ and to me it sounded like all ffdshow-tryout builds had some mt features, like x264 decoding. But it doesn't say what parts of the mt build is multithreaded that isn't in the common builds.

Anyway, if you say some people did benchmarks and it's faster and generally stable, I guess I'll use it anyway. :)

[haruhiko_yamagata]

is normal ffdshow now faster than ffdshow-mt? got with my c2d 47dfps with normal rev. 2614 and with -mt rev. 2615 44dfps, but I have 80fps more with -mt than with normal ffdshow. which value is more important now, fps or dfps?
and whats the difference comapred to the sse_icl build again? they seem to be ~1fps slower than the non sse_icl versions

It depends on the sample. mt is sometimes a bit slower than normal one on dual core. Because normal ffdshow has some multithreading.
Normal ffdshow is sometimes fast if its multithreading fits the sample, while ffmpeg-mt has stable performance for all samples.
In most cases mt is faster. On quad core, mt is almost always faster.

[clsid]

Both x86 and x64 rev2614 (compiled by XvidVideo.ru) are working perfectly here on Vista x64. I don't really know why you guys are saying the x64 build is unstable. I use it daily w/ tons of videos (and subtitles; using the built-in subtitle filter) and it's working wonderfully. Good job guys.
AMR audio decoding is broken. Libavcodec vorbis is broken. *

* Last time I checked. Results may vary depending on the MinGW64 build used for compilation.

[STaRGaZeR]

AMR audio decoding is broken. Libavcodec vorbis is broken. *

Libavcodec AC3 and E-AC3 are broken too.

I'm surprised, libavcodec DTS didn't work before but now it works like a charm (xvidvideo.ru rev2614). Apart from these issues ffdshow64 is now as stable and functional as ffdshow x86 for me. Granted there are some problems with the filters, but I've not encountered any so far.

[tetsuox]

Libavcodec vorbis is broken.

Tremor in ffdshow64 works fine for Vorbis though, at least for stereo sources.

[qyot27]

I did a search for this but couldn't find anything. But there seems to be an issue when trying to use ffdshow in conjunction with x264 - something in both the video decoder and VFW decoder causes x264 to not work unless the full path to x264.exe is specified.

The thread I started about this issue (and where I ultimately came to the conclusion that ffdshow was causing it) is here:
http://forum.doom9.org/showthread.php?t=144215

If there's a way of getting this to work correctly, I'd appreciate it.

[cyberbeing]

This is difficult. ffdshow does not know the output color space of the script on initialization.
Of course ffdshow knows it after processing the first image, it's too late. Video renderers usually do not accept the change of color space during the playback.
Anyway to add drop-down box override to the avisynth page or output page to tell ffdshow to always expect a certain colorspace from avisynth and a checkbox to not preform any colorspace conversions?

i.e. Expected Avisynth Output Colorspace Override [Have a drop-down box] (requires video to be reopened)
+
i.e. Use Expected Avisynth Output Colorspace Override as Output Colorspace [checkbox]. (all output colorspace options would be grayed out when this is checked, if avisynth is active in avisynth page)

I have no idea how difficult this would be to implement, nor do I have any coding knowledge to make a patch myself.


Video is opened

If built-in avisynth is active on launch, it reads the Expected Avisynth Output Colorspace value (if it exists).

If value exists, ffdshow overrides the colorspace with this value to use as a basis for color space conversions.

If Use Expected Avisynth Output Colorspace Override as Output Colorspace is true, do not preform any output colorspace conversions and just set correct colorspace flag when outputting to the renderer (or next item in the graph).


This way when a video is first loaded and avisynth is active, it would automatically assume the output colorspace is what the override specifies (without checking if it is correct). It would then use the override value as basis for output colorspace conversions, unless the other option is checked to not preform any output colorspace modifications.

I hope this makes sense.

[_xxl]

Libavcodec AC3 and E-AC3 are broken too.
MinGW64 GCC build? If so then all asm for Win64 should be disabled.

[_xxl]

I did a search for this but couldn't find anything. But there seems to be an issue when trying to use ffdshow in conjunction with x264 - something in both the video decoder and VFW decoder causes x264 to not work unless the full path to x264.exe is specified.
ffdshow doesn't use x264.exe

[STaRGaZeR]

MinGW64 GCC build? If so then all asm for Win64 should be disabled.

Yep: http://www.xvidvideo.ru/content/view/573/5/ (libavcodec.dll - GCC 4.4.0 x86_64 version)

Except AMR, Vorbis, AC3 and E-AC3 all other libavcodec audio decoders seem to work fine.

[qyot27]

ffdshow doesn't use x264.exe
I know that. What I'm talking about is that ffdshow is acting as the decoder for the video (which is ffvhuff) that I'm serving to x264, and thereby causing x264 to act weird (specifically, it ignores relative paths to the exe, even if the exe is in the directory I've cd-ed to; using the absolute path works without a hitch, but it's thoroughly redundant and unnecessary because I have x264 residing in my system path).

AVISource and DirectShowSource both cause this, but FFmpegSource - because it doesn't rely on VFW or DirectShow and hence doesn't call ffdshow - is perfectly fine. As is Lagarith (when I use AVISource, at least). From all of that, the only conclusion I could find is that something with ffdshow - although I don't know exactly what - is the root of the issue. But whatever it is, serving video with DirectShowSource to xvid_encraw works fine, just not x264.

I'm using clsid's generic build of rev2602 - although I can only assume the problems I've been having for the past month or month and a half (at least; I'm fairly sure at the beginning of November things worked fine, but I didn't do any encoding between then and sometime in December) also arose from builds during that span of time as well.

[halsboss]

dfps, which I'm guessing is displayed fps. Also, if I remember correctly, SSE ICL10 builds were built for optimizations for AMD processors, presumably with -arch:SSE.

I dear, now I'm confused. I have an Intel Q9450 and an Intel Q6600 - should I be using clsid's ICL10 (sse) build or the generic build ?

[fastplayer]

I dear, now I'm confused. I have an Intel Q9450 and an Intel Q6600 - should I be using clsid's ICL10 (sse) build or the generic build ?
http://ffdshow-tryout.wiki.sourceforge.net/FAQ#performance

[halsboss]

OK, thanks. Almost no performance difference according to that, certainly nothing about AMD-specificity for the ICL10 builds. On that basis I may as well use clsid's generic builds since they appear to be slightly more up to date usually.

[leeperry]

OK, thanks. Almost no performance difference according to that, certainly nothing about AMD-specificity for the ICL10 builds. On that basis I may as well use clsid's generic builds since they appear to be slightly more up to date usually.
this is an old outdated comparison.
as soon as you use sharpening or audio filters, the ICL10 versions are much faster(I got an o/c quad)
I've posted comparisons in the previous pages ;)

when I do frame by frame playback in KMPlayer with the ICL10 builds, it almost works in realtime....with the generic builds, it's much slower.

[halsboss]

Oh. Back to ICL10, then :)

[juanchu]

I'm having a problem with FFDShow Video Decoder. I've made a MKA file which contains a MP3 track and a JPG attachment. If I load it without FFDShow Raw Video mode activated, the JPG is shown well in any player, as MPC-HC, or WMP, as if it were a video track. However, with FFDShow Video Decoder with the Raw Video mode activated, the JPG is shown upside down! Have I forgotten something, or is this a bug in FFDShow? I'm using Haali Media Splitter, and FFDShow Prebeta 6 revision 2527. Other video tracks don't have this problem, and are shown correctly.

Thank you so much for your help.

[clsid]

Upload the file for us please.

[juanchu]

Here is:

http://www.megaupload.com/es/?d=ZRLRENUB

The file is a MKA, with a FLAC audio track and Matroska logo in JPG. As I said, if I activate "Raw Video" in FFDShow Video Decoder, the JPG is upside down. However, without that option activated, the JPG is shown fine. It happens with every JPG attached in a MKA file.

[qyot27]

As I posted in my thread on this relative paths issue, I've been able to narrow it down to a gap between November 14th and November 23rd, but not to the specific revision, I just know that:

ffdshow_rev2322_20081114_clsid.exe works fine
ffdshow_rev2347_20081123_clsid.exe displays the relative paths issue

Could this have been something that changed in ffmpeg itself, rather than in ffdshow? Is there some way I can log what's going on with ffdshow, AviSynth, x264, and Windows in a coherent way that can point to what's happening to cause the issue?

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

up! thanks

[jos99]

Sure, here is a 10MB sample of BBC HD (http://rapidshare.com/files/180886722/01-08_00-18-38_BBC_HD__NAR__BBC_HD_Preview.ts), a 5MB sample of Luxe HD (http://rapidshare.com/files/180886723/01-08_00-33-37_Luxe_TV_HD_Shopping.ts). The line of distortion is slightly wider in BBC HD than Luxe.
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.
Using mt 2624 ic10 build both these problems are gone.:thanks:

[anyone23]

Every time I use libavcodec to decode one of my xvid files i get washed out colors.

Screen: http://img218.imageshack.us/img218/7529/libavcodecwj6.th.png (http://img218.imageshack.us/my.php?image=libavcodecwj6.png)

Sample from the source: http://www.megaupload.com/de/?d=IIZHGT1W

Decoding with "Xvid" works fine.

2 Pics for comparison from another file (not frame accurate)

Decoding with Xvid: http://img218.imageshack.us/img218/1213/xvidmi1.th.png (http://img218.imageshack.us/my.php?image=xvidmi1.png)

Decoding with libav: http://img218.imageshack.us/img218/8763/libavscrubshi3.th.png (http://img218.imageshack.us/my.php?image=libavscrubshi3.png)

Is this my fault or a bug in ffdshow/libavcodec?

[haruhiko_yamagata]

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.
Sorry for late reply and than you for your help.
I'll implement some dialog when I get more time.
Auto is difficult except some clear cases such as jpeg and frap.

[haruhiko_yamagata]

[deleted]
oops, failed in testing

[haruhiko_yamagata]

up! thanksCan I have a sample?
Though I'm not sure if I have time to implement.

[haruhiko_yamagata]

Every time I use libavcodec to decode one of my xvid files i get washed out colors.

Screen: http://img218.imageshack.us/img218/7529/libavcodecwj6.th.png (http://img218.imageshack.us/my.php?image=libavcodecwj6.png)

Sample from the source: http://www.megaupload.com/de/?d=IIZHGT1W

Decoding with "Xvid" works fine.

2 Pics for comparison from another file (not frame accurate)

Decoding with Xvid: http://img218.imageshack.us/img218/1213/xvidmi1.th.png (http://img218.imageshack.us/my.php?image=xvidmi1.png)

Decoding with libav: http://img218.imageshack.us/img218/8763/libavscrubshi3.th.png (http://img218.imageshack.us/my.php?image=libavscrubshi3.png)

Is this my fault or a bug in ffdshow/libavcodec?
Although MD5 sum doesn't match with xvid, I can't reproduce the first screen shot.
Which version do you use?

[ikarad]

Can I have a sample?
Though I'm not sure if I have time to implement.

here the example
http://www.zshare.net/info.html?54307328-f4cf1e029ba268fd6fc1e3907e3ab1dc

[yesgrey]

Sorry for late reply
No problem.;)
I'll implement some dialog when I get more time.
Auto is difficult except some clear cases such as jpeg and frap.
Take your time. It's just a cosmetic thing, so when you have more time is good enough.
I think with the preset autoload conditions we can perform some kind of Auto... I have done it in my setup.

[ikarad]

I notice a another bug with ffdshow.
With some blu-ray, If I select MLP soundtrack, I have no sound

here an example of this problem
http://www.zshare.net/info.html?54310400-a553b6c77ff2d34994f4f3bc51b23de2

my config:
Q6600
xp sp3
geforce gtx280 180.48
MPC-HC 1.2.976

vmr9 renderless without direct3d and dxva option (i use ffdshow video decoder)
ffdshow audio 2624
xfi titanium last driver

EDIT:I try an old version 2489 (but it is the same since mlp support in ffdshow (october or november)) and i d'ont have sound with mlp soundtrack.
when i play the sample from the beginning, there is no sound.
However, if I play the sample from the beginning and during the movie, If I move the cursor of the sliding bar (which indicates the current playing time) to another location, then the sound can be listened whatever 2489 or the last version.
I have the same problem for most of blu-rays (that I own) including both lpcm and mlp soundtracks.

[haruhiko_yamagata]

here the example
http://www.zshare.net/info.html?54307328-f4cf1e029ba268fd6fc1e3907e3ab1dc
If you are using Haali's media splitter, there is no output pin of audio for the file.

[Mark_A_W]

I notice a another bug with ffdshow.
With some blu-ray, If I select MLP soundtrack, I have no sound

here an example of this problem
http://www.zshare.net/info.html?54310400-a553b6c77ff2d34994f4f3bc51b23de2

my config:
Q6600
xp sp3
geforce gtx280 180.48
MPC-HC 1.2.976

vmr9 renderless without direct3d and dxva option (i use ffdshow video decoder)
ffdshow audio 2624
xfi titanium last driver

Me too. DTS-MA as well.

The audio decoder jumps samplerate and sample type, but never picks the right one.

It happened a couple of SVN versions ago, not sure which exactly, but 2615 is broken. I'm using the MPC-HC splitter.

(However it could be MPC-HC..but I think it is ffdshow.)

Edit: might be a different issue if yours is related to the Haali Splitter.

[ikarad]

If you are using Haali's media splitter, there is no output pin of audio for the file.

I don't use haali's media splitter

I use only mpc-Hc (vmr9 renderless) and ffdshow.

If I use only mpc-HC and lpcm codec integrated from MPC-HC, I can select and listen lpcm soundtrack. But with ffdshow audio codec used instead of lpcm codec from mpc-hc, I can't select lpcm soundtrack

Me too. DTS-MA as well.

The audio decoder jumps samplerate and sample type, but never picks the right one.

It happened a couple of SVN versions ago, not sure which exactly, but 2615 is broken. I'm using the MPC-HC splitter.

(However it could be MPC-HC..but I think it is ffdshow.)

Edit: might be a different issue if yours is related to the Haali Splitter.

I try an old version 2489 (but it is the same since mlp support in ffdshow (october or november)) and i d'ont have sound with mlp soundtrack.
when i play the sample from the beginning, there is no sound.
However, if I play the sample from the beginning and during the movie, If I move the cursor of the sliding bar (which indicates the current playing time) to another location, then the sound can be listened whatever 2489 or the last version.
I have the same problem for all blu-rays (that I own) including both lpcm and mlp soundtracks.

[haruhiko_yamagata]

I disabled ffdshow audio and enabled MPC-HC (977) internal TS splitter and LPCM, still can't select LPCM track.

[haruhiko_yamagata]

I'm trying to implement H.264's colour primaries staff.

The spec says about ITU-R Rec. BT.709-5

primary x y
green 0.300 0.600
blue 0.150 0.060
red 0.640 0.330
white D65 0.3127 0.3290

What do these values mean?

[ikarad]

I disabled ffdshow audio and enabled MPC-HC (977) internal TS splitter and LPCM, still can't select LPCM track.

I use MPC-HC 976 and I can select LPCM soundtrack and I have sound

Try to disable haali's media splitter because before I used haali and with haali I could not listen lpcm soundtrack from blu-ray but It was 6 months ago

proof here:
http://nsa04.casimages.com/img/2009/01/18/mini_090118042021598636.jpg (http://www.casimages.com/img.php?i=090118042021598636.jpg)


video captured with fraps during 5 seconds (I have sound with lpcm selected)
http://www.zshare.net/info.html?54319451-e8a97d7fdf7d4b2dad1928df2fde1423

parameters: (nero splitter disabled, ffdshow aduio disabled, ffdshow video prefer)
http://nsa04.casimages.com/img/2009/01/18/mini_090118042140159696.jpg (http://www.casimages.com/img.php?i=090118042140159696.jpg)

http://nsa04.casimages.com/img/2009/01/18/mini_090118042223212915.jpg (http://www.casimages.com/img.php?i=090118042223212915.jpg)

http://nsa04.casimages.com/img/2009/01/18/mini_090118042332418520.jpg (http://www.casimages.com/img.php?i=090118042332418520.jpg)

http://nsa04.casimages.com/img/2009/01/18/mini_090118042753730970.jpg (http://www.casimages.com/img.php?i=090118042753730970.jpg)

http://nsa04.casimages.com/img/2009/01/18/mini_090118042603316648.jpg (http://www.casimages.com/img.php?i=090118042603316648.jpg)

[clsid]

A bit off-topic, but those external filter settings are completely pointless.
* If you enable an internal splitter, there is no need to block external ones
* If you enable an internal decoder, there is no need to block external ones
* ffdshow already has a high merit by default, there is no need to set it as preferred, it will automatically get used when needed

[yesgrey]

I'm trying to implement H.264's colour primaries staff.

The spec says about ITU-R Rec. BT.709-5

primary x y
green 0.300 0.600
blue 0.150 0.060
red 0.640 0.330
white D65 0.3127 0.3290

What do these values mean?
I would like to help, but I don't understand your question completelly...
Those numbers are the coordinates of the primaries used in BT.709-5 conformant material.

By the way, about the YUV->RGB Conversion, I think you should use the correct designation.
It's not YUV, it's YCbCr (the b and r should be subscript, but I think in lower case is good enough). We should not continue the spread of this misinformation...;)

[leeperry]

Revision 2393 - Directory Listing
Modified Sun Nov 30 01:01:29 2008 UTC (7 weeks ago) by h_yamagata
Crop: Check "Process whole image" checked by default
Deinterlacers: Hide "Cubic blending" and "Framerate doubler" from GUI
is there a good reason why you hide the "Framerate doubler" ? :(
I understand it might create some problems, but it was actually funny to use it on progressive material...to get fake 48/50fps effect.

there's still Avisynth scripts to do that :
http://www.avsforum.com/avs-vb/showthread.php?t=1025800

...but on slow motion scenes it was great to have it in ffdshow :)

[haruhiko_yamagata]

I use MPC-HC 976 and I can select LPCM soundtrack and I have sound

Oh, I see. If I check both AC3 and LPCM in MPC, it works.

[haruhiko_yamagata]

I would like to help, but I don't understand your question completelly...
Those numbers are the coordinates of the primaries used in BT.709-5 conformant material.

By the way, about the YUV->RGB Conversion, I think you should use the correct designation.
It's not YUV, it's YCbCr (the b and r should be subscript, but I think in lower case is good enough). We should not continue the spread of this misinformation...;)
OK, I found colour_primaries indicates the chromaticity coordinates of the source primaries as specified in Table E-3 in terms of
the CIE 1931 definition of x and y as specified by ISO/CIE 10527.Still not understanding perfectly though.
There are several color spaces such as 709-5, 470-6, 601-6, 240M and "Genelic film".

More confusingly, the spec says,
video_full_range_flag indicates the black level and range of the luma and chroma signals as derived from E’Y, E’PB,
and E’PR or E’R, E’G, and E’B analogue component signals.I don't understand at all :confused:

[madshi]

"video_full_range_flag" is a special flag which is often set incorrectly in broadcasts. E.g. older SkyHD and PremiereHD broadcasts have it all set to "1" although the correct value would be "0". Newer PremiereHD broadcasts have it set correctly. So it might be better to ignore it. All current PC h264 decoders seem to ignore it. If you actually honored this flag, playback of older SkyHD and PremiereHD broadcasts would produce incorrect output.

[tetsuo55]

haruhiko_yamagata
I was unable to reply to feature request 2510387

You asked me if high quality YV12>RGB conversion works in 10bit.
I have no idea, i am not sure where to find that piece of code..

there is also the any>YV12 conversion that should be done in 10bit aswell

[tetsuo55]

"video_full_range_flag" is a special flag which is often set incorrectly in broadcasts. E.g. older SkyHD and PremiereHD broadcasts have it all set to "1" although the correct value would be "0". Newer PremiereHD broadcasts have it set correctly. So it might be better to ignore it. All current PC h264 decoders seem to ignore it. If you actually honored this flag, playback of older SkyHD and PremiereHD broadcasts would produce incorrect output.

I know a lot of users will mind, but imho those streams are broken and should be fixed(probably a small script could be made to fix it)

MPC-HC/FFdshow have to follow the spec as best as possible

[diizzy]

As usual, thanks for the time you're devoting into this project.
I've found a little interesting bug that appears occasionally using libavcodec to decode MPEG2 sometimes results in garbled display.
Using libmpeg2 works fine also MPC-HCs decoder so it's not the file itself.
It's reproducable in both rev2615 (clsid build) and rev2547 (clsid build) with both YV12 and NV12 as output (not that I think it matters) using the standalone splitter from MPC (Home Cinema) rev974 or rev940 (xvidvideo.ru).
Here's a sample of what it looks like, I can also provide a video sample if you want to.

Edit:
As I don't know how long it will take for getting the attachment approved I'm linking it to an external site.
http://bayimg.com/ganPfAAbA
//Danne

[haruhiko_yamagata]

haruhiko_yamagata
I was unable to reply to feature request 2510387

You asked me if high quality YV12>RGB conversion works in 10bit.
I have no idea, i am not sure where to find that piece of code..

there is also the any>YV12 conversion that should be done in 10bit aswell
As you know, "High quality ..." is YV12->YUY2->RGB24/32.
I think YUY2->RGB conversion is 16bit.
However, YV12->YUY2 conversion rounds to 8bit (naturally). This may be a bit of loss.
I would like to implement direct YV12->RGB32 in the future.

The related files are convert_yuy2.h and convert_yv12.h.

[haruhiko_yamagata]

As usual, thanks for the time you're devoting into this project.
I've found a little interesting bug that appears occasionally using libavcodec to decode MPEG2 sometimes results in garbled display.
Using libmpeg2 works fine also MPC-HCs decoder so it's not the file itself.

Thanks, please send us a sample.

[haruhiko_yamagata]

"video_full_range_flag" is a special flag which is often set incorrectly in broadcasts. E.g. older SkyHD and PremiereHD broadcasts have it all set to "1" although the correct value would be "0". Newer PremiereHD broadcasts have it set correctly. So it might be better to ignore it. All current PC h264 decoders seem to ignore it. If you actually honored this flag, playback of older SkyHD and PremiereHD broadcasts would produce incorrect output.
Apart from the broken streams, can I simply assume full range means the range of Y is 0-255?

[yesgrey]

There are several color spaces such as 709-5, 470-6, 601-6, 240M and "Genelic film".
This is related to the phosphors used. Different media has different sensibility to light and its components. See Charle's Poynton's excellent colorfaq, and read the n.11. You can get it here: http://www.poynton.com/PDFs/ColorFAQ.pdf

That's why we need to perform the color correction to our display primaries coordinates. It's the only way we can watch our sources with accurate colors. Different sources are created with different RGB primaries, so, since our display has it's own set of RGB primaries, the colors only will look as it should if we watch material created with primaries equal to our display primaries.
We can color correct the sources to our own display primaries, that's what we can do with the solutions I and several other people have been working in - the reason why I requested the 3D LUT support in ffdshow.
Currently tritical have done it using avisynth, and now I am writing a little program to create the 3D LUTs outside Avisynth. The 3D LUT will include the YCbCr->RGB conversion and the color correction (including gamma correction), all with just the cpu load of using the 3D LUT and the 4:2:0 or 4:2:2 to 4:4:4 conversion. You can learn more about it in here (http://forum.doom9.org/showthread.php?t=139389) and in the first post in here (http://www.avsforum.com/avs-vb/showthread.php?t=912720).
More confusingly, the spec says...
Can you give me the link so I can try to understand it? Note that the specs also refer to the analog signals, which do not interest us...

[yesgrey]

Apart from the broken streams, can I simply assume full range means the range of Y is 0-255?
I don't think so.
Y full range is 1-254. The 0 and 255 values should never be used.
For video, the black is at Y:16 and white is at Y:235.

[tetsuo55]

I just finished reading the colorfaq.

It states(spread over the document)

To convert Y'CbCr to linear RGB you must color diff. decode to non-linear R'G'B and then apply a Gamma correction to get linear RGB.

This conversion officially only has 3 flavours.

1.Modern NTSC Rec601
2.PAL Rec601
3.HD Rec709

The conversion can be made near lossless by:
-Using 9bit or higher precision
-Dithering back to 8bit if/when needed. With dithering focused in the "blue" spectrum


Some notes:
-The conversion is always the same regardless of white/black reference point (0-255 or 16-235)
-The white/black reference point output choice changes the Gamma conversion.
-All the examples in the document are based on 8bit conversion, so we can use these only if we convert them to 9bit+
-Every step of the decoding and conversion steps are lossy in one way or another, by using 9bit or higher precision for each step and dithering back down to 8bit we can greatly reduce the loss in detail(and fix some banding at the same time)
-We should be able to disable to conversion to 8bit for windows7 as it supports up to 16bit.

I have yet to read the gammafaq


yesgrey3,

Do you agree? Did i understand it correctly?

EDIT:

Finished the GammaFAQ, seems to confirm the above.
It does add that any calculations involving luma should be done with linear values if you use non-linear a lot of errors occur. Also the 9bit+ processing seems to help black levels the most.

EDIT2:
The correct naming for the settings screen would be:

Luma reference black/white setting:**ToolTip**<The value at which your display renders Reference white/black, see "Link to ffdshow manual" for more information>
Studio (sRGB) : 16(black) and 235(white)**ToolTip**<This value is correct for most TV's and Projectors>
Computer (Full-RGB): 0(black) and 255(white**ToolTip**<This value is correct for most Computer monitors>

EDIT3:

Using 16bit instead of 8bit processing would result in a perfect scale for luma and a perfect gamut for visable colors(they don't all fit in sRGB/709 though).
Because of the rounding errors in conversion we might as well go all the way and do the calculations in 16bit. I will now take a look at the current ffdshow code

[diizzy]

As requested, here's a sample
http://www.zshare.net/download/54358430d47a4775/
//Danne

[tetsuo55]

As you know, "High quality ..." is YV12->YUY2->RGB24/32.
I think YUY2->RGB conversion is 16bit.
However, YV12->YUY2 conversion rounds to 8bit (naturally). This may be a bit of loss.
I would like to implement direct YV12->RGB32 in the future.

The related files are convert_yuy2.h and convert_yv12.h.


I cannot understand the code, too low level for me :(
I did see some conversions using "RGB24", according to what i read using RGB32 should result in faster calculation because 32 is a native value and 24 is not

[yesgrey]

This conversion officially only has 3 flavours.
1.Modern NTSC Rec601
2.PAL Rec601
3.HD Rec709

Unfortunatelly it seems not. Apparently some studios still perform the Blu-ray mastering using SMPTE-C or EBU monitors without color gammut correction, instead of BT.709 monitors. So, for you to see Blu-ray with accurate colors, sometimes you have to color correct to SMPTE-C or EBU primaries, not BT.709.
Please note that color gammut and conversion matrix are two different things. The Blu-ray conversion matrix is always BT.709, only the primaries could be different.
The conversion can be made near lossless by:
-Using 9bit or higher precision
-Dithering back to 8bit if/when needed. With dithering focused in the "blue" spectrum

The problem is not the conversion. All the calculations are done using 64 bit FP, so there is no problem with it. The only problem is that currently, in PC, we are still bounded by 8 bit per component color modes, so, the possibility of getting some banding is possible. In practice, with real world images, no one notices it...
Do you agree? Did i understand it correctly?

Yes, I think you have understand the essential questions.

-We should be able to disable to conversion to 8bit for windows7 as it supports up to 16bit.

But ffdshow and avisynth don't, and most of the displays also don't. Currently your only option with Windows7 is using mpc-hc with the pixel shader code, and only if your display also supports those modes.

The correct naming for the settings screen would be:
I think we should not complicate the naming too much, just enough to make it more intuitive while keeping it accurate enough.

[yesgrey]

@haruhiko,
About the 3D LUT thing - when you find the time, of course, i'm not pressuring you - you could take a look at the rgb3dlut code. It seems to me that it would be just adding rgb3dlut code to ffdshow; it already supports YUY2,RGB24 and RGB32 input.
Currently it can all be done in an avisynth script with ffdshow, but would it be faster to include the code inside ffdshow? If it would not be faster, we can forget about it and keep using it in an avisynth script.:)

[madshi]

I would like to implement direct YV12->RGB32 in the future.
That would be nice!

Also maybe some kind of dithering instead of using simple rounding would improve image quality further? FWIW, the Lumagen Radiance video processor has several dithering options to reduce banding with digital video output.

[tetsuo55]

Unfortunatelly it seems not. Apparently some studios still perform the Blu-ray mastering using SMPTE-C or EBU monitors without color gammut correction, instead of BT.709 monitors. So, for you to see Blu-ray with accurate colors, sometimes you have to color correct to SMPTE-C or EBU primaries, not BT.709.
Please note that color gammut and conversion matrix are two different things. The Blu-ray conversion matrix is always BT.709, only the primaries could be different.

i don't see any hard proof for this, other than a forum post and a guy in france with a website. And both are based on a loose conversation with some guy who works in a studio that happens to also produce bluray.

The colorfaq says that the mastering displays have been calibrated to 709/65D. Even the existing SMPTE-C or EBU have been re-calibrated to those values.
I also read that most of the newer DVD's are not 601 corrected from the 709 master, again i have seen no proof of this.

IMHO only the 3 i mentioned need to be used, followed by a 3dLUT containing the primaries of the user's display


The problem is not the conversion. All the calculations are done using 64 bit FP, so there is no problem with it. The only problem is that currently, in PC, we are still bounded by 8 bit per component color modes, so, the possibility of getting some banding is possible. In practice, with real world images, no one notices it...

Is the calculation 64 bit for all 3 color primaries or 64bit per color primary? Whichever it is it results in a higher than 16bit precision.
Dithering this back to 8bit should result in a banding free image in 99% of the situations, yet i see banding in almost every image. The problem must then not be the calculations of the rgb values, but the dithering back to 8bit


But ffdshow and avisynth don't, and most of the displays also don't. Currently your only option with Windows7 is using mpc-hc with the pixel shader code, and only if your display also supports those modes.

All videocards i could find made after 2007 support 10bit, there are a lot more that did before that, but those where insanely priced. You can get a 10bit videocard for 40$

All HDMI1.3a panels support 10bit(possibly using dithering to actually display them) signals.

Support for 10bit signals will have to be added. It's a chicken and egg story, but in this case the hardware is there, we just need software support.

(Note for anyone possibly misreading this, 10bit for 8bit source reduces banding, nothing more nothing less)


I think we should not complicate the naming too much, just enough to make it more intuitive while keeping it accurate enough.
Hmm, i think the descriptions i gave are both technically accurate and very easy to understand for end users

[tetsuo55]

That would be nice!

Also maybe some kind of dithering instead of using simple rounding would improve image quality further? FWIW, the Lumagen Radiance video processor has several dithering options to reduce banding with digital video output.

Wow that thing is awesome.
I think that's a good goal for ffdshow.

FFdshow should strive for a processing quality similar to that device

Or in other words.

the Lumagen Radiance video processor is the benchmark that ffdshow is compared too.

[madshi]

The problem must then not be the calculations of the rgb values, but the dithering back to 8bit
Banding can also come from the source.

The correct naming for the settings screen would be
Please let's not restart the discussion! ;) Let haruhiko_yamagata make the final decision, based on the very long discussion we already had a few days ago.

[leeperry]

i don't see any hard proof for this, other than a forum post and a guy in france with a website. And both are based on a loose conversation with some guy who works in a studio that happens to also produce bluray.
you might find the first page instructive:
http://www.avsforum.com/avs-vb/showthread.php?t=1038602

[anyone23]

Although MD5 sum doesn't match with xvid, I can't reproduce the first screen shot.
Which version do you use?

PC1
Win Vista SP1 32bit
ffdshow-mt 2624 icl10
libavcodec.dll 52.10.0 MinGw GCC 4.3.2, x86r, (Jan15 2009)

PC2
WinXP Sp3 32bit
ffdshow 2323 icl10
libavcodec.dll 52.10.0 ...

Has anybody else problems with this sample (http://www.megaupload.com/de/?d=IIZHGT1W) + libav (FourCC: Xvid)?

[tetsuo55]

you might find the first page instructive:
http://www.avsforum.com/avs-vb/showthread.php?t=1038602

Read the whole thread.
I see more confirmation of "The final print has 709 primaries" than the other side.

Also the examples discussed prove the use of 709 primaries.

All (US) content is mastered using SMPTE C monitors, however, either the display is being fed a color-converted 709/sRGB image or there is a post-processer that converts the image to 709/sRGB

Somewhere in the thread it's also stated that the final print is tested using a 709/sRGB projector

[yesgrey]

Also maybe some kind of dithering instead of using simple rounding would improve image quality further?
I will use it in my program for creating the 3D LUTs, but I don't believe it would be very significant.
YCbCr has less than 25% of the colors possible in 8bit RGB, so, even if we use only 8bit without dithering, the banding will hardly be an issue.

iIs the calculation 64 bit for all 3 color primaries or 64bit per color primary?
Dithering this back to 8bit should result in a banding free image in 99% of the situations, yet i see banding in almost every image. The problem must then not be the calculations of the rgb values, but the dithering back to 8bit.
64bit per color primary, of course.
Do you see the banding when? Always, or when you are using our color correction methods?

[leeperry]

there is a post-processer that converts the image to 709/sRGB
noone has ever said anything about that AFAIK.
they master stuff on these SONY CRT's, and then they are ENCODED in REC709 for HD....but they're still using the CRT gamut, which happens to be SMPTE-C or EBU.

ppl pushing this theory are from the ISF and/or mastering houses....and I can tell you that US BD's look better in SMPTE-C on a D65 calibrated display, and european BD's in EBU...to my eyes at least :D

the main Cars hero will never be as red in the cartoon as he is on the posters...

anyhow, use the HDTV/sRGB gamut conversion for everything if you think it looks better...it's a free country :p

I will use it in my program for creating the 3D LUTs
...which will be ready when it'll be ready, right ? :D

tritical is using some HQ chroma upsampling, better than anything available in ffdshow or avisynth at this point....can't....wait http://forum-images.hardware.fr/images/perso/agla.gif

[mark0077]

Great to see all of this work being done! I really can't wait for this gamut work to be completed, and just wondering do I need the 64bit version of Windows 7 to get higher than 32bit colour output.

I am using nvidia card and Samsung Series 9 over hdmi, but still nothing higher than 32bit color yet.

Also, just out of interest, when all of this gamut conversion is done, what should we calibrate our displays to, for example I am using settings on my Samsung at the moment that were apparantly calibrated to 709. I am not an expert on all of this so I wonder is calibrating to this correct.... I will be using the PC for more than just movies and would hope to calibrate the Samsung just once, and have everything look close to correct.

Cheers all.

[tetsuo55]

noone has ever said anything about that AFAIK.
they master stuff on these SONY CRT's, and then they are ENCODED in REC709 for HD....but they're still using the CRT gamut, which happens to be SMPTE-C or EBU.

ppl pushing this theory are from the ISF and/or mastering houses....and I can tell you that US BD's look better in SMPTE-C on a D65 calibrated display, and european BD's in EBU...to my eyes at least :D

the main Cars hero will never be as red in the cartoon as he is on the posters...

anyhow, use the HDTV/sRGB gamut conversion for everything if you think it looks better...it's a free country :p


...which will be ready when it'll be ready, right ? :D

tritical is using some HQ chroma upsampling, better than anything available in ffdshow or avisynth at this point....can't....wait http://forum-images.hardware.fr/images/perso/agla.gif

I am simply condensing the text from your source.
HoustonHoyaFan talked about the fact that the end result, the Bluray or DVD will be 709/sRGB.

I am dissapointed that no-one in that thread tried Cars with SMPTE-C primaries.
With my 709/sRGB and ati expansion settings he is about as red as the cover. Not orangy at all.

What do you see on your display?

I also tested skintones in several samples and they look lifelike to me.
The samples i have chosen as test-discs are like looking through a window.

[tetsuo55]

Great to see all of this work being done! I really can't wait for this gamut work to be completed, and just wondering do I need the 64bit version of Windows 7 to get higher than 32bit colour output.

I am using nvidia card and Samsung Series 9 over hdmi, but still nothing higher than 32bit color yet.

Also, just out of interest, when all of this gamut conversion is done, what should we calibrate our displays to, for example I am using settings on my Samsung at the moment that were apparantly calibrated to 709. I am not an expert on all of this so I wonder is calibrating to this correct.... I will be using the PC for more than just movies and would hope to calibrate the Samsung just once, and have everything look close to correct.

Cheers all.

Higher than 8bit color requires new drivers and i guess changed settings somewhere?
In windows XP and Vista the option for more than 8bit would only be available in DVI mode

[leeperry]

Windows 7 to get higher than 32bit colour output.
it would only be useful on a HDMI 1.3 display...with a HDMI 1.3 graphic card, which doesn't exist at this point.

besides there won't be xvYCC sources before a long while, apparently it's never gonna happen for BD...so it'll only be useful for gamut conversions because 8 bits input/output is lossy.

when all of this gamut conversion is done, what should we calibrate our displays to, for example I am using settings on my Samsung at the moment that were apparantly calibrated to 709. I am not an expert on all of this so I wonder is calibrating to this correct.... I will be using the PC for more than just movies and would hope to calibrate the Samsung just once, and have everything look close to correct.Cheers all.
D65, with a ±2.2 gamma.
native gamut will do, or SMPTE-C/EBU/HTDV if your display enables you to select them(at least your display might work in 10 bits internally)

anyhow, when yesgrey3's app is ready, I will compare the chroma upsampling from tritical to ffdshow and the nvidia drivers with both your and my test patterns :p

[mark0077]

Ah thats good, looking forward to seeing the results. So I think I will leave my TV's settings alone for the moment, calibrated to 709 should be fine. Exciting times :D

[leeperry]

HoustonHoyaFan talked about the fact that the end result, the Bluray or DVD will be 709/sRGB.
yes, it will be encoded to Rec.709, but there won't be any 3D LUT to convert the primaries from SMPTE-C.
I am dissapointed that no-one in that thread tried Cars with SMPTE-C primaries.
before yesgrey3, JohnAd and tritical worked on the case, there simply was no free solution to convert gamuts....you had to use crazy expensive equipment such as the Lumagen scalers.
With my 709/sRGB and ati expansion settings he is about as red as the cover. Not orangy at all.
lemme guess, your display has oversaturated primaries ?
What do you see on your display?
well SMPTE-C was chosen coz it was free of royalties...JVC and SONY had much wider gamuts but they refused to GPL them.
SMPTE-C's major flaw is the red part, that is actually more orangey...and reason why the SMPTE decided to go Rec.709 later on, because HD couldn't fit in such a small gamut.

on my D65/2.4 gamma calibrated DLP pj, in SMPTE-C the Cars Hero is not really red...or at least definitely not as red as on the BD cover.

some more food for thoughts :
http://forum.doom9.org/showthread.php?t=132745

and a very interesting PDF about 3D LUT's in the movie industry :
http://www.color.org/ICC_Chiba_07-06-19_PM_DMP_Float.pdf

[tetsuo55]

yes, it will be encoded to Rec.709, but there won't be any 3D LUT to convert the primaries from SMPTE-C.

First i am just quoting information to get things more clear, i am not convinced either side is correct.

3dluts being used for mastering:
http://www.avsforum.com/avs-vb/showthread.php?p=14370428#post14370428
http://www.avsforum.com/avs-vb/showthread.php?p=14104661#post14104661
http://www.avsforum.com/avs-vb/showthread.php?p=14083637#post14083637
http://www.avsforum.com/avs-vb/showthread.php?p=14083989#post14083989


There is a lot more,

Long story short. "Color is mastered using SMPTE-C primaries, and then converted to 709/sRGB primaries"
So according to the various discussions the 3Dlut we are talking about has already been done at the end of production. (and color conversion is near lossless in this case).

So when you convert the values back to SMPTE-C primaries you WILL have the image that the color guys had while post-producing
However you will NOT have the image the director saw when he okay'd the product as this test was done with 709/sRGB primaries
Most imporant quote here:
http://www.avsforum.com/avs-vb/showthread.php?p=14080317#post14080317



before yesgrey3, JohnAd and tritical worked on the case, there simply was no free solution to convert gamuts....you had to use crazy expensive equipment such as the Lumagen scalers.

Actrually several of the people responding to that thread have these type of devices.


lemme guess, your display has oversaturated primaries ?
My red and blue are 99% accurate and my green is slightly off(709/sRGB/D65)

well SMPTE-C was chosen coz it was free of royalties...JVC and SONY had much wider gamuts but they refused to GPL them.
SMPTE-C's major flaw is the red part, that is actually more orangey...and reason why the SMPTE decided to go Rec.709 later on, because HD couldn't fit in such a small gamut.
Interesting!


on my D65/2.4 gamma calibrated DLP pj, in SMPTE-C the Cars Hero is not really red...or at least definitely not as red as on the BD cover.
But not orange either right? does choosing 709/sRGB primaries look more or less red?



some more food for thoughts :
http://forum.doom9.org/showthread.php?t=132745

and a very interesting PDF about 3D LUT's in the movie industry :
http://www.color.org/ICC_Chiba_07-06-19_PM_DMP_Float.pdf

Goint to read those links, thanks!

[leeperry]

true, noone tells you that the mastering house didn't finally realize that they should run a 3D LUT from SMPTE-C to REC.709....but let's say that most don't, as confirmed by the ISF and many cinema professionals.

little do you care about the true original colors, look at what happened to TDK between the quicktime trailer and the final BD : http://forum.doom9.org/showpost.php?p=1236592&postcount=53

you want the colors the mastering engineer had on his CRT screen.

the only problen is with movies shot on HD cameras, coz their native gamut is indeed sRGB....my approach is to go SMPTE-C/EBU if it's a BD/DVD and sRGB if it's a web video shot on consumer stuff(and didn't get through mastering).

one quote that sums all that up is:
http://forum.doom9.org/showpost.php?p=1076274&postcount=4

Most consumers actually don't like a realistic, correctly calibrated picture. They like oversaturated colors and high contrast ratios.

if ppl don't care, why should mastering houses do? why do you, anyway? :D

[yesgrey]

You can get a 10bit videocard for 40$.
Yes, but even if you buy one for $400 you cannot work in 10bit mode, XP and Vista do not support it. You cannot have a 10bit per component desktop resolution.

...which will be ready when it'll be ready, right ? :D
Yes.;)
I am trying to release it during this week, but I don't want to do it without a good and comprehensive readme, and that will take me some time to write, since english is not my native language...

[tobinaka]

Oh, I'm coming here at the very good time! Hello and Thanks for ffdshow's developmets. I'm a x264 user and now interested in digital colors.

Don't confuse colour_primaries with matrix_coefficient. color_primaries is more connected with transfer_characteristics while video_full_range_flag with matrix_coefficient. color_primaries is for such profiles as sRGB or AdobeRGB. video_full_range_flag is for RGB<->YUV converting.

Anyway, I'm coming here to report that I found Flash Player on the web supports H.264's video_full_range_flag then I want ffdshow to suport it, too. First at all, look at the results of my comparing.
http://www.tobinaka.com/files/matrix_fullrange2.bmp (It's 1040x600 bmp)

-on RGB->YUV convert
I use ConvertToYV12 filter of AviSynth. Convert filter has 4 matrix options: Rec601, Rec709, pc.601, pc.709. 601 and 709 means matrix coefficients for SD and HD, while Rec and pc. means TV range and full range. This time I want to test full range then I use Rec601 and pc.601 to compare.

-on input in x264 the information to send to video player (decoder)
The information of the range which is used at RGB->YUV converting is NOT input when you finish AviSynth, BUT is input when you set H.264/AVC flag by setting x264 VUI option. Then if you use other ConvertToYV12 options than default, you must set x264 VUI options. To input fullrange information in H.264, you set x264 --fullrange off(default, Rec601) or on(pc.601).
(The same can be said about matrix coefficients that is used in ConvertToYV12 of AviSynth and can be set at x264. color_primaries and transfer_characteristics are different from them -- these are used before AviSynth and its information are input in H.264 parameters at x264.)

-on YUV->RGB convert (player and decoder)
I use Flash Player on Nicovideo (a YouTube-like video sharing service but allows posting by MP4 directly) and AviUtl (the same result with my eyes as WMP with WMP but I can't caputure the result of WMP for copyright protection function).


-Suggestion
On my test I found ffdshow_beta6_rev2527_20081219.exe (last stable) don't support H.264's video_full_range_flag. Is that right?

On Flash Player supporting fullrange flag,
-Rec601 with fullrange off
-pc.601 with fullrange on
show the same colors as original. That meets with the theory.
But there is one but inportant difference. RGB->YUV converting in Rec601 may cause some distortions for color banding because reducing 256 color steps into 224steps, while in pc.601 don't. That distortion is similar those caused by resize with no interpolation. To be pricise, pc.601 may causes color distortions (see the conveting equations with quantization), but it's much better than Rec601.

On ffdshow not supporting fullrange flag,
-Rec601 fullrange off
-Rec601 fullrange on
show the same colors as original. That meets the theory. ffdshow don't actually support fullrange flag. :)
Until now, we're content with Rec601 because it shows us the original colors. But, as above, Rec601 is worse than pc.601. Originally, Rec601 is for analog videos. Then if you use videos in digital from start to finish, it's better to use pc.601.

AviSynth supports fullrange, H.264 and x264 supports, Flash Player supports, but ffdshow don't supports. Then I want ffdshow to support and tell you about it. Thanks!

[tritical]

I will use it in my program for creating the 3D LUTs, but I don't believe it would be very significant.
YCbCr has less than 25% of the colors possible in 8bit RGB, so, even if we use only 8bit without dithering, the banding will hardly be an issue.
Dithering isn't possible when using a straight 8-bit to 8-bit 3D lut. Simply adjusting the rounding used while creating the lut will not eliminate banding. You need to spread the quantization error over neighboring pixels within the image... to do that you need to know the quantization error created when each new pixel value is converted to 8-bit. It would be possible to do it if in the lut you stored, along with the new rgb values, the quantization error for each band (or if you stored the new rgb values in greater precision). Then it would be possible to implement Floyd-Steinberg dithering or similar algorithms. Although, if people think the current lut method by itself is slow :p...

[madshi]

Dithering isn't possible when using a straight 8-bit to 8-bit 3D lut. Simply adjusting the rounding used while creating the lut will not eliminate banding. You need to spread the quantization error over neighboring pixels within the image... to do that you need to know the quantization error created when each new pixel value is converted to 8-bit. It would be possible to do it if in the lut you stored, along with the new rgb values, the quantization error for each band (or if you stored the new rgb values in greater precision). Then it would be possible to implement Floyd-Steinberg dithering or similar algorithms.
I think we should take into account that with Windows 7 it might be possible to output more than 8bit RGB. So I think the preferred solution should be for the LUT algorithm to output 16bit RGB (* 3 = 48bit). Some new MPC HC version might some day be able to output these 16bit RGB directly through HDMI 1.3.

For today (XP + Vista) of course we would then need a way to downconvert those 16bit RGB to 8bit RGB. So we'd need an additional algorithm which can downconvert those 16bit RGB to any bitdepth needed, e.g. 8bit for XP and Vista. This downconversion should ideally use dithering, e.g. Floyd-Steinberg, or something else...

Although, if people think the current lut method by itself is slow :p...
IMHO that shouldn't really be a thing to be worried about. PCs get faster all the time. Primery concern should be for the algorithm to do their job in the highest possible quality. If a given PC is not fast enough to execute the algorithms, then that's not your problem. Of course it would be nice to try to optimize the algorithms for best possible performance. But I wouldn't do any compromises on quality, just to increase performance. But of course that's just my opinion...

[haruhiko_yamagata]

Don't confuse colour_primaries with matrix_coefficient. color_primaries is more connected with transfer_characteristics while video_full_range_flag with matrix_coefficient. color_primaries is for such profiles as sRGB or AdobeRGB. video_full_range_flag is for RGB<->YUV converting.
I'm more than confused. Could you explain how the similar two (colour_primaries and matrix_coefficient) differ?
In short, may I ignore colour_primaries and use matrix_coefficient?

ffdshow does not support video_full_range_flag at all currently, and that's why I'm working on it.

[madshi]

ffdshow does not support video_full_range_flag at all currently, and that's why I'm working on it.
As I said before, there are lots of broadcasts out there (not just a few!!!) with incorrectly set "video_full_range_flag". So please let me advise you again to ignore this flag. Or if you insist on honoring this flag, then you *MUST* add an option to ignore it, or else you'll be flooded with complaints about incorrect black levels etc when using the ffdshow h264 decoder...

[shambles]

if you change profile in either video or audio config and press ok without changing anything else, it reverts back to the original profile.

it's not really very hard to work around it but still i think the profile selection should stick when clicking ok.

[yesgrey]

Dithering isn't possible when using a straight 8-bit to 8-bit 3D lut.
Yes, you are right. When I said I will do it, I was thinking in noise shaping, but then I realized I was confusing names... dither is another thing.:o
I was going to post about it but you came first.
But as I said, I don't think banding is an issue. After having the program ready I will test and look for it, to see if I can make it appear.
So I think the preferred solution should be for the LUT algorithm to output 16bit RGB (* 3 = 48bit).
Yes, I agree with that. First, I will create the possibility of 8bit, then I will add the possibility of other bit depths. If tritical wants to add dithering in a rgb3dlut future version the 3D lut file will already exist...;)
Of course this only makes sense for 8bit input.
I'm more than confused. Could you explain how the similar two (colour_primaries and matrix_coefficient) differ?
The difference it's not in the values, but in the usage.
The matrix coefficients are used for the conversion YCbCr<->RGB.
The colour primaries are used to inform us the accurate position of the colors that are converted.
For example:
Consider the red primary RGB [255,0,0] with bt.709 chromaticity coordinates x=0.64; y=0.33:
In YCbCr using bt.601 matrix: Y:81;Cb:90;Cr:240
In YCbCr using bt.709 matrix: Y:63;Cb:102;Cr:240
If you convert to RGB with the correct matrix, the resulting RGB will always be [255,0,0]
Now, if you output the RGB [255,0,0] in a display with:
-bt.709 primaries, the red chromaticity coordinates will be x=0.64; y=0.33
-smpte-c primaries, the red chromaticity coordinates will be x=0.63; y=0.34
-ebu primaries, the red chromaticity coordinates will be x=0.64; y=0.33

In short, may I ignore colour_primaries and use matrix_coefficient?
Yes.

[haruhiko_yamagata]

if you change profile in either video or audio config and press ok without changing anything else, it reverts back to the original profile.

it's not really very hard to work around it but still i think the profile selection should stick when clicking ok.Thank you, but...
In this high traffic, it is impossible for me not to forget this one after doing piled up tasks.
Please post to
http://ffdshow-tryout.sourceforge.net/phpBB2/viewforum.php?f=3&sid=c2d66e5ae33ae8ceeabf859bbd8f892d
or
http://sourceforge.net/tracker/?atid=867360&group_id=173941&func=browse

[haruhiko_yamagata]

The difference it's not in the values, but in the usage.
The matrix coefficients are used for the conversion YCbCr<->RGB.
The colour primaries are used to inform us the accurate position of the colors that are converted.
For example:
Consider the red primary RGB [255,0,0] with bt.709 chromaticity coordinates x=0.64; y=0.33:
In YCbCr using bt.601 matrix: Y:81;Cb:90;Cr:240
In YCbCr using bt.709 matrix: Y:63;Cb:102;Cr:240
If you convert to RGB with the correct matrix, the resulting RGB will always be [255,0,0]
Now, if you output the RGB [255,0,0] in a display with:
-bt.709 primaries, the red chromaticity coordinates will be x=0.64; y=0.33
-smpte-c primaries, the red chromaticity coordinates will be x=0.63; y=0.34
-ebu primaries, the red chromaticity coordinates will be x=0.64; y=0.33
Then, is colour_primaries to be used for calibrating display?

[haruhiko_yamagata]

As I said before, there are lots of broadcasts out there (not just a few!!!) with incorrectly set "video_full_range_flag". So please let me advise you again to ignore this flag. Or if you insist on honoring this flag, then you *MUST* add an option to ignore it, or else you'll be flooded with complaints about incorrect black levels etc when using the ffdshow h264 decoder...
OK, I'll add an option.

[tobinaka]

I'm more than confused. Could you explain how the similar two (colour_primaries and matrix_coefficient) differ?
In short, may I ignore colour_primaries and use matrix_coefficient?

ffdshow does not support video_full_range_flag at all currently, and that's why I'm working on it.

Let me say first I'm not the professional but just read some textbook and have come to understand recently (that's why I'm coming here today).

Here I show you 4 parameters which MP4 decoders have to manage in colors (see also ITU-T H.264/AVC Annex.E):

-video_full_range_flag
-colour_primaries
-transfer_characteristics
-matrix_coefficients

"video_full_range_flag" and "matrix_coefficients" tell decoders about the way of RGB->YUV converting. When decoders reconvert YUV into RGB, they must know how RGB was coverted into YUV, especially in the form of equations.

Let see BT.601 with TV range for example. Annex.E says about matrix that Kr=0.299 and Kb=0.114. There are only two values because the last can be determined by those two (Kr+Kg+Kb=1).

YUV is originally used at analog videos, then we should begin with 0-1 range for RGB. Set Er for R in 0-1 range, Eg for G, Eb for B.

Annex.E says analog values of YPbPr are determined as below:
Ey = Kr * Er + ( 1 – Kr – Kb ) * Eg + Kb * Eb
Epb = 0.5 * ( Eb – Ey ) ÷ ( 1 – Kb )
Epr = 0.5 * ( Er – Ey ) ÷ ( 1 – Kr )
In BT.601, Kr=0.299 and Kb=0.114, and you already have the values of Er, Eg, Eb. Then you can determined Ey. After you get Ey value, you can determined Epb and Epr.

Now, let's have only Ey, Epb and Epr. Can you determined Er, Eg and Eb? What else are needed to do so? You need Kr, Kb to determined Er, Eg and Eb by Ey, Epb, Epr. H.264's matrix_coefficients tells you about Kr and Kb.

Well, we have Ey, Epb, and Epr, which are analog and in 0-1 range. But we need digital values then Annex.E show a few equations. When YUV depth is 8bit:
Y = 219 * Ey + 16
Cb = 224 * Epb + 128
Cr = 224 * Epr + 128
EDIT: Correct the equations. Thank you yesgrey3.

and please digitize(quantize) them. Finally you get YCbCr values you want!

But those equations are for TV range. How about full scale? Change the last equations like that:
Y = 255 * Ey
Cb = 255 * Epb + 128
Cr = 255 * Epr +128
That is the change which video_full_range_flug causes. But those equations is to convert RGB into YUV. To support fullrange in ffdshow, you must count them backward.

As we see above, "video_full_range_flag" and "matrix_coefficients" are connected with RGB<->YUV converting. On the other hand, "colour_primaries" and "transfer_characteristics" are prepared for color management system.

RGB values tell you only the strenght of Red, Green and Blue at pixels. But RGB values never tell you what red RGB's Red is. The same can be said for green and blue (RGB on computers are different from CIE's RGB which defines R to 700nm, G to 546.1nm, B to 435.8nm). RGB is "relative" and don't tell the color "directly". If display monitors and their settings are different, the colors are NOT the same even with the same RGB value.

So how to display the desired colors? Then CIE(Commission Internationale de L'Eclairage, or International Commission on Illumination) difined color spaces in 1931. One of those is XYZ color space.

Using XYZ color space (and it variant xy or xyY chromaticity diagram), we can know the RGB gamut by determined the locations of red, green, blue and white. With three points of red, green and blue you can picture a triangle on xy chromaticity. After that, with white point you can make color gradations in the triangle (gamma correction changes the gradient of gradation). Now you know what colors your RGB can express for the limit!

H.264's colour_primaries tells you the locations of the four colors. So colour_primaries is connected with xy chromaticity.

xy chromaticity is often used to tell the spec of digital cameras, display monitors and printers. There are some profiles for xy chromaticity such as sRGB and AdobeRGB. AdobeRGB is larger than sRGB and AdobeRGB contains sRGB inside, so some monitors says "we can display AdobeRGB!"

Thus, xy chromaticity like sRGB is used in input devices like digital cameras, and in output devices like display monitors and printers. The xy chromaticity of input devices tells what colors the RGB values of their production means. The xy chromaticity for output devices are received for how to relate RGB values to actual colors. If xy chromaticities of both input and output is the same, we don't need to become aware of colour_primaries (because it's always the same).

I think ffdshow can manage colour_primaries when input xy chromacity is smaller than output xy chromacity. That's because ffdshow can't express the colors beyond the spec of display monitors. When input chromacity is smaller than output, ffdshow can narrow the RGB gamut. But at this time ffdshow will need the xy chromacity of output device. That's just my opinion. I could be wrong.

EDIT: I have a mistake. When input xy chromacity is larger than output xy chromacity, ffdshow have two ways. One is to ignore the input chromacity and adjust RGB with output. Another is to keep the input chromacity and cut off the colors beyond the output chromacity into inside of it. My textbook of color management says there are some ways to cut off colors outside into inside and it's difficult to select one from them.

transfer_characteristics is famous for gamma correction. CRT monitors can't display simple gradations linearly, but shows a curve. But we want to display simple gradations linearly so we gives a curve to RGB before CRT displays it. The strength of how much we should bend the linear curve is determined by the spec of CRT monitors. transfer_characteristics tells you about the bentness of the curve.

Originally, transfer characteristics is only for CRT monitors. But we need give gamma correction to videos before CRT displays it, so even if we use LCD monitors, not CRT monitors, videos have already given gamma correction to. Then LCD monitors have transfer characteristics, too, involuntarily.

Not only as above, but gamma curve is connected with xy chromacity. Then when ffdshow manage colour_primaries, ffdshow should manage transfer_characteristics at the same time.

That' the reason why I say video_full_range_flag is connected with matrix_coefficients while colour_primaries is connected with transfer_characteristics. I think the effects are stronger when I change x264's --fullrange and --colormatrix than x264's --colorprim and --transfer.

Sorry for that my explanation becomes so long.

[tobinaka]

Oh, my post is too late... :(

[STaRGaZeR]

Oh, my post is too late... :(

It's never too late for that kind of posts! http://www.xtremesystems.org/forums/images/smilies/thumbsup.gif

[haruhiko_yamagata]

Thank you very much. If I understand correctly,
To decode YCbCr to RGB, video_full_range_flag and matrix_coefficients should be used.
After knowing output device's color primaries, ffdshow may use colour_primaries and transfer_characteristics to 'calibrate' the RGB values (this isn't planed for now).

[haruhiko_yamagata]

"video_full_range_flag" is a special flag which is often set incorrectly in broadcasts. E.g. older SkyHD and PremiereHD broadcasts have it all set to "1" although the correct value would be "0". Newer PremiereHD broadcasts have it set correctly. So it might be better to ignore it. All current PC h264 decoders seem to ignore it. If you actually honored this flag, playback of older SkyHD and PremiereHD broadcasts would produce incorrect output.
CoreAVC does not ignore it if "Input levels" is set to "Auto detect" (default).
As for premiere HD, it is 1 as it should. I think it's true full range as far as I tested premiere-paff.ts. Although it looks better with standard range, it has some "blacker than black".

[madshi]

CoreAVC does not ignore it if "Input levels" is set to "Auto detect" (default).
Didn't know that. I never set it to "Auto detect". Currently using ATI hardware accelerated h264 decoding, anyway.

As for premiere HD, it is 1 as it should. I think it's true full range as far as I tested premiere-paff.ts. Although it looks better with standard range, it has some "blacker than black".
It is 1 for older PremiereHD broadcasts, but 0 for newer PremiereHD broadcasts. And I think the image is correct with 0 and not with 1. The same problem occurs with SkyHD broadcasts. I don't know how newer SkyHD broadcasts have set the flag, but older SkyHD broadcasts have set it to 1.

There are reports from people who have decoding problems with SkyHD broadcasts on their NMT media players due to this flag being set incorrectly. They claim that the image is wrong, unless they change the flag. The SkyHD satellite box seems to ignore the flag.

[madshi]

First, I will create the possibility of 8bit, then I will add the possibility of other bit depths. If tritical wants to add dithering in a rgb3dlut future version the 3D lut file will already exist...;)
Of course this only makes sense for 8bit input.
Why would that only make sense for 8bit input? Dithering is *always* recommended, if you go from a higher bitdepth to a lower bitdepth.

[tetsuo55]

64bit per color primary, of course.
Do you see the banding when? Always, or when you are using our color correction methods?

I see banding straight from source, without editing the image.
I can almost completely get rid of it with avisynth filters, but these are far from realtime...

Since we are doing the RGB conversion anyway we might as well apply dithering in that fase

Yes, but even if you buy one for $400 you cannot work in 10bit mode, XP and Vista do not support it. You cannot have a 10bit per component desktop resolution.

10bit works just fine and has done so for a long time, there are even 16bit videocards(not consumer products though)

The only catch is you must use DVI, and your DVI display has to tell the videocard it supprts 10bit to make the option available.

This monitor is going to cost you an arm and a leg though :P

Why would that only make sense for 8bit input? Dithering is *always* recommended, if you go from a higher bitdepth to a lower bitdepth.

Exactly, if FFdshow currently does it with 64 bits per primary all we need to add really is that Floyd-Steinberg dithering.
That should remove any and all banding, even if the source is a banding-fest

[madshi]

10bit works just fine and has done so for a long time, there are even 16bit videocards(not consumer products though)

The only catch is you must use DVI, and your DVI display has to tell the videocard it supprts 10bit to make the option available.
10bit is only available for YCbCr and only in 4:2:2. It's not available for RGB until HDMI 1.3. And I don't think Windows can output YCbCr in XP+Vista.

Exactly, if FFdshow currently does it with 64 bits per primary all we need to add really is that Floyd-Steinberg dithering.
That should remove any and all banding, even if the source is a banding-fest
Normal dithering does *not* get rid of banding in the source. It just reduces/eliminates banding caused by bitdepth reduction.

Dithering can help getting rid of source banding, if you use more dithering than you would normally use. But that would be a special post processing filter which should (if available at all) be strictly optional.

Proper dithering helps us getting as near to the original source data as possible (perceptually), while artificially increased dithering is a post processing filter which actually does the opposite: It intentionally changes the original source data. So these two kinds of dithering should be strictly separated.

[Px]

First at all, look at the results of my comparing.
http://www.tobinaka.com/files/matrix_fullrange2.bmp (It's 1040x600 bmp)
Am I see right, that picture 2 must be same as 1 and 6, but it differs?

[yesgrey]

But those equations are for TV range. How about full scale? Change the last equations like that:
Y = 255 * Ey
Cb = 255 * Epb
Cr = 255 * Epr

Excellent post tobinaka! Just a small correction, for full scale the equations are:
Y = 255 * Ey
Cb = 255 * Epb + 128
Cr = 255 * Epr + 128

After knowing output device's color primaries, ffdshow may use colour_primaries and transfer_characteristics to 'calibrate' the RGB values (this isn't planed for now).
This is what's done by the 3D LUT we are talking about. When you find the time to include the 3D LUT, ffdshow will support it.;)

Why would that only make sense for 8bit input?
Well, the formula for calculating the size of the 3D LUT in bytes is:
3*(2^(n.bit in))^3*(n.bit out)/8

So, for n.bit source/ n. bit output:
-8/8: 48MB
-8/16: 96MB
-9/9: 432MB
-10/10: 3840MB
Do you think it makes any sense using a 3D LUT with almost 4GB size? Even one with 432MB is a bit unreasonable...;)
But since the sources are all 8 bit, we can go for the 8/16, which gives 96MB, which is still a reasonable size.

I see banding straight from source, without editing the image.
Well, then you have to find a better source, or your YCbCr->RGB conversion is flawed. The problem is not related with the gammut conversion.

The only catch is you must use DVI, and your DVI display has to tell the videocard it supprts 10bit to make the option available.

Have you seen this working? I am asking because it doesn't make sense to me. Any crt can easilly support more than 8 bit (it's analog), and all the graphic cards dacs are already 10 or 12 bit, so why do not enable the option for the crt users?

[leeperry]

Any crt can easilly support more than 8 bit (it's analog), and all the graphic cards dacs are already 10 or 12 bit, so why do not enable the option for the crt users?
you get 10 bits gamma correction on a CRT using an nvidia card(it said 9 bits for ati 3850/2600)...the ARGYLLCMS package has a tool to check the LUT accuracy, but you can only output 8 bits video...if that makes any sense :D

the LUT's compress really well(48>1mb in RAR) so if that dithering stuff actually makes a difference, it's most welcome :)

[tobinaka]

Excellent post tobinaka! Just a small correction, for full scale the equations are:
Y = 255 * Ey
Cb = 255 * Epb + 128
Cr = 255 * Epr + 128


I corrected my privious post. Thank you yesgrey3.

Note: 10bit YUV, even with TV range used, will have less banding and less quantization errors in RGB<->YUV convertions.

[yesgrey]

so if that dithering stuff actually makes a difference, it's most welcome :)
I don't think it will...

[leeperry]

I don't think it will...
I don't think either, I believe tritical's algorithms are plenty accurate already for 8 bits resolution :cool:

call me crazy, but that precalculated LUT stuff is clearly more accurate than the old realtime 3D LUT to me, just like tritical said...colors have never looked so good, better than that doesn't seem achievable IMHO, or not w/o a true spectrophotometer thingie anyway :D

[madshi]

Well, the formula for calculating the size of the 3D LUT in bytes is:
3*(2^(n.bit in))^3*(n.bit out)/8

So, for n.bit source/ n. bit output:
-8/8: 48MB
-8/16: 96MB
-9/9: 432MB
-10/10: 3840MB
Do you think it makes any sense using a 3D LUT with almost 4GB size? Even one with 432MB is a bit unreasonable...;)
But since the sources are all 8 bit, we can go for the 8/16, which gives 96MB, which is still a reasonable size.
Ouch. Didn't know this formula.

I still think that we should handle all this more pragmatically. It seems to me that you guys want to combine 3D LUT conversion with dithering (or am I wrong?). I don't think that's a good approach. IMHO the dithering should be done in a separate step and only if it's really necessary. I think it should ideally be done like this:

(1) Any YCbCr to RGB conversion (regardless of whether 3D LUT correction is involved or not) should be done to a reasonably high RGB output bitdepth (e.g. 16bit).
(2) If 3D LUT correction is done, it should work with the full input bitdepth and output a reasonably high output bitdepth (e.g. 16bit).
(3) If the display process doesn't support outputting the RGB data in the full calculation bitdepth (e.g. 16bit), the bitdepth needs to be dithered down to whatever bitdepth the display process supports.

I think step (3) should be a separate step and not part of the 3D LUT processing, so that it can also be used if 3D LUT processing is turned off.

I don't think it will...
Why?

[tetsuo55]

Ouch. Didn't know this formula.

I still think that we should handle all this more pragmatically. It seems to me that you guys want to combine 3D LUT conversion with dithering (or am I wrong?). I don't think that's a good approach. IMHO the dithering should be done in a separate step and only if it's really necessary. I think it should ideally be done like this:

(1) Any YCbCr to RGB conversion (regardless of whether 3D LUT correction is involved or not) should be done to a reasonably high RGB output bitdepth (e.g. 16bit).
(2) If 3D LUT correction is done, it should work with the full input bitdepth and output a reasonably high output bitdepth (e.g. 16bit).
(3) If the display process doesn't support outputting the RGB data in the full calculation bitdepth (e.g. 16bit), the bitdepth needs to be dithered down to whatever bitdepth the display process supports.

I think step (3) should be a separate step and not part of the 3D LUT processing, so that it can also be used if 3D LUT processing is turned off.

I completely agree with this system.

Current RGB<->YCbCr is done in 64bit
A 64bit 3DLUT table is going to be HUGE!

Step 3 should indeed be a choice between either rounding(fast) or dithering(slow)

I have seen many examples of rounding VS dithering, and i have always prefered the dithered image to the rounded one.

[haruhiko_yamagata]

As requested, here's a sample
http://www.zshare.net/download/54358430d47a4775/
//Danne
Thank you. I can reproduce.

[tobinaka]

I don't know there have already shown the coefficients or the equations to convert between RGB and YUV with various ways. I think haruhiko_yamagata, or other developers, has already known them, but for reference at least, I show here the process to determined the equations to reconvert YUV into RGB in 8bit from those to RGB->YUV.

Now, let's start from H.264's Annex.E where the equations below are shown.
E'Y = KR * E'R + ( 1 - KR - KB ) * E'G + KB * E'B ... (E-13)
E'PB = 0.5 * ( E'B - E'Y ) / ( 1 - KB ) ............. (E-14)
E'PR = 0.5 * ( E'R - E'Y ) / ( 1 - KR ) ............. (E-15)

The details of the values:

Kr and Kb .... The coefficients given from matrix_coefficient such as BT.601, BT.709 and so on.
Analog ErEgEb .... Er, Eg and Eb range from 0 to 1
Analog EyEpbEpr .... Ey ranges from 0 to 1, Epb and Epr range from -0.5 to 0.5
Digital RGB .... R, B and G range from 0 to 255
Digiital TV range YUV .... Y ranges from 16 to 235, U and V range from 16 to 240
Digital full range YUV .... Y, U and V range from 0 to 255


Input (or substitute) Ey into the equations of Epb and Epr.
Ey = Kr * Er + ( 1 - Kr - Kb ) * Eg + Kb * Eb

Epb = 0.5 * ( Eb - Ey ) / ( 1 - Kb )
= 0.5 * [ Eb - { Kr * Er + ( 1 - Kr - Kb ) * Eg - Kb * Eb } ] / ( 1 - Kb )
= 0.5 * { - Kr * Er - ( 1 - Kr - Kb ) * Eg + ( 1 - Kb ) * Eb } / ( 1 - Kb )

Epr = 0.5 * ( Er - Ey ) / ( 1 - Kr )
= 0.5 * { ( 1 - Kr ) * Er - ( 1 - Kr - Kb ) * Eg - Kb * Eb } / ( 1 - Kr )

Then let's get analog RGBs(Er, Eg, Eb) from Ey, Epb and Epr.
Epb = 0.5 * ( Eb - Ey ) / ( 1 - Kb )
Eb = Epb * ( 1 - Kb ) * 2 + Ey

Epr = 0.5 * ( Er - Ey ) / ( 1 - Kr )
Er = Epr * ( 1- Kr ) * 2 + Ey

Ey = Kr * Er + ( 1 - Kr - Kb ) * Eg + Kb * Eb
Eg = ( Ey - Kr * Er - Kb * Eb ) / ( 1 - Kr - Kb )
= [ Ey - Kr * { Epr * ( 1- Kr ) * 2 + Ey } - Kb * { Epb * ( 1 - Kb ) * 2 + Ey } ] / ( 1 - Kr - Kb )
= Ey - { 2 * Kr * ( 1 - Kr ) / ( 1 - Kr - Kb ) } * Epr - { 2 * Kb * ( 1 - Kb ) / ( 1 - Kr - Kb ) } * Epb


Now you have the equations to convert between analog RGB and analog YUV. Note there are still the given coefficients without change.
Ey = Kr * Er + ( 1 - Kr - Kb ) * Eg + Kb * Eb
Epb = 0.5 * { - Kr * Er - ( 1 - Kr - Kb ) * Eg + ( 1 - Kb ) * Eb } / ( 1 - Kb )
Epr = 0.5 * { ( 1 - Kr ) * Er - ( 1 - Kr - Kb ) * Eg - Kb * Eb } / ( 1- Kr )

Er = Epr * ( 1 - Kr ) * 2 + Ey
Eg = Ey - { 2 * Kr * ( 1 - Kr ) / ( 1 - Kr - Kb ) } * Epr + { 2 * Kb * ( 1 - Kb ) / ( 1 - Kr - Kb ) } * Epb
Eb = Epb * ( 1 - Kb ) * 2 + Ey


Next time, prepare the equations to convert RGB and YUV between analog and digital.

between analog RGB and digital RGB
R = 255 * Er
G = 255 * Eg
B = 255 * Eb

Er = R / 255
Eg = G / 255
Eb = B / 255

between TV range analog YUV and TV range digital YUV
Y = 219 * Ey + 16
U = 224 * Epb + 128
V = 224 * Epr + 128

Ey = ( Y - 16 ) / 219
Epb = ( U - 128 ) / 224
Epr = ( V - 128 ) / 224

between full range analog YUV and full range digital YUV
Y = 255 * Ey
U = 255 * Epb + 128
V = 255 * Epr + 128

Ey = Y / 255
Epb = ( U - 128 ) / 255
Epr = ( V - 128 ) / 255


Finally, input Kb and Kr (the given coefficients), and digital RGB and YUV into the equations of analog RGB and YUV. In this way, you can get all RGB<->YUV equations whatever coefficients are given by matrix_coefficient flag, especially for full range YUV.

[tritical]

Why?
I'm not yesgrey3, but I do agree with him here... most sources played with ffdshow are lossy compressed in yv12. The amount of correlated quantization error introduced by the compression process and conversion to yv12 is going to far outweigh that introduced by conversion from floating point rgb to 8-bit/channel rgb after the rgb and gamut conversions. In other words, you'd have to have a very high quality source for the quantization error introduced by conversion to 8-bit per channel rgb to create a noticeable degradation. Simply adding dithering during the rgb conversion will do nothing to eliminate banding or other quantization artifacts already present in the source.

[tetsuo55]

I'm not yesgrey3, but I do agree with him here... most sources played with ffdshow are lossy compressed in yv12. The amount of correlated quantization error introduced by the compression process and conversion to yv12 is going to far outweigh that introduced by conversion from floating point rgb to 8-bit/channel rgb after the rgb and gamut conversions. In other words, you'd have to have a very high quality source for the quantization error introduced by conversion to 8-bit per channel rgb to create a noticeable degradation. Simply adding dithering during the rgb conversion will do nothing to eliminate banding or other quantization artifacts already present in the source.

Is it possible though, to add a debanding function to the rgb conversion? And if so will that be more accurate than a seperate debanding step?

[madshi]

I'm not yesgrey3, but I do agree with him here... most sources played with ffdshow are lossy compressed in yv12. The amount of correlated quantization error introduced by the compression process and conversion to yv12 is going to far outweigh that introduced by conversion from floating point rgb to 8-bit/channel rgb after the rgb and gamut conversions. In other words, you'd have to have a very high quality source for the quantization error introduced by conversion to 8-bit per channel rgb to create a noticeable degradation. Simply adding dithering during the rgb conversion will do nothing to eliminate banding or other quantization artifacts already present in the source.
It's clear that using dithering for downconversion to 8bit will not fix any problems that are already in the source. However, I'm thinking along the lines of: What if there's a YCbCr value which when properly converted to RGB ends up with e.g. RGB (95.5, 95.5, 95.5). And what if there's a large color area using this exact color? With simple rounding the whole area would be (96, 96, 96). Wouldn't that be a noticable degradation? With dithering roughly half of the pixels would be (95, 95, 95) and the other half (96, 96, 96), which would be a much more accurate downconversion...

Edit: And I think this inaccurateness with simple rounding *can* eventually result in increased banding. E.g. what if there is a color fade which in floating point RGB would have steps like e.g. 90.4, 91.5. With simple rounding we would get 90 and 92, but no 91. With dithering we would get a dithered mixture of values 90, 91 and 92. The rounding would IMHO be in danger of adding visible banding, while there would be no such danger when using dithering.

[mark0077]

In my opinion, dithering creates an ugly effect. I rather 96 than half 95 and half 96 in your case..... but thats just me. I am basing my view really on old 16bit dithering years ago on games which looked so bad compared to normal 16bit color.

[tetsuo55]

In my opinion, dithering creates an ugly effect. I rather 96 than half 95 and half 96 in your case..... but thats just me. I am basing my view really on old 16bit dithering years ago on games which looked so bad compared to normal 16bit color.

That dithering sucks bad. The dithering was done with +/- 5 bits per component

Correct dithering will be invisible at the correct seating distance. Not to mention the fact that ffdshow does its RGB conversion with 64bits per component!

[leeperry]

Is it possible though, to add a debanding function to the rgb conversion?
did you try deband()? it looks UGLY :eek:

[tetsuo55]

did you try deband()? it looks UGLY :eek:

Yep i did, and yes i saw.

the best result for debanding i have seen was actually a 10bit per component dithering.

[yesgrey]

I still think that we should handle all this more pragmatically.
It seems to me that you guys want to combine 3D LUT conversion with dithering (or am I wrong?).
No, I don't want to combine the 3D LUT with dithering, I only said that it could be a possibility, but I don't agree with it. It will slow down very much all the processing and probably without any benefit.
Why?
In fact, I'm very pragmatic, and since I've learned that YCbCr has less than 25% of the colors available in RGB (read this (http://www.poynton.com/PDFs/Merging_RGB_and_422.pdf) paper by Charle's Poynton) I have thought that's probably one of the reasons why I never had see banding with the color correction we are performing.
I think it should ideally be done like this...
I think you haven't understood completelly the 3D LUT thing...
In the beggining, the idea was only for color correction, but now, me and tritical, have extended it to also include the YCbCr->RGB conversion.
So, you can map a YCbCr value with the 3D LUT and it will output a RGB value. Currently, The YCbCr input is limited to YUY2, but maybe tritical could also add YV12 input support, and then we could use directly the output of the video decoders.
The 3D LUT is created using 64bit floating point per component in all stages, the roundings are all done only when creating the 3D LUT file, and will be to the output bit depth desired by the user. Currently, we only can use 8bit output, but maybe in the future, with Windows7, we can use a 3D LUT with 16bit output...

Wouldn't that be a noticable degradation? With dithering roughly half of the pixels would be (95, 95, 95) and the other half (96, 96, 96)
This logic only is valid if you have the full RGB colors available, and you don't, you will have less than 25% of it... and also remember, that probably you will not notice that color difference. When you notice banding, it's not color differences of only 1...

I think this discussion is becoming a little off-topic here... maybe it's better continuing it in the gammut correction thread, where ddcc was launched...

[madshi]

@yesgrey3,

sounds good to me, thanks.

Do you plan to replace the current "high quality RGB32" option in ffdshow with the new 3D LUT algorithm?

[Wilbert]

In fact, I'm very pragmatic, and since I've learned that YCbCr has less than 25% of the colors available in RGB (read this paper by Charle's Poynton) I have thought that's probably one of the reasons why I never had see banding with the color correction we are performing.
You will get that number if you start with 8-bit RGB and convert it to YCbCr [16,235]. I wonder how that number changes if you start with 10-bit RGB or whatever the studios use.

[SBeaver]

I can't seek in MLP audio tracks.
Is this a bug or a limitation?

[yesgrey]

You will get that number if you start with 8-bit RGB and convert it to YCbCr [16,235]. I wonder how that number changes if you start with 10-bit RGB or whatever the studios use.
You will always end with 8-bit YCbCr (that's what you get in the current consumer sources), so when you convert back to 8-bit RGB you will always get the < 25% number...

[ikarad]

Oh, I see. If I check both AC3 and LPCM in MPC, it works.

I hope a lpcm HD support as soon as possible.

[madshi]

Hey guys,

have been in contact with a Microsoft dev and he told me that the "official" Microsoft GUID for TrueHD is this:

DEFINE_GUID(MEDIASUBTYPE_DOLBY_TRUEHD, 0xeb27cec4, 0x163e, 0x4ca3, 0x8b, 0x74, 0x8e, 0x25, 0xf9, 0x1b, 0x51, 0x7e);

Could you please add this to your TrueHD decoder (in case you haven't already)? Thanks!

[nautilus7]

Does this mean that we'll be able to mux TrueHD to matroska now (as long as support from mkvmerge is added)?

[albain]

Hey guys,

have been in contact with a Microsoft dev and he told me that the "official" Microsoft GUID for TrueHD is this:

DEFINE_GUID(MEDIASUBTYPE_DOLBY_TRUEHD, 0xeb27cec4, 0x163e, 0x4ca3, 0x8b, 0x74, 0x8e, 0x25, 0xf9, 0x1b, 0x51, 0x7e);

Could you please add this to your TrueHD decoder (in case you haven't already)? Thanks!

Okay, I am on it but I won't have time to do it until monday.

I can't seek in MLP audio tracks.
Is this a bug or a limitation?



Concerning seeking on MLP, the problem is related to the parser.
The problem with this format is that there are not sync keywords for each frames, and this is (I think) the reason why the parser messes up when seeking is done

Regards,

Damien BT

[madshi]

Does this mean that we'll be able to mux TrueHD to matroska now (as long as support from mkvmerge is added)?
No, this is strictly Windows DirectShow stuff. Has nothing to do with MKV muxing, I think.

[haruhiko_yamagata]

Patch (http://ffdshow-tryout.sourceforge.net/samples/20080124a.patch)
Build (http://ffdshow-tryout.sourceforge.net/samples/ffdshow_rev2631_20090124_Q.exe)

Please correct the tool tips. Discussion is welcome, of course.
Fraps auto detecting is not implemented yet (will do).

[nautilus7]

No, this is strictly Windows DirectShow stuff. Has nothing to do with MKV muxing, I think.
So, it is an "internal" matroska issue. Thanks.

P.S sorry for the off topic.

[yesgrey]

Discussion is welcome, of course.
For me it's good. As I have said, I think you had enough information to make a good decision.

Just some minor things...
Since you decided to use the correct designation YCbCr in the specification group, I think it should also be used in the levels description... ( Y: 16-235; CbCr: 16-240)
I prefer the look without using spaces between the brackets. For example: instead of ( RGB: 0 - 255 ), I prefer (RGB: 0-255). Just cosmetic, nothing more.
If the spaces should be used, then the last field misses one space... (RGB: 16 - 235 ) should be: ( RGB: 16 - 235 );)

And... Thank you very much for your work.
:thanks:

[madshi]

For me it's good. As I have said, I think you had enough information to make a good decision.

Just some minor things...
Since you decided to use the correct designation YCbCr in the specification group, I think it should also be used in the levels description... ( Y: 16-235; CbCr: 16-240)
I prefer the look without using spaces between the brackets. For example: instead of ( RGB: 0 - 255 ), I prefer (RGB: 0-255). Just cosmetic, nothing more.
If the spaces should be used, then the last field misses one space... (RGB: 16 - 235 ) should be: ( RGB: 16 - 235 );)

And... Thank you very much for your work.
:thanks:
I agree with everything yesgrey3 said.

I also like the way the h264 "video_full_range_flag" is handled!

Some additional small corrections:

(1) The hint for "Auto" input levels says: "Some people says ...". It should read "Some people say ...".
(2) The hint for "Standard" input says: "Nealy". It should read "Nearly".
(3) The hint for "Standard" input says: "For JPEG and MJPEG, full range is used". I'm not sure what this means exactly. Does it mean that ffdshow automatically uses full range when JPEG and MJPEG sources are detected? Or does it mean that the user is supposed to switch to "full range" for JPEG and MJPEG sources? Maybe the hint could be clarify that. In the first case I'd suggest: "For JPEG and MJPEG, ffdshow automatically uses full range". In the latter case I'd suggest "For JPEG and MJPEG please use full range".
(4) There's no hint for "Full range" input. Maybe: "JPEG, MJPEG and FRAPS sources usually use this".
(5) Cosmetical: I'd suggest to put two spaces between the label caption and the "(" bracket.

Thanks - the changes are much appreciated!

[haruhiko_yamagata]

@yesgrey3: Thank you for comment. I'll fix the dialog.
"For JPEG and MJPEG, ffdshow automatically uses full range".
"JPEG, MJPEG and FRAPS sources usually use this".
I'll use these.

[mark0077]

Excellent to see these options. I assume the new high quality conversions havn't been implemented in this release?

Once all of this output/input stuff is finished I would love to build up a list of de-interlacing tests and improve the detection of interlaced vs progressive because on many of my friends machines, this bad detection causes huge drops in quality....

[madshi]

P.S: Just checked out "wmcodecdsp.h" in the Windows SDK. There are a number of interesting GUIDs in there:

DEFINE_GUID(MEDIASUBTYPE_MSAUDIO1, 0x00000160, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMAUDIO2, 0x00000161, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMAUDIO3, 0x00000162, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMAUDIO_LOSSLESS, 0x00000163, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMASPDIF, 0x00000164, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_MPEG_ADTS_AAC, 0x00001600, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_MPEG_RAW_AAC, 0x00001601, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_NOKIA_MPEG_ADTS_AAC, 0x00001608, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_NOKIA_MPEG_RAW_AAC, 0x00001609, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_VODAFONE_MPEG_ADTS_AAC, 0x0000160A, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_VODAFONE_MPEG_RAW_AAC, 0x0000160B, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_DOLBY_DDPLUS, 0xa7fb87af, 0x2d02, 0x42fb, 0xa4, 0xd4, 0x5, 0xcd, 0x93, 0x84, 0x3b, 0xdd);
DEFINE_GUID(MEDIASUBTYPE_DOLBY_TRUEHD, 0xeb27cec4, 0x163e, 0x4ca3, 0x8b, 0x74, 0x8e, 0x25, 0xf9, 0x1b, 0x51, 0x7e);
DEFINE_GUID(MEDIASUBTYPE_DTS_HD, 0xa2e58eb7, 0xfa9, 0x48bb, 0xa4, 0xc, 0xfa, 0xe, 0x15, 0x6d, 0x6, 0x45);
I'd suggest adding support for DOLBY_DDPLUS, DOLBY_TRUEHD and DTS_HD. I think DOLBY_DDPLUS and DTS_HD should be treated just the same way as the conventional AC3 and DTS GUIDs, though...

[tetsuo55]

Excellent to see these options. I assume the new high quality conversions havn't been implemented in this release?

Once all of this output/input stuff is finished I would love to build up a list of de-interlacing tests and improve the detection of interlaced vs progressive because on many of my friends machines, this bad detection causes huge drops in quality....

Yeah this is a good idea,

We need to find as many difficult samples as possible so we can create the ultimate detection algorithm

[Mercury_22]

ffdshow_rev2632_20090124_xxl_mt.exe it's crashing all my AVC ! :helpful: :mad:


P.S. I have No problem with ffdshow_rev2631_20090123_sse_icl10 or ffdshow_rev2631_20090123_x64 also I had no problems with MT until now:D

[alexins]

ffdshow_rev2632_20090124_xxl_mt.exe it's crashing all my AVC ! :helpful: :mad:


P.S. I have No problem with ffdshow_rev2631_20090123_sse_icl10 or ffdshow_rev2631_20090123_x64 also I had no problems with MT until now:D


The problem is the build libavcodec.dll. Because of this, I did not publish this revision on its website.

[STaRGaZeR]

No, this is strictly Windows DirectShow stuff. Has nothing to do with MKV muxing, I think.

Do you know how's in charge of adding support for new formats in Matroska? We need TrueHD support badly :D

[haruhiko_yamagata]

Excellent to see these options. I assume the new high quality conversions havn't been implemented in this release?Not yet.

Once all of this output/input stuff is finished I would love to build up a list of de-interlacing tests and improve the detection of interlaced vs progressive because on many of my friends machines, this bad detection causes huge drops in quality....
Interesting, though I'm not sure if I can handle it.

[albain]

P.S: Just checked out "wmcodecdsp.h" in the Windows SDK. There are a number of interesting GUIDs in there:

DEFINE_GUID(MEDIASUBTYPE_MSAUDIO1, 0x00000160, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMAUDIO2, 0x00000161, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMAUDIO3, 0x00000162, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMAUDIO_LOSSLESS, 0x00000163, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_WMASPDIF, 0x00000164, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_MPEG_ADTS_AAC, 0x00001600, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_MPEG_RAW_AAC, 0x00001601, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_NOKIA_MPEG_ADTS_AAC, 0x00001608, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_NOKIA_MPEG_RAW_AAC, 0x00001609, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_VODAFONE_MPEG_ADTS_AAC, 0x0000160A, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_VODAFONE_MPEG_RAW_AAC, 0x0000160B, 0x0000, 0x0010, 0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71);
DEFINE_GUID(MEDIASUBTYPE_DOLBY_DDPLUS, 0xa7fb87af, 0x2d02, 0x42fb, 0xa4, 0xd4, 0x5, 0xcd, 0x93, 0x84, 0x3b, 0xdd);
DEFINE_GUID(MEDIASUBTYPE_DOLBY_TRUEHD, 0xeb27cec4, 0x163e, 0x4ca3, 0x8b, 0x74, 0x8e, 0x25, 0xf9, 0x1b, 0x51, 0x7e);
DEFINE_GUID(MEDIASUBTYPE_DTS_HD, 0xa2e58eb7, 0xfa9, 0x48bb, 0xa4, 0xc, 0xfa, 0xe, 0x15, 0x6d, 0x6, 0x45);
I'd suggest adding support for DOLBY_DDPLUS, DOLBY_TRUEHD and DTS_HD. I think DOLBY_DDPLUS and DTS_HD should be treated just the same way as the conventional AC3 and DTS GUIDs, though...

I will add those too. Let's hope that the splitters will be updated soon too

*EDIT* : done in revision 2635

[madshi]

I will add those too. Let's hope that the splitters will be updated soon too

*EDIT* : done in revision 2635
Thanks! I've already notified the MPC HC guys and also Nero, so I hope that at least those two splitters will be updated sooner or later...

[SledgeHammer_999]

Hey guys, I have problems with latest builds from albain/clsid/xxl. They all temporarely "pause" after some seconds of playback of a certain file. The thing is I don't know if I am allowed(by the forum rules) to link to the torrent file(it is a fansub of an anime ep).

EDIT: rev2615 works fine. The "pausiness" exists in 2630/2635/2636/2633(mt)

[iron2000]

Not sure if its me only but for 2636, after I merge my settings from 2630 I will get an error when playing Xvid or DivX files.
Using MPC to play, WMP10 will freeze and spout a second then third process, end task before more could appear.

2635 is fine, using that now.

[Inspector.Gadget]

Now that the new GUIDs are in place, what happens with the different audio formats? As I understand it:
AC3 -> libavcodec or liba52 decoding.
EAC3 -> libavcodec decoding.
MLP/THD -> libavcodec decoding.
DTS -> libavcodec or libdts decoding.
DTS-HD -> libavcodec decoding of DTS core?
DTS-HD MA -> libavcodec decoding of DTS core?

Is this right? Thanks!

[madshi]

Now that the new GUIDs are in place, what happens with the different audio formats? As I understand it:
AC3 -> libavcodec or liba52 decoding.
EAC3 -> libavcodec decoding.
MLP/THD -> libavcodec decoding.
DTS -> libavcodec or libdts decoding.
DTS-HD -> libavcodec decoding of DTS core?
DTS-HD MA -> libavcodec decoding of DTS core?

Is this right? Thanks!
I would generally not trust in that GUID AC3 means that the actual data could not be E-AC3. Or GUID DTS can still contain DTS-HD data. So I think the new GUIDs should not improve anything for end users. It just means that hopefully splitters and decoders will be slightly more compatible with the new HD audio formats in the future than they were in the past.

[gruppo_sd]

for me crash when open all avi (divx-xvid), works with h264 an other.
excuse for bad english

[clsid]

Should be fixed now.

[clsid]

@Albain
Could you have a look at these bug reports:
http://sourceforge.net/tracker/index.php?func=detail&aid=2510125&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2517100&group_id=173941&atid=867360
http://sourceforge.net/tracker/index.php?func=detail&aid=2498294&group_id=173941&atid=867360

@Haruhiko
Could you have a look at this bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=2510125&group_id=173941&atid=867360

@Leak
Could you have a look at this bug report:
http://sourceforge.net/tracker/index.php?func=detail&aid=2528457&group_id=173941&atid=867360

[albain]

I use MPC-HC 976 and I can select LPCM soundtrack and I have sound

Try to disable haali's media splitter because before I used haali and with haali I could not listen lpcm soundtrack from blu-ray but It was 6 months ago


Hi,
That means that you played a blu-ray having an uncompressed 7.1 stream ?
I don't know if it possible for you to get a sample but I don't have any (I "only" have blurays with compressed TrueHD as highest quality, not with uncompressed streams)

I don't use haali's media splitter
I try an old version 2489 (but it is the same since mlp support in ffdshow (october or november)) and i d'ont have sound with mlp soundtrack.
when i play the sample from the beginning, there is no sound.
However, if I play the sample from the beginning and during the movie, If I move the cursor of the sliding bar (which indicates the current playing time) to another location, then the sound can be listened whatever 2489 or the last version.
I have the same problem for all blu-rays (that I own) including both lpcm and mlp soundtracks.
Is this always related to LPCM checkbox or can you hear sound when you check AC3 SPDIF ?


In all cases I suppose that you have an ATI 4xxx card that is able to bitstream LPCM 7.1 with high bitrates through the HDMI connector ?

If this is the case it will be hard to figure out because I only have SPDIF to test.

EDIT :
I have made a few tests. Actually, LPCM does work on regular AC3/DTS streams but not on TrueHD, but it may be due to my SPDIF bandwidth limitation.

[moshmothma]

I notice a another bug with ffdshow.
With some blu-ray, If I select MLP soundtrack, I have no sound



EDIT:I try an old version 2489 (but it is the same since mlp support in ffdshow (october or november)) and i d'ont have sound with mlp soundtrack.
when i play the sample from the beginning, there is no sound.
However, if I play the sample from the beginning and during the movie, If I move the cursor of the sliding bar (which indicates the current playing time) to another location, then the sound can be listened whatever 2489 or the last version.
I have the same problem for most of blu-rays (that I own) including both lpcm and mlp soundtracks.


I have the same issue. I have to move the slider before the sound will kick in (or alternately I can click on the subtitle option in the splitter output). I am using an ATI HDMI sound card. I have used various revs of MPC-HC filters along with different revs of ffdshow. This only happens with TrueHD. thx

[albain]

I remember this issue and it comes from the splitter that messes up with the frames. Casimir666 sent me a PM that he was implementing MLP splitting in MPCHC. I don't know if this is done by now.

However, it may also be a bug in FFDShow. Could you post a sample ?

[leeperry]

@Haruhiko : considering you're redoing the RGB32 conversion section in ffdshow, maybe you could use tritical's chroma upsampling algorithm ?

on tests patterns it looks really good :
http://forum.doom9.org/showpost.php?p=1242736&postcount=142

it's in ddcc's source code(http://bengal.missouri.edu/~kes25c/ddcc.zip), and I'm sure tritical wouldn't mind :D

also about OzoneMP, ffdshow works perfectly fine with FFX-4(from my friend Vincent Burel), so I'm now using Ozone3 DirectX with it in 32 bits float :

http://www.barryrudolph.com/mix/graphics/oz3stereo.gif

thing is FFX-4 shows its GUI when I play a file, but I've asked Vincent if he can disable that ;)

as you can see, Ozone is widely used :
http://www.head-fi.org/forums/f46/how-get-warmer-384571/#post5059409

:thanks: again for your fantastic work on ffdshow :cool:

[mark0077]

EDIT:

I found that avisynth's rgb32lut conversion that outputs rgb32, along with the use of libavcodec, causes ffdshow to do its own rgb32 conversion, which is not what is expected.

With libavcodec disabled, and using mpc-hc's mpeg2 decoder, ffdshow no longer seems to do the rgb32 conversion which is the expected behaviour.

[haruhiko_yamagata]

@Haruhiko : considering you're redoing the RGB32 conversion section in ffdshow, maybe you could use tritical's chroma upsampling algorithm ?
1 - linear interpolation (average u/v of first y with u/v of first y in next yuyv set)
Current ffdshow (HQ) and AviSynth's YUY2->RGB conversion use that algorithm. It's not perfect, it has an issue like this (http://img131.imageshack.us/my.php?image=comparisonzoomxr4.png).

What about my algorithm :D
Y0U0Y1V0 Y2U2Y3V2 Y4U4Y5V4 ...

newY1 = Y1
newU1 = (3*U0 + U2)/4

newY2 = Y2
newU2 = (U0 + 3*U2)/4

newY3 = Y3
newU3 = (3*U2 + U4)/4

newY4 = Y4
newU4 = (U2 + 3*U4)/4

AviSynth's YV12->YUY2 converter does this vertically, but it has limitation of output bit depth (naturally 8bit).
My implementation output 10bit vertical 75:25 averaging, 12 bit horizontal 75:25 averaging, other calculations are more than 10bit.

The implementation (patch (http://ffdshow-tryout.sourceforge.net/samples/newRGBconversion20090128.patch), build (http://ffdshow-tryout.sourceforge.net/samples/ffdshow_rev2640_20090128_Q.exe)).

20% faster than current "High quality YV12 to RGB conversion" with better quality. Make sure "High quality YV12 to RGB conversion" checked and have SSE2.
At this moment, YV12 progressive->RGB32 only.
Please wait a week or two, I'll add some more color spaces support. Maybe multithreading too. Please feel free to use my code in any GNU projects (under some other free software license, PM me).

// EDIT: 20% faster on Core2 Quad 9550 plus relatively slow memory. Maybe slower on 65nm Core2 or older and on system with very fast memory.

[madshi]

Current ffdshow (HQ) and AviSynth's YUY2->RGB conversion use that algorithm. It's not perfect, it has an issue like this (http://img131.imageshack.us/my.php?image=comparisonzoomxr4.png).

What about my algorithm :D

AviSynth's YV12->YUY2 converter does this vertically, but it has limitation of output bit depth (naturally 8bit).
My implementation output 10bit vertical 75:25 averaging, 12 bit horizontal 75:25 averaging, other calculations are more than 10bit.

The implementation (patch (http://ffdshow-tryout.sourceforge.net/samples/newRGBconversion20090128.patch), build (http://ffdshow-tryout.sourceforge.net/samples/ffdshow_rev2640_20090128_Q.exe)).

20% faster than current "High quality YV12 to RGB conversion" with better quality. Make sure "High quality YV12 to RGB conversion" checked and have SSE2.
Nice!!

In the image comparison you linked to is your new algorithm the one at the bottom of the comparison ("YV12 + Chroma Upscampler")?

[leeperry]

Current ffdshow (HQ) and AviSynth's YUY2->RGB conversion use that algorithm. It's not perfect, it has an issue like this (http://img131.imageshack.us/my.php?image=comparisonzoomxr4.png).
actually, these tests from mark0077 might be flawed, as he said himself here :
http://forum.doom9.org/showpost.php?p=1243013&postcount=156

here's ffdshow in RGB32/601 :

http://thumbnails.imagebam.com/2499/fe9a1124987333.gif (http://www.imagebam.com/image/fe9a1124987333)

and in RGB32HQ/601 :

http://thumbnails2.imagebam.com/2499/6a0f6e24987337.gif (http://www.imagebam.com/image/6a0f6e24987337)

this is tritical's ddcc :

http://thumbnails16.imagebam.com/2499/efa09524987327.gif (http://www.imagebam.com/image/efa09524987327)

and this is your new test build in RGB32HQ :

http://thumbnails13.imagebam.com/2499/058c4224987340.gif (http://www.imagebam.com/image/058c4224987340)

tritical explained it thorougly in this post :
http://forum.doom9.org/showpost.php?p=1235348&postcount=102

your new test build looks really good! :eek:

I will link your code in tritical's thread so you guys can discuss it :thanks:

please note that this is an extreme test pattern, the difference is hardly noticeable in movies, as shown here :
http://forum.doom9.org/showpost.php?p=1242783&postcount=149

but I'm kind of a nitpicker myself :D

the only TRUE difference is that yesgrey3's REC601/709 seem a lot more accurate than ffdshow's....the black background is actually R0-G0-B0 in ddcc, but in Convert()(full range 601)/ffdshow(full range 601) it's R2-G0-B1 :confused:

[haruhiko_yamagata]

the only TRUE difference is that yesgrey3's REC601/709 seem a lot more accurate than ffdshow's....the black background is actually R0-G0-B0 in ddcc, but in Convert()(full range 601)/ffdshow(full range 601) it's R2-G0-B1 :confused:
Does this still exist in the new build?

[leeperry]

Does this still exist in the new build?
it has improved a bit, now it's R2/G0/B0 :)

[haruhiko_yamagata]

it has improved a bit, now it's R2/G0/B0 :)
Could you send me the sample? I think (Y,Cb,Cr)-(16,128,128) is correctly mapped (0,0,0). The source may be slightly off (16,128,128).

[leeperry]

Could you send me the sample? I think (Y,Cb,Cr)-(16,128,128) is correctly mapped (0,0,0). The source may be slightly off (16,128,128).
http://rapidshare.com/files/122925763/Bronz_s.mkv.html http://forum-images.hardware.fr/images/perso/d4buff.gif

[haruhiko_yamagata]

Nice!!

In the image comparison you linked to is your new algorithm the one at the bottom of the comparison ("YV12 + Chroma Upscampler")?No. Mine is as good as "YV12".

[haruhiko_yamagata]

http://rapidshare.com/files/122925763/Bronz_s.mkv.html http://forum-images.hardware.fr/images/perso/d4buff.gif
The "black" is not black. It's (17,129,129). ffdshow is doing correct conversion. It is (R,G,B)=(3,0,1) as it should.

[leeperry]

The "black" is not black. It's (17,129,129). ffdshow is doing correct conversion. It is (R,G,B)=(3,0,1) as it should.
oops OK, I'll let yesgrey3 know :thanks:

[yesgrey]

haruhiko,
Nice work with the new YV12 algorythm!:)
Since you are working in that part of ffdshow's code, if you have the time could you add the option of using the 3D LUT? Remember that it's just loading the file in memory and then map the YCbCr or RGB data through it... The 3D LUT final goal would be a complete custumization of the output to match exactly the user's display, and the new YV12 algorythm will help increasing the quality!;)

oops OK, I'll let yesgrey3 know :thanks:
I will take a look at it...

[yesgrey]

leeperry,
I have tested with the exact same 3D LUT files and my results are:
BT.601: RGB[3,0,1]
BT.709: RGB[3,1,1]
Exactly the same values I get with ffdshow, so, both 3D LUT and ffdshow perform accurate conversions.
You should be doing something wrong... Try disabling the other filters you are using.

[mark0077]

Very impressed with the new ffdshow rgb32hq. Files are smaller than original rgb32hq and smaller than leeperry's (can't test properly because of some bug somewhere) posted code but look perfect.

Actually the new rgh32hq looks almost identical to Nvidias effort which is..... excellent!! GREAT STUFF

One final comment before I try and do a proper comparison with my machine, is there going to be an implementation of the two different REC.601's as I see in many posts there are two different ones.

[leeperry]

You should be doing something wrong... Try disabling the other filters you are using.
all I'm doing is colorYUV(levels="tv->pc") to output full range YUY2 + your 16-235 LUT(so it keeps the levels untouched and outputs 0-255).
I would appreciate one 601 and one 709 LUT for full range YUY2 if that's where the issue lies please.

I was also using colorYUV(levels="tv->pc") in the ffdshow tests, w/ ffdshow set to full range....so I guess the problem is w/ the LUT then?

[yesgrey]

so I guess the problem is w/ the LUT then?
There is no problem with the LUT.
What renderer have you used? I have used VMR9 in ZoomPlayer.
How are you measuring the RGB color?
I use this (http://www.iconico.com/colorpic/) free tool.

[leeperry]

There is no problem with the LUT.
What renderer have you used? I have used VMR9 in ZoomPlayer.
How are you measuring the RGB color?
I use this (http://www.iconico.com/colorpic/) free tool.
HR in RGB32, I used Photofiltre to check the screenshots(free alternative to Photoshop) :
http://photofiltre.free.fr/frames_en.htm

maybe you could try in full range in HR/RGB32 w/ colorYUV(levels="tv->pc") ?

[haruhiko_yamagata]

Since you are working in that part of ffdshow's code, if you have the time could you add the option of using the 3D LUT? Remember that it's just loading the file in memory and then map the YCbCr or RGB data through it... The 3D LUT final goal would be a complete custumization of the output to match exactly the user's display, and the new YV12 algorythm will help increasing the quality!;)
Well, if I have time.
We can use 3D LUT in AviSynth filter in ffdshow. For now, it's good enough for advanced users who can control 3D LUT.

[yesgrey]

Well, if I have time.
We can use 3D LUT in AviSynth filter in ffdshow. For now, it's good enough for advanced users who can control 3D LUT.
Yes, you're right. My request only makes sense if it would be faster using the 3D LUT directly inside ffdshow than using it via Avisynth filter in ffdshow. Do you think it would be faster, or would it be the same speed? If it would be the same speed, I think then we should forget about it and keep it the way it is, and use your time in improving other stuff...;)

[yesgrey]

maybe you could try in full range in HR/RGB32 w/ colorYUV(levels="tv->pc") ?
It's a ColorYUV problem. With it I get RGB[0,0,0] with the 3D LUT and with ffdshow. If you want accurate colors, do not use ColorYUV, or report the problem in Avisynth forum.

[leeperry]

It's a ColorYUV problem. With it I get RGB[0,0,0] with the 3D LUT and with ffdshow. If you want accurate colors, do not use ColorYUV, or report the problem in Avisynth forum.
I think I mixed the LUT's http://www.image-load.eu/out.php/i142320_slap.gif
I'll try again and PM you if required ;)

[mark0077]

Guys, will we have a new yuy2 => rgb32hq coming to compliment the excellent yv12 => rgb32hq?

[Leak]

In the image comparison you linked to is your new algorithm the one at the bottom of the comparison ("YV12 + Chroma Upscampler")?
I assume that's YV12 plus my "YV12 Chroma Upsampling" shader for MPC HC.

But that one is actually meant to be used with something that looks like the RGB32 sample in that picture, if you use it on something like the YV12 sample it'll just blur the chroma - not that this must be a bad thing, mind you...

np: New Order - Confusion (Power, Corruption & Lies Extras)

[Px]

Please wait a week or two, I'll add some more color spaces support
In such case, I want to request one feature - add to ffdshow ability to convert resulting picture from sRGB to Adobe RGB (Wide Gamut)
Short description of problem (why this option may be added): on wide gamut displays, when you play videos (which are sRGB), you have oversaturated colors on the picture.
More detailed explanation:
Working with color and software, the graphics card and monitor both operate not with physical measurement units but with some formal numbers, from 0 to 255 for each of the basic colors. For example, {0; 255; 0} is not green, it is just a set of numbers. It will become green if we assume that this set corresponds to the monitor’s showing a green subpixel.

So, the problem is that a green subpixel has different color on an ordinary monitor and on an extended-gamut monitor. It is greener on the latter. That is, it is purer, more saturated. If you put two such monitors next to each other and display the color {0; 255; 0} on both, you will see a pure green on the extended-gamut monitor and a green with a noticeable yellowish hue on the ordinary monitor.
...
As a result, monitors with an extended color gamut – which is extended relative to the standard sRGB gamut – will distort colors when displaying sRGB-oriented pictures prepared in sRGB-oriented software that does not know anything about non-sRGB monitors. The monitor will just stretch the sRGB-oriented picture out to fit its own gamut. Not only the pure colors, but also halftones will shift. The only exception is white and gray which are going to look correctly on any monitor unless the monitor is set up badly.
Source (http://www.xbitlabs.com/articles/monitors/display/samsung-sm-xl24-xl30_2.html#sect0)
I've searched in the Web for color space conversion samples, and find two sites, which can provide necessary functionality
http://www.color.org/sampleicc.xalter
http://www.littlecms.com/
Thanks! :)

[gonwk]

Hi folks,

Total newbie ... I was reading CLSID's 1st page pointer that it does not matter what version of FFDSHOW I should use ...

I have T5750 and ATI HD2600 card and my OS is Vista Home Prem., 64-bit ...

So I decided to try clsid r2639 ... my last version I forget what it was ... but I notice in this new version ... 3 of the file sizes are much smaller than my old version ... "ff_kernelDeint.dll" & "ffdshow.ax" & "libavcodec.dll".

Q1: Should I use the ICL version!?!?

Q2: When using DVDShrink ... the ffdshow Video & Audio icons pop-up in my Tray Bar ... is Shrink using FFDSHOW for Transcoding then?

Q3: I have a Greenish Color in my Preview Window ... which I fixed changing my DirectX Video Renderer in Shrink ... is there a fix with FFDSHOW or some other Codecs!?!?

Thanks,

G!:)

[jmartinr]

Current ffdshow (HQ) and AviSynth's YUY2->RGB conversion use that algorithm. It's not perfect, it has an issue like this (http://img131.imageshack.us/my.php?image=comparisonzoomxr4.png).

What about my algorithm :D

AviSynth's YV12->YUY2 converter does this vertically, but it has limitation of output bit depth (naturally 8bit).
My implementation output 10bit vertical 75:25 averaging, 12 bit horizontal 75:25 averaging, other calculations are more than 10bit.

Is this conversion not a sort of resize, giving lots of different possible methods?

[Jeremy Duncan]

understand you are talking about RGB?

I know a Secret about RGB and I will tell it to you now.
- If you open a "Gradient Ramp", you can actually see if the RGB range is good or not!

In the ffdshow version I'm using: 2547. There is a difference in quality depending on if I use full range or standard, in the RGB conversion tab.
This is using bt.601, and output RGB32, high quality yv12 to RGB conversion.

I have tested the same gradient ramp on powerdvd ultra and the result was a better looking gradient ramp, and the ps3 gives a better esult as well than the ffdshow version I'm using.

So, you need to use a gradient ramp to see the difference.
I will now show you what a gradient ramp is, in case you don't know already. :)

http://img90.imageshack.us/img90/8723/gradientrampfullrangezy0.th.png (http://img90.imageshack.us/my.php?image=gradientrampfullrangezy0.png)

[clsid]

Hi folks,

Total newbie ... I was reading CLSID's 1st page pointer that it does not matter what version of FFDSHOW I should use ...

I have T5750 and ATI HD2600 card and my OS is Vista Home Prem., 64-bit ...

So I decided to try clsid r2639 ... my last version I forget what it was ... but I notice in this new version ... 3 of the file sizes are much smaller than my old version ... "ff_kernelDeint.dll" & "ffdshow.ax" & "libavcodec.dll".

Q1: Should I use the ICL version!?!?

Q2: When using DVDShrink ... the ffdshow Video & Audio icons pop-up in my Tray Bar ... is Shrink using FFDSHOW for Transcoding then?

Q3: I have a Greenish Color in my Preview Window ... which I fixed changing my DirectX Video Renderer in Shrink ... is there a fix with FFDSHOW or some other Codecs!?!?

Thanks,

G!:)
1) The version you have now is fine.
2) If you see the icons, then it is using ffdshow for decoding. If you don't want that, put dvdschrink on the blacklist (ffdshow configuration -> directshow control).
3) That is a renderer bug.

[yesgrey]

In such case, I want to request one feature - add to ffdshow ability to convert resulting picture from sRGB to Adobe RGB (Wide Gamut)
Have you looked here (http://forum.doom9.org/showthread.php?t=139389)? That's what we are talking about...;) and it's alreading working in ffdshow.

[Px]

Have you looked here (http://forum.doom9.org/showthread.php?t=139389)?
No, I'll take a quick look and didn't find anything about wide gamut or Adobe RGB, but I'll read fully it tomorrow
and it's alreading working in ffdshow.
With Avisynth, yes? :rolleyes: I don't use Avisynth and wish that ffdshow do that without additional software :)

[yesgrey]

No, I'll take a quick look and didn't find anything about wide gamut or Adobe RGB
Was added in the new version released today, v1.7. I also already included it in my program for creating the 3D LUTs

With Avisynth, yes? :rolleyes: I don't use Avisynth and wish that ffdshow do that without additional software :)
Yes. Well, if you don't want to use Avisynth then you'll have to wait someone who will do it, which I think it's not a priprity, since we already have a working solution...
You just need to install Avisynth in your machine and use two lines in ffdshow's Avisynth filter.
Doing it in ffdshow will be a lot more work than this for one of the developers... and I think it's not fair asking ffdshow's developers to spend their time with something that is already working...;)

[gonwk]

1) The version you have now is fine.
2) If you see the icons, then it is using ffdshow for decoding. If you don't want that, put dvdschrink on the blacklist (ffdshow configuration -> directshow control).
3) That is a renderer bug.

Hi clsid,

THANKS for your reply!

G!:)

[madshi]

I assume that's YV12 plus my "YV12 Chroma Upsampling" shader for MPC HC.

But that one is actually meant to be used with something that looks like the RGB32 sample in that picture, if you use it on something like the YV12 sample it'll just blur the chroma - not that this must be a bad thing, mind you...
Not sure which quality is better, to be honest. The "YV12 Chroma Upsampling" image looks cleanest to me, but the red color seems to be slightly less saturated compared to the other 3 images.

( the comparison image I'm talking about (http://img131.imageshack.us/my.php?image=comparisonzoomxr4.png) )

[haruhiko_yamagata]

Yes, you're right. My request only makes sense if it would be faster using the 3D LUT directly inside ffdshow than using it via Avisynth filter in ffdshow. Do you think it would be faster, or would it be the same speed? If it would be the same speed, I think then we should forget about it and keep it the way it is, and use your time in improving other stuff...;)
On Core2 Quad 9550, premiere-paff.ts (H.264 1920x1080), yadif double framerate
Yadif in ffdshow (SSE2, SSSE3 and multithreading disabled): 31.0fps
Yadif in AviSynth: 27.1fps

The performance boost may not be negligible. Patches are welcome.

[haruhiko_yamagata]

Guys, will we have a new yuy2 => rgb32hq coming to compliment the excellent yv12 => rgb32hq?
Yep. I have added NV12 and RGB24. I'll add YUY2 and YV16.

[madshi]

Yep. I have added NV12 and RGB24. I'll add YUY2 and YV16.
Would it also make sense to add YV12 -> YUY2 conversion? I'm asking because the 3D LUT algorithm done by tcritical/yesgrey3 seems to want YUY2 input and having the option to let your new algorithm do YV12 -> YUY2 and then feed the result into the 3D LUT might be worthwhile?

[yesgrey]

The performance boost may not be negligible. Patches are welcome.
It will depend on which part is the bottleneck.
In the yadif example you pointed, the code you used in ffdshow is exactly the same used in avisynth?
If it is, then the avisynth wrapping in ffdshow could be the limiting part...

[haruhiko_yamagata]

Would it also make sense to add YV12 -> YUY2 conversion? I'm asking because the 3D LUT algorithm done by tcritical/yesgrey3 seems to want YUY2 input and having the option to let your new algorithm do YV12 -> YUY2 and then feed the result into the 3D LUT might be worthwhile?Current AviSynth's YV12->YUY2 conversion does 75:25 averaging. It's a very good converter. However it has limitation of output bit depth.
If 3D LUT support YV12 directly, it will benefit both in performance and quality.

[haruhiko_yamagata]

Is this conversion not a sort of resize, giving lots of different possible methods?
No, it's linear interpolation.
If we use resize, we have to move 0.5 pixel to the left by setting the matrix manually or something. Considering its performance and little difference in quality, I don't think it's a very good idea.

[haruhiko_yamagata]

It will depend on which part is the bottleneck.
In the yadif example you pointed, the code you used in ffdshow is exactly the same used in avisynth?
If it is, then the avisynth wrapping in ffdshow could be the limiting part...
I don't know much about the code of yadif in AviSynth. But assuming Fizick did his best for performance, the difference must be wrapping overhead. Copying HD content in memory is not a negligible overhead.

[Jong]

Anybody else noticed problems with some new DVD Menus and ffdshow beta6 post-processing? I have seen it with Mamma Mia (UK DVD) and Lars and the Real Girl (UK DVD). Both work fine in all players in DXVA mode. However, in both MPC-HC and TheaterTek (different MPEG-2 decoder in each, neither using ffdshow decoder) using ffdshow causes some of the menus to do what I can only describe as "crash" when navigating with the keyboard. The selected indicator in the menu stops moving. Even if you then try to use the mouse then the selected indicator does not change, although it did before the "crash" and if you click on a menu item it will play.
So the player is still active. If I press the appropriate key to go to the root menu that will work and the menu will start functioning again. However, after trying to navigate the troublesome menus with the keyboard the video window appears frozen.

This only happens at the moment with a small number of titles. It is maybe a new authoring tool or a new version of a tool that is confusing things. My first thought was that it was a bug in Theatertek, but now I have replicated the exact same issue in MPC-HC it seems more likely to be ffdshow. It occurs even if turn off all post-processing in ffdshow and output YV12, so it is essentially just passing through the video signal.

Anyone else seen this or have any ideas?

[noee]

...
Anyone else seen this or have any ideas?

Yes, I have seen that behavior with both jRiver MC13 and MPC-HC (Beelliyal's and SVN). I've tried HR and EVR and on the same DVD (Battlestar Galactica Season 4, D2) it does the same thing as you describe.

Seems to be more common with HR.

XPSP3, CCC8.12

[Jong]

I normally use VMR9 and it certainly occurs with that. Not sure about all the others. Also using XP SP3.

[Jeremy Duncan]

understand you are talking about RGB?

I know a Secret about RGB and I will tell it to you now.
- If you open a "Gradient Ramp", you can actually see if the RGB range is good or not!

In the ffdshow version I'm using: 2547. There is a difference in quality depending on if I use full range or standard, in the RGB conversion tab.
This is using bt.601, and output RGB32, high quality yv12 to RGB conversion.

I have tested the same gradient ramp on powerdvd ultra and the result was a better looking gradient ramp, and the ps3 gives a better esult as well than the ffdshow version I'm using.

So, you need to use a gradient ramp to see the difference.
I will now show you what a gradient ramp is, in case you don't know already. :)

http://img90.imageshack.us/img90/8723/gradientrampfullrangezy0.th.png (http://img90.imageshack.us/my.php?image=gradientrampfullrangezy0.png)


My input is all supported.
My output is rgb32 + high quality yv12 to rgb conversion
Rgb conversion tab uses bt 601
I use vmr9 renderless in mpc clsid build, I tried overlay too.

If I choose standard contrast in the rgb conversion tab, the gradient ramp is a bad result.
If I choose full range in the rgb conversion tab the gradient ramp is a better result than if I chose standard.

I would like to use standard though, by using full range the colors are not as good as they could be if I chose standard.

I have compaired the gradient ramp on the ps3 and cyberlink powerdvd ultra to the ffdshow version to see how the results vary.
At full range the ffdshow is better gradient ramp result than the ps3, the cyberlink gradient ramp is acceptable quality.

I understand you are looking at the output color range, and I ask that you look at improving the standard contrast in the rgb conversion tab. :)

[leeperry]

I ask that you look at improving the standard contrast in the rgb conversion tab. :)

"better result" / "colors are not as good" / "better gradient ramp"

do yourself a favor, get a colorimeter and calibrate your stuff, there's no better/good colors/levels...there's proper ones and uncalibrated ones ;)

[Jeremy Duncan]

"better result" / "colors are not as good" / "better gradient ramp"

do yourself a favor, get a colorimeter and calibrate your stuff, there's no better/good colors/levels...there's proper ones and uncalibrated ones ;)

You just Winky eyed my and tell me to shush!?

I did set the contrast and brightness to the best of my ability prior to this comparison.
I do not access the hidden monitor menu, I asked the tv repeir on how to and they would not let me know, and no web site tells me how either.

However I will look and see if my calibration can be improved and will see if this changes the resukt.

[leeperry]

You just Winky eyed my and tell me to shush!?

I did set the contrast and brightness to the best of my ability prior to this comparison.
well noone can calibrate video gear w/o a commercial sensor(spyder 2/3, eye one display 2)...it'd be like a partially deaf person complaining that his hifi set doesn't sound "good" :o
all my displays are calibrated, and colors/levels are "as good as they can get" :cool:

[Jeremy Duncan]

I just rechecked my brightness and contrast settings and they are fine.

I will tell you something, and you can choose to ignore it or not.
I have calibrated all three of my players: ps3, powerdvd ultra, mpc with ffdshow.
I know how and they are all calibrated to the same quality.
However the results the show on the gradient ramp show me that not all is well.

The result the cyberlink gives is different than the one the ps3 gives, and these two players are different than what the ffdshow rgb gives.
Why is that? Will you tell me that without another smiley wink?

Edit, and if you don't believe me, calibrate your monitor to the ps3 and the ffdshow and test with a gradient ramp and you will see with your own eyes.
It's testable. verify if I'm talking too much or not.

Edit. here's a better question.
If i use standard contrast, would the gradient bars be a different size than full range contrast? Or would the palet steps in the full range be more than the standard? And if the palet range is different between the standard and full range, would the standard range palet make it easier to see the gradient steps?

[leeperry]

if you expect some help, you should try to tone down maybe ;)
anyway, this is OT and not ffdshow related...ffdshow works perfectly fine as it is, when properly configured, that is :D
get a commercial sensor, create a 10 bits LUT w/ ARGYLLCMS to get perfect D65/2.2 colorimetry on your monitor, decode SD in REC601/HD in REC709 in full range RGB32HQ...and colors will look pretty darn good!
and if you crave for colorimetry awesomeness, use ddcc() to get spot-on gamut conversion....and then your troubles will be far away http://forum-images.hardware.fr/images/perso/dawen.gif

[Jeremy Duncan]

if you expect some help, you should try to tone down maybe ;)
anyway, this is OT and not ffdshow related...ffdshow works perfectly fine as it is, when properly configured, that is :D
get a commercial sensor, create a 10 bits LUT w/ ARGYLLCMS to get perfect D65/2.2 colorimetry on your monitor, decode SD in REC601/HD in REC709 in full range RGB32HQ...and colors will look pretty darn good!
and if you crave for colorimetry awesomeness, use ddcc() to get spot-on gamut conversion....and then your troubles will be far away http://forum-images.hardware.fr/images/perso/dawen.gif

If I understood your wisdom in the quote I would, but for now I will settle on simply believing your quoted response was valid.
I will be quiet now. :)

[leeperry]

I will settle on simply believing your quoted response was valid.
try this (http://tinyurl.com/apzh9l) ;)

long story made short, as long as your display won't be perfectly D65/2.2 calibrated....don't expect miracles out of ffdshow.

I never said it was easy, there's many places to learn about all this.....but this subject becomes addictive, you've been warned :)

[jmartinr]

No, it's linear interpolation.
If we use resize, we have to move 0.5 pixel to the left by setting the matrix manually or something. Considering its performance and little difference in quality, I don't think it's a very good idea.

I always resize to screen resolution anyway. Can't the two (normal resize and YV12 -> YV24) be combined so there's no speed penalty?

[ikarad]

Hi,
That means that you played a blu-ray having an uncompressed 7.1 stream ?
I don't know if it possible for you to get a sample but I don't have any (I "only" have blurays with compressed TrueHD as highest quality, not with uncompressed streams)


Is this always related to LPCM checkbox or can you hear sound when you check AC3 SPDIF ?


In all cases I suppose that you have an ATI 4xxx card that is able to bitstream LPCM 7.1 with high bitrates through the HDMI connector ?

If this is the case it will be hard to figure out because I only have SPDIF to test.

EDIT :
I have made a few tests. Actually, LPCM does work on regular AC3/DTS streams but not on TrueHD, but it may be due to my SPDIF bandwidth limitation.

I don't have ati, I have geforce gtx280, xfi titanium + G51 logitech 5.1

here the example

http://www.zshare.net/info.html?54307328-f4cf1e029ba268fd6fc1e3907e3ab1dc

I have the same issue. I have to move the slider before the sound will kick in (or alternately I can click on the subtitle option in the splitter output). I am using an ATI HDMI sound card. I have used various revs of MPC-HC filters along with different revs of ffdshow. This only happens with TrueHD. thx
Yes it is the same problem but I use geforce gtx280 + xfi titanium + G51 with analogic connection (no spidf) + iiyama 19" VGA CRT and this only happens with trueHD soundtrack.

[ikarad]

Can I have a sample?
Though I'm not sure if I have time to implement.

Have you time to implement lpcm HD (from blu-ray) support?

[Mc Onyx]

Has anyone been able to play 7.1 aac with latest FFDshow build or is 7.1 aac even supported? All I get is crackles and pops when i play 7.1 channel AAC audiotrack. Thanks for the answer.

[Px]

and I think it's not fair asking ffdshow's developers to spend their time with something that is already working...;)
Then why you ask for 3D LUT integration in ffdshow when it's currently working thought Avisynth? :rolleyes::D

[Jeremy Duncan]

try this (http://tinyurl.com/apzh9l) ;)

long story made short, as long as your display won't be perfectly D65/2.2 calibrated....don't expect miracles out of ffdshow.

I never said it was easy, there's many places to learn about all this.....but this subject becomes addictive, you've been warned :)

link to new quote (http://www.avsforum.com/avs-vb/showthread.php?p=15186601#post15186601)

There is no single right or wrong answer for this.

Source video files - DVD, HD-DVD, Blu-ray and Broadcast TV MPEG2, H264 and VC-1 will have their video stored in 16-235 format on-disc. This is what broadcast facilities and studios use as standard for digital video. Black is at 16, White is at 235. (There are values below black and above white to allow for undershoot and overshoot on high frequency edges without clipping, which would otherwise cause ringing etc. NB the black at 16 is nothing to do with composite NTSC 7.5IRE black level set-up) If you look at an SDI or HD-SDI signal in a broadcast facility or output from a VTR it will be 16-235 (or in some cases a 10 bit variant)

Some newer file-based video formats DON'T always use 16-235 though - and also SD and HD YCrCb to RGB mappings are different to each other. (601 vs 709 colourspace)

Sources can run at either 0-255 or 16-235 format. Original DVI output PCs ran 0-255 - as they were not designed with video in mind, and Windows ran with a 0-255 24bit desktop (8 bit 0-255 in each colour channel). Blu-ray players, satellite receivers, DVD players etc. with digital HDMI outputs would normally default to 16-235 output (as contained in the original broadcast or on the original disc) as this is the broadcast/production standard. (NB On-disc it is actuall YCrCb - with Y 16-235 and CrCb 16-240, but in RGB space it is 16-235 in all channels)

Displays can run in either 0-255 or 16-235 format in the same way. Most PC monitors with DVI-D inputs will usually expect a 0-255 input as a default, and most HDMI-equipped TVs will expect 16-235. That isn't to say that it isn't always possible to correctly calibrate a 0-255 display to correctly display a 16-235 input or vice versa - with the correct brightness (black level) and contrast (white level) settings it is often possible to correct for this (and many modern displays can have different brightness/contrast settings for different inputs). HOWEVER if you are switching HDMI multiple sources via an AV Amp into a single HDMI input, you really want your video levels to be consistent between sources.

So...

You have multiple points in the chain where 16-235 and 0-255 video can be used.

My understanding is that for consistency between applications and methods of display (though not always the highest quality), it is better for Windows to run internally in 0-255 mode. Thus either your video codec OR your overlay processor will ideally convert from 16-235 to 0-255 BUT NOT BOTH. Similarly your output video driver will then convert from 0-255 back to 16-235 for output if your display is a 16-235 model.

This MAY mean that there is some scaling going on, which could introduce some banding and truncation due to quantisation errors (as we don't have 30 or 36 bit internal RGB in many PCs yet - just 24 bit - which is 8 bit per channel).

Other options are possible - but they can leave you with crushed blacks or grey blacks if you aren't careful.

I'm not familiar with the Haali renderer I'm afraid - but if you only watch 16-235 sources, it may be worth setting it to 16-235 to see if you get consistent black levels between video playback and native Windows display (which won't use the renderer)

Using Vista EVR and an ATI driver registry hack to force 16-235 colour space conversion on SD content I have consistent black and white levels across content and apps now. I am able to set the output colour space of my HDMI output to RGB 16-235 in the drivers - and this works well for me.

So the new quote means if my video driver is using 0-255 levels, and ffdshow rgb contrast is using 16-235 levels, then there is some scaling which introduced the ugly gradient ramp result I complained about.
The solution is if I force ffdshow to use 16-235 levels, then my videocard needs to put out 16-235 levels.
The quoted fellow calls it 0-255 Mode. I dunno how to change the MODe in the settings to 16-235 so I can use ffdshow standard contrast with no banding.

heh heh. :helpful:

I am only saying this in the ffdshow thread because many people may put the rgb contrast to standard and then check the gradient ramp and not know whats the problem and why the result is ugliness.

[leeperry]

Then why you ask for 3D LUT integration in ffdshow when it's currently working thought Avisynth? :rolleyes::D
he's simply craving for the super neato experimental yv12 conversion algorithm from Haruhiko :D
the new quote means if my video driver is using 0-255 levels, and ffdshow rgb contrast is using 16-235 levels, then there is some scaling which introduced the ugly gradient ramp result I complained about.
The solution is if I force ffdshow to use 16-235 levels, then my videocard needs to put out 16-235 levels.
The quoted fellow calls it 0-255 Mode. I dunno how to change the MODe in the settings to 16-235 so I can use ffdshow standard contrast with no banding.
set ffdshow to full range in RGB32HQ, and it will output the original TV range(no TV>PC conversion).
most HDTV displays only accept 16-235 in HDMI, so this is your best option!
too bad it means your windows desktop will remain in 0-255, which can be a problem if you plan on watching digital pictures and stuff.
my pj accepts both TV/PC levels, but if I input TV levels it's internally converting to PC anyway....using it's cheapo onboard IC, which is of much lower quality than ffdshow :rolleyes:

there's no definitive answer to all situations, it's very much display dependent.

[noee]

Alright, I'm confused (whereas I thought I understood all this).

I play only SD material from DVDs (currently) and I have the ATI driver set to "Limited RGB". If I set FFDshow RGB32HQ output with:

YCbCr: BT.601
Input: Standard
Output: TV/Projector

Shouldn't this essentially be a "straight through" conversion, meaning there is really no levels conversion at all?

[yesgrey]

Then why you ask for 3D LUT integration in ffdshow when it's currently working thought Avisynth? :rolleyes::D
For the possibility (recently suported by haruhiko) that the integration in ffdshow could be faster than using the avisynth wrapping in ffdshow. And the new YV12->YV24 algorythm would also be nice, but the most important would be the speed gain.

[haruhiko_yamagata]

I always resize to screen resolution anyway. Can't the two (normal resize and YV12 -> YV24) be combined so there's no speed penalty?It is possible, but it's a bit hard work.

[haruhiko_yamagata]

Have you time to implement lpcm HD (from blu-ray) support?No, I have been busy with RGB stuffs. And while I'm doing that, many people have reported many bugs. Among many feature requests, I can handle only a few. I can't promise, please wait.

[Px]

For the possibility (recently suported by haruhiko) that the integration in ffdshow could be faster than using the avisynth wrapping in ffdshow. And the new YV12->YV24 algorythm would also be nice, but the most important would be the speed gain.
Problems with speed? :rolleyes: Upgrade your system and don't waste developers time which they could spend on new features/bugfixes :D

[yesgrey]

Problems with speed?
Nope. For me it's ok now, I will not ask for it again. If any of the developers find the time do do it, great, if not, it will also be fine, I will keep use rgb3dlut, which is also great. I do not perform any video processing, it's only decoding, resizing to screen resolution, convert to rgb32 and then correct the gammut, so my E2160@3GHz is enough...;).
In fact, if I want, I even can use the new YV12->YV24 algorythm, is just using an Avisynth script with DirectShowSource to open the file and set ffdshow for decoding the format and output rgb32, then is just calling rgb3dlut for performing the gammut correction.:)

[yesgrey]

Can't the two (normal resize and YV12 -> YV24) be combined so there's no speed penalty?

It is possible, but it's a bit hard work.

Now this seems to be a great idea...;)

[Jeremy Duncan]

Alright, I'm confused (whereas I thought I understood all this).

I play only SD material from DVDs (currently) and I have the ATI driver set to "Limited RGB". If I set FFDshow RGB32HQ output with:

YCbCr: BT.601
Input: Standard
Output: TV/Projector

Shouldn't this essentially be a "straight through" conversion, meaning there is really no levels conversion at all?

I googled some more on this and found out that if the videocard can't do 4:2:0 pixel format (limited) then there will be conversion, resulting in loss of information which means banding ugliness.

I then tried out ffdshow standard contrast and full range contrast with the ati 9.1 drivers and the various pixel formats it offers.
What I found out is, if I don't convert yv12 to rgb by using the output option to do that, but instead convert to rgb in avisynth, the banding seen is greatly reduced and so better quality.
Which leads me to the conclusion the "high quality yv12 to rgb conversion" isn't as high quality conversion as ConvertTorgb() in avisynth.

So I'm wondering is the code used for "high quality yv12 to rgb conversion" outdated or poor quality? :confused:

[ikarad]

No, I have been busy with RGB stuffs. And while I'm doing that, many people have reported many bugs. Among many feature requests, I can handle only a few. I can't promise, please wait.

thanks, I will wait

[leeperry]

I have been busy with RGB stuff
I've done another comparison w/ the latest ddcc() version :
http://forum.doom9.org/showpost.php?p=1243687&postcount=174

the background is R3/G1/B1 on all the screenshots, except in the new experimental "Q" version of yours where it's 2/0/0 :confused:

the only difference between the 6th & the 7th screenshots is that I've updated ffdshow, I haven't messed w/ the ffdshow settings at all..

Alright, I'm confused (whereas I thought I understood all this).
you'd be better off leaving the ATi drivers in full range RGB so they don't convert levels, and then set ffdshow to only do RGB32HQ w/o any levels conversion :)
but you should also try to set your display to full range (if any possible) to make sure that it doesn't work internally in 0-255 :o
Which leads me to the conclusion the "high quality yv12 to rgb conversion" isn't as high quality conversion as ConvertTorgb() in avisynth.
that's kinda funny, considering RGB32HQ is using ConvertToRGB32() code :D

[clsid]

But it executes that code at a different place, so it is possible the video is being altered somewhere esle in the processing chain in between the two places.

[albain]

thanks, I will wait

I have fixed the first bug already : no sound on some MLP/TrueHD samples.

Done in revision 2648

Concerning the other bug you mentioned, I wonder how to test it without an ATI 4xxx or a sound card that can handle HD bitstream ?

Maybe the previous fix will solve the problem...

[leeperry]

But it executes that code at a different place, so it is possible the video is being altered somewhere esle in the processing chain in between the two places.
left is colorYUV(levels="tv->pc")+ConvertToRGB32() REC601 full range / right is colorYUV(levels="tv->pc")+ffdshow RGB32HQ REC601 full range.

http://www.image-load.eu/out.php/t142541_convert32601.png (http://www.image-load.eu/out.php/i142541_convert32601.png)http://www.image-load.eu/out.php/t142542_ffdrgb32hq.png (http://www.image-load.eu/out.php/i142542_ffdrgb32hq.png)

Info
- date: 2/1/2009
- process: Compare
- source: convert32-601.png
- reference: ffd_rgb32hq.png

Basic statistics
- time elapsed: 00:00:00
- overall transfer [kB/s]: 2,851
- folders processed: 0
- files processed: 1

Errors
- errors: 0
- warnings: 0
- other: 0

[albain]

A new feature to be developed is the bitstream of HD audio streams to the HDMI output for receivers that can handle their decoding.

The question is : what is the difference in the implementation with SPDIF passthrough ?
Is there a specific media type to send, and most of all, it there a formatting to be done before ?

I really need to get my hand on a ATI 4xxxx card...

[Jeremy Duncan]

I will post a example of the ffdshow settings I used. For these pictures I used vista 32 bit, media player classic with vmr9 renderless.

________ top picture ________

Codecs tab
Set Mpeg2 to Libmpeg2, and check "DVD decoding".
Set Avisynth to Avisynth, Raw video to All supported

Subtitles tab, Unchecked
Uncheck "Decode closed captions"
Uncheck "Accept embedded subs"
Uncheck "Accept SSA, ASS, ASS2 Subtitle (experimental)
Vobsub subpage, uncheck Vobsub Enable.

Avisynth tab checked
YV12 checked,
Add FFdshow Video source checked,
3:2 Pulldown box: Ignore Pulldown checked,
Uncheck Buffer back/Ahead

setmemorymax(1024)
converttorgb32()

Queue & Output tab
Queue output samples checked

Output tab
rgb32 checked

rgb conversion tab
ycbcr: itu-bt 601
contrast: standard

________ middle picture ________

Codecs tab
Set Mpeg2 to Libmpeg2, and check "DVD decoding".
Set Avisynth to Avisynth, Raw video to All supported

Subtitles tab, Unchecked
Uncheck "Decode closed captions"
Uncheck "Accept embedded subs"
Uncheck "Accept SSA, ASS, ASS2 Subtitle (experimental)
Vobsub subpage, uncheck Vobsub Enable.

Resize & aspect tab checked
Multiply by:
2.668 (for 1920x1080 16:9 aspect ratio)
Process Pixel aspect ratio internally checked
No aspect ratio correction checked
spline
Luma Sharpen: 0.00
Luma Gaussian Blur: 0.50
Accurate rounding checked

Queue & Output tab
Queue output samples checked

Output tab
rgb32 checked
high quality yv12 to rgb conversion checked

rgb conversion tab
ycbcr: itu-bt 601
contrast: standard

________ bottom picture ________

Codecs tab
Set Mpeg2 to Libmpeg2, and check "DVD decoding".
Set Avisynth to Avisynth, Raw video to All supported

Subtitles tab, Unchecked
Uncheck "Decode closed captions"
Uncheck "Accept embedded subs"
Uncheck "Accept SSA, ASS, ASS2 Subtitle (experimental)
Vobsub subpage, uncheck Vobsub Enable.

Avisynth tab checked
YV12 checked,
Add FFdshow Video source checked,
3:2 Pulldown box: Ignore Pulldown checked,
Uncheck Buffer back/Ahead

setmemorymax(1024)
converttorgb32()

Resize & aspect tab checked
Multiply by:
2.668 (for 1920x1080 16:9 aspect ratio)
Process Pixel aspect ratio internally checked
No aspect ratio correction checked
spline
Luma Sharpen: 0.00
Luma Gaussian Blur: 0.50
Accurate rounding checked

Queue & Output tab
Queue output samples checked

Output tab
rgb32 checked

rgb conversion tab
ycbcr: itu-bt 601
contrast: standard

http://thumbnails2.imagebam.com/2538/7b29a725374267.gif (http://www.imagebam.com/image/7b29a725374267)

click to enlarge picture

dl link of zipped picture (http://www.megaupload.com/?d=29CQPXGR)

[STaRGaZeR]

Shouldn't it be BT.709 for everything >1024 instead of >=1024? Width = 1024 is mostly used when encoding anamorphic PAL DVDs (resulting in 1024x576), which are BT.601 in origin.

[Jeremy Duncan]

no, the test disk is from calibrate.tv and it is a standard definition test disk, not rec 709.

I use ffdshow to resize dvd hollywood movies on my 1080p tv, and those movies use rec 601.

I asked the kind people in the avisynth forum and they said that if the source is rec 601 I should not use colormatrix to change it to rec 709.
Those weren't their exact words, I will get the thread link for their exact statement: link to the wise mans words (http://forum.doom9.org/showthread.php?p=1108131#post1108131)

[STaRGaZeR]

Oh I wasn't responding to you :p

[Jeremy Duncan]

http://thumbnails2.imagebam.com/2538/7b29a725374267.gif (http://www.imagebam.com/image/7b29a725374267)

click to enlarge picture

The bottom picture changes to the same quality as the two pictures above it if I move the avisynth tab below the resize tab.

So this means, if you want to use resizing in ffdshow, and you also want to use the output tab's high quality yv12 to rgb conversion.
- That once you check high quality yv12 to rgb conversion, it move up above the resizing tab as if the output tab was above the resizing tab.

This way you will get the same quality from just checking high quality yv12 to rgb conversion as the bottom picture shows.

Exactly HOW you make the high quality yv12 to rgb conversion behave like it's a tab above the resize tab, even though it's in the output tab is your problem.

[haruhiko_yamagata]

Shouldn't it be BT.709 for everything >1024 instead of >=1024? Width = 1024 is mostly used when encoding anamorphic PAL DVDs (resulting in 1024x576), which are BT.601 in origin.Thank you for the info. I have fixed at rev 2650.

[clsid]

Some suggestions for the new RGB conversion dialog:

* Make "Auto" the default choice. Use a tooltip like this: "Uses full range for JPEG, MJPEG, and Fraps video. Uses standard range for all other video formats. Optionally can use level information as signaled by a special H.264 flag."

* Add checkbox behind Auto called "Use H.264 XXX flag" (XXX= name of the flag) and tooltip "Warning: some H.264 video streams have an incorrect value for this flag. It is recommended to leave this option disabled."

* Standard -> always use standard range.

The above seems more logical to me than the current options, were Standard isn't always standard range.


Tooltip for "Computer monitor" -> "When connecting an LCD/Plasma TV with a VGA or DVI cable, it also counts as a computer monitor."

[Mercury_22]

Some suggestions for the new RGB conversion dialog:

* Make "Auto" the default choice. Use a tooltip like this: "Uses full range for JPEG, MJPEG, and Fraps video. Uses standard range for all other video formats. Optionally can use level information as signaled by a special H.264 flag."

* Add checkbox behind Auto called "Use H.264 XXX flag" (XXX= name of the flag) and tooltip "Warning: some H.264 video streams have an incorrect value for this flag. It is recommended to leave this option disabled."

* Standard -> always use standard range.

The above seems more logical to me than the current options, were Standard isn't always standard range.


Tooltip for "Computer monitor" -> "When connecting an LCD/Plasma TV with a VGA or DVI cable, it also counts as a computer monitor."

Yes but add HDMI cable to Tooltip for "Computer monitor" -> "When connecting an LCD/Plasma TV with a VGA or DVI cable, it also counts as a computer monitor." :)

[madshi]

Some suggestions for the new RGB conversion dialog:

* Make "Auto" the default choice. Use a tooltip like this: "Uses full range for JPEG, MJPEG, and Fraps video. Uses standard range for all other video formats. Optionally can use level information as signaled by a special H.264 flag."

* Add checkbox behind Auto called "Use H.264 XXX flag" (XXX= name of the flag) and tooltip "Warning: some H.264 video streams have an incorrect value for this flag. It is recommended to leave this option disabled."

* Standard -> always use standard range.

The above seems more logical to me than the current options, were Standard isn't always standard range.
It's one more control, which is a disadvantage, but I agree that it's probably cleaner because in the current dialog the "non-auto" controls still contain some "auto" logic.

Tooltip for "Computer monitor" -> "When connecting an LCD/Plasma TV with a VGA or DVI cable, it also counts as a computer monitor."
That may be so with your LCD/Plasma TV, but not with mine. Generally DVI can transport video levels, too. And HDMI can also transport computer levels. Not sure about VGA, but I think it probably can also transport both video and computer levels.

[clsid]

Ok, how about this:
"When connecting an LCD/Plasma TV with a VGA/DVI/HDMI cable, it usually functions similar as a computer monitor. Consult your device's manual."

There will always be exceptions. If it works like described above in most cases, then the note is certainly relevant. Otherwise many people will most like choose the wrong setting when connecting to a TV.

[Mercury_22]

Ok, how about this:
"When connecting an LCD/Plasma TV with a VGA/DVI/HDMI cable, it usually functions similar as a computer monitor. Consult your device's manual."

There will always be exceptions. If it works like described above in most cases, then the note is certainly relevant. Otherwise many people will most like choose the wrong setting when connecting to a TV.

Or shorter "Usually A Flat Panel TV connected via a digital or VGA cable functions as a monitor. Consult your device's manual." :)

[madshi]

Ok, how about this:
"When connecting an LCD/Plasma TV with a VGA/DVI/HDMI cable, it usually functions similar as a computer monitor. Consult your device's manual."

There will always be exceptions. If it works like described above in most cases, then the note is certainly relevant. Otherwise many people will most like choose the wrong setting when connecting to a TV.
The problem is that I simply do not agree (at all!) with what you're aiming at. In my opinion most TVs expect RGB video levels, regardless of which connection type you're using. I believe TVs expecting RGB computer levels (even with DVI or VGA) are the exception and not the rule!

Usually A Flat Panel TV connected via a digital or VGA cable functions as a monitor.
Which is factually totally incorrect, AFAIK.

[mark0077]

All of this discussion and possible disagreement brings me back to the addition of the simple area in the conversion panel to TEST your screens output.

Describe what it should look like, and request the user to choose an output option that makes the test image match the desired output described. I would love this, especially for some friends that might not be sure which option is best. This would let them realize, aha, so thats the correct option and they can move on...

[clsid]

The two LCD TVs in my house (one Samsung, one JVC) both function as a computer monitor when I connect them with a VGA cable. The mode to view that input is even called "PC".

Does anyone here work in an electronics shop?

[mark0077]

I think if peoples TVs have the option for full range 0-255 then they should be hinted that this option might be available to them.

On my Samsung Series 9 the option is called "HDMI Black Level" and it can be set to Normal or Limited.

My perfect rgb conversion area would have a hint somewhere that if using a TV, to first check if it has the option to use "Full Range" or "Extended". If so set that to full range first.

THEN

Instruct them to use the image below to confirm which setting is correct for your display. When the correct setting is chosen, the image below should look like x y z and a b c should not be visible.... Something like this is what I think would be good.

That way they both get the benefits of full range for their pc usage, aswell as knowing based on the image test that they are setup correctly.

[madshi]

The two LCD TVs in my house (one Samsung, one JVC) both function as a computer monitor when I connect them with a VGA cable. The mode to view that input is even called "PC".
Hmmmm... As I said before, I'm not fully sure about VGA. It may be true, that the majority of flat panel TVs want computer levels when connected via VGA. Although my plasma doesn't. But what about projectors? Do they also usually expect computer levels via VGA? Projector owners here? And what about DVI?

BTW, you know, you can use a HDMI cable with DVI adapters or you can use a DVI cable with HDMI adapters. Or you can use a cable which has a DVI port at the one end and an HDMI port at the other end. The decisive factor will not be the cable type but probably the port type in the TV. You could even use a DVI cable and a DVI->VGA adapter. So again, it's the port used in the display/projector which decides, not the cable type.

[clsid]

HDMI is also used for connecting devices like HDD recorders and DVD players. So with that I would indeed not be surprised if it would default to using TV levels. It would also explain why that sometimes has an option to configure the levels (see mark's post). VGA/DVI is traditionally only used for PC monitors. Plasma TVs may behave differently than LCD, possibly because they generally have a relatively low native resolution. I don't have a projector, but I think those usually expect TV levels.

[honai]

My plasma TV allows both computer and video levels on the VGA input, and also through HDMI. For VGA the input type can be set in the menu. For HDMI (i.a. DVI, too) it simply accepts what is being fed into it.

[Mercury_22]

Which is factually totally incorrect, AFAIK.

My Samy says otherwise :eek:

[madshi]

My Samy says otherwise :eek:
With which connection type? HDMI?

[ash925]

Can somebody throw some light on the FAAN and other idct options in ffdshow tryouts and whether it is realtively better than the rest?Tried googling but nothing worthwhile came up.

[clsid]

idct = inverse dct

You need to use the IDCT that matches the DCT that was used during encoding.

[Mercury_22]

With which connection type? HDMI?

Yes !
Essentially Mark has give you a better / complete, description / answer which apply to my Samy too :)

I think if peoples TVs have the option for full range 0-255 then they should be hinted that this option might be available to them.

On my Samsung Series 9 the option is called "HDMI Black Level" and it can be set to Normal or Limited.

My perfect rgb conversion area would have a hint somewhere that if using a TV, to first check if it has the option to use "Full Range" or "Extended". If so set that to full range first.

THEN

Instruct them to use the image below to confirm which setting is correct for your display. When the correct setting is chosen, the image below should look like x y z and a b c should not be visible.... Something like this is what I think would be good.

That way they both get the benefits of full range for their pc usage, aswell as knowing based on the image test that they are setup correctly.

[madshi]

Yes !
Essentially Mark has give you a better / complete, description / answer which apply to my Samy too :)
So your Samy can do both video and computer levels. That's very nice. But it contradicts what you originally said:

"Usually A Flat Panel TV connected via a digital or VGA cable functions as a monitor."

If all TVs were like your Samy, then you should have said:

"Usually A Flat Panel TV connected via a digital or VGA cable can work as either a monitor or a TV, depending on how it's configured."

But not all TVs are like your Samy. Some do not have an option to switch between video and computer levels. And the important thing is which levels these displays expect on which input type.

[Mercury_22]

So your Samy can do both video and computer levels. That's very nice. But it contradicts what you originally said:

"Usually A Flat Panel TV connected via a digital or VGA cable functions as a monitor."

If all TVs were like your Samy, then you should have said:

"Usually A Flat Panel TV connected via a digital or VGA cable can work as either a monitor or a TV, depending on how it's configured."

But not all TVs are like your Samy. Some do not have an option to switch between video and computer levels. And the important thing is which levels these displays expect on which input type.

I thought that the term "USUALLY" was explanatory enough, but if you feel the need to make it more "CLEAR" it's fine with me :)
I was just trying to shorten the "Tooltip" :o

[madshi]

I thought that the term "USUALLY" was explanatory enough, but if you feel the need to make it more "CLEAR" it's fine with me :)
I was just trying to shorten the "Tooltip" :o
The point is that your shortened Tooltip is incorrect, at least when talking about HDMI. Maybe it's correct about DVI and/or VGA, but the jury is still out on that.

[Mercury_22]

The point is that your shortened Tooltip is incorrect, at least when talking about HDMI. Maybe it's correct about DVI and/or VGA, but the jury is still out on that.

OK YOU'RE RIGHT ! :)


P.S. But just to let you know many flat panel TVs, at least LCDs AFAIK, have a dedicated HDMI for PC connection !!! and when you connect to that HDMI (as manual tells you to ! :))(and rename it as PC in my case) you CAN'T even change from full range ! Tested on 3 LCDs :rolleyes: IF you're interested you can see my Samy's manual here Samsung LE32A656 (http://www.samsung.com/uk/support/download/supportDown.do?group=television&type=television&subtype=tftlcd&model_nm=LE32A656A1F&disp_nm=LE32A656&language=&cate_type=all&dType=D&mType=UM&vType=&prd_ia_cd=02010100&model_cd=&menu=download) :o

[madshi]

P.S. But just to let you know many flat panel TVs, at least LCDs AFAIK, have a dedicated HDMI for PC connection !!! and when you connect to that HDMI (as manual tells you to ! :))(and rename it as PC in my case) you CAN'T even change from full range !
That's interesting, didn't know that.

Argh, that complicates things. Because the typical end user will probably plug his HTPC into the "PC connection" labeled HDMI port...

So to recap:

(1) Some TVs want video levels via all HDMI ports and are not configurable.
(2) Some TVs want computer levels via all HDMI and are not configurable.
(3) Some TVs are fully adjustable.
(4) Some TVs want video levels via some HDMI ports and computer levels via other HDMI ports.

Argh, what a mess. Try to explain all that in a small hint!! :eek:

The decisive question is probably how many models are in each of the above groups. I don't really know about that. I still believe (1) is much more common than (2). I don't know how many models are in groups (3) and (4), though.

[Mercury_22]

That's interesting, didn't know that.

Argh, that complicates things. Because the typical end user will probably plug his HTPC into the "PC connection" labeled HDMI port...

So to recap:

(1) Some TVs want video levels via all HDMI ports and are not configurable.
(2) Some TVs want computer levels via all HDMI and are not configurable.
(3) Some TVs are fully adjustable.
(4) Some TVs want video levels via some HDMI ports and computer levels via other HDMI ports.

Argh, what a mess. Try to explain all that in a small hint!! :eek:

The decisive question is probably how many models are in each of the above groups. I don't really know about that. I still believe (1) is much more common than (2). I don't know how many models are in groups (3) and (4), though.

Yes this is more accurate !:)

And since I've recently studied the matter because I had to help somebody to chose / buy a new LCD I can say that the "recent" models of LCD from Samy Pany Philips and Sony all have the "full range" over HDMI connection :rolleyes:

I think it's safe to say that (3) and (4) refer to the same TVs cause even when connected on my dedicate HDMI jack if I DON'T EDIT / change the source to PC it acts as a normal HDMI ( I can change from full range) also I've never heard of (2) but...

So.... yeah "Try to explain all that in a small hint!!" :)

Maybe : "Your Flat Panel Tv may act as a monitor.See your display Manual"

[haruhiko_yamagata]

Shouldn't it be BT.709 for everything >1024 instead of >=1024? Width = 1024 is mostly used when encoding anamorphic PAL DVDs (resulting in 1024x576), which are BT.601 in origin.
Haali's video renderer use BT.709 for 1024.
The changelog (http://haali.cs.msu.ru/mkv/)says,
Added an automatic colorspace selection option to the renderer, it switches to BT.709 when video width is 1024 or more
Should I revert rev 2650?

[madshi]

I can say that the "recent" models of LCD from Samy Pany Philips and Sony all have the "full range" over HDMI connection
What do you mean? I'm not sure if you're saying that the Samy, Pany, Philips and Sony belong into group (2), (3) or (4)?

Haali's video renderer use BT.709 for 1024.
The changelog (http://haali.cs.msu.ru/mkv/)says,

Should I revert rev 2650?
Is that width number you're checking the number of encoded pixels or the number of pixels after anamorphic stretch? I've seen 1024 for anamorphic PAL DVDs. So if you look at the final decoded and aspect ratio corrected width, I'd say it must be bigger than 1024 to qualify for BT.709.

[shambles]

wouldn't it be better to use number of pixels instead of width for the colour system selection, since for 4/3 AR movies, 720p can be 960x720

1024x576 = 589824 px
960x720 = 691200 px
1280x528 = 675840 px

bt601 for <600k px and bt709 for >600k?


edit: hmm, even that would still be slightly problematic, since ITU spec dvds should be resized to 1047x576 (603072px), and really wide movies like ben hur would be ~1280x464 (593920px) for 720p

[madshi]

wouldn't it be better to use number of pixels instead of width for the colour system selection, since for 4/3 AR movies, 720p can be 960x720

1024x576 = 589824 px
960x720 = 691200 px
1280x528 = 675840 px

bt601 for <600k px and bt709 for >600k?
Sounds like a good suggestion to me.

[tetsuo55]

wouldn't it be better to use number of pixels instead of width for the colour system selection, since for 4/3 AR movies, 720p can be 960x720

1024x576 = 589824 px
960x720 = 691200 px
1280x528 = 675840 px

bt601 for <600k px and bt709 for >600k?

That's such a simple solution that i totally didn't think of it.

I did some random compares.

590k should be correct for 99% of all videos

EDIT:

WE can make the if statement a little more complex.

Count the pixels and check if W=1050+ or H=720+

If the pixels fall into SD and both W and H are false the result is SD
If the pixels fall into HD and both W and H are false the result is SD
If the pixels fall into HD and either W or H are true the result is HD
If the pixels fall into SD and either W or H are true the result is HD

[Mercury_22]

What do you mean? I'm not sure if you're saying that the Samy, Pany, Philips and Sony belong into group (2), (3) or (4)?


Is that width number you're checking the number of encoded pixels or the number of pixels after anamorphic stretch? I've seen 1024 for anamorphic PAL DVDs. So if you look at the final decoded and aspect ratio corrected width, I'd say it must be bigger than 1024 to qualify for BT.709.

Into group (3) ! (recent LCD models ! AFAIK) :rolleyes:

Also as I've said before in my experience cat (4) don't exist because even the dedicated HDMI jack CAN be reverted / used as configurable HDMI
To explain this better: FOR SAMY the dedicated HDMI port CAN act as "CONFIGURABLE" HDMI ( = you CAN change the level) UNLESS you select "PC" as the source for this port which makes it "UNCONFIGURABLE" (= CAN'T change the level) this I've tested on 3 different "recent" models of samy
For philips pany and sony I've just read about it on their sites and on http://www.avforums.com/index.php http://www.avsforum.com/ http://www.prad.de/en/index.html http://www.hdtvtest.co.uk/ ... !

[shambles]

WE can make the if statement a little more complex.

Count the pixels and check if W=1050+ or H=720+

If the pixels fall into SD and both W and H are false the result is SD
If the pixels fall into HD and both W and H are false the result is SD
If the pixels fall into HD and either W or H are true the result is HD
If the pixels fall into SD and either W or H are true the result is HD

That's fantastic! :)

[madshi]

Count the pixels and check if W=1050+ or H=720+

If the pixels fall into SD and both W and H are false the result is SD
If the pixels fall into HD and both W and H are false the result is SD
If the pixels fall into HD and either W or H are true the result is HD
If the pixels fall into SD and either W or H are true the result is HD
The "if the pixels fall into XX" doesn't have any effect in this logic.

Into group (3) ! (recent LCD models ! AFAIK) :rolleyes:
That's very good. What is the default setting? Video or computer levels?

[tetsuo55]

The "if the pixels fall into XX" doesn't have any effect in this logic.

You're right!

That also means it's slightly less usefull than i though.

It needs a little bit more thinking.

[tetsuo55]

Fixed the HD/SD detection

If W =>1050 or H =>600 Use 709
If both are false Use 601

I'm not 100% convinced we should be using this though.

The physical limits of SD/ED displays are 768 x 576
This means that anything larger than this should have been encoded using 709
Starting from 800x600 all content should be sRGB/709

[haruhiko_yamagata]

Width >1024 or height >=720 then BT.709, else BT.601?

// EDIT oops, too late. height >= 600 looks OK.

[madshi]

I'm not 100% convinced we should be using this though.

The physical limits of SD/ED displays are 768 x 576
Actually SD Plasmas are usually 852x480 or 853x480, IIRC.

Width >1024 or height >=720 then BT.709, else BT.601?
Sounds good to me. You could probably also use "(width > 1024) || (height > 576)". This would put anamorphic PAL DVDs just below the HD borderline. Which would make sense, I think, since anamorphic PAL DVDs are the highest resolution SD sources I know.

[tetsuo55]

After what madshi said i did some googling:

PAL anamorphic = 1024x576
NTSC anamorphic = 853x480

So
If height is >=577 use 709, Else check width
If width is >=1025 use 709, Else use 601

I think this is a bit more efficient because width is only checked when needed, and height is the only 100% accurate SD/HD limit
Also all new content should be HD/709 so it makes sense to default to 709 and keep 601 as an else

[Mercury_22]

The "if the pixels fall into XX" doesn't have any effect in this logic.


That's very good. What is the default setting? Video or computer levels?

For ALL, including dedicated port when the selected source it's NOT "PC", (or NO source is selected, which is the default) : default = video levels

[STaRGaZeR]

Haali's video renderer use BT.709 for 1024.
The changelog (http://haali.cs.msu.ru/mkv/)says,

Should I revert rev 2650?

Definitely not. To get square pixels from an anamorphic PAL DVD source (BT.601) you have to resize to 1024x576, so that includes 1024 in BT.601. However I think madshi's solution is the best:

Sounds good to me. You could probably also use "(width > 1024) || (height > 576)". This would put anamorphic PAL DVDs just below the HD borderline. Which would make sense, I think, since anamorphic PAL DVDs are the highest resolution SD sources I know.

I've never seen SD sources greater than that either.

[leeperry]

I've never seen SD sources greater than that either.
I don't see the point to take upscales in account.
I'm the one who asked Haali to add this auto matrix stuff in HR, as it was too annoying to constantly change manually. ppl who upscale SD to 720p/1080p will end up with 709 in your ffdshow "auto" mode :o

you can't really simplify all that stuff, you'd be better off making a clear and simple explanation page on the official ffdshow help site IMHO

[clsid]

This algo should use the input resolution in ffdshow, not the resolution after resizing ;) So there should be no problem with upsizing.

[leeperry]

well I've never seen 1024*576 source files...so it's been encoded upscaled :D

and what about 1/4 HD files ? like 960*540 ? did the guy actually convert from 709 to 601 ? I doubt it..

maybe you could let the user specify what value he wants to use.

also maybe you could use yesgrey3's forthcoming REC601/709 matrix decoding code, as it appears to be more accurate than the ffdshow current code.

as I understand it, it's using 2 highly accurate generic LUT's, one for 601, one for 709.

[madshi]

For ALL, including dedicated port when the selected source it's NOT "PC", (or NO source is selected, which is the default) : default = video levels
Good. So if consumers leave the TV settings alone HDMI defaults to video levels. Have you also checked DVI and VGA? Is it the same for those?

well I've never seen 1024*576 source files...so it's been encoded upscaled :D
Answer this question, please: Which resolution do anamorphic PAL DVDs have? I hope you won't say 720x576, because if you actually played anamorphic PAL DVDs in 720x576, you'd have distorted aspect ratio.

[tetsuo55]

well I've never seen 1024*576 source files...so it's been encoded upscaled :D

and what about 1/4 HD files ? like 960*540 ? did the guy actually convert from 709 to 601 ? I doubt it..

maybe you could let the user specify what value he wants to use.

also maybe you could use yesgrey3's forthcoming REC601/709 matrix decoding code, as it appears to be more accurate than the ffdshow current code.

as I understand it, it's using 2 highly accurate generic LUT's, one for 601, one for 709.

There is a fine line between HD/SD

The problem we are facing is out of spec resolutions for HD.
Any file with a resolution equal to or lower than 1024x576 is SD and any player/display capable of using this resolution will display it as 601

So if the guy did not convert to 601 it means that his encode is out-of-spec and thus needs a manual touch.
Disable auto-detection and use manual settings

[leeperry]

Answer this question, please: Which resolution do anamorphic PAL DVDs have? I hope you won't say 720x576, because if you actually played anamorphic PAL DVDs in 720x576, you'd have distorted aspect ratio.
I simply upscale to 720p, then set the AR as required.

yet the input resolution "seen" by ffdshow will still be 720*576 from the VOB's, you have to upscale to 1024*576 afterwards.

so if you wanna take rescales in account, you can end up with 1024*576 xvid's in BT601 and 960*540 WMV/h264 in BT709 :o

just let the user choose what value he fancies IMHO, he will set it depending on his needs.

[clsid]

No no no. We use heuristics to automatically decide for the user. If a user thinks he knows better, then the options are available to force a setting.

[leeperry]

We use heuristics to automatically decide for the user. If a user thinks he knows better, then the options are available to force a setting.
anyway, proper matrix decoding only matters if your display is carefully calibrated...so the user that cares about that needs to know what he's doing, hence my tip to make a proper explanation page on the ffdshow help site.

some stock LCD monitors have really scary ΔE figures :D

look at the charts :
http://www.hardware.fr/articles/677-3/samsung-245b-1er-24-tn-vs-24-pva-mva.html

and their wide gamuts(at the bottom) :
http://www.hardware.fr/articles/677-4/samsung-245b-1er-24-tn-vs-24-pva-mva.html

you can decode HD in 601 or SD in 709 on these things, it don't matter :p

http://www.image-load.eu/out.php/t143177_barsmatrix.jpg (http://www.image-load.eu/out.php/i143177_barsmatrix.jpg)

[haruhiko_yamagata]

This algo should use the input resolution in ffdshow, not the resolution after resizing ;) So there should be no problem with upsizing.
This is correct. Upscaling does not confuse ffdshow as far as it is done in ffdshow (or its AviSynth filter) at the decoding time.

[Mercury_22]

Good. So if consumers leave the TV settings alone HDMI defaults to video levels. Have you also checked DVI and VGA? Is it the same for those?


I've tested just the HDMI :o but I don't think the tv can tell if you're using a HDMI adapter for the DVI ! As for the VGA maybe Clsid can tell us ?! :helpful:
( I have / using only HDMI cable :cool:)

Also I don't think people are connecting their PC to TV WITHOUT configuring the connection cause it's not the usual / default device / type of connection for a PC ! NO? :confused:

In my experiance it's quite the opposite :cool: most people even ( try to ) calibrate the tv...

My proposal it's to change the existing "Computer monitor" to "Computer monitor / Some NEW TVs"

[STaRGaZeR]

So if the guy did not convert to 601 it means that his encode is out-of-spec and thus needs a manual touch.
Disable auto-detection and use manual settings

Exactly. 1024x576 is the maximum "standard" resolution for SD video as we know of. If anybody has lower resolution videos using BT.709 that's not ffdshow's fault.

[leeperry]

well anyway 576p is Enhanced Definition, an in-between SD/HD....REC.601 indeed ;)

[honai]

A way for PS3 owners to determine if the LCD TV supports full-range RGB over HDMI can be found in the manual:

http://manuals.playstation.net/document/en/ps3/current/settings/rgbfullrange.html

If black appears dull on the screen when [Full] is selected, set this option to [Limited].

[Liisachan]

Hi, I just wanted to thank the devs and other people who are trying to improve color space things. I don't understand the theory but I like the new hq rgb conv. It might be just my imagination but it looks nicer~

Btw... in the past, DGIndex <= 1.4.9 used bt709 by default, when DVD doesn't define the matrix explicitly. Which might be spec-compliant, but of course bt601 is more likely to be the actual matrix for movies displayed as 640x480, right?

Because of this, I assume quite a few old movies (when encoded through RGB, VFAPI...) have slightly wrong colors (especially, red-ish colors are noticeably off-key). I myself did that mistake more than once and had to correct it later for example using AVS ConvertToYUY2(matrix="rec709"). Saying this is probably useless, as you can't tell programatically which video was encoded using which, properly or improperly. But anyway, for what it's worth, I think that unexpectedly many clips in the world might be encoded through bt709 improperly.

[Mercury_22]

Anyone tryed Intel's Parallel Studio (http://www.intel.com/cd/software/products/asmo-na/eng/399359.htm) ? Maybe we can gain some speed especially for the libavcodec.dll - VS2008sp1 (x64) ?! :confused:

Source http://www.theregister.co.uk/2009/02/03/parallel_studio_beta/

[leeperry]

@Haruhiko : maybe you could remove dsp_vst.dll from the winamp2 plugin blacklist, because a lot of versions don't work at all...but this one works perfectly fine :
http://www.savioursofsoul.de/Christian/Programs/WinAmp_VST_Bridge.exe

I'm using it w/ this plugin w/o a itch :

http://www.crysonic.com/graphics/spectralivenxt_screenshot.jpg

just once in a while it kills MPC at opening, but you know that bug...basically ffdshow kills the DLL before closing it(same problem as w/ OzoneMP).

it even works w/ Effect Chainer, so you can chain as many DX/VST plugins as you'd like in ffdshow...too awesome :D

http://www.image-load.eu/out.php/i143204_plop11.png

it would be great if we could hide Effect Chainer's window so it never shows up...maybe ffdshow could kill it automatically ? that'd be so great :o

[mark0077]

Great to see the new ffdshow rgb conversion section. Its getting there.

Two questions for you guys

1) Is the new high quality yuy2 -> RGB32HQ coded into the latest builds yet?

2) Is there plans / any need to incorporate the two different Rec. 601's that are out there, and if not which one is being used. (I got the impression from previous discussions that there were two different Rec.601, one being something to do with European DVD's which would apply to myself)

I was under the impression there would be both 709, and the two different 601's listed in the new ffdshow options for completeness.

[yesgrey]

(I got the impression from previous discussions that there were two different Rec.601, one being something to do with European DVD's which would apply to myself)

No. There is only one Rec.601 matrix which applys to both PAL and NTSC dvds. The differences between PAL and NTSC are in the transfer functions and in the primaries, but none of these differences affect the YCbCr->RGB conversion.

[tetsuo55]

We could include the correct primaries for the following cases:

We have now got a 100% accurate SD/HD detection(Unless the file was encoded incorrectly, but that's what manual settings are for)
So all we would have to check is framerate:
25/50 PAL
30/60 NTSC
24 unknown (no change)
Other unknown (no change)

And for HD it would be sRGB for all framerates.

And for those HD cases with different primaries we have the manual settings.

------

The end user would have to choose output primaries.
Default would be sRGB/709 (monitors/HD displays)
But the user can choose whatever his display supports
NTSC/PAL/sRGB/Manually from calibration hardware

Ofcourse all of this should be based on 3D-luts (so we need basic ones on top of the per-user custom ones)

[clsid]

I made an interesting discovery with regard to the 64-bit build.

If I add "-mfpmath=387" to the compiler flags then libavcodec vorbis works again! It was broken before. That setting is used by default by GCC for 32-bit builds. For 64-bit builds GCC normally defaults to using -mfpmath=sse.
However it breaks WMA decoding. ffdshow just outputs silence, like it also already did for AMR audio.

[Taurus]

As a long time user of ffdshow, since when Milan Cutka was still around..
For the first time I found this most annoying behaviour in ffdshow.
My childrens PC's are mostly equipped with older hardware, Athlon XP 2200 and up.
Everytime I call up the video or audio properties page it takes about half a minute
until the windows load and the video and audio gets stuttering in the background.
So I did a little investigation. Every version of ffdshow before the 08.12.2008 is doing fine,
almost immediately the properties window pops up.
So ffdshow_rev2421_20081205_clsid.exe is the last good working.
ffdshow_rev2447_20081208_clsid.exe is the first one which shows the lags.
WinXP SP3 on three machines

[clsid]

Old hardware shouldn't be the issue. ffdshow works fine for me on even older hardware than you have. Settings load instantly.

[Monamona]

Under YCbCr specification set to Auto, it seems that ITU-R BT.709 is used only for width > 1024.
However, it should be also used for hight >=720 as HDTV definition.

[leeperry]

Ofcourse all of this should be based on 3D-luts (so we need basic ones on top of the per-user custom ones)
problem is : each LUT is 48 mb so one for 601/one for 709...we're talking about ffdshow requiring at least 100 mb of HDD space(and better not get them fragmented, I personnaly copy them on a ramdisk :D )

they compress to 1 mb w/ WinRAR so the installer size is no problem, though.

[Taurus]

Old hardware shouldn't be the issue. ffdshow works fine for me on even older hardware than you have. Settings load instantly.
I think you got me wrong.
ffdshow is working fine here up to the newest releases.
It's only opening the properties windows which shows this weird behaviour.
And I tested all versions from late november08 to January09.
It exactly changes between 05.12.2008 and 08.12.2008.
I've read the changelog @sourceforge but could'nt see any significant changes at this time in the gui.
I'm not complaining, just wondering :p

[Leak]

they compress to 1 mb w/ WinRAR so the installer size is no problem, though.
ffdshow already includes the unrar sources so keeping them compressed shouldn't be hard.

Also, how long does calculating those tables take? If it's a couple of seconds tops it's something that could be done right after installation...

[leeperry]

how long does calculating those tables take? If it's a couple of seconds tops it's something that could be done right after installation...
takes less than 5 seconds on my o/c Q6600 :cool:

[haruhiko_yamagata]

As a long time user of ffdshow, since when Milan Cutka was still around..
For the first time I found this most annoying behaviour in ffdshow.
My childrens PC's are mostly equipped with older hardware, Athlon XP 2200 and up.
Everytime I call up the video or audio properties page it takes about half a minute
until the windows load and the video and audio gets stuttering in the background.
So I did a little investigation. Every version of ffdshow before the 08.12.2008 is doing fine,
almost immediately the properties window pops up.
So ffdshow_rev2421_20081205_clsid.exe is the last good working.
ffdshow_rev2447_20081208_clsid.exe is the first one which shows the lags.
WinXP SP3 on three machines
I can't reproduce now, but I experienced the slowdown several times. Maybe the settings in the registry is broken somehow.
Don't you have garbled AviSynth script?
Could you save the settings and uninstall/reinstall? If it fixes the problem, please send me the settings.

[Taurus]

I can't reproduce now, but I experienced the slowdown several times. Maybe the settings in the registry is broken somehow.
Don't you have garbled AviSynth script?
Could you save the settings and uninstall/reinstall? If it fixes the problem, please send me the settings.
Uninstall/Reinstall, cleaning registry, -nothing changes.
Avisynth in conjunction with ffdshow works fine as far as I can see.
I can open any directshowsource and avisource script without any errors or misleading colours.
And remember, I did it the hard way, testing every release from late november till january.
The turning point was at 5th to 8th December.
Thank you for your interest in this thing.

Taurus

[iSunrise]

...and the video and audio gets stuttering in the background.
I experienced something of that kind 2 weeks ago, strange thing is that this problem went away after some updates to my Vista x64 SP1. The video and audio started to stutter right after I clicked the right mouse button and the context-menu showed up and kept stuttering until I closed the context-menu again. Happened both with EVR and Haali as renderer and both with ffdshow and the standard MS WMVideo/Audio Decoder.

I read that you use XP SP3, but nevermind, I´m gonna post it anyway, because it may help with your problem.

Since I didn´t really use a stop watch, all that I can remember is that I´ve installed the latest DirectX-redist directly from Microsoft (http://www.microsoft.com/downloads/details.aspx?FamilyId=2DA43D38-DB71-4C1B-BC6A-9B6652CD92A3&displaylang=en), because 3DMark Vantage asked for d3dx10_36.dll amongst other things. There were also _a lot_ of other files updated, which I didn´t expect since I´ve installed a fresh new Vista x64 SP1 from a bought DSP DVD.

After these updates I´ve never had any problems anymore, everything runs rock stable and fast (currently using x86 ffdshow, since MT had problems with some of my MP4 files, I´m not using x64 since I´m not sure if it is wortwhile). Maybe there were some new files related to DirectShow in there, I´m not sure.

Try it if you didn´t already do this. Maybe it solves your problem.

[tobinaka]

Thanks for ffdshow tryouts developers! I installed rev2653 (2nd Feb 2009) and saw video_full_range_flag interpreted correctly, how nice it is! I'm looking forwards to seeing a new stable version goes released.

I think it would be better if there is such a notice in "RGB conversion" setting like "uncheck all YUV from 'Supported output colorspaces' in output setting". Some people who gave me comments in my blog, and I also, have a simple mistake not to uncheck them. I guess that YUVs have higher priority than RGB to be send for renderes, then if a YUV is checked at "Supported output colorspaces' not RGB which is converted at ffdshow but YUV goes directly to renderers. Don't say those mistakes are stupid. Even if so, the fact is there are some users who miss unchecking them and all the option at "RGB conversion" may get affected by 'Supported output colorspaces'.

By the way, in rightside menu of ffdshow Japanese version "RGB conversion" isn't intended below "output". That's partly why some Japanese made the mistakes as above. Someone told me he wanted to correct and asked me where to reporte it. Please update it if you can.



What about my algorithm :D

AviSynth's YV12->YUY2 converter does this vertically, but it has limitation of output bit depth (naturally 8bit).
My implementation output 10bit vertical 75:25 averaging, 12 bit horizontal 75:25 averaging, other calculations are more than 10bit.


After thinking about chroma locations, I think bilinear interpolation is the best way. Your 75:25 is good, but it's only for "chroma sample type 1" in Annex E of H.264/AVC recommendation. Indeed, that's the way of YUV converting in AviSynth as much as in huffyuv and Ut Video Codec Suite. But it's not the only way: H.264 recommendation says there are 6 way to locate chroma samples. For example, I found "chroma sample type 0" the most suitable for the result of YUV converting in AviUtl, a video editor which has been widely used in Japan and in Asia as I heard. The documentation of x264 says "type 0" is for MPEG-2 and "type 1" is for JPEG-1 and MPEG-1.

Annex E of H.264 recommendation determines 6 chroma sample types and indicated on a figure, but for reference I explain it with the figures I made.

http://www.tobinaka.com/files/4luma.jpg <- 2x2 luma locations. Two upper luma are of top fields and two lower luma are of bottom fields.
http://www.tobinaka.com/files/6chromaloc.jpg <- 6 chroma sample types on it.

IMO, the locations of each chroma sample type tell how 2x2 chroma samples was down-scaled into 1x1 sample. One of the most important information about chroma is its value. The value of 1x1 chroma is usually given at the avarage from 1 to 4 samples of chroma. Then if you avarage not only their values but also their locations? I think that's the locations of 6 chroma sample types.

http://www.tobinaka.com/files/chromaloc0.jpg　http://www.tobinaka.com/files/chromaloc1.jpg　http://www.tobinaka.com/files/chromaloc2.jpg　http://www.tobinaka.com/files/chromaloc3.jpg　http://www.tobinaka.com/files/chromaloc4.jpg　http://www.tobinaka.com/files/chromaloc5.jpg

If the value of 1x1 chroma is the average of all of 2x2 chroma samples, the location of 1x1 chroma is the same as type 1.
If you make the value of 1x1 chroma by avaraging two rightside samples, the location of 1x1 chroma is the same as type 0.

So, how you use those informations of chroma sample types? I think it should be used for interpolation in converting YUV 4:2:0 into 4:4:4 or RGB. I show below 16 locations of chroma samples type 0 or 1 around the chroma sample you want to determine in YUV 4:4:4.

http://www.tobinaka.com/files/16chromaloc1.jpg
chroma sample type 1, the same 75:25 avarage linear interpolation in vertical and horizontal.
http://www.tobinaka.com/files/16chromaloc0.jpg chroma sample type 0, for MPEG-2 and x264 default.

You will find the figures above similar to the calculation for bicubic or B-spline interpolation. Those figures is useful to think about bilinear interpolation: see only 4 chroma locations around the red point.

If you support H.264 chroma sample types, the speed will become slower than your simple 25:75 avarage converting. And many users don't set H.264's chroma sample type in the right way. The default at x264 is chroma sample type 0 but the way of AviSynth looks like type 1 for me.

But I prefer what's written at H.264 recommendation to the current situation. So, how about setting the current way as default and add the option of "auto" like video_full_range_flag?

[ikarad]

I have the same issue. I have to move the slider before the sound will kick in (or alternately I can click on the subtitle option in the splitter output). I am using an ATI HDMI sound card. I have used various revs of MPC-HC filters along with different revs of ffdshow. This only happens with TrueHD. thx

rev2653 corrects your problem or not?

[ikarad]

I have fixed the first bug already : no sound on some MLP/TrueHD samples.

Done in revision 2648

Concerning the other bug you mentioned, I wonder how to test it without an ATI 4xxx or a sound card that can handle HD bitstream ?

Maybe the previous fix will solve the problem...

thanks,
But I have problem with an other video.
sample here:
http://www.zshare.net/info.html?55201231-bd04da067f0414b262f3c37ee94b83ab

Sound disappears after 20 seconds (rev2653).
I notice that jitter is very bad (-8656 ms)
http://nsa05.casimages.com/img/2009/02/06/mini_090206054500879129.jpg (http://www.casimages.com/img.php?i=090206054500879129.jpg)


one question: what is the other bug?

If it's the bug that ffdshow doesn't recognize lpcm sountrack from blu-ray, this problem isn't resolved

And I don't understand why you must have ati HD4xxx because even with stereo lpcm soundtrack (2.1), ffdshow isn't capable to listen lpcm soundtrack from blu-ray

[haruhiko_yamagata]

Thanks for ffdshow tryouts developers! I installed rev2653 (2nd Feb 2009) and saw video_full_range_flag interpreted correctly, how nice it is! I'm looking forwards to seeing a new stable version goes released.

I think it would be better if there is such a notice in "RGB conversion" setting like "uncheck all YUV from 'Supported output colorspaces' in output setting". Some people who gave me comments in my blog, and I also, have a simple mistake not to uncheck them. I guess that YUVs have higher priority than RGB to be send for renderes, then if a YUV is checked at "Supported output colorspaces' not RGB which is converted at ffdshow but YUV goes directly to renderers. Don't say those mistakes are stupid. Even if so, the fact is there are some users who miss unchecking them and all the option at "RGB conversion" may get affected by 'Supported output colorspaces'.
I think it's the worst part of ffdshow's GUI. I agree it needs to be improved.
CoreAVC has a good GUI, but that may not suit for ffdshow. ffdshow has "Select closet matching colorspace" feature. For example, if the input is YUY2 ffdshow output YUY2 instead of YV12.
Maybe simple check box "Prefer RGB32" may help, but what about NV12?
Maybe a check box "Force output colorspace" + combo box [YV12, YUY2, NV12, RGB32]? Fallbacks will be allowed.

By the way, in rightside menu of ffdshow Japanese version "RGB conversion" isn't intended below "output". That's partly why some Japanese made the mistakes as above. Someone told me he wanted to correct and asked me where to reporte it. Please update it if you can.OK, I'll do so.

After thinking about chroma locations, I think bilinear interpolation is the best way. Your 75:25 is good, but it's only for "chroma sample type 1" in Annex E of H.264/AVC recommendation. Indeed, that's the way of YUV converting in AviSynth as much as in huffyuv and Ut Video Codec Suite. But it's not the only way: H.264 recommendation says there are 6 way to locate chroma samples. For example, I found "chroma sample type 0" the most suitable for the result of YUV converting in AviUtl, a video editor which has been widely used in Japan and in Asia as I heard. The documentation of x264 says "type 0" is for MPEG-2 and "type 1" is for JPEG-1 and MPEG-1.

Annex E of H.264 recommendation determines 6 chroma sample types and indicated on a figure, but for reference I explain it with the figures I made.
Thank you for the info. It shouldn't be too hard to support type 0. Other types may not worth while.
But recent experiments seem to indicate type 1 looks better for MPEG-2 samples. More experiments are welcome.

[haruhiko_yamagata]

Uninstall/Reinstall, cleaning registry, -nothing changes.
Avisynth in conjunction with ffdshow works fine as far as I can see.
I can open any directshowsource and avisource script without any errors or misleading colours.
And remember, I did it the hard way, testing every release from late november till january.
The turning point was at 5th to 8th December.
Thank you for your interest in this thing.

Taurus
Thank you for your tests. I can't find anything suspicious between revision 2421 and 2447.
Only one thing relevant is rev 2441, which correct initialization of CRT.
As iSunrise pointed, it may be related to some bugs of OS or other device drivers, as initialization of CRT may invoke initializer of GDI and DirectX.

[madshi]

In revision 2653 (haven't checked newer revisions) there's a checkbox "High quality YV12 to RGB conversion" in both the "Output" and "RGB conversion" tabs. Wouldn't it make more sense to have this option only in the "RGB conversion" tab and to remove it from the "Output" tab? I always found that logically it didn't really belong into the "Output" tab, anyway. Fits much better into the "RGB conversion" tab.

Thank you!!

[haruhiko_yamagata]

In revision 2653 (haven't checked newer revisions) there's a checkbox "High quality YV12 to RGB conversion" in both the "Output" and "RGB conversion" tabs. Wouldn't it make more sense to have this option only in the "RGB conversion" tab and to remove it from the "Output" tab? I always found that logically it didn't really belong into the "Output" tab, anyway. Fits much better into the "RGB conversion" tab.

Thank you!!OK, I'll remove it next time I change the dialog.

[albain]

thanks,
But I have problem with an other video.
sample here:
http://www.zshare.net/info.html?55201231-bd04da067f0414b262f3c37ee94b83ab

Sound disappears after 20 seconds (rev2653).
I notice that jitter is very bad (-8656 ms)
http://nsa05.casimages.com/img/2009/02/06/mini_090206054500879129.jpg (http://www.casimages.com/img.php?i=090206054500879129.jpg)


one question: what is the other bug?

If it's the bug that ffdshow doesn't recognize lpcm sountrack from blu-ray, this problem isn't resolved

And I don't understand why you must have ati HD4xxx because even with stereo lpcm soundtrack (2.1), ffdshow isn't capable to listen lpcm soundtrack from blu-ray

Ok I reproduce the problem : it is working but the jitter causes problem. I remember I disabled jitter correction for MLP because it was causing problems. I will digg this around.

Concerning LPCM, I have no problem playing LPCM 2.0 but you mentioned LPCM coming from blurays, maybe the bandwidth is higher or the sample rate is different. Anyway, if you are able to extract a sample it will help. Also it may be interesting if you can confirm that you also have no sound using SPDIF output of your motherboard and not HDMI of your graphic card.

[yesgrey]

OK, I'll remove it next time I change the dialog.
haruhiko,
next time you'll change the dialog you could also correct some little details... here is a pic with those little details marked with red:
9406
Two "chroma" words were not substituted by CbCr, some spaces that were not removed between the '(' and ')', and in the last there are two spaces and it would look better just one, to be like the other text labels.

Forgive my pickiness...;)

[ikarad]

Ok I reproduce the problem : it is working but the jitter causes problem. I remember I disabled jitter correction for MLP because it was causing problems. I will digg this around.

Concerning LPCM, I have no problem playing LPCM 2.0 but you mentioned LPCM coming from blurays, maybe the bandwidth is higher or the sample rate is different. Anyway, if you are able to extract a sample it will help. Also it may be interesting if you can confirm that you also have no sound using SPDIF output of your motherboard and not HDMI of your graphic card.

for the sample : This sample have three soundtracks: one mlp and two lpcm 2.1.
http://www.zshare.net/info.html?54307328-f4cf1e029ba268fd6fc1e3907e3ab1dc

a second example with lpcm 2.1 and lpcm 6.1 soudntrack
http://www.zshare.net/info.html?55241905-3d52058746470a1fa90c6eed8b81c6ea


For spidf, I'm sorry but I can't try because my speakers only offers analogic output and not digital output. I d'ont use HDMI from my grphic card.
I use vga connector from my graphic card (I have CRT monitor) and for sound I use analogic connector from my soundcard (xfi titanium)

[v0lt]

I found a bug in DirectShow Huffyuv-decoder in ffdshow-mt rev2644.
I coded my video by Huffyuv v2.1.1 (YUY2). I get blue color instead of red in MPC.
In ffdshow beta6 bug is not watching.

Effect like http://forum.doom9.org/showthread.php?p=1229050#post1229050

[ACrowley]

One Question :

Is ffdshow _MT already /merged integrated in "standard" ffdshow tryouts ? No it isnt correct ?

I mean MT Build was faster for example on 1080p Bluray H264 1,85:1 with internal Subtitle Decoder enabled. ffdshow non MT was stuttering a bit and goes out of sync when the Subtitle Decoder was enabeld too

[clsid]

No, it is still a separate branch.

[Jeremy Duncan]

If you don't resize/scale the convert yv12 to rgb32, standard contrast.

Does this mean if I resize the picture in ffdshow, the conversion is being applied to a non-resized resolution?

Should it not be if I make the picture 1080p through resizing, the rgb conversion be applied to 1080p rather than 720x480?

[haruhiko_yamagata]

I would like to use Boost C++ Libraries (http://www.boost.org/) to make the new color space converters multithreaded and still keeping it portable.

Patch (http://ffdshow-tryout.sourceforge.net/samples/multithreading_of_ffdshow_converters.patch)

Thanks to threadpool (http://threadpool.sourceforge.net/), multithreading is realized by very simple and clean code.
Because ffdshow color space converter is C++ template code, multithreading of it should be done in the way of C++. Boost and threadpool helps much.

By the way, should we add Boost to our svn? It's 41.8MB, almost as big as ffdshow (67.5MB). If we add it, it will over 100MB. If we do not, new developers will suffer a bit. Version compatibility may be a issue.
Boost installer is available from here (http://www.boostpro.com/products/free).

On Core2 Quad, it is 3.2x faster, it is faster with "High quality YV12->RGB conversion" checked than unchecked (probably on Core2 Duo too). Of course my purpose is to make that option checked by default on modern CPUs (SSSE3 + core > 1).

[ACrowley]

No, it is still a separate branch.

ok, is MT significant faster in multithreading ? As i say, non MT stutters/async a bit on some 16:0 Full Frame Bluray with Subtitles enabled. MT not.

[_xxl]

By the way, should we add Boost to our svn? It's 41.8MB, almost as big as ffdshow (67.5MB). If we add it, it will over 100MB. If we do not, new developers will suffer a bit. Version compatibility may be a issue.
Yes, please add it.

[Leak]

Yes, please add it.
Isn't that what SVN externals (http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html) are for, though?

(Unless there's a need to make ffdshow-related changes to the Boost source code, that is...)

np: Fennesz - Perfume For Winter (Black Sea)

[haruhiko_yamagata]

Isn't that what SVN externals (http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html) are for, though?

(Unless there's a need to make ffdshow-related changes to the Boost source code, that is...)

np: Fennesz - Perfume For Winter (Black Sea)
Boost FAQ (http://www.boost.org/users/faq.html)How can the Boost libraries be used successfully for important projects?
Many of the Boost libraries are actively maintained and improved, so backward compatibility with prior version isn't always possible. Deal with this by freezing the version of the Boost libraries used by your project. Only upgrade at points in your project's life cycle where a bit of change will not cause problems. Individual bug fixes can always be obtained from the boost repository.

[_xxl]

I would like to use Boost C++ Libraries to make the new color space converters multithreaded and still keeping it portable.
Thanks to threadpool, multithreading is realized by very simple and clean code.
Because ffdshow color space converter is C++ template code, multithreading of it should be done in the way of C++. Boost and threadpool helps much.

Bin:
http://www.dump.ro/fisiere/ffdshow-rev2664-20090208-xxl-zip/90216/Cp8OZN7cpRsuXSk5

[Leak]

Boost FAQ (http://www.boost.org/users/faq.html)
SVN externals docs (http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html)
You should seriously consider using explicit revision numbers in all of your externals definitions. Doing so means that you get to decide when to pull down a different snapshot of external information, and exactly which snapshot to pull. Besides avoiding the surprise of getting changes to third-party repositories that you might not have any control over, using explicit revision numbers also means that as you backdate your working copy to a previous revision, your externals definitions will also revert to the way they looked in that previous revision, which in turn means that the external working copies will be updated to match the way they looked back when your repository was at that previous revision. For software projects, this could be the difference between a successful and a failed build of an older snapshot of your complex codebase.
Just add the revision for any (stable?) release of Boost to the external and update that revision when you think it's ready...

np: Joy Division - The Only Mistake (Still)

[haruhiko_yamagata]

Bin:
http://www.dump.ro/fisiere/ffdshow-rev2664-20090208-xxl-zip/90216/Cp8OZN7cpRsuXSk5
Thank you.

Guys who have Core2 Duo or Pentium D, could you tell me if it is faster with "High quality ..." checked than unchecked?

[haruhiko_yamagata]

SVN externals docs (http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html)

Just add the revision for any (stable?) release of Boost to the external and update that revision when you think it's ready...

np: Joy Division - The Only Mistake (Still)
Oh, I should have read it carefully.
Then it should work.

[clsid]

Or alternatively, just put a zip/rar/7z archive on the sourceforge website with the correct Boost libs that ffdshow needs. Then anyone can just download it once, instead of several times (once for each active branch). Put a text file in SVN with instructions on where to download it.

Speaking of branches. Do we want to keep the old inactive branches? Imo we could delete them.

Haruhiko, are you planning to write converters for all colorspaces? Does that mean we can eventually get rid of imgconvert and part of libswscale?

[clsid]

ok, is MT significant faster in multithreading ? As i say, non MT stutters/async a bit on some 16:0 Full Frame Bluray with Subtitles enabled. MT not.
The whole idea of the experimental multi-threading (= MT) branch is to have better decoding performance due to MT. It is still a work in progress. There are bugs. So use at own risk.

[_xxl]

I hope that soon MT and trunk will merge. haruhiko_yamagata is working to add MT to ffdshow's converters, maybe some other filters.

[tetsuo55]

I would like to use Boost C++ Libraries (http://www.boost.org/) to make the new color space converters multithreaded and still keeping it portable.

Patch (http://ffdshow-tryout.sourceforge.net/samples/multithreading_of_ffdshow_converters.patch)

Thanks to threadpool (http://threadpool.sourceforge.net/), multithreading is realized by very simple and clean code.
Because ffdshow color space converter is C++ template code, multithreading of it should be done in the way of C++. Boost and threadpool helps much.

By the way, should we add Boost to our svn? It's 41.8MB, almost as big as ffdshow (67.5MB). If we add it, it will over 100MB. If we do not, new developers will suffer a bit. Version compatibility may be a issue.
Boost installer is available from here (http://www.boostpro.com/products/free).

On Core2 Quad, it is 3.2x faster, it is faster with "High quality YV12->RGB conversion" checked than unchecked (probably on Core2 Duo too). Of course my purpose is to make that option checked by default on modern CPUs (SSSE3 + core > 1).


Cool!!

Some functions could be even faster than that if you use Libco. A long time ago we ran all kind's of tests comparing boost-thread with libco and is some cases it is up to 300x faster

you can find it here:http://byuu.cinnamonpirate.com/programming/

Released under PD but the author would like to recieve the changes so he can updated the PD archive.

[haruhiko_yamagata]

Maybe it's time to consider having two libavcodec in the trunk. Maintaining two branches is hard.
I give up updated libswscale.

[haruhiko_yamagata]

Cool!!

Some functions could be even faster than that if you use Libco. A long time ago we ran all kind's of tests comparing boost-thread with libco and is some cases it is up to 300x faster

you can find it here:http://byuu.cinnamonpirate.com/programming/

Released under PD but the author would like to recieve the changes so he can updated the PD archive.
I choose Boost because its thread library is very likely to be the next standard of C++ language.
I think overhead of thread is negligible in this case because each task is big enough.

[haruhiko_yamagata]

Or alternatively, just put a zip/rar/7z archive on the sourceforge website with the correct Boost libs that ffdshow needs. Then anyone can just download it once, instead of several times (once for each active branch). Put a text file in SVN with instructions on where to download it.Checking out takes a bit of time, but the advantage of version management outweighs IMO.
Inconveniently, threadpool is on CVS.

Speaking of branches. Do we want to keep the old inactive branches? Imo we could delete them.
What's the point of deleting? I hardly check out all.

Haruhiko, are you planning to write converters for all colorspaces? Does that mean we can eventually get rid of imgconvert and part of libswscale?
No, I don't have plan to write RGB->YCbCr conversion.

[clsid]

Maybe it's time to consider having two libavcodec in the trunk. Maintaining two branches is hard.
I give up updated libswscale. That would be a good idea, provided that the only differences are in libavcodec. Is trunk ffdshow.ax currently capable of working together with ffdshow-mt libavcodec.dll?
What's the point of deleting? I hardly check out all.I don't check them out either, but others might (accidentally) do. Is there any point in keeping them? If nobody is using them, we might as well clean them up.

[_xxl]

Is trunk ffdshow.ax currently capable of working together with ffdshow-mt libavcodec.dll?
No, there are changes in ffdshow.ax.
I don't check them out either, but others might (accidentally) do. Is there any point in keeping them? If nobody is using them, we might as well clean them up.
Delete them, not used anymore.

[Leak]

I don't check them out either, but others might (accidentally) do. Is there any point in keeping them? If nobody is using them, we might as well clean them up.
You can't really delete them anyway unless you dump/filter/load the SVN repository, as an SVN delete just hides the files you deleted - they'll still always be there in the earlier revisions.

But if you mean to prevent people who check out the whole repository instead of the trunk or a branch from wasting bandwidth - why not?

np: Joy Division - Dead Souls (Unknown Pleasures Extras)

[yesgrey]

Guys who have Core2 Duo or Pentium D, could you tell me if it is faster with "High quality ..." checked than unchecked?
I have, but the link above doesn't work, so no ffdshow version that I could test...

Edit: I have downloaded it. Will test and post results.

[@Tron@]

Hello all!

Long wanted to learn how you can update ffdshow??? I have ffdshow version 2624 and want to upgrade to 2665 (the latter at the moment ffdshow-tryout)

How can I update it????

[iron2000]

Having problem with all videos having Vorbis sound.
The sound comes out stuttering and theres this crackling sound also.
Both Tremor and libavcodec have the problem.
The MPC-HC filter has it too.

All other sound formats play fine.

Noticed this on 2653 and 2661.

Ok, I found the cause.
Under MPC-HC's options for the "DirectShow Audio" dropdown, the entry of type "DirectSound: ..." need to be selected.

[rack04]

Hello all!

Long wanted to learn how you can update ffdshow??? I have ffdshow version 2624 and want to upgrade to 2665 (the latter at the moment ffdshow-tryout)

How can I update it????

Latest build that I've seen is 2661.

[iSunrise]

Thank you.

Guys who have Core2 Duo or Pentium D, could you tell me if it is faster with "High quality ..." checked than unchecked?
I´d love to, but what exactly do I have to install? xxl´s build and Boost (you mentioned it) 1.37?

Cause without Boost, all my current players (e.x. ZoomPlayer) crash instantly when using that build. Before installing I had clsid´s build rev2649 icl10 (and all builds from him before it) working without problems. After installing clsid´s latest build again, everything is back to normal. I´m on Vista x64 with a Core i7 (all cores/MT enabled).

[clsid]

No, there are changes in ffdshow.axMaybe Haruhiko can solve that issue. Shouldn't be too difficult I think.

Then we could create an ffmpeg-mt directory in trunk for the MT version of libavcodec. That would mean we only need to keep that second copy of libavcodec updated, no more need for a whole separate branch.

I could even add an option in the installer to choose which version of libavcodec to use.

[_xxl]

Then we could create an ffmpeg-mt directory in trunk for the MT version of libavcodec. That would mean we only need to keep that second copy of libavcodec updated, no more need for a whole separate branch.

I could even add an option in the installer to choose which version of libavcodec to use.

I should start merging all updates from mt to trunk.

[_xxl]

Is anybody experiencing ffdshow crashes if mplayer temporal noise reducer is enabled. 2653 trunk and 2644 mt are fine, but 2664 is not.

[Mercury_22]

ffdshow (libmpeg2) rev 2661 & 2664 it's crashing when seeking !
Version rev 2653 it's OK !

[@Tron@]

Latest build that I've seen is 2661.

http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2665 Then its not ffdshow update ( or path ) ???

[_xxl]

Not every revision gets to be build. I compile ffdshow when time is available.

[clsid]

ffdshow (libmpeg2) rev 2661 & 2664 it's crashing when seeking !
Version rev 2653 it's OK !
Either the problem occurs randomly, or it is a difference between builds. Nothing has changed in the code in those revisions that can cause a crash.
Do the 'broken' builds work if you copy libmpeg2_ff.dll from the 'working' build?

[_xxl]

I think that those crashes come from 2660. I've done a test build with 2659 and no crashes. I should test more, maybe I'm wrong.

[@Tron@]

Not every revision gets to be build. I compile ffdshow when time is available.

And how do you do it ( compile ffdshow ) ???

What programs need ??

[Mercury_22]

Either the problem occurs randomly, or it is a difference between builds. Nothing has changed in the code in those revisions that can cause a crash.
Do the 'broken' builds work if you copy libmpeg2_ff.dll from the 'working' build?

I don't have that mpeg2 file any more but now I get a crash with ffdshow.ax Problem Event Name: BEX
Application Name: mplayerc.exe
Application Version: 1.2.988.0
Application Timestamp: 49861768
Fault Module Name: ffdshow.ax
Fault Module Version: 1.0.5.2462
Fault Module Timestamp: 498dc3c5
Exception Offset: 001f56f6
Exception Code: c0000417
Exception Data: 00000000
OS Version: 6.0.6002.2.2.0.256.1
Locale ID: 1033
Additional Information 1: 7ec4
Additional Information 2: 165a3f55fb11351ed7df118f8a20d5b4
Additional Information 3: 177c
Additional Information 4: ecc854e453e687b4d733365bb227284d
with several other mpeg2 files when seeking or just when I start playing the files
Again ffdshow_rev2653_20090202_sse_icl10 it's last working rev i can get my hands on !

P.S. copying libmpeg2_ff.dll from the 'working' build it's NOT helping but as i've said now it's ffdshow.ax crashing so... If you need I'll do more tests tomorrow . Let me know !
AVC files are OK with the 'broken' (ALL) builds


EDIT: Found the problem ! It's the combination between MPC-HC's MPEG splitter and rev 2661, 2664, 2666 because when I'm using other splitter or rev 2653 everything it's OK ! no more crashing !

[alexins]

I don't have that mpeg2 file any more but now I get a crash with ffdshow.ax with several other mpeg2 files when seeking or just when I start playing the files
Again ffdshow_rev2653_20090202_sse_icl10 it's last working rev i can get my hands on !

P.S. copying libmpeg2_ff.dll from the 'working' build it's NOT helping but as i've said now it's ffdshow.ax crashing so... If you need I'll do more tests tomorrow . Let me know !
AVC files are OK with the 'broken' (ALL) builds


EDIT: Found the problem ! It's the combination between MPC-HC's MPEG splitter and rev 2661, 2664, 2666 because when I'm using other splitter or FFD rev 2653 everything it's OK ! no more crashing !

This problem appeared, starting with the audit of 2660, 2659 last working version.

[Mercury_22]

This problem appeared, starting with the audit of 2660, 2659 last working version.

It's NOT manifesting in VOB file just in ts and m2ts so far
More testing with other type of files later !

@ alexins can you PLEASE compile rev 2659 and 2660 for testing ?:helpful:

EDIT: AVC in ts or m2ts files crashing too (previously tested only AVC in MKV) !! So after more testing I've discover that it's the AUDIO which it's crashing with the "new" rev and MPC-HC's mpeg splitter because when i'm using MPC-HC's internal audio filters and FFD (all rev) video (avc, mpeg.....) everything it's OK with the same files which previously were crashing on me !!!!!!!!

EDIT 2 : Vob files are crashing too ! but after more "intensing" seeking

[alexins]

@ alexins can you PLEASE compile rev 2659 and 2660 for testing ?:helpful:


2659, 2660, 2666 x86/x64 (http://www.xvidvideo.ru/clsid/for_Mercury_22.zip)

[STaRGaZeR]

clsid, have you take a look at the several decoders that revert back to the closest option if the current one is not in the installer's list? Example: WMV3, wmv9 selected as decoder, after a new install it reverts to libavcodec. It's really annoying, I have to manually reconfigure it each time I install a new build to test.

Haruhiko, how do you bench exactly? We need to know it if we want accurate results.

[Mercury_22]

2659, 2660, 2666 x86/x64 (http://www.xvidvideo.ru/clsid/for_Mercury_22.zip)

Thanks :thanks: :D

I can confirm that the problem it's starting with Revision 2660 - Directory Listing
Modified Sat Feb 7 08:55:27 2009 UTC (40 hours, 42 minutes ago) by h_yamagata
Use MSVC's STL instead of uClibc++. and it has something to do with ffdshow's audio component and MPC-HC's MPEG PS/TS/PVA splitter :confused::helpful:

[madshi]

Guys who have Core2 Duo or Pentium D, could you tell me if it is faster with "High quality ..." checked than unchecked?
Is there an easy and reliable way to get proper test results? Just playing a USA 1080i60 broadcast with "DScaler with IVTC mod -> ffdshow raw video processor" and looking at the task manager's CPU consumption graphs it seems to me that "High quality" is still slower by maybe 10% on my Core 2 Duo (Merom), but that's a very rough estimate...

[haruhiko_yamagata]

Is there an easy and reliable way to get proper test results? Just playing a USA 1080i60 broadcast with "DScaler with IVTC mod -> ffdshow raw video processor" and looking at the task manager's CPU consumption graphs it seems to me that "High quality" is still slower by maybe 10% on my Core 2 Duo (Merom), but that's a very rough estimate...
You already have one ;)
C:\Program Files\Haali\MatroskaSplitter\timeCodec.exe
dfps is the result that I need.

[yesgrey]

haruhiko,
Here are my results with Intel E2160@3.0GHz (Core2 duo) XPSP3:
Test Clip 1 - xvid 592x256
ffdshow 2653 enabled High Quality YV12 to RGB conversion:
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 824.0, dfps: 144.3

ffdshow 2653 disabled High Quality YV12 to RGB conversion:
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 824.0, dfps: 148.7

Test Clip 2 - h264 1920x816
ffdshow 2653 enabled High Quality YV12 to RGB conversion:
User: 1s, kernel: 0s, total: 1s, real: 4s, fps: 116.5, dfps: 41.7

ffdshow 2653 disabled High Quality YV12 to RGB conversion:
User: 0s, kernel: 0s, total: 1s, real: 4s, fps: 165.7, dfps: 46.3

Test Clip 1 - xvid 592x256
ffdshow 2666 enabled High Quality YV12 to RGB conversion:
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 988.8, dfps: 145.4

ffdshow 2666 disabled High Quality YV12 to RGB conversion:
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 941.7, dfps: 147.6

Test Clip 2 - h264 1920x816
ffdshow 2666 enabled High Quality YV12 to RGB conversion:
User: 1s, kernel: 0s, total: 1s, real: 4s, fps: 115.4, dfps: 42.8

ffdshow 2666 disabled High Quality YV12 to RGB conversion:
User: 0s, kernel: 0s, total: 1s, real: 4s, fps: 159.6, dfps: 47.9

[haruhiko_yamagata]

I can confirm that the problem it's starting with and it has something to do with ffdshow's audio component and MPC-HC's MPEG PS/TS/PVA splitter :confused::helpful:
I'm not sure if I reproduced your problem.
This includes some bug fixes. (Patch (http://ffdshow-tryout.sourceforge.net/doom9/multithreading_of_ffdshow_converters20090209.patch), Build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev2668_20090209_Q.exe))
Does this fix the problem?

[Mercury_22]

I'm not sure if I reproduced your problem.
This includes some bug fixes. (Patch (http://ffdshow-tryout.sourceforge.net/doom9/multithreading_of_ffdshow_converters20090209.patch), Build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev2668_20090209_Q.exe))
Does this fix the problem?

Sorry but it doesn't fix the problem (NOT just mine !)
Problem signature:
Problem Event Name: BEX
Application Name: mplayerc.exe
Application Version: 1.2.988.0
Application Timestamp: 49861768
Fault Module Name: ffdshow.ax
Fault Module Version: 1.0.5.2402
Fault Module Timestamp: 4990199a
Exception Offset: 0020202b
Exception Code: c0000417
Exception Data: 00000000
OS Version: 6.0.6002.2.2.0.256.1
Locale ID: 1033
Additional Information 1: 7ec4
Additional Information 2: 165a3f55fb11351ed7df118f8a20d5b4
Additional Information 3: 08a2
Additional Information 4: 992dfccb1af028196e2c9b335aa3f011
Please try to play any ts or m2ts using MPC-HC's internal mpeg splitter and ffd's audio (any ac3 or dts or.....) and then try seeking :( :helpful:

EDIT: there is some improvement because the files that were crashing from the start now are crashing only when I'm seeking

[haruhiko_yamagata]

haruhiko,
Here are my results with Intel E2160@3.0GHz (Core2 duo) XPSP3:

Almost!
Is your E2160 heavily overclocked Pentium DC?
Maybe different on 45nm Core2 Duo.

[haruhiko_yamagata]

Sorry but it doesn't fix the problem (NOT just mine !)

Please try to play any ts or m2ts using MPC-HC's internal mpeg splitter and ffd's audio (any ac3 or dts or.....) and then try seeking :( :helpful:

EDIT: there is some improvement because the files that were crashing from the begining now are crashing only when I'm seekingThanks, I found a sample that reproduced the problem.

[Mercury_22]

Thanks, I found a sample that reproduced the problem.

Ok :thanks: Let me know if you need more testing

[madshi]

build 2664, XPSP2, Core 2 Duo Mobile 2.0GHz

USA broadcast, decoded by ffdshow libavcodec, rendered to Overlay Mixer (rendering to NULL didn't work for me).

YV12 dfps: 127,5
Low Quality RGB dfps: 65,6
High Quality RGB dfps: 65,5
When playing back in MPC HC, the CPU consumption with High Quality is a bit higher than without High Quality, though, I think.

[yesgrey]

Is your E2160 heavily overclocked Pentium DC?
Yes. The name is Pentium DC, but it's a Core2 Duo based cpu, with 1MB cache.
Standard clock: 9x200MHz, I overclocked to 9x333MHz.:cool:
Maybe it's performance is lower due to the small cache...

[haruhiko_yamagata]

I have committed all my local changes. (Build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev2671_20090209_Q.exe))

[_xxl]

haruhiko,
Here are my results with Intel E2160@3.0GHz (Core2 duo) XPSP3:
Test Clip 1 - xvid 592x256
ffdshow 2653 enabled High Quality YV12 to RGB conversion:
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 824.0, dfps: 144.3

ffdshow 2653 disabled High Quality YV12 to RGB conversion:
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 824.0, dfps: 148.7

Test Clip 2 - h264 1920x816
ffdshow 2653 enabled High Quality YV12 to RGB conversion:
User: 1s, kernel: 0s, total: 1s, real: 4s, fps: 116.5, dfps: 41.7

ffdshow 2653 disabled High Quality YV12 to RGB conversion:
User: 0s, kernel: 0s, total: 1s, real: 4s, fps: 165.7, dfps: 46.3

Test Clip 1 - xvid 592x256
ffdshow 2666 enabled High Quality YV12 to RGB conversion:
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 988.8, dfps: 145.4

ffdshow 2666 disabled High Quality YV12 to RGB conversion:
User: 0s, kernel: 0s, total: 0s, real: 2s, fps: 941.7, dfps: 147.6

Test Clip 2 - h264 1920x816
ffdshow 2666 enabled High Quality YV12 to RGB conversion:
User: 1s, kernel: 0s, total: 1s, real: 4s, fps: 115.4, dfps: 42.8

ffdshow 2666 disabled High Quality YV12 to RGB conversion:
User: 0s, kernel: 0s, total: 1s, real: 4s, fps: 159.6, dfps: 47.9

I think that no MT is used for a reason with 2666 and your cpu.

[Mercury_22]

I have committed all my local changes. (Build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev2671_20090209_Q.exe))

Yes the problem has been fixed ! :thanks:

Any chance for a 64-bit build too ? PLEASE ! :helpful:

[@Tron@]

So ... How to compile ffdshow and what programs need ??????

[haruhiko_yamagata]

I think that no MT is used for a reason with 2666 and your cpu."High quality ..." was much slower before multithreading, now it's close on his special Pentium DC. Considering the heavy overclocking, I think his result is reasonable.
If his CPU was not overclocked, CPU would be more bottleneck than memory and result might be different.

[haruhiko_yamagata]

So ... How to compile ffdshow and what programs need ??????
This (http://ffdshow-tryout.sourceforge.net/wiki/playground:playground) was the secret place where we were planing for our new wiki.
I'm not sure if this will be our formal wiki.

[@Tron@]

This (http://ffdshow-tryout.sourceforge.net/wiki/playground:playground) was the secret place where we were planing for our new wiki.
I'm not sure if this will be our formal wiki.

Thank you.

But it is possible to explain the details that must be installed and how, how to install that and in what directory, and then how to make exe file, etc. ...

[haruhiko_yamagata]

Any chance for a 64-bit build too ? PLEASE ! :helpful:
OK, here (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev2671_20090209_Q_x64.exe) you go.

[haruhiko_yamagata]

Thank you.

But it is possible to explain the details that must be installed and how, how to install that and in what directory, and then how to make exe file, etc. ...
No, I don't want to explain how to install GCC...

[STaRGaZeR]

With a 45nm Core2Duo, E8400@4GHz (445x9)

H.264 1920x1080 ~37Mbps Blu-ray:

High quality YV12 to RGB conversion enabled --> dfps: 48.8
High quality YV12 to RGB conversion disabled --> dfps: 46.9

H.264 1440x1080 ~15Mbps x264:

High quality YV12 to RGB conversion enabled --> dfps: 85.2
High quality YV12 to RGB conversion disabled --> dfps: 80.9

Tested 3 times each, just to be sure :)

Using Haruhiko's post 6574 build (http://forum.doom9.org/showpost.php?p=1247337&postcount=6574).

[Mercury_22]

OK, here (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev2671_20090209_Q_x64.exe) you go.

:thanks:

[whurlston]

This patch will allow the audio decoder to connect to the ArcSoft Demux and decode EAC3 audio tracks. It also defines the wFormatTag as WAVE_FORMAT_DTS_HD instead of WAVE_FORMAT_DTS_W when the media subtype is MEDIASUBTYPE_ARCSOFT_DTSHD.

Index: src/ffdshow_mediaguids.h
===================================================================
--- src/ffdshow_mediaguids.h (revision 2672)
+++ src/ffdshow_mediaguids.h (working copy)
@@ -394,6 +394,7 @@

DEFINE_GUID(MEDIASUBTYPE_NERO_MLP ,0x1e889be7, 0xb276, 0x4064, 0x9a, 0x39, 0x16, 0x0a, 0x06, 0x89, 0x5b, 0x52);
DEFINE_GUID(MEDIASUBTYPE_ARCSOFT_MLP ,0x4288b843, 0x610b, 0x4e15, 0xa5, 0x3b, 0x43, 0x00, 0x7f, 0xcf, 0xf6, 0x14);
+DEFINE_GUID(MEDIASUBTYPE_ARCSOFT_DDPLUS ,0x71cfa727, 0x37e4, 0x404a, 0xae, 0xc0, 0x34, 0x84, 0x25, 0x32, 0xef, 0xf7);
DEFINE_GUID(MEDIASUBTYPE_SONIC_MLP ,0x4094a857, 0x7891, 0x44ac, 0x92, 0xb5, 0xc1, 0xcf, 0xf3, 0x7a, 0xf2, 0xe7);
DEFINE_GUID(MEDIASUBTYPE_ARCSOFT_DTSHD ,0xf6498f57, 0xb399, 0x4a43, 0xa6, 0xfa, 0xf6, 0x94, 0xad, 0x42, 0xb9, 0xbe);
DEFINE_GUID(MEDIASUBTYPE_DOLBY_DDPLUS ,0xa7fb87af, 0x2d02, 0x42fb, 0xa4, 0xd4, 0x5, 0xcd, 0x93, 0x84, 0x3b, 0xdd);
Index: src/TffDecoder_reg.cpp
===================================================================
--- src/TffDecoder_reg.cpp (revision 2672)
+++ src/TffDecoder_reg.cpp (working copy)
@@ -435,6 +435,7 @@
{ &MEDIATYPE_Audio , &MEDIASUBTYPE_Vorbis2 },
{ &MEDIATYPE_Audio , &MEDIASUBTYPE_VorbisIll },
{ &MEDIATYPE_Audio , &MEDIASUBTYPE_ARCSOFT_MLP },
+ { &MEDIATYPE_Audio , &MEDIASUBTYPE_ARCSOFT_DDPLUS },
{ &MEDIATYPE_Audio , &MEDIASUBTYPE_ARCSOFT_DTSHD },
//{ &MEDIATYPE_Audio , &MEDIASUBTYPE_EAC3 },
{ &MEDIATYPE_Audio , &MEDIASUBTYPE_PCM },
Index: src/TffdshowDecAudio.cpp
===================================================================
--- src/TffdshowDecAudio.cpp (revision 2672)
+++ src/TffdshowDecAudio.cpp (working copy)
@@ -212,7 +212,7 @@
wFormatTag=WAVE_FORMAT_VORBIS;
else if (mt.subtype==MEDIASUBTYPE_DOLBY_AC3)
wFormatTag=WAVE_FORMAT_AC3_W;
- else if (mt.subtype==MEDIASUBTYPE_DTS || mt.subtype==MEDIASUBTYPE_ARCSOFT_DTSHD)
+ else if (mt.subtype==MEDIASUBTYPE_DTS)
wFormatTag=WAVE_FORMAT_DTS_W;
else if (mt.subtype==MEDIASUBTYPE_DVD_LPCM_AUDIO)
wFormatTag=WAVE_FORMAT_LPCM;
@@ -233,9 +233,9 @@
else if (mt.subtype==MEDIASUBTYPE_DOLBY_TRUEHD || mt.subtype==MEDIASUBTYPE_NERO_MLP
|| mt.subtype==MEDIASUBTYPE_ARCSOFT_MLP || mt.subtype==MEDIASUBTYPE_SONIC_MLP)
wFormatTag=WAVE_FORMAT_MLP;
- else if (mt.subtype==MEDIASUBTYPE_DOLBY_DDPLUS)
+ else if (mt.subtype==MEDIASUBTYPE_DOLBY_DDPLUS || mt.subtype==MEDIASUBTYPE_ARCSOFT_DDPLUS)
wFormatTag=WAVE_FORMAT_EAC3;
- else if (mt.subtype==MEDIASUBTYPE_DTS_HD)
+ else if (mt.subtype==MEDIASUBTYPE_DTS_HD || mt.subtype==MEDIASUBTYPE_ARCSOFT_DTSHD)
wFormatTag=WAVE_FORMAT_DTS_HD; // TODO : define a separate codecId for DTSHD when available
else
{

[ikarad]

Ok I reproduce the problem : it is working but the jitter causes problem. I remember I disabled jitter correction for MLP because it was causing problems. I will digg this around.

Concerning LPCM, I have no problem playing LPCM 2.0 but you mentioned LPCM coming from blurays, maybe the bandwidth is higher or the sample rate is different. Anyway, if you are able to extract a sample it will help. Also it may be interesting if you can confirm that you also have no sound using SPDIF output of your motherboard and not HDMI of your graphic card.
for the sample : This sample have three soundtracks: one mlp and two lpcm 2.1.
http://www.zshare.net/info.html?54307328-f4cf1e029ba268fd6fc1e3907e3ab1dc

a second example with lpcm 2.1 and lpcm 6.1 soudntrack
http://www.zshare.net/info.html?55241905-3d52058746470a1fa90c6eed8b81c6ea


For spidf, I'm sorry but I can't try because my speakers only offers analogic output and not digital output. I d'ont use HDMI from my grphic card.
I use vga connector from my graphic card (I have CRT monitor) and for sound I use analogic connector from my soundcard (xfi titanium)


Albain, have you succeed to download my two examples?

[dandy]

re merging mt and main branch

tested mt "just for educational purposes" - and saw
the luma sharpen (resize/setting page) option has different scales (0-2 for normal / 0-1 for mt) - and
luma sharpen doesn't seeem to work with mt (mpeg2 spline resize)

this may only one example for subtle differences between mt and main
for me it wouldn't be nice to loose the resize/sharpen functionality

thanks

[clsid]

The functionality of the trunk will stay the same. So don't worry. The only differences will be in libavcodec, which will have two variants: normal and MT.

[albain]

Albain, have you succeed to download my two examples?

Yes, and I reproduced the problem which is different from the former issue.

However, I am quite busy at work right now so it may take a while until I come back with a fix.

[mark0077]

Hi guys.

Testing the colorspace conversions as I am about to update my dvd quality thread with all of my new findings and suggestions. It seems I have found a bug in ffdshows recent builds.

I am testing using the following clip. I notice in some recent builds of ffdshow and mpc-hc I see nothing when viewing this clip outside of its original DVD.

http://www.mediafire.com/?9g9ddlfzxhv

Here are my results using the mpc-hc mpeg2 decoder (so i can set it to feed out yv12 and yuy2 from my yv12 dvds), version 988, and ffdshow 2671. Only good thing in the new ffdshow versions from my tests weeks ago is the new excellent yv12 - rgb32 conversion. The yv12 to yuy2 conversion is still very bad.

mpc-hc yv12 -> ffdshow yv12-rgb32 -> nvidia rgb32 (VERY GOOD, EXCELLENT WORK GUYS)
mpc-hc yv12 -> ffdshow yv12-yuy2 -> nvidia yuy2-rgb32 (VERY BAD AS ALWAYS)
mpc-hc yuy2 -> ffdshow yuy2-rgb32 -> nvidia rgb32 (CRASH)
mpc-hc yuy2 -> ffdshow yuy2-yv12 -> nvidia yv12-rgb32 (USUALLY EXCELLENT QUALITY BUT NOW CRASH)

[BatKnight]

for the sample : This sample have three soundtracks: one mlp and two lpcm 2.1.
http://www.zshare.net/info.html?54307328-f4cf1e029ba268fd6fc1e3907e3ab1dc

a second example with lpcm 2.1 and lpcm 6.1 soudntrack
http://www.zshare.net/info.html?55241905-3d52058746470a1fa90c6eed8b81c6ea


For spidf, I'm sorry but I can't try because my speakers only offers analogic output and not digital output. I d'ont use HDMI from my grphic card.
I use vga connector from my graphic card (I have CRT monitor) and for sound I use analogic connector from my soundcard (xfi titanium)
Ikarad, i've tested your second sample using Media Player Classic HomeCinema (x86), svn 988 + Beliyaal Fixes Ver 8 http://forum.doom9.org/showpost.php?p=1238556&postcount=5934 and using the internal LPCM filter of MPC-HC it plays ok.
I then succesfully AC3 encoded it and SPDIFed it with AC3 Filter. This allowed me to have proper surround channel mapping from a multichannel LPCM on a digital-only output.

Do you have other problems?

Bat

[ikarad]

Ikarad, i've tested your second sample using Media Player Classic HomeCinema (x86), svn 988 + Beliyaal Fixes Ver 8 http://forum.doom9.org/showpost.php?p=1238556&postcount=5934 and using the internal LPCM filter of MPC-HC it plays ok.
I then succesfully AC3 encoded it and SPDIFed it with AC3 Filter. This allowed me to have proper surround channel mapping from a multichannel LPCM on a digital-only output.

Do you have other problems?

Bat
here is the ffdshow topic and not MPC-HC topic.
Yes, with internal LPCM filter of MPC-HC it works but not with ffdshow audio.
The problem is that FFDSHOW doesn't detects and decode lpcm soundtrack from blu-ray.

[madshi]

Just received information from Microsoft about how to pass TrueHD/DTS-HD to a DirectShow audio renderer in Windows 7. If anybody is interested, please PM me.

[leeperry]

if anyone's interested, I'm doing some betatesting for Christian-W. Budde and his VST>winamp2 bridge plugin :
http://www.savioursofsoul.de/Christian/?page_id=248

the newest beta doesn't freeze/crash anymore on opening new files :eek:

still polishing it a bit(like having no GUI visible when opening a file, etc...), should he rename the DLL or please Haruhiko, can you remove the blacklist on "dsp_vst.dll" ?

anyway, w/ Effect Chainer mixing VST/DX plugins, it's a riot :D

http://www.image-load.eu/out.php/i144947_vst.png

[haruhiko_yamagata]

mpc-hc yv12 -> ffdshow yv12-yuy2 -> nvidia yuy2-rgb32 (VERY BAD AS ALWAYS)
I can't reproduce. Please make sure "Set interlaced flags in output media type" in MPC's MPEG-2 properties is unchecked (or force progressive in ffdshow).

mpc-hc yuy2 -> ffdshow yuy2-rgb32 -> nvidia rgb32 (CRASH)
mpc-hc yuy2 -> ffdshow yuy2-yv12 -> nvidia yv12-rgb32 (USUALLY EXCELLENT QUALITY BUT NOW CRASH)
I can't reproduce. Please try the latest (2672 or newer) if you are using a build of a few days ago.

[bwlonsdale]

Hi all - does someone know if there should be any difference in having FFDShow decode AC3 against passing it through to my AMP and have it do the decoding?

I've noticed that the bass is reduced when I let FFDShow decode the stream.

I'm using an ATI 4600, set for multichannel out (5.1). I've made sure there are no options selected in the sound control panel applet, i.e. no effects or any bass management settings are selected, it shouldn't be doing anything to the audio.

My amp is a Denon 1909. I only noticed this the other day when I was messing with Slysoft's Reclock. I had an issue with it so I uninstalled it and then had FFDShow temporarily pass through the AC3 direct to the amp and then I noticed the bass volume either seemed to be louder or at least it gave more of a thump. It's not my imagination at work, I had someone else check too :)

I have it in my head that there was some issue around bass being 15db quieter when decoded by FFDShow, but that was something I either read in passing or have just made up in my head.

I have FFDShow configured to decode AC3 and the mixer set for 5.1 output, no other options selected for bass management etc. Pretty much everything is at defaults in the audio side of things.

Can anyone confirm or deny I need to be doing anything with bass management if I let FFDShow do the decoding?

This is in Vista Media Center - didn't try anything else yet. I like to let FFDShow do the decoding because then I can use the volume control on the VMC remote rather than reach for another one when I need to turn it down/mute.

[mark0077]

You were right, build 2676 fixed my crashes with colorspace conversion.

The yv12 to yuy2 conversion problem was narrowed down to nvidia doing bad conversion from yuy2 to rgb32....

My suggestions for everyone I guess are always output rgb32hq from ffdshow ;) Thanks alot.

[Brazil2]

This patch will allow the audio decoder to connect to the ArcSoft Demux and decode EAC3 audio tracks. It also defines the wFormatTag as WAVE_FORMAT_DTS_HD instead of WAVE_FORMAT_DTS_W when the media subtype is MEDIASUBTYPE_ARCSOFT_DTSHD.
Aaaah, that would be really great! http://www.lfsforum.net/images/smilies/thumb.gif

[Carpo]

I did search (maybe not that well ;p) but is anyone here getting stuttering video using latest versions of x64 and x86 ffdshow when viewing full screen in vista media center, i have googled for a fix but none seem to work, plays fine in wmp full screen media player classic, well any player for that matter untill i use vista mce and seeing as i use the pc as a HTPC its a bit of a pain in the rear

[clsid]

Update your graphics driver.

[wozio]

My suggestions for everyone I guess are always output rgb32hq from ffdshow ;) Thanks alot.
... or keep colors in nv12 all the way up to renderer which will do conversion to rgb in graphic card.

[Carpo]

Update your graphics driver.

it is the latest 181.22

[Mercury_22]

I have very bad (choppy ?!) video with some AVC files
Can anyone tell me what I'm doing wrong ? (default settings in FFD)
I've tested the same files (same MPC-HC settings too) with other avc filters and even MPC-HC's internal filter (DXVA only) it's better ! :confused: So it's definitely something wrong with FFD or my settings :confused:
:helpful:


Sample (http://rapidshare.com/files/197184924/TestAVC.m2ts.html)

[clsid]

it is the latest 181.22
I am pretty sure there are newer drivers than that.
A workaround that you could try is this:
Set Edge enhancements and Noise reduction to 20% in the NVIDIA control panel.

This problem is not caused by ffdshow.

[Carpo]

if you mean beta drivers i guess there is, but im usin latest whql ones, i have seen that fix advised before, i'll give it a try

[mark0077]

... or keep colors in nv12 all the way up to renderer which will do conversion to rgb in graphic card.

Actually no, on both of my nvidia cards, 7600GT and GTX295, nvidias nv12 to rgb32 conversion is HORRIBLE. yv12 to rgb32 conversion is perfect. I am updating my dvd quality thread at the moment and my findings on nv12 stand, it doesn't always provide the best quality colors, need more nvidia users to confirm this as an nvidia issue.

[rt87]

just found that when using ffdshow to decode sowt audio, it reduces playback speed alot.

[Snowknight26]

With r2671, when I have a 24-bit FLAC source connected to ffdshow via madFLAC, ffdshow seems to output '32-bit integer.' Is it upsampling the audio, zeroing the extra 8 bits, or what? Shouldn't it only output '24-bit integer,' assuming I have 16, 24, 32-bit and 32-bit floating point all checked in the Output?

Also, for consistency's sake, shouldn't there be a '-' between ## and bit under Output considering there is one on the tool tip when Extended info is checked?

[haruhiko_yamagata]

I have very bad (choppy ?!) video with some AVC files
Can anyone tell me what I'm doing wrong ? (default settings in FFD)
I've tested the same files (same MPC-HC settings too) with other avc filters and even MPC-HC's internal filter (DXVA only) it's better ! :confused: So it's definitely something wrong with FFD or my settings :confused:
:helpful:


Sample (http://rapidshare.com/files/197184924/TestAVC.m2ts.html)
It's just performance problem.
ffmpeg-mt + yadif(single) + RGBhq is OK on my Core2 Quad 6600.
libavcodec (normal) + YV12 is not OK.
To enjoy yadif in double frame rate, we need better CPU.

[albain]

This patch will allow the audio decoder to connect to the ArcSoft Demux and decode EAC3 audio tracks. It also defines the wFormatTag as WAVE_FORMAT_DTS_HD instead of WAVE_FORMAT_DTS_W when the media subtype is MEDIASUBTYPE_ARCSOFT_DTSHD.

Index: src/ffdshow_mediaguids.h
===================================================================
--- src/ffdshow_mediaguids.h (revision 2672)
+++ src/ffdshow_mediaguids.h (working copy)
@@ -394,6 +394,7 @@

DEFINE_GUID(MEDIASUBTYPE_NERO_MLP ,0x1e889be7, 0xb276, 0x4064, 0x9a, 0x39, 0x16, 0x0a, 0x06, 0x89, 0x5b, 0x52);
DEFINE_GUID(MEDIASUBTYPE_ARCSOFT_MLP ,0x4288b843, 0x610b, 0x4e15, 0xa5, 0x3b, 0x43, 0x00, 0x7f, 0xcf, 0xf6, 0x14);
+DEFINE_GUID(MEDIASUBTYPE_ARCSOFT_DDPLUS ,0x71cfa727, 0x37e4, 0x404a, 0xae, 0xc0, 0x34, 0x84, 0x25, 0x32, 0xef, 0xf7);
DEFINE_GUID(MEDIASUBTYPE_SONIC_MLP ,0x4094a857, 0x7891, 0x44ac, 0x92, 0xb5, 0xc1, 0xcf, 0xf3, 0x7a, 0xf2, 0xe7);
DEFINE_GUID(MEDIASUBTYPE_ARCSOFT_DTSHD ,0xf6498f57, 0xb399, 0x4a43, 0xa6, 0xfa, 0xf6, 0x94, 0xad, 0x42, 0xb9, 0xbe);
DEFINE_GUID(MEDIASUBTYPE_DOLBY_DDPLUS ,0xa7fb87af, 0x2d02, 0x42fb, 0xa4, 0xd4, 0x5, 0xcd, 0x93, 0x84, 0x3b, 0xdd);
Index: src/TffDecoder_reg.cpp
===================================================================
--- src/TffDecoder_reg.cpp (revision 2672)
+++ src/TffDecoder_reg.cpp (working copy)
@@ -435,6 +435,7 @@
{ &MEDIATYPE_Audio , &MEDIASUBTYPE_Vorbis2 },
{ &MEDIATYPE_Audio , &MEDIASUBTYPE_VorbisIll },
{ &MEDIATYPE_Audio , &MEDIASUBTYPE_ARCSOFT_MLP },
+ { &MEDIATYPE_Audio , &MEDIASUBTYPE_ARCSOFT_DDPLUS },
{ &MEDIATYPE_Audio , &MEDIASUBTYPE_ARCSOFT_DTSHD },
//{ &MEDIATYPE_Audio , &MEDIASUBTYPE_EAC3 },
{ &MEDIATYPE_Audio , &MEDIASUBTYPE_PCM },
Index: src/TffdshowDecAudio.cpp
===================================================================
--- src/TffdshowDecAudio.cpp (revision 2672)
+++ src/TffdshowDecAudio.cpp (working copy)
@@ -212,7 +212,7 @@
wFormatTag=WAVE_FORMAT_VORBIS;
else if (mt.subtype==MEDIASUBTYPE_DOLBY_AC3)
wFormatTag=WAVE_FORMAT_AC3_W;
- else if (mt.subtype==MEDIASUBTYPE_DTS || mt.subtype==MEDIASUBTYPE_ARCSOFT_DTSHD)
+ else if (mt.subtype==MEDIASUBTYPE_DTS)
wFormatTag=WAVE_FORMAT_DTS_W;
else if (mt.subtype==MEDIASUBTYPE_DVD_LPCM_AUDIO)
wFormatTag=WAVE_FORMAT_LPCM;
@@ -233,9 +233,9 @@
else if (mt.subtype==MEDIASUBTYPE_DOLBY_TRUEHD || mt.subtype==MEDIASUBTYPE_NERO_MLP
|| mt.subtype==MEDIASUBTYPE_ARCSOFT_MLP || mt.subtype==MEDIASUBTYPE_SONIC_MLP)
wFormatTag=WAVE_FORMAT_MLP;
- else if (mt.subtype==MEDIASUBTYPE_DOLBY_DDPLUS)
+ else if (mt.subtype==MEDIASUBTYPE_DOLBY_DDPLUS || mt.subtype==MEDIASUBTYPE_ARCSOFT_DDPLUS)
wFormatTag=WAVE_FORMAT_EAC3;
- else if (mt.subtype==MEDIASUBTYPE_DTS_HD)
+ else if (mt.subtype==MEDIASUBTYPE_DTS_HD || mt.subtype==MEDIASUBTYPE_ARCSOFT_DTSHD)
wFormatTag=WAVE_FORMAT_DTS_HD; // TODO : define a separate codecId for DTSHD when available
else
{


Thank you for your patch. I am testing it and working on bugfixes on this part.

[Mercury_22]

It's just performance problem.
ffmpeg-mt + yadif(single) + RGBhq is OK on my Core2 Quad 6600.
libavcodec (normal) + YV12 is not OK.
To enjoy yadif in double frame rate, we need better CPU.

So MPC-HD's internal DXVA AVC it's more performant (with my 4670) than FFD's AVC (+ my E8400 )?! :confused: That's strange I've alway thought that MPC's AVC it's slower than FFD !
Anyway :thanks:

P.S. any news about ffmpeg-mt 64-bit ?

[mark0077]

Now that I see colorspace conversion is looking excellent... I would love to build up a list of benchmarks for improving interlaced vs progressive frames... which has been a plague to dvd quality playback for im sure all of us, certainly me and my friends. Before I go about trying to come up with a list of tests.... I am just wondering does anyone know if I can use hardware deinterlacing as a step before ffdshow... like the following

ffdshow libavcodec mpeg2 decoder -> output in original colorspace with interlace flag -> deinterlaced by hardware -> back to ffdshow for colorspace conversion and other stuff -> output to renderer

Is this possible? I am watching alot of material the last few days and I can say there is that little improvement in deinterlacing when using hardware over yadif... I am just greedy and want the best of both worlds ;) Do you think this could be possible?

[Leak]

Do you think this could be possible?
Sorry, but I don't think so.

Hardware deinterlacing happens in the video renderer when the image is on the graphics card already; but there's no way to read it back in a graph, filter it then send it to the renderer again - same problem as with DXVA decoded video.

It should, however, be possible to do proper colorspace conversion with the interlaced image before handing it to the renderer, but I'm not sure whether hardware deinterlacing works with/is applied to RGB images - I rather doubt it...

np: Yage - He Laughed Himself To The Centre (The Woodlands Of Old)

[mark0077]

Thanks Leak. Yeah it seems hardware deinterlacing is dependent upon the colorspace its given, at least on my nvidia cards. Oh well.... trying to familiarize myself with the following dvd player benchmarks http://www.hometheaterhifi.com/volume_10_1/dvd-benchmark-guide-to-progressive-scan-shootout-1-2003.html to see how we could come up with software tests..

Its really the only annoying thing in my setup at the moment, having to manually enable or disable deinterlacing for dvd's. Interesting stuff.... I would love to see ffdshow on that site as no1 for ... well all of the benchmarks they come up with :D:D Its probably completely a libavcodec and libmpeg2 thing.. with the correctly set flags being sent to ffdshow maybe.

[albain]

Hi,

I think I have fixed the bugs remaining on HD audio formats :

MLP/Dolby True HD sound garbled with heavy jiter
LPCM tracks from blurays : sound was garbled


Fixed in revision 2682.
Please report if there are still issues.

Regards,

Damien BT

[ikarad]

Hi,

I think I have fixed the bugs remaining on HD audio formats :

MLP/Dolby True HD sound garbled with heavy jiter
LPCM tracks from blurays : sound was garbled


Fixed in revision 2682.
Please report if there are still issues.

Regards,

Damien BT
where can we download this version? Because here
https://sourceforge.net/project/showfiles.php?group_id=173941
the last version is 2676

and www.xvidvideo.ru doesn't work

[albain]

where can we download this version? Because here
https://sourceforge.net/project/showfiles.php?group_id=173941
the last version is 2676

and www.xvidvideo.ru doesn't work

I am currently building one. Please wait for a while...

[ikarad]

I am currently building one. Please wait for a while...

thanks

[clsid]

New build is online.

[Brazil2]

New build is online.
Does this build include Whurlston's patch (http://forum.doom9.org/showthread.php?p=1247644#post1247644) ?

And if so, is there any chance for an ICL10 build ? Please :)

[clsid]

The patch was committed to SVN, so yes it is included.

I don't have time right now for an ICL build. Those are available when they are availabe.

[Atak_Snajpera]

P.S. any news about ffmpeg-mt 64-bit ?
or just -mt 32bit?

[ikarad]

Hi,

I think I have fixed the bugs remaining on HD audio formats :

MLP/Dolby True HD sound garbled with heavy jiter
LPCM tracks from blurays : sound was garbled


Fixed in revision 2682.
Please report if there are still issues.

Regards,

Damien BT
thanks,
MLP seems to work well with my blu-rays.
But with LPCM there is still problems.
1) If in audio menu of MPC-HC, MLP is the first selected ffdshow is loaded
http://nsa05.casimages.com/img/2009/02/14/mini_090214061811672392.jpg (http://www.casimages.com/img.php?i=090214061811672392.jpg)

and I can select select LPCM soudntrack.
http://nsa05.casimages.com/img/2009/02/14/mini_090214062001829470.jpg (http://www.casimages.com/img.php?i=090214062001829470.jpg)


Now, if in audio menu of MPC-HC there is no MLP soundtrack, FFSDHOW isn't loaded even if LPCM decoder isn't selected in MPC-HC. Although LPCM is selected in codec from ffdshow audio
http://nsa05.casimages.com/img/2009/02/14/mini_090214062154461511.jpg (http://www.casimages.com/img.php?i=090214062154461511.jpg)
http://nsa05.casimages.com/img/2009/02/14/mini_090214062234286479.jpg (http://www.casimages.com/img.php?i=090214062234286479.jpg)
http://nsa05.casimages.com/img/2009/02/14/mini_090214062322248103.jpg (http://www.casimages.com/img.php?i=090214062322248103.jpg)

2) With MLP soundtrack
the current input bitrate line works well
http://nsa05.casimages.com/img/2009/02/14/mini_090214062548411407.jpg (http://www.casimages.com/img.php?i=090214062548411407.jpg)

But with LPCM soudntrack this line is always 0.
http://nsa05.casimages.com/img/2009/02/14/mini_090214062709130792.jpg (http://www.casimages.com/img.php?i=090214062709130792.jpg)


the example with only lpcm tracks
example with lpcm 2.1 and lpcm 6.1 soundtrack
http://www.zshare.net/info.html?55241905-3d52058746470a1fa90c6eed8b81c6ea

bugtracker
https://sourceforge.net/tracker2/?func=detail&aid=2600248&group_id=173941&atid=867360

[Leak]

or just -mt 32bit?
It's been merged into the trunk - just download clsid's rev. 2684 build and choose "ffmpeg-mt" as the H.264 codec...

np: Humanoid - 3AM And Feeling OK (King Roc Mix) (Your Body Robotic (Disc 1))

[fofwp]

I am trying to get TrueHD decoding to work with ffdshow. The movie is Tropic Thunder, and I created the m2ts file using Ts4Np v0.8.2.0. I had Bypass audio alignment and Use async I/O unchecked.

When I try to play the file back in MPC-HC, no audio is decoded. I have set ffdshow as preferred in external filters, and have set all stable formats to libavcodec. I am using Haali Media Splitter. Is there something I am doing wrong?

[clsid]

Try with the internal MPEG splitter of MPC-HC. I don't think Haali Media Splitter recognizes TrueHD yet.

[albain]

thanks,
MLP seems to work well with my blu-rays.
But with LPCM there is still problems.
1) If in audio menu of MPC-HC, MLP is the first selected ffdshow is loaded
and I can select select LPCM soudntrack.
Now, if in audio menu of MPC-HC there is no MLP soundtrack, FFSDHOW isn't loaded even if LPCM decoder isn't selected in MPC-HC. Although LPCM is selected in codec from ffdshow audio
2) With MLP soundtrack
the current input bitrate line works well

But with LPCM soudntrack this line is always 0.
the example with only lpcm tracks
example with lpcm 2.1 and lpcm 6.1 soundtrack

Ok, I will check after these. I had noticed the 1st problem (FFDShow not loaded for LPCM) and I had to force the submediatype in MPC-HC so that it would load it.
I didn't realized that this was a ffdshow bug too.

Concerning ICL10, my build is also posted and they all are built with ICL 10.1


*EDIT* : problem #1 is fixed in revision 2686. Problem #2 is minor, I will look after it when I will have time

[albain]

I posted an updated build (this is not a race I know) : build 2686 including LPCM fix (I hope)

Regards,

Damien BT

[fofwp]

Try with the internal MPEG splitter of MPC-HC. I don't think Haali Media Splitter recognizes TrueHD yet.

Yep that did the trick. Thanks.

[Snowknight26]

ffdshow's grab function takes screenshots with bad colors:
http://www.stfcc.org/misc/ffdshow.r2686.png
http://www.stfcc.org/misc/mpc-hc.r990.png

The filter chain was something like Haali Media Splitter -> ffdshow (decoding H.264) -> ffdshow (decoding YV12 - took screenshot) -> Renderer (in MPC-HC).

[chros]

It's been merged into the trunk - just download clsid's rev. 2684 build and choose "ffmpeg-mt" as the H.264 codec...

Woow !!!
But, is it possible that I can't select it in the config panel???
I selected during install, but in the config it shows an empty value, and at the info page it displays: libavcodec h.264 ...

[ikarad]

I posted an updated build (this is not a race I know) : build 2686 including LPCM fix (I hope)

Regards,

Damien BT

Yes it works.
Thank you very much.

[Atak_Snajpera]

I selected during install, but in the config it shows an empty value, and at the info page it displays: libavcodec h.264 ...
I have no problems.

[whurlston]

Thank you for your patch. I am testing it and working on bugfixes on this part.No problem. Thanks for all the hard work on HD audio in general. I was just doing the easy part. I'm new to the whole patching thing and C++ is not one of my strengths so please excuse any newbie errors.

[haruhiko_yamagata]

Woow !!!
But, is it possible that I can't select it in the config panel???
I selected during install, but in the config it shows an empty value, and at the info page it displays: libavcodec h.264 ...
Can you find pthreadGC2.dll in your system32 directory?

[chros]

Can you find pthreadGC2.dll in your system32 directory?
and @ Atak_Snajpera: thanks, I just needed a reboot ... :(

[Jeremy Duncan]

I have a bug report for the developers.

This is the script that causes the player to crash:
________ advanced ffdshow: framerate doubler. For ntsc(60hz) and pal(50hz) monitors. ________ (http://forum.doom9.org/showthread.php?t=115727)
Click link and look for configuration.
All the plugins and sw used is in that thread.
I use media player classic from that thread.
This is on xp pro media center edition, all updated.
A Ati 2600 pcie video card.
A e6600 cpu, not overclocked.
I'm using the dvi/hdmi dongle from the video card and hdmi to the 60hz lcd tv.

I have tried these steps to find the problem:
Different output colorspaces.
Specifying yv12 input colorspace.
Different avisynth configurations.
Not using the queue output samples.
Different rgb conversion tab settings.
Using the newest zoomplayer pro.
Trying the latest avisynth with no mt, and setting the avisynth script to use no mt.
I tried not using the ffdshow mpeg2 decoder and different ffdshow mpeg2 decoder.

I found the last ffdshow version that this configuration can be played on is the "2653" version by clsid.
At 2661 and anything higher the movie crashes at the warning screen.
I tried albains latest one too and that also crashed.

This player does not always cash, ot pnly crashed on one movie out of the three I tried.
Linked to in the link I gave, it did not crash on the progressive TEST DISK (ntsc), or the nsc sddvd Ghost in the Shell Anime.
It does crash on the movie "The Transporter 2" every time.
That anime does not have a root menu and it does not have a warning screen I think, just pop it and the the movie starts after the owners banner.

So I think this has something to do with the warning screen, since the movies that did not crash did not have a warning screen.

I will list the svn updates that may have caused the problem:
Revision 2661 - Directory Listing
Modified Sat Feb 7 14:44:18 2009 UTC (7 days, 22 hours ago) by clsid2

Updated FFmpeg

Revision 2660 - Directory Listing
Modified Sat Feb 7 08:55:27 2009 UTC (8 days, 4 hours ago) by h_yamagata

Use MSVC's STL instead of uClibc++.

Revision 2659 - Directory Listing
Modified Sat Feb 7 08:36:59 2009 UTC (8 days, 4 hours ago) by h_yamagata

ffdshow color space converters: separate some files

Revision 2658 - Directory Listing
Modified Sat Feb 7 07:37:36 2009 UTC (8 days, 5 hours ago) by h_yamagata

Optimize ffdshow color space converters: 6% faster (RGB32)

Revision 2657 - Directory Listing
Modified Fri Feb 6 17:27:33 2009 UTC (8 days, 20 hours ago) by clsid2

Updated FFmpeg

Revision 2656 - Directory Listing
Modified Fri Feb 6 14:24:22 2009 UTC (8 days, 23 hours ago) by h_yamagata

The new ffdshow color space converters:
Improve API and documentation

Revision 2655 - Directory Listing
Modified Fri Feb 6 10:52:25 2009 UTC (9 days, 2 hours ago) by h_yamagata

YCbCr specification: Auto:
width > 1024 or height >=600: BT.709
width <=1024 and height < 600: BT.601

Revision 2654 - Directory Listing
Modified Wed Feb 4 17:50:47 2009 UTC (10 days, 19 hours ago) by clsid2

Removed VS2003 project files


If you want to make this simple. Just make ffdshow version of each update I listed and I will try each one out and tell you when ffdshow begins to crash.

Edit.
I think update 2660 caused the problem.
Maybe make a 2659 version and I will tell you if that's the case. :)

[Steveo08]

mayby some one can help me, to fix my problem with ffdshow output. i want to use the colorspace "YV12", but i can't, because if i select "YV12" i always get an error message with mpc:

"MPC could not render some of the pins in the graph...etc."

i reinstall ffdshow for a few times, but it doesn't work.

[clsid]

Some renderers (like Haali) do not support YV12 input.

[Steveo08]

Some renderers (like Haali) do not support YV12 input.



thank you, because i am using haali video renderer, that would explain why it won't work! :-)

[iron2000]

I can't play DVDs.
Tried loading with MPCHC but as soon as it loads, an error dialog pops up and on clicking for more information, ffdshow.ax is shown:

AppName: mplayerc.exe AppVer: 1.2.986.0 ModName: ffdshow.ax
ModVer: 1.0.5.2471 Offset: 00201d3b

Does anybody have a clue to this problem?

[tal.aloni]

ffdshow's grab function takes screenshots with bad colors:
http://www.stfcc.org/misc/ffdshow.r2686.png
http://www.stfcc.org/misc/mpc-hc.r990.png

The filter chain was something like Haali Media Splitter -> ffdshow (decoding H.264) -> ffdshow (decoding YV12 - took screenshot) -> Renderer (in MPC-HC).

Snowknight26,
1. which revision?
2. do you have "High quality yv12 to rgb conversion" turned on?

I can't recreate this with rev. 2644, I'll test later revisions at the weekend (during encode at the moment)

Tal

[Leak]

I can't play DVDs.
Tried loading with MPCHC but as soon as it loads, an error dialog pops up and on clicking for more information, ffdshow.ax is shown:

AppName: mplayerc.exe AppVer: 1.2.986.0 ModName: ffdshow.ax
ModVer: 1.0.5.2471 Offset: 00201d3b

Does anybody have a clue to this problem?
Does it still crash if you don't use ffdshow's audio decoder, i.e. if you enable MPC-HC's internal audio decoders?

Because if it doesn't I've just fixed that crash in rev. 2691... :)

np: Distance - Radical (Chestplate)

[Snowknight26]

Snowknight26,
1. which revision?
2. do you have "High quality yv12 to rgb conversion" turned on?

It's in the file name. :P r2686.
Yes, High quality YV12 to RGB was checked.

I also have word that someone else is having this problem too (HQ YV12 -> RGB is on as well).

[Jeremy Duncan]

Does it still crash if you don't use ffdshow's audio decoder, i.e. if you enable MPC-HC's internal audio decoders?

Because if it doesn't I've just fixed that crash in rev. 2691... :)

np: Distance - Radical (Chestplate)

Was the update you made, 2691, made to the mpeg2 codec "libmpeg2"?

I ask because when the ffdshow developers update that codec again I know what to ask to be fixed. :)

[Leak]

Was the update you made, 2691, made to the mpeg2 codec "libmpeg2"?
No (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2691) - it was an update to the audio decoder.

np: Distance - Present Day (Chestplate)

[iron2000]

Does it still crash if you don't use ffdshow's audio decoder, i.e. if you enable MPC-HC's internal audio decoders?

Because if it doesn't I've just fixed that crash in rev. 2691... :)

np: Distance - Radical (Chestplate)

!!
I works!
With MPC-HC's internal audio decoder the DVD plays.

:thanks:

[Jeremy Duncan]

The bug I wrote about in post 6637 was the audio bug Leak fixed.

When I disable ffdshow audio in mpc the problem goes away.
It is puzzling though, since the svn changelog does not mention ffdshow audio in the updates 2654 to 2661, and it was in one of those updates the audio bug I wrote about appeared. :)

Edit.

When can we expect a new build from clsid or Albain or xxl?

[Leak]

It is puzzling though, since the svn changelog does not mention ffdshow audio in the updates 2654 to 2661, and it was in one of those updates the audio bug I wrote about appeared. :)
It probably was 2660 - it was an assertion triggered by trying to reference the first byte of a buffer of size zero via an iterator, and while uClibc++ didn't check this MS's library does...

Simply skipping that part of the code if the size is zero does the trick without any ill effects.

[clsid]

I have added an updated MinGW32 installer to first post.

[tal.aloni]

It's in the file name. :P r2686.
Yes, High quality YV12 to RGB was checked.

Snowknight26,
I have tested ffdshow_rev2686_20090214_dbt.exe, and also tested rev. 2693 (xvidvideo.ru), both generic & icl10 and could not recreate this. (AFAIK, there are two color conversion functions, one for CPUs with mmx, the other for CPUs without)

1. are you sure the input is YV12? (some decoders output YUY2)

2. please make sure there's no more than one ffdshow instance in the graph. (DirectShow Control)

3. please try to provide more information on the build you're using, and when does it happen / not happen, or which is the first version that triggers it.

Tal

[Snowknight26]

I was using ffdshow_rev2686_20090214_dbt.exe and r2671, forget which build. Both showed the issue.

1. Yes, because when I look at the second instance of ffdshow, the input is YV12. The first instance of ffdshow is outputting "YV12,adj."
2. The issue only seems to happen when there are two instances though, and only when taking screenshots with the one thats decoding the YV12.
3. Seems to happen every time there are two instances with whatever -> YV12 -> renderer. I'll try to find out which revision is the first one that shows the issue.

Edit: Switching to YUV2/RGB32 output in the first instance makes the issue disappear.
Just tried r2643 and it was fine. r2649 showed the problem again, so I'm guessing it was r2646.

[mark0077]

Guys, did something go wrong in some of these latest builds as now using ffdshow yv12 to rgbhq looks like the older versions... aka really bad.

Using build 2693 and tried both ffdshow and mpc-hc's mpeg2 decoder. Outputting yv12 fixes the problem... so its definitely the internal yv12 to rgbhq conversion. I have high quality conversion turned on. I will try and track down which build this started in.

[mark0077]

Guys, did something go wrong in some of these latest builds as now using ffdshow yv12 to rgbhq looks like the older versions... aka really bad.

Using build 2693 and tried both ffdshow and mpc-hc's mpeg2 decoder. Outputting yv12 fixes the problem... so its definitely the internal yv12 to rgbhq conversion. I have high quality conversion turned on. I will try and see what build this started in.

EDIT: Thats weird, restarting mpc a few times and the quality is back to perfect.... can't understand that...

[iron2000]

Is ffdshow dropping support for DScaler?

Tested and DVD plays alright on 2693 :)

[Jeremy Duncan]

All is well with the new ffdshow release clsid made today (2693).
The rgb conversion is good quality, and the audio is fine, and the root menu is ok too.
If nothing else is done to ffdshow then right now it looks ok to me. But keep up the good work as you see fit. :)

[cca]

Will there ever be a way for the user to prioritize the which colorspace to output? In ffdhsow-mt when I had all colorspaces checked I was getting NV12 as output, which is the best for my ATi card. In the recent ffdhsow builds after -mt merged into the main branch, it always outputs YUY2 unless I disable everything else! Disabling colospaces is a bad idea though, I prefer to have a priority order.

[THX-UltraII]

I just made a switch on my HTPC and skipped AC3Filter and going to use the ffdshow Audio Decoder for my audio signal.

I ll first tell you guys my setup and what I want:
I have a HTPC with three different types of media that I play: .mkv, .wmv and VIDEO_TS folders (standard def. dvd). I own the ATI HD4350 and managed to get sound over HDMI work. This way I can PCM passthrough the audio to my receiver. I also use ReClock and selected the internal AC3 encoder box in the ReClock properties.

So I ve installed ffdshow (the MMX version, this was the latest one. Dont know which version to use for best results, I have a intel quad-core processor, So first question id which version to use for my setup) and choose ONLY the audio decoder to install (I use other decoders for my video).

1.
codecs
I see that here I can disable and enable decoding for different formats. I think I ll have to select eg. AC3 here (my VIDEO_TS material contains an AC3 signal), but I see two option to decode: Liba52 and Libavcodec. Which one should I choose here? Am I correct when I say that when picking one of the two here decodes the AC3 signal and sends it as PCM to ReClock?

2.
mixer
Don t know if I have to set it on ENABLED and SAME AS INPUT or on DISABLED.

3.
output
- pass-through AC3/DTS: I think I don t have to check this one in my setup correct?
- Supported output sample formats: check 16,24 and 32 bit correct?
- Dont check AC3 encode (this is done by ReClock correct?) and LPCM correct?
- Connect to any filter; leave it like that?
- Allow direct-to-file output, check or uncheck?

that s it for now. Sorry for the bad English.

[haruhiko_yamagata]

EDIT: Thats weird, restarting mpc a few times and the quality is back to perfect.... can't understand that...I guess you had wrong settings about MPEG-2 interlacing flag in MPC.
MPC's settings about MPEG-2 decoder aren't saved if they are changed during playback. You have to launch MPC, change the settings and quit.

[haruhiko_yamagata]

Is ffdshow dropping support for DScaler?

Tested and DVD plays alright on 2693 :)
It works for me. Please make sure you have installed DScaler plugins on installation of ffdshow. Also make sure you have working installation of DScaler.

[haruhiko_yamagata]

Will there ever be a way for the user to prioritize the which colorspace to output? In ffdhsow-mt when I had all colorspaces checked I was getting NV12 as output, which is the best for my ATi card. In the recent ffdhsow builds after -mt merged into the main branch, it always outputs YUY2 unless I disable everything else! Disabling colospaces is a bad idea though, I prefer to have a priority order.I would love to, just don't have enough time to do that.

[Jeremy Duncan]

ffdshow audio osd.

I can see the output integer, but I cannot see the input integer selected if I choose "All integer" from the uncompressed tab.

As I understand it. Ideally I would have 16 bit integer from the codecs tab, uncompressed tab.
And in the output tab I select 16 bit integer.
There is less, "Dither".

"Silence only results if the subtraction is of identical data. Staying withing the 16 bit realm, from beginning to end, will produce silence, working with 24 bit data, without converting to 16 bit, will produce silence. Not only the part that started as silence, but also the part of the file that has a signal can be zeroed out completely if all operations stay within the bounds of 16 bit, or 24 bit, where ever we are operating."

"The result is not silence because the “dither” subtracted is not the same data."

link (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=49843&view=findpost&p=615158)

If the input integer in uncompressed is the same as the output integer, then the dither will be the same and theoretially the sound should be good.

But I select All integer in the uncompressed tab, so want to be able to know which integer is being selected? :)

[STaRGaZeR]

I've been testing the now merged ffmpeg-mt and all I can say is that it works way better than when it was a different branch. No crashes whatsoever. The garbled frames issue when seeking is vastly reduced, I've only found it in some samples. There are no rainbows but instead there is a bit of blockiness and other frames rests:

http://thumbnails7.imagebam.com/2705/11619e27046860.gif (http://www.imagebam.com/image/11619e27046860)

As you can see the garbage is part of a previous frame. Found this in Blu-ray's with 4 ref frames and with MBAFF streams. Also it seems to be random, I can't reproduce the same blockiness when seeking to a concrete frame twice. Everything else is perfect in ffmpeg-mt as far as I've tested.

On a side note, I've been playing with clsid's and xvidvideo.ru's x64 builds and I found something interesting. With clsid's builds the Resize filter is slow as hell compared to the 32-bit version, while in xvidvideo.ru's builds isn't. In fact it's faster than 32-bit. But in clsid's libavcodec MP3 decoder works and with mp3lib the sound is garbled, in xvidvideo's libav MP3 and mp3lib both don't work.

[shaolin95]

Guys a quick Q.
My X-Fi Prelude max output seems to be 24bit so should I select output 24bit in ffdshow audio instead of 32bit float?
Thanks

[Jeremy Duncan]

Guys a quick Q.
My X-Fi Prelude max output seems to be 24bit so should I select output 24bit in ffdshow audio instead of 32bit float?
Thanks

If the material is 24 bit then you would be best to choose 24 bit integer in the codecs uncompressed tab, and 24 bit in the output tab.

But 16 bit is a standard that the audio industry uses, I gather or I understand by gleaming the audio thread I linked too
(last 2 pages.).
So it's easy to think movies use 16 bit integer as a standard too, rather than 24 bit which even audio professionals argue over it's value when compared to 16 bit integer.

Also, if you choose the wrong value for the integer the result is dithering which brings bad audio result.
if the material is 16 bit integer then just because your sound card does 24 bit integer and you use 24 bit integer output this does not mean the result would be better than if you used 16 bit integer.

The idea is to get the integers to match so the Dithering doesn't ruin the sound.
If the integer values are mismatched then there will be uneven dithering matching resulting in poor audio quality.

They use 16 bit integer for dvd's I'm guessing. :)

[shaolin95]

Im only using Bluray rips and lately isntead of ripping to mkv I am just ripping the full mt2s file.
That means that most of the time 16bit would be the one to choose according to your information then.
Also based on your info then having that 32bit float option serves no real purpose. Right?
Thanks for the reply btw. :-)

[Jeremy Duncan]

Im only using Bluray rips and lately isntead of ripping to mkv I am just ripping the full mt2s file.
That means that most of the time 16bit would be the one to choose according to your information then.
- I think so.

Also based on your info then having that 32bit float option serves no real purpose. Right?
- I think so. After reading a few threads on this it's really between 16 and 24 bit integer, not float.

Thanks for the reply btw. :-)

Having set my audio to 16 bit integer I find the sound to be better in sddvd movies. That tells me the movie uses 16 bit integer.

[Dark Shikari]

Having set my audio to 16 bit integer I find the sound to be better in sddvd movies. That tells me the movie uses 16 bit integer.Most audio formats rely on floating point encoding internally regardless of the "actual" input bit depth. That is, they decode to 32-bit float, too. Outputting to 16-bit integer after that requires extra processing to downsample the resulting values.

[Jeremy Duncan]

Most audio formats rely on floating point encoding internally regardless of the "actual" input bit depth. That is, they decode to 32-bit float, too. Outputting to 16-bit integer after that requires extra processing to downsample the resulting values.

Yes, I read that integers use more cpu. But that's not what were talking about. Were talking about dithering and how to get the best result.

I think your saying using a output of 16 bit integer is not as good as using 32 float?
But that statement is based on the uncompressed in Codecs using 32 float?

Edit.
I just did a basic test and the speed is roughly the same is I choose 16 bit integer for uncompressed and output, or if I choose 32 bit float in uncompressed and output.

- The correct one would be to use 32 bit float in the codec uncompressed tab and in the output tab?

Edit,
I discovered that if I use 32 bit float in the codecs uncompressed tab and the ffdshow audio output tab I can open and use wmp to play mp3 again! :D

It now works regardless if I use spdif or analog, ffdshow audio doesn't get used and wmp opens as a result!

So I will use float 32 unless somebody gives a pretty good reason not too. :)

[THX-UltraII]

I just made a switch on my HTPC and skipped AC3Filter and going to use the ffdshow Audio Decoder for my audio signal.

I ll first tell you guys my setup and what I want:
I have a HTPC with three different types of media that I play: .mkv, .wmv and VIDEO_TS folders (standard def. dvd). I own the ATI HD4350 and managed to get sound over HDMI work. This way I can PCM passthrough the audio to my receiver. I also use ReClock and selected the internal AC3 encoder box in the ReClock properties.

So I ve installed ffdshow (the MMX version, this was the latest one. Dont know which version to use for best results, I have a intel quad-core processor, So first question id which version to use for my setup) and choose ONLY the audio decoder to install (I use other decoders for my video).

1.
codecs
I see that here I can disable and enable decoding for different formats. I think I ll have to select eg. AC3 here (my VIDEO_TS material contains an AC3 signal), but I see two option to decode: Liba52 and Libavcodec. Which one should I choose here? Am I correct when I say that when picking one of the two here decodes the AC3 signal and sends it as PCM to ReClock?

2.
mixer
Don t know if I have to set it on ENABLED and SAME AS INPUT or on DISABLED.

3.
output
- pass-through AC3/DTS: I think I don t have to check this one in my setup correct?
- Supported output sample formats: check 16,24 and 32 bit correct?
- Dont check AC3 encode (this is done by ReClock correct?) and LPCM correct?
- Connect to any filter; leave it like that?
- Allow direct-to-file output, check or uncheck?

that s it for now. Sorry for the bad English.

[Leak]

Please stop re- and crossposting the same post over and over again - it's against the forum's rules.

You won't get more of an answer if you do that, you'll just manage to get on people's nerves.

And before you ask - no, I can't answer this as I never used SPDIF and/or HDMI and just have 2 speakers hooked up to my PC...

[leeperry]

So it's easy to think movies use 16 bit integer as a standard too, rather than 24 bit which even audio professionals argue over it's value when compared to 16 bit integer.
AC3 & DTS are lossy, but if properly encoded they "can" reach between 18 and 20bit(and 24 for "DTS 96/24" obviously) :
http://www.google.com/search?hl=en&newwindow=1&safe=off&q=ac3+dts+20+bit&lr=

I also output 32 float so both Ozone4(through a VST>winamp2 wrapper) and Reclock work in the highest possible resolution(Reclock will convert to this anyway as this is its internal working res)...hell I even send 32 float to my audio drivers(24/96 M-Audio Audiophile USB) :D

each integer/float conversion is theoritically highly lossy, so refrain from doing them....and just for the record Ozone4 internally works in 64bit float :o

[ikarad]

I see a bug with ffdshow-mT.
In some blu-ray there is some bugs of decompression (or decoding)

screenshot here
http://nsa05.casimages.com/img/2009/02/18/mini_090218114945228794.jpg (http://www.casimages.com/img.php?i=090218114945228794.jpg)

sample here
http://www.zshare.net/info.html?55808118-1186c8d37659ccdc7c113ea973577df5

video captured by fraps to show this bug
http://www.zshare.net/info.html?55808947-2327e7dd24f9e7c0fc51bbeac433d69b

bugs appear between 1min40 and 1min45

- With ffdshow not MT, there isn't this bug.
- With H264 codec of MPC-HC there isn't this bug.
- If in ffdshow-Mt, I select 1 in the number of decoding threads (only 1 core used) there is no bug. If I select 2,3 or 4 there is the bug
http://nsa05.casimages.com/img/2009/02/18/mini_090218120751123616.jpg (http://www.casimages.com/img.php?i=090218120751123616.jpg)

I notice that this bug appear only with blu-rays at 29.970 fps but I am not very sure because I don't have many blu-rays to test (with blu-rays at 24fps, I have never seen this bug)

My config:
Q6600 (quad core), gtx280, xp sp3

[haruhiko_yamagata]

I've been testing the now merged ffmpeg-mt and all I can say is that it works way better than when it was a different branch. No crashes whatsoever. The garbled frames issue when seeking is vastly reduced, I've only found it in some samples. There are no rainbows but instead there is a bit of blockiness and other frames rests:

As you can see the garbage is part of a previous frame. Found this in Blu-ray's with 4 ref frames and with MBAFF streams. Also it seems to be random, I can't reproduce the same blockiness when seeking to a concrete frame twice. Everything else is perfect in ffmpeg-mt as far as I've tested.

I think the problem may be coming from the incomplete parsing of access units. It's being discussed here (http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=968).

[Reimar]

I think the problem may be coming from the incomplete parsing of access units. It's being discussed here (http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=968).

Assuming I understood correctly what you need here (namely detection of access unit boundaries from a stream of NAL units)...
This was discussed for MPlayer once, and we decided that complete parsing is actually not needed, and I think ff_h264_find_frame_end in libavcodec/h264_parser.c basically uses the same method.
It is in libmpdemux/video.c and this is the main part, maybe it helps ("i" contains the NAL unit number including the 0x100 - it is intended for annex B codec files, but should be easy to modify for the format mp4/mov uses):

// here starts the access unit end detection code
// see the mail on MPlayer-dev-eng for details:
// Date: Sat, 17 Sep 2005 11:24:06 +0200
// Subject: Re: [MPlayer-dev-eng] [RFC] h264 ES parser problems
// Message-ID: <20050917092406.GA7699@rz.uni-karlsruhe.de>
if((i&~0x60) == 0x101 || (i&~0x60) == 0x102 || (i&~0x60) == 0x105)
// found VCL NAL with slice header i.e. start of current primary coded
// picture, so start scanning for the end now
in_picture = 1;
if (in_picture) {
i = sync_video_packet(d_video) & ~0x60; // code of next packet
if(i == 0x106 || i == 0x109) break; // SEI or access unit delim.
if(i == 0x101 || i == 0x102 || i == 0x105) {
// assuming arbitrary slice ordering is not allowed, the
// first_mb_in_slice (golomb encoded) value should be 0 then
// for the first VCL NAL in a picture
if (demux_peekc(d_video) & 0x80)
break;
}
}

[clsid]

There is a bunch of discussions on the ffmpeg-dev mailinglist about thus subject. Someone is working on implementing it.

[tetsuo55]

Guys a quick Q.
My X-Fi Prelude max output seems to be 24bit so should I select output 24bit in ffdshow audio instead of 32bit float?
Thanks

I know its a bit late but the X-Fi uses 32bit internally, so if you feed it anything lower it will convert anyway.
It''s probably best to use 32bit

[bwlonsdale]

Hi all - does someone know if there should be any difference in having FFDShow decode AC3 against passing it through to my AMP and have it do the decoding?

I've noticed that the bass is reduced when I let FFDShow decode the stream.

I'm using an ATI 4600, set for multichannel out (5.1). I've made sure there are no options selected in the sound control panel applet, i.e. no effects or any bass management settings are selected, it shouldn't be doing anything to the audio.

My amp is a Denon 1909. I only noticed this the other day when I was messing with Slysoft's Reclock. I had an issue with it so I uninstalled it and then had FFDShow temporarily pass through the AC3 direct to the amp and then I noticed the bass volume either seemed to be louder or at least it gave more of a thump. It's not my imagination at work, I had someone else check too :)

I have it in my head that there was some issue around bass being 15db quieter when decoded by FFDShow, but that was something I either read in passing or have just made up in my head.

I have FFDShow configured to decode AC3 and the mixer set for 5.1 output, no other options selected for bass management etc. Pretty much everything is at defaults in the audio side of things.

Can anyone confirm or deny I need to be doing anything with bass management if I let FFDShow do the decoding?

This is in Vista Media Center - didn't try anything else yet. I like to let FFDShow do the decoding because then I can use the volume control on the VMC remote rather than reach for another one when I need to turn it down/mute.

Well at least I know I didn't imagine this now:-

http://www.avforums.com/forums/home-cinema-pcs/805938-bass-setup-htpc-av-receiver.html

The LFE channel is reduced 10db when it's encoded on DTS/DD tracks.

So....does FFDShow compensate in anyway for the -10db loss, or do I need to set that manually via LFE Crossover configuration?

I notice the default on there is -2db gain, which seems a little arbitrary. Maybe there was a decision made not to do any compensation or have that level for some other reason? I would guess a tick box on the LFE Crossover tab to apply -10db correction could be useful? However, I don't want to have to specify a crossover frequency when my amp is doing all that side of things itself, something separate would seem more logical.

There's maybe a setting on my amp for this, but since the HTPC isn't only going to be processing DD/DTS, to have a universal -10db gain on the amp is going to make the opposite problem appear on other sources.

[shaolin95]

I know its a bit late but the X-Fi uses 32bit internally, so if you feed it anything lower it will convert anyway.
It''s probably best to use 32bit
Thanks all of you for the answers to this.
I will then use 32bit float indeed. :-)

[haruhiko_yamagata]

ffdshow's grab function takes screenshots with bad colors:
http://www.stfcc.org/misc/ffdshow.r2686.png
http://www.stfcc.org/misc/mpc-hc.r990.png

The filter chain was something like Haali Media Splitter -> ffdshow (decoding H.264) -> ffdshow (decoding YV12 - took screenshot) -> Renderer (in MPC-HC).
Thanks, I have fixed at rev 2699. It was more generic problem than just one of grab filter.

[haruhiko_yamagata]

Assuming I understood correctly what you need here (namely detection of access unit boundaries from a stream of NAL units)...
This was discussed for MPlayer once, and we decided that complete parsing is actually not needed, and I think ff_h264_find_frame_end in libavcodec/h264_parser.c basically uses the same method.
It is in libmpdemux/video.c and this is the main part, maybe it helps ("i" contains the NAL unit number including the 0x100 - it is intended for annex B codec files, but should be easy to modify for the format mp4/mov uses):

Thank you for the info.
Then I might have guessed wrong. The issue may not related to parsing.

[leeperry]

I'm not sure anyone cares, but it would appear that the mixer coeffs for stereo are not too accurate :
http://ac3filter.net/guides/mixing_matrix

ffdshow sets them all to 1, so the center channel is too loud, and so is the LFE....and it doesn't accept 4 digits after the coma so it's not possible to use the 0.7071 value.

the ac3filter site doesn't say anything about BackL/BackC/BackR...so I'm not too sure about these....setting them to 1/0.7071/0 for L and 0/0.7071/1 for R seems to work pretty fine :

http://www.image-load.eu/out.php/i145749_mix.png

[STaRGaZeR]

Thank you for the info.
Then I might have guessed wrong. The issue may not related to parsing.

As you can see in the image the garbage has the form of a slice, and almost always happens in the bottom of the frame.

[LSudlow]

leeperry, I don't know if it's related, but I've always felt the same way about the Dolby Pro Logic II decoder. The center is WAY too loud and the surrounds are way too weak. I don't know what the correct matrix values are, but I doubt the current ones are right.

[mark0077]

Hi all,

Just started playing with ffdshow resize in build 2699.

I happened to be playing a 1920 x 1080 .ts file, but when I set resize to "Specify Horizontal Size" and begin typing into the "New Size" width, media player classic+ffdshow crash. Have to restart them both.

Reproducible time after time. Maybe someone could take a look? Means I can't reliably use the resize to test different settings without a crash.

[mark0077]

Hi all,

I am back to tracking down bugs / quality differences in the following decoders.

libmpeg2 (in mpc-hc), libmpeg2 (in ffdshow) and libavcodec mpeg2 (in ffdshow)

In my DVD Quality thread which I am currently updating with as much info as I can give, one thing i came accross before was very bad dvd menu rendering with ffdshow. Below is a comparison of all three decoders. You would expect the highlighted area to be the same in at least libmpeg2 in mpc-hc and libmpeg2 in ffdshow but no, again ffdshow has a problem. This has been a problem for months, through many operating systems and drivers. It has nothing to do with interlacing settings as everything is been treated as progressive at every stage.

Note: I can't understand why the colors look so different also on these menu highlights.

http://img24.imageshack.us/img24/6749/comparisonty8.th.png (http://img24.imageshack.us/my.php?image=comparisonty8.png)
http://img511.imageshack.us/img511/4188/comparison2ux2.th.png (http://img511.imageshack.us/my.php?image=comparison2ux2.png)

[leeperry]

leeperry, I don't know if it's related, but I've always felt the same way about the Dolby Pro Logic II decoder. The center is WAY too loud and the surrounds are way too weak. I don't know what the correct matrix values are, but I doubt the current ones are right.
well try my coeffs, and see how it goes ;)
in the DPL/DPL2 matrixes, the "-" characters are definitely wrong I think.....they invert the phase of the left channel, not something you wanna do :o

[LSudlow]

well try my coeffs, and see how it goes ;)
in the DPL/DPL2 matrixes, the "-" characters are definitely wrong I think.....they invert the phase of the left channel, not something you wanna do :o

I pretty much do that, using the sliders rather than the custom matrix. 70% on the center and 140% on the surrounds sounds pretty close to my reciever's DPLII decoder. But I do hope some of the wizards here can figure out why the center is so overpowered and the surrounds underpowered when the matrix values of 1.0 should be right. It looks like the mixer's input or output aren't handling something correctly.
:thanks:

[leeperry]

I pretty much do that, using the sliders rather than the custom matrix. 70% on the center and 140% on the surrounds sounds pretty close to my reciever's DPLII decoder. But I do hope some of the wizards here can figure out why the center is so overpowered and the surrounds underpowered when the matrix values of 1.0 should be right. It looks like the mixer's input or output aren't handling something correctly.
:thanks:
well don't use the sliders on the DPL/DPL2 matrixes, as their left channel has inverted phase..
you can't use 1.0 for each channel, there are coeffs(0.7071 for center channels) that need to be followed....see the link above on the ac3filter website.

anyway, I've tried my matrix on many movies, it's great! :cool:

[Kado]

@shaolin95, Jeremy Duncan
Check this article (http://mp3decoders.mp3-tech.org/24bit.html) regarding 16 and 24bit audio.

[squid_80]

in the DPL/DPL2 matrixes, the "-" characters are definitely wrong I think.....they invert the phase of the left channel, not something you wanna do :o
IIRC that's not strictly wrong, the channel may be inverted before encoding. But the decoder should be taking care of fixing it since it has access to the specific flag in the AC3 stream

[haruhiko_yamagata]

I'm not sure anyone cares, but it would appear that the mixer coeffs for stereo are not too accurate :
http://ac3filter.net/guides/mixing_matrix

ffdshow sets them all to 1, so the center channel is too loud, and so is the LFE....and it doesn't accept 4 digits after the coma so it's not possible to use the 0.7071 value.

the ac3filter site doesn't say anything about BackL/BackC/BackR...so I'm not too sure about these....setting them to 1/0.7071/0 for L and 0/0.7071/1 for R seems to work pretty fine :

http://www.image-load.eu/out.php/i145749_mix.pngIt should be 0.7071. I meant to set 0.7071, actually did not.
Is any developer interested in ffdshow audio? I'm not interested in it too much.

[lych_necross]

@shaolin95, Jeremy Duncan
Check this article (http://mp3decoders.mp3-tech.org/24bit.html) regarding 16 and 24bit audio.

That confirms what I suspected about 24bit audio. For the most part, it is not needed, but nice when it is done properly.

[Mr VacBob]

I've been testing the now merged ffmpeg-mt and all I can say is that it works way better than when it was a different branch. No crashes whatsoever. The garbled frames issue when seeking is vastly reduced, I've only found it in some samples. There are no rainbows but instead there is a bit of blockiness and other frames rests:

http://thumbnails7.imagebam.com/2705/11619e27046860.gif (http://www.imagebam.com/image/11619e27046860)

As you can see the garbage is part of a previous frame. Found this in Blu-ray's with 4 ref frames and with MBAFF streams. Also it seems to be random, I can't reproduce the same blockiness when seeking to a concrete frame twice. Everything else is perfect in ffmpeg-mt as far as I've tested.

Even if it's a race condition (= not reproducible), I can try to fix it with a sample. It can take pretty much forever to binary-search that kind of bug, though.

[leeperry]

It should be 0.7071. I meant to set 0.7071, actually did not.
Is any developer interested in ffdshow audio? I'm not interested in it too much.
well, it's user selectable, so no big deal :o
I'm not sure I could hear a diff between 0.707 and 0.7071 anyway :D
That confirms what I suspected about 24bit audio. For the most part, it is not needed, but nice when it is done properly.
each integer/float conversion is potentially very lossy...avoid them if you can.

also, how can I make sure that audio files remain in 32 float from start to end ? by decoding w/ the internal decoders ?
coz if I use madflac or MPC's audio MP3 decoder, the source is shown to be "PCM uncompressed"....meaning it's converted to 32 float when it goes through my winamp2 plugin? and then remains in 32 float when sent to my audio drivers(I've only checked 32float in the output section)

I've tried to use the internal FLAC decoding, but it lacks a source filter apparently...but FLAC is lossless so it's not as important as mp3 for instance.

[haruhiko_yamagata]

Even if it's a race condition (= not reproducible), I can try to fix it with a sample. It can take pretty much forever to binary-search that kind of bug, though.
Well, it may be DirectShow specific. I would rather like to ask you to take a look at this (http://forum.doom9.org/showthread.php?p=1251292#post1251292).
I have copied the sample here (http://ffdshow-tryout.sourceforge.net/doom9/full_metal_panic_blocky_at_100-105sec_with_ffmpeg-mt.m2ts) for convenience.

[mark0077]

haruhiko_yamagata any ideas about the bug I posted earlier regarding DVD Menu highlighting and positioning problems with ffdshow. I imagine it would be a small fix but would be great to get it off the list of ffdshow problems. :D

[haruhiko_yamagata]

haruhiko_yamagata any ideas about the bug I posted earlier regarding DVD Menu highlighting and positioning problems with ffdshow. I imagine it would be a small fix but would be great to get it off the list of ffdshow problems. :D
It won't be a easy fix. Because I know nothing about how DVD menu is handled, I have to read all the code. And search technical documentation about DVD menu and read it. If I could read through the code, still it may be difficult to understand...

[leeperry]

haruhiko_yamagata any ideas about the bug I posted earlier regarding DVD Menu highlighting and positioning problems with ffdshow. I imagine it would be a small fix but would be great to get it off the list of ffdshow problems. :D
w/ what player/renderer?
MPC HC and HR/EVR are not too DVD-friendly, mostly the m$ DVD Navigator is at fault I think :o
KMP lets you select other DVD navigators(nero/cyberlink/intervideo/nvidia), did you try that?
your last resort will be the keyboard arrows plus CTRL(or ALT, can't remember) to navigate the menus.

[clsid]

Maybe Leak knows how to fix that DVD menu issue.

[STaRGaZeR]

Even if it's a race condition (= not reproducible), I can try to fix it with a sample. It can take pretty much forever to binary-search that kind of bug, though.

This can perfectly be a ffdshow issue. You can use MSG00 ED.mkv, here you have a larger sample to test: http://www.megaupload.com/?d=XFE6RWJ0 (407MB)

I've tested Haali's splitter and Gabest splitter with the same result. You may need to seek a lot to see it. It seems that the larger the file the easier it is to see the blockiness when seeking and this one is "small".

Well, it may be DirectShow specific. I would rather like to ask you to take a look at this (http://forum.doom9.org/showthread.php?p=1251292#post1251292).
I have copied the sample here (http://ffdshow-tryout.sourceforge.net/doom9/full_metal_panic_blocky_at_100-105sec_with_ffmpeg-mt.m2ts) for convenience.

I confirm that with other MBAFF sources.

[mark0077]

w/ what player/renderer?
MPC HC and HR/EVR are not too DVD-friendly, mostly the m$ DVD Navigator is at fault I think :o
KMP lets you select other DVD navigators(nero/cyberlink/intervideo/nvidia), did you try that?
your last resort will be the keyboard arrows plus CTRL(or ALT, can't remember) to navigate the menus.

When using mpc-hc alone (using evr or evr-cp, I don't think the renderer is at fault), everything is perfect always. Using mpc-hc and any of the ffdshow mpeg2 decoders (including libmpeg2 which is what mpc-hc uses) its broken. This is why i assume its an ffdshow problem, not a navigator problem. I can still happily select any menu items so it doesn't stop me using most DVD's, just very ugly looking for the rest of the family ;) I have a small feeling that the uglyness in this case might be because this dvd menu (from "The World is Not Enough") like most of my DVD's are not marked as progressive (and everything on this DVD is completely progressive in origin) so I have deinterlacing completely disabled. Everywhere in my ffdshow options I have everything set to "Force Progressive" and I control deinterlacing myself by just enabling / disabling de-interlacing in ffdshow. So I have a feeling that whatever piece of code is drawing these little highlights, is assuming its drawing an interlaced highlight. I think this because you can see slight jumps in the highlights. So if this is the problem, maybe the fix could be to not let this piece of code just listen to the progressive flag, and take maybe an optional forced input, like "Force Progressive" which seems to be the solution to many of my problems surrounding bad dvd quality. This is really just a hunch though so I could be completely wrong. Below are two images comparing the different combinations of decoders. What you should gather from these is that ffdshow's decoders seem to be somehow the cause as mpc-hc looks perfect on its own.

http://img24.imageshack.us/img24/6749/comparisonty8.th.png (http://img24.imageshack.us/my.php?image=comparisonty8.png)
http://img511.imageshack.us/img511/4188/comparison2ux2.th.png (http://img511.imageshack.us/my.php?image=comparison2ux2.png)

My second issue with dvd menus and ffdshow, is only seen when using mpc-hc's internal decoder, and ffdshow as a filter doing whatever. In that situation, using a dvd menu that seems to be made up of one frame, not a video, then highlighting certain options completely freezes the image. This is a vast improvement over old ffdshow versions which just showed a black screen on these 1 frame menus (which was happily fixed due to my dvd quality post late last year), but something still causes these 1 frame menus to freeze up now when using mpc-hc mpeg2 decoder, along with ffdshow. Using ffdshows own mpeg2 decoders doesn't show the freeze so its an issue between the interface of mpc-hc and ffdshow I suspect. I don't think its a navigator problem again, something to do with the fact that this dvd menu is just one frame which was what caused the complete black frame in older versions.

I suppose my third and final issues with dvd menus, and again only when using ffdshow is if I have de-interlacing forced enabled (I use yadif, double frame rate, and de-interlace progressive frames enabled), as I do enable it sometimes when I know a certain DVD needs it. If the menus of that dvd were not designed to be de-interlaced, yes they look ugly sometimes with yadif but I still expect to get through the menu, hit play and the DVD begins and looks fine. The problem is, when forcing de-interlacing enabled (and forcing for frames marked as progressive also) 99% of the time the very first progressive image ffdshow meets will freeze. It will not progress onto the next image, or copyright warning or whatever should come next. The DVD that this happens on is again this "Queens Greatest Hits" dvd where there is a copyright warning, a DTS advertisement, both single frames. I very rarely get past the first warning as ffdshow will get stuck. My suspicion here is yadif or some internal ffdshow code is waiting on something, like a "field" or something that just isn't there when this single frame is actually progressive. Again this is just a hunch but this problem actually means many manual steps each time I want to play any of these disks. I end up enabling de-interlacing, starting the DVD, realizing, oh these progressive menus freeze when de-interlacing is forced in ffdshow, disable de-interlacing, apply settings, exit mpc, start dvd again, all works fine, then when I hit play within the dvd I can reenable de-interlacing.... Very weird but I suspect a fix would be easy ;) Again I see this problem mostly when dealing with single progressive frames. All stuff that probably wouldn't get caught during normal testing but something that will and does effect people actually being able to play DVDs or not.

[vio_man]

At xvidvideo.ru they wrote:

ffdshow-mt, beginning from revision 2677, was combined with the basic branch of ffdshow

So, this means that any ffdshow-tryouts build after 2677 will be using ffmpeg-mt?

[XhmikosR]

Yes, it is included, but by default libavcodec is used for h.264. You can set ffmpeg-mt as the default decoder for h.264 in codecs configuration.

[leeperry]

Again I see this problem mostly when dealing with single progressive frames. All stuff that probably wouldn't get caught during normal testing but something that will and does effect people actually being able to play DVDs or not.
oh, ok! well I've personally given up on DVD menus in HR a long time ago, so damn annoying to click...but nothing happening :mad:

if this could be fixed, that'd be pretty cool indeed :cool:

[Leak]

Maybe Leak knows how to fix that DVD menu issue.
Sorry, but I don't know any more about DVD subtitles (which the DVD menus are after all) than you do - but if I had to take a guess after looking at mark0077's image I'd say it's something to do with the fact that regular subtitles usually have black borders whereas menu highlights don't, and the ugly rendering seems to be caused by the highlight's chroma value overwriting the underlying image's chroma value instead of somehow being blended (at least at the edges).

I wonder if they'd look better if it was possible to add the subtitles after converting to RGB - at least when one converts to RGB in the end anyway...

np: The Qemists - SWAG Intro (Join The Q)

[mark0077]

Ooh interesting so I guess it can probably be boiled down to either ffdshow subtitles or the way the subtitles are merged with the video behind. Never knew the highlights were done with subtitles.

I guess in the case where I don't do mpeg2 decoding with ffdshow, the highlights / subtitles are handled with mpc's subtitle "engine" which seems to do the much better job?

[EpsilonX]

Yes, it is included, but by default libavcodec is used for h.264. You can set ffmpeg-mt as the default decoder for h.264 in codecs configuration.

What's the currrent "status" of ffmpeg-mt as H.264 decoder..?
Is it reliable enough to lets say replace libavcodec for daily use..?

[lych_necross]

each integer/float conversion is potentially very lossy...avoid them if you can.

Lossy isn't necessarily bad as long as its done properly. Also, if there is no perceivable difference between 16, 24, or 32 bit, simply choose the one that preforms the best/fastest.

[XhmikosR]

What's the currrent "status" of ffmpeg-mt as H.264 decoder..?
Is it reliable enough to lets say replace libavcodec for daily use..?
I'm not an expert on this, but ffmpeg-mt would probably have some bugs because it is experimental. So you better avoid using it for everyday use. Personally, I use ffmpeg-mt and haven't noticed anything wrong, but you know, use it at your own risk.
Besides, someone has to use it to report any bugs found and get them fixed.:p

[haruhiko_yamagata]

I suppose my third and final issues with dvd menus, and again only when using ffdshow is if I have de-interlacing forced enabled (I use yadif, double frame rate, and de-interlace progressive frames enabled), as I do enable it sometimes when I know a certain DVD needs it. If the menus of that dvd were not designed to be de-interlaced, yes they look ugly sometimes with yadif but I still expect to get through the menu, hit play and the DVD begins and looks fine. The problem is, when forcing de-interlacing enabled (and forcing for frames marked as progressive also) 99% of the time the very first progressive image ffdshow meets will freeze. It will not progress onto the next image, or copyright warning or whatever should come next. The DVD that this happens on is again this "Queens Greatest Hits" dvd where there is a copyright warning, a DTS advertisement, both single frames. I very rarely get past the first warning as ffdshow will get stuck. My suspicion here is yadif or some internal ffdshow code is waiting on something, like a "field" or something that just isn't there when this single frame is actually progressive. Again this is just a hunch but this problem actually means many manual steps each time I want to play any of these disks. I end up enabling de-interlacing, starting the DVD, realizing, oh these progressive menus freeze when de-interlacing is forced in ffdshow, disable de-interlacing, apply settings, exit mpc, start dvd again, all works fine, then when I hit play within the dvd I can reenable de-interlacing.... Very weird but I suspect a fix would be easy ;) Again I see this problem mostly when dealing with single progressive frames. All stuff that probably wouldn't get caught during normal testing but something that will and does effect people actually being able to play DVDs or not.
Does this happen if you decode MPEG-2 in ffdshow?
If you use other MPEG-2 decoder and decode raw video in ffdshow, it is expected.
yadif require previous, current and next frame to deinterlace. ffdshow passes through the first image of a segment, but if the second image of the segment has very long duration, ffdshow will wait for third frame without drawing the second frame.
If you decode MPEG-2 in ffdshow, ffdshow has more information about the stream, thus the long waiting is usually avoided.
I have no choice but to say "please decode MPEG-2 in ffdshow".

[leeperry]

Lossy isn't necessarily bad as long as its done properly. Also, if there is no perceivable difference between 16, 24, or 32 bit, simply choose the one that preforms the best/fastest.
well, if I decode mp3 in ffdshow I'm not sure whether it's decoded in 16 integer or 32 float....so I'm using Gabest's MP3 decoder in 32 float, then I process it in 32 float through the "Spectralive NXT" VST plugin in ffdshow, and output 32 float to my audio drivers.....at least there isn't any dodgy conversion happening.

ffdshow say "stereo PCM uncompressed" as input description, but I guess it "knows" that it's already 32 float :rolleyes:

my sound card is 24/96, so I've tried to output 24 integer + enable noise shaping to "heavy" in ffdshow, but I can't hear a difference.....so I prefer to let my audio drivers be the judge :D

[mark0077]

haruhiko_yamagata: I think your right. I can't reproduce the crash if I use ffdshows internal decoders. I still would definitely categorize this as a bug. It should be upto yadif / ffdshow to handle itself correctly and not crash... Some check should be put in place for the case where it doesn't have enough information from internal decoders.

[leeperry]

I can't reproduce the crash if I use ffdshows internal decoders.
so DVD menus work fine in HR/EVR if using ffdshow's MPEG2 decoder? I was using Gabest's, will give it a shot :cool:

[mark0077]

leeperry: no I have never been able to get menus working with HR. The three bugs I talk about in my post above are all related to ffdshow and can be fixed within it I am sure. The crash I see is, as haruhiko_yamagata says due to the way ffdshow with yadif works, and only seen in dvd menus where single frames are found. Because so many of my dvd's are badly marked as originating from progressive/interlaced sources I can say this yadif crash is something that will effect other users.

[haruhiko_yamagata]

It may be a bug, but workaround is impossible, as far as I can imagine.
By the way, does the highlight issue go away if you select libavcodec or libmpeg2 in ffdshow's MPEG-2 decoder configuration and check "DVD decoding" and just do not use it (decode YV12 instead)? If yes, it has been fixed at rev 2711.

[albain]

Hi all,

somewhere between revision 2686 (which is okay) and revision 2693 (which is not) I have many crashes with vista media center when loading videos. Last builds have this problem too (2715 included)

I have not made deep tests and I don't know if this is related to the video format or a general regression.
Videos are mkv 720p encoded in h264

I use Haali splitter and CoreAVC for decoding

I will try to narrow the analysis.

Crash occur on ICL or VS2008 builds, and in release mode only (not in debug, this is a memory violation error)

Regards

[clsid]

Perhaps your problem is related to this change:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2691

[albain]

Perhaps your problem is related to this change:
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2691

Actually, no, the problem comes from this revision : 2688 & 2689
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2689
It concerns FFDShow converters cleanup

Haruhiko, could you have a look on this ?

Thanks

[mark0077]

It may be a bug, but workaround is impossible, as far as I can imagine.
By the way, does the highlight issue go away if you select libavcodec or libmpeg2 in ffdshow's MPEG-2 decoder configuration and check "DVD decoding" and just do not use it (decode YV12 instead)? If yes, it has been fixed at rev 2711.

I guess the real solution to the crash is to begin improving interlaced/progressive frame detection. ;)

For the highlighting issue (using version 2715), the problem ONLY happens when using ffdshows's mpeg2 decoders. Using the decoder in mpc-hc the highlights are 100% perfect. Its an ffdshow issue. I have "DVD decoding" enabled, and have tried outputting in yv12 but this doesn't change the resulting image with ffdshows decoders, still the highlights look completely wrong.

[lych_necross]

well, if I decode mp3 in ffdshow I'm not sure whether it's decoded in 16 integer or 32 float....so I'm using Gabest's MP3 decoder in 32 float, then I process it in 32 float through the "Spectralive NXT" VST plugin in ffdshow, and output 32 float to my audio drivers.....at least there isn't any dodgy conversion happening.

ffdshow say "stereo PCM uncompressed" as input description, but I guess it "knows" that it's already 32 float :rolleyes:

my sound card is 24/96, so I've tried to output 24 integer + enable noise shaping to "heavy" in ffdshow, but I can't hear a difference.....so I prefer to let my audio drivers be the judge :D
In my experience, noise shaping is usually only helpful when converting to 16bits from either 24 or 32. MP3s are usually ripped from 16 bit sources, so decoding it in 32 bits is usually results in padding. I believe this was already mentioned, but the kmixer in Windows resamples to 16bit 48khz (as do most soundcard drivers). The only way to avoid this is to use kernel streaming, ASIO, or WASAPI.

[Snowknight26]

You wouldn't want to resample it. It doesn't matter what bitdepth the source was for a lossy format. The lossy transcode needs all the bits it can 'reconstruct' the source as accurately as possible.

[Leak]

It may be a bug, but workaround is impossible, as far as I can imagine.
Ummm... that problem was the reason I put some custom code into libmpeg2 to signal a sequence end, which is what is set on single-frame menu images.

In that case, just feed yadif the last frame however many times you need to for it to produce output, or just skip yadif entirely and return the picture un-deinterlaced - I don't think there's many interlaced static menus, and even then I'd rather take an ugly image over a hang...

[haruhiko_yamagata]

Ummm... that problem was the reason I put some custom code into libmpeg2 to signal a sequence end, which is what is set on single-frame menu images.

In that case, just feed yadif the last frame however many times you need to for it to produce output, or just skip yadif entirely and return the picture un-deinterlaced - I don't think there's many interlaced static menus, and even then I'd rather take an ugly image over a hang...hmm...
IDvdInfo2::GetCurrentDomain may help.

[mark0077]

Ummm... that problem was the reason I put some custom code into libmpeg2 to signal a sequence end, which is what is set on single-frame menu images.

In that case, just feed yadif the last frame however many times you need to for it to produce output, or just skip yadif entirely and return the picture un-deinterlaced - I don't think there's many interlaced static menus, and even then I'd rather take an ugly image over a hang...

My thoughts exactly. I rather see garbled image than a crash at any stage. From your description of the problem I suppose when ffdshow knows a certain frame / selection of frames could cause yadif to blow up, then it could be skipped or just sent some duplicates to keep yadif happy and prevent any freezing.

[Leak]

hmm...
IDvdInfo2::GetCurrentDomain may help.
Maybe, but I think I tried that when I worked on the AviSynth plugin and it wasn't too helpful.

Also, it won't help with extras stuff like self-running image galleries (like the ones on my Fullmetal Alchemist DVDs) that have a lot of static images with several seconds long pauses in between - but those work fine using the sequence flags in the AviSynth filter; you just need to special-case frames that have the SEQUENCE_END flag set and somehow pass them through immediately.

[haruhiko_yamagata]

Maybe, but I think I tried that when I worked on the AviSynth plugin and it wasn't too helpful.

Also, it won't help with extras stuff like self-running image galleries (like the ones on my Fullmetal Alchemist DVDs) that have a lot of static images with several seconds long pauses in between - but those work fine using the sequence flags in the AviSynth filter; you just need to special-case frames that have the SEQUENCE_END flag set and somehow pass them through immediately.
yadif in ffdshow use the SEQUENCE_START/SEQUENCE_END flags and works if MPEG-2 is decoded in ffdshow.
I'm talking about the cases MPEG-2 is decoded in the upper stream and ffdshow is decoding raw video.

[mark0077]

Maybe two of my problems with crashing are related then. The second time I get crashes when using ffdshow, is again with single frame menu's but when using a non ffdshow mpeg2 decoder (yadif enabled or disabled doesn't effect this). Trying to highlight any menu options in these single frame menus freezes up. I can still click menu options but I see no visual highlighting or indication I am selecting different options. Its like no more frames are drawn. The freeze doesn't happen when ffdshow is not used, or when I use ffdshows internal decoders. So I am sure a fix for one might also fix the other :D:D:D

[leeperry]

I worked on the AviSynth plugin
do you have any idea why is it impossible to have the avisynth.dll anywhere else than in /windows/system32/ ?
I'd like to put it on my ramdisk to lower the media opening time, but then it won't work anymore :(
In my experience, noise shaping is usually only helpful when converting to 16bits from either 24 or 32. MP3s are usually ripped from 16 bit sources, so decoding it in 32 bits is usually results in padding. I believe this was already mentioned, but the kmixer in Windows resamples to 16bit 48khz (as do most soundcard drivers). The only way to avoid this is to use kernel streaming, ASIO, or WASAPI.
kado gave a link in the previous pages where it's pretty clear that mp3 being lossy, you wanna decode it in the highest resolution to avoid roundings....that's what I've been doing for a long while. plus I don't use KMixer ;)

[iron2000]

It works for me. Please make sure you have installed DScaler plugins on installation of ffdshow. Also make sure you have working installation of DScaler.

I don't mean using the DScaler deinterlacing filters in ffdshow.
I mean using ffdshow as a filter in DScaler, to postprocess the picture in DScaler.

Was able to do it in some version of ffdshow way back.

[Leak]

yadif in ffdshow use the SEQUENCE_START/SEQUENCE_END flags and works if MPEG-2 is decoded in ffdshow.
I'm talking about the cases MPEG-2 is decoded in the upper stream and ffdshow is decoding raw video.
Oh, okay... but why on earth would anyone do that? :confused:

I guess it would be possible to simply keep re-processing the last image if no new image has been coming in for a second or so, but I dare not say how hard that would be to implement...

[mark0077]

Oh, okay... but why on earth would anyone do that? :confused:

I guess it would be possible to simply keep re-processing the last image if no new image has been coming in for a second or so, but I dare not say how hard that would be to implement...

I need to decode mpeg2 in the upper stream, aka mpc-hc because of the problems ffdshow has with menu highlighting not looking correct. ;)

[Leak]

I need to decode mpeg2 in the upper stream, aka mpc-hc because of the problems ffdshow has with menu highlighting not looking correct. ;)
Maybe it's just me, and maybe I'm repeating myself, but I'd take slightly blocky menu highlights over stuck menus every day of the week...

Not to mention that I watch DVDs for the content and not for the menus... :p

[haruhiko_yamagata]

Actually, no, the problem comes from this revision : 2688 & 2689
http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=rev&revision=2689
It concerns FFDShow converters cleanup

Haruhiko, could you have a look on this ?

Thanks
It's not my fault. You have an e-mail from me.

[mark0077]

Maybe it's just me, and maybe I'm repeating myself, but I'd take slightly blocky menu highlights over stuck menus every day of the week...

Not to mention that I watch DVDs for the content and not for the menus... :p

I guess I can just hope someone figures out whats going wrong with the highlighting using ffdshow then :D That really makes using ffdshow decoders pretty much perfect when it comes to DVD decoding. Just smart progressive/interlace detection is all thats needed then, detection that can rival some of these expensive hardware DVD players ;)

I just thought the second type of freeze I get which is not related to yadif, just single menu freezes alone would be something that could be fixed. Earlier builds just showed a black screen, its improved quite alot but with decoding happening earlier in the graph... ffdshow still gets a bit confused and stuck :)

[haruhiko_yamagata]

Hi all,

Just started playing with ffdshow resize in build 2699.

I happened to be playing a 1920 x 1080 .ts file, but when I set resize to "Specify Horizontal Size" and begin typing into the "New Size" width, media player classic+ffdshow crash. Have to restart them both.

Reproducible time after time. Maybe someone could take a look? Means I can't reliably use the resize to test different settings without a crash.
I can't reproduce. What did you type?

[mark0077]

I was actually going to type 720.

I think the crash happened after the 7. I will try and reproduce again and see what settings may stop it happening if any.

[haruhiko_yamagata]

As for the positioning of DVD menu, if I uncheck "Set pixel aspect ratio in output media type" the problem is fixed. The AR is still correct. Tested with overlay mixer, VMR7, VMR9.

[mark0077]

Wow, great find :D Thanks for that I will try it when I get home. :D

[clsid]

Does that mean that the dvd menu positioning issue is caused by ffdshow sending bad interlacing info to the next filter in the graph? But since ffdshow gets the same bad info from the MPEG-2 decoder, it is not really ffdshow's fault?

When ffdshow is only doing the processing, it is not able to (use the sequence flags to) detect whether it currently is processing a 1 frame menu, right?

[albain]

It's not my fault. You have an e-mail from me.

Yes this is my fault (this was not an accusation by the way, I suspected this was an old bug because it would not crash under debug mode. Those bugs are the most difficult do trace)
Thanks I got your email. How did you reproduce without debug mode ?

Following your guidelines, I think this is fixed by now : revision 2716

[haruhiko_yamagata]

Yes this is my fault (this was not an accusation by the way, I suspected this was an old bug because it would not crash under debug mode. Those bugs are the most difficult do trace)
Thanks I got your email. How did you reproduce without debug mode ?

Following your guidelines, I think this is fixed by now : revision 2716
I could reproduce the crash with debug build, however, if CoreAVC is used in the filter graph, we can't use debugger.
I used Debugview for Windows (http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx) and many DPRINTF. It's the classic.
Thank you for the fix.

[haruhiko_yamagata]

Does that mean that the dvd menu positioning issue is caused by ffdshow sending bad interlacing info to the next filter in the graph? But since ffdshow gets the same bad info from the MPEG-2 decoder, it is not really ffdshow's fault?The aspect ratio rather than interlacing flag. The position is calculated in the application (MPC-HC in this case), ffdshow has to send some info to video renderer or somewhere so the the application can calculate correctly.

When ffdshow is only doing the processing, it is not able to (use the sequence flags to) detect whether it currently is processing a 1 frame menu, right?It's impossible as the sequence flags are obtained by ffdshow custom code in libmpeg2 and libavcodec.

[madshi]

It's impossible as the sequence flags are obtained by ffdshow custom code in libmpeg2 and libavcodec.
I think you could go down (you would say "up" :)) the filter chain by browsing through the connected pins to find the MPEG2 output pin and then ask its connection media type and grab the codec private data from there, which usually contains the sequence headers. Isn't that what you need? A bit ugly, but it might work...

[mark0077]

As for the positioning of DVD menu, if I uncheck "Set pixel aspect ratio in output media type" the problem is fixed. The AR is still correct. Tested with overlay mixer, VMR7, VMR9.

Damn, unfortunately setting this option to any of its 3 available options has no change on my menu highlights. I have also tried playing with settings like the mpc-hc "Keep aspect ratio" setting, and the ffdshow resizer on and off, ... the highlights seem a few pixels off, or slightly garbled in some cases.

Tis a pity. In my opinion, if ffdshow relies on internal data like you say, flags set by the internal decoders, and gains an advantage by doing this, I think every effort should be made to try and get that information from raw video also. I will leave the implementation upto you guys but it just sounds like the right thing to do... ie not favour internal / external decoders if the information can be gained using other methods. (although in this case, decoding WITH ffdshow seems to be causing the ugly highlights on 1 frame and moving menus, decoding WITHOUT ffdshow causes the freeze/crash in 1 frame menus, and decoding WITHOUT ffdshow in one frame screens with de-interlacing incorrectly enabled causes freezes / crashes).

[tetsuo55]

Shouldn't the relevant information be passed on between each step in the filter graph?

Information like:
-AR(in all its flavours)
-Framerate
-Interlace flag

Maybe even more information is usefull, if any value is no longer true(in the case of deinterlacing) the part of the chain that caused the change in the value should update the information to the new status and pass that along.

[haruhiko_yamagata]

I think you could go down (you would say "up" :)) the filter chain by browsing through the connected pins to find the MPEG2 output pin and then ask its connection media type and grab the codec private data from there, which usually contains the sequence headers. Isn't that what you need? A bit ugly, but it might work...
SEQUENCE_START/SEQUENCE_END flags indicate that the frame is a start/end of a sequence. It is not possible to use media types, because media types are not attached to all frames.

[lych_necross]

kado gave a link in the previous pages where it's pretty clear that mp3 being lossy, you wanna decode it in the highest resolution to avoid roundings....that's what I've been doing for a long while. plus I don't use KMixer ;)
I re-read that link and I see what your saying. I normally don't use gabset for mp3 playback (I usually use foobar) :)

[haruhiko_yamagata]

Damn, unfortunately setting this option to any of its 3 available options has no change on my menu highlights. I have also tried playing with settings like the mpc-hc "Keep aspect ratio" setting, and the ffdshow resizer on and off, ... the highlights seem a few pixels off, or slightly garbled in some cases.
A few pixels? Then it's quite usable.
With some special DVD (wrong encoding IMO), the menu is off by 10% of the screen height. I found I can avoid this by using DVD navigator's aspect ratio instead of decoded aspect ratio.

[mark0077]

A few pixels? Then it's quite usable.
With some special DVD (wrong encoding IMO), the menu is off by 10% of the screen height. I found I can avoid this by using DVD navigator's aspect ratio instead of decoded aspect ratio.

Oh definitely usable but consistently wrong for every DVD I have... Its not just a few pixels off really you can see in the screen shots where the perfect rectangle that mpc-hc draws isn't drawn nearly as good when using ffdshow decoders. The corners get blurred and the lines are skewed and a few pixels off. MPC-HC seems to get it perfect each time with every DVD I have... Not a big issue, at least better than the crashing when not using the non ffdshow decoders so for the moment I will put up with ugly highlights until someone would like to take a look into the code ;)

Actually I do notice, on this Queen DVD menu where you can select the audio output, PCM Stereo, DTS, or DD I think it is. The three options go from top to bottom so

---------- top of screen -------------



Option 1 - Highlight 1 should be here
< Position of option 1 highlight (ie. skewed toward centre)


Option 2 < Position of option 2highlight (90% perfect)


< Position of option 3 highlight (ie. skewed toware centre)
Option 3 - Highlight 3 should be here


---------- bottom of screen -------------

When I look at where the rectangles around these options are, I notice they are all skewed / offset towards the centre of the image (horizontally). Those further from the center get offset more so the further from the horizontal centre, the worse any menus will look in this combination.

So i think you are right in saying the aspect ratio flag has something to do with this problem. Its like the highlights are being displayed on an overlayed image but in slightly different aspect ratio window to the underlying image, like as if the overlay window isn't being given the right AR. I don't know how subtitles / highlights work but this sounds like a reasonable explanation. :D Do you see any easy solution.... what part of the ffdshow AR code might be at fault? I assume an AR is also supposed to be output with these subtitles / highlights, or at least taken into account when rendering them. Seems as if it is not in fact being taken into account correctly. Not a big deal but still would be nice to see it fixed now that we have an idea what it could be.

EDIT: Unfortunately build 2718 doesn't fix the above for me. Thought it was going to looking at the change list :P I thought fiddling with ffdshow resize settings, and turning it on or off, or editing the ar output option might have an effect but not for me. All highlights are stretched towards the centre of the screen by a few pixels, as I said, the further the highlight should be from the centre, the more it seems to get offset.

[haruhiko_yamagata]

I don't mean using the DScaler deinterlacing filters in ffdshow.
I mean using ffdshow as a filter in DScaler, to postprocess the picture in DScaler.

Was able to do it in some version of ffdshow way back.
OK, I'll take a look later.

[flanger216]

This has been bugging me for a while:

If you use libavcodec to decode MP3s, and you have 16, 24, 32 and 32-bit floating-point enabled as outputs, then ffdshow outputs 16-bit. If you deselect 16, 24 and 32-bit integer as output formats, then libavcodec outputs to 32-bit floating-point. So in the latter case, is libavcodec truly decoding to 32-bit floating-point, or is it still decoding to 16-bit and then merely padding the output to 32-bit floating point?

This also applies to AC3, DTS, Vorbis and all the other lossy (bitdepth-less) codecs that libavcodec can handle.

I only ask because libac3, libdts and libmad all seem to output to the highest bit-depth available, whereas libavcodec seems to prefer using the lowest available.

[leeperry]

I re-read that link and I see what your saying. I normally don't use gabset for mp3 playback (I usually use foobar) :)
the mp3 decoder in foobar is very unforgiving IMHO, the sound is just flat flat flat...I'll take libmad(Gabest or ffdshow) anyday over foobar for mp3.
plus you can't process VST/winamp plugins in 32 float, it's 16 integer or nothing....which also sounds ugly :o
leeperry: no I have never been able to get menus working with HR. The three bugs I talk about in my post above are all related to ffdshow and can be fixed within it I am sure. The crash I see is, as haruhiko_yamagata says due to the way ffdshow with yadif works, and only seen in dvd menus where single frames are found. Because so many of my dvd's are badly marked as originating from progressive/interlaced sources I can say this yadif crash is something that will effect other users.
I've never been too lucky w/ YADIF...in non-double framerate mode anyway(my AVS script can't affort 50fps :D )...it looks very ugly, like some drastic posterizing on PAL 576i?

Gabest's MPEG2 decoder in auto mode looks way better, and yet it doesn't blend fields...I think :o

[haruhiko_yamagata]

Oh definitely usable but consistently wrong for every DVD I have... Its not just a few pixels off really you can see in the screen shots
If you are talking about
http://img511.imageshack.us/img511/4188/comparison2ux2.th.png (http://img511.imageshack.us/my.php?image=comparison2ux2.png)
It's just rendering quality.
The code is written in mmx, I know it's wrong, but it's a bit hard to fix.

[B.F.]

Deblocking filter doesn't work in AviSynth and VirtualDub filters.

And can you do a checkbox in the Postprocessing page like "always postprocess" ?
It will be nice to use postprocessing filters even with a codecs like h264 sometimes.

[mark0077]

If you are talking about
http://img511.imageshack.us/img511/4188/comparison2ux2.th.png (http://img511.imageshack.us/my.php?image=comparison2ux2.png)
It's just rendering quality.
The code is written in mmx, I know it's wrong, but it's a bit hard to fix.

Thanks for letting me know the issue anyways. Any further ideas on my other problem, ie crashes in one frame areas when using external decoder or is that too tricky to work around?

[haruhiko_yamagata]

Thanks for letting me know the issue anyways. Any further ideas on my other problem, ie crashes in one frame areas when using external decoder or is that too tricky to work around?
What do you mean by "crash"? Is it memory access violation?

[mark0077]

Sorry i should say freeze. In the images above, if I use mpc-hc as the mpeg2 decoder, the menu looks perfect, but if I highlight one option, all is ok, but if I move the mouse up to another option, nothing happens. Media player classic still responds but no new frames are drawn so it appears as if the software has frozen. Its like ffdshow won't draw any subsequent frames when I highlight different options. This makes many dvds unusable without navigating through the player titles until the right one is found to start the movie.

MPC used on its own without ffdshow at all is ok, I can move the mouse around between options in the menu and no freezes. With ffdshow in the chain (but not decoding), I can only highlight one menu option, after that, no more screen updates happen and I will need to restart mpc to get back to a usable state.

[iron2000]

There are the edge-enhancement and denoise sliders in CCC, do they just work or need there be some ATI codec?
Or does it work only in DXVA? I'm confused of the video card's roles in playing my videos.
Don't seem to see a difference with those compared to the sharpen filter in ffdshow.

[roozhou]

Hi, I have a question on ffdshow's deinterlacing filters.
When I use deinterlacer from DScaler in ffdshow, it always doubles the framerate. IIRC some of DScaler deinterlacers run in adaptive mode, that is doubling framerate at high-motion scene and weaving at low-motion scene. I also checked the DS_Deinterlace.h and there is

// Deinterlace functions return true if the overlay is ready to be displayed.
typedef BOOL (__cdecl DEINTERLACE_FUNC)(TDeinterlaceInfo *Info);


But ffdshow just ignores the return value and shows the frame always. Does ffdshow have some limitation on adaptive deinterlacing?

[Konrad Klar]

If I change state of video codecs WMV1/7, WMV 2/8, WMV 3/9 to "disabled" MPC and MPC-HC crash when opening .wmv file.
This happens since rev2715, both in 32bit and 64bit version and for all .wmv files I have tested. WindowsMediaPlayer is not affected.
rev2698 and earlier are free from this problem (both 32bit and 64bit).
Example crash info:
Nazwa zdarzenia problemu: APPCRASH
Nazwa aplikacji: mplayerc32.exe
Wersja aplikacji: 1.2.1004.0
Sygnatura czasowa aplikacji: 49a1f286
Nazwa modułu z błędem: libmplayer.dll
Wersja modułu z błędem: 0.0.0.0
Sygnatura czasowa modułu z błędem: 499c05b2
Kod wyjątku: c0000005
Przesunięcie wyjątku: 00066cd5
Wersja systemu operacyjnego: 6.0.6001.2.1.0.256.1
Identyfikator ustawień regionalnych: 1045
Dodatkowe informacje 1: fd00
Dodatkowe informacje 2: ea6f5fe8924aaa756324d57f87834160
Dodatkowe informacje 3: fd00
Dodatkowe informacje 4: ea6f5fe8924aaa756324d57f87834160


I'm on:
Vista Ultimate x64 SP1 (polish).

[clsid]

No such problem here with rev2732.

[mark0077]

Guys is there a problem with ffdshows aspect ratio correction / handling code.

I just played some old star trek episodes from DVD today and noticed they were getting squished by ffdshow.

My solution to getting it back to normal was setting "No aspect ratio correction" on. That seemed to fix that. But playing another disk later in the day I found now that was stretched to fill the screen... The solution to this was to set ffdshow output option "Set pixel aspect ratio in output media type" to off.

My settings now that work for evrything I have thrown at it are

Resize - Aspect Ratio - "No aspect ratio correction"
Output - "Set pixel aspect ratio in output media type" - "Off"
MPC-HC - "Video Frame" - "Keep aspect ratio"

I am happy with this now but I am wondering theoretically shouldn't the finished aspect ratio be correct in all situations.... with the AR flag being sent around the place shouldn't mpc-hc sort my aspect ratio out no matter what ffdshow does. I am thinking of other users in the future, with ffdshows default settings for me not working for all of my video types. Would be nice to see the ratio looking correct in all settings, with the player doing any final aspect ratio correct if needed based on correct flags being sent around.

EDIT: Damn, found another 4:3 clip that gets stretched to 16:9 in this combination... Can't find a combination of these 4 settings that just gives me the right aspect ratio.

[LSudlow]

2732 - I can't enable the overlay control. Is anyone else seeing this? It's never been a problem in previous builds.

[haruhiko_yamagata]

Guys is there a problem with ffdshows aspect ratio correction / handling code.

I just played some old star trek episodes from DVD today and noticed they were getting squished by ffdshow.

My solution to getting it back to normal was setting "No aspect ratio correction" on. That seemed to fix that. But playing another disk later in the day I found now that was stretched to fill the screen... The solution to this was to set ffdshow output option "Set pixel aspect ratio in output media type" to off.

My settings now that work for evrything I have thrown at it are

Resize - Aspect Ratio - "No aspect ratio correction"
Output - "Set pixel aspect ratio in output media type" - "Off"
MPC-HC - "Video Frame" - "Keep aspect ratio"

I am happy with this now but I am wondering theoretically shouldn't the finished aspect ratio be correct in all situations.... with the AR flag being sent around the place shouldn't mpc-hc sort my aspect ratio out no matter what ffdshow does. I am thinking of other users in the future, with ffdshows default settings for me not working for all of my video types. Would be nice to see the ratio looking correct in all settings, with the player doing any final aspect ratio correct if needed based on correct flags being sent around.

EDIT: Damn, found another 4:3 clip that gets stretched to 16:9 in this combination... Can't find a combination of these 4 settings that just gives me the right aspect ratio.
Does this start at rev 2718? If yes, I may have to revert it.

[haruhiko_yamagata]

2732 - I can't enable the overlay control. Is anyone else seeing this? It's never been a problem in previous builds.
Thanks for quick feed back. I have fixed at rev 2733.

[mark0077]

Does this start at rev 2718? If yes, I may have to revert it.

I will get an older version when I get home to test. I can't find a combination that works in all types of video I play so it may have caused the problem I see. Will confirm in a few hours.

[ikarad]

I see a bug with ffdshow-mT.
In some blu-ray there is some bugs of decompression (or decoding)

screenshot here
http://nsa05.casimages.com/img/2009/02/18/mini_090218114945228794.jpg (http://www.casimages.com/img.php?i=090218114945228794.jpg)

sample here
http://www.zshare.net/info.html?55808118-1186c8d37659ccdc7c113ea973577df5

video captured by fraps to show this bug
http://www.zshare.net/info.html?55808947-2327e7dd24f9e7c0fc51bbeac433d69b

bugs appear between 1min40 and 1min45

- With ffdshow not MT, there isn't this bug.
- With H264 codec of MPC-HC there isn't this bug.
- If in ffdshow-Mt, I select 1 in the number of decoding threads (only 1 core used) there is no bug. If I select 2,3 or 4 there is the bug
http://nsa05.casimages.com/img/2009/02/18/mini_090218120751123616.jpg (http://www.casimages.com/img.php?i=090218120751123616.jpg)

I notice that this bug appear only with blu-rays at 29.970 fps but I am not very sure because I don't have many blu-rays to test (with blu-rays at 24fps, I have never seen this bug)

My config:
Q6600 (quad core), gtx280, xp sp3,ffdshow-mt2694 or 2733

up!
thanks

[~bT~]

^ which version of ffdshow??

[ikarad]

^ which version of ffdshow??

ffdshow-mT 2694

[STaRGaZeR]

The changes made in rev2720 are supposed to affect the release builds or just the debug builds? Being able to change some settings in real time was really useful and I didn't experience any crashes.

[~bT~]

ffdshow-mT 2694

an update overdue?

http://www.xvidvideo.ru/content/category/1/4/5/

[ikarad]

an update overdue?

http://www.xvidvideo.ru/content/category/1/4/5/

I try the last version 2733, and the same problem exists.

This problem exists since the first release of ffdshow-mt project.

https://sourceforge.net/tracker2/?func=detail&aid=2612226&group_id=173941&atid=867360

[Shakey_Jake33]

^On that note, what's the difference between the standard x64 build, and the one built using VS2008? It's presumably significant enough for XvidVideo to continue doing 2 separate builds.

[clsid]

We all use VS2008 for most files. So I think it is about libavcodec.dll. GCC is used for that by default. VS2008 builds of it will have much worse performance.

[clsid]

Someone reported to me that ffdshow crashes WMP and Vista Media Center when "raw video" is enabled. Can anyone confirm that with a recent build? I am typing this on a XP box.

[yesgrey]

@clsid,
What happened to your ffdshow changelog link? Now the changelog does not appear...

[clsid]

I have changed it back. Does anyone know if it is possible to show only the last X log entries through the web interface?

[yesgrey]

I have changed it back.
Thanks.

[Leak]

I have changed it back. Does anyone know if it is possible to show only the last X log entries through the web interface?
I'm afraid not; as far as I have groked the ViewVC docs you *can* configure it to split the log into pages of a user-set size, but it will always read the whole log anyway and only return what's on the page you requested, so if you're trying to keep the server load down that's not going to work.

I suppose you could make a static page that shows, say, the last 100 log entries by setting up a post-commit hook (if that's possible on SourceForge) that runs a "svn log" command, pretties the result up a bit and writes that into said static file...

[Jeremy Duncan]

Playng the ntsc movie ' Blade Trinity' , and using float32 on the input and output. The first screen of the movie and after that would have a loud noisy snow sound that was very loud and you could not hear the movie.

I wonder if checking the float32 input and output works on some ntsc movies but not on others like blade trinity?

[rickardk]

Someone reported to me that ffdshow crashes WMP and Vista Media Center when "raw video" is enabled. Can anyone confirm that with a recent build? I am typing this on a XP box.

Confirmed. It does crash both WMP and VMC under Vista.
Also WMP11 on XP.

[dandy]

I still can't get ffdshow working in a push mode graph with ms mpegdemultiplexer

yes - I belong to this DVB crowd - sorry

MPEG 2 broadcasts -> libmpeg2 works fine (THANKS FOR THAT), libvacodec connects ok but no picture
H264 broadcasts (BBC HD / ITV HD) -> libvacodec and ffmpeg-mt connect ok but for both no picture

thanks

[albain]

Confirmed. It does crash both WMP and VMC under Vista.
Also WMP11 on XP.

Hi,

this means that I didn't fix the bug completely (or at all)
Haruhiko identified it on the colorspace from the input decoder that was not copied back into FFDShow colorspace converter.

I thought this was fixed because I had no more crash until I tried recent builds on another machine.

I will have a look at this

Damien

[B.F.]

Hi.
Any chance to someone fix not working postprocessing filter in ffdshow virtual dub and avisynth plugins?

[albain]

Confirmed. It does crash both WMP and VMC under Vista.
Also WMP11 on XP.

Hi rickardk,

crashes should not occur on Windows XP WMP11, because I don't use the compatible codec feature.
The regression appeared on Vista and and in XP but only with Media Center, not media player.

Do you confirm the crashes on this OS with WMP11 too ?

Thanks

Regards
Damien BT

[Leak]

Hi.
Any chance to someone fix not working postprocessing filter in ffdshow virtual dub and avisynth plugins?
How? Those filters depend on having the quantizer values for each macroblock, which only works if ffdshow is doing the actual decoding...

[rickardk]

Hi rickardk,

crashes should not occur on Windows XP WMP11, because I don't use the compatible codec feature.
The regression appeared on Vista and and in XP but only with Media Center, not media player.

Do you confirm the crashes on this OS with WMP11 too ?

Thanks

Regards
Damien BT

Maybe ffdshow is not to blame. But WMP11 under XP does crash using CoreAVC (v1.9) with latest build 2719 of ffdshow.
It does not crash using an earlier version of ffdshow (like ffdshow ~b2100).

[albain]

Maybe ffdshow is not to blame. But WMP11 under XP does crash using CoreAVC (v1.9) with latest build 2719 of ffdshow.
It does not crash using an earlier version of ffdshow (like ffdshow ~b2100).

I am pretty convinced that FFDShow is in fault, but that may be another bug...

[albain]

I think I have fixed the crash problem (revision 2735).

It seems that when an alternate codec is used (so FFDShow receives uncompressed stream), the output colorspace is not set (= 0) which makes it crash on ocsps.sort(pictOut.csp) (Tffdecoder.cpp:298).

Haruhiko, maybe you have a clue on this ?

EDIT : nice tool dbgview by the way, I was actually writing traces to a file which was not practical at all

Damien

[turbojet]

libavcodec and wmv9 can't decode this 1080i VC-1 clip (http://www.sendspace.com/file/s07gpn) or any of the other 6 1080i VC-1 clips from 300 (USA BD). Latest cyberlink handles it ok.

[Kurtnoise]

iirc, lavc doesn't support vc-1 interlaced streams...

[B.F.]

How? Those filters depend on having the quantizer values for each macroblock, which only works if ffdshow is doing the actual decoding...
I worked before, on any source. :confused:
Maybe some fake quantizer value helps?

[avivahl]

Small question... I've installed ffdshow_rev2738_20090303.exe (from XvidVideo.ru) on a clean Vista x86 SP1 machine.
I used defaults in the installation.
Then, I went to the Mixer part of the Audio Configuration and noticed that Normalize Matrix is OFF by default.
When pressing the Reset button, it was turn ON.

So... my question is what is/should be the default value for the Normalize Matrix? ON or OFF?

[avivahl]

And a new bug I've noticed that has to do with the Presets of the Video Configuration.
I use ffdshow to show Subtitles and always have 2 presets:
1st- Default. Subtitles are on.
2nd- Called "NoSubs". Subtitles are off. Automatically loaded when SubtitleWorkshop.exe is using ffdshow.

My steps to setting up everything:
- Install ffdshow.
- Configure "default" preset.
- Create new preset from "default" (it sets the new preset name to be "default1").
- Rename "default1" to be called "NoSubs" and configure it to be autoloaded w/ SubtitleWorkshop.
- Turn subtitles off in "NoSubs.

Everything seemed to be fine w/ the new revision, but when I restarted ffdshow it had 3 presets: "default", "default1", and "NoSubs"!
Any try to delete "default1" removes it from the list... but when I restart ffdshow it shows back up!

The bug: ffdshow fails to correctly delete presets and creates a new one when a preset is renamed.

Avi Vahl.

EDIT: If I manually delete HKEY_CURRENT_USER\Software\GNU\ffdshow\default1, this preset won't show up again... (until the next time I'll create/rename a preset?)

[haruhiko_yamagata]

I think I have fixed the crash problem (revision 2735).

It seems that when an alternate codec is used (so FFDShow receives uncompressed stream), the output colorspace is not set (= 0) which makes it crash on ocsps.sort(pictOut.csp) (Tffdecoder.cpp:298).

Haruhiko, maybe you have a clue on this ?

EDIT : nice tool dbgview by the way, I was actually writing traces to a file which was not practical at all

DamienpictOut.csp must be set correctly. Revision 2735 just avoids crashing there. Hope you can fix this.

[Jeremy Duncan]

that audio problem i had with float 32 went away when i changed it for 32 bit integer.
I'm using version 2734

[haruhiko_yamagata]

And a new bug I've noticed that has to do with the Presets of the Video Configuration.
I use ffdshow to show Subtitles and always have 2 presets:
1st- Default. Subtitles are on.
2nd- Called "NoSubs". Subtitles are off. Automatically loaded when SubtitleWorkshop.exe is using ffdshow.

My steps to setting up everything:
- Install ffdshow.
- Configure "default" preset.
- Create new preset from "default" (it sets the new preset name to be "default1").
- Rename "default1" to be called "NoSubs" and configure it to be autoloaded w/ SubtitleWorkshop.
- Turn subtitles off in "NoSubs.

Everything seemed to be fine w/ the new revision, but when I restarted ffdshow it had 3 presets: "default", "default1", and "NoSubs"!
Any try to delete "default1" removes it from the list... but when I restart ffdshow it shows back up!

The bug: ffdshow fails to correctly delete presets and creates a new one when a preset is renamed.

Avi Vahl.

EDIT: If I manually delete HKEY_CURRENT_USER\Software\GNU\ffdshow\default1, this preset won't show up again... (until the next time I'll create/rename a preset?)
Probably I have added this bug recently. I'll take a look.

[Superlanboy]

Probably I have added this bug recently. I'll take a look.

Yeah I got this bug as well. Only way to get rid of those other presets was by deleting their corresponding registry keys.

[Inventive Software]

Any recommendations as to whether ffdshow-tryouts is ready for a beta 7? There's been a LOT of big changes recently, both in ffmpeg and ffdshow-tryouts that could warrant a new beta.

[clsid]

There are a few regressions that must be fixed first. It is not yet the right moment for a new beta.

[avivahl]

Probably I have added this bug recently. I'll take a look.
Thanks. :)

[mark0077]

haruhiko_yamagata

Just coming briefly back to my issue with dvd menu placement and aspect ratio problems.

It seems the problem with the menu positioning is NOT the mpeg2 ffdshow decoders, its something ffdshow itself is doing. Even if I do use the mpeg2 decoder within mpc-hc and have ffdshow in the chain doing nothing, the menu highlights come out in the wrong places. The moment I disable ffdshow from the chain, the problems are gone again, perfect menu positioning. I think originally we / you thought it was some decoding code / mmx within ffdshow causing the weird placement of the highlights.

------

I can also confirm your recent work on the aspect ratio output has broken something.

With a 4:3 source
"Set pixel aspect ratio in output media type" off + resize off = aspect ratio is correct.
"Set pixel aspect ratio in output media type" semi-checked + resize off = wrong aspect ratio (looks like 16:9)
"Set pixel aspect ratio in output media type" off + resize on + "no aspect ratio correction" on = wrong aspect ratio (looks like 16:9).
"Set pixel aspect ratio in output media type" off + resize on + "keep original aspect ratio" on = aspectio ratio is correct

Shouldn't every combination of these result in the visible AR being correct as the AR flags get sent to the next item in the chain. This would be a good test to see if changes you make work, ie try as many combinations of the resize options, and "set pixel aspect ratio....." option to see if they all correctly give the same final AR on maybe 4:3 and 16:9 material for a start.

------

Now that I can confirm the menu positioning problem is not decoder related, but something else in ffdshow, maybe both of these are related :D

[v0lt]

Hi!

My fix reg_formats.iss (look attach file)

Fix registration Div3 in VFW.

[turbojet]

iirc, lavc doesn't support vc-1 interlaced streams...

Ya I've heard this before too, I mainly wanted to provide (another) sample to help them with development if they are planning on supporting it, anyone know?

This sample is kind of a special case because not even wmv9 decodes it properly. I've heard of other streams where this is the case from the BD-RB thread but I haven't seen any clips posted.

[ikarad]

I see a bug with ffdshow-mT.
In some blu-ray there is some bugs of decompression (or decoding)

screenshot here
http://nsa05.casimages.com/img/2009/02/18/mini_090218114945228794.jpg (http://www.casimages.com/img.php?i=090218114945228794.jpg)

sample here
http://www.zshare.net/info.html?55808118-1186c8d37659ccdc7c113ea973577df5

video captured by fraps to show this bug
http://www.zshare.net/info.html?55808947-2327e7dd24f9e7c0fc51bbeac433d69b

bugs appear between 1min40 and 1min45

- With ffdshow not MT, there isn't this bug.
- With H264 codec of MPC-HC there isn't this bug.
- If in ffdshow-Mt, I select 1 in the number of decoding threads (only 1 core used) there is no bug. If I select 2,3 or 4 there is the bug
http://nsa05.casimages.com/img/2009/02/18/mini_090218120751123616.jpg (http://www.casimages.com/img.php?i=090218120751123616.jpg)

I notice that this bug appear only with blu-rays at 29.970 fps but I am not very sure because I don't have many blu-rays to test (with blu-rays at 24fps, I have never seen this bug)

My config:
Q6600 (quad core), gtx280, xp sp3,ffdshow-mt2694 or 2733

I have the same problem with ffdshow-MT 2744.
The update of ffmpeg-mt doesn't change the problem.

[georgevalkov]

The ffdshow video encoder DirectShow filter is broken. When I try to encode any video source to any format (I tested H264 and Xvid), ffdshow encoder indicates:
Frames encoded:0; FPS:0; kbps:0...

GraphEdit indicates Play, but is not using any CPU resources. If I try to interrupt the encoding, GraphEdit will freeze for 10 seconds and show an error:
The graph was unable to complete pause within 10 seconds.
Press Retry to wait another 10 seconds for completion
or Cancel, to attempt to stop the graph.

This version works properly:
ffdshow_rev2477_20081211_clsid_sse_icl10.exe

This and some versions before it are broken (I don't know since when):
ffdshow_rev2744_20090305_clsid.exe


Please see the composited screen shot!


PS:
ffdshow Video Codec works properly in VirtualDub with the same source and destination formats and settings. I guess that only the DirectShow version is broken.

[alexins]

Hi!

My fix reg_formats.iss (look attach file)

Fix registration Div3 in VFW.

I think, need to do so:

Index: bin/distrib/InnoSetup/reg_formats.iss
===================================================================
--- bin/distrib/InnoSetup/reg_formats.iss (revision 2744)
+++ bin/distrib/InnoSetup/reg_formats.iss (working copy)
@@ -371,6 +371,7 @@
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "mp4v"; ValueData: "0"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: NOT video\mpeg4
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "xvid"; ValueData: "0"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: NOT video\xvid

+Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "div3"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\divx
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "ffv1"; ValueData: "1"; Components: ffdshow\vfw
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "fvfw"; ValueData: "1"; Components: ffdshow\vfw
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "h264"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\h264\libavcodec
@@ -379,12 +380,12 @@
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "mp42"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\mpeg4
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "mp43"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\mpeg4
#if include_xvidcore
-Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "div3"; ValueData: "9"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\divx
+;Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "div3"; ValueData: "9"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\divx
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "dx50"; ValueData: "9"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\divx
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "xvid"; ValueData: "9"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\xvid
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "mp4v"; ValueData: "9"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\mpeg4
#else
-Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "div3"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\divx
+;Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "div3"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\divx
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "dx50"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\divx
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "xvid"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\xvid
Root: HKLM; Subkey: "{#= ff_reg_base}_vfw"; ValueType: dword; ValueName: "mp4v"; ValueData: "1"; Components: ffdshow\vfw; Flags: createvalueifdoesntexist; Tasks: video\mpeg4

[clsid]

I have the same problem with ffdshow-MT 2744.
The update of ffmpeg-mt doesn't change the problem.
There is no need to continually repeat your problem.

[avivahl]

The "delete preset" bug is now fixed. :-)
what about the default value (http://forum.doom9.org/showthread.php?p=1257021#post1257021) for the Normalize Matrix? Anybody knows?
And guys... could you please add "16:10" to the drop down box in the subtitles' letterbox option? Most wide computer screens have 16:10 native resolutions.

[ikarad]

There is no need to continually repeat your problem.

why?
I though that the recent update of ffmpeg-mt corrected this problem.

[clsid]

Unless the SVN changelog specifically mentions a fix, it is unlikely that an existing problem was fixed.

[Snowknight26]

I've got some 2.0 channel AC3 Surround files that eac3to identifies as such, but when I play them with ffdshow, it says the input is 6-channel AC3. Normal?

Sample: http://stfcc.org/misc/threekings.ac3

[georgevalkov]

I've got some 2.0 channel AC3 Surround files that eac3to identifies as such, but when I play them with ffdshow, it says the input is 6-channel AC3. Normal?

Sample: http://stfcc.org/misc/threekings.ac3

I don't understand much about AC3, but If I feed the built-in decoder of the my X-fi card, it will play more like a 6 ch. sound (the card was in 5.1 mode when I made the test). I used an AC3 decoder from Cyberlink configured in AC3 pass through mode; the sound card was configured to decode AC3 bit streams to analogue sound.

Graphedit indicates 2 channels, but all of the 6 speakers play different sounds.

[albain]

In the future DirectShow support will be dropped (actually I think that it will be still supported but without updates)

In Windows 7 Microsoft integrates a divx decoder which is coded with Direct Media Foundation, the replacement of DirectShow.
So no possible subtitles, postprocessing... with MPEG4 formats.
Same thing with H264

This is annoying because DirectShow filters have no way to override or replace any DMF codec because they deal with a separate merit.

In Vista this was not a problem because only mp3 and MS codecs was integrated into DMF. But now the most commonly used codecs are migrated to Direct Media.

MS claims that DMF is better for High Definition, tearing and streal synhcronization. Personnally I don't share this opinion but the things are that in the future DirectShow will disappear.

Looking at the samples, DMF coding seems simpler than DirectShow, but the cost of transcoding FFDShow to DMF seems very high considering the high level of customtization of FFDShow. If someone has leads, I don't know maybe it is possible to develop a generic DMF filter that would call or encapsulate FFDShow ?

Just want to raise a debate

Damien

[clsid]

ffdshow currently is one big entangled mess with an eroded architecture. My suggestion would be to start new filter from scratch. That would have several advantages:
- It does not interfere with development of current ffdshow.
- Should result in clean code with a better architecture.
- Allows separation of audio and video into two filters.


I have tested Windows 7 and the MS DMO decoders work fine in DirectShow players. The MS decoder even works with DXVA in MPC-HC. Subtitles work as well.

[RadScorpion]

If the "directshow ffmpeg" project is to be reborn I'd suggest making multiple filters - not one big superfilter.
That way all features (encoder/decoder) could be used or configured in much simpler way. The biggest problem with ffdshow is its evil interface. It has a nice GUI, but making it do simple task like resize into specified resolution is a pain in the ass.

Also the video/audio processing stuff might be separated completely.

[georgevalkov]

In the future DirectShow support will be dropped (actually I think that it will be still supported but without updates)
Albain, I think it's okay if you don't want to update or support the DirectShow functionality of ffdshow, but please don't remove it! And Please restore the ffdshow encoder filter (see my post #6807 (http://forum.doom9.org/showthread.php?p=1258405#post1258405)).

I've used Windows 7 beta for a few weeks, seems better than Vista. I like it, however the interface does not respond in real-time. Both Vista and Windows 7 have good new features, but in the end it's just an OS - Users want to run their programs and manage their documents.

So consider the fact that there are still a lot of people using windows XP. I don't know if it supports DMF, but it will probably be better to keep the DirectShow functionality, even if not updated.

I suggest that a second DMF component may be added to complement ffdshow (together in the same installer). In the part of it's development it's functionality will increase as more parts from the original ffdshow project are added to it. It's not a single step but a long process.

I think it will be a bad idea to separate the ffdshow developers on the two variants (DirectShow vs. DMF) - this will make you weaker.



This is annoying because DirectShow filters have no way to override or replace any DMF codec because they deal with a separate merit.
An application can still add ffdshow to the graph and use it. It's better than nothing (for now) ;)

MS claims that DMF is better for High Definition, tearing and streal synhcronization. Personnally I don't share this opinion but the things are that in the future DirectShow will disappear.
Could be true or no quite?! I don't take anything from them for granted, until I try it. They also said that Vista is faster. Hm :devil: If I use Win 2008 or Win 7 for some time and than switch back to the Win 2003 installation, my computer really speeds up a lot :cool:

Looking at the samples, DMF coding seems simpler than DirectShow, but the cost of transcoding FFDShow to DMF seems very high considering the high level of customtization of FFDShow. If someone has leads, I don't know maybe it is possible to develop a generic DMF filter that would call or encapsulate FFDShow ?

Just want to raise a debate

Damien

Is DMF supported on Win 2003 or XP? Anyway, c++ codding and multimedia are only my hobby, I'm studying electronics.

One thing I learned from the HTML codding is to separate code design and data. The basic idea is to create a common way for adding DSP filters and formats to the ffdshow project. Something like the plug-in architecture model, except that the whole project is compiled together in the end.

~ The main part has to be fast and simple;
~ Each DSP filter appends itself to a list of effects;
~ Each format appends itself to a list of codecs.
~ Each effect and codec is independent from the other; can be added or removed from the project, without breaking it. E.g.
add a .cpp file to the project; it registers at run-time (so that the main code knows about it) and is ready to use.
~ Multiple instances of one and same effects can be pipelined together with other effects. Multiple threads can be used for pipelined effects to better utilize multi core CPUs.

[Leak]

Albain, I think it's okay if you don't want to update or support the DirectShow functionality of ffdshow, but please don't remove it!
Errr... he was saying that in the future DirectShow support in Windows will be dropped *BY MICROSOFT*, not by ffdshow...

[haruhiko_yamagata]

ffdshow currently is one big entangled mess with an eroded architecture. My suggestion would be to start new filter from scratch. That would have several advantages:
- It does not interfere with development of current ffdshow.
- Should result in clean code with a better architecture.
- Allows separation of audio and video into two filters.


I have tested Windows 7 and the MS DMO decoders work fine in DirectShow players. The MS decoder even works with DXVA in MPC-HC. Subtitles work as well.
I'm bit tired of coding for mainstream of ffdshow and playing with subtitles. It's mainly cleaning of the code as I can't code any further without cleaning it. Cleaning code is easier than writing code from scratch. My new code isn't clean enough, but it's just my skill.
However, as for me, I'm not motivated enough to code for MF for now. I'm already overwhelmed enough.

[albain]

I agree, but I would like to know how huge is the work to port FFDShow to become "FFDMF".

So I am willing to give it a try (locally on my side first), of course it will take time.

Too bad that MS has not delivered a DirectShow to DirectMedia developers guide.

This is the reason why I was asking this : if there is any material (code, documentation) to begin with, I would be more motivated to begin with.

I think that there are lots of similarities between DirectShow/DMF, most work (I am probably naive) would be to reconnect the old methods with the new ones.

Before talking about splitting project or anything, it would be great that I could adapt current code. First thing would be to make FFDShow compile with windows SDK 7.0, which is not the case for now.

[tetsuo55]

How is windows 7 backwards compatible with DirectShow?
Does it emulate it through MediaFoundation?

I fully agree that the move to MediaFoundation should be made sooner than later.

Like clsid said it might be a better idea to start a new version for MediaFoundation.
What it needs is a better framework, designed to do everything we want now and in the future. Then we can plug existing ffdshow code into the framework and update that later. (like mame)

[albain]

Yes WMP and WMC emulate DirectShow but I don't know if this emulation is based upon DMF or works in parallel

[Inventive Software]

I agree, but I would like to know how huge is the work to port FFDShow to become "FFDMF".

So I am willing to give it a try (locally on my side first), of course it will take time.

Too bad that MS has not delivered a DirectShow to DirectMedia developers guide.

This is the reason why I was asking this : if there is any material (code, documentation) to begin with, I would be more motivated to begin with.

I think that there are lots of similarities between DirectShow/DMF, most work (I am probably naive) would be to reconnect the old methods with the new ones.

Before talking about splitting project or anything, it would be great that I could adapt current code. First thing would be to make FFDShow compile with windows SDK 7.0, which is not the case for now.

DMF is a completely different framework to DirectShow. The fact ffdshow (the name implies it) is based around DirectShow only serves to show how big the task is. Not to mention, ffdshow also includes a VFW decoder/encoder, which should ideally be separate from ffdshow.

In a totally ideal ffdshow world, the following elements of ffdshow would be separate:

video decoder,
post-processing,
post-filtering,
audio decoder,
subtitle decoder,
VFW encoder/decoder.


Anybody else wanna add things to it, feel free.

If we could have it, along with possibly taking some more ffmpeg components, the libavformat splitter/parser would be a separate entity too. It would make ffdshow a more complete codec with it, but granted the core philosophy of it is that it's a decoder, not a parser.

[albain]

Here are some interesting information I got from MS :

Link to original post (http://social.msdn.microsoft.com/Forums/en-US/mediafoundationdevelopment/thread/0eb66fc9-6cf2-4f6e-b575-9739d36bc643/?ffpr=0)

The Media Center TV application still uses DirectShow. It might also use Media Foundation for certain tasks, but for live and recorded TV, it uses DirectShow.

I don't have a document that describes how to port a DirectShow filter to Media Foundation. (This is a good idea though.)

In the specific case of a decoder filter, you'll want to implement a Media Foundation Transform. Here are some things to consider:


Understand the new media type API. There are some conversion functions to convert between DirectShow and MF types.
The MFT data processing model is very similar to the DMO model.
A DirectShow filter typically delivers an output sample inside its Receive method. For an MFT, input and output are distinct steps. The pipeline will call ProcessInput to give you an input sample, and will call ProcessOutput to get an output sample from the MFT. It may call these two methods in any order, so the MFT must return error codes indicating "need more input" or "not ready to receive input"; these are documented in the IMFTransform documentation.
End-of-stream and flushing are indicated through the IMFTransform::ProcessMessage method.
Discontinuities, key frames, and per-frame interlacing are indicated through media sample attributes.
An MFT does not have to worry about run, pause, and stop states.
If you support DXVA, read Supporting DXVA 2.0 in Media Foundation.
The MFT_Grayscale sample in the SDK shows a simple video effect. You can use this as a starting point. It shows type negotiation, the basic processing model, and MFT registration.

Hopefully this is enough to get started. Let me know if you have more questions.

- Mike

[Jeremy Duncan]

ffdshow currently is one big entangled mess with an eroded architecture. My suggestion would be to start new filter from scratch. That would have several advantages:
- It does not interfere with development of current ffdshow.
- Should result in clean code with a better architecture.
- Allows separation of audio and video into two filters.


I have tested Windows 7 and the MS DMO decoders work fine in DirectShow players. The MS decoder even works with DXVA in MPC-HC. Subtitles work as well.

In that post to msdn albain made. Microsoft said it's intention is to erase the use of direct show in time.
"the goal is that Media Foundation will replace DirectShow in the long term."

And Albain said he was gonna try and port ffdshow to directshows replacement with a new unnamed project.

So I humbly ask you to help him.
Maybe start a new thread so you and him can discuss this and get it going.

[albain]

Thank you but not so fast, I am not sure that I won't give up.

For now I am trying to integrate a new DMO filter inside FFDShow based on existing classes.

I will get back to you when I will have come to something that (nearly) works.


Advancement so far :

Like Haruhiko said earlier, it is always easier to modify existing code rather than create a new one from scratch.
So this is what I am trying to do. It is possible to make a directshow and DMO filters coexist with some adaptations

ffdhow.ax now contains existing directshow filters + a DMO decoder (that decodes nothing for now).

[mrcorbo]

If we could have it, along with possibly taking some more ffmpeg components, the libavformat splitter/parser would be a separate entity too. It would make ffdshow a more complete codec with it, but granted the core philosophy of it is that it's a decoder, not a parser.

I think that a libavformat-based Media Source object for WMF would be a worthy project on its own. It would certainly make a potential ff(wmf?) much more useful.

[Mtz]

clsid, I tested ffdshow_rev2754_20090310_clsid with a .ts file from here: http://rapidshare.com/files/206456698/TVR_HD.ts and the decoding is broken.
With some previous version was working and also I tested with ffdshow_rev2734_20090301_xxl.exe and is working OK.

enjoy,
Mtz

[clsid]

Please test rev2744 as well
http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_rev2744_20090305_clsid.exe

Your file is working here. So please give a more specific definition of 'broken'.

[Mtz]

I think the problem is in libavcodec.dll.
In attachment are 4 screenshots. The name of the files represent the number of ffdshow releases.
Sorry for not taking the screenshot at the same frame, but with the buggy versions all frames are bad decoded so the frame number is not important.
http://www.sendspace.com/file/rtzn6m
Latest Haali used.

enjoy,
Mtz

[mark0077]

Guys is there a problem with vc-1 playback using the ffdshow vc1 libavcodec decoder.

Watching a 1080p movie using the internal decoder I am getting 50% of my frames shown 50% dropped. Using mpc-hc internal decoder I get 100% drawn.

Just surprised. I am using ffdshow 32bit 2754 with just rgb color conversion enabled. Using 1080p .ts file.

[Inventive Software]

What's your CPU usage? What happens when you don't have RGB conversion?

[mark0077]

CPU Usage is 15% (Core i7 @ 4ghz). Just restarted the video again and now I am losing approx 20% of frames and slowly seems to calm down to not dropping as many.

RGB Conversion doesn't have any effect. Just now out of 500 frames, I lost 47 which isn't too bad, but using mpc-hc I lose 0, perfectly smooth.... It actually took alot of effort on my part to get mpc to drop even 1 frame.... but it definitely does show dropped frames. Got it to drop 3 now with some high cpu usage in other apps. ;)

Maybe some ffdshow code is dropping frames unnecessarily... not sure whats wrong. I have a very simple setup.

I was hoping to move to ffdshow decoders rather than mpc-hc's ones because of the bad communication between the two regarding interlaced flags. Decoding in ffdshow for the moment seems to have advantages at least with DVD playback and crashing / freezing with de-interlacing.

[clsid]

Fixed the interlaced H.264 bug in revision 2768.


Mark, does it make a difference if you uncheck "Drop frame on delay" on the decoder options page in ffdshow settings?

[leeperry]

guys, small question please :)

Seb.26(an occasional ffdshow coder) told me that ffdshow couldn't resize horizontally while retaining AR....Haruhiko told me that it wasn't true.

so here's a real world example : a 672x384 AVI file w 7/4 DAR

resized to 1024*768 w/ these settings :

http://www.image-load.eu/out.php/t152284_ffd.jpg (http://www.image-load.eu/out.php/i152284_ffd.jpg)

yet Info() in the Avisynth filter shows : 1022*584, which is not mod4....and none of my scripts work because of that :(

is there a way to force ffdshow to actually resize to 1024*585 or 586 :confused:

if I force 1.78 AR in ffdshow, then it is 1024*576....

[Mtz]

I think the problem is in libavcodec.dll.
In attachment are 4 screenshots. The name of the files represent the number of ffdshow releases.
http://www.sendspace.com/file/rtzn6m
Latest Haali used.

The bug from: 0305_clsid.jpg and 0310_clsid.jpg is solved in the ffdshow_rev2768_20090313_clsid release.
Maybe that .ts capture have some bugs because sometimes is dropping about 25-45 frames from ~650 frames. But not always.

enjoy,
Mtz

[mark0077]

Fixed the interlaced H.264 bug in revision 2768.


Mark, does it make a difference if you uncheck "Drop frame on delay" on the decoder options page in ffdshow settings?

Hi clsid, yes unchecking that does stop most of the dropping of frames. I still get a few hundred frames dropped, but mostly at the start of playback then it settles down to no dropped frames.

Unchecking this option also fixed some dropped frames I was having when using the mpc-hc decoder in certain situations. Now using the mpc-hc decoder I am getting 0 dropped frames. Just wondering why ffdshow drops so many frames at the beginning of playback, and.... well if this drop frame setting is buggy in general. Its doing a fine job disabled.... I wonder if mpc-hc is doing some sort of buffering of frames, does ffdshow think the frames wern't "drawn" yet and .... start dropping frames. I don't know I will leave it to you guys ;)

[Mirabel]

Hello, I'm sorry but I don't now if I ask sth. stupid or if this is really a problem.

I used ffdshow-mt (I speak about the time before the builds were merged) and noticed that "NV12" in the colorspaces wasn't checked. I activated it and now ffdshow(-mt) used NV12 as output color space.

After the builds were merged, ffdshow started to use YUY2. I unchecked YUY2 and it used a different space but not NV12.

http://img147.imageshack.us/img147/103/ffd1.png

I decided not to try to enforce NV12 cause to my eyes there was something wrong. No my color spaces config looks like this:

http://img12.imageshack.us/img12/1995/ffd2.png

I'm using an ATI Mobility Radeon HD 2400, the drivers should be up to date. Windows Vista 32.
At the moment my ffdshow build is ffdshow_rev2768_20090313_sse_icl10.

Questions:

- What's going on?
- Is this a bug?
- Does NV12 have any advantages about YUY2? If that's not the case, I do not mind what's happening.

Thanks.

[georgevalkov]

Fixed the interlaced H.264 bug in revision 2768.

Hi clsid!
There is a bug in the 'ffdshow video encoder' filter.

To reproduce:
1. clean install ffdshow_rev2768_20090313_clsid.exe
2. Try to encode some video source,
http://www.mediafire.com/file/jd5bwcmmymm/RGB24.avi.7z
add the 'ffdshow video encoder' to GraphEdit (I used the default configuration - MPEG-4 encoder, but any other including uncompressed will fail too).
3. Connect the input of the filter and open the properties on the 'Out' tab.
4. Preferred media types indicate:
Major Type: Video - Sub Type: {0020002C-0000-0010-8000-00AA00389B71} - Format: RGB 16777216x524712, 8 bits
rcSrc=(0,0,917546,524720)
rcDst=(0,0,917546,524720)
Major Type: Stream - Sub Type: None - Format: None


This strange format seems invalid and unsupported by any other filter. Could be some uninitialized variable?

5. Replace the 'ffdshow video encoder' with the 'ffdshow Video Codec' and connect the input. Open the properties on the 'Out' tab.
6. Preferred media types indicate:
Major Type: Video - Sub Type: {44495658-0000-0010-8000-00AA00389B71} - Format: XVID 640x480, 24 bits
rcSrc=(0,0,0,0)
rcDst=(0,0,0,0)


7. Connect 'ffdshow Video Decoder' and 'Video Renderer' to decompress and preview the encoded frames.
8. Click Play: 'ffdshow Video Codec' works properly, but the 'ffdshow video encoder' filter needs to be fixed.

Please help!

edit: fixed after rev2832. Thank You!

[georgevalkov]

- Does NV12 have any advantages about YUY2?

See this link for details about the YUV formats:
http://www.fourcc.org/yuv.php

NV12 and YV12 are 12 bit, decoding is faster (less CPU than YUY2 and UYVY - which are both 16 bit), but in NV12 and YV12 there is a more colour information loss, also I think they are not suitable for interlaced movies.

You may try to force only NV12 (uncheck the others) and see if the Video Renderer supports it.

[Mirabel]

See this link for details about the YUV formats:
http://www.fourcc.org/yuv.php

NV12 and YV12 are 12 bit, decoding is faster (less CPU than YUY2 and UYVY - which are both 16 bit), but in NV12 and YV12 there is a more colour information loss, also I think they are not suitable for interlaced movies.

You may try to force only NV12 (uncheck the others) and see if the Video Renderer supports it.

Thank you very much. Actually, I do not insist on NV12.

If anyone could tell me what - regarding the available color spaces in ffdshow - is the best choice as colorspace if I rather take quality instead of speed, I'd be really lucky. N.b.: I can't remember to have had contact with any interlaced video in all the years I used ffdshow. I use MPC-HC's internal decoders for DVDs.

I still wonder why the output color space was changed by ffdshow, I didn't changed anything but it moved from NV12 to YUY2.

[yesgrey]

I use MPC-HC's internal decoders for DVDs.

I still wonder why the output color space was changed by ffdshow, I didn't changed anything but it moved from NV12 to YUY2.
MPC-HC decoders output YUY2, so that's the reason you are getting YUY2 in ffdshow, it selects the nearest colorspace from the ones you have selected.

[Ger]

About the color space thing, this is the situation on my system with DVBViewer + ffdshow + Nvidia 8800GT + Vista32-SP1 and a live interlaced MPEG-2 DVB-S channel:

If I enable YUY2 in ffdshow, then YUY2 is used according to ffdshows extended tray info like in Mirabel's screenshots, however I can clearly see visible interlacing lines, so the hardware deinterlacing (no matter if it's auto or force bob) is not working properly.

If I disable YUY2 and leave NV12 as the only checked output color space in ffdshow, then the tray info says "NV21,VU" whatever that means, and there are no visible interlacing lines anymore, so now the hardware deinterlacing works.

[Richardw322]

Didn't know where else to put his, but I wanted to let everyone what happened here with Windows 7 Beta 7048 and FFDshow 2754 yesterday.

I had a day off, and I had downloaded the 7048 beta of Windows 7. I thought I would try it as it had built in h264 decoding, and I saw an article on how to play MKV files in Media C3enter. So, I thought I'd play a bit. Loaded Windows 7 7048, installed FFDshow and Haali Splitter, then a couple REG patches. Set up Media Center, (easy setup, busy program) and when I went to Videos there were the MKV files. And they played!!

I was playing just pieces of them, and I when I got to my DVD rip of Iron Man I started to notice it was "sputtering" badly. The sound was fine, but the video looked like everyone was doing the "Robot" (remember that dance?) I tried to get it to use FFDshow, and Media Center just kept using it's internal codec. At least I think it did, the FFDshow tray icon never showed up. Then I installed GBPVR and set that up. I set the preferred decoder in GBPVR to FFDshow and tried again. The same stutter, and no tray icon. I tried Media Player Classic Home Cinema and no stutter. (Using the internal codec). I tried forcing the merit on FFDshow to highest and still no FFDshow.

I think when Microsoft included the H264 codec they block all others in Windows from using any other codec for H264 playback on the computer, even third party software. I wish I had thought to try Graphedit to figure it out, but instead went to Beta 7022 (no H264 codec) and everything went back to normal. I smell a rat here.

[ikarad]

Fixed the interlaced H.264 bug in revision 2768.




H264 from blu-ray or not?
is-it for ffmpeg-mt or just ffmepg
What is the bug?

in the readme there is:
"Bugfix for revision 2744. Fixed decoding issue with interlaced H.264 video"


but with my blu-ray there is always a decoding issue that I reported here
https://sourceforge.net/tracker2/?func=detail&aid=2612226&group_id=173941&atid=867360

i would like to have a confirmation if it is the same thing.
If not, I'm sorry to disturb you.

[clsid]

Its the bug that was reported yesterday. Nothing else has been fixed.

[Mirabel]

MPC-HC decoders output YUY2, so that's the reason you are getting YUY2 in ffdshow, it selects the nearest colorspace from the ones you have selected.

In WMP I get YUY2 too. I assume WMP decodes to YUY2 too..?

[BatKnight]

Thank you very much. Actually, I do not insist on NV12.

If anyone could tell me what - regarding the available color spaces in ffdshow - is the best choice as colorspace if I rather take quality instead of speed, I'd be really lucky. N.b.: I can't remember to have had contact with any interlaced video in all the years I used ffdshow. I use MPC-HC's internal decoders for DVDs.

I still wonder why the output color space was changed by ffdshow, I didn't changed anything but it moved from NV12 to YUY2.
I've read somewhere that ATI Radeon owners benefit from NV12 over the other colorspaces.
I ticked NV12 only and it displays (NV21,VU). I've noticed that only NV12 enforces the Edge Enhancements and De-noise settings at the AVIVO tab inside Catalyst Center. All other colorspaces ignore those settings.

Bat

[mark0077]

Hi guys, especially those of you interested in colorspace conversion. Now that Beliyaal has discovered how to set the levels flag in the output type of mpc-hc, I had an idea.

Wouldn't it be beneficial to have colorspace conversion and levels conversion in yv12 itself, not just when converting to RGB.

So what I was thinking was the following config.

decoder outputs in yv12 or yuy2 -> ffdshow does colorspace and levels conversion ALSO within yv12 or yuy2 (not RGB) -> mpc-hc outputs with levels flag set correctly so drivers don't touch levels -> hardware de-interlace if necessary (sweeeeet) -> output to display

This would be excellent and would mean we can have the best of both worlds, the excellent hardware de-interlacers, aswell as levels and colorspace conversion done in ffdshow (yv12 with original colorspace and levels -> yv12 colorspace and levels corrected).

Do you think it would hard to change the current "RGB Conversion" area to something else like "Levels / Colorspace Conversion) instead and not be limited to just RGB :D

[clsid]

I might be wrong, but the flag Beliyaal was talking about is not usable by ffdshow afaik. It is a flag that is set by MPC when initializing its custom version of EVR.

[STaRGaZeR]

That flag is probably the one that tells the renderer the luma range of the source when feeding it with YUV data so it can convert it to RGB knowing the correct levels. The only sure thing is that if you're already feeding the renderer with RGB data that flag is useless as no conversion is done there.

[albain]

There is bug (my fault) since revision 2735 : with uncompressed streams + in Vista WMP or Media Center + and when alternate decoder is used (FFDShow acts as raw decoder), then no more crash but picture size in input is wrong so the picture is cropped.

I will work on it

Damien

[halsboss]

Hi, after a REALLY serious PC infection (causing good programs to try to connect to websites where my firewall says - "source port 1596 dest IP 205.234.175.175 dest port 80 which resolves to vip1.anycast.cachefly.com") I reformatted and locked it down more with Trend 2009 with "prevent unauthorized changes" turned on.

It blocks some programs with an error message "Program Library Injection" which it says is trying to "configure windows so that a DLL is automatically loaded by some or all of your applications". If I hadn't had settings change detection turned on in TREND I would never have known.

It appears that not installing ffdshow (from the ffdshow tryouts in sourceforge) in the first place gets rid of the "library injection" error in MPC and HCenc etc... Went back to using the plain (new) xvid and other individual reliable codecs.

Not at all saying it's the cause of the infection issue I had, however it does at least do away with the "library injection" matter. eg when I just try to run MPC.

Can someone please clarify what dll it's trying to "inject" ?

PS XP-sp3 fully updated

[Leak]

Can someone please clarify what dll it's trying to "inject" ?
Well, to figure this out I just built debug versions of MPC-HC and ffdshow-tryouts.

The only thing that happens on startup of MPC-HC is that it's capture dialog enumerates all VfW audio codecs on initialization, where it finds ff_acm.acm, which is a vfw audio decoder needed for files created with MakeAVIS to return sound.

That in turn loads ffdshow.ax since ff_acm.acm is only a tiny stub, and all ffdshow.ax does is to check if the process that's loading it is on the blacklist.

ff_acm.acm is a decoder only, so MPC-HC's capture dialog shouldn't even load it, but VfW has no mechanism to flag a codec as decoding only, so it gets loaded anyway and simply returns that it can't encode anything.

That's the only cause I can think of, but if your version of Trend Micro's crap stinks as much as the version I have to endure at work I wouldn't be surprised if that's really it.

So I think installing ffdshow without MakeAVIS support should fix the "problem", or if you do need MakeAVIS maybe you should just go ahead and tell your, errr, "watchdog" to shut up - after all, there's legitimate uses for "Program Library Injection" (is that what we call loading a DLL nowadays?) besides scaring it's users.

Also, I want the hour of my life that I've just spent on analyzing this back... :mad: (And no, I'm not going to infect my machine with a test version of "Trend soandso anything 2009" to figure out if that was really it, thankyouverymuch.)

np: The Fireman - Light From Your Lighthouse (Electric Arguments)

[halsboss]

Leak, THANKYOU for your work. I can't give you back your hour, but think of all the good karma due to you :) I think you just convinced me it's "OK".

I still have visions of credit card pins being used (given that coincidentally programs were starting connect to odd places on the web).

Thankyou once again.:thanks:

[Mirabel]

I've read somewhere that ATI Radeon owners benefit from NV12 over the other colorspaces.
I ticked NV12 only and it displays (NV21,VU). I've noticed that only NV12 enforces the Edge Enhancements and De-noise settings at the AVIVO tab inside Catalyst Center. All other colorspaces ignore those settings.

Bat

I also heard something like that, but to my eyes it looks as I'd get the AVIVO stuff in YUY2 too. Maybe I should do more testing.

Hi guys, especially those of you interested in colorspace conversion. Now that Beliyaal has discovered how to set the levels flag in the output type of mpc-hc, I had an idea.

Sorry for noob question, but how do you do it?

And I use EVR custom, since I'm on Vista.

[BatKnight]

I also heard something like that, but to my eyes it looks as I'd get the AVIVO stuff in YUY2 too. Maybe I should do more testing.
In fact, I've noticed that when I upgraded from Catalyst 8.12 to 9.2 those Advanced Quality settings of AVIVO no longer come effective no matter what colorspace you choose; not even NV12 :scared:
It's pretty anoying that you developers spend time fixing and adding new features and then ATI just break things on their drivers.

Bat

[mark0077]

I might be wrong, but the flag Beliyaal was talking about is not usable by ffdshow afaik. It is a flag that is set by MPC when initializing its custom version of EVR.

Yeah what I meant was not using the flag by ffdshow, but instead using the flag as a way to stop the graphics card doing any conversions when being sent non RGB.

So if we could do levels conversions in ffdshow without having to go to output in RGB, aswell as setting the flag in mpc-hc we can achieve two things

1) The graphic card won't do any conversion of levels as the flag is set.
2) We are still sending non RGB to the renderer so things like hardware de-interlacing are now possible :D

I think this is very reasonable.

[albain]

Some (minor) updates about Direct Media Object implementation within FFDShow :

from the following url (http://alax.info/blog/402) you can see that this is possible (and better) to implement a DirectShow+DMO filter, meaning that the filter handles both DirectShow and Direct Media Foundation interfaces.

This is what I am trying to do, it does not seem too difficult and there are much fewer modifications than developing a new filter from scratch.

[clsid]

What would be the benefit of having a DMO filter? I don't know of a player that supports DMO but not DirectShow. And WMP will most likely favor its own DMO instead of third party ones (even if those have higher merit). Would processing raw video become easier (without special workarounds) in WMP?

[Leak]

What would be the benefit of having a DMO filter? I don't know of a player that supports DMO but not DirectShow. And WMP will most likely favor its own DMO instead of third party ones (even if those have higher merit). Would processing raw video become easier (without special workarounds) in WMP?
Well, unless I misunderstood something MS is going to drop DirectShow somewhere down the line, so why not support DMO it early on?

And I'd hazard a guess that WMP simply tries DMO first, finds a suitable (built-in) decoder and simply doesn't try DirectShow at all...

[albain]

What would be the benefit of having a DMO filter? I don't know of a player that supports DMO but not DirectShow. And WMP will most likely favor its own DMO instead of third party ones (even if those have higher merit). Would processing raw video become easier (without special workarounds) in WMP?

Well, in Windows 7 as you can (or will) see, divx support is now integrated into DMO, as well as some other formats (wmv of course but also H264, and MP3 WMA for audio formats). I am not sure about MPEG1 & 2.

As a result, FFDShow cannot be used to decode divx/h264 within Windows Media Player and Windows Media Center, which is a big loss.

The only way to reverse this behaviour is a (heavy) hack : unregister MS DMO filters which breaks media center TV module.


So if everything works as I expect, FFDShow could support DMO interfaces and it should be possible to override (with higher merit) the standard DMO filters. Of course all of this is conditional and now I am facing some technical difficulties with the new SDK (v7 beta).

But you're right : if this is not possible to override the merit to use FFDShow instead of MS DMO filters or add FFDShow as raw decoder in output all of this is not worth it (it will just be useful for future versions of Windows with no directshow support).

[leeperry]

when the ffdshow installer detects my language, where does it get the info please ?
\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Nls\Language\ ?

I'd like to fake it so all programs believe I've got a US XP, but setting these keys to 0409 doesn't help :o

[Leak]

I'd like to fake it so all programs believe I've got a US XP, but setting these keys to 0409 doesn't help :o
I think the only way to really get that effect is to install an English version of Windows. At least that's what works for me at home.

Changing the regional settings of the German Windows XP I have at work doesn't work in that regard - I guess there's some OS function that returns which language version of Windows was installed.

np: Apollo 440 - Christiane (Dude Descending A Staircase (Disc 2))

[leeperry]

I think the only way to really get that effect is to install an English version of Windows. At least that's what works for me at home.

Changing the regional settings of the German Windows XP I have at work doesn't work in that regard - I guess there's some OS function that returns which language version of Windows was installed.
ok thanks for the confirmation, I've done some googling for like 1H before giving up and asking here :o
but where does the ffdshow installer get the info from?!

[clsid]

Well, unless I misunderstood something MS is going to drop DirectShow somewhere down the line, so why not support DMO it early on?Windows 7 still supports DirectShow, so we have got nothing to worry about for the coming years.

I am not against adding a DMO interface. But if it brings no benefits, then it would be a waste of time.

[e-t172]

I'm experiencing some strange performance problems with the Avisynth filter in ffdshow. Details are in this topic. (http://forum.doom9.org/showthread.php?t=145704) Is there an explanation? Should I file a bug report in the SF tracker?

By the way, what is the preferred way to get in touch with ffdshow-tryouts developers? I didn't find any mailing list, so...

[Leak]

By the way, what is the preferred way to get in touch with ffdshow-tryouts developers? I didn't find any mailing list, so...
*waves*

Last time I checked I do read these forums regularly...

Also, you didn't find a mailing list because there is no mailing list. But if you take a closer look at the homepage (http://ffdshow-tryout.sourceforge.net/) you'll notice the "Forum" link...

As for AviSynth speed - I'll look into it (most probably not before the weekend), but if I were you I wouldn't hold my breath for speed improvements - after all, this is just a wrapper around AviSynth, so it'll always be slower than using AviSynth alone or an equivalent built-in filter of ffdshow, and AviSynth itself probably creates a duplicate of each frame somewhere due to caching since it's designed to minimize the re-fetching of frames.

Also, pardon my french, but testing how it performs on an empty script seems rather useless to me.

[e-t172]

Also, pardon my french, but testing how it performs on an empty script seems rather useless to me.

I don't know of any better way to measure the overhead of the Avisynth filter in ffdshow. With the current situation, even a simple script which is supposed to be fast turns out to be slow when used in ffdshow.

[rt87]

/me still waits for COOK decoder be appeared in ffdshow.

[tetsuo55]

/me still waits for COOK decoder be appeared in ffdshow.

Is it added/stable in ffmpeg??

[clsid]

It has been in FFmpeg for a long time already. But supporting it in ffdshow needs some work. There already is some (old) code for it, but that doesn't work. We need a volunteer to fix that.

[Mirabel]

/me still waits for COOK decoder be appeared in ffdshow.

I'd prefer Snow.

[clsid]

Then wait for Christmas ;)

[rt87]

Is it added/stable in ffmpeg??

It was added into ffmpeg 0.5 release.

[clsid]

Wrong. It was added long before the 0.5 release. It is just mentioned in the changelog because the previous "official" FFmpeg release was several years ago.

[roozhou]

*waves*

Last time I checked I do read these forums regularly...

Also, you didn't find a mailing list because there is no mailing list. But if you take a closer look at the homepage (http://ffdshow-tryout.sourceforge.net/) you'll notice the "Forum" link...

As for AviSynth speed - I'll look into it (most probably not before the weekend), but if I were you I wouldn't hold my breath for speed improvements - after all, this is just a wrapper around AviSynth, so it'll always be slower than using AviSynth alone or an equivalent built-in filter of ffdshow, and AviSynth itself probably creates a duplicate of each frame somewhere due to caching since it's designed to minimize the re-fetching of frames.

Also, pardon my french, but testing how it performs on an empty script seems rather useless to me.

Will there be a built-in avisynth loader, which works w/o avisynth.dll? In that way avisynth plugins will work in ffdshow like Winamp and DScaler plugins.

[albain]

Windows 7 still supports DirectShow, so we have got nothing to worry about for the coming years.

I am not against adding a DMO interface. But if it brings no benefits, then it would be a waste of time.

With Windows 7 you can't use FFDShow with Media Player and Media Center on MPEG4 streams for example, even with the hack on uncompressed streams.

Some information :

Media Foundation separates decode to transform : this means that the decoding part should be separated from the postprocessing part, which makes sense
This is a good news because this is possible to get FFDShow work even if it does not decode by declaring it as a decoder and a transformer. At first in DMO world it will be only usefull as a transform filter and let the directshow part handle the decoding (when possible)

[Leak]

Will there be a built-in avisynth loader, which works w/o avisynth.dll? In that way avisynth plugins will work in ffdshow like Winamp and DScaler plugins.
I don't think so - it's really unfeasible as AviSynth plugins can use any built-in or external AviSynth filter, and many do. Without the AviSynth.dll (and the surrounding script environment) all you'd get would be a crash at best.

np: Broker/Dealer - Midnight (100)

[Snowknight26]

I couldn't think of an appropriate place to post this but here, so don't hate me! :P

What I'm trying to do is to compare the output (lets say YV12 or YUV2) between libavcodec and ffmpeg-mt for H.264 decoding. What I was thinking is that I could use something like OSD's MD5 feature. For every frame that gets played, the MD5 hash of the current frame is appended to the corresponding line number (new line of course) in a text file. That way, its as simple as play a file using timecodec, switch between libavcodec and ffmpeg-mt, then MD5 the resulting text file to see if all the MD5s are identical. That way I can see whether they produce exact results, and if they don't, find the frames that don't match, and possibly report a bug.

However, I haven't found an easier way to do this. Heck, the method I'd do can't be done at the moment either... which is why I'm looking for suggestions to help me with my little dilemma.

[leeperry]

you can CRC check them w/ cdcheck...it'll run a binary compare.

not sure that's what you're asking for, though

[Snowknight26]

Basically trying to ensure that two decoders' outputs are exactly the same without having to actually write the raw output to a file.

Edit: Hmm, I think I found the perfect thing, assuming the MD5 sum is of the decoded frame, not encoded frame.
I turned on the OSD, chose only current frame and MD5 sum, saved the file and played the video from start to finish. Then I simply switched decoders from libavcodec to ffmpeg, repeated (renaming the output file of course), then compared the MD5 of the saved files.

Edit 2: Aww, enabling MD5 significantly drops the decoding speed.. almost to that of 1 thread.

[leeperry]

@Haruhiko : I'm in contact w/ Christian Budde, the author of the VST winamp bridge/Electri-Q and many more audio plugins.

he will drop you an email on your "nifty" account, can you please have a look at it?

here's what he told me, and he will try to fix the ffdshow audio code :

It's hard to believe, but there's some very big mistakes in ffdshow audio code(calling "Init" twice and never "Quit", also checking only for the export as name rather than the index, etc).

http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=434 : they "blame" me for being the bad guy, while the mistakes they have in their code are at least at the same level(if not worse). So the best thing would simply be to fix the mistakes once and for all in their source (I hate workarounds or maintaining more than one version).

Also they could remove the name from the blacklist.

:thanks:

[haruhiko_yamagata]

@Haruhiko : I'm in contact w/ Christian Budde, the author of the VST winamp bridge/Electri-Q and many more audio plugins.

he will drop you an email on your "nifty" account, can you please have a look at it?

here's what he told me, and he will try to fix the ffdshow audio code :



:thanks:Good news. Please excuse me for blaming that filter.

[leeperry]

Good news.
sure is! I'm so looking forward perfect winamp/VST plugins support in ffdshow :cool:

BTW, sorry to repeat myself, but don't you think it's a bug :confused:

http://forum.doom9.org/showpost.php?p=1261217&postcount=6836

I want 1024, I get 1022 :(

[yesgrey]

so here's a real world example : a 672x384 AVI file w 7/4 DAR
resized to 1024*768 yet Info() in the Avisynth filter shows : 1022*584, which is not mod4....and none of my scripts work because of that
IMHO ffdshow is working correctly. You are specifying both horizontal and vertical sizes, but those values are just outer limits. To keep the AR, ffdshow has to calculate the target resolution, which could result in a slightly lower size to give you an accurate AR.
If the horizontal resolution is more important to you, specify only the horizontal size, then the vertical will be calculated using the AR and the horizontal res you specify.
is there a way to force ffdshow to actually resize to 1024*585 or 586 :confused:
Yes, just select "specify horizontal and vertical size", put 1024x586 in the size fields, and select "no aspect ratio correction".

[leeperry]

IMHO ffdshow is working correctly.
ok thanks for your help, but resizing to 1024* doesn't help, still 1022...but if I select "outside" in the borders option of the resize, then it's 1024*584 as I wanted in the first place..I've always thought that this setting was only active if you manually added black bars :rolleyes:

even Seb.26 missed that one....alright problem solved :cool:

OTOH I've got a 362*272 divx file that crashes Avisynth no matter what I do :D

whatever I set the borders to inside/outside, it resizes to 1024*766 if I keep the AR and crashes the ffdshow Avisynth filter instantly(whatever 2.57 or 2.58)...I'll make a profile that enforces 1.3333333 :cool:

[yesgrey]

but if I select "outside" in the borders option of the resize, then it's 1024*584 as I wanted in the first place
I have the "outside" selected, that's why it worked with me when I tested it...
I've always thought that this setting was only active if you actually added black bars :rolleyes:
When you resize to a size with a different AR and want to keep the source AR, you have to add black bars.;)

[mark0077]

haruhiko I see your recent work on dvd menu quality and positioning.

Maybe while you are looking into it I could do some tests for you? With the new version on xvidvideo 2792, my menu highlights are still off by a few pixels when ffdshow is in the chain.

As I said before, it doesn't matter if ffdshow or mpc-hc does the decoding, the menu's getting broken only happens when ffdshow is in the chain, even if it is doing nothing but passing data straight through to the renderer. Maybe this might give a clue to you as to where the "bug" might lie.

[therealjoeblow]

I'd like to report what I believe to be a bug with the FFDshow Official Beta6_rev2527_20081219 version.

If I toggle resize (either on or off, depending on what it started with, it doesn't really make a difference), video playback of XviD material freezes. FFDshow is set as the sole video decoder in this instance.

It does NOT do this for DVD material in either case where where (1) PowerDVD 8 or PowerDVD 9 decoders are the primary video filter and FFDshow is a supplementary filter post-processing the video; or (2) where FFDshow is set as the primary MPEG2 filter.

Nor does it do this for x264 material. In both the DVD and x264 examples, it happily toggles resize on and off as many times as I want without ever a hitch, unlike XviD.

For XviD I've tried on two different machines, with three different players and several different renderers:

-One machine is a custom built HTPC with a GA-MA78GM-S2HP motherboard using the onboard Radeon HD 3200 video chip out to HDMI

-The other is a Dell Vostro 1510 laptop using an Intel Mobile 965 IGP to its own display.

I tried Zoom Player v6.00, MPC v6.4.9.0 and MPC-Home Cinema v1.2.908.0, with Overlay Mixer, VMR9 (Windowed, Windowless and Renderless) and EVR (from .NET SP3.5), and in all cases the result is exactly the same. XviD freezes when resize is toggled, and DVD/MPEG2/x264 plays fine.

I should point out that resize actually works fine on XviD if it is enabled before playback starts, but it's the *process* of turning it off that freezes the video. Likewise if it was off, the video plays fine, but turning it on freezes the video as well.

Would be great if this could be fixed, since this is probably the most frequently used instance where one would want to be able to toggle it on and off. Resize performance with DVD and x264 is pretty predictable since they are higher quality formats to start with, but in many cases with XviD, resizing it just introduces too many artifacts and I find myself wanting to turn it on and off much more frequently there than in the other cases.

[clsid]

@mark0077
Those fixed are in a separate branch. They are a work in progress. There are not public builds that include those changes.

@therealjoeblow
Please test with a recent SVN build.

[jmartinr]

OTOH I've got a 362*272 divx file that crashes Avisynth no matter what I do :D

whatever I set the borders to inside/outside, it resizes to 1024*766 if I keep the AR and crashes the ffdshow Avisynth filter instantly(whatever 2.57 or 2.58).

Specify horizontal and vertical size, keep original aspect ratio and process pixel aspect ratio internally.

You can also do your avisynth stuff before resizing, or you could do the resize in avisynth. A bit of scripting will give you the same possibilities as the ffdshow resizer.

[therealjoeblow]

@therealjoeblow
Please test with a recent SVN build.

Tested ffdshow_rev2792_20090320_clsid.exe just now.

Exactly the same (XviD freezes when toggling resize on and/or off, DVD and x264 are fine).

I believe I forgot to point out earlier that both machines are running WinXP-SP3 (32bit) if that makes any difference. The Gigabyte HTPC is a brand new fresh install with very little else on it; the Dell laptop is only about 3 months old and has a pretty clean OS too.

[haruhiko_yamagata]

I'd like to report what I believe to be a bug with the FFDshow Official Beta6_rev2527_20081219 version.

If I toggle resize (either on or off, depending on what it started with, it doesn't really make a difference), video playback of XviD material freezes. FFDshow is set as the sole video decoder in this instance.

I can't reproduce. Toggling resize during playback is a basic feature of ffdshow, fully tested and shouldn't be a common bug to everyone. Please try to find something in your filter graph that prevents reconnecting. ffdshow may be connected to some filter other than video renderer.
You could check the status of "Allow output format changes during playback" in "Output" page.

[haruhiko_yamagata]

haruhiko I see your recent work on dvd menu quality and positioning.

Maybe while you are looking into it I could do some tests for you? With the new version on xvidvideo 2792, my menu highlights are still off by a few pixels when ffdshow is in the chain.

As I said before, it doesn't matter if ffdshow or mpc-hc does the decoding, the menu's getting broken only happens when ffdshow is in the chain, even if it is doing nothing but passing data straight through to the renderer. Maybe this might give a clue to you as to where the "bug" might lie.
That branch is finally ready for open test.
Improved and fixed:

Background rendering of glyph in thread. The thread has priority below normal. Better performance and quality with higher CPU usage.
Better gradation
Collision and layer handling
Karaoke bug fix
UTF-8 in 'Charset' combo box.
Better opaque box
Stereoscopic bug fix
Partial rewrite: cleaner code. It's still a big mess though.
Improved rendering of DVD menu/subtitles (especially in RGB output).
Fixed positioning of DVD menu/subtitles.
Fixed missing initial highlight of static DVD menu.
Improved vobsub handling: try to use non empty stream. This fixes the bug "nothing is displayed" in most cases.

TODO:

Improve text subtitles rendering in YV12 mode. Convert to RGB32, process, convert to YV12 and write back with mask.
Improve the gradation of borders (use the code from MPC).
Implement rotation (code for rotating glyph is already there but still much work to use it)
ASS:Implement \h, \clip(), \t(), etc.

Build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev2797_20090321_Q.exe)

[CiNcH]

Is anybody in charge of the VC-1 decoder? An Access Unit parser like it has been done for H.264 would be cool. Here (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc/trunk/src/filters/transform/mpcvideodec/MPCVideoDecFilter.cpp?revision=1009&view=markup) is Casimir's code concerning this issue (>= line 1285) but he did not yet release the code for the H.264 and VC-1 Access Unit parsers as you can see (code is commented out).

[mark0077]

That branch is finally ready for open test.


WOW very impressed now. Probably of the big 6 problems I had with dvd quality on my machine in relation to ffdshow listed in my dvd quality thread, I would say 5 have all been fixed now. Thanks alot for that.

The last problem that still remains is obv advanced interlaced vs progressive frame detection and I am assuming my other problem of some dvd menu freezes or delays are related to mpc-hc beliyaal's build for the moment as recent builds have exhibited this behaviour.

Thanks again!
EDIT: Here are my findings after testing on Queen Greatest Video Hits 1 which has some rectangular menus, aswell as some menus containing one frame. I have never seen this dvd menu look perfect recently.

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

-- ffdshow libmpeg2 --
DVD Menu Quality: Excellent
DVD Menu Speed: Extremely slow. This slowness means a minute or two wait for simple text animations to finish, like fade in fade out animations before a song plays. One of my core i7 @4ghz cores gets maxed out while these animations attempt to complete. These animations LOOK correct but perform very slow.
DVD Quality: Excellent

-- ffdshow libavcodec --
DVD Menu Quality: Excellent (But when text fade begins before dvd playback, the image below happens). Bad quality of dvd quality might be triggered by the text fade that was also extremely slow above.
DVD Menu Speed: Excellent
DVD Quality: Very Bad, screenshot attached
http://img16.imageshack.us/img16/9473/newlibavcodec.th.jpg (http://img16.imageshack.us/my.php?image=newlibavcodec.jpg)

-- mpc-hc libmpeg2 decoder --
DVD Menu Quality: Excellent
DVD Quality: Excellent
DVD Menu Speed: Excellent
Other Problems: Freezing when highlighting menus as always has been a problem (Image where freeze happens below), items seem to be still clickable even though highlights don't appear, no highlight shown when hovering over items (except first item), no frame drops reported in mpc-hc. I guess this is something mpc-hc developers and ffdshow developers need to discuss between eachother. Its like the hover event isn't being passed from mpc-hc to ffdshow when mpc-hc is doing the decoding, and ffdshow the highlights. Like as if communication isn't working.
http://img7.imageshack.us/img7/8038/queenproblem.th.jpg (http://img7.imageshack.us/my.php?image=queenproblem.jpg)

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

Interlaced Text?
I assume from the ffdshow libmpeg2 slowness on these text fades I talk about above, that these are treated as subtitles. If this is the case for this DVD I can also say that there is a problem (and always has been) with these text fades as the text looks like its interlaced. Our standard dvd player actually shows these text fades beautifully, but on PC they have always look interlaced, or with horizontal lines through them (except the first one strangely, with de-interlacing enabled OR disabled). Image shown below to illustrate this.

First one that always looks perfect
http://img3.imageshack.us/img3/646/firstu.th.jpg (http://img3.imageshack.us/my.php?image=firstu.jpg)
Second one that shows that any apart from the first always look like this.
http://img3.imageshack.us/img3/4092/secondhaa.th.jpg (http://img3.imageshack.us/my.php?image=secondhaa.jpg)

[Leak]

Can't say that I can duplicate your results - both libavcodec and libmpeg2 work for me without speed problems, though libavcodec seems to get the aspect ratio wrong when I close and reopen MPC-HC and resume playback. And the BSG DVD I've tested it with also showed the menu highlights without problems (except for the mouse areas being off, but I guess that's what you get when you set ffdshow to add all added borders to the bottom - MPC can't know that... ;))

(OT - while I get more than 25% CPU usage on my Core 2 Quad it's nicely distributed over many (10+) threads according to Process Explorer, none of them using more then 5% in total so I'm a happy camper... :D)

np: Jesse Somfay - The Days Of Our Youth Ended With Broken Bottles (Dominik Eulberg & Riley Reinhold Remix) (100)

[mark0077]

Can't say that I can duplicate your results - both libavcodec and libmpeg2 work for me without speed problems, though libavcodec seems to get the aspect ratio wrong when I close and reopen MPC-HC and resume playback. And the BSG DVD I've tested it with also showed the menu highlights without problems (except for the mouse areas being off, but I guess that's what you get when you set ffdshow to add all added borders to the bottom - MPC can't know that... ;))

(OT - while I get more than 25% CPU usage on my Core 2 Quad it's nicely distributed over many (10+) threads according to Process Explorer, none of them using more then 5% in total so I'm a happy camper... :D)

np: Jesse Somfay - The Days Of Our Youth Ended With Broken Bottles (Dominik Eulberg & Riley Reinhold Remix) (100)

Maybe these speed problems are only on the fading text. This Queen DVD contains alot of strange DVD menus I guess with single frame menu's. It has been a good test DVD for this type of thing in the past and is still finding problems. I am sure haruhiko will sort them out ;)

Below is the single frame menu that now looks PERFECT, but when mpc-hc does the decoding, moving the mouse over any of the other options in the menu shows no highlights. As I say, when I click on them the correct audio channels are used, but menu highlight never appears when I move mouse over different options in this scenario. I just confirm that the menu highlights don't appear in this scenario even when using keyboard navigation so definitely some communication problem between mpc-hc and ffdshow which causes these freezes.
http://img7.imageshack.us/img7/8038/queenproblem.th.jpg (http://img7.imageshack.us/my.php?image=queenproblem.jpg)

[clsid]

Perhaps you could create a modified copy of that DVD for Haruhiko (and Leak) for testing purposes? With for example DVDShrink it is possible to replace all videos with a still image and keep the original menus. That should result in a very small ISO.

[Leak]

Perhaps you could create a modified copy of that DVD for Haruhiko (and Leak) for testing purposes? With for example DVDShrink it is possible to replace all videos with a still image and keep the original menus. That should result in a very small ISO.
I've found that VOBBlanker does an even better job at that; it could be harder to use, though.

np: Moonbeam - You Can Hear Them (100)

[mark0077]

Perhaps you could create a modified copy of that DVD for Haruhiko (and Leak) for testing purposes? With for example DVDShrink it is possible to replace all videos with a still image and keep the original menus. That should result in a very small ISO.

Here is a RAR containing the menu (ended up being 107mb) and the parts of the clip that I thuoght were necessary. Total 219mb

Hope its not too big.

So my test for crashing is, use mpc-hc decoder. Start movie, when menu appears go into options, try and hover over the audio options. You will see hovering over options doesn't show highlights.
http://www.megaupload.com/?d=V2XYOUFA

Slowness of menu text before each song smoothness is not visible in this test as they are semi-removed but I can make another clip containing these if is not reproducable using other tests. This one shows the problem when using decoders outside of ffdshowl.

I cannot ever get through the following sequence without frame drops / glithces / freezes

Start Queen DVD -> Go to options menu -> Select 5.1 DTS -> go to main menu -> Start movie / songs

[haruhiko_yamagata]

I can reproduce the unclickable 'option' menu. The stream has bogus AR, rev 2800 fixes the problem.
I don't have the slowdown problem.

New build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev2804_20090322_Q.exe)

[mark0077]

I can reproduce the unclickable 'option' menu. The stream has bogus AR, rev 2800 fixes the problem.
I don't have the slowdown problem.

New build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev2804_20090322_Q.exe)
Unfortunately all of my original problems still stand with this build, with mpc-hc beliyaals build using evr-custom presentation.

Try disabling ffdshow mpeg2 decoder and navigate into "Options" in that DVD Shrink I posted. I have never been able to move the mouse up and down through the items and have the highlights appear in this config. No hardware or operating system or version of ffdshow has ever let me do this. The highlights don't appear as I move the mouse up and down through the items.

[haruhiko_yamagata]

Can I merge the subtitle branch?
If nobody can find any regressions, I'll commit this.
Patch (http://ffdshow-tryout.sourceforge.net/doom9/subtitle_branch_merge.patch) (TsubtitleText.cpp is broken because of the patch. The new one is UTF8. Please use the file in the branch)
Build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev2805_20090323_Q.exe)

[haruhiko_yamagata]

Unfortunately all of my original problems still stand with this build, with mpc-hc beliyaals build using evr-custom presentation.

Try disabling ffdshow mpeg2 decoder and navigate into "Options" in that DVD Shrink I posted. I have never been able to move the mouse up and down through the items and have the highlights appear in this config. No hardware or operating system or version of ffdshow has ever let me do this. The highlights don't appear as I move the mouse up and down through the items.
Please update to the latest MPC-HC. EVR Custom Pres. (on Vista) isn't very stable for me.

[mark0077]

Please update to the latest MPC-HC. EVR Custom Pres. (on Vista) isn't very stable for me.

I will try different renderers later tonight to see if the problem is related to that. I am using the latest build from
http://forum.doom9.org/showthread.php?t=145203 but the problem has been there for.... well for as long as I can remember. I will update you when I try different renderers later, maybe the problem is evr-cp related.

[tetsuo55]

Although things should work on all renders, focus seems to be moving to EVR-CP.
Logical since that render works on XP and up and is the most advanced.

[haruhiko_yamagata]

I can reproduce now, perhaps I have missed something in the combination of the settings.

// EDIT
Debug build is OK, release build is not.

[mark0077]

Great stuff, thanks alot for testing. Once that lack of highlight with non ffdshow mpeg2 decoders is sorted ;) then I have almost no problems. I will check again tonight to see if I can provide a smaller sample to reproduce the "slow fade" problem with ffdshow libmpeg2 aswell as garbled picture quality with ffdshow libavcodec. Maybe these also are evr-custom presentation related.

Thanks

EDIT: Sorry, the latest build you sent up doesn't show the slow fade problem anymore... might have been something on my end I am not sure.

The only two problems remaining are
1) No highlights when using non ffdshow decoder - You have been able to reproduce ;)
2) Garbled decoding using ffdshow libavcodec mpeg2 decoder - I can reproduce with all of the latest builds but only in this Queen DVD. The video I uploaded will demonstrate the problem when using libavcodec for mpeg2. When you cllck play, the garbled output begins. This scene is interlaced and I have noticed a problem with this DVD in the past with libavcodec as it usually detects the fields the wrong way around (other decoders don't show this swapped fields problem). In the past using libavcodec I need to manually swap fields for this DVD. Now this problem arises instead with garbled output. Try the shrink I uploaded recently which will show you the problem.

[Amour]

Hello,

I would like to submit an issue with clsid's installer. It's related to another old issue that I submitted in august 2007:
http://forum.doom9.org/showpost.php?p=1034129

There are two sub-issues, and together they cause some trouble for the average lambda user:

1) The default selection of formats to decode on a fresh clean install of ffdshow is slightly different from the "select all" selection of formats to decode.
To be more specific, the default selection of formats to decode on a fresh install of ffdshow does not include:
* MPEG-1
* MPEG-2
* VC-1
* ASV1/2, CYUV, ZLIB, 8BPS, LOCO, MSZH, QPEG, WNV1, VCR1
* CamStudio, ZMBV, Ultimotion, VIXL, AASC, IV32, FPS1, RT21
* FLAC
* ADPCM, MS GSM, TrueSpeech
They will only be included when you click on the top box next to "Decode the following video formats with ffdshow" and "Decode the following audio formats with ffdshow".

2) On an update of ffdshow, the list of formats to decode is slightly less than the list of formats to decode on a fresh clean install.
To be more specific, the following formats aren't listed on an update of ffdshow:
* H.261, MJPEG, Theora, VP3
* CorePNG, MS Video 1, MSRLE, Techsmith, Truemotion
* ASV1/2, CYUV, ZLIB, 8BPS, LOCO, MSZH, QPEG, WNV1, VCR1
* CamStudio, ZMBV, Ultimotion, VIXL, AASC, IV32, FPS1, RT21
* ADPCM, MS GSM, TrueSpeech

Now, I'll describe the average lambda user (like me) catastrophe scenario:
a) You install a fresh new ffdshow with default settings.
b) You try to play a video with CYUV, VCR1, IV32, or whatever codec and it won't work (because it is not enable by default ffdshow install).
c) You install the latest ffdshow build and you check all possible formats to decode.
d) You try again the same video, and it won't work again (because when updating ffdshow, only 50% of the selection of formats is displayed).


To avoid this, I would greatly appreciate a few improvements related to the ffdshow installer (especially clsid's builds). I know he told me that there was a difficulty related to save in the registry "options covering multiple formats", but then I don't see why we have the following multiple-formats options available when updating ffdshow:
* FLV1, FLV4
* SVQ1, SVQ3, Cinepak, RPZA, QTRLE
* VP5, VP6
* QDM2, MACE

I propose the following:

1) To fix first issue: default selection of formats on a fresh clean install should include the same selection as a "select all" selection (the thing when you check the top box next to "Decode the following video formats with ffdshow").

2) To fix second issue: when updating ffdshow, display the same full list of formats than a fresh clean install.

3) Additional third fix: make the "reset all ffdshow settings" option like a button that will actually really reset the selection of formats to decode to default settings.

Thanks a lot.

[Amour]

Can ffdshow decode Intel Indeo Video 5.0 Wavelet (IV50) format?

[Konrad Klar]

Also, if I choose "Decode the following video formats with ffdshow" for Xvid, DivV 4/5/6, Other MPEG4, FVFW,FFDS it is always set to libavcodec, even if Xvid was previously set as decoder for that formats. I must manually reset that formats to Xvid each time, after installation of new FFDShow.

[Amour]

In ffdshow video decoder configuration -> codecs, shouldn't it be the following?

QRPZA -> RPZA
Quicktime Video Video (QRPZA) -> Quicktime Video (RPZA)

[Inventive Software]

ffdshow doesn't decode AC-3 audio from DVDs, even though it's enabled.... the MPC-HC decoder's used even though I tell that not to!

Can somebody tell me what I'm doing wrong?

[Leak]

Can somebody tell me what I'm doing wrong?
I'm afraid I can only tell you that it works fine for me in conjunction with MPC-HC... :(

np: Sten - More Stash (The Essence)

[mark0077]

Just back again to speak about aspect ratios. Definitely lots of problems relating to aspect ratio handling when resize is enabled. In my current config I can post a link to a file that shows the wrong aspect ratio.

http://www.dvdloc8.com/dolbydtsclip.php?clipid=3

This dtspiano.vob audio test which is 16:9 displays incorrect in the following setup.

Screen Resolution: 1920 x 1080
Resize & Aspect: Enabled
Resize Always
Aspect Ratio - Keep Original Aspect Ratio
Process Pixel Aspect Ratio Internally - Enabled
Lanczos - Accurate Rounding
Set Pixel Aspect Ratio In Output Media Type: Semi-Checked

mpc-hc EVR and EVR-CP tested.
mpc-hc Video Frame: Keep Aspect Ratio - Enabled

This results in an image thats much shorter height than expected. I am still having lots of trouble using ffdshow's resize due to incorrect ratios for various configurations and image ratios.

[clsid]

@Amour

Formats like MPEG-1 and MPEG-2 are disabled by default because ffdshow is not the preferred decoder for that.

Some items are hidden on updates because it is not possible to determine the "current" state of such a checkbox because it involves multiple independent registry keys. The decision was made long ago that the checkboxes should reflect the state of the users current settings, not the settings used in a previous run of the installer (which is trivial to do). There is just no way to do it right. Perhaps we should just hide everything during updates. If a user wants to change settings, the ffdshow configuration dialogs can be used.

Reset settings applies to the filter settings, not the enabled formats.

[Amour]

Thanks, but you are giving me the same answer as last time, which is not covering all the details I gave in today's post.

1) It's not just MEPG-1 and MPEG-2, it's also:
* VC-1
* ASV1/2, CYUV, ZLIB, 8BPS, LOCO, MSZH, QPEG, WNV1, VCR1
* CamStudio, ZMBV, Ultimotion, VIXL, AASC, IV32, FPS1, RT21
* FLAC
* ADPCM, MS GSM, TrueSpeech

2) If it is not possible to determine the "current" state of multiple-formats checkboxes, then it doesn't explain why/how you do it for the following:
* FLV1, FLV4
* SVQ1, SVQ3, Cinepak, RPZA, QTRLE
* VP5, VP6
* QDM2, MACE

3) The "reset all ffdshow settings" should be renamed "reset ffdshow filters" to avoid confusion.

[Amour]

Maybe we could alter/change the display of the codecs list in the ffdshow video decoder configuration dialogs to highlight or separate two different kinds of codecs:
* The codecs fully supported by ffdshow
* The codecs not preferred or not fully supported by ffdshow

This way, we would give an easy hint to simple average users (like me) about how to configure ffdshow, which decoders should be enabled and which decoders are better left disabled.

[Amour]

2) If it is not possible to determine the "current" state of multiple-formats checkboxes, then it doesn't explain why/how you do it for the following:
* FLV1, FLV4
* SVQ1, SVQ3, Cinepak, RPZA, QTRLE
* VP5, VP6
* QDM2, MACE

I got the answer to this from \trunk\bin\distrib\InnoSetup\ffdshow_installer.iss :

"FLV1, FLV4" -> it only checks "flv1"
"SVQ1, SVQ3, Cinepak, RPZA, QTRLE" -> it only checks "svq3"
"VP5, VP6" -> it only checks "vp6"
"QDM2, MACE" -> it only checks "qdm2"

Which means that any update of ffdshow will ignore previous states for FLV4, SVQ1, Cinepaq, RPZA, QTRLE, VP5, MACE.

Konrad Klar is giving hints that there might be more problems with the installation/update procedure.

[STaRGaZeR]

Some codecs are missing options in the installer, if you have DivX and Xvid decoders set to Xvid and you update ffdshow, the installer only has one checkbox for each and it doesn't know if you have libavcodec or Xvid selected as decoder. Either way the checked checkbox will always put libavcodec as decoder regardless of what you had previously. Add that to your list.

[clsid]

1) Some settings have just been chosen arbitrarily. For VC-1 of course the standard MS decoder is the recommended choice instead of ffdshow.
2) I suggest you take a look at the install script. It checks only one of the formats in those cases. Why? It simply does. It is either that or hiding them as well.
3) No it should not. The description is already correct. If you don't understand it, then well, it your fricking problem. It resets all settings. Then the settings chosen during installation are applied.
4) Nothing will get separated. The preferred settings depend on the users OS, other installed software, and personal preferences. The installer does not detect other filters (I can't be bothered to add that) and it isn't a mind reader.
5) Users that don't understand the options given in the installer should simply not touch the options and install with defaults.
6) Making the installer idiot-proof is impossible because 97,34% just presses next next next finish. 1,45% is illiterate. 0,98% is stupid beyond help. For only 0,13% it might be useful to hold their hand and guide them through the installation.

I don't use the installer, so I don't care much about it. There are few complaints about it. It works fine. Its job is to do the initial configuration. The ffdshow configuration dialogs are there to tweak the settings. Update installs are supposed to be used primarily for updating files, not for adjusting settings. If you want things changed then (1) come with better suggestions, and (2) find someone else to implement it.

Here is a deal:
If someone adds working COOK support to ffdshow, then I will 'fix' the installer.

[haruhiko_yamagata]

Just back again to speak about aspect ratios. Definitely lots of problems relating to aspect ratio handling when resize is enabled. In my current config I can post a link to a file that shows the wrong aspect ratio.

http://www.dvdloc8.com/dolbydtsclip.php?clipid=3

This dtspiano.vob audio test which is 16:9 displays incorrect in the following setup.

Screen Resolution: 1920 x 1080
Resize & Aspect: Enabled
Resize Always
Aspect Ratio - Keep Original Aspect Ratio
Process Pixel Aspect Ratio Internally - Enabled
Lanczos - Accurate Rounding
Set Pixel Aspect Ratio In Output Media Type: Semi-Checked

mpc-hc EVR and EVR-CP tested.
mpc-hc Video Frame: Keep Aspect Ratio - Enabled

This results in an image thats much shorter height than expected. I am still having lots of trouble using ffdshow's resize due to incorrect ratios for various configurations and image ratios.
I can't reproduce. Could you send your settings to me?
In "Profiles / Preset settings", "Save to file", please.

[thuan]

@Haruhiko: Using your ffdshow_rev2805_20090323_Q build I have trouble with this sub (http://www.mediafire.com/download.php?oti5lbz2wz0). Basically your collision handling code works differently to VSFilter starts at around 1:07. Please have a look.

[STaRGaZeR]

Update installs are supposed to be used primarily for updating files, not for adjusting settings.

Very true. Problem is, next next next finish adjust settings on its own, without user intervention, instead of just updating files...

[tetsuo55]

It would be nice to have an extra selection that auto-selects all stable/recommended codecs in FFdshow.

I personally use the K-Lite Mega codecpack, and i try to have as many codecs as possible be handled by FFdshow

[haruhiko_yamagata]

@Haruhiko: Using your ffdshow_rev2805_20090323_Q build I have trouble with this sub (http://www.mediafire.com/download.php?oti5lbz2wz0). Basically your collision handling code works differently to VSFilter starts at around 1:07. Please have a look.
Thank you for feed back. {\org(x,y)} seems to cancel collision.
\org is for rotation, which is not implemented in ffdshow. The script use \org only to cancel collision.
I'll add some parser code for \org.

[Amour]

Well, clsid, currently I only know how to browse a SVN repository. I might try to learn how to compile a program, what is an .iss script, and how to do a patch.

If I manage to handle all that, I'll try to provide an improved installation/update procedure for ffdshow. I do not know if it will be faster or not than any “COOK” support.

[Amour]

Just a small question to help me started: can I compile ffdshow with Visual C++ 2008 Express Edition, or do I need to find a full edition of Visual Studio 2008? Is this thread the best place to ask about how to compile ffdshow, or is there another place with help for that?

[tetsuo55]

Just a small question to help me started: can I compile ffdshow with Visual C++ 2008 Express Edition, or do I need to find a full edition of Visual Studio 2008? Is this thread the best place to ask about how to compile ffdshow, or is there another place with help for that?


The EE edition should do the trick.
I don't know which dependency's you need to install though

[thuan]

Thank you for feed back. {\org(x,y)} seems to cancel collision.
\org is for rotation, which is not implemented in ffdshow. The script use \org only to cancel collision.
I'll add some parser code for \org.
Thanks, here's another problematic sub (http://www.mediafire.com/download.php?zhmdmizlje2). It starts at 00:04 sec and subs will move incorrectly or overlap over each other.

[clsid]

DirectX SDK August 2007 is the only extra thing that is needed.

[mark0077]

I can't reproduce. Could you send your settings to me?
In "Profiles / Preset settings", "Save to file", please.

I will send preset file now. I have the borders set to white so I can see what ffdshow is doing. In this case, there should be no white borders, but instead massive white borders are added at the top and bottom making the image squashed.

16:9 in 1920 x 1080 (should be no white bars at all, instead white bars at top and bottom).
http://img7.imageshack.us/img7/9608/resizeproblem.th.jpg (http://img7.imageshack.us/my.php?image=resizeproblem.jpg)

4:3 in 1920 x 1080 (should be white bars at top and bottom, instead white bars at sides)
http://img7.imageshack.us/img7/5676/anothertesti.th.jpg (http://img7.imageshack.us/my.php?image=anothertesti.jpg)

Looks like one fraction in the code is turned upside down. ;)

PS: Thanks for fixing the other dvd highlight problem. :D Looking forward to it getting merged.

[albain]

I am becoming frustrated with Windows 7 :

This is no longer possible to decode divx/xvid/h264 within FFDShow, whatever used technology (DirectShow, Media Foundation)

This is no longer possible to have raw processing (worked in XP, worked in Vista with a hack).

So let's say that about 99% of your videos won't play with FFDSHow.

I just had the confirmation from MS.

I am talking about MS applications : windows media center and media player. MPC for example still works fine with FFDSHow

For us, this is annoying but we do this for free, but for Divx networks, core codec, ... this is another story

[Amour]

I heard that Windows Media Player can be uninstalled from Windows 7.

If that is the case, then we can try in the future to advertise this way:
Install MPC and uninstall WMP!

Also, it would be interesting to know the following ratio:
* How many people are using ffdshow with WMP
* How many people are using ffdshow with an alternative player

[rickardk]

I am becoming frustrated with Windows 7 :

This is no longer possible to decode divx/xvid/h264 within FFDShow, whatever used technology (DirectShow, Media Foundation)

This is no longer possible to have raw processing (worked in XP, worked in Vista with a hack).

So let's say that about 99% of your videos won't play with FFDSHow.

I just had the confirmation from MS.

I am talking about MS applications : windows media center and media player. MPC for example still works fine with FFDSHow

For us, this is annoying but we do this for free, but for Divx networks, core codec, ... this is another story

Did MS actually confirm that Media Center (in Windows 7) will be locked down to just use codecs from Microsoft for divx/xvid/h264 even in the final release?

[albain]

Did MS actually confirm that Media Center (in Windows 7) will be locked down to just use codecs from Microsoft for divx/xvid/h264 even in the final release?

No, there is (little) hope that this is a bug.

However, I made my tests on build 7057, which is nearly Release Candidate

Concerning the debate : who use WMP, I would say many people, because of Media Center, which has no equivalent these days

[Jeremy Duncan]

clsid,

You said to the amour that visual studio with sdk 2007 august can build ffdshow. This makes me ask a question. Does the ffdshow have a src with a dsw or vcproj file that visual studio can open and just build ffdshow?

[clsid]

Why would there not be any project files for Visual Studio? We all use it to compile ffdshow, so yes, they are present in our source repository ;)


@albain
Perhaps Haali could add a tweak to his splitter to (optionally) force ffdshow's video processor into the graph. It already is able to do that with DirectVobSub and that still works with WMP on Windows 7. Then at least ffdshow could be used when playing .mkv files.

[therealjoeblow]

I can't reproduce. Toggling resize during playback is a basic feature of ffdshow, fully tested and shouldn't be a common bug to everyone. Please try to find something in your filter graph that prevents reconnecting. ffdshow may be connected to some filter other than video renderer.
You could check the status of "Allow output format changes during playback" in "Output" page.

Thanks, and sorry for the false alarm - after testing a bunch more files and looking at haruhiko's suggestions, the resize freeze bug only occurred on some files, not all of them; and in looking at the filter graph, for the problematic files, ffdshow was connecting it's output pins to directvobsub in those cases. It just so happened that the half dozen or so I tested the first time around all had subtitles :-( and in reinstalling AutoGK recently, directvobsub got reenabled.

In testing, I temporarily removed the subtitle files which stopped directvobsub from loading and the resize works for what I thought were the "glitch" videos, so my bad. Now I've disabled directvobsub completely from loading and all is well.

Sorry again for the false alarm.

Cheers,
The REAL Joe

[STaRGaZeR]

Update about the corruption issues when seeking with ffmpeg-mt:

- Progressive material --> Completely gone with the lastest changes in EVR by Beliyaal. So forget about this one.

- PAFF material --> Gone.

- MBAFF material --> Still there, plus ocasional decoding artifacts when normal playing like ikarad reported. Some are random and some are fixed, with all renderers (even overlay), and they look like this:

http://thumbnails14.imagebam.com/3072/d3722630715344.gif (http://www.imagebam.com/image/d3722630715344)

[Amour]

DirectX SDK August 2007 is the only extra thing that is needed.

I thought that “August 2007” would be some minimal requirement, but I was wrong: any later release of DirectX SDK is missing dinput.lib!

[edit]
Ok, I can work-around that by doing:
Project -> Properties -> Configuration Properties -> Linker -> Input -> Additional Dependancies
And then I replace dinput.lib with dinput8.lib.

Unfortunatly, it doesn't help to compile to the end of the project.

[edit]
Revision 2811 by clsid2:
“Simplified install script. Tasks are now only shown at the initial installation and are hidden when updating.”

...

Thanks.

[albain]

Why would there not be any project files for Visual Studio? We all use it to compile ffdshow, so yes, they are present in our source repository ;)


@albain
Perhaps Haali could add a tweak to his splitter to (optionally) force ffdshow's video processor into the graph. It already is able to do that with DirectVobSub and that still works with WMP on Windows 7. Then at least ffdshow could be used when playing .mkv files.

Do you know a way to contact Mike ? I have subscrbed to his mailing list but he rarely answers to it
Also it would be a good idea to implement such an option in gabest matroska splitter too ?

Thanks

[tal.aloni]

Amour,
Here are the missing old DirectX SDK files:
http://iknowu.net/files/public/ffdshow/old_dx_sdk.rar

(I'm using them with the August 2008 SDK)

[haruhiko_yamagata]

@Amour
Building ffdshow (http://ffdshow-tryout.sourceforge.net/wiki/developer)

[haruhiko_yamagata]

We are migrating to the new wiki.
http://ffdshow-tryout.sourceforge.net/wiki/
Please contribute.

We gave up Sourceforge's built in wiki, because it was too much buggy.

[Amour]

Thanks a lot tal.aloni: now compilation is working (almost: only a problem with ff_vfw).
I'll look into how to use InnoSetup now for creating the install program.

In the end, I might not change/patch anything, but it will be my first compiled program!

Thanks haruhiko_yamagata... it's just a few minutes too late. :D
Looking at the wiki, I didn't download/install MinGW, but I had to download/install another program: yasm.exe.

[albain]

We are migrating to the new wiki.
http://ffdshow-tryout.sourceforge.net/wiki/
Please contribute.

We gave up Sourceforge's built in wiki, because it was too much buggy.

Can you give me the access ?

Thanks

[haruhiko_yamagata]

Just a small question to help me started: can I compile ffdshow with Visual C++ 2008 Express Edition, or do I need to find a full edition of Visual Studio 2008? Is this thread the best place to ask about how to compile ffdshow, or is there another place with help for that?
We don't know. Please try Express Edition and let us know the result.

[haruhiko_yamagata]

I will send preset file now. I have the borders set to white so I can see what ffdshow is doing. In this case, there should be no white borders, but instead massive white borders are added at the top and bottom making the image squashed.
Thanks, I have reproduced.

[haruhiko_yamagata]

Thanks, here's another problematic sub (http://www.mediafire.com/download.php?zhmdmizlje2). It starts at 00:04 sec and subs will move incorrectly or overlap over each other.
\move(424,462,509,362,1057,1390)\t(1057,1390,\fscx80\fscy80)
\t is not implemented. It should get smaller while it is moving.
It is overlapped because the font is to big.

[haruhiko_yamagata]

Thanks a lot tal.aloni: now compilation is working (almost: only a problem with ff_vfw).
I'll look into how to use InnoSetup now for creating the install program.

In the end, I might not change/patch anything, but it will be my first compiled program!

Thanks haruhiko_yamagata... it's just a few minutes too late. :D
Looking at the wiki, I didn't download/install MinGW, but I had to download/install another program: yasm.exe.I have added yasm.
MinGW is required to compile libmplayer, libavcodec and some other dlls.

[haruhiko_yamagata]

Can you give me the access ?

Thanks
Please register yourself. Press Login and register.

[e-t172]

Just a small question to help me started: can I compile ffdshow with Visual C++ 2008 Express Edition, or do I need to find a full edition of Visual Studio 2008? Is this thread the best place to ask about how to compile ffdshow, or is there another place with help for that?

Using VC++ 2008 Express Edition I managed to build a ffdshow.ax which works flawlessly.

[clsid]

Do you know a way to contact Mike ? I have subscrbed to his mailing list but he rarely answers to it
Also it would be a good idea to implement such an option in gabest matroska splitter too ?

Thanks
Maybe BetaBoy knows how to contact him.

The Gabest splitters don't have a GUI with options, so adding a optional tweak would be more difficult. Also that Matroska splitter is inferior to Haali's so people should simply not use it (outside of MPC).

[haruhiko_yamagata]

Just back again to speak about aspect ratios. Definitely lots of problems relating to aspect ratio handling when resize is enabled. In my current config I can post a link to a file that shows the wrong aspect ratio.

http://www.dvdloc8.com/dolbydtsclip.php?clipid=3

This dtspiano.vob audio test which is 16:9 displays incorrect in the following setup.
Resize is not the problem. It's the stream that is wrong IMO. According to the decoders of ffdshow, the stream is 720x526, SAR 256/135, DAR 64/27.
The aspect ratio of MPEG-2 stream is quite unreliable according to FFmpeg. Currently there are two ways of calculating AR (see the code below).
If it is DVD, it is either 4:3 or 16:9. In that case, we can fix AR.
However, if it is a file, I don't know which way to choose.
Gurus of MPEG-2, please lead me to a correct fix.
//MPEG-2 aspect
if(s->aspect_ratio_info > 1){
//we ignore the spec here as reality does not match the spec, see for example
// res_change_ffmpeg_aspect.ts and sequence-display-aspect.mpg

/* ffdshow custom code - we do not want to ignore spec. Comment out "// 1".
DVD plays better. It breaks the playback of res_change_ffmpeg_aspect.ts though. */
if( (s1->pan_scan.width == 0 )||(s1->pan_scan.height == 0) /*|| 1*/){
AVRational r={s->width, s->height};
s->avctx->sample_aspect_ratio=
av_div_q(
ff_mpeg2_aspect[s->aspect_ratio_info],
r//(AVRational){s->width, s->height}
);
}else{
AVRational r={s1->pan_scan.width, s1->pan_scan.height};
s->avctx->sample_aspect_ratio=
av_div_q(
ff_mpeg2_aspect[s->aspect_ratio_info],
r//(AVRational){s1->pan_scan.width, s1->pan_scan.height}
);
}

[haruhiko_yamagata]

Using VC++ 2008 Express Edition I managed to build a ffdshow.ax which works flawlessly.
Great, I have updated the wiki.

[albain]

Maybe BetaBoy knows how to contact him.

The Gabest splitters don't have a GUI with options, so adding a optional tweak would be more difficult. Also that Matroska splitter is inferior to Haali's so people should simply not use it (outside of MPC).

Okay thanks, I have PM him.

[mark0077]

Resize is not the problem. It's the stream that is wrong IMO. According to the decoders of ffdshow, the stream is 720x526, SAR 256/135, DAR 64/27.
The aspect ratio of MPEG-2 stream is quite unreliable according to FFmpeg. Currently there are two ways of calculating AR (see the code below).
If it is DVD, it is either 4:3 or 16:9. In that case, we can fix AR.
However, if it is a file, I don't know which way to choose.
Gurus of MPEG-2, please lead me to a correct fix.

Hi thanks for looking into the issue. If it is the stream that is wrong, what about the DVD's like the Test DVD. It appears in the perfect aspect ratio when not using ffdshow resize. When resize is used, it is squashed horizontally.

[haruhiko_yamagata]

Hi thanks for looking into the issue. If it is the stream that is wrong, what about the DVD's like the Test DVD. It appears in the perfect aspect ratio when not using ffdshow resize. When resize is used, it is squashed horizontally.
In DVD applications, video renderer correct AR if resize is not used. Please use ffdshow beta6 + OSD (User:%outd %odim %oar).
If AR is wrong, menu does not work though.

[mark0077]

In DVD applications, video renderer correct AR if resize is not used. Please use ffdshow beta6 + OSD (User:%outd %odim %oar).
If AR is wrong, menu does not work though.

Do you need me to gather more info with beta 6 using DVD's that show the wrong aspect ratio? I am concerned because all display correctly without resize, many display incorrectly with resize.

[haruhiko_yamagata]

Do you need me to gather more info with beta 6 using DVD's that show the wrong aspect ratio? I am concerned because all display correctly without resize, many display incorrectly with resize.
I'm just explaining that DVD applications can show wrong AR correctly.

[BetaBoy]

Albain... thx for the detective work on the filter issue in WMP/MCE and Windows 7. I started a dedicated thread here on D9 ( http://forum.doom9.org/showthread.php?p=1265646 ) on what your initial findings were, so others could confirm if this is the case. If so... well... I'm speechless.

[haruhiko_yamagata]

Is video_format in MPEG-2 reliable?
video_format specifies component/PAL/NTSC/SECAM/MAC/...
If it is reliable,
if (video_format== PAL && width==768 && height==576){
// Force 4:3 or 16:9
}
if (video_format== NTSC && width==720 && height==480){
// Force 4:3 or 16:9
}is possible.

[mark0077]

Is video_format in MPEG-2 reliable?
video_format specifies component/PAL/NTSC/SECAM/MAC/...
If it is reliable,
if (video_format== PAL && width==768 && height==576){
// Force 4:3 or 16:9
}
if (video_format== NTSC && width==720 && height==480){
// Force 4:3 or 16:9
}is possible.

I suppose if it is possible to check what the renderer does to decide then you could use that as a starting point. I think I understand the problem now.

[Amour]

MinGW is required to compile libmplayer, libavcodec and some other dlls.

Ok, true, I was slow to notice some important missing files. I'll study how to compile them as well.

By the way, on the wiki, you write "Microsoft Platform SDK" (aka Microsoft Windows SDK). But are you sure it is required? I haven't installed it for building the vcproj.

[clsid]

The Platform SDK is not needed. Visual Studio comes with its own SDK.

[fastplayer]

albain, you've made it into the news section of heise.de! Congrats! :)
Heise is the German publisher of the very reputable PC magazine "c't".
Here's the link: Windows 7 blockiert Codecs von Drittanbietern (http://www.heise.de/newsticker/Windows-7-blockiert-Codecs-von-Drittanbietern--/meldung/135209)
I'l post a link to the English translation, once it gets available.

[albain]

Good news :)

The most buzz we make, easier it will be to make Microsoft change his mind

[STaRGaZeR]

Is there a faster way of compiling all the stuff that requires GCC (libavcodec, ffmpeg-mt, etc.) that manually going to the required folder in MSYS and running the makefile?

[Thunderbolt8]

I know why I stick to XP. vista and 7 just seem to be useless lulz.

[clsid]

Is there a faster way of compiling all the stuff that requires GCC (libavcodec, ffmpeg-mt, etc.) that manually going to the required folder in MSYS and running the makefile?
You don't need MSYS. You can also run "make" from the windows command prompt if you use my MinGW32 installer.

[STaRGaZeR]

Cool, it works just fine. BTW it's impossible to make ICL builds with VS2008 Express Edition if anyone is interested.

[Amour]

Good to know, Stargazer. :)

I haven't installed MinGW32 yet, and I am first trying with VS2008 to compile the projects. Unfortunatly, for the following file I get multiple errors:
\trunk\src\codecs\x264\common\macroblock.c

Here are the first errors (there are a few more similar):
.\common\macroblock.c(842) : error C2143: syntax error : missing ';' before 'type'
.\common\macroblock.c(843) : error C2143: syntax error : missing ';' before 'type'

And the related lines:
int buf_hpel = (h->param.i_width+48) * sizeof(int16_t);
int buf_ssim = h->param.analyse.b_ssim * 8 * (h->param.i_width/4+3) * sizeof(int);

[Leak]

I haven't installed MinGW32 yet, and I am first trying with VS2008 to compile the projects. Unfortunatly, for the following file I get multiple errors:
\trunk\src\codecs\x264\common\macroblock.c
I'm pretty sure that's because nobody has been using the ff_x264 solution that's been last touched about 900 revisions ago for a long time.

Compiling it with GCC works fine...

np: SCSI-9 - Vesna, Lastic & Elliott (Easy As Down)

[haruhiko_yamagata]

You don't need MSYS. You can also run "make" from the windows command prompt if you use my MinGW32 installer.
I use MSYS. Without MSYS, what do you use as an alternative of 'rm'.

[mark0077]

Hi, Just playing around with building ffdshow also. I can compile fine now but where can I find the command to create the installer so I can test any changes I may make.

Also thanks haruhiko for fixing 95% of my dvd menu problems. Only some slight delays now, mostly when using external mpeg2 decoder. But its still perfectly usable now.

[jmartinr]

Subtitle Problem.

I'm sorry to say that "horizontal position 7%" with "alignment left" doesn't work as expected in revision 2815. The alignment does not make any difference now. It did work in revision 2737.

[Leak]

Hi, Just playing around with building ffdshow also. I can compile fine now but where can I find the command to create the installer so I can test any changes I may make.

Also thanks haruhiko for fixing 95% of my dvd menu problems. Only some slight delays now, mostly when using external mpeg2 decoder. But its still perfectly usable now.
Install InnoSetup then open the ffdshow_installer.iss file in bin\distrib\InnoSetup with it, maybe update the version and date at the top and hit "Compile" and "Run"...

np: Sylvain Chauveau - Nuage III (Pop Ambient 2009)

[STaRGaZeR]

Good to know, Stargazer. :)

I haven't installed MinGW32 yet, and I am first trying with VS2008 to compile the projects. Unfortunatly, for the following file I get multiple errors:
\trunk\src\codecs\x264\common\macroblock.c

Here are the first errors (there are a few more similar):
.\common\macroblock.c(842) : error C2143: syntax error : missing ';' before 'type'
.\common\macroblock.c(843) : error C2143: syntax error : missing ';' before 'type'

And the related lines:
int buf_hpel = (h->param.i_width+48) * sizeof(int16_t);
int buf_ssim = h->param.analyse.b_ssim * 8 * (h->param.i_width/4+3) * sizeof(int);

Forget about VS2008 for the GCC stuff, just install clsid's MinGW32 installer and from the command prompt go to each project folder and run "make". You can cook a simple .cmd and compile everything by just double-clicking it. Using InnoSetup is trivial.

BTW developers, I've noticed that my build of rev2812 has different file sizes for almost all .dll's compared to clsid's, some are bigger and some are smaller, while working just fine. Any reason for this?

[haruhiko_yamagata]

Subtitle Problem.

I'm sorry to say that "horizontal position 7%" with "alignment left" doesn't work as expected in revision 2815. The alignment does not make any difference now. It did work in revision 2737.
I have fixed at rev 2816.

[jmartinr]

I have fixed at rev 2816.

:thanks:

[clsid]

I use MSYS. Without MSYS, what do you use as an alternative of 'rm'.
The "UnxUtils" item in my MinGW pack installs rm.exe to the bin dir, which can be called from the command prompt :)

BTW developers, I've noticed that my build of rev2812 has different file sizes for almost all .dll's compared to clsid's, some are bigger and some are smaller, while working just fine. Any reason for this?I use ICL for compiling a couple of files (libmad, libfaad, libdts, etc) so that should explain the difference in size.

[haruhiko_yamagata]

BTW developers, I've noticed that my build of rev2812 has different file sizes for almost all .dll's compared to clsid's, some are bigger and some are smaller, while working just fine. Any reason for this?
You don't have to worry about it as long as it is working fine. It depends on the version of libraries, hearer files and compilers. In this complicated project, it is hard to match all of them completely.

[mark0077]

BUG: I notice recently that my keyboard shortcut in ffdshow CTRL+ALT+D for enabling / disabling de-interlacing, now causes ffdshow and mpc-hc to crash. Crash doesn't happen when manually clicking de-interlacing on or off so I imagine the issue is with the shortcut somehow.

[STaRGaZeR]

OK, thanks. rev2812 ICL11 build: http://www.zshare.net/download/57712418624f949b/

After rev2812 compiling with ICL is not possible because it complaints about operand types being incompatible in files coming from the subtitle branch:

http://thumbnails12.imagebam.com/3088/6ee08d30874987.gif (http://www.imagebam.com/image/6ee08d30874987)

[haruhiko_yamagata]

BUG: I notice recently that my keyboard shortcut in ffdshow CTRL+ALT+D for enabling / disabling de-interlacing, now causes ffdshow and mpc-hc to crash. Crash doesn't happen when manually clicking de-interlacing on or off so I imagine the issue is with the shortcut somehow.
OK, it's a bug in short OSD. I'll fix this.

[haruhiko_yamagata]

OK, thanks. rev2812 ICL11 build: http://www.zshare.net/download/57712418624f949b/

After rev2812 compiling with ICL is not possible because it complaints about operand types being incompatible in files coming from the subtitle branch:

http://thumbnails12.imagebam.com/3088/6ee08d30874987.gif (http://www.imagebam.com/image/6ee08d30874987)

Please try this (http://www.nabble.com/BOOST_FOREACH-not-compiling-with-Multindex-containers,-Intel-Compiler-version-11-td20541659.html).
It's up to boost or Intel.

[STaRGaZeR]

Please try this (http://www.nabble.com/BOOST_FOREACH-not-compiling-with-Multindex-containers,-Intel-Compiler-version-11-td20541659.html).
It's up to boost or Intel.

Yes, ICL10.1 doesn't have the problem. I will use it for the time being. Thanks.

[Amour]

haruhiko_yamagata, could you allow registered users to create new pages on the wiki? Thanks.

[ikarad]

I would like to know if the bugs of ffdshow-Mt will be soon corrected or not because in my blu-ray there is lot of bugs?

[haruhiko_yamagata]

haruhiko_yamagata, could you allow registered users to create new pages on the wiki? Thanks.
OK, updated permission.

[fastplayer]

haruhiko_yamagata, could you allow registered users to create new pages on the wiki? Thanks.
Wiki is down for "maintenance". Try again in half an hour.

[mark0077]

Just did a re-install of vista 64 lastnight and was playing some 1080p vc-1 files. Installed ffdshow and decided to try its vc-1 libavcodec decoder again to see if I was getting the terrible frame rate.

Yes I still get the problem with build 2815. Its MUCH better when "Drop frame on delay" is disabled as before. I get no frame drops recorded in mpc-hc. I am only getting 18% cpu usage, almost identical to the mpc-hc decoder. The only difference is terrible performance, looks like 10fps instead of 24.

Anyone know what might be wrong with both
vc-1 terrible performance compared to mpc-hc decoder even though same cpu usage.
"Drop Frame On Delay" causing more slowness even though no frame drops recorded.

[clsid]

I would like to know if the bugs of ffdshow-Mt will be soon corrected or not because in my blu-ray there is lot of bugs?You would have to ask Mr VacBob, he is the developer of ffmpeg-mt.


@mark0077
Do you get the same problem if you play those files in GraphStudio or GraphEdit? Just to rule out MPC related issues.

[mark0077]

You would have to ask Mr VacBob, he is the developer of ffmpeg-mt.


@mark0077
Do you get the same problem if you play those files in GraphStudio or GraphEdit? Just to rule out MPC related issues.

Neither of those programs can connect to my remote graph, no graph appears.... I have tried mpc-hc beliyaals build and normal one, using ever and evr-cp.... Strange thing is the lack of reporting of dropped frames. I would say over half the frames are dropped but not being recorded.

EDIT: OK I tested with reclock on and off, no difference BUT I notice something in reclock that may indicate where the problem is. Decoding in mpc-hc, reclock says it finds the frame rate 23.97fps. But decoding using libavcodec or wmv9 decoders in ffdshow, reclock doesn't know the frame rate..... This may be something to do with the problem.... I don't know what though, do you think this is ffdshow or mpc-hc related?

[clsid]

I meant letting GraphStudio do the graph building and playback. So no use of MPC at all. Then you can also manually alter the filter chain, for example to remove reclock.

[mark0077]

I meant letting GraphStudio do the graph building and playback. So no use of MPC at all. Then you can also manually alter the filter chain, for example to remove reclock.

This might take a while, been ages since I played with graph editing, not sure what splitter to split a .ts file..... Can any of you test vc-1 internal decoders with mpc-hc?

[ikarad]

You would have to ask Mr VacBob, he is the developer of ffmpeg-mt.


.

Do you have e-mail of Mr VacBob?