[MPlayer-G2-dev] Re: requirements for vo2 layer

[Alban Bedel]

Hi D Richard Felker III,

on Wed, 7 Jan 2004 14:49:04 -0500 you wrote:

[...]
> * Simplification of query_format to a simple yes/no. VO's should never
>   perform colorspace conversion, software scaling, etc. Flipping is
>   just negative stride in G2, so it falls in the next point:
But what about hw conversion ? Often not all colorspace give the same speep.
Imho the driver should be able to "rate" the colorsapce in order to let
the caller know wich one is the fastest.

> * Report or negotiate pixel aspect ratio of the output picture. For
>   drivers without overlay which can change video mode, we might
>   actually want some way of negotiating a video mode to meet certain
>   size/aspect constraints.
What we rather want is: the physical aspect ratio of the screen and
all possible resolutions on this screen. This also imply a way to
set these videmode. Imho this should be, if possible, separated from
the vo drivers. All x drivers can use the same code, most console based
can use the fb modedb thing, etc
I think that it must be up to libvo2 user to query avaible video mode
and set a new mode before calling query_format, config, etc
An helper func wich auto select best video mode would be nice, but
libvo2 usurs must have 100% control over video mode selection if
they need to.

> * Exporting stride restrictions so the vo2 wrapper can negotiate
>   stride with the filter chain in hopes of getting DR to work. There
>   are actually 2 sets of stride restrictions: one for direct
>   rendering, and the other for all input images. The latter
>   restriction should _ONLY_ be in place if the VO driver does not
>   export its buffers, and requires some sort of slice or frame drawing
>   function to be called (svgalib?).
Also note that some vo can nearly provide any stride you want. It's the
case with tdfx_vid wich can use any stride > width (no negative stride).
Currently in libvo2 the driver have to choose the stride itself :(
If it knew what stride the last fliter want it could just provide it
most of the time.
However there are probably vo that will have different restrictions
for different colorspace.

[...]

> * A method to request oversized buffers with extra space (which can be
>   written with junk) outside the image dimensions. This allows panscan
>   style direct rendering through crop (and thus vf_panscan) and may be
>   needed for broken codecs which can't do edge emulation or which need
>   extra space to write when width or height % 16 != 0.
Yes, that sound like a very good idea. Basicaly what is needed is a
"visible area" area information. However i think that this info must also
be avaible at config time.

To resume i think that query_format should return :
 colorspace rating (0 = not supported 1-255 speed rating)
 flags (support oversized buffer, need aligned stride, etc)
 max visible width,height
 min,max strides

And config should get:
 colorspace
 src width, height
 visible width, height, x,y (only if oversized buf supported)
 src aspect (imho we should give aspect and helper funcs instead of
             d_width,d_height)
 desired strides  (the driver doesn't have to respect these)
 desired num_buff
 flags (fullscreen, etc)

	Albeu
-- 

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