ffdshow tryouts project: Discussion & Development

[albain]

Doubt it, because it only happens when you play the DVD in DVD mode. If you play the .vob's independently the problem doesn't happen.

Also seeking is way slower, thing that also doesn't happen when playing the .vob's independently.

EDIT: http://www.megaupload.com/?d=S2YOGNS5 (500KB) --> This sample plays fine with liba52 and MPlayer, but there is a little jump in the middle when ffdshow+libav is used. The sound you'll hear when the jump starts is the same one that happens in the DVD problem.

The problem comes from the libavcodec AC3 parser, which is buggy, and not useful because I already parse AC3 frames internally. Disabling it resolves this issue.

Here is an updated build (different from the official build on sourceforge) :
http://damienbt.free.fr/ffdshow_rev2239_20081020_dbt_new_audio_codecs.exe

[tal.aloni]

Here is an updated build (different from the official build on sourceforge) :
http://damienbt.free.fr/ffdshow_rev2239_20081020_dbt_new_audio_codecs.exe

Awesome!
Thanks for taking the time for an updated merge,
I can now enjoy my mixed playlist without changing codecs / deinterlace settings / volume all the time! peace, at last! :thanks:

[madshi]

The problem comes from the libavcodec AC3 parser, which is buggy, and not useful because I already parse AC3 frames internally. Disabling it resolves this issue.
Do you have any libav parsers left? Getting rid of all of them would of course allow you to also get rid of the complete libavformat package... :)

[Amour]

Little joke for Albain:
I've tested your new build, but it can't play any sound! I've done a sample with TechSmith ...

[STaRGaZeR]

@tal.aloni

I've one question regarding some R1 DVDs I've here and ffdshow+libmpeg2+hardware deinterlacing. There are two possible scenarios:

- The video is 29,97 interlaced --> ffdshow flags it has interlaced and the video gets deinterlaced correctly, 59.96fps.
- The video is 23,976 progressive with a 3:2 soft pulldown --> ffdshow flags it has interlaced, and the resulting fps are 47,96fps. The video is wrong, it get's deinterlaced when there is nothing to deinterlace. Some artifacts and bliking lines can be seen in letters for example. It's possible to do the IVCT process inside ffdshow and feed the renderer with pure progressive frames?

Thanks.

The problem comes from the libavcodec AC3 parser, which is buggy, and not useful because I already parse AC3 frames internally. Disabling it resolves this issue.

Here is an updated build (different from the official build on sourceforge) :
http://damienbt.free.fr/ffdshow_rev2239_20081020_dbt_new_audio_codecs.exe

With that build my sample is fixed, but the DVD thing is still there.

[tal.aloni]

@tal.aloni
I've one question regarding some R1 DVDs I've here and ffdshow+libmpeg2+hardware deinterlacing. There are two possible scenarios:

- The video is 29,97 interlaced --> ffdshow flags it has interlaced and the video gets deinterlaced correctly, 59.96fps.

I guess you use bob deinterlacing and making a frame out of each field. if you have the CPU power, that's the way to go for this type of content.


- The video is 23,976 progressive with a 3:2 soft pulldown --> ffdshow flags it has interlaced, and the resulting fps are 47,96fps. The video is wrong, it get's deinterlaced when there is nothing to deinterlace. Some artifacts and bliking lines can be seen in letters for example. It's possible to do the IVCT process inside ffdshow and feed the renderer with pure progressive frames?

It's not ITCV if the source is progressive, it's just a matter of ignoring the flags.
Since you directed the question to me, I went out of my way and encoded a 23.976 video, and added pulldown flags.

I'm using the latest build, and it seems that haruhiku yamagata had already done something in regard:


Author: h_yamagata
Date: Mon Oct 20 13:04:50 2008 UTC (4 hours, 14 minutes ago)
Log Message: Import code from guliverkli by gabest.
libmpeg2: flag "progressive" if telecined film is detected.



I noticed something strange:
while the video reported as "progressive", and does not need deinterlacing, it's framerate reported incorrectly as 29.976. (playback time / speed is correct, but number of frames is not. strangely).

Edit:
by going frame by frame, I figured out the mystery, it just plays back the end of the video another time when it reaches the actual end.
Haruhiko, since you already familiar with the subject, can you look it up?

[MatMaul]

@ haruhiko_yamagata : thank you for the libmpeg2 interlaced code detection :)

but it seems to me that the SEQ_FLAG_PROGRESSIVE_SEQUENCE is not reliable : it is set to 0 in my lord of the ring DVD.
I take the specs and it seems that we should consider a frame as progressive if the PIC_FLAG_PROGRESSIVE_FRAME is set, even if the SEQ_FLAG_PROGRESSIVE_SEQUENCE isn't.

with this diff :
Index: TvideoCodecLibmpeg2.cpp
===================================================================
--- TvideoCodecLibmpeg2.cpp (revision 2239)
+++ TvideoCodecLibmpeg2.cpp (working copy)
@@ -253,7 +253,7 @@
}
}

- if(seqflags & SEQ_FLAG_PROGRESSIVE_SEQUENCE)
+ if(newflags & PIC_FLAG_PROGRESSIVE_FRAME)
di_method = FIELD_TYPE::PROGRESSIVE_FRAME; // hurray!
else if(m_fFilm)
di_method = FIELD_TYPE::PROGRESSIVE_FRAME; // we are lucky

I obtain the same output as libavcodec.

I think we also need a way to force bob in the output tab because some (most ?) of DVB streams are badly flagged :(

[tal.aloni]

I improved the normalization algorithm (Regain volume checked) a little bit:

+ now it does not tied to sampling rate or samples per call, (so it should act pretty much the same on files with different sampling / format / container)

+ I figured changing the Normalization checkbox title would be too radical for some, so I've stuck with "Normalization".

+ "Buffer Size" combo box was Removed. (the new algorithm doesn't use the buffer)

This Build is based on Albain's latest revision:
http://iknowu.net/files/public/ffdshow/BetterNormalization/ffdshow_rev2239_20081020-NewAudioCodecsAndBetterNormalization-RC4.exe

Patch:
http://iknowu.net/files/public/ffdshow/BetterNormalization/ffdshow-BetterNormalizationAlgorithm-RC4-Patch.zip

I think it's ready for prime time, maybe the coefficients will be modified slightly if requested,
but its already much better then the existing code.
http://iknowu.net/files/public/ffdshow/BetterNormalization/ffdshow-BetterNormalizationAlgorithm-RC4-Patch.zip

p.s. if, unimaginably, we'll prefer to keep the existing mechanism,
I have a patch that fix an old bug: ffdshow does not crush anymore when buffer size decreased during playback.

[STaRGaZeR]

I guess you use bob deinterlacing and making a frame out of each field. if you have the CPU power, that's the way to go for this type of content.

Yes, CPU power is not a problem (is it in any modern computer? :p). The ATI cad does an excellent job here.

It's not ITCV if the source is progressive, it's just a matter of ignoring the flags.
Since you directed the question to me, I went out of my way and encoded a 23.976 video, and added pulldown flags.

I'm using the latest build, and it seems that haruhiku yamagata had already done something in regard:

I noticed something strange:
while the video reported as "progressive", and does not need deinterlacing, it's framerate reported incorrectly as 29.976. (playback time / speed is correct, but number of frames is not. strangely).


I'm using the last build posted by albain here (seems to be 2239) and it's still flagging film DVD material as interlaced, resulting in 47.96fps. So it ignores the pulldown flags, but the output flag is still interlaced and the videocard is still deinterlacing, clearly visible. Looks like MatMaul has figured it out.

BTW, when no deinterlacing is done playing the file results in this, the video goes in small jumps:

http://i33.tinypic.com/1p9ro0.png

If I use Avisynth - Smooth timestamps (in the 3:2 pulldown option) the line looks flat and the video plays with no jerks like it should be. Also if I strip the pulldown marks, perfect playback(obvious).

[madshi]

@ haruhiko_yamagata : thank you for the libmpeg2 interlaced code detection :)

but it seems to me that the SEQ_FLAG_PROGRESSIVE_SEQUENCE is not reliable : it is set to 0 in my lord of the ring DVD.
I take the specs and it seems that we should consider a frame as progressive if the PIC_FLAG_PROGRESSIVE_FRAME is set, even if the SEQ_FLAG_PROGRESSIVE_SEQUENCE isn't.
Here's what I figured out for MPEG2:

// progressive_sequence = 1 -> all frames are progressive; 0 -> can be everything
// picture_structure = 3 -> progressive or interlaced frame; 1-2 -> interlaced field; 0 -> reserved
// progressive_frame = 1 -> only allowed with "picture_structure = 3"; progressive; 0 -> interlaced
The problem is that with both broadcasting and DVD sources you can not rely on things staying constant. E.g. some parts of the movie can be encoded as progressive frames while other parts are encoded as interlaced frames or even fields. Furthermore some parts of the movie may contain pulldown flags while in other parts the pulldown may be hard coded into the stream (as double encoded fields/frames). Finally, even if a frame is flagged as progressive, it can actually be interlaced - and it's possible that the wrong interlaced fields were mixed together into this frame. Such bad stuff happens only rarely, but some DVDs are known to be incorrectly authored. So the safest bet is always to assume that the source is interlaced and to use a proper IVTC algorithm to match the separate fields. The only situation where you can rely on stability is if "progressive_sequence" is set (usually only the case for Blu-Ray sources) or for 1080i60 sources where you know their origin is HD DVD (those all have a regular and constant pulldown pattern).

[fleon]

Hi i have two problems with the x64 version of ffdshow this one ffdshow_rev2202_20081010_clsid_x64.exe, I have windows xp x64 and eventhought I have selected the tray icons to be displayed that doesnt happen with any video, and the second problem is that the xvid decoder doesnt work and maybe other decoders also doesnt work,

I know this because I tried to convert an xvid avi video and I got this error "render the file the filter graph won't talk to me" I searched for some answeres and installed graphedit and opened the video and it said that it could not find the decoder so I installed the xvid decoder fromn the koepi site and it worked,

So is there a workaround or something?

Thanks

[_xxl]

x64 is experimental so don't expect too much...

[albain]

Hi i have two problems with the x64 version of ffdshow this one ffdshow_rev2202_20081010_clsid_x64.exe, I have windows xp x64 and eventhought I have selected the tray icons to be displayed that doesnt happen with any video, and the second problem is that the xvid decoder doesnt work and maybe other decoders also doesnt work,

I know this because I tried to convert an xvid avi video and I got this error "render the file the filter graph won't talk to me" I searched for some answeres and installed graphedit and opened the video and it said that it could not find the decoder so I installed the xvid decoder fromn the koepi site and it worked,

So is there a workaround or something?

Thanks

Maybe you tried to play those with the 32 bits version of media player (the default icon of WMP points to 32 bits version) ?

[haruhiko_yamagata]

I'm using the last build posted by albain here (seems to be 2239) and it's still flagging film DVD material as interlaced,It's from different branch. Please try another build by tal.aloni.

Timestamps issue is another problem.

[haruhiko_yamagata]

I improved the normalization algorithm (Regain volume checked) a little bit:

+ now it does not tied to sampling rate or samples per call, (so it should act pretty much the same on files with different sampling / format / container)

+ I figured changing the Normalization checkbox title would be too radical for some, so I've stuck with "Normalization".

+ "Buffer Size" combo box was Removed. (the new algorithm doesn't use the buffer)Looks OK. I would like to hear more opinion from members here.

I wouldn't understand what "Regain volume" is, if I was not reading this thread.
"Night mode" would be easier to understand, if it is not wrong.

[tal.aloni]

It's from different branch. Please try another build by tal.aloni.

In 2239, Albain merged the changed from the trunk up to 2238, so you're modification should be already implemented there.


I wouldn't understand what "Regain volume" is, if I was not reading this thread.
"Night mode" would be easier to understand, if it is not wrong.
What about this tooltip:

"Unchecked: one-pass normalization will be performed
(this mode is used to reach the highest possible loudness
with minimum of possible artifacts)

Checked: dynamic range compression will be performed, quieter parts will be
amplified more then louder parts (also known as night mode)."

Thanks,
Tal

[MatMaul]

here is a patch which allows to force bob and to force the field order in the output tab for hardware deinterlacing.
http://www.etud.insa-toulouse.fr/~mvelten/bordel/hw_deinterlace_auto.01.diff

[haruhiko_yamagata]

In 2239, Albain merged the changed from the trunk up to 2238, so you're modification should be already implemented there.No. In 2239, he merged up to 2235.

What about this tooltip:

"Unchecked: one-pass normalization will be performed
(this mode is used to reach the highest possible loudness
with minimum of possible artifacts)

Checked: dynamic range compression will be performed, quieter parts will be
amplified more then louder parts (also known as night mode)."

Thanks,
TalTool tip is good, but I still prefer to label it night mode.

[Eragon4ever]

I don't like the idea of "night mode". IMHO features should be named after what they do, not what they can be used for. That can be written down in the documentation (if there were any). With no documentation (or this thread in this case) I surely would not understand what "night mode" means.

[tal.aloni]

here is a patch which allows to force bob and to force the field order in the output tab for hardware deinterlacing.
http://www.etud.insa-toulouse.fr/~mvelten/bordel/hw_deinterlace_auto.01.diff

Bad choise of names, "AUTO" is very confusing.
IMO, it should be
"BOB",
"Weave",
"Forced BOB",
"Forced Weave".

[tal.aloni]

features should be named after what they do, not what they can be used for.

I agree, "Regain volume" is friendlier to the average user.
it's also used on Media player classic, so it would be more familiar.

[albain]

Why not adding a description in the tool tip ?

[tal.aloni]

Why not adding a description in the tool tip ?

I will do that anyway.

[MatMaul]

Bad choise of names, "AUTO" is very confusing.
IMO, it should be
"BOB",
"Weave",
"Forced BOB",
"Forced Weave".
force weave doesn't exist, if you choose weave you force to do not deinterlace anyway.
auto choose between bob (deinterlace) and weave according to the flags reported by the decoder so I think it is a good name.

[fleon]

Maybe you tried to play those with the 32 bits version of media player (the default icon of WMP points to 32 bits version) ?

I played it with Media player classic home cinema x64 edition, but there I can be sure if ffdshow is running since as I said I activated the tray icons are they dont appear, but I also activated the osd and that did appear so it seems that it is running , but why the tray icons are not displaying?

Also the error happened when I was going to convert a xvid avi video with megui I got the render file wont talk to me, then as I said I installed the xvid decoder from koepi's site and it worked, so I dont know maybe it is an error from megui.. but still the tray icons are not showing(look above)

[tal.aloni]

force weave doesn't exist


that's what I figured, what is this then: (your code) :)

+ // Force weave


auto choose between bob (deinterlace) and weave according to the flags reported by the decoder so I think it is a good name.

I'm sorry, but I'm confused, is Auto = what was "Bob" up until today?

[STaRGaZeR]

I'm sorry, but I'm confused, is Auto = what was "Bob" up until today?

Yes. BOB today checks if the source is progressive or interlaced and put the flags in consequence, you're not using only BOB. So AUTO is a good name for the actual BOB, because that's what it's doing.

Can anybody compile a test version with the lastest changes of haruhiko?

[tal.aloni]

Yes. BOB today checks if the source is progressive or interlaced and put the flags in consequence, you're not using only BOB. So AUTO is a good name for the actual BOB, because that's what it's doing.


OK, Thanks.
I think this 3 are more clear:
"AUTO BOB"
"ALWAYS BOB"
"WEAVE"

[MatMaul]

OK, Thanks.
I think this 3 are more clear:
"AUTO BOB"
"ALWAYS BOB"
"WEAVE"
I agree, here is the updated patch :
http://www.etud.insa-toulouse.fr/~mvelten/bordel/hw_deinterlace_auto.02.diff

[tal.aloni]

don't get mad, and forgive the noob, but I must say again, it's time to merge Albain's changes into the SVN.

The whole reason I started getting into ffdshow audio decoder, and ultimately into ffdshow's development, was our "next generation" format support, and for anybody else that has gotten into HD Audio, there is no other free (real time) alternative. I know that many High-Def enthusiastic use his builds exclusively, including me,
and the current split makes both developing and testing a bit harder for all parties involved.
besides, if there are still bugs in his latest beta, which I use thoroughly, they are hiding pretty well.

Tal

[tal.aloni]

Can anybody compile a test version with the lastest changes of haruhiko?

xvidvideo.ru has posted build based on rev. 2240, (no russian needed).

[STaRGaZeR]

xvidvideo.ru has posted build based on rev. 2240, (no russian needed).

Tested and it indeed puts the progressive flag, but now there is another problem: titles with film+video in the same stream. ffdshow detects the first, progressive, and when the second is reached (has to be deinterlaced) the flags are still progressive. I bet the same will happen when there is video first and then film, film will get deinterlaced. Below I've uploaded a funny MPEG-2 clip, extracted from a DVD. It has film content at the beginning, video at the end and most probably bad pulldown flags. Check the scene changes, specially when the pink haired girl appears.


http://www.megaupload.com/?d=MPMULDNV (21MB)

[adam777]

Hello all,
First things first, I must say I've already posted the following in the feature request and open discussion forum sections of the sourceforge page, but it seems way more active in here.
I was wondering if it's possible to add revision number (e.g. 2228), for ffdshow.ax, under "Product Version", so one can track installed version, using software like SUMo (http://www.kcsoftwares.com/?sumo).
I know the information is presented in the registry, but I figured it might be possible to automate the compiling process (or something of that sort) and include the information in there also.
Thanks in advance, Adam.

[haruhiko_yamagata]

I agree, here is the updated patch :
http://www.etud.insa-toulouse.fr/~mvelten/bordel/hw_deinterlace_auto.02.diffI can't accept your patch about TvideoCodecLibmpeg2.cpp.
Please read madshi's post (http://forum.doom9.org/showthread.php?p=1205181#post1205181) again.

As for deinterlacing methods, what about "Auto", "Force Bob", "Force Weave"?

[tal.aloni]

I was wondering if it's possible to add revision number (e.g. 2228), for ffdshow.ax, under "Product Version"

1. ffdshow.ax contains version number already, Windows XP will show it only if you rename the extension to "dll".
(not sure it's properly maintained though)

2. you can always see the revision number in the "About screen". (decoder configuration)

[madshi]

I know that this is a tall order, but do you video deinterlacing guys think that it would be possible to extract the IVTC deinterlacing solution implemented in the DScaler IVTC mod and make it work in ffdshow as a separate deinterlacer? That would be more than awesome cause this deinterlacing solution works extremely well for all my MPEG2 sources. But I guess it would be too much work because the IVTC deinterlacing code is interweaved with the DScaler decoder? So it's probably hard to extract? I have to admit that I don't know neither the ffdshow sources nor the DScaler sources...

[haruhiko_yamagata]

Tested and it indeed puts the progressive flag, but now there is another problem: titles with film+video in the same stream. ffdshow detects the first, progressive, and when the second is reached (has to be deinterlaced) the flags are still progressive. I bet the same will happen when there is video first and then film, film will get deinterlaced. Below I've uploaded a funny MPEG-2 clip, extracted from a DVD. It has film content at the beginning, video at the end and most probably bad pulldown flags. Check the scene changes, specially when the pink haired girl appears.


http://www.megaupload.com/?d=MPMULDNV (21MB)
Helpful post but please read forum rule #6. Please use PM.
Rev 2242 is hopefully the solution.

[haruhiko_yamagata]

I know that this is a tall order, but do you video deinterlacing guys think that it would be possible to extract the IVTC deinterlacing solution implemented in the DScaler IVTC mod and make it work in ffdshow as a separate deinterlacer? That would be more than awesome cause this deinterlacing solution works extremely well for all my MPEG2 sources. But I guess it would be too much work because the IVTC deinterlacing code is interweaved with the DScaler decoder? So it's probably hard to extract? I have to admit that I don't know neither the ffdshow sources nor the DScaler sources...I'm trying to import yadif from mplayer. It's a complicated work.
IVTC is also an wanted feature. I guess it's more complicated though.

[adam777]

1. ffdshow.ax contains version number already, Windows XP will show it only if you rename the extension to "dll".
(not sure it's properly maintained though)

2. you can always see the revision number in the "About screen". (decoder configuration)

Hi Tal,
The file indeed contains version number, I'm aware of that fact, but as you've said, it isn't maintained properly (at the moment, rev. 2240 shows version no. 1.0.5.2184, as did all the revisions I can think of).
That is why I asked if an automated process might be possible when compiling the binaries from source.

[Inventive Software]

Helpful post but please read forum rule #6. Please use PM.
Rev 2242 is hopefully the solution.

It is a sample for diagnosing playback problems and fixing them. It is not in contravention of Rule 6. ;)

[STaRGaZeR]

Helpful post but please read forum rule #6. Please use PM.
Rev 2242 is hopefully the solution.

I own the DVDs, English edition ;)

I'll report any problems.

[MatMaul]

I can't accept your patch about TvideoCodecLibmpeg2.cpp.
Please read madshi's post (http://forum.doom9.org/showthread.php?p=1205181#post1205181) again.
ok I read it again and you are right but there is still a problem :
if seq_progressive = 0 (so we can't assume anything) the actual code don't take in account the value of pict_progressive and it ends by flagging with TFF or BFF even if pict_progressive is set (it is what happens on my lord of the ring DVD).

here is (I hope :p) a correct patch :
Index: TvideoCodecLibmpeg2.cpp
===================================================================
--- TvideoCodecLibmpeg2.cpp (revision 2242)
+++ TvideoCodecLibmpeg2.cpp (working copy)
@@ -254,6 +254,8 @@

if(seqflags & SEQ_FLAG_PROGRESSIVE_SEQUENCE)
di_method = FIELD_TYPE::PROGRESSIVE_FRAME; // hurray!
+ else if(newflags & PIC_FLAG_PROGRESSIVE_FRAME)
+ di_method = FIELD_TYPE::PROGRESSIVE_FRAME;
else if(m_fFilm)
di_method = FIELD_TYPE::PROGRESSIVE_FRAME; // we are lucky
#if 1 // ffdshow custom code


As for deinterlacing methods, what about "Auto", "Force Bob", "Force Weave"?
I agree

[clsid]

don't get mad, and forgive the noob, but I must say again, it's time to merge Albain's changes into the SVN.

The whole reason I started getting into ffdshow audio decoder, and ultimately into ffdshow's development, was our "next generation" format support, and for anybody else that has gotten into HD Audio, there is no other free (real time) alternative. I know that many High-Def enthusiastic use his builds exclusively, including me,
and the current split makes both developing and testing a bit harder for all parties involved.
besides, if there are still bugs in his latest beta, which I use thoroughly, they are hiding pretty well.

Tal
I disagree. The whole process of getting these new audio decoders to function properly took much longer than everyone expected. In hindsight I am therefore very glad we decided to open up a branch for it during development. It seems to be working OK now thanks to Albain's hard work, but it has only been tested by a small group of users. Albain has released a public build a few days ago. Like I have said before, if no bugs are reported for about a week, then it can be considered stable enough for merging. So if all goes well, I will update the trunk this weekend/beginning of next week.

[haruhiko_yamagata]

ok I read it again and you are right but there is still a problem :
if seq_progressive = 0 (so we can't assume anything) the actual code don't take in account the value of pict_progressive and it ends by flagging with TFF or BFF even if pict_progressive is set (it is what happens on my lord of the ring DVD).
If I understand correctly,
PIC_FLAG_PROGRESSIVE_FRAME set: progressive or interlaced
PIC_FLAG_PROGRESSIVE_FRAME not set: interlaced

[MatMaul]

from the specs :
If progressive_frame is set to 0 it indicates that the two fields of the frame are interlaced fields in which an interval of time of the field period exists between (corresponding spatial samples) of the two fields.
If progressive_frame is set to 1 it indicates that the two fields (of the frame) are actually from the same time instant as one another.

I interpret like that :
progressive_flag==1 => progressive (same timestamp for both field => frame)
progressive_flag==0 => interlaced (two timestamps, one for each field)

[haruhiko_yamagata]

Then why on earth gabest had to write that complicated code?
He had to have good reason.

[Mercury_22]

I disagree. The whole process of getting these new audio decoders to function properly took much longer than everyone expected. In hindsight I am therefore very glad we decided to open up a branch for it during development. It seems to be working OK now thanks to Albain's hard work, but it has only been tested by a small group of users. Albain has released a public build a few days ago. Like I have said before, if no bugs are reported for about a week, then it can be considered stable enough for merging. So if all goes well, I will update the trunk this weekend/beginning of next week.

Can you PLEASE compile a WORKING 64-bit build of that branch for testing, (since Albain can't compile 64-bit successfully) ? :thanks: :helpful:

[littleD]

I'm trying to import yadif from mplayer. It's a complicated work.
IVTC is also an wanted feature. I guess it's more complicated though.

Well, maybe its not necessary. :) I managed to use avisynth plugin directly in ffdshow. I didn't know until now, thats even possible. Its nice workaround and i dont know if it is proper way of using avs filters, but it'll save ur time :) Just paste this code:
Load_Stdcall_Plugin("Path to Yadif\yadif.dll")
Yadif(order=-1)
into ffdshow's avisynth configuration section. Anyway I cant test it further, cause all my interleaced HD samples choke my poor Sempron :devil: and cant say about quality of output. Of course any avs plugin can be used, just be aware of cpu utilization.

[STaRGaZeR]

Rev 2242 is hopefully the solution.

It works :)

Can you say anything about what happens in scene changes? DGIndex reports interlaced frames in those locations, but they don't get deinterlaced? libav mpeg2 seems to do something to them, if that helps you. There is a small jump, but... Also, smooth timestamps without Avisynth would be really nice.

[alexins]

Can you PLEASE compile a WORKING 64-bit build of that branch for testing, (since Albain can't compile 64-bit successfully) ? :thanks: :helpful:

Try this version of the assembly ffdshow 2239 x64 (http://www.xvidvideo.ru/component/option,com_docman/task,doc_details/gid,564/Itemid,11/) (libavformat branch (http://www.xvidvideo.ru/component/option,com_docman/task,doc_download/gid,564/Itemid,11/))