DirectShowSource problem vs. AviSource

[numlock]

I just made a short capture using HuffYUV in YUY2 color space.

Then I wrote 2 scripts to open the file - one using AVISource and the other with DirectShowSource. The results are very different. DirectShowsource is visibly worse quality cause it adds rainbow artifacts. (see pictures)

For AVISource:

http://www.wtlzone.com/images/avisource.jpg

and here is the file information (by opening the script in VirtualDub)

http://www.wtlzone.com/images/avisource2.jpg

Here is the picture for DirectShowSource (notice the rainbows)

http://www.wtlzone.com/images/dss.jpg

and here is the file info: (notice it outputs it in YV12 instead of YUY2. Why ??)

http://www.wtlzone.com/images/dss2.jpg

Is there solution to this problem ? I'd like to get the same results as I get with AviSource.

[numlock]

OK, I just copied the same DSS script and the same file on a different
computer and when I open it in VDub the rainbows are gone and
in file info it says Decompressor: Uncompressed RGB32

This is still unacceptable because I want it in YUY2.

So it looks to me like directshow reads the file and then it outputs it in YV12 on the first computer and in uncompressed RGB32 on the other computer and that's what VDub is reading.

SO is there a way to tell it to output in YUY2 ?

[stickboy]

I don't understand why you're using DirectShowSource if you can use AVISource...?

[numlock]

Problem is I want to start using the new plugin ASF Direct Writer
for iuVCR which uses asf container.

http://vlafy.iulabs.com/

In order to open these files i have to use DirectShowSource. The same problem that I just described is happening with ASF Direct Writer files (.asf) as well as regular AVI files.

Basically to summarize this - DirectShowSource reads YUY2 files encoded in HuffYUV and ouputs them in YV12 color space on one computer and in RGB32 on another computer. There must be some setting somewhere that can do it correctly.

[Schlumpf]

When using DirectShowSource the output colorspace is dependant on the direct-show decoder installed and that can vary from system to system.
Either edit the responsible decoder to output to another colorspace or replace it or add a ConvertToYUY2(interlaced = true/false) after DirectShowSource.

[numlock]

Originally posted by Schlumpf
When using DirectShowSource the output colorspace is dependant on the direct-show decoder installed and that can vary from system to system.
Either edit the responsible decoder to output to another colorspace or replace

Yes that's what I think. But how do I change the directshow decoder ?

[kingmob]

Disable the divx decoder. Then use xvid or ffdshow and set these up so that the output is in the colorspace you want. I'd bet that would fix it.

[numlock]

OK, thanks but how to I disable the divx decoder ?

[stephanV]

What does huffyuv have to do with divx anyway? you will have to let the directshow renderer output to YUY2... divx has nothing to do with this...

how? I dunno... :(

maybe taking a look at your directshow graph in graphedit might help though...

[numlock]

Problem is directshow renderes output to YV12 instead of YUY2.

DivX decoder is used on my system to decode YV12 color space.

I wish there was a way to tell directshowsource to decode it in particular color space - the same way it can be done with AVISource function

[Seed]

In first PC:

a) Huffyuv avi (YUY2)
--> avisource by Avisynth (YUY2)
--> Vdub (YUY2) (Video for windows or VfW)
--> DISPLAYS as RGB24 on monitor

b) Huffyuv avi (YUY2)
--> DSS by Avisynth (YUY2)
--> default directshow decoder = DivX in this PC (YV12)
--> Vdub (YV12)
--> DISPLAYS as RGB24 on monitor

DivX converts YUY2 to YV12 and output YV12 to Vdub, which finally DISPLAY as RGB24 on your monitor. The rainbow is perhaps due to chroma sampling error during these conversions.

In your second PC, not sure what direct show decoder is installed. But since it outputs as RGB32 to Vdub, there is no down-sampling to YV12 then upsampling to RGB24. Hence the absence of rainbow artefact.

I find this useful in general:

1) To understand why the colourspace discrepancy between the 2 PC, use Gspot (easier to use in my opinion) or Graphedit to see the paths from Huffyuv avi --> directshow filters --> video player/Vdub

2) To solve the problem, install ffdshow in both PC and enable ffdshow as the default direct-show decoder for output to video player/Vdub. The "video decoder configuration" in ffdshow let you override DivX as the default decoder.

[jinkslynx]

On your start menu, go to divx => divx codec => decoder configuration utillity, hit the quality settings tab, and uncheck the support generic MPEG-4 box, or uninstall it. Install the Xvid codec, and go to Xvid => configure decoder. That should give you all the options you want.

[numlock]

OK, I got rid of DivX and installed XVid and still the same problem. The output is still in YV12 color space on one machine and RGB32 on the other.

[numlock]

Originally posted by Seed
In first PC:

a) Huffyuv avi (YUY2)
--> avisource by Avisynth (YUY2)
--> Vdub (YUY2) (Video for windows or VfW)
--> DISPLAYS as RGB24 on monitor

b) Huffyuv avi (YUY2)
--> DSS by Avisynth (YUY2)
--> default directshow decoder = DivX in this PC (YV12)
--> Vdub (YV12)
--> DISPLAYS as RGB24 on monitor

DivX converts YUY2 to YV12 and output YV12 to Vdub, which finally DISPLAY as RGB24 on your monitor. The rainbow is perhaps due to chroma sampling error during these conversions.

In your second PC, not sure what direct show decoder is installed. But since it outputs as RGB32 to Vdub, there is no down-sampling to YV12 then upsampling to RGB24. Hence the absence of rainbow artefact.


Yes this is exactly what's happening. So I installed ffdshow but the problem is I can't find anyting in "video decoder configuration" that would enable ffdshow as the default direct-show decoder for output to video player/Vdub.

Where should I look for this option under codecs ?

[stephanV]

Originally posted by Seed
DivX converts YUY2 to YV12 and output YV12 to Vdub, which finally DISPLAY as RGB24 on your monitor. The rainbow is perhaps due to chroma sampling error during these conversions.

Sorry, this is complete nonsense. DIvX does NOT convert anything here, the only thing its doing is "decoding" the YV12 output from Avisynth.

Please look at your directshow graph to find out whats going on and what filters are used.

[numlock]

stephanV

Yes you are correct DivX is only decoding the YV12 output from Avisynth

How do I look at directshow graph ? Do I need to use GraphEdit for
it ?

[stephanV]

yup

[numlock]

OK, here is the graph and it clearly shows there is a Color Space Converter. But what is it ? Where do I find the name of this file or codec that's doing this. If I click on properties it says
"The requested property page could not be displayed"

http://www.wtlzone.com/images/graph.jpg

[stephanV]

I think it is more useful to look at the graph of your original Huffyuv file, as that is the graph that AVIsynth uses...

[Leak]

Originally posted by numlock
If I click on properties it says
"The requested property page could not be displayed"

You need to run

regsvr32 proppage.dll

(or register.bat, if it's included) in graphedit's directory.

[Seed]

Originally posted by Seed
DivX converts YUY2 to YV12 and output YV12 to Vdub, which finally DISPLAY as RGB24 on your monitor. The rainbow is perhaps due to chroma sampling error during these conversions.


Originally posted by stephanV
Sorry, this is complete nonsense. DIvX does NOT convert anything here, the only thing its doing is "decoding" the YV12 output from Avisynth.

You are right, the first part of the first sentence is wrong, I should not have said that, not being familiar with DivX. Sorry. But the the rest of the (quoted) first sentence, and the second sentence is correct, not complete nonsense. Something (not DivX) IS CONVERTING YUY2 to YV12, which DivX then decode to Vdub.

@numlock
I might have a blind-spot when posted the first reply (or was the screenshot modified later???), now I see the second screenshot of "avi info" indicates ATI YVU12 4:2:0 Planar under FourCC code.

I guess is you have ATI hardware (?? ATI All-in-Wonder card) or MMC driver installed, and it is the one responsible for colour space conversion (without you asking for it).

Another point at hand, "CX23883 NTSC DVD.avs" suggests to me that you have Conexant 2388x series chipset installed (? in ATI card).

[stephanV]

Originally posted by Seed
You are right, the first part of the first sentence is wrong, I should not have said that, not being familiar with DivX. Sorry. But the the rest of the (quoted) first sentence, and the second sentence is correct, not complete nonsense. Something (not DivX) IS CONVERTING YUY2 to YV12, which DivX then decode to Vdub.


Agreed :)

[numlock]

Originally posted by Seed
@numlock
I might have a blind-spot when posted the first reply (or was the screenshot modified later???), now I see the second screenshot of "avi info" indicates ATI YVU12 4:2:0 Planar under FourCC code.

I guess is you have ATI hardware (?? ATI All-in-Wonder card) or MMC driver installed, and it is the one responsible for colour space conversion (without you asking for it).

Another point at hand, "CX23883 NTSC DVD.avs" suggests to me that you have Conexant 2388x series chipset installed (? in ATI card).

Ye I have ATI graphics card. But that shouldn't be a problem. There are many people who have ATI cards and there are no color space conversions.

I also want to mention that on the 2nd computer there is also a color space conversion from YUY2 to RGB32

OK, here is the graph from loading the avi files directly.

This graph is the same on both computers. Only difference is as I mentioned earlier the color space is converted to YV12 or RGB32

So question is how to a disable this filter.

http://www.wtlzone.com/images/graph2.jpg

[Seed]

Umm, from your screenshot GraphEdit does not seem to give much info on which codecs or dll are used as "Color space converter", "Video renderer".

Try Gspot latest beta version
http://www.headbands.com/gspot/gspot252dl.html

Look at the lower part of the program Gspot, click on the button under "under MS A/V", mouse over the phrases "Color space converter", "Video renderer" etc, and you will see which dll's or codecs are used. E.g all 3 "AVI decompressor", "Color space converter", "Video renderer" on my PC are served by "quartz.dll" (from Microsoft I think).

I am quite sure that in your first PC, ATI driver/codec somewhat gets in the way. You should consider uninstalling ATI MMC driver (NOT Catalyst display driver). Alternatively, after you learn at what point ATI codec gets in, use GraphEdit's "Render Media File" function to bypass the ATI codec. I am not familiar with this function myself, but here are two links that may give you an idea on how to do it:
http://www.videohelp.com/forum/userguides/89139.php
http://dscreat.com/DVType1AVISynthGuide/index.html

[stephanV]

@Numlock:

There is one thing that is worth a shot. AviSynth is also able to open directshow graphs with open pins.

Delete from the graph you posted here the colorspace converter and the audio and video renderers. Then save the graph in graphedit to something like mygraph.grf. then open it in avisynth with DirectShowSource("mygraf.grf"). Open the script in VirtualDub and look if YUY2 is the colorspace.

I think the problem is that your video renderer does not know what to do with YUY2 and therefor asks for a colorspace conversion to either YV12 or RGB32. While I don't know how to fix that, above solution might fix your problem since AVS obviously does know how to handle YUY2.

Hope this helps. :)

[numlock]

ok, I looked at it via GSpot and it's "quartz.dll" on both systems that's used for color space conversion.

stephanV:

I tried to delete the colorspace converter and the audio and video renderers and opened it in VDub. The color space this time was in RGB32 instead of YV12.

So it just won't leave the colorspace alone. Why is it that this kind of crap is only happening with MS technologies

[Wilbert]

I suggest you install huffyuv and if that still doesn't work, you add this

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
"VIDC.YUY2"="hfyu.dll"

thingie (or whatever the name of the dll is) to your registry.

[numlock]

Originally posted by Wilbert
I suggest you install huffyuv and if that still doesn't work, you add this

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
"VIDC.YUY2"="hfyu.dll"

thingie (or whatever the name of the dll is) to your registry.

this still results in RGB32

[stephanV]

perhaps you have huffyuv set to always output RGB?

[numlock]

Originally posted by stephanV
perhaps you have huffyuv set to always output RGB?

No, I already checked it before it's not set to RGB.

I think the problem is DirectShow Source function builds a graph that converts the color space

AviSynth clearly does not build the same graph as the one I see when I load the file in Graph Edit otherwise it would not be able to extract any data from it (do you see any filter that can extract data from the graph?). So it must insert its own sink in place of the video renderer which means that the graph I built in GraphEdit has no meaning. If the AvuSynth sink accepts YUY2, there won't be any CSC in its graph. But apparently the filter to extract data for some odd reason requires RGB32 or YV12 format.

Is there are a way to see the graph that DSS builds ?

[numlock]

Yesterday I did another test and this is going to shed some more light.

I use HuffYUV for my captures.

Yesterday I captured video by disabling the codec and did uncompressed capture in YUY2

----------------------
DirectShowSource("capture.avi")
Info()
----------------------

I opened the script in VirtualDub and the color format is correct in YUY2

However if I go back and use HuffYUV codec to capture in YUY2

the same script gives me color space RGB32

But if I use
----------------------
AVISource("capture.avi")
Info()
----------------------

The color space is correctly in YUY2

Unfortunately I cannot use AVISource function in my projects because I'm gonna be using ASF container to capture
files and only DirectShowSource can open those files.

I only use the old AVI mux to capture these test files to be able to compare the retults between AViSource and DirectShowSource

SO I think at this point we can assume that the problem is in how DirectShow handles files encoded in HuffYUV

If it's not too much trouble could somebody test this with HuffYUV codec and see what results you get

TIA

[Wilbert]

Sorry, i was not paying attention :)

Huffyuv is a VfW codec. So the main question is which directshow decoder is decompressing your huffyuvs in Graphedit (obviously not Huffyuv)? Also which colorformat does it output (i guess not yuy2)?

Perhaps you can use ffdshow to decode your huffyuvs in graphedit?

Oh eh, why are you going to use asf for capping?

[Seed]

Originally posted by numlock
SO I think at this point we can assume that the problem is in how DirectShow handles files encoded in HuffYUV

(Latest beta version 15th March 2005 of Avisynth gives "there is no function named "DirectShowSource". I am too lazy to reintall older version for testing - and reinstall latest version again.)

But I can reinforce this finding of yours. For quite some time almost all my avi files were compressed with Huffyuv 2.1.1, and they behave like a RGB avi when called/loaded to a Directshow app:

1) In Gspot, when rendered with "MS A/V" (i.e. Directshow renderer), a YUY2 Huffyuv avi will turn into RGB32 after "AVI decompressor" (quatz.dll)

2) Whe a YUY2 Huffyuv avi is loaded directly into Procoder Express (PCE), the resultant MPEG2 file is too "contrasted". It is seen by PCE as if it is a RGB avi file, which (from my testing) PCE will do a rescale from [0, 255] to [16, 235]. (Interestingly if you framserve the Huffyuv avi with Avisynth "avisource", PCE will see it correctly as YUY2 and will not rescale the levels, giving a correct color scale MPEG2.)

At first you focus on why the first PC gave YV12 colour, and this was solved by GaphEdit. But your ultimate aim is to get YUY2 colour space from DirectShowSource. I think the solution is what I said earlier: install ffdshow in both PC and enable ffdshow as the default direct-show decoder for output. The "ffdshow video decoder configuration" let you use "libavcodec" as decoder for Huffyuv format. By enabling libavcodec in ffdshow, I have found:

1) In Gspot, when rendered with "MS A/V" (i.e. Directshow renderer), a YUY2 Huffyuv avi will remain in YUY2. (No such things as "AVI decompressor", "Color space converter")

2) PCE will give correct colour scale MPEG with a directly loaded Huffyuv avi.

All the above are my previous observation and sorry I have not tested directly with DirectshowSource.

[numlock]

Originally posted by Seed
I think the solution is what I said earlier: install ffdshow in both PC and enable ffdshow as the default direct-show decoder for output. The "ffdshow video decoder configuration" let you use "libavcodec" as decoder for Huffyuv format. By enabling libavcodec in ffdshow, I have found:


OK, I installed ffdshow and enabled ffdshow as the default direct-show decoder for output in HuffYUV.

This still gave me YV12 . SO I had to actually go to "ffdshow video decoder configuration" and in the output option I had to disable
YV12 as "supported output colorspaces". Now I finally get YUY2.
Of course I won't be able to output YV12 now but I don't really care about that.

I still don't understand why I had to disable it in order to get this result.

Wilbert:

I'm just gonna use ASF container to capture files but I will still use HuffYUV codec. This new pluging for IUVCR is the thing I will be using.

http://vlafy.iulabs.com/asfdirect.htm


The main advantage is that I will never have to worry about audio/video desync cause this thing will solve it. No need to resample audio dynamically. So this is the reason I need to use DSS function

[Si]

But how does it guarantee A/V sync?

Is there something special about the .asf format that allows video and audio clocks to be out of sync but be recorded to a common file?

I thought the iuVCR prog itself did synchronisation -so what does asf add to the game ? :confused:

regards

Simon

[numlock]

Originally posted by Si
But how does it guarantee A/V sync?

Is there something special about the .asf format that allows video and audio clocks to be out of sync but be recorded to a common file?

I thought the iuVCR prog itself did synchronisation -so what does asf add to the game ? :confused:

regards

Simon

I talked to the guy who makes iuVCR and he recommended me this ASF plugin. He say that by using ASF container all the sync issues go away. And the nice thing is that you can still use HuffYUV codec.

[kevinm]

Hi numlock,

I am a bit late joining this discussion but I stumbled upon it while desperately looking for help to resolve my audio sync issues. I too am using iuVCR and also I was told to use the ASF writer for iuVCR so that all my sync issues would go away .. they did not :-(

Yes, when the captured video was played in media player the sync was perfect but all attempts to encode in TMPGEnc have failed; the audio goes out of sync in the encoded mpg.

I am using DirectShowSource too, I am concerned about one of the previous posts mentioning that it is not available in the latest beta avisynth, better make sure I don't loose my current installation of avisynth!

BTW I have tried capturing using picvideo MJPEG 3 and Panasonic codec, both show the same sync problems.

I also (at the suggestion of the iuVCR guy) tried encoding using Mainconcept MPEG2 encoder and the audio sync was even worse.

I am at a brick wall right now, I was hoping the iuVCR developer would come up with some ideas but I don't know enough about this stuff to know if the problem is likely with the ASF from iuVCR or with avisynth or TMPGEnc.

Kevin

[Wilbert]

I am using DirectShowSource too, I am concerned about one of the previous posts mentioning that it is not available in the latest beta avisynth, better make sure I don't loose my current installation of avisynth!
It's always available in official alphas/betas.

Could you try to open the asf with

DirectShowSource("file.asf", fps=29.97, convertfps=true)

using latest beta3 and encode to something.

[kevinm]

Wilbert, thanks for the quick reply. I will certainly give that a try this evening,

Kevin

[kevinm]

Wilbert,

I tried the latest Beta3 last night (AVS 2.5.6 Beta3 [050505]), TMPGEnc got to about 1hr into the video and I got a memory read address error. I have never had this error before and I have used AVISynth many times with TMPGEnc so I assume it is probably related to this being a beta build.

Anyway, I was able to play the MPG ok in WinDVD but was not able to check the original point where I had been checking for sync previously (1hr 14sec) as it didn't encode that far, however I did find another point in the video where I was able to see that the audio was still delayed. Tonight I will try to measure the sync error but it looks to still be over half a second.

I will contact the author of iuVCR again to see if he can give me any more information on ASF and take a look again for possible reasons why taking a iuVCR created ASF and encoding to MPEG2 would cause the sync to go bad.

If you have any other ideas or suggestions please let me know,

Kevin

[Wilbert]

I tried the latest Beta3 last night (AVS 2.5.6 Beta3 [050505]), TMPGEnc got to about 1hr into the video and I got a memory read address error.
Just curious. Does it also crash with directshowsource.dll provided with avs v2.55 (using DirectShowSource("file.asf", fps=29.97))?

[kevinm]

I have used DirectShowSource on the same ASF using the 2.55 DLL with no crash, however for that run I did not use the 'fps' and 'convertfps' option.

Also, I dont suppose it makes any difference but I thought I should mention a couple of things:

The ASF from iuVCR is 25fps (therefore I used 'fps=25.00, convertfps=true'
The ASF from iuVCR was also deinterlaced by iuVCR during the capture

I have been performing the deinterlacing step in iuVCR as it saves me having to do it in avs, also it seems to do a decent job of it. (the reason I want it deinterlaced as this is what I have to pass to DGPullDown)

Kevin

[kevinm]

Wilbert,

I encoded the ASF last night using avs 2.5.5, there was no memory address error this time.

I had to comment out the 'convertfps' option as it was not recognized by 2.55 as a valid option for DirectShowSource, however I did leave the 'fps=25.00' in the script.

Unfortunately the encoded video had the same audio sync problem.

I am still waiting to hear from the iuVCR developer, I am still hoping that he finds something wrong with his ASF writer, although he will probably point out that it plays ok in Media Player so the problem must be with my encoder.

BTW, I have seen many posts about codec registering and people using 'gspot' and some 'graph' app to see what codecs are being used. I have no experience with this but if you have some document or thread you can point me to it might help. It would be good to check that avs is using the right decoder/codec. I will have a look at the TMPGEnc environment settings and try to turn off as many readers as possible to ensure DirectShowSource is using the correct reader.

(sorry if my terminology is all out of whack, I hope you understand what I am trying to say),

Kevin

[Wilbert]

I'm not able to duplicate it using short non-asf clips. Perhaps you can answer the following:

1) Does it only happen with asf files? Also with short asf files?
2) What's the duration of your asf file?
2) Does it happen at the same frame, or randomly (for the same clip)?
4) Does the crash also happen with VDub?

[kevinm]

Wilbert, thanks for trying to replicate the problem, to answer your questions ..


Q1) Does it only happen with asf files? Also with short asf files?

A/ If I use iuVCR to capture to AVI I observe the sync problem even before I encode it to MPEG2. (I observe the problem when played in WinDVD). I have not seen the problem in short clips but I since all I have been doing is copying camcorder tapes they are all around an hour and a half in length.

If I use the ASF writer in inVCR the ASF played in Media Player does not show any sync problem, but sync problem occurs in the MPEG encoded from that ASF.

Q2) What's the duration of your asf file?

A/ 1hr 16min

Q3) Does it happen at the same frame, or randomly (for the same clip)?

A/ For the event I have been analyzing the sync occurs at the same frame consistently.

I have been investigating a problem around 1h 14mins just because the event is easy to spot in both the video and the audio. I have also seen problems at 15mins and 28mins into the clip. I am not sure if the sync gets progressively worse, I am trying to figure that out now.


Q4) Does the crash also happen with VDub?

I have not used VDub other than to load the video to get the file information. I have since switched back to TMPGEnc 2.5.5 and do not see the crash. Maybe I should try that 2.5.6 Beta build of TMPGEnc again, problem is that it takes about 8hrs to get to the crash point.

Some more info on some experiments I have been doing ..

I loaded the ASF into VDub 1.3d, I wrote out WAV using direct stream. I played the audio in GoldWave, I measured the audio event to occur at the following point:

1hr 14min 40.813 sec

In VDub I measured the corresponding video event to occur at:

1hr 14min 40.240 sec

In VDub I previewed the ASF, the audio and video at the 1hr 14min 40.240 sec point is perfectly in sync!

In TMPGEnc the video event can also be seen at the 1hr 14min 40.240 sec, I can’t tell when the audio event occurs as preview in TMPGEnc doesn't play the audio.


So it seems to me that something may be going wrong with the demuxing of the video and audio. Is it possible that as soon as you demux the time tags provided in the ASF container get discarded?


Kevin

[Wilbert]

Regarding Q1 and Q3, I was asking about the crash (ie about the crash point, not the desync "point") :)

For clarity, using

DirectShowSource("file.asf", fps=29.97, convertfps=true)

is the only way to garantee sync. If you load the asf in some other way in AviSynth it will be out of sync (because asf is variable framerate video - at least i think).

[kevinm]

Wilbert,
sorry I misread your message before I understand now that it is essential for me to get it to run using 2.5.6 since I need to use all those switches with DirectShowSource. I will kick off another avs 2.5.6 run tonight.

Is it ok to use the very latest Beta or should I use a slightly earlier build?

Regarding ASF having variable framerate video ..

I have read that iuVCR deliberately adjusts the framerate in order to keep audio sync whilst not having to drop any frames. I also read that the ASF container was the way that time tags are added to the stream to maintain that sync. If you are saying that DirectShowSource must be used with those switches in order to handle variable framerate video then that may have been my problem all along.

fingers crossed I can get a build which doesn't crash.

BTW does is matter that I am encoding progressive material? If so, I can turn off the de-interlace filter in iuVCR and run it on regular interlaced material instead,

Kevin

[Wilbert]

Is it ok to use the very latest Beta or should I use a slightly earlier build?
You must use the latest beta (the convertfps option is not available in older builds).

(...) If you are saying that DirectShowSource must be used with those switches in order to handle variable framerate video then that may have been my problem all along.
Yup.

BTW does is matter that I am encoding progressive material?
No, that shouldn't matter. But personally i wouldn't use the deinterlacer filter in iuVCR.
I don't know that deinterlacer, but i assume that the ones available for AviSynth are better.

[kevinm]

Wilbert,

I have some more information for you ..

1. If I load the ASF directly into TMPGEnc and encode to MPEG2 that mpg has perfect audio sync! (I don't know why I didn't think of trying this before but I guess I assumed TMPGEnc couldn't read the ASF directly)

2. If I frameserve to TMPGEnc using AVS 2.5.5 the encoded mpeg has the sync problem

3. If I use 2.5.6 with 'DirectShowSource("file.asf", fps=25.00)' the encode completes ok but the sync problem still exists.

4. If I use 2.5.6 with 'DirectShowSource("file.asf", fps=25.00, convertfps=true) TMPGEnc crashes as soon as I try to load the AVS script. This crash is different to the problem I saw with the beta build the other day, that would encode 3/4 of the way through the video and stop in TMPGEnc with an addressing error. What have I done different this time? ....


a) I am using a new video clip, but it still uses the same iuVCR/ASF writer setup. It also uses the deinterlace filter in iuVCR (which actually does a pretty decent job IMHO)

b) in switching from 2.5.5 to 2.5.6 all I did was replace the dll in the windows/system32 directory with the dll from the 2.5.6 install which I did the other day. Is this a valid way of switching between versions or should I do an uninstall from control panel and install 2.5.6 using the installer?


Do you have any suggestions how I can help debug this crash problem with 2.5.6? It seems getting DirectShowSource to work correctly is the key to solving this sync problem,


Kevin

[Wilbert]

b) in switching from 2.5.5 to 2.5.6 all I did was replace the dll in the windows/system32 directory with the dll from the 2.5.6 install which I did the other day.
For clarity. It doesn't matter which AviSynth version you use. Only the directshowsource.dll version matters. You used the new directshowsource.dll right (the one you get when installing AviSynth v2.56b3)? Try this one (this one will be for v2.56b4):

http://www.geocities.com/wilbertdijkhof/DSS_060305.zip

Just put it in avs plugin folder.