AVI is IVTC'd differently than previewed AVS

[ExarKun634]

I don't know if this is the correct forum in which to post a thread for my question, so move this thread if I have made a bad decision.

I am encoding an HDTV source:
1920x1088
29.97fps Telecined

I am using the following script:LoadPlugin("D:\programs\avisynth\DGDecode.dll")
LoadPlugin("D:\programs\avisynth\Decomb.dll")
#LoadPlugin("D:\programs\avisynth\UnDot.dll")

MPEG2Source("my.d2v")

#AssumeTFF().SeparateFields()

Telecide(order=1,guide=0,post=0)
Decimate(cycle=5)

#UnDot()

Crop(0,0,1920,1080)
BicubicResize(1280,720)I am using the latest stable versions of DGMPGDec (1.4.0), Decomb (5.2.1), AviSynth (2.55), and XviD (1.0.3), and I have tried both VirtualDub 1.5.10 and VirtualDub 1.6.10. I have also tried setting guide=1 in Telecide. The result is the same every time.

I load the AviSynth script into VirtualDub, and the preview looks just fine. I can't make it show an interlaced frame, no matter where I move the position slider, so I assume that Decomb is doing its job perfectly. I encode the video using XviD, and the resulting AVI (both first pass and second pass AVIs) has interlaced frames everywhere. It is not a pattern, but there are quite a few. I have looked at specific frames in the previewed AVS versus the encoded AVI in VirtualDub, and they are IVTC'd differently. If the frames were interlaced in both the preview and the output, then I would just turn on post-processing in the Telecide function, but they are not. Maybe I just haven't noticed it, but I don't think I have ever had this problem before, and I haven't changed the versions of any software since the last time I encoded a video. What is the deal? Is there any way to make the input for encoding be exactly what I see when I preview the AVS in VirtualDub, frame for frame?

What makes it even more frustrating is that the video takes a day and a half to encode each pass due to its length and resolution and my 3-year-old processor. (VirtualDub 1.6.10 shortened the time. It was over 2 days per pass using 1.5.10.)

[Guest]

Please try again with DGMPGDec 1.4.1 beta 5. I recently corrected a similar problem reported to me on my forum by holden. It was caused by bad error recovery for some kinds of video stream errors.

http://neuron2.net/dgmpgdec/dgmpgdec141b5.zip

Please advise on your results. If this does not solve your problem I will ask you to provide a VOB. Thank you.

[ExarKun634]

I am attempting an encode now. I will post the results when the first pass is done, since it has been obvious even at that point.

The source is a 20GB transport stream, so I don't know how I would get it to you without altering it.

EDIT: Thanks for replying. I am very pleased with prompt and relevant answers, especially from such a definitive source.

[Guest]

Please also tell me what, if any, video errors are reported by DGIndex.

[ExarKun634]

Please also tell me what, if any, video errors are reported by DGIndex.I have uploaded the relevant files to your FTP. The file is called exar-dgfiles.rar. Included are the original D2Vs, parse.txt, fix.txt, and changed D2Vs from both 1.4.0 and 1.4.1b5.

81% through the first pass. It is taking a while because I am playing games and doing other processing too.

[ExarKun634]

1.4.1 beta 5 worked like a charm. The video looks beautiful. Thanks again. Let me know if you need any other files for beta-testing purposes.

[ExarKun634]

I guess I spoke too soon. 1.4.1 beta 5 has introduced audio/video desynch similar to what I experienced when encoding HDTV content with the 1.3.x series. I will try 1.4.1 beta 6.

[Guest]

I suggest waiting for my next beta 7. I'm revamping the slice processing and error recovery. I've completed it successfully for DGIndex and am now applying it to DGDecode. It solves the outstanding stream problems that have been reported to me.

[Guest]

Version 1.4.1 beta 7 is now available. There shouldn't be any problems with the video. If you are having an AV sync issue please start a new thread in the DVD2AVI/DGIndex forum.