[MPlayer-dev-eng] [PATCH] Better double frame rate output and frame limit option.

[Vicente Sendra]

--- El dom, 6/1/13, Vicente Sendra <visenri at yahoo.es> escribió:
> > > I suppose I would need something like
> -softframedrop
> > with
> > > liberal limits of some drift against audio sync
> > followed by
> > > initially at least droping VOUT rather than
> making
> > decoder
> > > drop useful frames.
> > 
> > Maybe i can modify it to drop generated frames in an
> hybrid
> > mode, for example, start dropping some generated frames
> if
> > delay is bigger than 0.05s, this way it will kick in
> before
> > decoded frames are dropped (at 0.1s). This way it would
> work
> > around 0.05s of delay dropping a generated frame every
> now
> > and then.
> > I think this can't generate any problem, so it can be
> done
> > always, even if no fpslimit option is used (only
> framedrop
> > option).
> > I have to do some tests to see how regular is the
> dropping
> > of generated frames with this behaviour.
> 
> An additional note, hybrid mode without fpslimit option will
> make the cpu work almost at 100% as vanilla mplayer does
> when framerate is very close to refresh rate.


I did it (it's just a small change in check_framedrop function) and tested with good results.

changed this:
-----------------------------------------------------
    // interpolated frames, only drop by fps limit
    if(drop_vout > 0)
        drop_frame = frame_dropping;
-----------------------------------------------------
by this:
-----------------------------------------------------
    // interpolated frames, drop preferentially by fps limit
    if(drop_vout > 0){
        drop_frame = frame_dropping;
    }else{
        if(d < - 0.050) // start dropping interpolated frames before we drop normal frames
            drop_frame = frame_dropping;
    }
-----------------------------------------------------


These are the results of testing a 29.970fps video with yadif=1 on a 60hz display with buffered vo and vsync:

no frames dropped by SYNC, all drops by VOUT:
-framedrop -fpslimit mode=2:fastdrop=1:min=50:max=61
38 dropped frames ~60% cpu use

some frames dropped by SYNC:
-framedrop -fpslimit mode=1:fastdrop=0:min=50:max=59.5
45 dropped frames ~70% cpu use

all frames dropped by SYNC:
-framedrop -fpslimit mode=0
30 dropped frames 100% cpu use

In any case only dropped interpolated frames.

The last two modes are the ones you should try if you have trouble with mode=2 (no buffering).

with no buffering you must use mode 1 or disable it (mode 0).

With mode=1 you have to set "max" to  a value lower than screen refresh rate. Lower it if you get "DROPPED NEW FRAME by SYNC" or too many "DROPPED INT. FRAME by SYNC" and a high cpu usage, raise it to get less  "DROPPED INT. FRAME by VOUT".

With mode=0 you get the lowest count of frames dropped but you get 100% cpu usage, but should work with any vo.

Attached full patch over .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer.c.diff
Type: application/octet-stream
Size: 47655 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20130107/74f036fb/attachment-0001.obj>