[MPlayer-G2-dev] Re: pre34 & vf/vo resize problem

Arpi arpi at thot.banki.hu
Sun Jul 13 21:56:28 CEST 2003


Hi,

> > the question is how to do the actual impelmentation.
> > you have the wanted dwidth/dheight at the vo (so the resized window's
> > new width/height) and you have to send a (or 2) control through teh
> > filter layer to get them reconfigured for this new desitination size.
> > i'm interested in sample/pshedo code, my ideas are overcomplicated :(
> It is complex but we'll make it  !!!
:)

> Basiclly afaiu it should work like this :
> 
>  - The app get a resize event from the vo (optional)
>  - The app call vf_resize(..., d_width,d_height)
>     - vf_resize check that the chain is really capable of resize
>     - Call the resize control on the first filter.
>  - The control call reach a resize capable filter (let say scale).
>     - The filter pass the control to the next filter to see if some
>       other filter can do it.
>     - The filter setup itself to now output in d_width x d_height size.
>     - Call config(....,d_width,d_height,d_width,d_height,..) on
>       the next filter to setup the following filters with the new size.
> 
> Ok it's too simple ;) So i probably overlooked a lot of stuff

Yes, i would say that you missed the step of d_width/d_height altering
filters, like rotate, relative expand, frame<->field converters etc.

But maybe you're right, I was on wrong step, it all can be done in oen step
maybe, some psuecode:

// expand=-1:-100
resize(vf,int* p){
    if(vf_resize_next(vf->next,p)==VF_TRUE) return VF_TRUE;
    if(we_do_resize){
        vf->priv->exp_w=p[0];
        vf->priv->exp_h=p[1];
        vf->config(vf,vf->priv->w,vf->priv->h,vf->priv->exp_w,vf->priv->exp_h);
        return VF_TRUE; // we do resizing
    } else {
        // tell the upper filters to resize to d_width x d_height-100
        // so we can provide d_width x d_height-100+100 images
        p[1]-=100;
        return VF_FALSE;
    }
}

// rotate:
resize(vf,int* p){
    if(vf_resize_next(vf->next,p)==VF_TRUE) return VF_TRUE;
    swap(p[0],p[1]);
    return VF_FALSE;
}

(of course there will be no new vf->resize() but a control for this)


> considering that you said you were thinking on that for 2 days.

it does mean nothing, it seems :)

> > > However, i don't know if using config() to setup a new size is a so
> > > good idea regarding the vo's. For filters it's allright but for in the
> > > case of vo's, config() will often setup some buffer, etc.
> > 
> > but when you only have to config() when the vo isnt capable of resizing,
> > and then it really have to resize (reallocate) the buffers so its' o kto
> > call it, imho. although vo drivers should support multiple config()
> > calls, and do optimizations based on changed parameters.
> That's my point. This multiple config call is alredy not so easy to
> implement. So if you have also to take in account that sometimes
> this call is used only for resize then it's even worse.

I'll release pre35 today, pelase check vo_xv and vo_x11, the config()
is less than 5 lines of code...
actually it does near nothing, just creates GC for the window if not yet done
and saves the new w/h to the vo struct.
(buffer creation/releasing is done in get/release_buffer(), X11 init in
preinit())

> I speak from my g1 experience, so this may be somewhat different in g2.

there is really BIG difference between g1's libvo and g2's libvo2
(but it also means that porting g1 vo drivers to g2 is a lots of work
and actually means rewrite from scratch)

> Anyway this kind of issues is unimportant atm.

agree


A'rpi / Astral & ESP-team

--
Developer of MPlayer G2, the Movie Framework for all - http://www.MPlayerHQ.hu



More information about the MPlayer-G2-dev mailing list