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

[Arpi]

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.

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 :(

> 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.

> 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)


A'rpi / Astral & ESP-team

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