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

[Andy Furniss]

Vicente Sendra wrote:

>> 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.

This works for my (limited) h264 HD ts testing with just -framedrop and 
blocking vo saving me from disruptive drops.

Testing an old mpeg2 transport stream I am seeing an initial pause with 
lavf/correct-pts - this happens with previous version of mplayer.c patch 
as well - I know there are mpeg2 correct pts issues mentioned elsewhere, 
but I haven't had time to re-read/test more yet.

My testing is on a setup without compositing - which may be atypical.

>
> 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:

On my box (4 x 3.4Ghz) ever getting anything that uses gpu and/or 
mmx/sse never seems to register as using full Cpu with top - and as a 
result cpufreq ondemand doesn't work well for these cases. I always have 
to set my cpus to perf if I want good behavior to save them constantly 
switching down to 800MHz.

What I am trying to say is that extra framedrops to save cpu doesn't 
appeal to me, as it seems that most of my frame drops are just down to 
blocking vo and not drift/running out of cpu.

I haven't seen/tested Dan's patches - maybe the way they do things works 
differently with blocking vo?

On the plus side for full screen I found that I can get gl to vsync and 
not block by using vblank_mode=0 and a radeon xorg.conf option 
SwapBuffersWait.