On Wed, Jul 20, 2011 at 11:26 PM, Younes Manton <[email protected]> wrote: > On Wed, Jul 20, 2011 at 11:40 PM, Rob Clark <[email protected]> wrote: >> On Wed, Jul 20, 2011 at 5:53 PM, Younes Manton <[email protected]> wrote: >>> On Wed, Jul 20, 2011 at 6:28 PM, Corbin Simpson >>> <[email protected]> wrote: >>>> On Wed, Jul 20, 2011 at 3:15 PM, Rob Clark <[email protected]> wrote: >>>>> >>>>> Anyone have some opinions on the best approach to take? Anyone else >>>>> given some thought to this sort of thing before? >>>>> >>>> >>>> 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. >>>> >>> >>> The code in mesa does everything client side since overlays are pretty >>> much extinct so doesn't really have a need for any of this, although >>> more control over the swap chain might be useful. >>> >> >> yeah, and therein lies the challenge.. ;-) >> >> I'm dealing with smaller embedded devices (ie. that runs off >> batteries) where overlays are actually useful from power/efficiency >> standpoint. But at same time video decode hw has some requirements >> that normal shmem allocated buffers don't meet so Xv is not terribly >> helpful. The aspect of DRI2 of just getting a GEM buffer handle >> shared between xorg and client is 90% of what I need. >> >> BR, >> -R >> > > Understood. Since you mentioned the need for 16 buffers, B frames, > zero-copy, etc, it seems these frames are not only for display but > also ref frames. Doesn't that mean you actually a couple of other > things as well?
yup.. all things that could be stuffed behind some properties, I suppose, or if extending existing msgs a handful of additional fields are needed. > 1. Not just cropping and larger buffers but actually buffer sizes that > are independent of the drawable's size and an interface that can > specify any mapping of buffer -> drawable and some notion of a > background color to cropping/scaling up/scaling down? Or are decoded > frames guaranteed to be drawable-sized + a bit extra at the edges? scaling is important, so you are right.. we need an input size in addition to output (drawable) size. > 2. A way to specify a standard for color conversion, or preferably, an > arbitrary matrix? Or are you thinking a single fixed standard? I was just thinking to use a fourcc as the 'format' value.. that would be a good start. Having some way to specify a property to indicate vc1 range-mapping parameters would help.. > 3. Some kind of OSD (i.e. compositing, with both YUV and RGB surfaces) > support? Or is that not required? > yeah, but that is getting a couple steps ahead.. although an additional attachment point for OSD to be overlayed over the video is the approach I'm thinking of BR, -R _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
