Telecide() & Decimate() Accuracy
Posted: Sat Nov 20, 2010 10:32 pm
Ran an HDTV capture through DGIndexNV (which found it better than 99% film). Set correct field order using AssumeTFF()/SeparateFields(). Used Telecide(guide=1) and Decimate(cycle=5) to get 24 fps (well, 23.976 fps). Checked hundreds of frames to confirm all was well. Spend a long time doing some custom masking of hard subtitles using AviSynth. Rendered for the better part of a day to get glorious high-bitrate, OAR, 1080p video. Muxed in audio. Then sat back and played the file, to pat myself on the back for how awesome I am.
And found this:
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?
And found this:
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?