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

[Vicente Sendra]

--- El dom, 6/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: domingo, 6 de enero, 2013 14:03
> 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.
> 

Well this is something that should be fixed in the decoder, they should not be dropped if frame_dropping = 1, only hardframedrop should do that.

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

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.

If you use xv or gl without vblank_mode=2 and the filters tfields or yadiff you are going to get what you want, only some "DROPPED INT. FRAME
> by VOUT" if you use -fpslimit mode=2:fastdrop=1:max=50.

Even with gl without vblank_mode=2 (or any other vo that delays always flip to next vsync, that is, no buffering) you can use mode 1 with no fastdrop: -fpslimit mode=1:fastdrop=0:max=49.8.
But you have to set max to some value a little lower than actual refresh rate (with 49.8 you drop a frame every 250 frames at 50hz). You can raise it until you get some "DROPPED NEW FRAME by SYNC".

> 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.1s, this way it will kick in before decoded frames are dropped (at 0.2s). This way it would work around 0.1s 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.