[MEncoder-users] Automating telecined/interlaced detection

[Scott Fones]

On Sun, 2006-09-03 at 10:59 -0400, Rich Felker wrote:
> I dunno what's wrong but your email message has atrociously bad
> formatting. It's very hard to read.

Yeah, I don't have the slightest clue.  I wrote it with evolution, like
every other email...hopefully this one turns out better.

> That pattern should appear at least somewhere if the content is 3:2
> telecine, but it won't appear everywhere because there simply is no
> pattern to see during still shots and some kinds of low-motion. 12 fps
> content will also fail to show up exactly like that, and a good deal
> of animation is 12 fps in many parts.
> 
> And of course you also have other things like 24->25 fps conversion
> for PAL which sometimes uses a form of telecine, but if you're just
> processing NTSC you won't see that.

Thanks, that's great to know.  What I plan on doing:  Find out the
framerate.  If its all 24fps, then just treat it as progressive.  If it
comes back 30fps or mixed, I'll send it through another check, looking
for the 3:2 duration pattern.  If it finds it anywhere, I'm just
assuming its either all telecined or mixed telecined.  If not, I'm
treating it as all interlaced or mixed interlaced.  Hopefully, that will
work :/
         
> >         A:   2.3 V:   2.3 A-V:  0.000 ct:  0.065  56/ 53  6% 13% 19.7% 0
> >         0 80%
> >         affinity: .0+.1.+2..3+
> >         breaks:   |0..1..2|.3.
> >         duration: 3
> >         A:   2.4 V:   2.4 A-V:  0.001 ct:  0.066  57/ 54  6% 13% 19.6% 0
> >         0 79%
> >         affinity: .0++1..2+.3.
> >         breaks:   .0..1.|2..3.
> >         duration: 2
> 
> This looks like the same pattern to me. What is different?

Yeah...this was a terrible example.  I just used the first file I came
to and it happened to turn out this way.  I was only wanting to use it
as a generality.  Dumb luck it turned out that way.

> The important thing to realize is that this pattern is nothing
> _inherently_ stored in the video. The filter is forced to examine the
> visual contents of the fields and make a best guess about how they
> match. The output from pullup is representing these guesses: the
> second | in:
> 
>          affinity: .0+.1.+2..3+
>          breaks:   |0..1..2|.3.
> 
> indicates that because field 0 and 2 are much more similar than 1 and
> 3, 0,1,2 probably all come from the same original picture. The + signs
> indicate that a field 'preferrs' one of its neighbors over the other
> in the sense that the other neighbor would give a significantly worse
> appearance of combing.
> 
> Whether this data is useful or sufficient for distinguishing
> interlaced and telecined content, I dunno. I just wrote the verbose
> output for debugging pullup's behavior on strange content so I could
> see why it makes the decisions it does.
> 
> Rich

Thanks a ton!  This really helped me out.

Scott