On Fri, 30 May 2003, Ian Romanick wrote: > Mark Vojkovich wrote: > > I'd like to propose adding a XvMCCopySurfaceToGLXPbuffer function > > to XvMC. I have implemented this in NVIDIA's binary drivers and > > am able to do full framerate HDTV video textures on the higher end > > GeForce4 MX cards by using glCopyTexSubImage2D to copy the Pbuffer > > contents into a texture. > > This shoulds like a good candidate for a GLX extension. I've been > wondering when someone would suggest somthing like this. :) Although, I > did expect it to come from someone doing video capture work first.
I wanted to avoid something from the GLX side. Introducing the concept of an XFree86 video extension buffer to GLX seemed like a hard sell. Introducting a well establish GLX drawable type to XvMC seemed more reasonable. > > Over the years there have been a couple extensions for doing things > this, both from SGI. They both work by streaming video data into a new > type of GLX drawable and use that to source pixel / texel data. > > http://oss.sgi.com/projects/ogl-sample/registry/SGIX/video_source.txt > http://oss.sgi.com/projects/ogl-sample/registry/SGIX/dmbuffer.txt > > The function that you're suggesting here is a clear break from that. I > don't think that's a bad thing. I suspect that you designed it this way > so that the implementation would not have to live in the GLX subsystem > or in the 3D driver, correct? That was one of the goals. I generally view trying to bind a video-specific buffer to an OpenGL buffer as a bad idea since they always end up as second class. While there have been implementations that could use video buffers as textures, etc... they've always had serious limitations like the inability to have mipmaps, or repeat, or limited filtering ability or other disapointing things that people are sad to learn about. I opted instead for an explicit copy from a video-specific surface to a first-class OpenGL drawable. Being able to do HDTV video textures on a P4 1.2 Gig PC with a $100 video card has show this to be a reasonable tradeoff. > > With slightly closer integration between XvMC and the 3D driver, we > ought to be able to do something along those lines. Basically, bind a > XvMCSurface to a pbuffer. Then, each time a new frame of video is > rendered the pbuffer would be automatically updated. Given the way the > XvMC works, I'm not sure how well that would work, though. I'll have to > think on it some more. Mpeg frames are displayed in a different order than they are rendered. It's best if the decoder has full control over what goes where and when. > > > Status > > XvMCCopySurfaceToGLXPbuffer ( > > Display *display, > > XvMCSurface *surface, > > XID pbuffer_id, > > short src_x, > > short src_y, > > unsigned short width, > > unsigned short height, > > short dst_x, > > short dst_y, > > int flags > > ); > > One quick comment. Don't use 'short', use 'int'. On every existing and > future platform that we're likely to care about the shorts will take up > as much space as an int on the stack anyway, and slower / larger / more > instructions will need to be used to access them. This is an X-window extension. It's limited to the signed 16 bit coordinate system like the X-window system itself, all of Xlib and the rest of XvMC. > > > This function copies the rectangle specified by src_x, src_y, width, > > and height from the XvMCSurface denoted by "surface" to offset dst_x, dst_y > > within the pbuffer identified by its GLXPbuffer XID "pbuffer_id". > > Note that while the src_x, src_y are in XvMC's standard left-handed > > coordinate system and specify the upper left hand corner of the > > rectangle, dst_x and dst_y are in OpenGL's right-handed coordinate > > system and denote the lower left hand corner of the destination > > rectangle in the pbuffer. > > This conceptually concerns me. Mixing coordinate systems is usually a > bad call, and is likely to confuse developers. I assume this means that > the image is implicitly inverted? Hmm... X is left handed. OpenGL is right handed. Addressing a pbuffer in anything other than a right handed coordinate system is perverse. Mixed coordinate systems seems a necessity here. There is no inversion, it's just a remap of the origins. > > > "Flags" may be XVMC_TOP_FIELD, XVMC_BOTTOM_FIELD or XVMC_FRAME_PICTURE. > > If flags is not XVMC_FRAME_PICTURE, the src_y and height are in field > > coordinates, not frame. That is, the total copyable height is half > > the height of the XvMCSurface. > > > > XvMCCopySurfaceToGLXPbuffer does not return until the copy to the > > pbuffer has completed. XvMCCopySurfaceToGLXPbuffer is pipelined > > with XvMCRenderSurface so no explicit synchronization between > > XvMCRenderSurface and XvMCCopySurfaceToGLXPbuffer is needed. > > > > The pbuffer must be of type GLX_RGBA, and the destination of the > > copy is the left front buffer of the pbuffer. Success is returned > > if no error occured, the error code is returned otherwise. > > This goes against common practice. The copy should obey the setting of > glDrawBuffer. I assume you must have had some reason for doing this...I > just can't imagine what it was. :) The glDrawBuffer has nothing to do with the Pbuffer. It is part of OpenGL context, not the Pbuffer. XvMC has no knowlege of internal OpenGL context state. Mark. > > > Possible Errors: > > > > XvMCBadSurface - The surface is invalid. > > > > BadDrawable - The pbuffer_id is not a valid pbuffer. > > > > BadMatch - The pbuffer is not of type GLX_RGBA or the > > pbuffer does not have a front left buffer. > > > > XvMCCopySurfaceToGLXPbuffer is supported if the following flag: > > > > #define XVMC_COPY_TO_PBUFFER 0x00000010 > > > > is set in the XvMCSurfaceInfo's flags field. > > > > I'd like to bump the API version up to 1.1 and add this. > > Comments? > > _______________________________________________ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
