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

[Alban Bedel]

Hi Arpi,

on Sun, 13 Jul 2003 16:26:49 +0200 you wrote:

> Hi,
> 
> > > there are several vo drivers without scaling ability.
> > > (and there are some with limited scaling, left them for now).
> > > in g1 we included swscaler support in all of them to workaround
> > > this. of course it isn't acceptable in g2.
> > > i found 2 ways to solve:
> > > 1. simple, g1-like but cleaner method: include swscaler support into
> > >    vf_vo2, the vf->vo wrapper. so if it receives scaling request,
> > >    but vo is not capable of scaling, it will use swscaler instead of
> > >    memcpy. advantages: easy to implement, less errors possible
> > >    disadvantage: doesnt use filters, so even if there is scale in
> > >    the
> > >      filter path, it wont be used but yet another swscaler.
> > >      (vf_scale right before vf_vo2 may be workarounded by ugly
> > >      hacks)
> > > 2. complex but very interesting solution:
> > >    add controls to filters changing size and/or aspect to convert
> > >    between src/dst sizes (both direction).
> > >    so when the user resizes the window to X*Y, this control would be
> > >    launched from vd to get the resulting image sized to X*Y.
> > >    Ok it isnt so simple to implement, imho you need at least 2
> > >    controls: one to calculate the d_width/d_height for first vf to
> > >    get X*Y at the end of filter path, and one to setup
> > >    scaling/resizing in filters.(maybe the second one can be (shoudl
> > >    be?) replaced by config() re-call?) advantages: utilizes
> > >    vfilters. allows not only scaling, but for example crop/expand
> > >    and other resizing filters to be used to change window size. Can
> > >    use scale before other filters, for example-vop
> > >    expand=0:-100,scale will scale the iamge up when you resize the
> > >    window, but always keep the constant 100 pixel height black band
> > >    under the image for the subtitles. disadvantages: very complex,
> > >    requires new/extra code in many vf_*
> > > 
> > > any better idea?
> > > or ideas how to implement 2. ?
> > > (my control/config method is even too complex to describe here...
> > > i'm thinking on it for 2 days already, but always find new problems)
> > I'm not sure if i understood everything, so feel free to try to
> > explain more, that wolud be nice :)
> > 
> > Imho the problem with 2. is that the control call go in the wrong
> > direction. Shouldn't the call for resize be done on vf_vo2 and then
> > have it (if needed) go back in the chain until it meet a filter
> > capable of resizing ??
> 
> yes
> 
> > I know that it's not really possible atm to have some call to go up
> > in the filter chain. But in such case it make a lot more sense i
> > think.
> 
> actually you can do it (tricky), and i meant the control above this way.
> 
> control(int* p){
> 	call_next_control(p)
>         do something with p[] values
> }
> 
> so you can start teh control from the top, it will call down to the
> bottom(vf_vo2) filter and then returns the values up to the caller
> through all teh filters so they can alter the values.
> 
> > Allthought it's possible to have the control first pass the call down
> > in the chain to see if another filter (wich is later in the chain) can
> 
> yes i mean the same
> 
> > do it. With such method it would also be possible for the user (via
> > filter options) to set a filter as the "resizer" so the resize is
> > not necessarily done by the last scale filter (or is done by expand,
> > etc).
> 
> yes, i also planned such resize/noresize flags for such filters
> for example, filter 'expand' by default would do automatic resizing,
> but if you give it relative sizes (like expand=-1:-100) it disables
> resizing by default andlet other filters to do it.
> normally the last filter capable to resize (including vo via vf_vo2)
> would do it.
That would be really nice.

> 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
considering that you said you were thinking on that for 2 days.

> > 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 speak from my g1 experience, so this may be somewhat different in g2.
Anyway this kind of issues is unimportant atm.

> > What about having a control to set new size, so vo like x11 can
> > optimize the resize case a bit. But if the vo doesn't support the
> > control then we fallback on config().
> 
> i wonder what can you optimize in vo_x11, at least in vo2 when teh only
> thing that config() does is allocating buffer.
> (actually even buffer allocation can be moved out of config to
> get_buffer)
I just took x11 bcs it can't scale. I really have to look at libvo2
it sound so nice :)
	Albeu
-- 

Everything is controlled by a small evil group
to which, unfortunately, no one we know belongs.