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
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: in6addr_any reference breaks libICE.so compatibility
On Tue, 11 Nov 2003, David Dawes wrote: > On Mon, Nov 10, 2003 at 03:09:14PM -0500, David Dawes wrote: > >On Mon, Nov 10, 2003 at 11:36:54AM -0800, Alan Coopersmith wrote: > >>David Dawes wrote: > >>> I've noticed that the reference to in6addr_any in xtrans has broken > >>> libICE.so compatibility, at least on FreeBSD 4.3. This shows up a > >>> runtime loader error when attempting to run applications built against > >>> an older version of the library: > >>> /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libICE.so.6: Undefined symbol > >>> "in6addr_any" > >>> It is almost certainly related to in6addr_any being a const. > >>> I'm not sure if this is a localised problem, or if it affects a > >>> wider range of platforms. I'm committing a workaround that makes > >>> use of IN6ADDR_ANY_INIT when available, and that works here. > >>> Has anyone seen this to be a problem on other platforms? > >>We have no problem like that on Solaris - but on Solaris in6addr_any > >>is defined in libsocket.so, which libICE.so is linked with, so it > >>always automatically gets resolved at runtime. I haven't seen any > >>problem reports on other platforms either. > >On FreeBSD it is in libc.so. I thought that since 'cc' is used to > >create libICE.so, it was implicitly linked against -lc, based on the > >comment in bsdLib.rules: > >#ifndef BaseShLibReqs > >#define BaseShLibReqs /* -lc implied by $(CC) */ > >#endif > >If I add it explicitly it solves the problem. > Just to follow up on this, I think I've found the reason for the problem. > The application I noticed this with was built in 1999 against an older > libc (libc.so.3 on FreeBSD 3.x). That older libc doesn't have any IPv6 > support, so without -lc specified explicitly for libICE.so, the application > loads only the old libc that doesn't have in6addr_any. Linking libICE.so > explicitly against -lc allows both the old and new libc's to be loaded > at runtime, and this seems to work. I'm naively assuming that the new > libc gets used solely for the X libs and the old one solely for the > app's own code, and that since the X library ABIs should be independent > of libc, everything will work happily together. > However, Matthieu reminded me that explicitly linking our shared libraries > against libc can cause problems on some BSD versions that link threaded > apps with -lc_r (instead of -lc), and I believe that was one of the main > reasons for not linking shared libraries against -lc explicitly on these > platforms. > I'm not sure what the best answer to all of this is. So the newer libc isn't compatible with the old one? Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
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: in6addr_any reference breaks libICE.so compatibility
On Wed, Nov 12, 2003 at 12:48:25PM -0700, Marc Aurele La France wrote: >On Tue, 11 Nov 2003, David Dawes wrote: >> On Mon, Nov 10, 2003 at 03:09:14PM -0500, David Dawes wrote: >> >On Mon, Nov 10, 2003 at 11:36:54AM -0800, Alan Coopersmith wrote: >> >>David Dawes wrote: >> >>> I've noticed that the reference to in6addr_any in xtrans has broken >> >>> libICE.so compatibility, at least on FreeBSD 4.3. This shows up a >> >>> runtime loader error when attempting to run applications built against >> >>> an older version of the library: > >> >>> /usr/libexec/ld-elf.so.1: /usr/X11R6/lib/libICE.so.6: Undefined symbol >> >>> "in6addr_any" > >> >>> It is almost certainly related to in6addr_any being a const. > >> >>> I'm not sure if this is a localised problem, or if it affects a >> >>> wider range of platforms. I'm committing a workaround that makes >> >>> use of IN6ADDR_ANY_INIT when available, and that works here. > >> >>> Has anyone seen this to be a problem on other platforms? > >> >>We have no problem like that on Solaris - but on Solaris in6addr_any >> >>is defined in libsocket.so, which libICE.so is linked with, so it >> >>always automatically gets resolved at runtime. I haven't seen any >> >>problem reports on other platforms either. > >> >On FreeBSD it is in libc.so. I thought that since 'cc' is used to >> >create libICE.so, it was implicitly linked against -lc, based on the >> >comment in bsdLib.rules: > >> >#ifndef BaseShLibReqs >> >#define BaseShLibReqs /* -lc implied by $(CC) */ >> >#endif > >> >If I add it explicitly it solves the problem. > >> Just to follow up on this, I think I've found the reason for the problem. >> The application I noticed this with was built in 1999 against an older >> libc (libc.so.3 on FreeBSD 3.x). That older libc doesn't have any IPv6 >> support, so without -lc specified explicitly for libICE.so, the application >> loads only the old libc that doesn't have in6addr_any. Linking libICE.so >> explicitly against -lc allows both the old and new libc's to be loaded >> at runtime, and this seems to work. I'm naively assuming that the new >> libc gets used solely for the X libs and the old one solely for the >> app's own code, and that since the X library ABIs should be independent >> of libc, everything will work happily together. > >> However, Matthieu reminded me that explicitly linking our shared libraries >> against libc can cause problems on some BSD versions that link threaded >> apps with -lc_r (instead of -lc), and I believe that was one of the main >> reasons for not linking shared libraries against -lc explicitly on these >> platforms. > >> I'm not sure what the best answer to all of this is. > >So the newer libc isn't compatible with the old one? I believe that's the case. I don't know what the extent of the incompatibilities is (I think some interfaces were removed). ldd shows both versions getting loaded when an app is linked against the old one and libICE.so is linked against the new one: libm.so.2 => /usr/lib/libm.so.2 (0x28098000) libXaw3d.so.6 => /usr/X11R6/lib/libXaw3d.so.6 (0x280b4000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x280f1000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x28106000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x2814f000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x28158000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x2816f000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x2817c000) libxpg4.so.2 => /usr/lib/libxpg4.so.2 (0x28237000) libc.so.3 => /usr/lib/libc.so.3 (0x2823b000) libc.so.4 => /usr/lib/libc.so.4 (0x282bb000) libXThrStub.so.6 => /usr/X11R6/lib/libXThrStub.so.6 (0x28353000) It is (or at least used to be) considered important on FreeBSD that old apps continue to run if you choose to install the old system libraries. They are provided as part of the installation for that reason. I don't know if what I'm seeing is just a case of good luck, or whether achieving this sort of compatibility for X applications would require another approach. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ 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
