[MPlayer-users] show interlaced/progressive info..

[D Richard Felker III]

On Thu, Nov 13, 2003 at 08:08:28PM +0100, Matthias Wieser wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Am Donnerstag, 13. November 2003 19:03 schrieb D Richard Felker III:
> 
> > Even if the guessing part were acceptable, the decoding part isn't.
> > You can't go and decode a big block of video at startup just to print
> > information. It's way too costly in startup time and messes up the
> > flow of the program entirely (not to mention what happens if your
> > input isn't seekable!).
> 
> It could behave just like -vf cropdetect.
> 
> Then my mencoder script could terminate the no-deinterlace-mencoder and 
> start mencoder with -vf pp=xy.
> 
> > > because mplayer/mencoder can sometimes better guess if a video
> > > is interlaced than a human eye.
> >
> > It can? Would you care to show me how?
> 
> ;-) /s/can/could/
> 
> > BTW, you should always assume TV captures are interlaced unless you're
> > sure the original came from film or animation.
> 
> That's what I thought. But its not always true. Now I have a 2.3GByte 16:9 
> interlaced video which looks horrible. (mplayer [...]-vf pp=lb[...] helps 
> a bit...)

If it's from film or animation, then most likely some sort of pulldown
was applied, in which case you need to reverse this. Normally PAL is
2:2 pulldown, just sped up a bit, so it plays fine as progressive
video, but every once in a while some lame transfer studio does
2:2:2:2:2:2:2:2:2:2:2:3 pulldown to keep the speed exactly the same...
BTW, animation telecined for NTSC then converted to PAL without
remastering will be horrible no matter how it's done...

Rich