RFC: video with DRI2

[Corbin Simpson]

If I recall correctly, DRI2 can transport VDPAU and there is some
libvdpau stuff in the Mesa/Gallium source tree. I haven't really been
heavily involved, but I would imagine that that might be interesting
to you.

~ C.

On Wed, Jul 20, 2011 at 3:15 PM, Rob Clark <robdclark at gmail.com> wrote:
> All,
>
> I've been looking a bit at dri2 as a way to handle video display (in
> addition to just GL stuff).  Basically it seems like a convenient way
> to share buffer handles between Xorg driver and client video player
> app.  (Yes, I know about Xv.. no, it isn't useful if I want to avoid a
> memcpy.)
>
> The basic differences compared to some 3d/gl app:
> 1) color format..  video content would (most likely) be in some YUV
> format.  No problem for DRI2GetBuffersWithFormat, passing a fourcc as
> the 'format' value seems sane.
>
> 2) attachment points.. for GL you might triple or double buffer.  For
> video you might have >16 buffers.  This mostly seems ok, most of the
> existing dri2.c code seems like it would tolerate me requesting
> non-existing attachment points.  The one bit of awkwardness is that
> DRI2SwapBuffers doesn't let me specify *which* buffers I want to swap.
>  Maybe I could cope by playing some games by changing buffer name to
> buffer object mappings.  The tricky thing to keep in mind is that in
> the video case the buffers would be displayed in a seemingly random
> (to the xorg driver) order, if B-frames are present..  decode order !=
> display order
>
> 3) cropping.. in case you are actually trying to share buffers without
> copy between video codec and Xorg, you probably have some codec edges
> that need to be cropped out.  So you need some way to request buffers
> larger than the target drawable, and specify some x,y offset into that
> larger buffer to find what should appear on screen.  In some cases it
> might even be that the x,y offset is changing frame by frame.
>
>
> Some of these issues go away if you do a blit/colorconvert on client
> side into the DRI2 buffer.  This seems to be what intel vaapi driver
> (and probably others) are doing currently.  Although my ideal goal is
> to push this to xorg side, and let xorg driver decide whether to blit,
> or use an overlay, etc.
>
>
> The approaches I can think of to deal with this are:
> 1) add DRI2Get/SetProperty sort of messages.  Some things like
> cropping offsets and perhaps actual requested buffers sizes could be
> set as properties.  There are some things that are a bit iff'y about
> this.  For example, changing crop should apply on the next
> SwapBuffers.  The good news is it would be easy to later define new
> properties as the need arises.
>
> 2) Add additional parameters to GetBuffers and SwapBuffers
>
> 3) Define some new msgs with extra parameters...
> DRI2GetBufferWithFormatAndMore, etc.
>
>
> Anyone have some opinions on the best approach to take?  Anyone else
> given some thought to this sort of thing before?
>
>
>
> BR,
> -R
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>



-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude at gmail.com>