XvShmPutImage with XDraw commands
I am using XvShmPutImage to draw video via a YUV overlay into a window. Then I am using XDraw commands to draw "overlays" directly to the window (lines, arcs, text, etc.). When I do this the video image appears correctly, but the overlays do not update properly. Each time the overlays move, the old XDraw data remains along with the new, until I do something to force an exposure on the drawable - such as drag a window over it. Then the window is redrawn with only the new XDraw data drawn over the video image ("new" meaning from XDraw calls made since the last XvShmPutImage call) which is what I wanted. I don't seem to be able to force the XServer to re-expose the window via software, or I would find that an acceptable workaround. Is there something I am not understanding? I have seen this same behavior both on a Matrox G550 and an nVidia Quadro 4 card, so I don't believe it has anything to do with the particular graphics card drivers. Thanks in advance, Steve Thrash
XvShmPutImage with XDraw commands
I am using XvShmPutImage to draw video via a YUV overlay on an nVidia Quadro 4 XGL card (PNY 580 XGL). I then do an XSync() to make sure that the video is completely drawn before continuing. I am having a problem where the video is sometimes not keeping up. I am drawing a 1280x960 image and have noticed that the first 14-16 draws take about 22 ms, and all subsequent ones take about 9-10 ms. The timing starts before the XvShmPutImage and ends after the XSync. Sometimes after switching video windows around a few times, I get into a state where the draws get slow again and stay that way indefinitely. The input rate of the data does not seem to be a factor - I tried lowering it from 30 FPS to 10 FPS and got the same results. Trying XvPutImage didn't help either. I get the same problem if I switch to the blitter, rather than the overlay port. I DO NOT get the problem however if I blit RGB data instead of YUV. Does anybody have any idea what is going on and if there is some way to get around this? I am kind of dead in the water right now. Thanks in advance, Steve Thrash P.S. On a related note, does anybody know what the XV_ITURBT_709 attribute does?
Re: XvShmPutImage with XDraw commands
--Original Message Text--- From: Steve Thrash Date: Wed, 12 Nov 2003 13:09:01 -0500 I am using XvShmPutImage to draw video via a YUV overlay into a window. Then I am using XDraw commands to draw "overlays" directly to the window (lines, arcs, text, etc.). When I do this the video image appears correctly, but the overlays do not update properly. Each time the overlays move, the old XDraw data remains along with the new, until I do something to force an exposure on the drawable - such as drag a window over it. Then the window is redrawn with only the new XDraw data drawn over the video image ("new" meaning from XDraw calls made since the last XvShmPutImage call) which is what I wanted. I don't seem to be able to force the XServer to re-expose the window via software, or I would find that an acceptable workaround. Is there something I am not understanding? I have seen this same behavior both on a Matrox G550 and an nVidia Quadro 4 card, so I don't believe it has anything to do with the particular graphics card drivers. I'm not sure why this should be a surprise to you. When you use an overlay, the on-screen window gets solid filled with a chromakey color. If you draw something over the top of the chromakey fill, those somethings will be visible until either you erase them, by restoring the chromakey, or you force an expose event, which tells xvideo to fill with the chromakey again. This is working by design. If the chromakey refilled with every overlay update, it would be impossible to draw anything over a running movie. -- - Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc.
RE: XvShmPutImage with XDraw commands
Sorry, I'm kind of new to Xv. That makes perfect sense. Is there a way to force the expose event at the server without actually changing what is viewed (mapping/unmapping, moving, etc)? I tried XSendEvent, but that didn't seem to work. I am using XvShmPutImage to draw video via a YUV overlay into a window. Then I am using XDraw commands to draw "overlays" directly to the window (lines, arcs, text, etc.). When I do this the video image appears correctly, but the overlays do not update properly. Each time the overlays move, the old XDraw data remains along with the new, until I do something to force an exposure on the drawable - such as drag a window over it. Then the window is redrawn with only the new XDraw data drawn over the video image ("new" meaning from XDraw calls made since the last XvShmPutImage call) which is what I wanted. I don't seem to be able to force the XServer to re-expose the window via software, or I would find that an acceptable workaround. Is there something I am not understanding? I have seen this same behavior both on a Matrox G550 and an nVidia Quadro 4 card, so I don't believe it has anything to do with the particular graphics card drivers. I'm not sure why this should be a surprise to you. When you use an overlay, the on-screen window gets solid filled with a chromakey color. If you draw something over the top of the chromakey fill, those somethings will be visible until either you erase them, by restoring the chromakey, or you force an expose event, which tells xvideo to fill with the chromakey again.This is working by design. If the chromakey refilled with every overlay update, it would be impossible to draw anything over a running movie.--- Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc.
RE: XvShmPutImage with XDraw commands
One more question - how can you tell what the chromakey value is? Do I need to use XGetImage or is there a better way? Sorry, I'm kind of new to Xv. That makes perfect sense. Is there a way to force the expose event at the server without actually changing what is viewed (mapping/unmapping, moving, etc)? I tried XSendEvent, but that didn't seem to work. I am using XvShmPutImage to draw video via a YUV overlay into a window. Then I am using XDraw commands to draw "overlays" directly to the window (lines, arcs, text, etc.). When I do this the video image appears correctly, but the overlays do not update properly. Each time the overlays move, the old XDraw data remains along with the new, until I do something to force an exposure on the drawable - such as drag a window over it. Then the window is redrawn with only the new XDraw data drawn over the video image ("new" meaning from XDraw calls made since the last XvShmPutImage call) which is what I wanted. I don't seem to be able to force the XServer to re-expose the window via software, or I would find that an acceptable workaround. Is there something I am not understanding? I have seen this same behavior both on a Matrox G550 and an nVidia Quadro 4 card, so I don't believe it has anything to do with the particular graphics card drivers. I'm not sure why this should be a surprise to you. When you use an overlay, the on-screen window gets solid filled with a chromakey color. If you draw something over the top of the chromakey fill, those somethings will be visible until either you erase them, by restoring the chromakey, or you force an expose event, which tells xvideo to fill with the chromakey again.This is working by design. If the chromakey refilled with every overlay update, it would be impossible to draw anything over a running movie.--- Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc.
Re: XvShmPutImage with XDraw commands
Most drivers implement XvShmPutImage as a video overlay. That means it's not "draw" into the window. It was not the intention that one should be able to render XvShmPutImage into a window along with normal Xlib rendering, subsequently, that type of thing is not supported in the general case. Some drivers offer non-overlay Xv PutImage adaptors that will have the behavior you desire. Check the output of "xvinfo". Usually PutImage adaptors that do not support the XV_COLORKEY port attribute are such adaptors. Mark. On Wed, 12 Nov 2003, Steve Thrash wrote: > I am using XvShmPutImage to draw video via a YUV overlay into a window. > Then I am using XDraw commands to draw "overlays" directly to the window > (lines, arcs, text, etc.). > > When I do this the video image appears correctly, but the overlays do not > update properly. Each time the overlays move, the old XDraw data remains > along with the new, until I do something to force an exposure on the > drawable - such as drag a window over it. Then the window is redrawn with > only the new XDraw data drawn over the video image ("new" meaning from XDraw > calls made since the last XvShmPutImage call) which is what I wanted. I > don't seem to be able to force the XServer to re-expose the window via > software, or I would find that an acceptable workaround. Is there something > I am not understanding? > > I have seen this same behavior both on a Matrox G550 and an nVidia Quadro 4 > card, so I don't believe it has anything to do with the particular graphics > card drivers. > > Thanks in advance, >Steve Thrash > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XvShmPutImage with XDraw commands
On Wed, 12 Nov 2003, Steve Thrash wrote: > One more question - how can you tell what the chromakey value is? Do I need > to use XGetImage or is there a better way? Use XvGetPortAttribute to get the value of the XV_COLORKEY attribute. You'll want to query the attributes first though. If the attribute doesn't exist, the adaptor isn't using an overlay. And calling XvGetPortAttribute for an attribute that doesn't exist is an error. The application "xvinfo" is an example of how to query this sort of stuff. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XvShmPutImage with XDraw commands
Okay, the light bulb finally turned on! I see that the chromakey is something I can set via XvSetPortAttribute(). I also see what you mean about not directly putting the image and drawing the data to the window. The following sequence seems to be working well: For each video frame: 1. XFillRectangle() - to fill a pixmap with the chromakey 2. XDraw...() to put my data into the pixmap 3. XCopyArea() to copy the pixmap onto the window 4. XvShmPutImage() to place the video "under" the drawn data on the window. The overlays may update a split second before the associated video, and I get a flicker when there is a real exposure event, but I think that is acceptable. Thank you both very much for the help! - Steve > >Most drivers implement XvShmPutImage as a video overlay. That > means it's not "draw" into the window. It was not the intention > that one should be able to render XvShmPutImage into a window along > with normal Xlib rendering, subsequently, that type of thing is not > supported in the general case. Some drivers offer non-overlay Xv > PutImage adaptors that will have the behavior you desire. Check > the output of "xvinfo". Usually PutImage adaptors that do not > support the XV_COLORKEY port attribute are such adaptors. > > Mark. > > On Wed, 12 Nov 2003, Steve Thrash wrote: > > > I am using XvShmPutImage to draw video via a YUV overlay into a window. > > Then I am using XDraw commands to draw "overlays" directly to the window > > (lines, arcs, text, etc.). > > > > When I do this the video image appears correctly, but the > overlays do not > > update properly. Each time the overlays move, the old XDraw > data remains > > along with the new, until I do something to force an exposure on the > > drawable - such as drag a window over it. Then the window is > redrawn with > > only the new XDraw data drawn over the video image ("new" > meaning from XDraw > > calls made since the last XvShmPutImage call) which is what I wanted. I > > don't seem to be able to force the XServer to re-expose the window via > > software, or I would find that an acceptable workaround. Is > there something > > I am not understanding? > > > > I have seen this same behavior both on a Matrox G550 and an > nVidia Quadro 4 > > card, so I don't believe it has anything to do with the > particular graphics > > card drivers. > > > > Thanks in advance, > >Steve Thrash > > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XvShmPutImage with XDraw commands
On Wed, 12 Nov 2003, Steve Thrash wrote: > Okay, the light bulb finally turned on! > > I see that the chromakey is something I can set via XvSetPortAttribute(). I > also see what you mean about not directly putting the image and drawing the > data to the window. > > The following sequence seems to be working well: > > For each video frame: > 1. XFillRectangle() - to fill a pixmap with the chromakey > 2. XDraw...() to put my data into the pixmap > 3. XCopyArea() to copy the pixmap onto the window > 4. XvShmPutImage() to place the video "under" the drawn data on the window. > > The overlays may update a split second before the associated video, and I > get a flicker when there is a real exposure event, but I think that is > acceptable. > > Thank you both very much for the help! The flicker-free solution would be to disable the XV_AUTOPAINT_COLORKEY attribute. That prevents the driver from painting the key, leaving it entirely your responsibility. Then you can do something like draw your scene (key+graphics) into the window yourself, or if you're not changing the graphics frequently, draw it into a pixmap and set that pixmap as the window background. In that case you update the graphics by redrawing the pixmap, resetting it as the window background and then calling XClearWindow. If you do something like that, you never need to handle expose events. The server automatically paints the window background on expose events. Mark. > > - Steve > > > > >Most drivers implement XvShmPutImage as a video overlay. That > > means it's not "draw" into the window. It was not the intention > > that one should be able to render XvShmPutImage into a window along > > with normal Xlib rendering, subsequently, that type of thing is not > > supported in the general case. Some drivers offer non-overlay Xv > > PutImage adaptors that will have the behavior you desire. Check > > the output of "xvinfo". Usually PutImage adaptors that do not > > support the XV_COLORKEY port attribute are such adaptors. > > > > Mark. > > > > On Wed, 12 Nov 2003, Steve Thrash wrote: > > > > > I am using XvShmPutImage to draw video via a YUV overlay into a window. > > > Then I am using XDraw commands to draw "overlays" directly to the window > > > (lines, arcs, text, etc.). > > > > > > When I do this the video image appears correctly, but the > > overlays do not > > > update properly. Each time the overlays move, the old XDraw > > data remains > > > along with the new, until I do something to force an exposure on the > > > drawable - such as drag a window over it. Then the window is > > redrawn with > > > only the new XDraw data drawn over the video image ("new" > > meaning from XDraw > > > calls made since the last XvShmPutImage call) which is what I wanted. I > > > don't seem to be able to force the XServer to re-expose the window via > > > software, or I would find that an acceptable workaround. Is > > there something > > > I am not understanding? > > > > > > I have seen this same behavior both on a Matrox G550 and an > > nVidia Quadro 4 > > > card, so I don't believe it has anything to do with the > > particular graphics > > > card drivers. > > > > > > Thanks in advance, > > >Steve Thrash > > > > > > > ___ > > Devel mailing list > > [EMAIL PROTECTED] > > http://XFree86.Org/mailman/listinfo/devel > > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XvShmPutImage with XDraw commands
> The flicker-free solution would be to disable the XV_AUTOPAINT_COLORKEY > attribute. That prevents the driver from painting the key, leaving it > entirely your responsibility. Then you can do something like draw > your scene (key+graphics) into the window yourself, or if you're > not changing the graphics frequently, draw it into a pixmap and set > that pixmap as the window background. In that case you update the > graphics by redrawing the pixmap, resetting it as the window background > and then calling XClearWindow. If you do something like that, you > never need to handle expose events. The server automatically paints > the window background on expose events. > > Mark. > You are right (of course) that did make for a flicker free solution. I'll have to think about some of the other implications you said - although our background will be updating at about 30 FPS - there could be good implication during freeze frame or other times. On a related note, what does the double buffering option give you? Does it allow you to call XvShmPutImage before the old image has finished drawing to the drawable? It looks like the server handles it all automatically. Also - is XvMC the right solution if I want to blend two images to an arbitrary percentage tranparency at 30 FPS using the graphics hardware? Thanks again, Steve ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XvShmPutImage with XDraw commands
On Thu, 13 Nov 2003 08:51:25 -0500, Steve Thrash wrote: > >Also - is XvMC the right solution if I want to blend two images to an >arbitrary percentage tranparency at 30 FPS using the graphics hardware? Unless I have missed a staff meeting somewhere, XvMC is specifically designed to allow hardware acceleration of MPEG motion compensation vectors. It is VERY specific to the MPEG protocol, and is likely of no use in any other context. The xrender extension can do alpha blending, although driver support is still lacking. -- - Tim Roberts, [EMAIL PROTECTED] Providenza & Boekelheide, Inc. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: XvShmPutImage with XDraw commands
On Thu, 13 Nov 2003, Steve Thrash wrote: > > The flicker-free solution would be to disable the XV_AUTOPAINT_COLORKEY > > attribute. That prevents the driver from painting the key, leaving it > > entirely your responsibility. Then you can do something like draw > > your scene (key+graphics) into the window yourself, or if you're > > not changing the graphics frequently, draw it into a pixmap and set > > that pixmap as the window background. In that case you update the > > graphics by redrawing the pixmap, resetting it as the window background > > and then calling XClearWindow. If you do something like that, you > > never need to handle expose events. The server automatically paints > > the window background on expose events. > > > > You are right (of course) that did make for a flicker free solution. I'll > have to think about some of the other implications you said - although our > background will be updating at about 30 FPS - there could be good > implication during freeze frame or other times. > > On a related note, what does the double buffering option give you? Does it > allow you to call XvShmPutImage before the old image has finished drawing to > the drawable? It looks like the server handles it all automatically. XV_DOUBLE_BUFFER just determines whether the video updates are tear-free or not. Without it updates occur to the buffer while being displayed. With it updates occur to a separate buffer which gets swapped with the displaying buffer at the next vertical retrace. XV_DOUBLE_BUFFER is on by default and the only benefit of disabling it is that it requires less video memory. This was really only an issue back in the days of 8 Meg video cards. I'm considering removing the option on NVIDIA cards. > > Also - is XvMC the right solution if I want to blend two images to an > arbitrary percentage tranparency at 30 FPS using the graphics hardware? No. XvMC is an MPEG decode acceleration library. What you are describing sounds like a job for OpenGL. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XvShmPutImage with XDraw commands
On Tue, 25 Nov 2003, Steve Thrash wrote: > I am using XvShmPutImage to draw video via a YUV overlay on an nVidia Quadro > 4 XGL card (PNY 580 XGL). I then do an XSync() to make sure that the video > is completely drawn before continuing. I am having a problem where the > video is sometimes not keeping up. I am drawing a 1280x960 image and have > noticed that the first 14-16 draws take about 22 ms, and all subsequent ones > take about 9-10 ms. The timing starts before the XvShmPutImage and ends > after the XSync. 9-10 ms sounds like reasonable performance (254-273 MB/sec). Note that the video isn't displayed when XSync is finished. It's merely been uploaded to the card. The image itself won't get displayed until the next vertical retrace (which at 60Hz is up to 17ms later). > > Sometimes after switching video windows around a few times, I get into a > state where the draws get slow again and stay that way indefinitely. The > input rate of the data does not seem to be a factor - I tried lowering it > from 30 FPS to 10 FPS and got the same results. Trying XvPutImage didn't > help either. I get the same problem if I switch to the blitter, rather than > the overlay port. I DO NOT get the problem however if I blit RGB data > instead of YUV. RGB blits aren't synced to the retrace. The NVIDIA binary drivers offer a "NV05 Video Blitter" Xv adaptor which supports YUV blits (see the output of xvinfo). The "nv" driver from CVS also supports a similar blit adaptor. > > P.S. On a related note, does anybody know what the XV_ITURBT_709 attribute > does? > It changes the algorithm for the color space conversion. Most MPEG content is ITU-R BT.601, but HDTV is ITU-R BT.709. Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel