Telecide() & Decimate() Accuracy

Support for my Avisynth filters
Post Reply
User avatar
Karyudo
Posts: 24
Joined: Tue Sep 21, 2010 11:47 am

Telecide() & Decimate() Accuracy

Post by Karyudo » Sat Nov 20, 2010 11: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:
Image

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?

User avatar
admin
Site Admin
Posts: 4002
Joined: Thu Sep 09, 2010 3:08 pm

Re: Telecide() & Decimate() Accuracy

Post by admin » Sun Nov 21, 2010 8:33 am

1. If it's 99% film, you should use Force Film mode rather than Telecide/Decimate. Assuming the flagging is accurate, that will not only solve your problem completely, but it will also be much faster.

2. I already use a windowed algorithm. Such small changes have always been a challenge for adaptive field matching.

3. Post an unprocessed source sample clip containing that frame and/or others that do not get matched properly.

User avatar
Karyudo
Posts: 24
Joined: Tue Sep 21, 2010 11:47 am

Re: Telecide() & Decimate() Accuracy

Post by Karyudo » Tue Nov 23, 2010 12:20 am

RE: Force Film
I never knew exactly how Force Film worked, so I had no idea it would be better or faster! I don't know how I missed that.

RE: Windowed Algorithm
Good to know I'm not an idiot for thinking up this way of adaptive field matching. Even better to know you've thought it up!

RE: Sample Clip
Before I post a sample, lemme tell you what I've experimented with, and the results.

I loaded up my .avs in VirtualDub, and there was no problem with the frame I posted! I tried it both with T/D and Force Film, and both methods produced a clean result. So I tried re-encoding from the beginning to just past this point with T/D by using Return=file.Trim(0,19500). Checked the result, and the broken frame was back! Tried again with FFilm, and it was gone! Now, to me that's an odd result: Virtual Dub parses the .avs / .dgi and does it right. MeGUI parses the same .avs / .dgi and gets it wrong??

I also tried encoding just this shot, and into the next one, total of 185 frames (presumably lots to get a representative encode?), by using Return=file.Trim(<non-zero number>,<non-zero number +184>. Both T/D and FFilm produced flawless output. From the exact same .avs that gave the interlaced result in the first case!

I thought this fiddling might prevent me from pursuing something stupid and wasting your time, but now I'll cut a sample and post it soon.

Finally, I watched DGIndexNV as it reindexed the first part of the film. The only reasons it didn't return 100% film seem to be because of (a) a few frames at the start, and (b) a few instances where hard-coded subs have been added (presumably after pulldown?). When the interlace-y frame comes up, it's 99.6% film. By the end of the movie, it's 99.91% film. So Force Film it is...

User avatar
admin
Site Admin
Posts: 4002
Joined: Thu Sep 09, 2010 3:08 pm

Re: Telecide() & Decimate() Accuracy

Post by admin » Tue Nov 23, 2010 8:49 am

I don't like to speculate on things without the sample clip, so I will wait for that.

User avatar
Karyudo
Posts: 24
Joined: Tue Sep 21, 2010 11:47 am

Re: Telecide() & Decimate() Accuracy

Post by Karyudo » Tue Nov 23, 2010 4:52 pm

Here are two 50 MB samples, cut from the original transport stream with DGSplit:

Start of the TS: http://www.mediafire.com/file/3d75sz5zp ... _clip_0.ts
Scene with the mismatch: http://www.mediafire.com/file/cqiezd97y ... clip_41.ts

User avatar
admin
Site Admin
Posts: 4002
Joined: Thu Sep 09, 2010 3:08 pm

Re: Telecide() & Decimate() Accuracy

Post by admin » Tue Nov 23, 2010 5:25 pm

Everything looks fine with force film, which is what you should be using.

The anomaly with T/D and MEGUI can be due to jumping around on the timeline, maybe MEGUI is doing some silliness with previews or something that causes Telecide() or Decimate() to see a frame history that is different from just loading and playing straight from the beginning.

User avatar
Karyudo
Posts: 24
Joined: Tue Sep 21, 2010 11:47 am

Re: Telecide() & Decimate() Accuracy

Post by Karyudo » Wed Nov 24, 2010 1:39 am

Here are two chunks of the same TS that contain something -- I'm almost certain it's the hard subs -- that makes the "% Film" drop.

http://www.mediafire.com/file/p7s7jysz2 ... clip_21.ts
http://www.mediafire.com/file/l8i3bbw3i ... clip_33.ts

Will these not mess with Force Film? How's that work (e.g. what's the fallback)?

I will be re-rendering using Force Film this weekend...

Post Reply