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

[D Richard Felker III]

On Fri, Feb 21, 2003 at 04:57:59PM -0500, mplayer at interlinx.bc.ca wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]

> On Fri, Feb 21, 2003 at 11:15:21AM -0500, D Richard Felker III wrote:
> > 
> > Yes, and because your -vo sucks. With a vo that syncs to vertical
> > retrace,
> 
> Perhaps we are not talking about the same thing.  But I suspect we
> are.  I am saying that dfbmga does (or rather can -- I dunno if it's
> in the official mplayer version of dfbmga or not) sync to vertical
> retrace.  i.e. vo_dfbmga.c on my working mplayer here does a:
> 
>      vo_flags |= 0x100;
> 
> in it's preinit().  And mplayer.c does this:
> 
> //============================== SLEEP: ===================================
> 
> time_frame/=playback_speed;
> 
> // flag 256 means: libvo driver does its timing (dvb card)
> if(time_frame>0.001 && !(vo_flags&256)){
> 
> #ifdef HAVE_RTC
>     if(rtc_fd>=0){
> ...
>     } else
> #endif
>     {
>     // -------- USLEEP + SOFTSLEEP -----------
> ...
>     }
> 
> }
> 
> If that's not what you mean by a vo driver syncing to vertical
> retrace, what do you mean?

I actually mean a more intelligent interrupt-based approach. I have no
idea how dfb does it...

> > you'll at least see the extra frame for one refresh period.
> 
> But if mplayer is only producing 4 frames where it should be producing
> 5 (3 reguarlar "progressive" frames plus two interlaced/telecined
> frames), then only 4 will display, no?

It IS producing 5, but one of them is only 'visible' for maybe less
than 5% of a refresh period.

> > If you're using DXR3, I would imagine you'd get nice smooth perfect
> > 29.97 fps output.
> 
> I am testing the 3:2 pulldown by using "-fps 1" on my workstation in
> an Xvideo window and counting the number of good looking frames vs.
> interlaced frames and it's 3 normal 2then 1 interlaced then 3 then
> 1...  

-fps 1 will not do ANYTHING to help you see the extra frame, since it
controls the rate at which mplayer decodes them, not the rate at which
they get displayed. vf_telecine calls vf_next_put_image twice in a
row, with NO DELAY in between, since it can't control the delay. Only
if the vo driver somehow prevents the second frame from being
displayed immediately after the first will you see two frames!

In short, you CANNOT test vf_telecine with mplayer unless you use -vo
(x)mga or a hardware mpeg board! Use mencoder instead (or perhaps -vo
mpegpes).

Rich