It's not another adaptor. I lets you copy video surfaces
rendered with an existing XvMC adaptor into a GLXPbuffer. It's
possible to both display in the overlay and save off to a
Pbuffer.
A while ago, I started getting inquiries from a couple film
companies who store their rendered animated features as jpegs.
They decompress them in software and copy them into textures
so they can do post processing on them in OpenGL. I think mostly
they're interested in doing things like adding film grain and
doing color correction. The software decode is really a significant
expense if you're trying to do 1920x1080 sized jpegs in real time.
Unfortunately, I don't think the quality of 4:2:0 video is really
is up their standards, but there are lower quality applications such
as HDTV and DVD post processing that can benefit from accelerated
decode of mpeg streams into an OpenGL drawable. There are probably
some interesting multimedia projects as well.
Mark.
On Sun, 1 Jun 2003, Alex Deucher wrote:
> Just curious, as I'm not too familiar with XvMC yet, but would this
> provide another Xv adapter that used the 3D texture engine to display
> videos rather than othe video overlay? or something else. Sorry for
> my ignorance.
>
> Thanks,
>
> Alex
>
> --- Mark Vojkovich <[EMAIL PROTECTED]> 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.
> >
> >
> > 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
> > );
> >
> > 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.
> >
> > "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.
> >
> > 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?
> >
> >
> > Mark.
> >
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> http://calendar.yahoo.com
> _______________________________________________
> Devel mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/devel
>
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
