XvShmPutImage with XDraw commands

2003-11-12 Thread Steve Thrash



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

2003-11-25 Thread Steve Thrash



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

2003-11-12 Thread Tim Roberts



--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

2003-11-12 Thread Steve Thrash



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

2003-11-12 Thread Steve Thrash



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

2003-11-12 Thread Mark Vojkovich
   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

2003-11-12 Thread Mark Vojkovich
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

2003-11-12 Thread Steve Thrash
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

2003-11-12 Thread Mark Vojkovich
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

2003-11-13 Thread Steve Thrash
>   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

2003-11-13 Thread Tim Roberts
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

2003-11-13 Thread Mark Vojkovich
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

2003-11-25 Thread Mark Vojkovich
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