Re: pre34 & vf/vo resize problem

Hi Arpi,

on Sun, 13 Jul 2003 01:23:04 +0200 you wrote:

> and introducing yet another problem for discussion, mayeb you have
> better ideas than me:
> 
> 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 ??

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

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

	Albeu
-- 

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