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

[D Richard Felker III]

On Thu, Jan 08, 2004 at 01:08:23PM +0100, Alban Bedel wrote:
> 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.

Does this case really exist? I've never heard of it. Usually the
conversion is done in the driver, not the hardware, and this is slow
so it shouldn't be supported.

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

It's still part of the vo driver. If the vo driver wants to call
generic code from x11_helper, that's fine.

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

This is nonsense. You have no idea what video mode you want until the
filter chain starts configuring.

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

No problem. The caller (vp layer) decides the stride it wants based on
the source and destination's stride restrictions. Then it will
configure the vo for the selected stride.

> However there are probably vo that will have different restrictions
> for different colorspace.

This is annoying, but not necessarily a critical problem.

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

Of course. _EVERYTHING_ about the image passing is determined at
config time. Dimensions, stride, borders, colorspace, SAR, ... This is
one of the main differences from G1.

> 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

I don't like querying everything at once. Ultimately the only things
you absolutely _need_ to know when configuring are (a) supported
colorspace and (b) whether there's an absolute stride restriction
(only happens when buffers are indirect). All the other queries are
only needed for direct rendering.

I still haven't decided exactly how query and config should work,
though... :(

> And config should get:
>  colorspace
>  src width, height
>  visible width, height, x,y (only if oversized buf supported)

This is ugly, or at least very different from how vp will work. It
will have width, height, and 4 border sizes (top, bottom, left,
right). But I don't really care if vo is done differently since we get
to wrap it anyway.

>  src aspect (imho we should give aspect and helper funcs instead of
>              d_width,d_height)

Of course. We use sample (pixel) aspect, not hideous d_width/d_height
stuff like G1.

>  desired strides  (the driver doesn't have to respect these)

Yes it does (under certain conditions, at least), but the desired
stride is guaranteed to be something the vo agreed to support already.
That's why we negotiate strides in advance.

>  desired num_buff

This is never known. :(
Very unfortunate, but I don't see any way we can possibly know it.
Maybe force each vp node (decoders and filters) to report how many
buffers they'll need at config time? This would be very helpful, but
might be impossible for some! Or at least very very difficult to guess
correctly...

>  flags (fullscreen, etc)

This is irrelevant to the filter chain. It should be configured some
other way.

Rich