[MPlayer-G2-dev] [?] hit 3 flies - aspect ratio, resize, query_format

[D Richard Felker III]

On Mon, Sep 15, 2003 at 04:15:20PM +0200, Felix Buenemann wrote:
> On Friday 22 August 2003 21:48, Arpi wrote:
> > I would extend vf's query_format() by a int p[6] parameter.
> > (actually int* size, which points to an array of 6 integers)
> > these 6 values are:
> >
> > buff_w, buff_h  -  w/h of the image buffer (real pixels)
> > disp_w, disp_h  -  pre-scaled w/h (recommended display size)  [for startup]
> > want_w, want_h  -  wanted output size [for window resizing]
> >
> >
> > query_format() of 'normal' filters (which dont alter aspect ratio nor
> > buffer size) would just pass thru the pointer to next filter.
> > other filters shoudl implement it this way:
> > query_format(...){
> >       - change buff_w/h  (only filters which chaneg buffer dimensios)
> >       - change disp_w/h  (only filters which change aspect ratio)
> >       - call next filter's query_format()
> >       - change want_w/h  (only filters which change buffer dimensios)
> > }
> 
> 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.

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

> > also, the scaling flags of vfcap.h shoudl be reviewed: merging HSWSCALE_UP
> > and HWSCALE_DOWN, it ha sno sence to keep them separated.
> > query_format() implementations can now check source and dest resolution so
> > can decide if sw/hw scaling is possible or not. if they can do the scaling
> > (or resize), they should change the want_w/h values. otherwise left
> > unchanged.
> hmm, I'm not sure about this. The bad thing about eg. XV is that you can tell 
> it to scale down in most cases but then if the adapter can't do it, it'll 
> simply crop away part of the image to get the desired size. So the idea was 
> to be able to specify if the card can do hw downsizing/upsizing using the 
> selected vo, so we can downsize/upsize by swscaler if needed whilst using the 
> faster hw scaler for upscaling/downscaling. But maybe I misunderstood you 
> Arpi.

I think you just misunderstood. Arpi was saying that config would just
return failure for scaling down, if the card didn't support it, rather
than using a flag.

Rich