ffdshow tryouts project: Discussion & Development

[cyberbeing]

@haruhiko_yamagata

I sent you a PM with a test build of xy-VSFilter (work-in-progress refactor2 branch (http://repo.or.cz/w/xy_vsfilter.git/shortlog/refs/heads/Refactor2)). When using madVR, FFDShow r4136 is outputting P010 to that build even with 8-bit video, and even when P010 output is disabled in FFDShow (tested on WinXP with MPC-HC). At least the problem of outputting P010 when it's disabled seems to be a FFDShow bug. This doesn't happen in CoreAVC or LAV Video, but that may be because neither of those decoders allow 8-bit -> 10-bit conversion.

Edit: I can confirm that r4139 fixed the P010 non-mod4 bug

[mandarinka]

Maybe you have P010 set in the preferred colorspace option? I noticed that when I pick a colorspace there, it will get used for output even if I untick it in the menu bellow.

[cyberbeing]

The Primary Output Colorspace is set to Auto in FFDShow, but it does seem possible that something xy-VSFilter is doing causes that Auto setting to fail.

Update: I tried setting Primary Output Colorspace to YV12 in FFDShow, but it still outputs P010 for 8-bit video to that xy-VSFilter build. Something else must be going on.

[madshi]

important bug report:

It seems that ffdshow does not set the "IMediaSample2::GetProperties" flag "AM_VIDEO_FLAG_REPEAT_FIELD". This is an important piece of information which is needed to reliably detect a 3:2 pulldown pattern for IVTC algorithms. Without this flag, soft-telecined content will look like 2:2 while hard-telecined content will look like 3:2. Broadcasts and DVDs often switch between soft-telecine and hard-telecine. So they will look like a wild mix of 3:2 and 2:2, which will make it hard to perform a proper IVTC.

FWIW, LAV Video Decoder sets this flag correctly.

@haruhiko_yamagata, I'm sorry that you're getting burried in bug reports at the moment. And I'm sorry that I just reported another one. It's good to have you back!

[fano]

Hy,
in your opinion it's possible to do a realtime Dolby True HD encoding as it's doable now with ffdshow audio, with the function "AC3 (SPDIF encode Mode)"?
In this way if I've an AAC file (for example but it can be a high quality FLAC file) instead of converting to LPCM (and windows can modify it add its annoying "click" or "plimp" when it has done or FAILED its unuseful things!) but a Dolby True HD bitstream cannot be touched...

It's that I do now (trascoding all audio stereo audio, too), with satisfaction as before if I was browsing and contemporary playing a song, the song "clicked" when I moved the mouse, I know should be the audio "exclusive mode" but, in my case, it does not worked... windows likes to do click and it clicks!
My audio is garbage, now :(

But a Dolby True HD bitstream goes untuched, right?
... and for its uncompressed nature, I do not have to compress and deteriorate my audio to avoid the clicks...

What do you say? It's feasible? Or too CPU intensive to do in realtime?

[nevcairiel]

Its not possible because none of the "HD" codecs have a free encoder available. You should rather go debug your audio setup, its certainly possible to stop windows from messing with it.

[fano]

Well but we've decoders, right?

It's not simple to do an encoder?
I suppose no :angry:

[haruhiko_yamagata]

@haruhiko_yamagata

I sent you a PM with a test build of xy-VSFilter (work-in-progress refactor2 branch (http://repo.or.cz/w/xy_vsfilter.git/shortlog/refs/heads/Refactor2)). When using madVR, FFDShow r4136 is outputting P010 to that build even with 8-bit video, and even when P010 output is disabled in FFDShow (tested on WinXP with MPC-HC). At least the problem of outputting P010 when it's disabled seems to be a FFDShow bug.
ffdshow's output pin is called for IPin::Connect twice.
The first call is called with pmt=NULL and succeeds.
The second call which should not happen is called with pmt fully specified. It's NV12 for me, not P010 though.
ffdshow has no choice to connect with NV12 but to reject connection.
The second call does not happen with normal vsfilter, so please look into your code.
ffdshow accepts unchecked color spaces in such cases. ffdshow is not too strict. It's not a bug.
Other filters may reject connection for the second call.
Good luck.:)

[ryrynz]

I can't reproduce. Please export the settings and send me the file.

I'll look further into it and get back to you if I can reproduce. I had similar problems last night but am not sure what was causing it.

Regarding naming of saved presets, is there any chance of having it the file name greater than 9 characters? All my preset names get truncated if I don't correct them.

Just one other thing, I've never managed to ever import my Avisynth code from the ffdshow exported settings without going viewing the exported file and manually copying the code for each preset, I documented that here.

http://sourceforge.net/tracker/index.php?func=detail&aid=3149428&group_id=53761&atid=471489

[haruhiko_yamagata]

important bug report:

It seems that ffdshow does not set the "IMediaSample2::GetProperties" flag "AM_VIDEO_FLAG_REPEAT_FIELD". This is an important piece of information which is needed to reliably detect a 3:2 pulldown pattern for IVTC algorithms. Without this flag, soft-telecined content will look like 2:2 while hard-telecined content will look like 3:2. Broadcasts and DVDs often switch between soft-telecine and hard-telecine. So they will look like a wild mix of 3:2 and 2:2, which will make it hard to perform a proper IVTC.

ffdshow handles soft-telecine internally if detected. It average timestamps and output the frame as progressive. So video renderers do not have to take care of soft-telecine. In theory...
Please make sure "Soft telecine" is checked in "Decoder options" page. And enable OSD "Frame timestamps" and "Frame duration".
ffdshow might be failing to detect soft-telecine. In that case, please send me the sample.
By the way, current MPEG2 decoders in ffdshow doesn't seem to be stable...

[xy]

Hi, I'm the current dev of xy-VSFilter. I'm not yet look into the problem myself. But:

ffdshow's output pin is called for IPin::Connect twice.
The first call is called with pmt=NULL and succeeds.
The second call which should not happen is called with pmt fully specified. It's NV12 for me, not P010 though.
ffdshow has no choice to connect with NV12 but to reject connection.
The second call does not happen with normal vsfilter, so please look into your code.


Normal vsfilter doesnot have any reconnection logic, definitely reconnection is a must for any filter want to make a effort to avoid color space transformation. xy-VSFilter does the reconnection in the stardard way (http://msdn.microsoft.com/en-us/library/windows/desktop/dd377502%28v=vs.85%29.aspx).


ffdshow accepts unchecked color spaces in such cases. ffdshow is not too strict. It's not a bug.


This is definitely a bug. Any trans-in-place filter will have reconnection logic. It means that when such filters connect to ffdshow, ffdshow may output unallowed formats.


Other filters may reject connection for the second call.

According to the document (http://msdn.microsoft.com/en-us/library/windows/desktop/dd377502%28v=vs.85%29.aspx), if QueryAccept return S_OK, they should not reject the reconnection (or at least, the reconnection is expected to success).

[haruhiko_yamagata]

xy, it is not you who decide it's a spec or bug. It's the spec. Be modest, you have to deal with existing filters.
ffdshow connects as requested. Your filter requests ffdshow to connect using NV12, and so ffdshow accepts it even if NV12 is unchecked in the dialog. What's wrong?

[haruhiko_yamagata]

For the record, ffdshow raw also doesn't deal with any stride, it will exhibit the same problems (green bar, etc).
The best solution would be if the post-processor takes over the buffer control and then requests the stride (much like a renderer would function).In my two years absence, it has been buried in oblivion. Anyway, done at rev 4142 (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout?view=revision&sortby=date&revision=4142). This is a big change, which needs testing.
ffdshow's allocator was copied from guliverkli, so it is natural that vsfilter and ffdshow have the same issue.
TffdshowDecVideoAllocator.cpp says,
/*
* Copyright (c) 2004-2006 Milan Cutka
* based on CDirectVobSubInputPin by Gabest
I hope MPC-HC project can handle this as well. Who should I contact?

[cyberbeing]

What's wrong?
Downstream video filters shouldn't be allowed to connect with formats that the user has explicitly disabled in FFDShow? When an end-user disables something, the expectation is for it to always stay disabled?

FFDShow shouldn't do an 8-bit->10-bit conversion for 8-bit 4:2:0 video if the filter/renderer supports YV12/NV12, even if it asks for P010? From a performance and practicality point of view, FFDshow should only perform 8-bit -> 10-bit conversion as a last resort if the filter/renderer doesn't accept any 8-bit formats?

Both fall under the umbrella of having FFDShow using its knowledge of the video bit-depth and chroma sub-sampling to make smarter output format decisions, and not allow other filters to do stupid things because they don't know any better. Leaving FFDShow converters completely unrestricted as they are now, has both advantages and disadvantages.

filter requests ffdshow to connect using NV12, and so ffdshow accepts it
That xy-VSFilter test build requesting formats it shouldn't be requesting was the biggest issue in that build. FFDShow was indeed doing exactly what xy-VSFilter asked, and that was the problem.
Be modest, you have to deal with existing filters.
The only reason I PM'ed you a broken build was because it was causing some 'odd' behavior in FFDShow, not because xy planned to keep it that way. Changes to this fix this undesired behavior were already underway before I originally posted.

[xy]

What's wrong?

I'll repeat it:
Any trans-in-place filter will have reconnection logic. It means that when such filters connect to ffdshow, ffdshow may output unallowed formats.


Your filter requests ffdshow to connect using NV12, and so ffdshow accepts it even if NV12 is unchecked in the dialog.

Before the request, xy-VSFilter would quire ffdshow if it want to output NV12, and ffdshow returns OK even if NV12 is unchecked in the dialog.

[haruhiko_yamagata]

Downstream video filters shouldn't be allowed to connect with formats that the user has explicitly disabled in FFDShow? When an end-user disables something, the expectation is for it to always stay disabled?
As xy explained above, ffdshow must output unallowed formats. It is already connected and rejecting reconnection is not a good choice even if it is possible in QuerryAccept.

FFDShow shouldn't do an 8-bit->10-bit conversion for 8-bit 4:2:0 video if the filter/renderer supports YV12/NV12, even if it asks for P010? From a performance and practicality point of view, FFDshow should only perform 8-bit -> 10-bit conversion as a last resort if the filter/renderer doesn't accept any 8-bit formats?
xy-filter force ffdshow to do so.

Both fall under the umbrella of having FFDShow using its knowledge of the video bit-depth and chroma sub-sampling to make smarter output format decisions, and not allow other filters to do stupid things because they don't know any better. Leaving FFDShow converters completely unrestricted as they are now, has both advantages and disadvantages.
ffdshow has no choice in this case.

That xy-VSFilter test build requesting formats it shouldn't be requesting was the biggest issue in that build. FFDShow was indeed doing exactly what xy-VSFilter asked, and that was the problem. The only reason I PM'ed you a broken build was because it was causing some 'odd' behavior in FFDShow, not because xy planned to keep it that way. Changes to this behavior were already underway before I originally posted.
Please don't send me a broken build!
Without any explanation...
It's not odd at all. It's a computer program and it works as it is forced to do.

[haruhiko_yamagata]

I'll repeat it:
Any trans-in-place filter will have reconnection logic. It means that when such filters connect to ffdshow, ffdshow may output unallowed formats.
So ffdshow is working as it should. What do you want to say?

[xy]

So ffdshow is working as it should. What do you want to say?

FFDShow has unexpected behavior when working with any filters that have reconnection logic, not only xy-VSFilter. So you are confirming that?

[xy]

rejecting reconnection is not a good choice even if it is possible in QuerryAccept

If QuerryAccept returns the right value, than the reconnection never happen. If a downstream filter do a reconnection before QuerryAccept or even if upstream filter doesnot accept it, than that is its fault.

[cyberbeing]

Please don't send me a broken build!
Without any explanation...
My mistake, I'll try to be a bit more clear in the future. :scared:

When I stated it was a "work-in-progress test build", from secondary "refactor branch", which I was unwilling to post publicly, I was attempting to imply it was experimental non-release build which had known issues and bugs.The build was sent only to assist in reproducing the behavior and determining why FFDShow was doing what it was doing.

After-all, FFDShow is the only decoder which contains an unrestricted 8bit->10bit converter, and that is the main reason why that build broke. Fault of xy-VSFilter for not anticipating it. ;)

[haruhiko_yamagata]

If QuerryAccept returns the right value, than the reconnection never happen. If a downstream filter do a reconnection before QuerryAccept or even if upstream filter doesnot accept it, than that is its fault.
I know ffdshow can return an error on QuerryAccept. But QuerryAccept may be called for an inevitable reason (for example, the hardware can no longer accept the prior color space), in that case, rejecting may result the application stop working. What happens after rejection depends on the downstream. ffdshow's choice is to keep connection as long as it is possible even by outputting unckecked color space. It's not violating the manner of DirectShow at all.
ffdshow had code to reject that strictly, which is currently disabled (TffdshowDecVideo::setOutputMediaType etc). It was Milan's choice and I completely agree with him.

[xy]

I know ffdshow can return an error on QuerryAccept. But QuerryAccept may be called for an inevitable reason (for example, the hardware can no longer accept the prior color space), in that case, rejecting may result the application stop working. What happens after rejection depends on the downstream. ffdshow's choice is to keep connection as long as it is possible even by outputting unckecked color space. It's not violating the manner of DirectShow at all.
ffdshow had code to reject that strictly, which is currently disabled (TffdshowDecVideo::setOutputMediaType etc). It was Milan's choice and I completely agree with him.

Ah, that's news to me. Although I'm not really understand the technic point, (for COREAVC returns an error on QuerryAccept. Or think about it in another way, if ffdshow is queried for some formats it doesnot implement, then it still needs to reject. The unchecked types can be seen as unimplemented types.) I'm OK with this answer.

[haruhiko_yamagata]

Ah, that's news to me. Although I'm not really understand the technic point, (for COREAVC returns an error on QuerryAccept. Or think about it in another way, if ffdshow is queried for some formats it doesnot implement, then it still needs to reject. The unchecked types can be seen as unimplemented types.) I'm OK with this answer.ffdshow rejects connection if the media type is not supported. There are not too may formats that ffdshow can connect.const TcspFcc cspFccs[]= {
_l("YV12") ,FOURCC_YV12,FF_CSP_420P|FF_CSP_FLAGS_YUV_ADJ,false,true,
_l("I420/IYUV"),FOURCC_I420,FF_CSP_420P|FF_CSP_FLAGS_YUV_ADJ|FF_CSP_FLAGS_YUV_ORDER,false,true,
_l("YUY2") ,FOURCC_YUY2,FF_CSP_YUY2,false,true,
_l("YVYU") ,FOURCC_YVYU,FF_CSP_YVYU,false,true,
_l("UYVY") ,FOURCC_UYVY,FF_CSP_UYVY,false,true,
_l("VYUY") ,FOURCC_VYUY,FF_CSP_VYUY,false,true,
_l("RGB32") ,FOURCC_RGB3,FF_CSP_RGB32,true,true,
_l("RGB24") ,FOURCC_RGB2,FF_CSP_RGB24,true,true,
_l("RGB555") ,FOURCC_RGB5,FF_CSP_RGB15,true,true,
_l("RGB565") ,FOURCC_RGB6,FF_CSP_RGB16,true,true,
_l("CLJR") ,FOURCC_CLJR,FF_CSP_CLJR,false,false,
_l("Y800") ,FOURCC_Y800,FF_CSP_Y800,false,true,
_l("NV12") ,FOURCC_NV12,FF_CSP_NV12,false,false,
_l("P016") ,FOURCC_P016,FF_CSP_P016,false,false,
_l("P010") ,FOURCC_P010,FF_CSP_P010,false,false,
_l("P210") ,FOURCC_P210,FF_CSP_P210,false,false,
_l("P216") ,FOURCC_P216,FF_CSP_P216,false,false,
_l("AYUV") ,FOURCC_AYUV,FF_CSP_AYUV,false,false,
_l("Y416") ,FOURCC_Y416,FF_CSP_Y416,false,false,
NULL,0
};

[madshi]

ffdshow handles soft-telecine internally if detected. It average timestamps and output the frame as progressive. So video renderers do not have to take care of soft-telecine. In theory...
Please make sure "Soft telecine" is checked in "Decoder options" page. And enable OSD "Frame timestamps" and "Frame duration".
ffdshow might be failing to detect soft-telecine. In that case, please send me the sample.
By the way, current MPEG2 decoders in ffdshow doesn't seem to be stable...
Thanks, I didn't know that "soft telecine" option in the decoder options. That option seems to work ok if the whole stream is soft-telecined. But if the stream is a mixture of soft- and hard-telecine (I mean if it switches between soft- and hard-telecine all the time), it fails to do IVTC properly. That probably was to be expected, so it's not a bug. Doesn't matter, anyway, cause I'm working on my own IVTC algorithm. So I've disabled that "soft telecine" option in ffdshow. After I did that, things looked better, but there's still something wrong. With the "soft telecine option" disabled, here are the flags madVR receives from ffdshow:

168: top field first: -, repeat first field: +
169: top field first: +, repeat first field: -
170: top field first: +, repeat first field: +
171: top field first: -, repeat first field: -
172: top field first: -, repeat first field: +
173: top field first: +, repeat first field: -
174: top field first: +, repeat first field: -
175: top field first: +, repeat first field: -
176: top field first: +, repeat first field: -
177: top field first: +, repeat first field: -
178: top field first: +, repeat first field: -
179: top field first: -, repeat first field: -
180: top field first: -, repeat first field: -
181: top field first: -, repeat first field: +
182: top field first: +, repeat first field: -
183: top field first: +, repeat first field: +
184: top field first: -, repeat first field: -
185: top field first: -, repeat first field: +
For comparison, here are the correct flags, output by ffmpeg/libav directly:

168: top field first: -, repeat first field: +
169: top field first: +, repeat first field: -
170: top field first: +, repeat first field: +
171: top field first: -, repeat first field: -
172: top field first: -, repeat first field: +
173: top field first: +, repeat first field: -
174: top field first: +, repeat first field: -
175: top field first: +, repeat first field: -
176: top field first: +, repeat first field: -
177: top field first: +, repeat first field: -
178: top field first: +, repeat first field: -
179: top field first: +, repeat first field: +
180: top field first: -, repeat first field: -
181: top field first: -, repeat first field: +
182: top field first: +, repeat first field: -
183: top field first: +, repeat first field: +
184: top field first: -, repeat first field: -
185: top field first: -, repeat first field: +
You can see that the video switches from soft-telecine to hard-telecine in frame 173. Then it switches back to soft-telecine in frame 179. But ffdshow doesn't output the correct flags for frame 179. This results in my IVTC algorithm detecting a break in the 3:2 cadence. With the correct flags there's no cadence break detected, and my algorithm walks right through the soft->hard->soft telecine switch.

[haruhiko_yamagata]

But if the stream is a mixture of soft- and hard-telecine (I mean if it switches between soft- and hard-telecine all the time), it fails to do IVTC properly.Yeah, there are such difficult streams. I have not looked into the code detail, but I can imagine it's failing to detect the switching. I have too much to do, please wait.

[madshi]

Yeah, there are such difficult streams. I have not looked into the code detail, but I can imagine it's failing to detect the switching. I have too much to do, please wait.
Please don't misunderstand me. I couldn't care less about whether ffdshow's internal IVTC algorithm works or not. The only thing that bothers me is that if I tell ffdshow to *NOT* try to do IVTC, then it outputs wrong flags. The fix for that should be pretty easy. In this configuration ffdshow should not even try to detect the switching. It should just plain and simply output the video bitstream flags as they are. Nothing should be simpler than that.

[Blight]

Thank you for testing that filter. I've been thinking of removal of the registration, but if you have any plan to use it, I'll fix it.

Hi,
I'm not sure what you mean by "removal of the registration".
I allow users to choose between FFDShow and VobSub for subtitle rendering in ZP.
I'm rewriting all the stream-selection code for v8.1 and encountered this bug.

[Reino]

http://img847.imageshack.us/img847/4470/ffdshowrev4142.th.jpg (http://img847.imageshack.us/img847/4470/ffdshowrev4142.jpg)

Caused by Rev.4142? Rev.4127 didn't have this.


Btw, when I'm calling forth FFDShow's cubic interpolation deinterlacing filter through Avisynth;ffdshow(options="isDeinterlace=1,deinterlaceAlways=1,deinterlaceMethod=2") it works flawlessly in AvsP (GUI for Avisynth) and in any DirectShow player, but NOT in MPC-HC. Script error: there is no function named "ffdshow" is what I'm being shown. Are you developers familiar with this? (perhaps I should post this in MPC-HC's thread as well, because it initially concerns MPC-HC of course)

[Reino]

VC1 crash was fixed yesterday. It still randomly crashes while closing the player though.I thought MPC-HC's code and FFDShow were pretty much identical, or at least have a lot simularities, but when I'm testing a 1280x720 60fps WMV[VC-1+WMA9.2]-file with MPC-HC's internal VC-1 decoder my cpu is @ ±10% utilization and plays absolutely smooth, while with the FFDShow DXVA Video Decoder it's @ ±50% and a bit choppy every now and then.

[haruhiko_yamagata]

Hi,
I'm not sure what you mean by "removal of the registration".
I allow users to choose between FFDShow and VobSub for subtitle rendering in ZP.
I'm rewriting all the stream-selection code for v8.1 and encountered this bug.
I have fixed the crash issue and dialog problem at rev 4137-4138.

[Thunderbolt8]

when playing some VC-1 videos with the WMV DecoderDMO and ffdshow set to raw video (and LAVsplitter), the screen remains dark and playback doesnt start. it works fine though when deactivating ffdshow. why is this?

heres an example: http://www.mediafire.com/?vhxgz1qwxmc2u6b

[ryrynz]

Haruhiko, regarding the bug I posted earlier,

If you create a preset under ffdshow raw that does not have the same name as a preset under normal ffdshow then there is no default selected (nothing in bold) This is as I would expect.

If you click on create a new profile from selected, ffdshow crashes with an error in rundll32 and exits instead of throwing up an error that no profile is selected.

Also if you click on codecs while no preset is selected the rest of the menu items disappear.

[fano]

Its not possible because none of the "HD" codecs have a free encoder available. You should rather go debug your audio setup, its certainly possible to stop windows from messing with it.

I'll try to use an example:
Yesterday I was playing (using Foobar it should be the best audio player, right?) one of these free to use flac multichannel audio clip:
http://www.2l.no/hires/index.html

then I decide to browse a little... Firefox I don't why likes to do a little "click" :(
... foobar is in the trash... and of the suber-uber audio session if it does "click" it's unuseful.

I do know there is a thing know as "Kernel Streaming" that should bypass windows mixer et all but... foobar after installing the KS plugin says that "I can't open device" :angry:

The only way to play a song in peace it's to use ffdshow or reclock "AC3 encode mode"... you agree it's pretty ridiculous to compress an HD lossless track to no hear the "click" :sly:

[haruhiko_yamagata]

http://img847.imageshack.us/img847/4470/ffdshowrev4142.th.jpg (http://img847.imageshack.us/img847/4470/ffdshowrev4142.jpg)

Caused by Rev.4142? Rev.4127 didn't have this.
A Microsoft's DirectShow filter "AVI/WAV File Source" can somehow process avs file and output raw formats, but it cannot connect directly to a video renderer. I don't know if it is a intended feature by the AviSynth project or just a user's hack.
A week ago (http://forum.doom9.org/showthread.php?p=1543126#post1543126), I didn't believe that YV12 does not connect to a video renderer. This time I found the truth. As an intermediate filter, ffdshow or Microsoft's color space converter filter is needed.
I think All filters that can directly work with a video renderer can handle stride changes. Unfortunately AVI/WAV File Source cannot handle stride changes.
I hope this is the only exception that require dirty workaround. The code for this has been written (not committed yet).

[haruhiko_yamagata]

Haruhiko, regarding the bug I posted earlier,

If you create a preset under ffdshow raw that does not have the same name as a preset under normal ffdshow then there is no default selected (nothing in bold) This is as I would expect.

If you click on create a new profile from selected, ffdshow crashes with an error in rundll32 and exits instead of throwing up an error that no profile is selected.

Also if you click on codecs while no preset is selected the rest of the menu items disappear.
I see. The crash is reproduced.

[Blight]

haruhiko_yamagata:
Thank you for the fix.

[Blight]

Bug Report:
When using the VobSub COM interface with the "putParamStrW(IDFF_subFilename,FileName)", it doesn't update the IAMStreamSelect interface.
I expect it to only list the specified file, or add the specified subtitle file to the existing stream list (preferable).
Note that I'm using "putParam(IDFF_subAutoFlnm,False)" to enable the user-selected external sub-file.

More details:
If no auto-sub file is found by the ffdshow sub filter and one is manually loaded by the functions above, the IAMStreamSelect interface returns no streams whatsoever.

P.S.
The RAW and Subtitle filter instances seem to share the same registry location to save their settings. Is this intentional?

[haruhiko_yamagata]

when playing some VC-1 videos with the WMV DecoderDMO and ffdshow set to raw video (and LAVsplitter), the screen remains dark and playback doesnt start. it works fine though when deactivating ffdshow. why is this?

heres an example: http://www.mediafire.com/?vhxgz1qwxmc2u6bThe freeze is reproduced.
I don't know why though.

[haruhiko_yamagata]

Btw, when I'm calling forth FFDShow's cubic interpolation deinterlacing filter through Avisynth;ffdshow(options="isDeinterlace=1,deinterlaceAlways=1,deinterlaceMethod=2") it works flawlessly in AvsP (GUI for Avisynth) and in any DirectShow player, but NOT in MPC-HC. Script error: there is no function named "ffdshow" is what I'm being shown. Are you developers familiar with this? (perhaps I should post this in MPC-HC's thread as well, because it initially concerns MPC-HC of course)
I can reproduce. Old MPC works fine.

[clsid]

AviSynth plugin loading issues can be solved by adding the plugin dir to %PATH%.

[haruhiko_yamagata]

Please don't misunderstand me. I couldn't care less about whether ffdshow's internal IVTC algorithm works or not. The only thing that bothers me is that if I tell ffdshow to *NOT* try to do IVTC, then it outputs wrong flags. The fix for that should be pretty easy. In this configuration ffdshow should not even try to detect the switching. It should just plain and simply output the video bitstream flags as they are. Nothing should be simpler than that.OK, but as you can see, I'm buried too deeply in too many bugs. Please wait.

[madshi]

OK, but as you can see, I'm buried too deeply in too many bugs. Please wait.
I'm not in a hurry, take all the time you need... :)

[Reino]

AviSynth plugin loading issues can be solved by adding the plugin dir to %PATH%.ffavisynth.avsi:
try { Load_Stdcall_Plugin("C:\Program Files\Media\AviSynth 2.5\plugins\ffavisynth.dll") }
catch(err_msg) { NOP() }Confirmed! Still funny though, again this only affects MPC-HC, unlike Zoom Player and alike.

Btw, haruhiko_yamagata, thanks for your time.

[Thunderbolt8]

The freeze is reproduced.
I don't know why though.
I got it to work by unticking the internal MPEG PS/TS/PVA filter in MPC-HC (also updated to the latest test version of LAVfilters, not sure whether this had an effect though).

and the bottom of the loaded filter list in MPC-HC, theres a filter called "File Source (Async)" loaded now as well. got no idea what for though.

[egur]

Lately I'm getting a lot of runtime errors from libavcodec under WMC 64 bit.
WMC spawns a lot of ffdshow instances in order to create thumbnails for media files.
The error is that memory is written past the area allocated to the av context. Happens when this line is called (TvideoCodecLibavcodec.cpp):
libavcodec->av_free(avctx);
Running Parallel Inspector (memory checker) didn't reveal anything and looking at the code didn't point me to the problem. Looks like a memory overrun from somewhere in the code.
The above error is followed by a second one - the pointer sent to RtlFreeHeap (Ntdll.dll) is bad.
Commenting the above line removes all the runtime errors.

BTW, due to lazyness, I didn't compile the ffmpeg dll, I used the one from the last clsid build from SourceForge.

This can also happen when opening a file in WMC and skipping a few times.
The crash always happen then libavcodec is decoding video. Crashed on h264 content among others.

Can someone reproduce?

[haruhiko_yamagata]

I got it to work by unticking the internal MPEG PS/TS/PVA filter in MPC-HC (also updated to the latest test version of LAVfilters, not sure whether this had an effect though).

and the bottom of the loaded filter list in MPC-HC, theres a filter called "File Source (Async)" loaded now as well. got no idea what for though.
I'm not sure if this is a bug of ffdshow or not, but as far as I can observe, ffdshow is not called an after successful call to IPin::NewSegment. It doesn't look like a dead lock in ffdshow. There's little hint to fix this in ffdshow.
Please submit a request to MPC-HC project and ask if they can help us.

[haruhiko_yamagata]

Bug Report:
When using the VobSub COM interface with the "putParamStrW(IDFF_subFilename,FileName)", it doesn't update the IAMStreamSelect interface.
I expect it to only list the specified file, or add the specified subtitle file to the existing stream list (preferable).
Note that I'm using "putParam(IDFF_subAutoFlnm,False)" to enable the user-selected external sub-file.

More details:
If no auto-sub file is found by the ffdshow sub filter and one is manually loaded by the functions above, the IAMStreamSelect interface returns no streams whatsoever.I'll take a look later.

P.S.
The RAW and Subtitle filter instances seem to share the same registry location to save their settings. Is this intentional?
I might have thought that it was unnecessary to separate the settings. On second thought, it may be better to separate.

[haruhiko_yamagata]

Lately I'm getting a lot of runtime errors from libavcodec under WMC 64 bit.
WMC spawns a lot of ffdshow instances in order to create thumbnails for media files.
The error is that memory is written past the area allocated to the av context. Happens when this line is called (TvideoCodecLibavcodec.cpp):
libavcodec->av_free(avctx);
Running Parallel Inspector (memory checker) didn't reveal anything and looking at the code didn't point me to the problem. Looks like a memory overrun from somewhere in the code.
The above error is followed by a second one - the pointer sent to RtlFreeHeap (Ntdll.dll) is bad.
Commenting the above line removes all the runtime errors.

BTW, due to lazyness, I didn't compile the ffmpeg dll, I used the one from the last clsid build from SourceForge.

This can also happen when opening a file in WMC and skipping a few times.
The crash always happen then libavcodec is decoding video. Crashed on h264 content among others.

Can someone reproduce?I have not looked into the issue yet. Did you try a new binary? New version is available from XvidVideo.RU (http://www.xvidvideo.ru/x264-video-codec).
Binary compatibility of libavcodec.dll is not guaranteed between versions.

[oddball]

Any idea on that logo away issue? I can't mask out the very edges of a logo that are right up to the edges of the video.

[Blight]

haruhiko_yamagata:
I have a very weird ffdshow subtitle renderer behavior.
I've written an automatic subtitle stream-selection code based on Language ID, Name, etc.
When I'm enabling a stream matching the user params right after the graph is built, depending on what appears to be a race condition, it seems ffdshow is selecting a different (external file) subtitle stream after I specify the stream I want (one of several embedded streams) using the IAMStreamSelect interface.

If I enable 'give embedded priority over subtitle files', it seems to fix the issue, but I haven't tested it against enough content and other splitter filters.
Can you disable FFDShow from selecting a subtitle stream itself if the IAMStreamSelect interface was issued a call to enable a stream?

Another cosmetic glitch:
If you have both the FFDShow Video decoder and the FFDShow Subtitle filter in the same graph, the FFDShow video decoder's IAMStreamSelect interface contains duplicate streams (The vid decoder grabs the stream list from the sub-filter).
You need to blacklist other ffdshow filters when building the stream list.

Screenshot:
http://t.inmatrix.com/ffdshowglitch.png