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

[Andy Furniss]

Vicente Sendra wrote:

>> Well in the case of gl + vsync and vdpau +tfields (yadif
>> uses a bit too much CPU on HD), I can't use fastdrop and so
>> don't see any DROPPED INT. FRAME by VOUT.
>>
>> For R600 specific reasons I wouldn't normally use xv. It is
>> faster (probably on my set up because it uses memcopy rather
>> than blits in gallium), but the way it gets vsync (waits for
>> hline out of picture) and a current regression which means
>> it doesn't seem to sync with the right screen even though
>> you can specify make it not very useful. It also requires
>> -nodouble with mplayer to avoid getting buffers reversed
>> when you push to display rate.
>>
>> Saying all that, for a short test on a single full screen it
>> can do OK/better than gl/vdpau - but using fastdrop doesn't
>> save me from any DROPPED NEW FRAME by SYNC, but I guess
>> because of the stricter timing adds a few DROPPED INT. FRAME
>> by VOUT on top of what I see with just -framedrop.
>>
>
> If you get 0.2s of delay between audio and video, it's going to drop decoded frames, framedropping because of A-V sync just behaves as vanilla mplayer.
>
> What i was trying to explain is:
>
> You can't use vdpau vo with integrated deinterlacer in combination with new fpslimit option and expect it to drop fields, because mplayer main loop currently has no control over fields generated by vdpau.

Yea, I got that, what I refer to above is vdpau + tfields.