ffdshow tryouts project: Discussion & Development

[Terka]

>LoRd_MuldeR
it works now, thank you.
Has Dscaler some deint. filters that output 50p, not 25p?

[haruhiko_yamagata]

One last thing (which I have asked earlier): can you prevent DFX to steal the focus from the player (or is this the fault of DFX) ?
I'm afraid I can't.

[WorBry]

With the ffavisynth filter it is. It's installed in ffdshow's folder, either loadplugin() it from there or put it in your avisynth plugin folder. Create a preset with mocomp deinterlacing enabled. In the avisynth script, call ffdshow("presetname") and it'll run the video through ffdshow.

Not all versions come with ffavisynth.dll. Post to the ffdshow thread if you have trouble.

OK, that applies to calling FFDShow filters from an AVISynth script. If I understand correctly, it is also possible to do the reverse i.e. call an AVI script from FFDShow. If so, could someone explain how to do this?

My interest is, in part, sparked by the topic I addressed earlier in this thread:

http://forum.doom9.org/showthread.php?p=999502#post999502

If no-one is interested in adding Yadif to the list of deinterlace presets in FFDShow, is it at least possible to call the AVISynth plugin from FFDShow?

[Leak]

If no-one is interested in adding Yadif to the list of deinterlace presets in FFDShow, is it at least possible to call the AVISynth plugin from FFDShow?
*cough* (http://leak.no-ip.org/AviSynth/ffdshow/docs/html/en/AviSynth.htm)

(While I'm at it - sorry all for not having finished the next update to the AviSynth filter, but real life intruded; I'll hopefully get it done this weekend...)

np: Adult. - Red Herring (Why Bother?)

[WorBry]

*cough* (http://leak.no-ip.org/AviSynth/ffdshow/docs/html/en/AviSynth.htm)

(While I'm at it - sorry all for not having finished the next update to the AviSynth filter, but real life intruded; I'll hopefully get it done this weekend...)


Thanks for the link Leak :) I'd pretty much figured thats how its done, but whenever I've tried even simple scripts with vfw-FFDShow in VDub, either it crashes or freezes at the first frame. Got Yadif sort of working with the 'main' FFDShow decoder (played back with TCMP) but the motion is very jerky. Maybe, as the tutorial suggests, I need to adjust the 'buffers back/ahead'. However, in the try-outs build I'm using (rev 1145 6th May) I can see no such setting. Nor can I find 'AVISynth' in the listed OSD display items (and in the vfw version I cannot see OSD at all in the decoder config); which version should I use, or is that coming in your update?

Cheers

[Leak]

Thanks for the link Leak :)
Glad to be of service.
However, in the try-outs build I'm using (rev 1145 6th May) I can see no such setting. Nor can I find 'AVISynth' in the listed OSD display items (and in the vfw version I cannot see OSD at all in the decoder config); which version should I use, or is that coming in your update?
I'm still working on it, but you can get builds with it here (http://leak.no-ip.org/AviSynth/ffdshow/) - just remember that those builds aren't always based on the latest and greatest ffdshow code.

[haruhiko_yamagata]

Has anyonw looked into this bug:

http://sourceforge.net/tracker/index.php?func=detail&aid=1695996&group_id=173941&atid=867360

"When I build a graph with Haali-splitter, VC-1 codec from Microsoft, I have
a fine playback at 24 fps (HD-DVD-rip from my own Discs onto my media,
server, playing *.evo).

When I integrate ffdshow into the chain, re-clock reports not only 30fps,
but audio and video are heavily out of sync. It does not matter if I use
ffdshow as raw-postprocessor or if I use ffdshow as VC-1-decoder as well. As
soon as ffdshow is in the video-chain, video and audio is out of sync
(beta2 release). "

?

If not, could you please be so kind ? I would love to use ffdshow as my playback/pq-tuning solution as well for HD-DCD, as my cinema has a pretty big screnn and ffdshow really shines...
ffdshow video decoder receives timestamps saying 30fps(33ms) from VIDEOINFOHEADER2 and IMediaSample::GetTime.
This is not likely ffdshow's bug. Please report this issue to Haali.
I don't know what trick Microsoft's codec use though.

[DeepBeepMeep]

ffdshow video decoder receives timestamps saying 30fps(33ms) from VIDEOINFOHEADER2 and IMediaSample::GetTime.
This is not likely ffdshow's bug. Please report this issue to Haali.
I don't know what trick Microsoft's codec use though.

I had already reported the incompatibility to Haali and he was quite convinced the issue was not coming from his filter.

In fact it could be that the stream is really 29.976 fps in order to played on NTSC TV and therefore the average frame duration of 30ms makes sense. However this should be combined with the telecine flags (AM_VIDEO_FLAG_FIELD1FIRST / AM_VIDEO_FLAG_REPEAT_FIELD) which are supposed to increase the duration of every other frame by 50%. So to obtain 23.97 fps the durations of the frames should 50ms 33ms 50ms 33ms etc... It seems here the telecine flags are ignored by a filter or not forwarded to the next filter in the chain.

[cc979]

i have been busy with other things, just tried to build svn:1155 and fails with many errors

as there been some gcc side changes?

cheers

ps. looked more closely errors are on libavcodec/svq3.c & libavcodec/h264.c

[haruhiko_yamagata]

I had already reported the incompatibility to Haali and he was quite convinced the issue was not coming from his filter.

In fact it could be that the stream is really 29.976 fps in order to played on NTSC TV and therefore the average frame duration of 30ms makes sense. However this should be combined with the telecine flags (AM_VIDEO_FLAG_FIELD1FIRST / AM_VIDEO_FLAG_REPEAT_FIELD) which are supposed to increase the duration of every other frame by 50%. So to obtain 23.97 fps the durations of the frames should 50ms 33ms 50ms 33ms etc... It seems here the telecine flags are ignored by a filter or not forwarded to the next filter in the chain.
Thank you. I'll look into it again.

[iron2000]

What needs to be enabled for ffdshow to do the colour settings of VMR9?

[Kado]

@iron2000
Try using only RGB32 in the output color spaces, disabling the others.

@haruhiko_yamagata
Found an issue with the "allow multichannel audio processing" option. If you play a file with two audio streams (one 5.1 and other 2.0) and have the option disabled, when the 5.1 track is played no processing is made which is normal but when you change to the 2.0 track no audio processing occurs even though ffdshow is outputting audio properly. If you enable then disable the option during the 2.0 audio playback processing begins and continues as ffdshow is now aware of the type of audio track.
If you do the reverse it happens again: playing 2.0 audio with option disabled and sound processing ,switch to 5.1 audio and sound will processed with the option disabled which is not ok for stereo plugins.
This probably happens because i'm using haali media splitter which handles the streams, so ffdshow is not totally aware of the audio stream changes.

P.S.=> Is it possible to add a function to load DirectX audio dsp's from within ffdshow like is done with the winamp plugins?

[Leak]

While I'm putting the finishing touches to a new version of my patch - is it just me, or are all recent ffdshow installer builds missing all of the html documentation that is still hooked up inside the config dialogs?

np: Mia Doi Todd - Muscle, Bond & Blood (Chessie Mix) (La Ninja)

[fano]

I'm using the release 1104 of Apr 15 2007 - ICL and I've some issues with subtitles... they are always on and I like to have the possibility that they are off at default and that pressing a key on my remote I can active them and if they are more than 1 cicle around them as is:

no subs -> sub 1 -> sub 2 -> ... -> no subs

I've found the keys & remote section and I'm tried to use the CTRL+ALT+L combination (it was CTRL+ALT+S but it conflicted with Mediaportal) and with keyboard it works (but it doesn't cicle!!! On/Off only) but with my Imon remote I've to press longer to have the command executed and in this way ffdshow sees more that a key pression and do on-off-on for example :eek:

This is not my remote fault... it works well with Mediaportal and Medioo...

Another annoying thing is that after I've enabled/disabled subs for a file ffdshow remember the previous status and that is not
good in my opion....

Thanks for help,
fano

[Leak]

Here's the aforementioned AviSynth patch update:

Download (http://leak.no-ip.org/AviSynth/ffdshow/ffdshow_AviSynth_rev1167_20070514.exe)
Documentation (http://leak.no-ip.org/AviSynth/ffdshow/docs/html/en/avisynth.htm)
Patch (https://sourceforge.net/tracker/index.php?func=detail&aid=1676882&group_id=173941&atid=867362) (against rev. 1167)

Changes:

* Reset AviSynth only after deactivating the filter or when the image size or the script changes - that's about as low as I can go when it comes to resetting AviSynth

* Added a help webpage for the filter (see link above)

* One additional pulldown option ("Smooth timestamps") to smooth out alternating timestamps without duplicating fields - this should make adding/dropping frames work on 24 FPS movie material, probably even on hybrid material, but the output frame rate will then vary proportional to the input frame rate

* Global variables "ffdshow_dar_x" and "ffdshow_dar_y" now available to the AviSynth script to get and/or set the aspect ratio and process images differently depending on the aspec ratio; this way the script can react to aspect ratio changes since it is reset when the ratio changes:


function Resize_16_9(v)
{
ffdshow_dar_x=4 ffdshow_dar_Y=3
return v.LanczosResize(800,480,22,0,676,480).AddBorders(0,60,0,60)
}

function Resize_4_3(v)
{
ffdshow_dar_x=4 ffdshow_dar_Y=3
return v.LanczosResize(800,600)
}

TFM(order=1,chroma=false)
TDecimate(mode=1,hybrid=1,conCycle=1,chroma=false)

ar=float(ffdshow_dar_x)/float(ffdshow_dar_y)
diff=ar-1.5555

abs(abs(diff)-0.2222) > 0.05 ? last : \
(diff >= 0 \
? last.Resize_16_9 \
: last.Resize_4_3)
That script is fitting 16:9 and 4:3 DVD video into 800x600 for my projector, in case you're wondering... :D

Oh, and make sure "Keep aspect ratio" is off in MPC if you're using it when tinkering with the aspect ratio, as MPC will ask the DVD navigator for the DVD's current aspect ratio instead of using the video's output aspect ratio, and that will get the resized video squashed another time... :(

TODO: Use the above to actually watch a DVD again on my projector several weeks after the last time... :/

np: Tarwater - When Tomorrow Comes (Spider Smile)

[WorBry]

Here's the aforementioned AviSynth patch update:

Download (http://leak.no-ip.org/AviSynth/ffdshow/ffdshow_AviSynth_rev1167_20070514.exe)
Documentation (http://leak.no-ip.org/AviSynth/ffdshow/docs/html/en/avisynth.htm)
Patch (https://sourceforge.net/tracker/index.php?func=detail&aid=1676882&group_id=173941&atid=867362) (against rev. 1167)



Really excellent Leak.

Yep, with the Yadif, adjusting the 'buffers ahead/back' did the trick. Real-time, on-the-fly, smart-bobbed (50p) playback of interlaced PAL DV in 'yer favourite' player (well mine anyway -TCMP). Cant be bad. IMHO, Yadif knocks spots (literally) off the existing FFDShow deinterlacers and DScaler plugins.

Still cant get it to work properly in the vfw FFDshow version though. Same-framerate (mode=0) output is OK, but bobbed (mode=1) output just gives me a black screen.

[zambelli]

Suggestions for Ffdshow installer defaults:

Components:
+ enable "Avisynth scripts serving"

Decoders:
- disable MP3
- disable MP1, MP2
+ enable FLAC

Speaker setup:
* choose "disable mixer" or add the "same as input" option

Misc:
+ enable "Show tray icon" and "Extended info" for all encoders/decoders


My reasoning for disabling default MPEG audio decoding support is that those codecs are already supported on Windows without Ffdshow and I don't think Ffdshow should ever be changing the default codec assignment unless the user specifically choses to do so. Ffdshow should augment the existing codec ecosystem but not change it. I think this is the "right" thing to do not for political reasons, but for legacy/compatibility reasons.

In the long run, I think some sort of intelligent codec detection system might be in order where the installer checks whether a decoder already exists for a given video or audio type and doesn't enable the equivalent ffdshow decoder by default. Example: When DivX or CoreAVC are already installed on a system, it might be safer to assume those are the preferred DivX/XviD and H.264 decoders. The users can always override them if they decide they prefer Ffdshow.

[Leak]

Really excellent Leak.
:D

Still cant get it to work in the vfw FFDshow version though. Before, VDub either crashed or froze at first frame. Now I'm just getting a black screen.
Can't say I can recommend using it with VfW, as the buffering isn't going to work at all due to the way VfW works - you can't refuse to give an output frame back when VfW hands you an input frame, or return more than one frame at a time, which is how buffering and inserting/removing frame works in DirectShow.

This means you can't really use filters that change the number of frames in the stream, like bobbers and decimation - pure spatial filtering without buffering should still work, although I haven't tested it lately. Just buffering ahead/back probably works as well, but the video will be delayed by a number of frames equal to the buffer ahead setting, and the same number of frames will be then missing at the end.

Then again, when using VfW for encoding it's better to use AviSynth directly anyway, if at all possible.

[WorBry]

:D
Can't say I can recommend using it with VfW, as the buffering isn't going to work at all due to the way VfW works - you can't refuse to give an output frame back when VfW hands you an input frame, or return more than one frame at a time, which is how buffering and inserting/removing frame works in DirectShow.

This means you can't really use filters that change the number of frames in the stream, like bobbers and decimation - pure spatial filtering without buffering should still work, although I haven't tested it lately. Just buffering ahead/back probably works as well, but the video will be delayed by a number of frames equal to the buffer ahead setting, and the same number of frames will be then missing at the end.

Then again, when using VfW for encoding it's better to use AviSynth directly anyway, if at all possible.

Note: I'd edited my comment about vfw i.e. sort of got it to work with 25p (mode=0) output, but not 50p (mode=1). Thanks for the explanation.

For vfw I do normally use AVIsynth directly; I was just intrigued by the query posted by thiseas:

http://forum.doom9.org/showthread.php?p=999056#post999056

i.e. the notion of being able to just drop a DV source into VDub, without loading it into a script.

[Leak]

For vfw I do normally use AVIsynth directly; I was just intrigued by the query posted by thiseas:

http://forum.doom9.org/showthread.php?p=999056#post999056

i.e. the notion of being able to just drop a DV source into VDub, without loading it into a script.
I'm afraid that also won't work because you'd need to double the number of frames VfW reports to the application if you don't want your video being cut in half, which also isn't possible.

It should work with applications that use DirectShow for either de- or encoding, though - too bad VirtualDub isn't one of those... :(

[WorBry]

Thanks again for the explanation :)

[haruhiko_yamagata]

@haruhiko_yamagata
Found an issue with the "allow multichannel audio processing" option. If you play a file with two audio streams (one 5.1 and other 2.0) and have the option disabled, when the 5.1 track is played no processing is made which is normal but when you change to the 2.0 track no audio processing occurs even though ffdshow is outputting audio properly. If you enable then disable the option during the 2.0 audio playback processing begins and continues as ffdshow is now aware of the type of audio track.
If you do the reverse it happens again: playing 2.0 audio with option disabled and sound processing ,switch to 5.1 audio and sound will processed with the option disabled which is not ok for stereo plugins.
This probably happens because i'm using haali media splitter which handles the streams, so ffdshow is not totally aware of the audio stream changes.Thank you for report.
Please provide a sample file.

P.S.=> Is it possible to add a function to load DirectX audio dsp's from within ffdshow like is done with the winamp plugins?I'm not sure, as for now, I don't have much time.

[_xxl]

Latest's (1167,1155) libavcodec mpeg4 encoder is crashing.
Rev 1148 is working ok.
Tested with Intel Dual Core SSSE3.
30867cb9: 660f7f4c2420 movdqa [esp+20h], xmm1 <-- FAULT
Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'libavcodec'...

...reading address FFFFFFFF...

...while compressing frame 0 from 0b3a0020 to 0b1a0020 using codec "ffdshow Video Codec" (VideoSequenceCompressor.cpp:618)...

...while running thread "Processing" (thread.cpp:150).

[Kado]

Thank you for report.
Please provide a sample file.

Sample here. (http://rapidshare.com/files/31445600/5.1_2.0_sample.mka.html)

I'm not sure, as for now, I don't have much time.
Wakarimashita!:)

[clsid]

Latest's (1167,1155) libavcodec mpeg4 encoder is crashing.
Rev 1148 is working ok.
Tested with Intel Dual Core SSSE3.
It works ok for me (on default settings) on an old Athlon (MMX/MMXext).

So it may be caused by the added SSE2/SSSE3 SIMD code of rev1155.

[haruhiko_yamagata]

Sample here. (http://rapidshare.com/files/31445600/5.1_2.0_sample.mka.html)

Thank you. I can reproduce the problem.

[_xxl]

Rev 1155 doesn't have SSSE3 enabled.
Maybe some custom code is missing?

[clsid]

Yes, but some SSE2 code was added/changed.

[_xxl]

"movdqa"
Doesn't depend on data alignment:
"movdqu"
(/arch:SSE2)
The compiler generated SSE code uses the MOVDQA instruction which requires the data to be aligned on a 16-byte boundary, but it is not safe to assume that the last element of an array of struct "data" is aligned on a 16-byte boundary due to its odd size, and executing the code aborts with an access violation at the first movdqa instruction.
Is this access violation due to movdqa on misaligned memory address?

[wozio]

I have noticed that when HW deinterlacing is checked then ffdshow sets video in connection media type as interlaced (AMINTERLACE_IsInterlaced flag always set in VIDEOINFOHEADER2) even when it is in fact progressive. I know that later every video frame is presented with progressive flag set but I don't think if it is correct. I checked coreavc and it sets interlaced flag only when video stream is truly interlaced.

In result VMR9 reports doubled output frame rate and achieved is half of that.

Is it possible to fix it? I want to predict output frame rate of the rendered video in my application and want to check it from connection media type, when ffdshow always sets interlaced flag I will end with incorrect result.

[zambelli]

I have noticed that when HW deinterlacing is checked then ffdshow sets video in connection media type as interlaced (AMINTERLACE_IsInterlaced flag always set in VIDEOINFOHEADER2) even when it is in fact progressive.
I think libavcodec libs need to be enabled to pass that info to the Dshow filter layer. Any codec that supports interlaced video (MPEG-2, H.264, VC-1, etc.) would need to pass that info out, ideally per every frame, but at the least once for the sequence.

[squid_80]

Is this access violation due to movdqa on misaligned memory address?
If you posted the full virtualdub crash log it would be pretty easy to tell. I doubt whether it's the fault of the compiler, they don't generate SSE2 code unless it's really safe. More than likely this is caused by some hand written assembly which is assuming the stack pointer to be 16-byte aligned - this is done by gcc but not MSVC.

[_xxl]

Vd 1.6.1 crashinfo:
http://rapidshare.com/files/31573240/crashinfo.txt.html

[haruhiko_yamagata]

I have noticed that when HW deinterlacing is checked then ffdshow sets video in connection media type as interlaced (AMINTERLACE_IsInterlaced flag always set in VIDEOINFOHEADER2) even when it is in fact progressive. I know that later every video frame is presented with progressive flag set but I don't think if it is correct. I checked coreavc and it sets interlaced flag only when video stream is truly interlaced.

In result VMR9 reports doubled output frame rate and achieved is half of that.

Is it possible to fix it? I want to predict output frame rate of the rendered video in my application and want to check it from connection media type, when ffdshow always sets interlaced flag I will end with incorrect result.
It's difficult. To set the flag properly, ffdshow has to decode a few frames or at least the "codec private".
In most cases, codec private should help, but it's not easy because I don't have the documentation about codec private.

[squid_80]

Vd 1.6.1 crashinfo:
http://rapidshare.com/files/31573240/crashinfo.txt.html
The assembly code causing the crash appears to be an fdct function, most likely it's the fdct_col_##cpu function found in ffmpeg/libavcodec/i386/fdct_mmx.c. You'd need to find where the function is being called from and make sure the int16_t array being passed as the 2nd parameter is declared as being 16-byte aligned.

[swordsman]

Thanks for great codec!!!!
I've found strange thing - for all versions after 1025
drawOSD function isn't working. At 1025 and below
all is Ok. Does that mean you changed header file or
it's simply broken?

[multiblitz]

Thank you. I'll look into it again.

That would be great actually. THX

[[Toff]]

I've just spent more than an hour trying to remotely diagnose some video file loading problems in one of my application to finally find the culprit here: ffdshow and its white list.
I was not aware of this "new" functionality, so I was starting to pull my hair seeing the video loading well in the good old mplayer2.exe and in graphedit.
The user was using a codec pack so he didn't even see any ffdshow configurations dialog.
IMHO the white list option should be disabled by default, and only the black list should be pre-filled with some application known to cause problems.
At the very least a warning window should popup telling what's going one and why it's not loading with an option to not show the warning again.

[jidelite]

Here's the aforementioned AviSynth patch update:

Download (http://leak.no-ip.org/AviSynth/ffdshow/ffdshow_AviSynth_rev1167_20070514.exe)
Documentation (http://leak.no-ip.org/AviSynth/ffdshow/docs/html/en/avisynth.htm)
Patch (https://sourceforge.net/tracker/index.php?func=detail&aid=1676882&group_id=173941&atid=867362) (against rev. 1167)

Changes:

* Reset AviSynth only after deactivating the filter or when the image size or the script changes - that's about as low as I can go when it comes to resetting AviSynth

* Added a help webpage for the filter (see link above)

* One additional pulldown option ("Smooth timestamps") to smooth out alternating timestamps without duplicating fields - this should make adding/dropping frames work on 24 FPS movie material, probably even on hybrid material, but the output frame rate will then vary proportional to the input frame rate


Leak, Finally got a chance to try your latest patch and I must say, this time you did it :)!! I no longer get any stuttering on DVDs when my frame duration changes. I cannot thank you enough for all your hard work!

:thanks:
jidelite

[haruhiko_yamagata]

;1004141']I've just spent more than an hour trying to remotely diagnose some video file loading problems in one of my application to finally find the culprit here: ffdshow and its white list.
I was not aware of this "new" functionality, so I was starting to pull my hair seeing the video loading well in the good old mplayer2.exe and in graphedit.
The user was using a codec pack so he didn't even see any ffdshow configurations dialog.
IMHO the white list option should be disabled by default, and only the black list should be pre-filled with some application known to cause problems.Codec packs may not show the installation dialog for the compatibility list. They should either show a dialog on installation or disable compatibility list.
At the very least a warning window should popup telling what's going one and why it's not loading with an option to not show the warning again.
Yes, it's a good idea.

[haruhiko_yamagata]

Decoders:
- disable MP3
- disable MP1, MP2

My reasoning for disabling default MPEG audio decoding support is that those codecs are already supported on Windows without Ffdshow and I don't think Ffdshow should ever be changing the default codec assignment unless the user specifically choses to do so. Ffdshow should augment the existing codec ecosystem but not change it. I think this is the "right" thing to do not for political reasons, but for legacy/compatibility reasons.

I agree. What other's opinion?
Speaker setup:
* choose "disable mixer" or add the "same as input" option
No.

[ExtraEye]

i like decoding mp3 with ffdshow. Isn't it better to decode it that way?

[fastplayer]

What other's opinion?
I agree about zambelli's MP1/2/3 and tray icon suggestions but I don't understand why the mixer should be disabled.

[vlada]

I don't agree with disabling MPEG-1 audio. For example with ffdshow I can use volume normalization. I also know many people who use ffdhsow to upmix stereo MP3 to 5.1. Or are there any problems with the ffdshow decoder why it should be disabled?

One of the strong points of ffdshow is the fact, that it usually takes over any other decoders installed in system. So it can very often fix problems caused by various codecpacks.

Edit: Maybe instead of it, we might want to create some easy to understand profiles during installation (with the option to choose details):

1) Enable only basic formats
2) Enable all fully supported formats (including VfW)
3) Enable everything

[zambelli]

i like decoding mp3 with ffdshow. Isn't it better to decode it that way?
My suggestion was more based on backwards compatibility and legacy support than on quality. I'm not sure how much quality gain there is in decoding MP3 with Ffdshow versus the default Fraunhofer decoder anyway.

I don't agree with disabling MPEG-1 audio. For example with ffdshow I can use volume normalization. I also know many people who use ffdhsow to upmix stereo MP3 to 5.1. Or are there any problems with the ffdshow decoder why it should be disabled?
We're talking about defaults here. There'd be nothing stopping users who want to upmix MP3 to select MP3 during install.

One of the strong points of ffdshow is the fact, that it usually takes over any other decoders installed in system. So it can very often fix problems caused by various codecpacks.
It shouldn't be Ffdshow's role to solve problems introduced by bad codec packs. That'd be like sweeping the problem under the rug anyway.

My approach for installing Ffdshow has always been to let it handle only codecs which aren't already handled by other codecs on the system - unless there's a very good reason to do so. I think the installer's goal should be to fill the gaps in codec coverage, not try to patch existing codecs. Idealy there'd be a detection method in the installer that checks for present codecs - but at the least, I think Ffdshow should not replace decoders that are known to exist on every Windows OS (MP2/MP3, MPEG-1, WMA, WMV, etc.).

[vlada]

@zambelli> But AFAIK currently ffdshow works right the opposite way. It has very high merit a replaces all existing filters (why everybody calls them codecs?). I think your request would be much better fulfilled if you just decreased ffdshow's merit and enabled all formats. Then ffdshow would be used only if there are no other filters installed.

My target is always to let ffdshow handle as much formats (why everybody calls them codecs?) as it can, because I want to use the same postprocessing filters for all formats (subtitles, volume normalization, downmix). I know I could just use ffdhow as RAW filter, but why not letting it do the decoding part too. I'm afraid we'll probably won't find a common attitude on this matter.

That's why I suggest to prepare some presets so users can choose what they want. Informed people like you and me have no problems to select whatever they want. So I think we shouldn't care about what we need, but what setting will be the best for a common user. And unfortunately many users have their system damaged by different codecpacks. I already saved many people by telling them just to install ffdshow with default setting, if they had video playback problems and hoped to solve it by installing more and more codecpacks :devil: I agree it's sweeping the problem under the rug, but have you ever tried to explain to a common user how to work with Graphedit, identify problematic filters and disable them?

The way ffdshow works now gains a lot of success because it solves many video playback issues people have. But I think it's up to the developers to decide which way they want to go. There are 2 extremes: Associate everything to ffdshow (my wish) or associate only formats not yet supported on the system (your wish). Maybe something between would be the right choice.

[squid_80]

but at the least, I think Ffdshow should not replace decoders that are known to exist on every Windows OS (MP2/MP3, MPEG-1, WMA, WMV, etc.).
Windows x64 doesn't have a 64-bit mp3 codec, and I've never known any windows to come with an acm mp2 codec.

[haruhiko_yamagata]

@Leak
Thank you for your great work. It is getting more stable and I can report only one this meaningless issue.
FadeIn(30)
With this script and your latest build, when I seek, fade in occurs every time. Without your patch, fade in occurs only on start up (after stop). Which is normal?

Well, my sample is meaningless test. But compatible behavior with original ffdshow is more likable for the case that buffering is not necessary.

Here, I have a feature request.
Please add a new check box "Enable buffering", off by default. Buffers back/ahead can be set 10/10 or something by default.

With the check box off, "Buffers back/ahead", "Use Current", "3:2 Pulldown" is grayed out. The behavior can be as compatible as possible unless the original one is too buggy.

It's good for not only compatibility but also user's convenience.

[Leak]

@Leak
Thank you for your great work. It is getting more stable and I can report only one this meaningless issue.
Thanks! :)

FadeIn(30)
With this script and your latest build, when I seek, fade in occurs every time. Without your patch, fade in occurs only on start up (after stop). Which is normal?
There's a problem with FadeIn, because it makes the output clip one frame longer than the input clip.

Since every time my filter skips ahead it adds 1000 to the frame number and rounds it up according to the input/output frame ratio - this works fine if the ratio is 5:4 with IVTC, or 1:2 with bobbing, but with a ratio of 10810800:10810801 the value to round to gets waaay too big and thus the current frame number is reset to 0.

If you use FadeIn0, which doesn't add an extra frame at the very end of the clip (which you probably won't ever reach anyway), you won't get that problem, but you won't get the fade either (unless it's several thousand frames long), since all the resizing/re-connecting/re-you-name-it at the beginning of playback will make the filter seek ahead several thousand frames.

I'm afraid there's not much I can do... if I don't seek ahead, you'll be getting green/double/wrong frames again, and if I go back to reseting AviSynth, people will complain about seeking/starting being slow, and the FadeIn is going to happen after every seek.

Then again, using FadeIn doesn't make much sense, and FadeOut won't work anyway - it's best to only use filters in ffdshow that will do their magic on all frames of the video, and not just some fixed range of a clip that is a moving target.

It does work when buffering is turned off, though, as seeking ahead only seeks ahead one frame then.

Well, my sample is meaningless test. But compatible behavior with original ffdshow is more likable for the case that buffering is not necessary.
It already is compatible in that regard when you use FadeIn0 - I guess I can just disable the rounding part as well when buffering is off since it doesn't really make much sense then, as the only adding and removing of frames that will work reliably then is either multiplying or dividing the input number of frames by an integer, i.e. halving or doubling the number of frames.

I was planning to add some code to figure out a "better" ratio if it's just off by a few frames (in a range of, say, -15 to +15 frames, by just trying them out), as any difference of a few frames with a clip that's 10 million frames long can be compensated by buffering an extra frame or two ahead at most.

Here, I have a feature request.
Please add a new check box "Enable buffering", off by default. Buffers back/ahead can be set 10/10 or something by default.

With the check box off, "Buffers back/ahead", "Use Current", "3:2 Pulldown" is grayed out. The behavior can be as compatible as possible unless the original one is too buggy.

It's good for not only compatibility but also user's convenience.
Sure, why not? :)

Would a checkbox before "Buffers back/ahead" be sufficient? I really don't want tear the dialog design apart another time, which would be neccessary to fit another checkbox with label.

I won't disable the pulldown options though, as they're independent from buffering - only "Apply pulldown" adds frames, and that's just using the current and the previous frame, so there's no lag introduced either since it doesn't buffer ahead.

The pulldown part would even make sense as a filter on it's own - if you've got a TV connected to the PC you can make sure it gets it's 30 interlaced frames per second that way instead of leaving that up to the renderer. And smoothing the timestamps just averages the frame duration to get the oscillating between two frame lenghts out, but won't do anything else.

I've also found that leaving the script empty produces no image at all; most probably because an empty script in the config is used to signal the filter to reset itself - that should probably be fixed... :)

Also, it would probably be nice to change the FPS value in the output video headers as well instead of just mangling the timestamps - do you perhaps know where that information is stored?

[haruhiko_yamagata]

There's a problem with FadeIn, because it makes the output clip one frame longer than the input clip. Thank you for explanation.
Sure, why not? :):thanks:
Also, it would probably be nice to change the FPS value in the output video headers as well instead of just mangling the timestamps - do you perhaps know where that information is stored?
It's in VIDEOINFOHEADER / VIDEOINFOHEADER2. They are used on connection. It should be hard to calculate the value before decoding begins. I think it's better to leave it as it is.