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

Vicente Sendra visenri at yahoo.es
Sat Jan 5 00:56:13 CET 2013


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

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.



More information about the MPlayer-dev-eng mailing list