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

[Andy Furniss]

Vicente Sendra wrote:
> --- El vie, 4/1/13, Andy Furniss <andyqos at ukfsn.org> escribió:
>
>> De: Andy Furniss <andyqos at ukfsn.org>
>> Asunto: Re: [MPlayer-dev-eng] [PATCH] Better double frame rate output and frame limit option.
>> Para: mplayer-dev-eng at mplayerhq.hu
>> CC: "Vicente Sendra" <visenri at yahoo.es>
>> Fecha: viernes, 4 de enero, 2013 13:29
>> Andy Furniss wrote:
>>
>>> I have yet to decide if the new options help or hinder
>> my use case of
>>> playing 50i deinterlaced on a 50Hz TV
>>
>> To follow on from this, how hard would it be to to implement
>> something that didn't really drop a frame which is sometimes
>> quite disruptive with h264, but just didn't display what had
>> been decoded in order to handle the case where clock drift
>> between video and sound means that video is slightly faster
>> than refresh?
>>
>>
>
>  From mplayer manual:
>
> −framedrop (also see −hardframedrop)
>
> Skip displaying some frames to maintain A/V sync on slow systems. Video filters are not applied to such frames. For B-frames even decoding is skipped completely.
>
>  From wikipedia:
>
> In older standard designs (such as MPEG-2), B-frames are never used as references for the prediction of other pictures.
>
> In H.264, may or may not be used as references for the decoding of other pictures (at the discretion of the encoder).
>
> So, as you said, in H264 normal framedrop (frame_dropping = 1) can be a problem, but only if B frames are used as references, can anyone tell us if decode_video() function skips only decoding of non referenced B frames with frame_dropping = 1.

Judging by the disruption and the logging of the decoder I would say 
referenced frames are dropped.

>
> Anyway, in the case you're testing (playing 50i deinterlaced on a 50Hz TV), if you use double frame rate deinterlacing (tfields or yadif) and new fpslimit option, only frames generated by these video filters should skip display step.
> As long as framedrop is triggered by fpslimit, the system will try to drop filter generated frames, only if this is not enough, normal frames will be dropped.
> This will result in no file decoded frames dropped.
>
> In conclussion, i think it behaves just the way you said.

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.

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.