[MPlayer-users] Re: inverse telecine... not

[D Richard Felker III]

On Wed, Feb 19, 2003 at 05:21:35PM -0800, Brian Craft wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> On Wed, Feb 19, 2003 at 05:37:53PM -0500, D Richard Felker III wrote:
> > I think I'll go ahead and commit it to CVS soon, but with the
> > understanding that it might change a good bit over the next few weeks,
> > including in ways that make it incompatible with old options syntax,
> > etc. That way users can actually test it and see if it works.
> 
> Very cool. I'll be curious to see how you approached it.
> 
> Reading up on it a bit, it's significantly more complex than I imagined. You
> can't expect the 3-2 pattern to be consistent throughout the entire video (for
> various reasons, including the possibility that the stream was edited after
> being telecined), so resyncing has to be done continuously. 

Yep. If you want to see the extent of the craziness, I'll upload the
opening of Serial Experiments Lain to MPHQ. That's what I tuned my
code for, and it's probably among the hardest things to inverse
telecine, since it's a digitally edited mix of telecined hand-drawn
animation and progressive 30fps computer graphics. (sometimes both in
the same frames, even!!)

> Apparently sync accuracy is a differentiating feature of hardware devices that
> do inverse telecine -- the poorer implementations may let a few interlaced
> frames through before resyncing, if there is a change in the pattern.

My code is paranoid in the opposite direction. If there are frames
that look interlaced but can't be synced to telecine, they'll most
likely get dropped. I've only seen three interlaced frames manage to
get through on all my tests.

> Seems like a hard thing to do quickly in software, since there are no markers
> on the interlaced frames -- the player has to "look" at the frame and decide
> if it's interlaced.

Yeah. :( I've worked out some good metrics for detecting interlacing,
but it's still not working as well as I'd like. It shouldn't be *that*
hard to detect ugliness that a human can spot so trivially... :))

> I was thinking it might be possible to make a telecine table of a file prior to
> playback, in the event that the pattern changed. Then the player wouldn't have
> to detect it on-the-fly, but would just look up the pattern changes based on
> frame count.

Well, I have a plan even better than that, once I implement my 2pass
code. The first pass will detect telecined frames and write a file
that the second pass can use to decide which frames to merge or drop.
However, it won't just use frame numbers; it'll also store hashes
based on part of each frame, to use in resyncing after seeking. This
will make it so you can watch your telecined DVD's without having to
reencode first (although playback will be sort of choppy still since
every 4th frame will be shown for twice as long).

Rich