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

[Vicente Sendra]

--- El lun, 25/2/13, Dan Oscarsson <Dan.Oscarsson at tieto.com> escribió:

> De: Dan Oscarsson <Dan.Oscarsson at tieto.com>
> Asunto: Re: [MPlayer-dev-eng] [PATCH] Better double frame rate output and frame limit option.
> Para: mplayer-dev-eng at mplayerhq.hu
> Fecha: lunes, 25 de febrero, 2013 10:41
> sön 2013-02-24 klockan 21:22 +0000
> skrev Vicente Sendra:
> > > I looked at this when adding my patches (will
> check your
> > > patches soon
> > > and compare to mine - my patches use pts for
> timing and
> > > schedules frame
> > > display to best vsync (works with vdpau)). 
> > 
> > > As soon as I have some time I will have a deeper
> look at
> > > your patches
> > > and see how they work together with mine.
> > 
> > 
> > Any progress on this?
> 
> Sorry, I have not had time.
> 
> I think you also had problem with some VO that waits until a
> vsync
> before returning, just like I had (and fixed in vdpau).
> Maybe it could
> be time to discuss if we should do some change in mplayer so
> that a vo
> should not hang until a vsync occurs. Both vlc and xbmc uses
> threads and
> works well. Why not add threads to mplayer allowing both
> demuxing and
> output to be in threads som more things could be done in
> parallell and
> idling on cpu waiting for for example a vsync could be
> avoided?
> 
>    Dan

I totally agree with you, but as long as frame timing control remains in mplayer main function, my patches should work with that new system.

I think my patches can work right now and get better with a threaded system.


As i said in a previous mail, my patches do a lot more than just solve the problem with blocking VO (because of waiting to vsync). There are improvements in frame drop logic, frame timing  (for generated frames) and new functionality for deinterlacing filters (adds enable control).
 

--- On 18/12/12, Vicente Sendra <visenri at yahoo.es> escribió:

> ////////////////////////////////////////
>     New fpslimit option
> ////////////////////////////////////////
> 
> The new option fpslimit has this syntax:
>  
> -fpslimit <option1:option2..>
> 
>  -options:
>   mode=<0 .. 2>
>     working mode, 
>     0(default) disables frame limit
>     1 fixed frame limit
>     2 automatic frame limit detection
>   fastdrop=<0.0 .. 10.0>
>     makes some extra drops if > 0
>   min=<value>
>     lower limit for fps (set to max in mode 1)
>   max=<value>
>     upper limit for fps
>   start=<value>
>     starting limit for fps (set to max in mode 1)
> 
> In mode 1 the system simply drops frames trying to limit
> output frame rate to specified value ("max").
> 
> In mode 2 the system calculates a max frame rate based on
> vflip time.
> Roughly speaking, it lowers max frame rate if vflip time
> gets big, and raises frame rate if if vflip time is low and
> video frame rate is higher than max frame rate.
> ("min" and "max" options limit the calculated value, and
> "start" sets the initial value, if not specified or 0, no
> limits are applied. If "start" is not set a value is
> calculated from video frame rate and average frame rate
> output).
> It takes a few seconds to get the right value.
> 
> Fastdrop reacts in a fast way to vflip time, triggering
> extra frame drops, it makes the system react faster, highly
> recommended for either mode 1 or 2, makes fps limit
> precision (specified or calculated) less important.
> Higher values trigger a frame drop faster, normaly should be
> 
> set to 1.
> 
> Mode 1 can be used in all vo drivers, but must be used for
> vo drivers where vflip generates a wait in almost all
> frames
> (vsync enabled, but no buffering), mode 2 would drop lots
> of
> frames. Also, for these drivers, fastdrop option must not
> be
> used.
> 
> Example (no buffering) : -fpslimit mode=1:max=60
> Example (with buffering):-fpslimit mode=1:fastdrop=1:max=60
> (fastdrop is optional, but recommended)
> 
> Mode 2 should be used for vo drivers that do not delay
> vflip
> to next vertical refresh (vsync enabled, but buffering
> allows to return immediately).
> 
> Example (no buffering) : do not use
> Example (with buffering):-fpslimit mode=2:fastdrop=1:max=60
> (fastdrop is optional, but recommended)
> 
>  
> ////////////////////////////////////////
>     New framedrop logic
> ////////////////////////////////////////
>  
> -Works even with no sound.
> -Drops frames by sync or fpslimit.
> -Works for all frames, read and interpolated (created by
> vf)
> 
> ////////////////////////////////////////
>     New double frame rate output
> ////////////////////////////////////////
>  
> -Accurate timing for frames created by video filters
> 
>  In correct-pts mode frame time is set by video filter.
>  to make this work video filter needs to know video frame 
>  time, this is supplied by new control option:
>  VFCTRL_SET_FRAMETIME.
>  
>  In normal mode frame time is calculated taking into
> account
>  the number of frames created by video filter(s) and video 
>  frame time. (vf_num_queued_frames function returns number 
>  of frames created for each read frame).
>  
>  In both modes, filters that add frames always queue them
>  (previously this only happened in correct-pts mode).
>  
>  Changes were needed in decode_video function(dec_video.c) 
>  to avoid the message:
>  "Too many buffered pts"
>  This happens with vanilla mplayer.
>  When framedropping dropped some frames, pts values
> accumulated
>  in the buffer.
>  
> ////////////////////////////////////////
>     Filter yadif compatible with new double frame
> rate output
> ////////////////////////////////////////
> 
> Added internal field: buffered_frametime
> Added handling of VFCTRL_SET_FRAMETIME
> 
> ////////////////////////////////////////
>     Filter tfields compatible with new double
> frame rate output
> ////////////////////////////////////////
>   
> - vf_tfields.c
> 
> Added internal fields: buffered_frametime, do_deinterlace
> Added control function
> Added handling of :
> VFCTRL_SET_FRAMETIME, VFCTRL_GET_DEINTERLACE,
> VFCTRL_SET_DEINTERLACE
> Added mode 5 for this filter, like mode 1, but just skips
> filtering
> 
> VFCTRL_SET_DEINTERLACE is only allowed in mode 1,5.
> A question here: can the filter configuration (video output
> size) be changed on the fly, so we can allow this in all
> modes?.



We just need to make it work with vdpau, as i said, i think it can be done quite easily:

--- On 18/12/12, Vicente Sendra <visenri at yahoo.es> escribió:

> I'm taking a look at vo_vdpau.c and it seems it has the same
> problem that was present in tfields and yadiff, it calls
> flip_page with no timing in function
> video_to_output_surface().
> 
> New option fpslimit is not going to work as expected with
> this VO, it will detect a frame limit equal to real frame
> limit/2, and it will drop frames in pairs, because main loop
> will process full frames, not fields (as it's done now in
> tfields and yadiff).
> 
> I need to study it deeper, but i think it can be done.
> 
> Call stack for one frame (2 fields) is something like this
> (deinterlace mode):
> 
>  filter_video
>   -draw_image
>    --video_to_output_surface
>     ---flip_page
>  flip_page
> 
> We have to avoid ---flip_page and queue a frame like in
> tfields and yadiff, then modify video_to_output_surface to
> output just one field on each call.
> New call stack should be something like this:
>  
>  (field 1)
>  filter_video
>   -draw_image
>    --video_to_output_surface
>     ---vf_queue_frame
>  flip_page
> 
>  (field 2)
>  vf_output_queued_frame
>    -video_to_output_surface
>  flip_page
> 
> vf_queue_frame should handle both frames queued from vo
> (vo_vdpau) and vf (tfields, yadif)
> same applies to vf_output_queued_frame.