x264's TDeint bug

[ncahammer]

This is a repost from http://doom10.org/index.php?topic=308.0
I was advised there that this is not an x264 bug, but TDeint

The repro follows :

http://www.mediafire.com/?o2y2mryndyk

This pack contains
Bug.demuxed.m2v, Bug.d2v : video and index generated by DGIndex
Bug.matches.log: Log of the first run of the VFR, contains the script and the output of avs2avi
Bug.matches.txt: TFM output of the above run
Bug.metrics.txt: TDecimate output of the above run, notice in the 2nd line of this the crc32 = b512bd84

Bug.avs: The final .avs, you need to change the paths for DGDecode.dll, TIVTC.dll and TDeint.dll to match to your system. Test it with avsp or VirualDubMod. It should open without any errors

x264_1400.cmd: Command that calls x264_x86_r1400_vanilla_icc_techouse.exe release, again change the path to yours
x264_1564.cmd: Command that calls the latest revision of x264

When I run x264_1400 I get

avs [info]: 1280x720p 321:320 @ 1406250/47047 fps (cfr)
x264 [info]: using SAR=321/320
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 Slow_mod4_stack
x264 [info]: profile High, level 5.0

The encoding starts without a problem

when I run the x264_1564, I get

avs [error]: TDecimate: crc32 in input file does not match that of the current clip (0xb512bd84 vs 0x39da6196)! (Bug.avs, line 8 )
x264 [error]: could not open input file `Bug.avs'

BugImages.avs: The same as Bug.avs but ImageWriter was placed just before TDecimate, you should change the directory where it saves the images. If you use this with x264_1400 and x264_1564 (instead of Bug.avs) and binary compare the first 10 images, you will notice that they differ

So according to the responses I got from there, it seems that TDeint behaves differently under x264_1564 (or any other x264 mingw's build )

[Vitaliy Gorbatenko]

This is a pure interlesed video - vfr mode no good for this. Best to use TempGaussMC deinterleser.

[ncahammer]

This sample it is, the whole video contains film parts. That's irrelevant for the issue, even the script

DGDecode_mpeg2source("Bug.d2v",idct=5)
TFM(pp=2, slow=2, clip2=TDeint())
TDecimate(mode=5, hybrid=2, VidDetect=2, hint=False, input="Bug.metrics.txt", mkvout="Bug.timecodes.txt")

is not the optimal for this video. That doesn't mean that I shouldn't be able to encode it, using the latest release of x264

[Vitaliy Gorbatenko]

You are right! But it quite ease to avoid.. - just make a quick encode to avi with lossless video codec (haffi or lagarith) through Virtualdub or virtualdubmod =)
In any way it's not a x264 fault.