[MPlayer-users] will mplayer do a 3:2 pulldown on 24 fps video when ofps=29.97?

[D Richard Felker III]

On Thu, Feb 20, 2003 at 07:47:58PM -0500, mplayer at interlinx.bc.ca wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]

> On Thu, Feb 20, 2003 at 03:02:29PM -0800, Brian Craft wrote:
> > 
> > Yeah, this really is an on-going problem. The xp fork is too far behind to be
> > useful.
> 
> I was thinking about taking a look at it again due to this problem,
> but maybe not.
> 
> > It's unfortunate that threading wasn't maintained as a patch -- like
> > other notable oss projects that were too intrusive or controversial (low
> > latency patches, uml, etc.), it could have remained relevant that way.
> 
> I guess the problem was that it was so intrusive that keeping up with
> the mplayer moving target was difficult.  But indeed, there are gains
> to threading to be sure.
> 
> Like the case of dfbmga.  It's possible to sync mplayer's processing
> of frames to the clock of the output device simply by having the vo
> driver wait for the vsync from the television/video card.  But having
> it wait and having mplayer decode frames all in the same thread does
> not work on machines it should work on because too much of the
> needed decoding time is spend sleeping for the vsync interrupt.

Sleeping for vsync is a brain damaged approach. Instead, you should
inform the video driver (which belongs in the kernel) which page you
want selected next time vblank occurs, and the kernel should trap the
interrupt and switch pages for you. (This of course requires triple
buffering, but you need that for the threaded approach too.) mga_vid
already does this. Like I've said, the api is in fbcon too, but it's
not implemented by any drivers.


> > Video filters can't tell what the framerate is, and anyway, it's
> > possible someone might want to use 3:2 pulldown for any 20% framerate
> > increase, not just 23.976->29.97.
> 
> Right.  And somebody that does want to do that can specify -vop
> telecine.  But what I am proposing is that mplayer see that -ofps was
> set to "ntsc" and then examine the input rate of the video.  If it's
> 29.97 fps, do nothing, if it's 23.976, automatically insert the
> telecine filter.

Hmm, on second thought, fps is probably a global variable... :|

So, it should be possible to make a the telecine filter accept some
sort of 'auto' parameter to control whether it auto-activates
according to framerates. This definitely does not belong inside -ofps
handling, though.

> > For a PVR, you really should run mplayer -info or whatever in advance
> > to get the stream parameters, then use these to configure the second
> > run.
> 
> That is an idea, indeed.  But having mplayer be more intuitive on it's
> own is a good thing.
> 
> BTW:  I couldn't seem to find (at first glance) an option to just get
> a stream's parameters.  I will look deeper in a bit.

Ah, it's called -identify!

Rich