New ffdshow build (?)

[haruhiko_yamagata]

I can also reproduce it with ffdshow before rev601. Without "Allow YV12 (fastest)" enabled, Crystal Player cannot play video with YV12 color space like rmvb, which quite puzzled me. I have no idea what's the problem?

Furthermore, with "Allow YV12 (fastest)" enabled in Crystal Player and only allow YV12 output in ffdshow settings, it becomes not only freezing but also take over 90% cpu power.
The problem is fixed at rev 613. My binary is available for testing.

[Anima123]

Thanks Mr.Q

I've tried your latest build, it works without enable "queue output samples" option within ffdshow. Since that was not needed with Crystal Player which has its own buffer mechanism, so it's the solution.

[fastplayer]

What is the audxlib.dll good for? Which one of the audio codecs is using it?

[Episode]

It's for the Aud-X (http://www.aud-x.com/) 5.1 channel Mp3 decoding

[fastplayer]

I don't see any references to Aud-X in the audio codecs properties. Is it used at all?

[Inventive Software]

It's only used if you have an Aud-X encoded MP3 stream. http://www.aud-x.com will tell you more about Aud-X.

[foxyshadis]

Hm, I don't have audx.dll or whatever it is, I don't think clsid packages it. But it's supposed to be one of the options for mp3 decoding, iirc, since it piggybacks off a normal mp3. (It's somewhat similar to dolby 5.1 in that the backward-compatible downmix is listenable as well.)

[F_L_C]

Revision 602 - Directory Listing
Modified Thu Nov 30 13:28:23 2006 UTC (3 days, 21 hours ago) by h_yamagata
Bug fix : subtitle : fast rendering on UNICODE build was garbling.

This fix is causing Zoomplayer 4.51 to crash when subtitles are enabled w/ default settings. The popup says graphedit is the cause and the WinXP event viewer says ntdll.dll is the source. These crashes occur with Q rev619 and clsid rev610. Crashes do not occur w/ clsid rev598 because the fix was not implemented yet.

[haruhiko_yamagata]

Revision 602 - Directory Listing
Modified Thu Nov 30 13:28:23 2006 UTC (3 days, 21 hours ago) by h_yamagata
Bug fix : subtitle : fast rendering on UNICODE build was garbling.

This fix is causing Zoomplayer 4.51 to crash when subtitles are enabled w/ default settings. The popup says graphedit is the cause and the WinXP event viewer says ntdll.dll is the source. These crashes occur with Q rev619 and clsid rev610. Crashes do not occur w/ clsid rev598 because the fix was not implemented yet.
It works for me. What kind of subtitle do you use?
Could you upload the sample?

[F_L_C]

I spoke too soon about clsid rev598 not being affected...it just crashed. The subtitles are English and is for an xvid video. They are of the form .idx and .sub. The event viewer says:

Faulting application zplayer.exe, version 4.5.1.0, faulting module ntdll.dll, version 5.1.2600.2180, fault address 0x00011c48.

Sorry, I can't upload the file because it exceeds the forum limit (it's 1.5MB RAR).

[F_L_C]

I have uploaded it to rapidshare:

http://rapidshare.com/files/6006335/subsample4Q.rar.html

[haruhiko_yamagata]

I have uploaded it to rapidshare:

http://rapidshare.com/files/6006335/subsample4Q.rar.html
Thank you, but I still can't reproduce the problem. Where does it crash? at the first subtitle? Does the host sample movie matter?
I reset all ffdshow settings except for the subtitle file. Is it reproducible by the default settings?

[F_L_C]

I just tried drevil's latest sse build and same crash as yours and clsid. It crashes a few minutes into the video at almost the same exact scene (frame). The subtitle filter is at default settings; I just ticked the enabled box that's all. If I disable it, there is no crash at the scene or anywhere else.

The timeline in ZP shows 11:04 at the scene when it crashes and the words being displayed says "The move affects 37,000 workers in 160 countries..." It either crashes at this exact scene or immediately after.

[haruhiko_yamagata]

I just tried drevil's latest sse build and same crash as yours and clsid. It crashes a few minutes into the video at almost the same exact scene (frame). The subtitle filter is at default settings; I just ticked the enabled box that's all. If I disable it, there is no crash at the scene or anywhere else.

The timeline in ZP shows 11:04 at the scene when it crashes and the words being displayed says "The move affects 37,000 workers in 160 countries..." It either crashes at this exact scene or immediately after.
Thank you. Now I can reproduce the problem.
The error comes from the destructer of TrenderedSubtitleLines in ffdshow.ax/Tfont.h.

[F_L_C]

I have no idea what that means, lol. Bless the holy mother that people like you, clsid, and drevil exist. Thank-you.

[Mangix]

it means there's an error in the code. now we just have to wait for a fix(if it isn't fixed yet :))

[Isochroma]

An item of interest to ffshow developers has this morning been posted on the CoreAVC thread here (http://forum.doom9.org/showthread.php?p=911912#post911912).

The post details how an unusual feature of CoreAVC tweaks the VMR9 renderer - which normally clamps the luma of any YUV inputs to TV range - to output full range with YUV input.

ffdshow's Levels filter can be used to convert videos encoded in TV range to PC range. However, if the output is set to any YUV format, it will continue to show TV range using the VMR renderers, due to the clamping behavior. Some might be fooled into thinking that the Levels filter is working because some parts of the image get brighter, but the brightest whites will still be at level 235, and the blackest blacks at 16.

The article continues in greater depth; it is proposed that the CoreAVC developers reveal the specific code used to tweak the VMR renderers, so that ffdshow and others may incorporate the code to allow full range passthrough for significant performance improvement without significant coding complexity increase.

[MatMaul]

ffdshow's Levels filter can be used to convert videos encoded in TV range to PC range. However, if the output is set to any YUV format, it will continue to show TV range using the VMR renderers, due to the clamping behavior. Some might be fooled into thinking that the Levels filter is working because some parts of the image get brighter, but the brightest whites will still be at level 235, and the blackest blacks at 16.

Sorry but I don't understand the problem.
If I do a 16-235=>0-255 conversion like that :

http://img396.imageshack.us/img396/3785/ffdshowlevelsss1.png

where is the problem ?
anyone can explain that more clearly (I don't understand very well "clamping") or in french by MP if a french who understood read me :) .

Thanks

EDIT :

I think I understand !! :)

if I remap like that, cool I have the good luminance but I lose all datas in 0-16 and 235-255 in the remaped levels

So if I take the original YUV levels, I see only around 30-218 range instead of 16-235 range. :(

[Isochroma]

If your source is PC range or you expand a TV source to full range using the Levels filter, ffdshow sends full range data to the downstream renderer (assuming it is VMR9). Also assuming you are using a YUV output format in ffdshow (RGB always passes PC range all the way thru the pipeline - so we won't bother with that case here), everything's ok at this point.

Next, the VMR9 renderer receives YUV frame data from ffdshow's output pin on its input pin. However, because it is YUV, a little piece of code in the VMR9 renderer clamps any values outside of the 16-235 range. Then the frame is sent to your video card. So expanding the range in ffdshow is an exercise in futility because VMR9 will lop of the top and bottom anyway like a chainsaw.

The VMR9 renderer assumes that because it is receiving YUV data on its input pin, that the luma ought to be clamped to TV range. That is the problem. Range and color space representation are two entirely separate matters, not to be confused. Both RGB and YUV representations can contain the full range 0-255 for luma.

Any YUV frames passed to the input pin of VMR9 will be clamped to TV range, EXCEPT the magic CoreAVC when the "Fix VMR9 levels" checkbox is checked and a YUV format is selected for output (remember RGB is never clamped by VMR so the checkbox doesn't apply there). The CoreAVC filter must be directly connected to VMR for this to work - no filters in between - because it does some very special tweak that noboby but the Core team understand.

CoreAVC does not itself modify the frame luma range. That would be useless, because VMR9 renderer would clamp it anyway when it is delivered to the input pin. Rather, CoreAVC tweaks the renderer itself using either an undocumented switch or hack to force the renderer to pass full PC range even though its input pin is connected to a YUV source.

If ffdshow used this trick, you could expand your levels and output in any YUV format (such as MPEG-4's native YV12) and know that the VMR won't clamp it back to TV. This means much lower CPU usage, because the only way to get PC levels with VMR from ffdshow right now is RGB output (software YUV -> RGB conversion).

[foxyshadis]

Doesn't happen on ATI cards, so :bigshrug: here. At least, not on my 9200 and x1300pro. (Haven't tested the TNT2. Hope I never have to.) When dealing with display yuv levels, you should never claim that it happens some way and no other, because the combinations of gpu, drivers, and who knows what else lead to an almost random nature to it. You can certainly list the cards and driver versions you've tested on that your observations apply to. In this case, I'd really like to know how your system is set up so that it might be possible to duplicate by someone who can debug it.

The problem is that the video driver is what implements VMR9, not directx and not the OS.

Anyway, thanks for bringing that interesting behavior to our attention. I'll see if I can find anything about this signaling in the MS documentation, or online if it isn't here.

I'm just waiting for Haali's renderer to get a PC/TV levels switch, then I can finally quit screwing with levels.

[Isochroma]

As CPUs become more powerful, it becomes less important anyway. Using RGB formats as output guarantees that nothing will be altered and full PC levels passed to the display.

As far as I know, the Video Mixing Renderer is a feature of the operating system, not the graphics driver. I'm probably wrong... here's some fascinating documentation on the VMR: Using the Video Mixing Renderer (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directshow/htm/usingvmrmixingmode.asp).

[foxyshadis]

VMR7/9 are the interface to the graphics driver's actual renderer implementation. The interface is provided by DirectX, specifying how they communicate. Actually, most of DirectX is just interfaces and methods to enumerate supported interfaces, along with housekeeping stuf, it acts as a glue code between driver code and application code. I'm sure you know that, but anyway, that's all VMR9 is, which is why it works so differently with different drivers; the only complicated things VMR (renderless) does is timing and delay messages. I'd appreciate it more if there was one single reference implementation of yuv->rgb because at least then there's none of this confusion and bugginess.

May I ask whether you're using Windowed or Renderless modes (or Windowless)? Or both/all three? I'm home now so I'm scrounging all the docs looking for such a tweak. Still like to know what card/driver family you have.

[Isochroma]

Tested using MPC's windowed and renderless modes in VMR9. MPC doesn't support windowless mode, so far as I can tell. Not sure how VMR7 works in this regard, stopped using it some time ago because VMR9 renderless provided superior performance (lower CPU) using my FX5200 AGP8X. And I'm using Forceware 84.21; the 9x.xx series drivers are a disaster, IMHO.

I've emailed Avery Lee with the link to the CoreAVC thread post. I'm very sure he uses a 6-series GeForce for his debugging sessions. He was the first to post about the strange behavior of VMR9 and levels: YCbCr levels and the Video Mixing Renderer 9 (http://www.virtualdub.org/blog/pivot/entry.php?id=92)

Here's a comment posted after the article by Blight:

"I actually asked NVIDIA about this (a long time ago, this problem is as old as DirectX 9) and they said that it’s a microsoft directive or something of that nature that the output luma range should be 16-235 (no conversion to RGB luma range), very confusing and inconsistant."

[foxyshadis]

Yeah, ATI dropped support for below 9600 around 5.8, and more recently all 9000-series, so I feel your pain there. I believe nvidia only fixed their drivers in the 91.x time. =\ So at least that gives us a target: Older cards on the older drivers. Hmm. I wonder if it's possible to find out what options coreavc sets by querying directshow as it runs.

[MatMaul]

Yeah, ATI dropped support for below 9600 around 5.8, and more recently all 9000-series, so I feel your pain there. I believe nvidia only fixed their drivers in the 91.x time. =\ So at least that gives us a target: Older cards on the older drivers. Hmm. I wonder if it's possible to find out what options coreavc sets by querying directshow as it runs.

So with a x700 with last drivers, if I do a 16-235=>0-255 conversion, there are no clamping ?
how can I verifie that ?

[SeeMoreDigital]

I've emailed Avery Lee with the link to the CoreAVC thread post. I'm very sure he uses a 6-series GeForce for his debugging sessions. He was the first to post about the strange behavior of VMR9 and levels: YCbCr levels and the Video Mixing Renderer 9 (http://www.virtualdub.org/blog/pivot/entry.php?id=92)Hmmmm....

This was one of the reasons why I developed my own RGB (0-255) test cards..... I could not understand why there was so much colour and contrast difference between each one of MPC's video display output modes.... If say, I play a test card with 255:255:255 (white) in it and take a screen grab... What I'm seeing is grey. But with MPC's internal capture facility (set to .bmp), it's white!

Hope that makes sense?!

[foxyshadis]

So with a x700 with last drivers, if I do a 16-235=>0-255 conversion, there are no clamping ?
how can I verifie that ?

With VMR modes you should be able to make a screencap and test that. You can also play two instances at once, one in rgb out and one in yuv out, and they should match in brightness. The method I usually use is less strict - since I get black borders on most stuff, I just ensure that black edges match the black borders when watching. Any fade-to-grey will jump right out. Obviously if you try to correct it in ffdshow levels and it doesn't go away, just gets distorted, it's clamping - you will need to use the full luma range option though, or it'll be the levels filter itself doing the clamping.

You should ensure your monitor is something near a reference brightness, where you can discern both near-blacks and near-whites in some graphics software.

I already know that VMR9 will do PC-mode passthrough (no clamping) on mine, in all yuv modes, and Haali's will do TV-mode these days (it used to be PC-mode as well, maybe it sets some bits somewhere now, or one of my many recent &#!$ driver updates farged it up).

[F_L_C]

haruhiko_yamagata: I don't know if this will help you, but if I disable the ffdshow sub filter and use the one that ZP recommends: http://www.inmatrix.com/zplayer/formats/vsfilter.shtml

then there are no crashes. But the one ZP recommends screws up the derived aspect ratio of the xvid and I cannot figure out how to make it work/look like ffdshow's sub filter. Hope you or your clever ffdshow friends can straighten this out soon.

[Egh]

Good :) At least someone finally grabbed attention of the developers for that issue! Since I've been working with the fullrange encoded videos for a while, i've noticed strange behaviour on VMR9+YV12 already.

But it was fixed thanks to DW help a while ago: http://forum.doom9.org/showthread.php?p=912584#post912584

Taking this as an opportunity, and since many devs will hopefully test this issue, would like to remind that videos can be fullrange encoded already. Does ffdshow work correctly with them if you convert them to RGB32?

I didn't bovver to hack into the relevant code, but, in my n00bish opinion, RGB32 correction is wrong in that case. The function which does the conversion actually has a parameter for a fullrange video, but i wonder if that parameter is ever set if the fullrange video is indeed produced by the decoder.

[haruhiko_yamagata]

haruhiko_yamagata: I don't know if this will help you, but if I disable the ffdshow sub filter and use the one that ZP recommends: http://www.inmatrix.com/zplayer/formats/vsfilter.shtml

then there are no crashes. But the one ZP recommends screws up the derived aspect ratio of the xvid and I cannot figure out how to make it work/look like ffdshow's sub filter. Hope you or your clever ffdshow friends can straighten this out soon.
fixed at rev625. ffdshow's subtitle is not bad. I prefer Subtitles - Vobsub - Smoothing method - full (Slowest).
It looks better than the default one(swscaler gaussian).

[SeeMoreDigital]

Can some of you guys play the following Test Card Samples (http://82.10.220.174/Uploaded_Files/Doom9_Forum_files/MPC_Test_Card_Samples.zip) with MediaPlayer Classic (and FFdshows MPEG-4 decoder filter) and confirm whether the "white" in the 1280x720 sample is more or less white than in the 1024x576 sample?


Cheers

[fastplayer]

What exactly is delvcr80.exe removing when being executed? Only VC8 runtime DLLs in the ffdshow directory, right? I noticed it in the {tmp} directory. As far as I understand it is only effective when using NSIS builds but the comment in the Inno script suggests that it'll be ported to Inno, too.

[haruhiko_yamagata]

What exactly is delvcr80.exe removing when being executed? Only VC8 runtime DLLs in the ffdshow directory, right? I noticed it in the {tmp} directory. As far as I understand it is only effective when using NSIS builds but the comment in the Inno script suggests that it'll be ported to Inno, too.
Yes, it just remove old NSIS's msvcr80. It is executed only when the user is current ly using NSIS build and only effective if the user have ever used my build. Briefly ,it is executed only once.
Porting it to Inno script is easy, but I can't deny a posibility of serious bug. I prefer used code, at least untill our first beta.

[fastplayer]

Thanks for explaining this!
I noticed the file in drevil's build even though he's using Inno and 7.1 runtime.

Porting it to Inno script is easy, but I can't deny a posibility of serious bug. I prefer used code, at least untill our first beta.
You mean deleting the global assembly in the WinSxS directory? :D

[n3w813]

...
Next, the VMR9 renderer receives YUV frame data from ffdshow's output pin on its input pin. However, because it is YUV, a little piece of code in the VMR9 renderer clamps any values outside of the 16-235 range. Then the frame is sent to your video card. So expanding the range in ffdshow is an exercise in futility because VMR9 will lop of the top and bottom anyway like a chainsaw...


First of all, is YV12 a subgroup of YUV colorspace? Or are they 2 totally different colorspace (ie rgb vs yv12)?

I'm a newb when it comes to video related stuff, but I'm offering my experience here.

I'm using a Nvidia 7800GT with 97.31 drivers in WinXP SP2.
This is how I use ffdshow/vmr9.

DVD mpeg2 -> Nvidia mpeg2 decoder -(yv12)> ffdshow denoise/resize/sharpen -(yv12)> vmr9 renderless.

In my testing, using GetGray DVD calibration disc, 0-16 BTB and 236-255 WTW are being passed to vmr9 then to my tv through DVI. To verify, I turn up the brightness on my tv, and I can see BTB bars.

With CoreAVC 1.1, if I CHECK the 'Fix VMR9 Range' checkbox, 0-16 and 236-255 actually gets chopped off!! Weird huh, it's actually the exact opposite of what you are describing. :confused:

I never thought twice about trying to understand why. :p I know that my video is outputting the correct levels. But I guess this is a good time to find out the bottom of this.

My MCE box with 6800GT is experiencing the exact same thing.

P.S. I did use the vmrcccstatus=0x1 registry setting as suggested in Nvidia's driver pdf to supposedly fix video level issue. But I don't know if it is required, I think it may be defaulted to 0x1. Also, the description in the pdf is wrong, I think. It says to set to 0x1 for 16-235, and 0x3 for 0-255. I've tested this; if you set to 0x3, you DO NOT get BTB or WTW info. It is the opposite here also.

I'm already confused as it is with all this video level/pc level/colorspace stuff, and then manufactures come in and confuse me some more. :mad:

[Egh]

With CoreAVC 1.1, if I CHECK the 'Fix VMR9 Range' checkbox, 0-16 and 236-255 actually gets chopped off!! Weird huh, it's actually the exact opposite of what you are describing. :confused:


I guess that's CoreAVC bug. Since I've noticed some time ago that if the video is already fullrange, with --fullrange VUI parameter (in h264 stream itself) coreavc changes already present PC levels into TV ones, i.e. does exactly the opposite of what is needed :)

btw, what is that calibration disc?

[Jeremy Duncan]

http://calibrate.tv/

[haruhiko_yamagata]

You mean deleting the global assembly in the WinSxS directory? :D
No, it just delete msvcr80.dll and some related things from plugin directories and registry.

[clsid]

Thanks for explaining this!
I noticed the file in drevil's build even though he's using Inno and 7.1 runtime.It is supposed to be in the Inno packs ;) The Inno packs are silently removing the files installed/created by the old NSIS ffdshow installers.

I'll port the code sometime soon. Most people don't like hidden processes.

[SeeMoreDigital]

Isochroma posed the following in the CoreAVC thread yesterday: -
84.21 may clips VMR9 outside 16-235 over DVI, Latest Nvidia driver clips (http://forum.inmatrix.com/index.php?showtopic=4387)

Quote from the 84.21 driver release notes:

"Video color-space range for DVI-only1 outputs is erroneously set to standard mode (16-235) instead of extended mode (0-255).

A new detection feature to apply Standard CSC mode to TV outputs (including NTSC, PAL, 480i, and 576i), included DVI-only outputs by mistake.

Note: The driver correctly applies extended mode to analog outputs, and standard mode to TV outputs (including NTSC, PAL, 480i, and 576i).

A future driver release will correct this and apply the extended-mode color space to DVI-only outputs."

1. “DVI-only” means only one display is connected, and it is to the DVI output.So it would seem the differences we see in the colour output are most likely caused by discrepancies in Nvidia handling of certain sized input resolutions.... Bummer!

[cc979]

Can some of you guys play the following Test Card Samples (http://82.10.220.174/Uploaded_Files/Doom9_Forum_files/MPC_Test_Card_Samples.zip) with MediaPlayer Classic (and FFdshows MPEG-4 decoder filter) and confirm whether the "white" in the 1280x720 sample is more or less white than in the 1024x576 sample?


Cheers

i tested, all whites are the same in vmr9/overlay with colourspace yv12/rgb32/nv21

nvidia driver 93.71, 'Do not use colour temperature correction', on the adjust video colour settings - otherwise i got colour problems in overlay mode

[SeeMoreDigital]

i tested, all whites are the same in vmr9/overlay with colourspace yv12/rgb32/nv21How did you test. Was it "visually" or did you make a "screen-grab" and perform a spot test?

invidia driver 93.71, 'Do not use colour temperature correction', on the adjust video colour settings - otherwise i got colour problems in overlay mode I don't seem to be able to find this setting....


Cheers

[dk75]

First of all, is YV12 a subgroup of YUV colorspace? Or are they 2 totally different colorspace (ie rgb vs yv12)?
It's subgroup of YUV, 4:2:0 YUV to be exact, while YUY2 is 4:2:2 YUV.

[haruhiko_yamagata]

clsid uploaded a candidate (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=213872) for our first beta.

clsid, drevil_xxl, foxyshadis and I talked each other and decided to launch our first beta. Please test ffdshow_rev641_20061206_clsid.exe. When the build is confirmed to be stable, the package will be renamed "ffdshow official release beta1 revision 641 20061206" or something. Packages for each builders will be renamed like "Nightly builds by ...".

[F_L_C]

I have installed clsid's rev641 and can confirm the subtitle crash bug that Q and I were discussing has been fixed. I had no other issues with ffdshow. Thanks once again and congrats to you all for the stable release.

[MatMaul]

@clsid : can we have some information about the compilation of the beta, like which component is compiled with which compiler ?

[clsid]

Same compilers as previous builds. Details of compilers used can be found on sourceforge. Click on the clipboard icon.

[fastplayer]

I have installed clsid's rev641 and can confirm the subtitle crash bug that Q and I were discussing has been fixed. I had no other issues with ffdshow. Thanks once again and congrats to you all for the stable release.
This bug apparently affected me too. I just checked 2 AVI files that are vobsub'ed and would crash in 8 out of 10 cases at one specific scene and now they don't. I didn't report this bug because I couldn't reproduce it 100% and the crash dump never mentioned anything ffdshow-related. Guess I was wrong... :/
Anyway, thanks a lot for the fix! And build 641 behaves great so far! :thanks:

[MatMaul]

Same compilers as previous builds. Details of compilers used can be found on sourceforge. Click on the clipboard icon.
thanks !

[Anima123]

There's a new build rev646 out (marked as "proposed stable"). Thanks for developers.