Re: [?] hit 3 flies - aspect ratio, resize, query_format

On Monday 15 September 2003 18:35, D Richard Felker III wrote:
> On Mon, Sep 15, 2003 at 04:15:20PM +0200, Felix Buenemann wrote:
> > On Friday 22 August 2003 21:48, Arpi wrote:
[...Arpis proposal...]
> > hmm, I see something missing here: Where do you account for the
> > aspect-discrepancy of Screen-Resolution-Aspect vs.
> > Physical-Displaydevice-Aspect. Eg. think of the case where displaying
> > video at 1280x1024 on a 4:3 19" CRT, which is a very common case. In this
> > case we have to do slight aspect correction in order to retain correct
> > aspect ratio.
>
> The vo simply sets the wanted display width/height based on monitor
> aspect and disp_w/disp_h from filters. No problem there. However IMO
> this whole system where window resizes propagate back through the
> filter chain is a very very bad idea. Consider the following example
> filter chains:
>
> 1) scale=480:480,(deinterlace/ivtc)
>
> If the user resizes the window, Arpi's proposal would have the first
> scale filter get reconfigured for the new output size! If any vertical
> resizing takes place, this will ruin the deinterlacing!!
>
> 2) rgb codec => scale,denoise3d
>
> If user resizes the window, the scale filter will resize the image
> before denoising rather than just converting colorspace! This will
> ruin the denoising process.
>
> I'm sure there are more examples too. In all these cases, the basic
> problem is the same -- when resizes propagate back through the filter
> chain, the video gets resized at the wrong point, and the output is
> wrong. It's a similar problem to how mencoder skips frames at the
> beginning of the filterchain rather than at the end. IMO any final
> preparation for display like this needs to be done at the very end of
> the filter chain. I'd even suggest putting swscaler support in vf_vo2
> rather than loading a filter for window resizing. That way the filter
> chain doesn't have to be aware of any silly resize signals. IIRC Arpi
> also considered putting swscaler in vf_vo2 when we were talking about
> it on IRC.

You are totally right, scaling at the wrong point in the chain can mess uo 
things badly. I, too, think it's a good idea to put a scaler in the video out 
filter.

> > Another place is TV-Out, often the display-area from the graphics card
> > doesn't fill the whole visible area of the TV's CRT, so that there are
> > black areas above and below (sometimes also at the sides). With mplayer
> > G1 id'd simply
>
> This means your TVout is horribly misconfigured! Try changing the
> timings (with Matrox, sync pulse length is used to control the black
> border size when in TV mode, so it may be similar on other cards).
> I've never seen a card which forces black borders when used on
> windows, so if you're getting black borders, I really do expect a
> driver/configuration problem, not a fundamental limit of the hardware.
Oh, I'm not talking about vanilla ice graphics cards, I'm talking about shit 
hardware, like Savage/MX Chip (my laptop), or Gefore 4 MX on Windows with 
cheapo TV-Codec (the one in a friends PC).

>
> Rich
>

-- 
Best Regards,
        Atmos
____________________________________________
- MPlayer Developer - http://mplayerhq.hu/ -
____________________________________________