FFVDUB Deinterlace filters stopped working

[Corpsy]

A couple weeks ago I began investigating various techniques for deinterlacing the video from my DV camcorder. After doing a bit of research I came upon FFVDUB, installed it, tried the deinterlace filters and really liked the results I was able to get using TomsMoComp.

A few days later, I tried using the technique on another clip from the camcorder and found that it wasn't working. The preview screen and the output screen looked the same as the input, and saving the video output provided an obviously still-interlaced video. In fact, all of the deinterlace options in FFVDUB ceased to work. However, it seems all the other filters in FFVDUB, like Levels, Blur, Sharpen, etc., all still work just fine.

Here's what I've tried so far to fix this:

1. Delete the VDF file from the plugins directory of both VirtualDub and VirtualDubMod and replacing them with the original file (FFVDUB behaves the same in both programs).

2. Installing a newer version of Virtualdub and installing the original VDF.

3. Uninstalling FFDSHOW and reinstalling it.

None of those changed anything. So, I'm hoping someone here can clue me in onto what is going wrong here, or perhaps suggest another solution that would be as simple using VirtualDub or Avidemux.

Thanks

[lordadmira]

I have the same problem sort of. I isntall rev 3466 and all the filters stopped working. I went back to my old rev 2546 and it started working again. Trying to find out what the problem is now.


LA

[LoRd_MuldeR]

Seems to work for me:
http://img44.imageshack.us/img44/7313/ffvdubworks.jpg

Test with ffdshow/ffvdub r3472 (http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/ffdshow-tryouts-project-svn-3472-x86-x64.html) (ICL11 build) and VirtualDub v1.9.8.

[lordadmira]

I've since discovered that it's the postprocessing section that doesn't work at all. VirtualDub Mod 1.5.10.2.


LA

[LoRd_MuldeR]

I've since discovered that it's the postprocessing section that doesn't work at all. VirtualDub Mod 1.5.10.2.


LA

Try an up-to-date VirtualDub, not an old and outdated fork that wasn't updated for years...

[lordadmira]

I did try a normal VirtualDub 1.9 and it doesn't work there either.


LA

[LoRd_MuldeR]

I did try a normal VirtualDub 1.9 and it doesn't work there either.

Time to file a bug report:
http://sourceforge.net/tracker/?group_id=173941&atid=867360

[foxyshadis]

ffdshow has always intentionally disabled the postprocessing in vfw import. It probably should have been removed. However the deinterlacing should work fine, though I've never used ffvdub (instead, I use the vfw decoding control panel, which filters the video before vdub touches it), so I can't help much there.

[LoRd_MuldeR]

ffdshow has always intentionally disabled the postprocessing in vfw import. It probably should have been removed. However the deinterlacing should work fine, though I've never used ffvdub (instead, I use the vfw decoding control panel, which filters the video before vdub touches it), so I can't help much there.

Ah, didn't know that. I usually don't post-processing. But indeed it makes sense to disable the post-processing in the "ffvdub" filter, because at this point information about the original compressed video is lost and thus only "blind" post-processing would be possible (i.e. smooth each block with the same strength), while post-processing can be adaptive (i.e. smooth blocks depending on their individual quantizer) when done directly in the decoding step.

@lordadmira
Goto Start -> Programs -> ffdshow -> VFW configuration. Then setup "post-processing" on the Decoder tab.
Also make sure VirtualDub uses ffdshow/ffvfw for decoding your source clip...

[lordadmira]

ffdshow has always intentionally disabled the postprocessing in vfw import. It probably should have been removed. However the deinterlacing should work fine, though I've never used ffvdub (instead, I use the vfw decoding control panel, which filters the video before vdub touches it), so I can't help much there.
Why???? It works perfectly fine in the old build tree I have so why disable it in tryouts?

And regardless, *that should be documented*.


LA

[LoRd_MuldeR]

Why???? It works perfectly fine in the old build tree I have so why disable it in tryouts?

For the reasons that have already been explained: Using post-proessing (i.e. deblocking) filters as part of the decoding process has the advantage that the deblocker can work adaptively. It can control the deblocking strength per block, depending on each block's quantizer. But if you use the deblocker as a "blind" post-processing filter, which would be the case in ffvdub, this kind of adaptivity isn't possible. Hence you'd smooth each block equally, no matter if a block needs deblcoking or not. Therefore it makes sense to have post-processing enabled in ffdshow and in the ffvfw decoder, but not in the ffvdub filter...

[lordadmira]

That decision should be left to the user. In my application I'm perfectly fine with the blind approach as I'm sure countless people are. Just document it in the dialog and readme.

It's not always possible to do the pp in the decoding stage. In VirtualDubMod when u load up an mpeg2 file, u don't have access to that stage. U don't have access to it in numerous other scenarios as well. U can only have access to it if ffdshow is doing the decoding via VFW.

The ffdshow pp works better than any other pp filter I have available. I really can't comprehend why u don't let the user make an informed decision about using it. How about re-enabling it?


LA

[LoRd_MuldeR]

That decision should be left to the user. In my application I'm perfectly fine with the blind approach as I'm sure countless people are. Just document it in the dialog and readme.

The problem is: Most users don't have a clue what they are doing. And they don't read 'readme' files :rolleyes:

Also most of the newer video formats, such as H.264, WMV9/VC1 and VP8/WebM, have their own "built-in" deblocking feature.
For those formats one should never use an additional post-progressing filter.
But again it's impossible to detect this case in ffvdub, as the source video format is unknown at this point of the processing chain.
And of course the average user doesn't know that he should disable post-processing for H.264, WMV9 and Co...

It's not always possible to do the pp in the decoding stage. In VirtualDubMod when u load up an mpeg2 file, u don't have access to that stage. U don't have access to it in numerous other scenarios as well. U can only have access to it if ffdshow is doing the decoding via VFW.

You could still use DGIndex/DGDecode for decoding MPEG-2 files. It provides post-processing (deblocking) as well.

Another alternative would be DirectShowSource() or DSS2() with the 'regular' ffdshow decoder...

The ffdshow pp works better than any other pp filter I have available. I really can't comprehend why u don't let the user make an informed decision about using it. How about re-enabling it?

Feel free to file a feature request on their tracker:
http://sourceforge.net/projects/ffdshow-tryout/support

[foxyshadis]

When I started working on ffdshow, I actually assumed it had always been disabled. I didn't know it worked at one point, I don't work on it anymore or I'd look into why that is. Blind PP is available through a number of avisynth deblocking filters though, and avisynth's ffms2 source even gives you the ability to do quant-based deblocking with no slowdown compared to loading it directly in vdmod.

Also, is it so hard to type 'you'?

[lordadmira]

The problem is: Most users don't have a clue what they are doing. And they don't read 'readme' files :rolleyes:
I get that, and even have to deal with it myself sometimes. However I think that if somebody is using *VirtualDub* or any other non commercial video utility u have to make the assumption that they know what they're doing. The clueless people aren't even going to get this far. This isn't a Microsoft/Apple product we're talking about here. :D

I'll make the feature request. Those other options u listed are complete non starters. :) I was rather happy when I discovered ffvdub because it meant I could pull all kinds of functionality into one place. Changing ffdshow installs is easier than bending over backwards to get ffdshow somewhere else in the graph or use a new tool.

And incidentally, I'm not so much using it for deblocking. It does a bang up job on getting rid of periodic static. I have diagonal rolling lines in one video source. Knowledge of macroblocks isn't any use in this situation.


LA

[foxyshadis]

Use avisynth's defreq or ftquiver, you'll get much, much better results. With any luck you'll even be able to reuse the settings across many videos.