ffdshow tryouts project: Discussion & Development [Archive] - Page 24

Leak

3rd May 2007, 08:40

btw, this is what shows in the debug console when it happens:
[2948] TimgFilterAvisynth: onFlush
[2948] TffdshowDecVideoOutputPin:: DeliverBeginFlush
[2948] TffdshowDecVideoOutputPin:: DeliverEndFlush
[2948] TimgFilterAvisynth: (Re-)Initializing buffers
Ugh. The other splitters I know only do a BeginFlush when you seek in the DVD navigator; that's sadly about the only way to detect that there is some seeking going on at that point in a DVD graph.

So what I do is drop all buffered frames, then start buffering again - processing and delivering the frames that had been buffered before the seek will just make things look funny and take longer.

I guess I'll have to try using Haali's splitter when I get home, but I'm not sure what I should do about this - if I ignore the DirectShow flushes navigating the DVD will get laggy.

EDIT: But I still can't figure out why it would stutter with the settings you had to have set, namely no Apply pulldown and no buffering - after all, in that case it just passes through the current frame, with no pre-buffering or anything else that would take any noticeable time (and nothing to drop, either), and as you can see the timestamps are consecutive as well... :confused:

EDIT2: The timestamps on the DebugView log entries would have been interesting... those would show where the exact pause happened.

chros

3rd May 2007, 09:30

@haruhiko_yamagata: I don't want to hurry you, but when will be merged the DFX multichannel patch?

Thank you for your effort ...

jidelite

3rd May 2007, 14:34

Thanks. :)

Hmmm... could you try the following?

* Download DebugView from Microsoft (http://www.microsoft.com/technet/sysinternals/Miscellaneous/DebugView.mspx)

* Run DebugView, go to "Edit > Filter/Highlight..." and enter "TimgFilterAvisynth:" (sans quotes) in the "Include:" box, then hit OK and probably minimize it so it won't take much extra time scrolling the output across the screen

* Add "#debug" as the very first line of your AviSynth script

* Open your media player, play the material you're having problems with until you get past one of those stutters or two

* Save the output of DebugView to a file and mail it to leak (at) gmx (dot) at

That should give us some clues as to what's happening. ...

When I get home I will certainly try and debug this on my PC. I will try to do this on an unpatched version as well.

What happens if you strip down your script to where it doesn't use as much CPU? Could you perhaps try that?

When I strip down my script to where my OSD says I'm using about 15-20% cpu (and buffering is disabled), the pause time is definitely reduced but the OSD does show something being reset. I don't know if this makes a difference but I'm also using the mult-thread version of the avisynth.dll from tsp's MT package.

Okay, so I don't have that player and really don't want to buy it, so could you perhaps try this in Media Player Classic (http://forum.doom9.org/showthread.php?p=975082#post975082) as well? And, in case you're using the nVidia MPEG decoder that seems to come with TheaterTek, could you please use ffdshow's MPEG2 decoder instead?

I can't blame anyone for not wanting to purchase a particular player :) so I will try to use MPC and I'll try to see if I can build a graph to use ffdshow's MPEG2 decoder instead...

Thanks,
jidelite

Leak

3rd May 2007, 14:48

I will try to do this on an unpatched version as well.
That won't do much, as none of the debug output I'm looking for is printed by the unpatched version...

But if what foxyshadis wrote above is the same that happens to you then I'm not sure how to fix it - after all, the splitter in that case asks ffdshow to flush everything it has queued, and I happily oblige...

foxyshadis

3rd May 2007, 16:24

EDIT: But I still can't figure out why it would stutter with the settings you had to have set, namely no Apply pulldown and no buffering - after all, in that case it just passes through the current frame, with no pre-buffering or anything else that would take any noticeable time (and nothing to drop, either), and as you can see the timestamps are consecutive as well... :confused:

EDIT2: The timestamps on the DebugView log entries would have been interesting... those would show where the exact pause happened.

The stutter is just the scriptenvironment re-initializing itself, changing settings always causes the same lag for me; the luts for seesaw take a bit to fill, and I bet jidelite's complex script is using quite a few of them with several instances of something like MT+LSF (where each filter has to be initialized in each thread) so it's worse.

I wish debugview copied timestamps, but they were at 4.4s and 23s from the start, which didn't correspond to the video time. The first was at frame 43; it's dark but noticeable. I ran dgindex over it but since I don't deal with mpeg-2 much, I don't know what to look for to detect errors.

I'm also not sure what can be done about it. Set up some kind of conditions to just ignore it? I don't know.

Leak

3rd May 2007, 16:57

The stutter is just the scriptenvironment re-initializing itself, changing settings always causes the same lag for me; the luts for seesaw take a bit to fill, and I bet jidelite's complex script is using quite a few of them with several instances of something like MT+LSF (where each filter has to be initialized in each thread) so it's worse.
Ah, but it shouldn't be doing that, and it most probably isn't, unless you get two messages about "(Re-)Starting playback" and "Freeing buffers". In all other cases (unless buffering is totally disabled), I only seek forward 1000 or so frames in the script (to make sure AviSynth doesn't re-use cached stuff), which shouldn't have that much of an impact.

The stutter with buffering turned on is most probably coming from decoding and buffering 12 frames (in TIVTC's case) before playback resumes, but of course that shouldn't (can't?) happen when it's turned off...

I gotta try to reproduce this with Haali's splitter, but first I need to test that RMAed 17" piece of monitor next to me... :D

np: Burnt Friedman - Fucking Long Time (Plays Love Songs)

Fizick

3rd May 2007, 18:55

Leak, correction of doc (last phrase):

Replace:

...disable "Apply pulldown" to get the old behaviour of earlier AviSynth versions back...

By:

...disable "Apply pulldown" to get the old behaviour of earlier FFDSHOW versions back...

Leak

3rd May 2007, 21:08

Leak, correction of doc (last phrase)
Errr... oops. :thanks:

Soulhunter

3rd May 2007, 22:48

Hey, just want to thank you all for continuing FFDShow development! :]

Thanks 'n Bye

4th May 2007, 01:20

x264 is an encoder.Use virtualdub and see if 1126 is faster.ffdshow.ax compiled by MinGW GCC can't detect (S)SSE3.Please use MSVC builds.
Ok, I'll test it on sunday.....

foxyshadis

4th May 2007, 01:37

Okay, not quite so confused anymore. The faulty splitter I was using was v1.000 of gabest's, from mid-2004, whereas the current and built-in are 1.003, where the sync problem is fixed. Not sure why MS DVD Nav. only trips over it occasionally, instead of always, but it is in the same spots.

Don't use Haali's, btw, wait a few more versions. The MPEG-PS code isn't working very well right now, in fact it works better on .evo than .vob.

jidelite

4th May 2007, 03:09

haruhiko_yamagata

4th May 2007, 03:34

@haruhiko_yamagata: I don't want to hurry you, but when will be merged the DFX multichannel patch?

Thank you for your effort ...
I have been building a new PC and developing environment. Now it's mostly done, please wait a bit more.

Leak

4th May 2007, 08:17

Ok. DebugView file are on their way. Still working on MPC and trying to use ffdshow's MPEG2 decoder in TheaterTek.

foxyshadis, :thanks: for looking into this as well...
Well, looking at your log files I can see that the DirectShow graph was stopped and restarted several times; if it wasn't you hitting "Stop" and "Play" repeatedly then I'm afraid it was your player software causing those stutters, since I'm re-initializing the AviSynth script after a full stop.

Why it would stop the DirectShow graph during playback is really beyond me, though... :confused:

zambelli

4th May 2007, 09:38

Have the YV12 raw decoding issues been addressed in recent builds? The Beta2 still has issues handling YV12 video and rendering it to VMR7/9 in both DShow and VfW.

chros

4th May 2007, 10:56

I have been building a new PC and developing environment. Now it's mostly done, please wait a bit more.
Thank you very much!

jidelite

4th May 2007, 12:55

Well, looking at your log files I can see that the DirectShow graph was stopped and restarted several times; if it wasn't you hitting "Stop" and "Play" repeatedly then I'm afraid it was your player software causing those stutters, since I'm re-initializing the AviSynth script after a full stop.

Why it would stop the DirectShow graph during playback is really beyond me, though... :confused:

Hmmm... Sounds like I'm back to square 1 :( since I didn't hit stop or play during playback. I'm sure you see from the logs that I always have a problem when the frame duration changes from 41 ms to 33 ms - even when buffering is off so my script is not behaving like unpatched versions of ffdshow on my PC. As you pointed out, TheaterTek uses the nvidia decoder so I will see if I can get MPC to use the same decoder when I get a chance to play with it this weekend.

Thanks,
jidelite

Leak

4th May 2007, 13:15

Hmmm... Sounds like I'm back to square 1 :( since I didn't hit stop or play during playback. I'm sure you see from the logs that I always have a problem when the frame duration changes from 41 ms to 33 ms - even when buffering is off so my script is not behaving like unpatched versions of ffdshow on my PC.
Okay, so looking at the old code again shows that ffdshow didn't do anything special when the graph was stopped (it only reinitialized AviSynth when the frame size changed), but this really isn't an option anymore, since I have to get rid of the buffered frames somehow... playing the last few frames buffered when the stop came when it gets restarted again is simply wrong.

I could make AviSynth seek forward instead of totally resetting it, but I rather like the idea of getting everything back into a working state by hitting "Stop", followed by "Play".

I could add that as an option, though... "Reset on stop" or something. But still, it's idiotic for the graph to be stopped then restarted in the middle of playback if the user did not do anything...

jidelite

4th May 2007, 15:00

Okay, so looking at the old code again shows that ffdshow didn't do anything special when the graph was stopped (it only reinitialized AviSynth when the frame size changed), but this really isn't an option anymore, since I have to get rid of the buffered frames somehow... playing the last few frames buffered when the stop came when it gets restarted again is simply wrong.

I could make AviSynth seek forward instead of totally resetting it, but I rather like the idea of getting everything back into a working state by hitting "Stop", followed by "Play".

I could add that as an option, though... "Reset on stop" or something. But still, it's idiotic for the graph to be stopped then restarted in the middle of playback if the user did not do anything...

Forgive me if this sounds far-fetched & simplistic since I'm not a ffdshow coder (believe me, I have great respect for you guys that maintain this code) but as a compromise if I set the parms to disable buffering, can you disgard the initial buffers the way you normally do and then not buffer anymore (just reinitialized AviSynth like the old code) since you now know its turned off?

jidelite

Leak

4th May 2007, 15:54

Forgive me if this sounds far-fetched & simplistic since I'm not a ffdshow coder (believe me, I have great respect for you guys that maintain this code) but as a compromise if I set the parms to disable buffering, can you disgard the initial buffers the way you normally do and then not buffer anymore (just reinitialized AviSynth like the old code) since you now know its turned off?
I think you meant "if buffering is turned off, could you skip resetting AviSynth like it was done previously", right?

Sure, why not? But I guess I'll just skip the total reset on stop anyway, and simply skip ahead to lose the buffered frames like I do when the DirectShow graph is flushed - after all, a fix that only works if you cripple the filter (by turning off buffering) isn't much of a fix.

You'll just have to edit the AviSynth script to totally reset AviSynth, then, or toggle the filter off and on via the tray menu or a hotkey...

clsid

4th May 2007, 18:04

Have the YV12 raw decoding issues been addressed in recent builds? The Beta2 still has issues handling YV12 video and rendering it to VMR7/9 in both DShow and VfW.I haven't seen a fix for that mentioned in the SVN logs. So I think they are still present.

Kado

4th May 2007, 18:34

Revision 1130
Winamp plugin: multichannel processing
A new check box "Allow multichannel audio processing" can be configured for every plugins.

Great haruhiko! Now just have to wait for another nightly build by drevil_xxl or clsid to test it. :thanks:

zambelli

4th May 2007, 21:26

I haven't seen a fix for that mentioned in the SVN logs. So I think they are still present.
I'm surprised that bug is not a higher priority, given that Ffdshow is commonly used as the codec for handling YV12 video.

clsid

4th May 2007, 22:58

How to reproduce the YV12 bugs?

I tried forcing YV12 output in the Xvid decoder. However ffdshow (placed after Xvid in graph) reports the input as IYUV.

jidelite

5th May 2007, 03:01

I think you meant "if buffering is turned off, could you skip resetting AviSynth like it was done previously", right?

Sure, why not? But I guess I'll just skip the total reset on stop anyway, and simply skip ahead to lose the buffered frames like I do when the DirectShow graph is flushed - after all, a fix that only works if you cripple the filter (by turning off buffering) isn't much of a fix.

You'll just have to edit the AviSynth script to totally reset AviSynth, then, or toggle the filter off and on via the tray menu or a hotkey...

Leak, Got around to configuring MPC to play my Video Essentials clip. All things being equal (& buffering off), I ran the clip through the internal MPEG-2 Decoder and then the Nvidia Video decoder that came with TheaterTek (nvviddec.ax: 4020.223.0.0). Interesting thing is the internal MPEG-2 Decoder played the clip perfect while the Nvidia Decoder paused/stuttered on the frame duration change as always. Taking a snapshot from the DebugView log of the same clip played by MPC, the decoders produced the attached output.

For sure, the frame durations from the decoders are handled differently. To be fare, the pause/stuttering from the Nvidia decoder hasn't happen a whole lot during my regular viewing of movies so far (I think I counted 2) but who knows how many other DVDs are out there where the decoder screws up on a frame duration change with your patch. I still wish others could confirm what I see since I know there are alot of Nvidia video decoder users out there :confused: ...

jidelite

foxyshadis

5th May 2007, 03:24

I'm beginning to wonder if these segments are concatenated together from separate encodes with wildly different timestamps, which I hear happens quite a bit when people copy /b the encodes. It's concievable that the studio did it in segments. Too bad I don't have any of neuron2's tools. Well, that's not quite true, I might have something.

The solution might be to simply keep a blacklist of filters that cause spectacular failures in avisynth.

zambelli

5th May 2007, 04:55

How to reproduce the YV12 bugs?
I tried forcing YV12 output in the Xvid decoder. However ffdshow (placed after Xvid in graph) reports the input as IYUV.
Check out:
http://forum.doom9.org/showthread.php?p=970974#post970974
http://forum.doom9.org/showthread.php?p=973655#post973655

A simple Avisynth script can be used to repro:
ColorBars(320, 240, "YV12")

Disable all raw video codec handling in Video Decoder Configuration.
Enable "All YUV" raw video codec handling in VfW configuration.

Drop the test .avs script into GraphEdit. Render with the default VMR7. Check the renderer input pin properties for input format. Stop the graph, remove the video renderer and replace it with VMR9. Render the video again and check the VMR input pin properties again.

Now enable "All YUV" raw video handling in the Dshow Video Decoder Configuration and repeat the same repro steps.

Getting the decoder to render YV12 doesn't seem to work, and there seem to be some mirroring issues with the VfW component.

WorBry

5th May 2007, 10:00

Fizicks AVISynth port of the MPlayer deinterlace filter, Yadif, is creating quite a buzz.

http://forum.doom9.org/showthread.php?p=999472#post999472

Any chance of incorporating it in the FFDShow decoder deinterlace options, ideally with an option for double-rate (bobbed) output?

Leak

5th May 2007, 11:17

The solution might be to simply keep a blacklist of filters that cause spectacular failures in avisynth.
Nah... like I said, I'll just skip resetting AviSynth on a stop and just make it flush all buffers like I do on a seek or flush. That'll still cause some jerkiness and/or dropped frames (and that's why I'll recommend using ffdshow for MPEG2 decoding), but it won't be that much of a pause.

If you really need to reset AviSynth for some reason (which should be rather seldom), just define a hotkey for enabling/disabling the AviSynth filter and hit it twice in a row, or change the script.

I'm afraid I probably won't be able to work on it before tomorrow, though.

Also, the pulldown handling really needs 3 options, like in DGIndex: "Honor flags" (like it does now when it's checked, to get out 30 FPS material), "Force film" (which is missing currently, to get out 24 FPS material with correct timestamps) and "Ignore flags" (like it does now when it's unchecked).

Without that "force film" option, you can't really use filters that add or remove frames (like a bobber) on almost-correctly flagged progressive material which you don't want to IVTC yourself. Shouldn't be hard to add, though - I just need to correct the timestamps a bit so they don't alternate between 33 and 50 ms.

np: Pole - Strand (3)

haruhiko_yamagata

5th May 2007, 15:02

Check out:
http://forum.doom9.org/showthread.php?p=970974#post970974
http://forum.doom9.org/showthread.php?p=973655#post973655

A simple Avisynth script can be used to repro:
ColorBars(320, 240, "YV12")

Disable all raw video codec handling in Video Decoder Configuration.
Enable "All YUV" raw video codec handling in VfW configuration.

Drop the test .avs script into GraphEdit. Render with the default VMR7. Check the renderer input pin properties for input format. Stop the graph, remove the video renderer and replace it with VMR9. Render the video again and check the VMR input pin properties again.

Now enable "All YUV" raw video handling in the Dshow Video Decoder Configuration and repeat the same repro steps.

Getting the decoder to render YV12 doesn't seem to work, and there seem to be some mirroring issues with the VfW component.
Now I'm looking this issue. I can reproduce the flip issue.
As for YV12->YUY2 conversion, when ffdshow is wrapped by AviDecompresser (i.e. vfw codecs are used in a DirectShow filter graph), it appears that AviDecompresser doesn't want YV12 output. Do you have any vfw codecs that output YV12 from AviDecompresser's output pin? If nobody have such codecs, it's not a ffdshow's bug.

diizzy

5th May 2007, 18:45

@ clsid
In your installer (Inno Setup) you have two versions of ffdshow.ax and ff_wmv9.dll, what's the difference between ffdshow,1.ax and ffdshow,2.ax and which one is which?
//Danne

fastplayer

5th May 2007, 19:24

...what's the difference between ffdshow,1.ax and ffdshow,2.ax and which one is which?
ffdshow,1.ax is the ANSI, ffdshow,2.ax the Unicode version.

5th May 2007, 21:30

Quick test
[AKROSS]_Tayo_-_Pale_Sun.avi (DivX 5.2.1, 640 x 360, 1715 kbps -> H264, 640 x 360, 1000 kbps), 3:18
ffdshow_rev1125_20070428_clsid
3:20
ffdshow_rev1126_20070430_xxl_msvc2005
3:19
Doom.720p.avi (DivX 6.0.0, 1280 x 720, 4027 kbps -> H264, 1280 x 720, 2000 kbps), 1:15
ffdshow_rev1125_20070428_clsid
2:48
ffdshow_rev1126_20070430_xxl_msvc2003
2:46
ffdshow_rev1126_20070430_xxl_msvc2005
2:46

Maybe on more longer videos will be more difference between builds, but I don't have time to test it now....

thuan

6th May 2007, 10:03

Find something interesting with two xxl's builds. Tested on the same file Chevalier ep2 HD subbed by Shinsen-subs with timecodec running through the OP part as it's the most CPU stressing part. I have those results:

build 1122
user: 70s kernel: 0s total: 70s real: 71s fps: 30.6 dfps: 30.2

build 1136
user: 75s kernel: 0s total: 75s real: 76s fps: 28.7 dfps: 28.3

Seems to be because of different gcc versions used to compiled ffdshow. Not much different but I noticed with 1136 a scene where ffdshow has to skip inloop filter, with 1122 everything goes smoothly.

multiblitz

6th May 2007, 13:09

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

haruhiko_yamagata

6th May 2007, 14:08

multiblitz

6th May 2007, 17:38

haruhiko_yamagata, it would be wonderful if you could have a look into it . I am happy to upload a trailer, if anyone can tell me where and how to upload.

Otherwise you can download two trailers with emule:

ed2k://|file|[Trailer]%20The%20chronicles%20of%20Riddick%20[HD-DVD][VC1+DDPlus].EVO|178018304|E062E84C619E9206F89EC742A6852084|/

ed2k://|file|[Trailer]%20Serenity%20[HD-DVD].EVO|137259008|5D8EB063EE02AAB60D007CDEF4B6ECC1|/

I am really thankful, if you could have a look into the issues as you only would need ffdshow for the best HD-DVD-playback possible (and yes, I own all my disks myself, this one here is about improving pq).

wozio

6th May 2007, 17:50

Not yet, partly because I don't have a sample VC1 in EVO. Could you upload a sample?
I started to load to megaupload.com but it will take some time.

BTW in mkv with latest haali splitter behaviour is the same, correct frame rate with ms decoder and wrong with ffdshow (even when wmv9 decoders are used inside).

Dr Pizza

6th May 2007, 20:34

OK, I've synced with the trunk again and will try to put up a new build/patch some time in the next week.

I'm beginning to take a look at the various "64-bit compatibility warnings" that VC++8 provides; they're generally pretty helpful, and there's quite a lot of them, and at least some of them should definitely be fixed (to avoid potential pointer truncations and similar). I'm going to start going through and doing that; I think mostly it's going to be a question of using different typedefs (e.g. DWORD_PTR instead of DWORD) and so the code should be clean on both 32-bit and 64-bit builds.

However, I'd like to check that what I'm seeing is accurate; it looks like the mini lzo library used by ffdshow for its settings is not using Win64 types properly. The library itself does know how to build for Win64 properly, but it doesn't seem to be doing so. For Win64 LZO_ABI_LLP64 should be set, but it apparently isn't.

Another thing, there are some bits of code that are depending on __WIN32__. __WIN32__ is not set for Win64, but at least some of the code I've seen should be included for any Windows build, not just 32-bit (though maybe it's only used for gcc builds, in which case it doesn't matter, as I'm not doing 64-bit builds with gcc). I think they should be checking for (maybe) _WIN32 (which VC++, at least, always defines, even for 64-bit builds), or perhaps there should be three symbols; Win32, Win64, and "Windows".

multiblitz

6th May 2007, 23:16

Ok, I uploaded a trailer in EVO:

http://www.megaupload.com/?d=8EGB8DWJ

_xxl

7th May 2007, 10:38

@Pizza
Can you do separate patches for all fixes?
x64 patch:
http://rapidshare.com/files/29983702/x64.patch.html
ftp://mplayerhq.hu/MPlayer/samples/evob/
VC1 and H.264 evobs.

clsid

7th May 2007, 11:49

Split the "Info & Debug" page into three pages:

- "DirectShow control", containing the Merit/Instances/Blacklist/Whitelist stuff. Located below "Codecs".
- "Video Details" / "Audio Details", containing the stuff from Info. Located above "OSD".
- "SIMD Debug", containing the SIMD stuff. Located above "About".

fastplayer

7th May 2007, 12:12

While we're at GUI suggestions, what do you think about removing the horizontal line and that grey border around the drop-down menu?

http://img185.imageshack.us/img185/4564/ffdshownv7.png

Maybe something like this (with removed group box):

http://img295.imageshack.us/img295/6886/ffdshowto3.png

haruhiko_yamagata

7th May 2007, 14:18

Ok, I uploaded a trailer in EVO:

http://www.megaupload.com/?d=8EGB8DWJ
Thank you. AV sync broken. Confirmed.

chros

8th May 2007, 20:54

Originally Posted by h_yamagata
Revision 1130
Winamp plugin: multichannel processing
A new check box "Allow multichannel audio processing" can be configured for every plugins.
"multichannel support per plugin": it's perfect!!! Thank you!
I have tried ffdshow_rev1133_20070504_clsid.exe, and it works perfectly.
(haruhiko: if you want you can make contact with the DFX guys, I think they would make your name out of gold :) if they knew that DFX is fully working in the directshow players through ffdshow, since they try to create so many plugin for so many players (WMP, Real, etc.))

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) ?

Terka

9th May 2007, 13:48

is it possible to apply MoComp2 via avisynth?

foxyshadis

9th May 2007, 14:55

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.

Terka

9th May 2007, 15:36

i cant see MoComp2 in ffdshow?

chipzoller

9th May 2007, 15:41

foxyshadis, can you give a hint as to where you create the preset? I assume you create a preset in the vfw config screen rather than the decoder? I'd like to try this out myself and compare it...

LoRd_MuldeR

9th May 2007, 21:43

i cant see MoComp2 in ffdshow?

You need the Plugins from DScaler ;)

Go the ffdshow configuration, then to "Tray, dialog & paths" and then set DScaler folder.
You will then see the "DScaler: Video (MoComp2)" filter on the list of Deinterlace filters.

DScaler download can be found here:
http://deinterlace.sourceforge.net/downloads.htm