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

[Alban Bedel]

Hi D Richard Felker III,

on Thu, 8 Jan 2004 22:56:40 -0500 you wrote:

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

3dfx stuff have such colorspace converters on board. 1 YUV planar -> packed
and 1 YUV packed -> RGB. They are heavily used by tdfxfb and tdfx_vid.

> Usually the conversion is done in the driver, not the hardware, and this
> is slow so it shouldn't be supported.

ROTF ??? are you proposing that i rewrite vo_tdfx_vid so it use sw converter
in the driver instead of the hw converters ? That probably make things
a lot faster !!!

BTW, this rating i'm proposing should not be taken so seriously. I'm just
thinking that it would be nice if the user could "easily" tell wich is
the fastest colorspace a given vo support.

> > > * 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 was more thinking along the line of a "video mode" driver to allow
a single API for video mode query/setting while avoiding duplicate code.

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

Right. But what i was thinking about is that most limits that a vo may
have (stride, visible area, etc) will in most case depend on the
selected video mode and colorspace. Or taken the other way aroud:
it will be hard for a vo to give it's stride restrictions without
knowing in wich resolution/colorspace it will run.

And that's only resolution. Now if you change display depth you may
also change the avaible colorspace too :(

I think that we must assume the following to be safe with most hw:
 - each video mode support a number of colorspace.
 - in each video mode, each colorspace have it's own restrictions.

This mean that you can know the restriction only when you choosed
a video mode. What i proposed is the simplest: first set the mode
then query restriction. It make driver implementation easy.
I agree it would be better if one could query restrictions without
really setting the video mode. But it make implementation in drivers
a bit harder and for some hw you probably have no other way than
setting the mode at least once to get the limits :(

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

Well, the colorspace imply the bitdepth wich imply how many buffer
you may use, how big they can be (bcs of stride limit), etc
When i think about nice overlay chip i don't think it's a big problem.
But when a start to think about some shitty vga hw ... i fear ;)

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

Personaly i don't like to implement too many query stuff.
Again as restrictions depend on colorspace it made sense for me to put
that together.

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

That's why i was doing some proposition ;)

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

How fields are named is smthg i don't care about, as long as the information
is there in some form or another ;)
Imho it should be the same as in vp (or vp the same as vo ;)

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

Imvho drivers should work even if the given stride is invalid. So users
who don't care can just set it to 0.

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

I really understand that in vp it's near to impossible to know. Anyway
i thought that as a hint only. It should just give the vo a "good number"
to start with. In mplayer the default value would 2 or 3, smtg a la
mplayer-xp would would set it to 20 or more.

> >  flags (fullscreen, etc)
> 
> This is irrelevant to the filter chain. It should be configured some
> other way.
We are talking about libvo2, aren't we ? At least I am ;)
	Albeu

-- 

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