And found this:
![Image](http://img819.imageshack.us/img819/9836/theincredibles2004engco.jpg)
I'm pretty used to Telecide()/Decimate() being just about bulletproof, so I was pretty gutted.
I guess this is a case where so little changes between frames that the subtlety of a field mismatch is lost down there in the background noise of the vagaries of MPEG-2 encoding at broadcast bitrates?
I wonder if Telecide() could be improved for tough-to-call frame matches by doing a comparison on a grid basis, so that each frame below some "certainty threshold" is divided up into a series of small blocks, and each of the blocks is tested for matching? I would guess that encoding differences (noise?) would likely be more randomly distributed than field matching errors, so when looking at all the blocks on aggregate, I guess you'd expect to see a fairly wide, flat distribution of frame differences due to encoding. Not flat, of course (because you'd expect the encoder would have to work harder to allot bitrate to edges or smoke or whatever), but relatively evenly-distributed. If you were to look at frames with field mis-matches, however, the differences between no-motion blocks would just be due to encoding, but the blocks with field mismatches would show considerably greater differences. So, overall the differences between two frames might be below the matching threshold, but one might have a wide, flat distribution of differences in every block (e.g. properly matched fields), and another might have a slightly lower number of differences in most blocks, but significantly higher differences (e.g. improperly matched fields) in a few blocks. Thus for two frame matching options with the same average, single-value, difference threshold, the matching possibility with the lower peak difference would be the correctly-matched frame.
Or am I just an idiot who's using your tool incorrectly? What am I doing wrong? Without watching every frame of a given film like a hawk, how can I reliably boost the matching / IVTC?