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

Arpi arpi at thot.banki.hu
Fri Aug 22 21:48:58 CEST 2003


Hi,

I'm trying to solve several design issues/problems/ideas around the
image size, including the bypassing buffer size to vo driver in
query_format, aspect ratio handling in vf layer, cleanup of VFCTRL_RESIZE.

After several hours of analyzing ideas, i'm still in doubt, but here
is what i found out the best:  feel free to tell me better solutions
or point out possible problems with this method!

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

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.


actually buff_* and disp_* are the current w/h pairs passed in vf->config().

buff-* is the real (phisical) size of the buffer, ignoring any kind of apect
ratios. it's originally the width/height of the movie, altered by filters
which change the buffer dimensions (so scale, crop, expand, rotate).

disp_* are the scaled (by movie aspect, and aspect changes by filters)
dimensions. this can be used to get the final aspect ratio at the end (vo).
if we put the prescale dmovei size into it at the top, we'll get the
recommended display window size. it's useful for startup, before the window
created.

want_* are the values from current VFCTRL_RESIZE. it's the wanted output
size (values of disp_* at the end of chain, ie. at vo). it's useful when
the user resized the window by mouse, or switched to fullscreen. we can
calculate dimenstions backward. value of want_* may be 0 (or -1?), in this
case the final values of disp_* will be copied at the end of chain (vf_vo2).


I would also change config() of vf layer.
The second w/h pair (d_width/h_height) will be the wanted w/h.
config() functions shouldn't change it.
But the filters which are able to do some kind of resizing, should call
query_format of next filter from config(), to check if the rest of the
filter chain is able to fulfill the resizing request (to wanted w/h),
and do it otherwise.


Ok, I see (know) this sounds very complex. But at least quite easy to
implement (but a big work, mostly testing and discovering hidden
side-effects and tricks used in current filters).
Also it affects special (size/aspect changig) filters only, so only a few.
(the rest should be changed to byupass new parameter of query_format, but it
has rto be done anyway to solve vo->query_format problem (some vo supports
some colorspaces only at limited size range, same for scaling)

Comments?


A'rpi / Astral & ESP-team

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



More information about the MPlayer-G2-dev mailing list