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

[Vicente Sendra]

--- El dom, 6/1/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: domingo, 6 de enero, 2013 14:21
> lör 2013-01-05 klockan 01:24 +0000
> skrev Vicente Sendra:
> > > Being able to field step is nice, is it possible
> to
> > > implement the same 
> > > for vdpau:deint=2 ?
> 
> > Any Ideas?, suggestions are welcome.
> 
> 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)). 

These are the goals of my patches:

-Lower cpu usage (with vanilla mplayer cpu usage rises to 100% when frame rate get closer to video card refresh rate with vsync enabled).

-Get correct timing of frames generated by filters in all modes (with vanilla mplayer, this is only done in correct-pts mode), this is why my patches always use queued frames in all vf that add frames, correcting pts if necessary, taking into account original frame time.

I think we are going in the same direction.


>As my patches do
> frame
> scheduling in mplayer core I would have to add to the
> protocol to call
> vo code to handle deinterlacing code working inside vo. So I
> did not fix
> it. Though, as my patches add code to vdpau that makes the
> vo drop
> frames when to many frames are queued for display, it should
> work quite
> well for hardware deinterlacing when display refresh rate is
> around
> double the frame rate. As vdpau displays frames on vsync,
> extra
> deinterlaced frames will be shown at next vsync and my code
> will drop
> frames if there are to many queued.  I could do better
> if I expanded the
> protocol taking to the vo, but I wanted to avoid that as it
> is difficult
> enough to get things accepted in mplayer.


I've been thinking about a generic solution for any vo that adds frames like vdpau, that will work exactly as the other vf do with my patches.

in vf_vo.c, we should add a check at the end of the function "put_image"
to check if vo has added a frame.


video_out->control(VOCTRL_GET_FRAME_ADDED,&frame_added);

if(frame_added){
    vf_queue_frame(vf, continue_buffered_image);
}

in vf_vo.c add a function continue_buffered_image (like the other filters) to handle the processing of the queued frame.

static int continue_buffered_image(struct vf_instance *vf)
{
    video_out->control(VOCTRL_DRAW_FRAME_ADDED,&frame_added);
}


like in my patches for vf_yadif and vf_tfields:
 -add hanling of  VFCTRL_SET_FRAMETIME for correct-pts calculations
 -update pts in "put_image", taking into account frame time and queued frames.


In the affected vo, in this case, vo_vdpau.c, we should add a field to store the value of frame_added, let's call it "frame_added".

Set "frame_added" to 1 when we handle VOCTRL_DRAW_IMAGE if double frame rate deinterlacing mode is set.

Add handling for VOCTRL_GET_FRAME_ADDED
- just get "frame_added" field

Add handling for VOCTRL_DRAW_FRAME_ADDED
- draw the queued frame
- reset "frame_added" field




> As soon as I have some time I will have a deeper look at
> your patches
> and see how they work together with mine.

Can i have a look at your's.

I can't test any of these modifications, i have a computer with linux installed with an nvidia card, but it's too old (ti4200), and does not support vdpau, i have another one with a fx5200, but i would have to install linux and dev tools on it, and currently i'm using it for other things.