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

[Vicente Sendra]

--- El dom, 6/1/13, Vicente Sendra <visenri at yahoo.es> escribió:

> De: Vicente Sendra <visenri at yahoo.es>
> Asunto: Re: [MPlayer-dev-eng] [PATCH] Better double frame rate output and frame limit option.
> Para: mplayer-dev-eng at mplayerhq.hu
> Fecha: domingo, 6 de enero, 2013 22:34
> --- 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.


Sorry, when i say 0.2s i mean 0.1s, and where i say 0.1s should be 0.05s.

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.