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

D Richard Felker III dalias at aerifal.cx
Fri Nov 14 02:23:43 CET 2003


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



More information about the MPlayer-users mailing list