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.

[cc979]

How did you test. Was it "visually" or did you make a "screen-grab" and perform a spot test?

I don't seem to be able to find this setting....


Cheers

i took screen grabs for all the modes apart from overlay

the colour correction is in video/television panel using advanced settings

http://img392.imageshack.us/img392/8835/clipboard1de5.th.png (http://img392.imageshack.us/my.php?image=clipboard1de5.png)

[fastplayer]

@clsid:
I noticed in your install_script.iss that you ship 2 versions of ffdshow.ax and ff_wmv9.dll. I suppose both are compiled for different CPUs but where in your script is the CPU detection part? Or is this done automagically by the Inno installer?

Edit: Never mind. One file is built with ANSI, the other with Unicode support.

[clsid]

edit: nevermind

[fastplayer]

In case someone missed it:
Build 654 aka proposed stable is out!
http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=213872&release_id=469134

[Romario]

I downloading it now!!!

clsid, I don't know how to report bug to ffmpeg devs. So, can you, please, instead of me, report x264 interlaced bug to them.

Thanks.

I think that when this bug get fix, ffdshow devs can declare stable build.

[LoRd_MuldeR]

I just noticed that the German installer says: "Unverarbeitete Videodaten" (unprocessed videodata)
shouldn't it be: "Unkomprimierte Videodaten" (uncompressed videodata)
instead?

[fastplayer]

Since eragon4ever translated "RAW Audio" with "Unkomprimierte Audiodaten", he should change it for consistency's sake. PM him.

[Eragon4ever]

No need for PM. I'll change it.

[fastplayer]

That was fast! :eek:
Thanks!

[clsid]

I think I have found a bug in the ffdshow subtitle filter.

If I slow down the playback speed of the video in Media Player Classic, then the subtitles will continue to play at their normal speed. So the subs go faster than the video and synchronization is lost. After changing the playback speed back to normal, the subtitles will synchronize and continue at the correct position.

[fastplayer]

For me the subtitles play faster than in normal mode.

[Px]

Downloaded Build 654 aka proposed stable, only remaining problem - with vfw encoder

[foxyshadis]

Er, what error would that be, exactly? It doesn't crash or corrupt anything for me.

[Px]

Er, what error would that be, exactly? It doesn't crash or corrupt anything for me.
http://forum.doom9.org/showthread.php?p=900177#post900177
8) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2, h.263, H.261 and DV. VirtualDub 1.16.16 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)".

[ilpippo80]

I've tested ffvfw+virtualdub 1.6.16 reencoding an avi file and a mpeg1 file. I used "full processing mode" for video and "no audio" settings. The ffvfw were the default ones, with one step and constant bitrate.
Here's my results:

- The following encoders gave me the error "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100):"
MPEG-4 MPEG-1 MPEG-2 (with the avi but no problems with the mpeg1)
H261
H263
DV
ISO MPEG-4 Video V1
Windows Media MPEG-4 Video V3
Windows Media Screen V7
Windows Media Video 9 Image
Windows Media Video 9 Image v2

- the mjpeg files created crashed with ffdshow decoder (in mpc) but not vlc.

- the wmv8 files created gave me corrupted video with both ffdshow decoder and vlc

[_xxl]

Sample file please.
the mjpeg files created crashed with ffdshow decoder (in mpc) but not vlc.
What version are you using?This bug was fixed in rev 400.
- The following encoders gave me the error "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100):"
MPEG-4 MPEG-1 MPEG-2 (with the avi but no problems with the mpeg1)
H261
H263
DV
ISO MPEG-4 Video V1
Windows Media MPEG-4 Video V3
Windows Media Screen V7
Windows Media Video 9 Image
Windows Media Video 9 Image v2

EDIT:
H263+ is working?
I don't think that it is possible to reencode to any video codec? :confused:

[clsid]

sample input file (http://www.mytempdir.com/1105695)

[ilpippo80]

I'll upload the files later this evening, anyway I'm using rev641_20061206_clsid_icl9

[egandt]

Using the rev654 20061207 I can not resize as the aspect ratios is always 9x16 and not source derived, I've tried 3 builds from the 7th all with the same MO. The input resolution is 640x480 resize is set to "no aspect ratio correction", the output video is always 16x9 no matter what setting is used in Zoomplayer (which has had no changes since I upgraded from an 11/17 build). Note: turning off resize in ffdshow resolves the issue.

Also flawed in the rev601_20061130-sse2.

ERIC

[ilpippo80]

Sorry for the lack of news, I've been a bit busy yesterday...
Anyway, here's the files:
http://www.sendspace.com/file/yk37wq

I just made some other tests, and I've seen that the mpeg1,2,4 compression problem is with some avi files and not with others, while I had no problems with mpg files so far...

H263+ is working?

Yes, H263+ is working...

I don't think that it is possible to reencode to any video codec? :confused:

What do you mean?

[haruhiko_yamagata]

Using the rev654 20061207 I can not resize as the aspect ratios is always 9x16 and not source derived, I've tried 3 builds from the 7th all with the same MO. The input resolution is 640x480 resize is set to "no aspect ratio correction", the output video is always 16x9 no matter what setting is used in Zoomplayer (which has had no changes since I upgraded from an 11/17 build). Note: turning off resize in ffdshow resolves the issue.

Also flawed in the rev601_20061130-sse2.

ERIC
No aspect ratio correction means ffdshow respects the setting of "Specify size".
If you want to respect source aspect ration, you have to choose "Keep original aspect ratio".

[vlada]

I have some questions regarding default setting of ffdshow. I'm writing a beginners guide on how to set up video playback on computers with MS Windows. Of course ffdshow is here the base. I don't want to confuse the readers so I'd like to ask you a couple of questions:

1) Why are MPEG-1 and MPEG-2 not checked by default. I had some troubles with some MPEG-1 videos and ffdshow. But I never had a problem with MPEG-2 videos using libmpeg2. On the other side libavcodec always causes very choppy playback with MPEG-2. What are the reasons that MPEG-2/libmpeg2 is not enabled by default?

2) Why isn't FLAC enabled? Are there any problems?

3) Why is tremor the default decoder for Vorbis? I heard libavcodec should have higher quality. But there used to be a bug in 5.1 decoding. Is it already fixed?

4) Why is postprocessing off by default? I even can't select it in installer.

Thank you.

[fastplayer]

1) Why are MPEG-1 and MPEG-2 not checked by default. I had some troubles with some MPEG-1 videos and ffdshow. But I never had a problem with MPEG-2 videos using libmpeg2. On the other side libavcodec always causes very choppy playback with MPEG-2. What are the reasons that MPEG-2/libmpeg2 is not enabled by default?
I can only guess so... Since most people have some 3rd party MPEG2 decoder installed on their system, enabling libmpeg2 in ffdshow would override the default MPEG2 decoder which some people don't like. As for MPEG1, Windows already ships with a basic MPEG1 decoder which handles most MPEG1 videos. At least for me... :D
And most people use MPC as their default player anyway which already has libmpeg2 integrated and enabled by default. So I don't see any problems with ffdshow regarding libmpeg2...

[clsid]

Playing .flac files requires a source filter. ffdshow is only a decoder. If you install the source filter, then it also comes with a decoder.

Post-processing should never be on by default. PP is only useful for bad quality videos, and even then the best settings depend on the specific video and the users eyes and taste.

[fastplayer]

3) Why is tremor the default decoder for Vorbis? I heard libavcodec should have higher quality. But there used to be a bug in 5.1 decoding. Is it already fixed?
AFAIK, celtic_druid released once a version which had this bug fixed. I don't know if it has been incorporated into the tryouts... :confused:

[Eragon4ever]

It has been fixed it rev 4.

[Jeremy Duncan]

Since Lanczos Resizing is Multithreaded on Dual Core cpu's and not Hyperthreading ones.
What else is hyperthreaded on Dual core only and not hyperthreading cpu's, Is Queue output samples useful on Hyperthreading cpu's ?

[MatMaul]

I have tried to make a trunk folder in the repository, and I totally break the repository, sorry.

:stupid: (it's me...)

anyone who have a svn access can make a trunk folder with the development version in it please (the last non-broken version is the 674) ? like that :

/branches/ => beta1, beta 2 etc
/trunk/ => the development version

like that if anyone want only the development version he can have it without download all the branches

thanks a lot and sorry again.

EDIT : I actually try to resolv that, I think it was good in about 5 minutes. sorry...

[clsid]

uploading now

[MatMaul]

ok, I stop my own upload.

[fastplayer]

Why does ffdshow need a branch? It's not like some sort of backwards-compatibility has to be maintained like the Mozilla guys having Firefox branches for version 1.0.x, 1.5.x.x, and 2.0.0.x, or am I wrong?
Why not stay with one branch and release monthly/quarterly etc. a stable version? The decision could be based on a democratic poll here on the forums or the main developers decide among themselves which build to release.

[Eragon4ever]

This way new features can be added to trunk while fixes are in both. And maybe it will be deleted after a release and the source code will be packed?

[Mangix]

got a question here. why is the ALAC decoder not included with ffdshow? the current libavcodec has the code needed to decode ALAC but ffdshow isn't using it...

[_xxl]

got a question here. why is the ALAC decoder not included with ffdshow? the current libavcodec has the code needed to decode ALAC but ffdshow isn't using it...
http://sourceforge.net/tracker/index.php?func=detail&aid=1359547&group_id=53761&atid=471492

[fastplayer]

This way new features can be added to trunk while fixes are in both. And maybe it will be deleted after a release and the source code will be packed?
You got a point. Although most of the development work is updating ffmpeg and fixing bugs. So I'm not entirely sure if adding branches is of any advantage. Maybe I'm just too short-sighted... :D

[clsid]

I got a timeout twice during commit. MatMaul, can you upload it?

Here is the latest source code:
http://www.mytempdir.com/1109364

[MatMaul]

ok i upload now.

[haruhiko_yamagata]

Since Lanczos Resizing is Multithreaded on Dual Core cpu's and not Hyperthreading ones.
What else is hyperthreaded on Dual core only and not hyperthreading cpu's, Is Queue output samples useful on Hyperthreading cpu's ?
Yes. Resize is the only one that P4HT is excluded from multithreading.
Because P4HT does not have extra core for MMX, resizing and decoders would get little effect from multithreading.
Queue output samples does not depend on MMX and so it is best match with P4HT.

[clsid]

List of known issues in revision 684:

1) Wavpack decoder only works with lossless wavpack. Lossy and hybrid wavpack is not yet supported.
2) Some files with interlaced H.264 video don't decode properly. Sample file (http://www.egoshare.com/9dad3c13be3968c0ed977ed5cd62e25f/3rd_rock_of_sun_sampleavi.html). FFmpeg bug or perhaps a x264 VFW bug? (Reported by Romario)

Other bug reports:

3) Writing an OGM file via VFW interface creates a corrupt file. (reported by clsid)
4) FLV muxer seems to be buggy as well.
5) The following encoders do not work for me: MPEG 4, MPEG 1, MPEG 2, h.263, H.261 and DV. VirtualDub 1.6.17 gives the following error: "Cannot start video compression. An unknown error occurred (may be corrupt data). (error code -100)". At least some of these encoders do work for others? Seems to depend on the input? Sample input file (http://www.mytempdir.com/1105695). (reported by: a few people)
6) I think I have found a bug in the ffdshow subtitle filter. If I slow down the playback speed of the video in Media Player Classic, then the subtitles will continue to play at their normal speed. So the subs go faster than the video and synchronization is lost. After changing the playback speed back to normal, the subtitles will synchronize and continue at the correct position. (reported by clsid)

ToDo:

7) Add WM9 decoder passthrough
8) Update and fix SNOW support
9) Fix VMnc decoding
10) Fix VC-1 decoding
11) Update libavcodec vorbis

Other issues:

12) ICL9 builds of ffdshow.ax crash on files created by a specific old revision of x264 (don't know the rev number). These files should be very rare. Funny thing however is that the files play fine and without crash if you first play another file and then play the 'troublesome' file in the same player instance. Also no crash when using an unoptimized debug build. So this seems to be a compiler bug. Sample file (http://rapidshare.com/files/1609924/sample.mp4.html). (reported by clsid)

[MatMaul]

7) Add WM9 decoder passthrough
I don't understand this feature :o

EDIT : when I tick "VMR9 mixer mode" in MPC, queue is not actived (rev684 by clsid) : it is normal ?

[mpioner]

developers pls add suport for this http://cia.navi.cx/
How
https://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1#scripts
like http://cia.navi.cx/stats/project/ffdshow

[Liisachan]

you mean this? [ 1577522 ] ffdshow "Queue output samples" support (http://sourceforge.net/tracker/index.php?func=detail&aid=1577522&group_id=82303&atid=565651)
patch is included in celtic_druid's 611-2, tho it is reported that 611-2 has a problem about Dts

[MatMaul]

you mean this? [ 1577522 ] ffdshow "Queue output samples" support (http://sourceforge.net/tracker/index.php?func=detail&aid=1577522&group_id=82303&atid=565651)
patch is included in celtic_druid's 611-2, tho it is reported that 611-2 has a problem about Dts
I have the last celtic druid mpc.
I'm not talking of this bug.

If I haven't "vmr9 mixer mode" ticked, no problem queue is active.
if I tick "vmr9 mixer mode", I have a "not effective : the video renderer in use does not support queue."
I use vmr9 renderless as renderer.

[KoD]

Libavcodec vorbis in current ffdshow does work with 6 channel vorbis. You can look at a test file here http://www.cccp-project.net/beta/test_files/[CCCP]_Manhole_Test_Your_5.1_[revamped].mkv

There is an issue with drevil's installer (at least in build 685). It installs the ansi version of files (at least considering what the about box says) instead of the unicode ones on my Windows XP. Clsid's 684 build installs the unicode version as expected.

[LoRd_MuldeR]

I have the last celtic druid mpc.
I'm not talking of this bug.

If I haven't "vmr9 mixer mode" ticked, no problem queue is active.
if I tick "vmr9 mixer mode", I have a "not effective : the video renderer in use does not support queue."
I use vmr9 renderless as renderer.

yeah, same here!

[haruhiko_yamagata]

EDIT : when I tick "VMR9 mixer mode" in MPC, queue is not actived (rev684 by clsid) : it is normal ?
fixed at rev 682. Though it was a simple bug, I decided to enable queue in VMR9 renderless and disable in VMR9(except for renderless) for beta 1. After beta1, I'll try to enable queue in VMR9 only when it is safe.

[MatMaul]

fixed at rev 682. Though it was a simple bug, I decided to enable queue in VMR9 renderless and disable in VMR9(except for renderless) for beta 1. After beta1, I'll try to enable queue in VMR9 only when it is safe.
Are you sure ?
I have test with beta 1 and rev 684, same behaviour.

[haruhiko_yamagata]

There is an issue with drevil's installer (at least in build 685). It installs the ansi version of files (at least considering what the about box says) instead of the unicode ones on my Windows XP. Clsid's 684 build installs the unicode version as expected.
ANSI build work fine in Windows XP. It's the spec of my and drevil_xxl's builds.
If you use more than 3 languages(English, Windows version of language, another language), UNICODE build have the advantage. It may be two, if you use English version of Windows.

[haruhiko_yamagata]

Libavcodec vorbis in current ffdshow does work with 6 channel vorbis. You can look at a test file here http://www.cccp-project.net/beta/test_files/[CCCP]_Manhole_Test_Your_5.1_[revamped].mkv

Vorbis? The sample looks like dts.

[haruhiko_yamagata]

Are you sure ?
I have test with beta 1 and rev 684, same behaviour.
Yes, both beta 1 and 684 work for me. VMR9 renderless + queue, YUY2 or RGB32.

[LoRd_MuldeR]

Yes, both beta 1 and 684 work for me. VMR9 renderless + queue, YUY2 or RGB32.

Sorry, for me it does not :(

With "VMR9 (renderless)" and "VRM9 mixer mode" enabled, it says queue not supported by renderer.
With "VMR9 (renderless)" and "VRM9 mixer mode" disabled, it does queue, but I get about 1 frame each 5 seconds.
Doesn't happen when queue is off in ffdshow.

[MatMaul]

With "VMR9 (renderless)" and "VRM9 mixer mode" disabled, it does queue, but I get about 1 frame each 5 seconds.
I haven't this problem, all is ok (aboot 10 frames in queue) when "VRM9 mixer mode" is disabled.

With "VMR9 (renderless)" and "VRM9 mixer mode" enabled, it says queue not supported by renderer.
Same behaviour with me

[sillKotscha]

Vorbis? The sample looks like dts.

there are 11 sound tracks in this matroska file... try track 6

http://img151.imageshack.us/img151/5494/6iz6.png (http://imageshack.us)

[haruhiko_yamagata]

With "VMR9 (renderless)" and "VRM9 mixer mode" enabled, it says queue not supported by renderer.
OK, I can reproduce this. It's not a bug. ffdshow detects error from GetBuffer and prints like that.

With "VMR9 (renderless)" and "VRM9 mixer mode" disabled, it does queue, but I get about 1 frame each 5 seconds.
Doesn't happen when queue is off in ffdshow.
I understood that the queue still had compatibility issue.

It is too hard to fix for beta 1, because the trial to fix the problem will break the code too much.

[clsid]

Just fix it in trunk. Then it can be in beta2.


Here is an interesting topic about ffdshow:
http://forum.doom9.org/showthread.php?t=119319

[KoD]

As mentioned by sillKotscha, the sample does have a 6ch Vorbis track just that it's not the default track but the DTS one is.

Regarding Unicode and Windows. It's not a matter of how many languages are being used on the computer, but a matter of Windows function calls and how they are implemented in the dlls that come with Windows. (gdi32.dll, user32.dll, etc)

All Win32 API functions that have a string argument exist, in fact, in two flavours : WindowsFunctionA and WindowsFunctionW , in which A stands for the function that gets an ansi string argument and W stands for the function that gets a unicode string parameter.

For instance, TextOut is implemented in gdi32.dll both as TextOutA and TextOutW.

So, a call in my program to TextOut is in fact a call to either TextOutA or TextOutW from that gdi32.dll. If I defined UNICODE at compile time, then the preprocessor actually replaced all my TextOut function calls with TextOutW function calls and when the linker later on exported the symbols, it exported the TextOutW function call. If UNICODE was not defined, then the preprocessor replaced all my TextOut function calls with calls to TextOutA.

Now, the thing is on Win2000, XP, 2003, Vista and probably all future Windows versions, only TextOutW is actually implemented in gdi32.dll. TextOutA does nothing more than allocate memory from the program heap, converts the ANSI string argument to a Unicode string and then calls TextOutW with that Unicode string as an argument. When the function returns, the heap memory is freed. Since memory allocation is one of the expensive operations, it will incur a performance hit on the application. All Windows functions that have a string argument behave this way, with the A (ANSI) version having to allocate heap memory for string conversion to unicode and then call the W (unicode) function to actually do the job.

On Win98/Me, the situation is different: the A version of functions are implemented and most of the W versions are not, they simply return an ERROR_CALL_NOT_IMPLEMENTED.

So, in the end, on Windows 2000 and newer Windowses, it's best to build with UNICODE defined so that the compiler will generate code that uses the W Windows functions directly.

[Eragon4ever]

Please take a look here: http://ffdshow-tryout.sourceforge.net/phpBB2/viewtopic.php?t=207

[aduwind]

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

FFT3dGPU is a GPU version of Fizick's FFT3DFilter.
It's, among other things, a denoiser and sharpner filter,that uses the GPU.
FFT3dGPU is an avisynth plugin and it works in ffdshow!!!!...unfortunately at 5/10 FPS in real time ffdshow postprocessing:( :( - On my opteron 165 @ 2.900 and ATI X1600 pro AGP -Catalist 6.10 and Avisynt 2.6
In this version the next frame is processed while waiting for the GPU to end it's work. Meaning the filters before fft3dGPU are working concurrently with it.

The following card should work:

Nvidia:
Geforce FX 5xxx
Geforce 6xxx
Geforce 7xxx

Ati:
Radeon 9500
Radeon 9550
Radeon 9600
Radeon 9700
Radeon 9800
Radeon Xxxx
Radeon X1xxx

Where x, means any digit.

Dear developers, why not explore the way to improve this filter in ffdshow as postprocessing filter ?
We could save CPU usage...:cool: :cool: :cool:

Many thanks

[Romario]

Your idea is, certainly, refreshing! But, I don't think that fft3dGPU 0.8.2 can integrate and work with ffdshow easily.

Other opinions about this?

[devaster]

jj i have still big problem to include a (i)dct on gpu implemented with brook but with pure cg is very good
when i get a whole frame builded from dct coeficients then i may run a idct on one call to cg shader and i get back from shader a transformed frame with accurancy comparable to xvid mmx idct but
it is as a twice faster... (my home results ...nvidia6600)

[Booji Boy]

Uhm, is VP6 advanced profile (VP61) not supported? I use the beta1 from the tryouts.

[Jeremy Duncan]

jj i have still big problem to include a (i)dct on gpu implemented with brook but with pure cg is very good
when i get a whole frame builded from dct coeficients then i may run a idct on one call to cg shader and i get back from shader a transformed frame with accurancy comparable to xvid mmx idct but
it is as a twice faster... (my home results ...nvidia6600)

How about you post your work or a link to your work so far and the developers here can look and it and maybe help you ? :)

[Liisachan]

VP61 is too old. What is supported is VP62 aka FLV4.

[KoD]

On2 has a free download (http://www.on2.com/downloads/) for a directshow vp6 decoder.

[DeepBeepMeep]

Just fix it in trunk. Then it can be in beta2.


Here is an interesting topic about ffdshow:
http://forum.doom9.org/showthread.php?t=119319

This is maybe slightly off topic. I am quite a big fan of ffdshow, I use it for almost everything including deinterlacing HD.

I have found out that the Kernel deinterlacer and Kernel bob give some very nice results. However the bob version seems to be too CPU intensive with HD even for top notch PCs.

It seems that the kernel deinternlacer / bob have been superseded by LeakKernal deinterlacer / Bob which are much faster. I have tried Leakkernal deinterlacer in avisynth running inside ffdshow and it consumes much less CPU than the previous versions. Unfortunately one can not use the Leakkernal bob since it doubles the output frame rate, which obviously is not supported by ffdshow

Any plan to allow avisynth scripts running inside ffdshow to change frame rates? If not it would be a very good idea to update the kernel deinterlacer / bob with their latest versions. They can be obtained here: http://neuron2.net/kerneldeint/leakkerneldeint154.zip

Thanks

[Inventive Software]

VP62 is essentially 6.1 and 6.0 with a sharpening postprocessing option. VP61 IIRC implemented "ordinary" postprocessing (i.e deblocking), and VP60 is just the video. I have the encoder if you would like to encode some samples. :)

[clsid]

Media Player Classic has an internal decoder for VP6 that supports all three subtypes. ffdshow only supports VP62.

[Inventive Software]

Since when has MPC had decoder support for all VP6 types? It doesn't specify it, so I assume it's cleverly disguised in the FLV support... :D

[Liisachan]

More or less Gabest planned to support VP60 and VP61 too in the beginning, and even defined MEDIASUBTYPE_vp*60 and 61 once, which were deleted @ rev 596. If there's anything special in MPC, it supports FLV5 partially, not only FLV4.

In case anyone needs VP4/5/60/61 to test them and try to support them, some files are here (http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/.on2/). But I think there are more important things to worry about than VP61 etc.

[clsid]

A while ago I created some sample files with the VP6 VFW codec and I could play all of them with MPC (svn build by Celtic_Druid).

[fastplayer]

Wow! 24 hours have passed without an update or a new build. ffdshow must be ready for prime time! :D

[Liisachan]

MPC uses libvp62, a different lib than ffmpeg's, which can only decode On2 VP6.2. Both (VP62).avi and (FLV4).flv play. They are the same codec, and you could even transmux FLV4.flv to VP62.avi using FLV_Extract. Last time I checked, ffdshow and vlc can play VP62.avi too. For ffdshow, both VfW and DS work.

(VP6.1).avi doesn't play.

[asasadad_1]

ffdshow.ax(ffdshow_rev696_20061215_clsid.exe) conflicted with Elecard MPEG Demultiplexer 1, 0, 74, 60725+ DScaler Mpeg2 Video Decoder 0, 0, 6, 0, after uninstalled ffdshow or just renamed ffdshow.ax to ffdshow1.ax, Elecard MPEG Demultiplexer+ DScaler Mpeg2 Video Decoder worked well.
here (http://www.yourfilelink.com/get.php?fid=239516) is a small mpeg sample + Elecard MPEG Demultiplexer+DScaler Mpeg2 Video Decoder.
os xp sp2.

[haruhiko_yamagata]

ffdshow.ax(ffdshow_rev696_20061215_clsid.exe) conflicted with Elecard MPEG Demultiplexer 1, 0, 74, 60725+ DScaler Mpeg2 Video Decoder 0, 0, 6, 0, after uninstalled ffdshow or just renamed ffdshow.ax to ffdshow1.ax, Elecard MPEG Demultiplexer+ DScaler Mpeg2 Video Decoder worked well.
here (http://www.yourfilelink.com/get.php?fid=239516) is a small mpeg sample + Elecard MPEG Demultiplexer+DScaler Mpeg2 Video Decoder.
os xp sp2.
Confirmed. Either ffdshow or Elecard MPEG Demultiplexer is broken.

[Yong]

Could someone help me with this?
im trying to compile ffdshow with gcc 4.1.1/4.2.0, but this is what i get,
http://img174.imageshack.us/img174/3637/grrrrccoo7.jpg

I have set the dxsdk environment accoring to b0bor guide, do i need the platform sdk?
gcc3.4.5 compile baseclasses flawlessly, except the convert dir.
here is where i download gcc4xx :
http://oss.netfarm.it/mplayer-win32.php

ffdshow compilers, please tell me where to download other versions of gcc, i wanna try other versions :)

[_xxl]

Could someone help me with this?
im trying to compile ffdshow with gcc 4.1.1/4.2.0, but this is what i get,
I have set the dxsdk environment accoring to deaththesheep guide, do i need the platform sdk?
gcc3.4.5 compile baseclasses flawlessly, except the convert dir.
here is where i download gcc4xx :
http://oss.netfarm.it/mplayer-win32.php
ffdshow compilers, please tell me where to download other versions of gcc, i wanna try other versions :)
You can compile ffdshow only with MinGW GCC 4.0.3.

[Yong]

Thx drevil_xxl :D :D :D
compiling ffdshow is easier than i thought:)
compiled, installed and its worked flawlessly.

[Romario]

ffmpeg rev 7332 introduce SSSE3 detection. Wow!!!

Revision 7332 - Directory Listing
Modified Mon Dec 18 22:43:09 2006 UTC (23 minutes, 34 seconds ago) by gpoirier

Add SSSE3 (Core2 aka Conroe/Merom/Woodcrester new instructions) detection

[midiboy]

Hi everyone!

Is it possible that the raw processing filter has problems in ffdshow_beta1_20061211_clsid.exe ?

As you can see in the pics I cannot use it in ZP anymore as a postprocessing filter for DVD playback.

The ZP settings have not changed and it worked well with all previous ffdshow versions (last one I tried before beta 1 was
ffdshow_rev404_20061017_clsid.exe )

Changing the settings in ZP (color space etc.) does not help and raw video in the ffdshow codec section is set to "all supported".

By the way, why is the raw processing filter settings link not included anymore ? I got to it by copying it from an old ffdshow build:

C:\WINDOWS\system32\rundll32.exe ffdshow.ax,configureRaw

Thanks for your help,
Alex

[cc979]

theres problem with gcc about the thunks, theres a patch out

thunk error (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067)
my build of gcc 4.1.2 has the patch in, check my sig. about it

[_xxl]

Still,ffdshow.ax compiled by MInGW GCC 4.1.2 crashes.

[haruhiko_yamagata]

Hi everyone!

Is it possible that the raw processing filter has problems in ffdshow_beta1_20061211_clsid.exe ?

As you can see in the pics I cannot use it in ZP anymore as a postprocessing filter for DVD playback.

The ZP settings have not changed and it worked well with all previous ffdshow versions (last one I tried before beta 1 was
ffdshow_rev404_20061017_clsid.exe )

Changing the settings in ZP (color space etc.) does not help and raw video in the ffdshow codec section is set to "all supported".

By the way, why is the raw processing filter settings link not included anymore ? I got to it by copying it from an old ffdshow build:

C:\WINDOWS\system32\rundll32.exe ffdshow.ax,configureRaw

Thanks for your help,
Alex
If you want to use ffdshow raw video processing in Zoom Player, you have to configure ffdshow using Video decoder configuration (not raw processing filter settings).

[Jeremy Duncan]

The new libavcodec supports SSE3.
Will this speed up real time Lanczos Resizing, or is libavcodec used only for Encoding ?

[foxyshadis]

Search for "MM_SSE3" in "*.c;*.h;*.cpp" in "D:\video\work\dev\ffmpeg":

---------- Find in Files ----------
"D:\video\work\dev\ffmpeg\libavcodec\i386\cputest.c"(89,21): rval |= MM_SSE3;
"D:\video\work\dev\ffmpeg\libavcodec\i386\cputest.c"(114,15): (rval&MM_SSE3) ? "SSE3 ":"",
"D:\video\work\dev\ffmpeg\libavcodec\dsputil.h"(486,9):#define MM_SSE3 0x0040 /* Prescott SSE3 functions */
3 occurrences have been found.
Output completed (23 sec consumed)


The new libavcodec supports SSE3.????

That's two people who've confused "detecting processor support" with "supporting". Compare to SSE2, which actually has a few functions written for it. Anyway, libswscale is part of mplayer, although it's also copied into ffmpeg.

[LigH]

SNOW support has been disabled some time ago, since it was extremely buggy.

Did that change in the meantime? Or is it still recommendable for a "stable" release to avoid its implementation?

[Jeremy Duncan]

????

That's two people who've confused "detecting processor support" with "supporting". Compare to SSE2, which actually has a few functions written for it. Anyway, libswscale is part of mplayer, although it's also copied into ffmpeg.

So this new feature of ffmpeg won't speed up fps of realtime playback ?
Is this feature only for encoding ?

[_xxl]

Multithreaded/SMP decoding for MPEG4/H263/H.264 will be very useful.

[thuan]

It means it only detects whether your CPU has SSE3 or not. No gain in speed.

[Inventive Software]

Assuming the installers are (sorta) consistent between builders, can I suggest this? Decoders that are selected in the installer are applied for the DShow decoder. Why not have them applied for the VFW decoder too?

[sillKotscha]

Decoders that are selected in the installer are applied for the DShow decoder. Why not have them applied for the VFW decoder too?

nice idea... but that would mean overwriting already existing vfw decoders you may prefer over ffdshow :rolleyes:

e.g. divx/xvid... I use ffdshow for directshow decoding but I still like to use divx/xvid for vfw...

[clsid]

Did that change in the meantime? Or is it still recommendable for a "stable" release to avoid its implementation?
There have been no changes to SNOW.

[clsid]

Assuming the installers are (sorta) consistent between builders, can I suggest this? Decoders that are selected in the installer are applied for the DShow decoder. Why not have them applied for the VFW decoder too?
The current installers already do that. It does so for all MPEG-4 variants and H.264. More can be added at request.

Afaik VFW does not have a merit system. So I don't know whether ffdshow or for example Xvid will take precedence. Probably Xvid, since its FourCC will be a direct match. Please test, if there is a problem, I can build in a detection function.

[Mario Bros]

Hi! I think i found a possible bug. I often use frame by frame skip in mpc (with the arrow keys), when i hold down the forward key, the player hangs at 100% cpu usage, and i need to kill the process in task man.. The last build that works is CLSID's rev386. I suspect it has something to do with queued output. (it was introduced in rev389). Environment spec: CPU: Athlon 64 3000+ (MMX,SSE1-3), OS: XP SP2, FFdshow -> queued output -> off, media player classic + queue output patch.

[haruhiko_yamagata]

Hi! I think i found a possible bug. I often use frame by frame skip in mpc (with the arrow keys), when i hold down the forward key, the player hangs at 100% cpu usage, and i need to kill the process in task man.. The last build that works is CLSID's rev386. I suspect it has something to do with queued output. (it was introduced in rev389). Environment spec: CPU: Athlon 64 3000+ (MMX,SSE1-3), OS: XP SP2, FFdshow -> queued output -> off, media player classic + queue output patch.
Yes, it is a bug. I have been debuging this problem since last Sunday.

// EDIT
100% cpu usage? It freezes with 0% cpu usage for me.
It freezes only with VMR9 renderless + RGB out.

[Mario Bros]

You are right.
Sorry!, I didn't remember correctly.

[Jeremy Duncan]

"I've been trying to play H.264 files with CoreAVC , but unless I turn raw video to disabled in the ffdshow video settings, the ffdshow mpeg4 filter always seems to be used as well.

I think the CoreAVC decoder is used first, but ffdshow is then used. I get significantly lower frames when this happens, as opposed to when ffdshow is set to disabled. I've run Gspot and it shows CoreAVC only when ffdshow is disabled, but it shows ffdshow being used after CoreAVC when it isn't.

If I block the ffdshow mpeg4 filter in media player this stops it from using the filter even if the raw video is set to all supported in the ffdshow video settings. However, if I do this, I am no longer able to use ffdshow when I watch DVD's, which I would like to do.

I tried setting H.264 to disabled in the ffdshow video codec settings, but this didn't seem to do anything.

Does anyone know how I can prevent ffdshow from being used when playing H.264 files, but still use it when watching DVD's WITHOUT having to change settings everytime I want to watch a different type of media?

Thanks a lot for the help."

[Inventive Software]

I tested the VFW encoder side of ffdshow. rev 696, the following encoders worked, assume those not listed didn't work.

libavcodec

MPEG-4
MPEG-1
MPEG-2
Lossless JPEG
HuffYUV
FFV1
DV

libtheora
Theora

wmv9 (Note: these encoders used the default WMP10 codecs after installation of WMP10)

Windows Media Video 9
Windows Media Video 9 Advanced Profile (WMVA, not WVC1)
Windows Media Video 9 Screen
Windows Media Video V7
Windows Media Video V8

All other codecs chucked out a "Cannot start encoder (-100)" error in VirtualDub 1.7.0. The source used was an AviSynth input size 720x576@25 FPS, YV12 colourspace. The settings used were the defaults for each codec, 1 pass quality 80.

I will try an old tryouts revision, as well as an old ffdshow revision to determine when the encoder support was broken.

[Isochroma]

@Jeremy Duncan: The issue is with the CoreAVC filter, which has a strange output colorspace implementation. If you set ffdshow to accept YUV in the Codecs page, then even if you set CoreAVC to output an RGB format, you'll find on playback that it outputs some YUV format and ffdshow ends up in the graph.

There is one solution, you can remove the registry keys for CoreAVC that allow it to output YUV formats, thus forcing RGB always.

Strangely, CoreAVC runs with 2-4% LESS CPU outputting RGB32 than YV12, at least with VMR9 Levels fix checkbox checked.

[clsid]

If you enable RAW video support then ffdshow will get inserted into the DirectShow graph. That is not a bug, but exactly what it is supposed to do. It will process the video that was decoded by another filter.

[midiboy]

Hi haruhiko_yamagata,

If you want to use ffdshow raw video processing in Zoom Player, you have to configure ffdshow using Video decoder configuration (not raw processing filter settings).

As you can see in the pic, I enabled "all supported" in the "raw video decoder configuration". This used to work fine for years now but not with the beta1 build.

If I enable raw video in the normal video decoder configuration then ffdshow will load in all kinds of graphs where I do not want it. Thats the reason for the extra raw video decoder, no? To be able to insert ffdshow for instance for DVD post processing.

Otherwise the "raw video filter" ({0B390488-D80F-4A68-8408-48DC199F0E97}) is useless, no ?

Thanks for your help,
Alex

[Isochroma]

@CLSID: Yes, there is a bug in CoreAVC or ffdshow or both.

There are many RAW formats that can be selected; selecting YUV only means ffdshow should ONLY put itself in the graph if the upstream filter is outputting YUV.

However, even if CoreAVC is set to some RGB output, ffdshow still puts itself ahead and then CoreAVC outputs YUV.

[clsid]

@midiboy, try using {04FE9017-F873-410E-871E-AB91661A4EF7} and enable RAW support in the normal ffdshow decoder.


@Isochroma, do you mean that if you set ffdshow to accept only YUV in RAW mode, then CoreAVC suddenly starts outputting YUV instead of RGB?

[Isochroma]

YES, EXACTLY, you have hit the nail on the head.

[foxyshadis]

I bet CoreAVC uses YUV as a fallback mode, then, even if RGB is selected. Probably queries for all supported colorspaces, and if it does YUV but not RGB it'll switch. I wonder if it will use RGB fallback if you have YUV selected, too.

You'll have to ask Core about that behavior though.

[midiboy]

midiboy, try using {04FE9017-F873-410E-871E-AB91661A4EF7} and enable RAW support in the normal ffdshow decoder.

Hi Clsid,

yeah I know I can do that but then ffdshow will insert itself in all kinds of graphs where I don´t want it (tv recording software etc.).

Why did you stop using the raw video processor filter ? That was a very good idea, having a seperate filter for raw video processing that can be used for special things like DVD postprocessing WITHOUT disturing other playback graphs.

Would it be too much work supporting it again ??

Thanks,
Alex

[KoD]

midiboy, what's wrong with enabling what raw formats you want ffdshow to act as a postprocessing filter in ffdshow video decoder configuration -> Codecs page -> Raw option ?

If you want graph building control (which filters go where and in what order), you should know that's not meant for a filter in the graph to decide, but for the player that builds the graph. Use something like ZoomPlayer that offers the user an interface to alter the graph as he wants or contact the makers of the playback software you are using to implement such a functionality. Having filters force what goes where is wrong ! I leave it up to you as an exercise to find out why. ffdshow already forces its choices in some situations, and that's what's causing some issues (as well as solving some issues like explorer thumbnails).

And as amazing as it may seem, falling back to a format that all filters in the graph agree upon is what's meant to happen. Is what makes automatic graph building work.

[clsid]

Afaik, no changes have been made to the raw filter. Try some old versions to see when it stopped working for you.

[haruhiko_yamagata]

Though I'm messed up with the bug (http://forum.doom9.org/showthread.php?p=919534#post919534) of the patch for MPC and don't have much time, it may be interesting to try adding a option "DVD only" for Raw video.
TffdshowDecVideo::dvdproc shows if the source is DVD in most cases.
{04FE9017-F873-410E-871E-AB91661A4EF7} is suposed to be added into filter graph manually and used in graphedit.exe. That's why it has that low merit setting.

[foxyshadis]

And as amazing as it may seem, falling back to a format that all filters in the graph agree upon is what's meant to happen. Is what makes automatic graph building work.

I realize that, but Isochroma implied that it was exclusive. Similar to how ffdshow has total control over preferred/fallback/disabled formats. Now that I found a screenshot of 1.1 prefs (http://www.coreavc.com/index.php?option=com_joom12pic&Itemid=1), which I assume is the same in 1.2, it really is a full list of formats in order of preference, and there's no way to easily remove RGB or YUV modes, so a fallback to YUV is totally understandable. (I'm surprised it's possible to disable them completely via the registry, honestly.)

[CoRoNe]

The fact that the following MOV[SVQ3+AAC] crashes...is this FFDShow to blame or the MP4 Splitter?

link: http://www.a-film.nl/film/trailer/00000397_quicktime_HOOG.mov

[Episode]

@clsid, would it be possible to have another icl9 build sometime soon? Thanks in advance!

[Jeremy Duncan]

Though I'm messed up with the bug (http://forum.doom9.org/showthread.php?p=919534#post919534) of the patch for MPC and don't have much time, it may be interesting to try adding a option "DVD only" for Raw video.
TffdshowDecVideo::dvdproc shows if the source is DVD in most cases.
{04FE9017-F873-410E-871E-AB91661A4EF7} is suposed to be added into filter graph manually and used in graphedit.exe. That's why it has that low merit setting.

That's a nice idea.

[Px]

I tested the VFW encoder side of ffdshow. rev 696, the following encoders worked, assume those not listed didn't work.
I tested
ffdshow_rev705_20061222_clsid.exe
ffdshow_rev705_20061222_clsid_icl9.exe
Still "Cannot start encoder (-100)" on MPEG4 codec. Which build, you are used for test?


All other codecs chucked out a "Cannot start encoder (-100)" error in VirtualDub 1.7.0. The source used was an AviSynth input size 720x576@25 FPS, YV12 colourspace. The settings used were the defaults for each codec, 1 pass quality 80.
Did you tried to recompress files? I try both Vdub/Vdubmod, 5 or 6 files with different codecs, divx, xvid, mpeg2, on all of them "Cannot start encoder (-100)" error appeared :(

[_xxl]

I compiled ffdshow with wvc1 support in wmv9lib.
Please enable vc1 from codec list.
http://www.mytempdir.com/1129848

[Episode]

I really don't understand why CCCP -project considers ffdshow-tryouts as very unstable and unusable. They released a new version few days ago with a version of ffdshow that's dated way back in the september and they won't use tryouts versions because they have "very badly written multithreading code and almost none real improvements". Is the original code really that much more stable than what we have now or is CCCP just ignoring this project since the changes are not made by milan?-)

[foxyshadis]

Presumably one of their members used a build with queuing in the summer sometime, it didn't noticeably improve performance (or he stumbled onto one of the hanging bugs), and instead of filing a bug they wrote off the whole project indefinitely. But I'll see if I can convince them; I was sort of hoping Check would, since he's somehow involved with the group.

The original code is most definitely not more stable than what we have now. If CCCP wants to disable multithreading in their installer that's easy enough, but that's no excuse for ignoring the numerous bugfixes and performance improvements even in the original ffdshow code. Obvs none of them have compared current AVC performance to the last official build's.

[fastplayer]

Quote from the CCCP changelog (http://www.cccp-project.net/wiki/index.php?title=Main_Page):
Updated ffdshow to 2006-09-23, no multithreading since it isn't currently stable enough. Yes, this build might seem old. The reason for this is that ffdshow-tryouts isn't (and hasn't been) very stable. We prioritize stability over bleeding-edge features.
I'd really like to know what sh|t they're on... :rolleyes:

[_xxl]

Updated ffdshow to 2006-09-23, no multithreading since it isn't currently stable enough. Yes, this build might seem old. The reason for this is that ffdshow-tryouts isn't (and hasn't been) very stable. We prioritize stability over bleeding-edge features.
Yes,they seem to know everything better than we do.:confused:

[sillKotscha]

wtf is cccp? and more important... who cares about them?

[foxyshadis]

Combined Community Codec Pack (http://www.cccp-project.net/). The most popular codec pack on the net currently; k-lite has lost a lot of popular support over the past year or two, since CCCP showed up, because the alternative is much simpler and less dangerous on the system, and does a great job of cleaning up other codec packs' leftover garbage. They basically center the pack around ffdshow & haali's splitter, with a few extras to take up the slack. Fansub groups in particular nearly unanimously recommend CCCP now. It's important, because more people install such things than ever install ffdshow separately.

(In case you know the real meaning of CCCP, they do hint at that as well.)

[haruhiko_yamagata]

QueueUp20061223.patch (http://sourceforge.net/tracker/index.php?func=detail&aid=1621133&group_id=173941&atid=867362)

New version of queue. This patch was writen to improve the stability and compatibility issue. Ironically this patch is too large and needs more testing.

As a result, queue becomes effective with Zoom player and MPC + VMR9.

Another fix includes,
improved compatibility issue with BSPlayer.
Windows Media Player is excluded from queueing internally regardless of the settings.

VMR9 rengerless + RGB out + patched MPC : continue pressing right cursor key freezes. This issue is improved if queue is off. If queue is on, we have to wait for new builds.

My binary (http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_rev706p_20061223_Q.exe) is available for testing.

ListEmptyIMediaSamples is a helper class of queue and does prefetch.
GetBuffer and Receive is now called from the same thread.
If Receive and GetBuffer is called from other threads, GetBuffer often returns error.
By cooperating with TffOutputQ, ListEmptyIMediaSamples buffers the IMediaSample as soon as it is released in TffOutputQ::ThreadProc.

[sillKotscha]

(In case you know the real meaning of CCCP, they do hint at that as well.)

Союз Советских Социалистических Республик :D

installing codec packs... that's the point - if a widely accepted codec pack offers ffdshow respectively build the pack around ffdshow than someone should convince them to include the last marked stable beta release... as it is rock solid for 99% of the users...

on the other hand it is a move in the right direction that no rip-offs of (il-) legal codecs are floating around but ffdshow is used instead in their pack... but to be honest - I don't care about codec packs :)

it's just kind of a sad feeling that your (devs around ffdshow) work doesn't get that respected as you've worked hard to release a stable beta release of ffdshow...

[Liisachan]

Personally, I don't use codec packs either, but codec packs are not all bad if you use it right. ffdshow is a codec pack too, in a way. The good point of CCCP would be, with it you can play video on relatively slow computers. So it could be recommended for general users who may or may not have fast CPU.

However, if you have fast CPU and prefer quality over speed that's a whole different story.

For instance, ffdshow's high-quality RGB32 output or MPC's internal sub-renderer with no sub-pic buffering.

Originally, haruhiko's mt patch was for that very purpose--VMR9 Renderless RGB32; so... that codec pack is in a way inconsistent with ffdshow's philosophy. ffdshow is quality-oriented (as in vorbis decoder, changed into high-quality mode). Actually, tho, many users didn't know old ffdshow's default Vorbis decoder was problematic; even today, many users don't know their video is out of sync, audio being about 50ms (typically 1 video frame) too late because of encoder delay + lame tag, as the encoders use lame default without knowing what they are doing. Obviously I wouldn't listen to "recommendations" of such people.

CCCP is "people's pack" (or "poor men's" pack in a good sense); Fast VSFilter softsubs instead of MPC's too beautiful but too slow desktop resolution (reasonable for normal users). Fast YUV color space instead of software-side RGB (the quality is especially degraded for many of nVidia users who don't configure the driver correctly; not CCCP's fault, tho). As another note, last time I checked, the official Matroska pack from matroska.org was CCCP-based too. (They didn't include ffdshow's mp4 encoders as legal precautions)
So, altho I'm not sure if cccp is good or not (as I'm not a user), it's used relatively widely, and I believe it must be much better than Nimo (?) or something, I don't remember the exact name, but I mean old notorious codec packs.
From what I gathered many people recommend cccp too, tho just because many ppl recommend it doesn't mean I automatically agree with that.

[LoRd_MuldeR]

QueueUp20061223.patch (http://sourceforge.net/tracker/index.php?func=detail&aid=1621133&group_id=173941&atid=867362)

New version of queue. This patch was writen to improve the stability and compatibility issue. Ironically this patch is too large and needs more testing.

As a result, queue becomes effective with Zoom player and MPC + VMR9.

Another fix includes,
improved compatibility issue with BSPlayer.
Windows Media Player is excluded from queueing internally regardless of the settings.

VMR9 rengerless + RGB out + patched MPC : continue pressing right cursor key freezes. This issue is improved if queue is off. If queue is on, we have to wait for new builds.

My binary (http://downloads.sourceforge.net/ffdshow-tryout/ffdshow_rev706p_20061223_Q.exe) is available for testing.

ListEmptyIMediaSamples is a helper class of queue and does prefetch.
GetBuffer and Receive is now called from the same thread.
If Receive and GetBuffer is called from other threads, GetBuffer often returns error.
By cooperating with TffOutputQ, ListEmptyIMediaSamples buffers the IMediaSample as soon as it is released in TffOutputQ::ThreadProc.

Tested with MPC:
VMR7 works fine
VMR9 works fine
Haali Renderer completely freezes with Queue enabled, otherwise is does not
Overlay says "not supported"

[cc979]

i've recompiled gcc-4.1.2 with the strip option, @clsid files are smaller - check my sig for the file

i try to compile ffdshow - and every thing compiles ok - ffdshow.ax will crash when looking the filters
but i've found a solution it has to do with '-march=pentium-mmx -mtune=i686' in makefile.inc's

if i remove them, it does compile and function correctly on my athlon_x64, but shows on version page x86, sse

and in the .bat files it should be "%SystemRoot%\..\Program Files\NSIS\makensisw.exe" for people who have windows on a drive

cheers

[haruhiko_yamagata]

Tested with MPC:
VMR7 works fine
VMR9 works fine
Haali Renderer completely freezes with Queue enabled, otherwise is does not
Overlay says "not supported"
Thank you very much for testing. Haali's renderer does not work on my developing environment. I find a PC that Haali's renderer works and reproduced the problem.

//EDIT
Overlay often fail over old renderer. That's why the OSD says "not supported".

[foxyshadis]

Still have issues with video output freezing when I make on-the-fly adjustments to avisynth. (Did I ever report that? Only noticed recently.) While the video's either playing or paused. Seeking fixes it.

Queue works well in YV12 and not in YUY2 here, in VMR9 renderless YUV mixing mode, just to let you know. I got it to work once in Zoomplayer, too, but it wouldn't after that. ;_;

And pretty much all MPEG-4 and WMV based codecs are crashing, the last few revisions, but only in MPC. Grr, and I have yet to successfully compile MPC to debug (when attempting to debug the binary, it exits process before it can be attached properly).

[haruhiko_yamagata]

I got it to work once in Zoomplayer, too, but it wouldn't after that. ;_;
Thank you for report. Is it about ffdshow_rev706p*_20061223_Q.exe? Please let me know the detail.

[Px]

I tested
ffdshow_rev705_20061222_clsid.exe
ffdshow_rev705_20061222_clsid_icl9.exe
Still "Cannot start encoder (-100)" on MPEG4 codec. I try both Vdub/Vdubmod, 5 or 6 files with different codecs, divx, xvid, mpeg2, on all of them "Cannot start encoder (-100)" error appeared :(
Today I made some additional test on huffyuv compressed 720x576 video, MPEG4 encoder works normally. Could it be, that ffdshow can't start encoding because another instance of vfw codec must be used for decoding?

[Px]

I compiled ffdshow with wvc1 support in wmv9lib.
Please enable vc1 from codec list.
Where I can download vc1 samples for testing?

[Px]

And one another thing (or maybe I missed something?):
I recently upgraded my cpu to dualcore, and found that when I play 24 Mbps H.264 sample in MPC, ffdshow works as if it multithreaded, first core load near 60%, and second - 40%. When I play same file in bsplayer, cores load 80-100/20...

[clsid]

Today I made some additional test on huffyuv compressed 720x576 video, MPEG4 encoder works normally. Could it be, that ffdshow can't start encoding because another instance of vfw codec must be used for decoding?
I tried disabling everything in ffdshow VFW decoder and it still has the same problems. Even with uncompressed input.

[foxyshadis]

Thank you for report. Is it about ffdshow_rev706p*_20061223_Q.exe? Please let me know the detail.

Yes, my apologies, it's your test build. Queue seems to be working normally in Zoom Player again now (in YUY2 VMR9), I think it might have stopped working because I installed clsid's build, oops. :o Btw, if it's important: ATI X1400 Mobility, Catalyst 6.10. XP SP2.

Btw, can the queue limit be raised, if there's enough free memory? Once in a while it'll hit a scene or the system will get busy and it shrinks to zero.

I still have to test certain scenes that had jerky panning before even with 9 frames in queue.

Where I can download vc1 samples for testing?

http://www1.mplayerhq.hu/MPlayer/samples/V-codecs/WVC1/

Lots of video game sites are using it for trailers now, too.

And one another thing (or maybe I missed something?):
I recently upgraded my cpu to dualcore, and found that when I play 24 Mbps H.264 sample in MPC, ffdshow works as if it multithreaded, first core load near 60%, and second - 40%. When I play same file in bsplayer, cores load 80-100/20...

Decoding is not yet multithreaded. (Except mpeg 1/2.) The queue only works if you have enough spare cpu to decode ahead a few frames. (Turn on ffdshow's OSD and select Queued Samples to find out if that's the case.) Once the pictures leave the decoder they can be multithread through the rest of the pipeline, to some degree, as well as fully threaded software resize.

Instead of watching task manager's graphs, it's often better to watch the cpu% in the process list, where you don't have to eyeball total utilization. If you really need graphs, process explorer has a single per-process graph that I think you'd like. It's hard to push mine above 50%, but I did it by resizing to 1280x1024. :p

[Px]

http://www1.mplayerhq.hu/MPlayer/samples/V-codecs/WVC1/

Lots of video game sites are using it for trailers now, too.
Thanks :)

Decoding is not yet multithreaded. (Except mpeg 1/2.) The queue only works if you have enough spare cpu to decode ahead a few frames. (Turn on ffdshow's OSD and select Queued Samples to find out if that's the case.) Once the pictures leave the decoder they can be multithread through the rest of the pipeline, to some degree, as well as fully threaded software resize.
Ok, I see, the Queued Samples most time is 9-10, in worth cases - 3-4

Instead of watching task manager's graphs, it's often better to watch the cpu% in the process list, where you don't have to eyeball total utilization.
I don't watch task manager, I use RMClock for watching and Rivatuner for logging core usage separately :)

[haruhiko_yamagata]

celtic_druid has compiled a new build for MPC.
Both the cursor key problem (http://forum.doom9.org/showthread.php?p=919534#post919534) and DTS problem are fixed.

mplayerc.rev611-3.2kxp.7z (http://tirnanog.fate.jp/mirror/Media%20Player%20Classic/mplayerc.rev611-3.2kxp.7z)

Thank you very much, celtic_druid.

[foxyshadis]

A couple interesting results, with r706p and the new MPC 611-3. The video hang when editing avisynth (or output) during playback is still there, but now it only lasts a second before resetting and playing normally. Also YUY2 works for queue now. Oh wow, that's awesome. (RGB also works, naturally.)

[fastplayer]

Not a biggie but... XP visual styles are not working with the latest MPC build.

[foxyshadis]

They work here. You might want to try searching your system for mplayerc.* and delete whatever comes up; a stray manifest might be breaking something. Or it might be something entirely different, not sure.

[celtic_druid]

The manifest file is embedded, so yeah it should work.

[haruhiko_yamagata]

Yes, my apologies, it's your test build. Queue seems to be working normally in Zoom Player again now (in YUY2 VMR9), I think it might have stopped working because I installed clsid's build, oops. :o Btw, if it's important: ATI X1400 Mobility, Catalyst 6.10. XP SP2.

Btw, can the queue limit be raised, if there's enough free memory? Once in a while it'll hit a scene or the system will get busy and it shrinks to zero.

I still have to test certain scenes that had jerky panning before even with 9 frames in queue.

I need a hard ware compatiblity list:(.
The limit of queue count can be raised, though I doubt the efficacy. Registry option for testing may help.

[fastplayer]

They work here. You might want to try searching your system for mplayerc.* and delete whatever comes up; a stray manifest might be breaking something. Or it might be something entirely different, not sure.

The manifest file is embedded, so yeah it should work.

@foxyshadis:
There's no hidden manifest file in my MPC directory or anywhere else. Just the EXE and INI.
@celtic_druid:
I remember that this happened with one of your previous MPC builds. I think the manifest file wasn't properly embedded as a resource or something...
Update: manifest is not embedded. Couldn't find it with ResHacker but I added it from your previous MPC build. See link below.

Edit: Fixed it by adding a manifest file.
Edit2: MPC build rev611-3.2 by celtic_druid + embedded manifest for XP visual styles support:
http://d.turboupload.com/d/1361725/mplayerc.rar.html

[leeperry]

call me stupid but I got a pretty annoying problem with the latest versions of ffdshow :(

in the older "official" releases, it was possible to fine-tune the aspect ratio with the keyboard arrows in order to reach 1.67/1.78/1.85 and 2.35

with the newer versions it doesn't work anymore, so you have to move the mouse like crazy to more or less reach the ratio you want........and you can only reach 1.66/1.77/1.84-1.86 and 2.36

is there a recent release that lets you change it with the keyboard arrows ?!!?!?

thanks ;)

[celtic_druid]

Yeah, MSVC sometimes leaves out embedding it. You can add it with MSVC (copy paste from previous exe).

[fastplayer]

Yeah, MSVC sometimes leaves out embedding it. You can add it with MSVC (copy paste from previous exe).
I actually copied the %windir%\system32\cdplayer.exe.manifest file into the MPC folder, renamed it to mplayerc.exe.manifest and voilà it works again :)

[leeperry]

any chance getting a reply pls ?
noone cares to get perfect aspect ratio but me ? :(

[haruhiko_yamagata]

any chance getting a reply pls ?
noone cares to get perfect aspect ratio but me ? :(
Please wait. I'm looking into it.

[leeperry]

awesome, thanks a lot :)

actually I'd be really great to be able to choose between :
1.0
1.22
1.33
1.47
1.666666
1.777777
1.85
2.35

and then being able to input it manually

[haruhiko_yamagata]

awesome, thanks a lot :)

actually I'd be really great to be able to choose between :
1.0
1.22
1.33
1.47
1.666666
1.777777
1.85
2.35

and then being able to input it manually
Just fixed at rev 708. Restored from the code just before rev 1427 of the original project. Direct text input is not supported though.

[mpioner]

celtic_druid
time to do MPC-tryout :D

[leeperry]

Just fixed at rev 708. Restored from the code just before rev 1427 of the original project. Direct text input is not supported though.

better talk to god than to his saints I guess, thank you so much :D

so I can use the keyboard arrows to finetune ?
any chance of implementing buttons with just 1.33/1.66666/1.77777/1.85 and 2.35 ?
or making the incremental change a lot slower when the right button is pushed ?
coz sometimes I just got my wireless mouse handy, no keyboard :D

where could I get a SSE2(GCC?) compiled version ?

thanks again and merry xmas :D

[Peuj]

The fact that the following MOV[SVQ3+AAC] crashes...is this FFDShow to blame or the MP4 Splitter?

link: http://www.a-film.nl/film/trailer/00000397_quicktime_HOOG.mov

Same issue for me with the latest ffdshow version.

[clsid]

You can drag the slider with your mouse.

[_xxl]

ffdshow(SSE2) compiled by MinGW GCC 4.0.3 is crashing.

[leeperry]

You can drag the slider with your mouse.

I know but you cannot reach every 0.1 increment......which is freakin' annoying

I cannot reach 1.67/1.78/1.85 and 2.35

[cc979]

ffdshow(SSE2) compiled by MinGW GCC 4.0.3 is crashing.

i'll check on it on mine, and try and find whats wrong - maybe related to crash with gcc 4.1.2 - as i had to alter the makefile.inc's remove the -march and -mtune to get it to work

[cc979]

just compiled it with gcc-4.0.3 with 'make SSE2=yes' works fine so far

[Yong]

sse and sse2 works here, with -march=pentium4 -mtune=pentium4, compiled with gcc 4.0.3, only libmpeg2 have problem with sse2(broken output or crash).

[cc979]

sse and sse2 works here, with -march=pentium4 -mtune=pentium4, compiled with gcc 4.0.3, only libmpeg2 have problem with sse2(broken output or crash).

just found libmpeg2 not sse2, just read a webpage about cpuid not in libmpeg2 - maybe its optimized for plain i686

edit. i maybe wrong https://trac.videolan.org/libmpeg2/browser/trunk?rev=1107

[Yong]

just found libmpeg2 not sse2, just read a webpage about cpuid not in libmpeg2 - maybe its optimized for plain i686

edit. i maybe wrong https://trac.videolan.org/libmpeg2/browser/trunk?rev=1107

libmpeg2 works if u define it with -U__SSE2__, which will disable the sse2 assembly code(?), or dont select the sse2 in here (http://img412.imageshack.us/img412/8176/sse2xd3.png).

[popper]

It'd be great if we could also nominate something as a stable release, I put up a new frontpage for the ffdshow tryouts page and don't redirect to the tryouts forums directly anymore, and I'd like to link there at least directly to a stable build people can use.

so the tryouts forums is reachable via http://forum.ffdshow.info/ and the new frontpage that's not the hottest of the hottest stuff but at least something easy at http://ffdshow-tryout.sourceforge.net/ ...

better contributions are always welcome.

it looks nice and simple , the way a book cover/first page should be, however im not so sure about this, perhaps its just me but 'if it's MPEG4 or H264, MPEG2 or MPEG1 or even WMV3' seems wrong and favours mpeg4-ASP and educates or at least implys to the average user that mpeg4 is the best (everyone says mpeg4 is the best as its [singular]the newest thing according to X-salesman)and so it most be divx as you state H.264 seperately (if they even know H.264 is AVC/mpeg4 p10, probably not).

perhaps its time for everyone to stress the point that mpeg4 is a generic salesmans trick (to sell non AVC kit)and people should be using 'the new AVC' and 'the old ASP' as the key words to at least make an effort to get people to ask these salesmen the right questions and perhaps get AVC/ASP written on the packages .....

[boom9]

sorry for offtopic, but do you know what does the "snap to desktop edges" option in MPC do?

Options->Player->"snap to desktop edges"

i have do some servial tests but did not see any difference

[thuan]

It does exactly what it says, when you move the thing close to your Desktop (screen) edges.

[boom9]

It does exactly what it says, when you move the thing close to your Desktop (screen) edges.

Looks like my MPC does not move closer, did I get it wrong?
thank you

[KoD]

How is this ffdshow related ? Is this the MPC thread ?

[LoRd_MuldeR]

@boom9
1. Plase remove over-sized images form your posting. They derstroy the layout!
2. "snap to desktop edges" means that MPC will dock to the edges of the screen when you move the window near to the edges. It's just the same behavior as Winamp, for example. Make the MPC window small enough and move it arround. You will notice the effect!
3. This post obviously is off-topic...

[leeperry]

Just fixed at rev 708. Restored from the code just before rev 1427 of the original project. Direct text input is not supported though.

better talk to god than to his saints I guess, thank you so much :D

so I can use the keyboard arrows to finetune ?
any chance of implementing buttons with just 1.33/1.66666/1.77777/1.85 and 2.35 ?
or making the incremental change a lot slower when the right button is pushed ?
coz sometimes I just got my wireless mouse handy, no keyboard :D

where could I get a SSE2(GCC?) compiled version ?

thanks again and merry xmas :D

[fastplayer]

better talk to god than to his saints I guess, thank you so much :D
<snipped>

Why do you post the same (http://forum.doom9.org/showthread.php?p=921111#post921111) message again?

[leeperry]

coz it seems that I'd love to get a reply :)
sorry for that,

[_xxl]

I ran some tests on my computer and here are the results.
I used for testing a h264 sample and ffdshow rev 716.
I have enabled Queue in timecodec.exe.

The output colorspace is yv12.
NUll:
User: 22s, kernel: 0s, total: 22s, real: 23s, fps: 99.2, dfps: 97.0
http://i12.tinypic.com/47imfev.jpg
old:
User: 23s, kernel: 11s, total: 34s, real: 36s, fps: 64.1, dfps: 61.0
http://i14.tinypic.com/4igfskm.jpg
om:
User: 22s, kernel: 11s, total: 34s, real: 36s, fps: 64.8, dfps: 61.0
http://i12.tinypic.com/448sepd.jpg
vmr7:
queue on
User: 22s, kernel: 0s, total: 22s, real: 29s, fps: 98.0, dfps: 75.1
http://i16.tinypic.com/2evspj7.jpg
vmr9:
queue off
User: 22s, kernel: 0s, total: 23s, real: 24s, fps: 97.1, dfps: 92.9
http://i13.tinypic.com/400w3gh.jpg

[fastplayer]

Has a maxed-out core any adverse effects when using queued output?

[fastplayer]

Haruhiko has implemented a new version of queued output in rev719 with quite some fundamental changes - at least it looks like it to me :). So those who had issues with queued output in the past - *cough*CCCP*cough* - should give the 719+ builds a try.

Changelog:
New version of queue.
As a result, queue becomes effective with Zoom player and MPC + VMR9.

Another fix includes,
Only queue in VMR7 and overlay mixer.
In VMR9, try VMR9's internal queue.
improved compatibility issue with BSPlayer.
Windows Media Player is excluded from queueing internally regardless of the settings.
registry option "queueCount".

ListEmptyIMediaSamples is a helper class of queue and does prefetch.
GetBuffer and Receive is now called from the same thread.
If Receive and GetBuffer is called from other threads, GetBuffer often returns error.
By cooperating with TffOutputQ, ListEmptyIMediaSamples buffers the IMediaSample as soon as it is released in TffOutputQ::ThreadProc.

Download:
ffdshow_rev719_20061227_xxl.exe (http://sourceforge.net/project/showfiles.php?group_id=173941&package_id=214245&release_id=470135)

[haruhiko_yamagata]

Haruhiko has implemented a new version of queued output in rev719 with quite some fundamental changes - at least it looks like it to me :). So those who had issues with queued output in the past - *cough*CCCP*cough* - should give the 719+ builds a try.

Well, let's fotet CCCP.
rev719 may not be as stable as beta1, though no new bugs are reported regarding queue (issue with Haali's renderer has been fixed).
I found VMR9 has internal queueing mechanism. It is not worse than ffdshow's but no better. When I try to play 720p 24fps movie in 48fps, it drops more frams with queue in a certain hardware(my intel on bord one). It's very usefull in G450, but it's not usefull at all in some hardware.
Queue is effective in VMR9 renderless/MPC in most video cards though.

[clsid]

I have tested the new queue.

ffdshow rev720
MPC rev611-3
Windows 2000 Sp4

Renderers:

System default:
Picture freezes after a few frames. Time slider progresses normally. If I move the slider to another spot in the movie, then again only a few frames are played before the picture freezes. CPU usage during freeze ~10%.

Old renderer:
queue off

Overlay Mixer:
off: old renderer does not support queue ???

VMR-7 (windowed):
ok

VMR-7 (renderless):
ok

VMR-9 (windowed):
off: video driver can't work with YV12 + VMR-9 + queue

VMR-9 (renderless):
ok

[LoRd_MuldeR]

jap:
* Overlay Mixer: "old renderer does not support queue"
* Haali Renderer: "Queued Frames: 0"
* VMR7/9 okay

(rev719, MPC 611-3)

[MacAddict]

jap:
* Haali Renderer: "Queued Frames: 0"
* VMR7/9 okay

(rev719, MPC 611-3)

I can verify this on my system as well.

[cc979]

rev 721

trunk/src/dialog/CcurveNormal.h

#ifndef _CCURVENORMALPAGE_H_1
#define _CCURVENORMALPAGE_H_

should it be

#ifndef _CCURVENORMALPAGE_H_1
#define _CCURVENORMALPAGE_H_1

[Eragon4ever]

I think this is my bad from removing spaces.
If so it should be
#ifndef _CCURVENORMALPAGE_H_
#define _CCURVENORMALPAGE_H_

I'll change it.

[haruhiko_yamagata]

Thank you for testing.
@clsid : I'll test Windows2000 and its default renderer.
@LoRd_MuldeR : I can't connect to Overlay Mixer recently in MPC. It connects to old renderer. Seems same for everyone. I remember I could. What's wrong? MPC, Direct X, OS, ffdshow?

[_xxl]

I used for testing a h264 sample and ffdshow rev 719 + queue on, MPC rev611-3 and Windows XP SP2.
Output colorspace YV12.
Renderers:
1).System default:
http://i14.tinypic.com/2duxmx4.jpg
2).Old renderer:
queue off
http://i13.tinypic.com/34z0vw3.jpg
3).Overlay Mixer:
queue off
http://i10.tinypic.com/313iv0j.jpg
4).VMR-7 (windowed):
http://i10.tinypic.com/2vd0ccm.jpg
5).VMR-7 (renderless):
http://i11.tinypic.com/4g4zndt.jpg
6).VMR-9 (windowed):
queue off
http://i17.tinypic.com/4ck6xxh.jpg
7).VMR-9 (windowed):YUY2
http://i10.tinypic.com/2i0sl5w.jpg
8).VMR-9 (renderless):
http://i10.tinypic.com/448twsk.jpg
9).Haali:
queue off
Queued Frames: 0
http://i14.tinypic.com/4h7j3py.jpg
MPC + ffdshow + Queue.
Queue off:
http://i12.tinypic.com/2cxw87s.jpg
Queue on:
http://i18.tinypic.com/2hs4vih.jpg
Media Player2 + ffdshow + Queue.
Queue off:
http://i10.tinypic.com/4gow6kw.jpg
Queue on:
http://i17.tinypic.com/2lih6wz.jpg
I have enabled Queue in timecodec.exe.
TimeCodec VMR7 + ffdshow + queue:
http://i11.tinypic.com/2gtueyf.jpg
User: 22s, kernel: 0s, total: 22s, real: 29s, fps: 101.4, dfps: 75.2
TimeCodec VMR7 + coreavc 0.0.0.4:
http://i18.tinypic.com/2lwxfed.jpg
User: 14s, kernel: 13s, total: 27s, real: 30s, fps: 81.2, dfps: 74.0
TimeCodec VMR7 + coreavc decoder 0.0.0.4 + ffdshow queue:
http://i18.tinypic.com/2a9165g.jpg
User: 15s, kernel: 0s, total: 15s, real: 29s, fps: 141.5, dfps: 75.1

[LigH]

Just as side note -- if you want to test Theora decoding, or output space clamping:

Some community modelling project of the PlaneShift MMORPG made a preview video in Theora which looked distorted at first in ffdshow, like: [\]

The reason was: It uses some odd dimensions (1202x911), and YV12 output was enabled in ffdshow. Limiting the output to RGB and YUV 4:2:2 only "fixed" the messed output. But here I wonder: May it be recommendable to expand the dimensions to the next matching sizes (e.g. height of 912 lines) to avoid that?

http://vaalnor.mine.nu/Downloads/Video/waterfall.avi (312 KB)

[_xxl]

http://img139.imagevenue.com/loc369/th_09263_theo_122_369lo.jpg (http://img139.imagevenue.com/img.php?image=09263_theo_122_369lo.jpg)
Input size:1202x911
Output size 1216x912
ffdshow + Haali Media Splitter (AR)

[fastplayer]

@drevil_xxl:
Any chance you include Unicode-version of ffdshow.ax in your builds (like clsid)?

[vlada]

On my system the output resolution is 1208x902 and it looks O.K. I'm using ffdshow beta1.

Btw. recently I read quite a lot about queued output. What is it good for? How does it works?

[LigH]

Hmm...

ffdshow_beta1_20061211_clsid.exe
YV12 output enabled
MPC 6.4.9.0 deutsch
Output: Overlay
ELSA Gladiac GeForce2 GTS, 32 MB, Detonator 4345

Video size:1202x911
Slanted picture

[LoRd_MuldeR]

@LoRd_MuldeR : I can't connect to Overlay Mixer recently in MPC. It connects to old renderer. Seems same for everyone. I remember I could. What's wrong? MPC, Direct X, OS, ffdshow?

Sorry, I don't know.

MPC is rev611-3
DirectX is 9.0c (2006 Dec)
OS is WinXP Pro (SP-2)
ffdshow is rev719

So everything should be up-to-date, eh?

// EDIT

With "Overlay Mixer" selected in MPC I get this:
http://img136.imageshack.us/img136/8554/overlaymf9.gif
So there is Overly Mixer on the graph...

But ffdshow still says "Queued samples: off: old video renderer does not support queue"

[clsid]

MPC also shows Overlay Mixer in "Play -> Filters" for me. Perhaps a bug in ffdshow that detects it wrong?

[haruhiko_yamagata]

Sorry, I don't know.

MPC is rev611-3
DirectX is 9.0c (2006 Dec)
OS is WinXP Pro (SP-2)
ffdshow is rev719

So everything should be up-to-date, eh?

// EDIT

With "Overlay Mixer" selected in MPC I get this:
http://img136.imageshack.us/img136/8554/overlaymf9.gif
So there is Overly Mixer on the graph...

But ffdshow still says "Queued samples: off: old video renderer does not support queue"
Thank you for the graph. I understood. When ffdshow detects "Video Renderer" in the graph, it says like that.
I'll fix the bug.

[haruhiko_yamagata]

Btw. recently I read quite a lot about queued output. What is it good for? How does it works?
Queue may save the CPU time and increase the frame rate when CPU load is high and droping a few frams/sec.

When ffdshow finished decoding, ffdshow delivers the sample to video renderer. Video renderer process the sample in its back buffer and waits untill it is time to present the image(the samples have timestamps). This waiting is waste of time. Queue utilize the time video renderer is waiting for the presentation time.

Assume the frame rate is 25. Each samples have to be processed in 40ms. Assume consecutive frames are decoded in 30ms, 45ms, 20ms, 50ms. With queue frame 2 and 4 can be delivered before presentation time. Without queue it failes to be in time and some video renderers drop such frames(depend on drivers).

Queue is especially effective when GPU is slow and frames are being dropped in video renderer. Queue was initially developped in G450.

Queue is not effective when it is too heavy and video is delayed, because the sample sent to video renderer is presented as soon as possible.

Queue is not effective in Timecodec.exe because Timecodec present the sample as soon as it is delivered.

Video renderer is executed in other thread, so it may help accelalation in some cases(usually not that much).

If you have fast CPU and GPU, you should disable queue.

[haruhiko_yamagata]

Just as side note -- if you want to test Theora decoding, or output space clamping:

Some community modelling project of the PlaneShift MMORPG made a preview video in Theora which looked distorted at first in ffdshow, like: [\]

The reason was: It uses some odd dimensions (1202x911), and YV12 output was enabled in ffdshow. Limiting the output to RGB and YUV 4:2:2 only "fixed" the messed output. But here I wonder: May it be recommendable to expand the dimensions to the next matching sizes (e.g. height of 912 lines) to avoid that?

http://vaalnor.mine.nu/Downloads/Video/waterfall.avi (312 KB)
Only VMR7 worked for me. All other renderers did not(I can't test Haali's). Obviously it is downstream's responsibility to reject such connection. But in practice they connects, means ffdshow has to do some work around. It is good to skip YV12 for such sized media.

Btw, is YV12 supported in VMR9?
If you have direct X SDK, see d3d9types.h
D3DFMT_UYVY = MAKEFOURCC('U', 'Y', 'V', 'Y'),
D3DFMT_R8G8_B8G8 = MAKEFOURCC('R', 'G', 'B', 'G'),
D3DFMT_YUY2 = MAKEFOURCC('Y', 'U', 'Y', '2'),
D3DFMT_G8R8_G8B8 = MAKEFOURCC('G', 'R', 'G', 'B'),
D3DFMT_DXT1 = MAKEFOURCC('D', 'X', 'T', '1'),
D3DFMT_DXT2 = MAKEFOURCC('D', 'X', 'T', '2'),
D3DFMT_DXT3 = MAKEFOURCC('D', 'X', 'T', '3'),
D3DFMT_DXT4 = MAKEFOURCC('D', 'X', 'T', '4'),
D3DFMT_DXT5 = MAKEFOURCC('D', 'X', 'T', '5'),

YV12 is not listed. Is YV12 + VMR9 with normal file working for evryone?

YV12 and VMR9 renderless/MPC does not work for me. ffdshow try YV12 first of all, This behavior may be changed for VMR9 renderless.

drevil_xxl said that it is black and white in WMP11/YV12/WinXp.

YV12 first may need reconsidering.

[wyrd]

Hi,in my case:

XPpro sp2
DirectX 9.0c(4.09.00.0904)
ATI Radeon(Omega3.8.252)
MPC611-3
WMP10 10.00.00.4036
ffdshow drevil_xxl's rev722
haali's media splitter 20061228

capture:
http://tirnanog.fate.jp/tmp/waterfall/
mpc_systemdefault.JPG
mpc_overlaymixer.JPG
mpc_vmr9_MixerModeOff.JPG
mpc_vmr9_MixerModeOn_YUVOff.JPG
mpc_vmr9_MixerModeOn_YUVOn.JPG
wmp_dontusevmr.JPG
wmp_overlaymixer.JPG
wmp_HQmode+ffdshow_forced_RGB32.JPG
wmp_HQmode.JPG

Regards

[foxyshadis]

I believe all YUV planar is converted inside the driver to UYVY before being passed on to the card, if the driver supports it. In my case it does, I have no problems using YV12+VMR9 with or without queue.

I have an odd bug that I've been unable to track down: Enabling avisynth drops frames for no apparent reason. It's totally repeatable on this sample (http://foxyshadis.slightlydark.com/random/[960x540%5D.mkv), and repeatable on certain panning scenes in other movies, but rare on others both larger and smaller. I can't figure it out. All the avisynth script has to contain is "last", if it's empty but enabled it'll be smooth. Queue has nothing to do with it, I'm sure of that. CPU usage is practically nothing, queue is at 9, and avisynth is the only filter enabled.

Better script: "ShowSMPTE()", which gives a counter that should change every frame. It doesn't, showing that it's sticking somewhere. Hrm. I'm not as lost as I was originally, but still don't see where the problem might be, assuming it's in the avisynth code.

[clsid]

In my experience YV12 output gives the best performance.

But in some (rare) cases it gives color shifts in Overlay, like in wyrd's mpc_overlaymixer.jpg screenshot.

A file that has color shift for me is "beyonce.at.the.bbc.1080mbaff.sample.ts (http://mirror05.x264.nl/public/force.php?file=./beyonce.at.the.bbc.1080mbaff.sample.ts)" (1440x1088). Funny thing is that coreavc has no such problem on this file when outputting YV12 to Overlay Mixer.

Two others files with the problem are "STORMAHEAD_PodsTrailer.mov" (SVQ3 640x259) and "dv-300708.mov" (SVQ3 300x225). So both with non-mod2/4/8/16 resolutions.

[haruhiko_yamagata]

Of course YV12 is the fastest. That's why it is still default despite many problems.

For the odd number line files, the decision making for the spec is easy. Just add one line at the bottom, though the implementation may be hard.

Thorny issue is what to do in VMR9 renderless. VMR9 renderless supports YV12 but it does not work for me(i82865G, both MPC and Zoom player pro).

[foxyshadis]

Oh, an idea I wanted to mention. What do you guys think about having grain filter retrigger every 45 ms? This avoids one of the big problems with using it with vfr video (wmv and mkv particularly) with long stretches of a single frame. Sometimes a full second of staring at the same motionless grain pattern on a black screen. At least if it's moving at 22fps the eye is fooled into seeing haze, instead of grain. 45 ms is long enough to not interfere with film or video, and while it'd trigger twice a frame for 20fps and lower, I don't think it would look too bad. (But I still intend to run experiments to find out.)

[clsid]

I have tested the new queue.

ffdshow rev723
MPC rev611-3
Windows 2000 Sp4

Renderers:

System default:
works ok now

Old renderer:
off: The video renderer in use is not supported.

Overlay Mixer:
off: The video renderer in use is not supported.

VMR-7 (windowed):
ok

VMR-7 (renderless):
ok

VMR-9 (windowed):
off: video driver can't work with YV12 + VMR-9 + queue

VMR-9 (renderless):
Weird behavior: queue shows "1" once in a while, the rest of the time it shows "off: The video renderer in use is not supported".

Edit: Here is the OSD log file (http://www.mytempdir.com/1139999).

[wyrd]

@clsid
confirm here too. beyonce_colshift (http://tirnanog.fate.jp/tmp/waterfall/beyonce_colshift.JPG)
also, STORMAHEAD_PodsTrailer.mov is similar, too.(even defaultrenderer mode)
I'm wondering, but a snapshot comes out normally.(???) I've using "Fraps" for overlay capture.

Test report for "new queue":
I've a one problem too. It seems like the clsid's report.
("Picture freezes after a few frames. Time slider progresses normally.")
http://tirnanog.fate.jp/tmp/for_new_queue/sakura_hangup.jpg
samplemovie (http://tirnanog.fate.jp/tmp/for_new_queue/sakuratan.avi) (1.7M)

Test with:
ffdshow rev706p2,rev721,rev722
MPC rev611-3 WinXP sp2
splitter:mp4=haali's mkv=MPC avi=system
non HT P4(queue output sample: on - daring^^)

Because this problem occurs intermittently, I still can't clarify a reproduction procedure.

The operation that i did and a sample which is easy to occur with my pc.
1.restart pc
2.play movie with vmr9(renderless)+mixer mode off
3.change vmr9 -> null and play
4.change null -> vmr9(windowed) and play
5.change vmr9(windowed) -> vmr9(renderless)+mixer mode on and play
6.change vmr9(rederless) mixer on -> vmr9(renderless) mixer mode off and play
repeat 1-6.(may or may not be reproduce)

or other way,(This was easy to reproduce for me.(in rev721))
1.restart pc
2.play movie with vmr9(renderless)+mixer mode off
3.other applicaiton exec(open) and close.(e.g word,excel,msvc,photoshop...as heavy as one can)
4.play movie with system default renderer.
5.other applicaiton exec(open) and close.(e.g same as above)
repeat 2-5. or 1-5.
(Plz put sample movie to a network drive if possible.)

This problem reproduce with or with out renderer mode(vmr9/overlay).
other freeze snapshot & sample movie:
sanyo (http://tirnanog.fate.jp/tmp/for_new_queue/sanyo_hangup.jpg),starwars (http://tirnanog.fate.jp/tmp/for_new_queue/starwars_hangup.jpg),unreal (http://tirnanog.fate.jp/tmp/for_new_queue/unreal_hangup.jpg),mezon (http://tirnanog.fate.jp/tmp/for_new_queue/mezon_hangup.jpg)
http://tirnanog.fate.jp/tmp/for_new_queue/

Best Regards.
oh, I do not yet test rev723...

[clsid]

That freeze issue was fixed in rev723.

[wyrd]

I tested drevil's rev724 until a while ago.:o
It works fine for me.
Thanks a lot.

[haruhiko_yamagata]

In my video card(i82865G), YV12 is not supported for any 1025 or larger holizontal size. I see some green artifact or black screen.

//EDIT
YV12 is not supported for any 320 or smaller holizontal size. Many files from YouTube are smaller than 320.

[haruhiko_yamagata]

Now YV12 plays better than before in odd line numbers.
STORMAHEAD_PodsTrailer.mov as well as many files from YouTube plays better.

I still have issue in VMR9, but I'm sure it's VMR9's responsibility unless using YV12 in VMR9 of itself is wrong.

Do you agree to adding an option like "Disable YV12 in VMR9" and set it to default?
Because YV12 is the fastest, I think we need a poll.

I guess it should work in DVD resolution. Please test using resize to small(dx<320) and large size(dx>1024).