Michael,
  I Think some of the other replies have given the correct
information, but I'll try to sum it up.

First, when you do Xv you are not drawing to the screen as
you know it as all. The data goes into a totally different
buffer. This area is then "overlaid" on top of the normal
framebuffer by the overlay hardware. This is why your
framebuffer (desktop) is in RGB color but the data you send
to Xv is YUV.  Additionally the overlay can stretch or shrink
the image on the screen without altering the actual data in
memory. This of the overlay as a projector that projects on
the top of your desktop. The projector can change the size of
an image or alter it's colors without changing the input.

Second, XImages and XvImages are client side images. When you
do an XPutImage or XvPutImage you are putting the data into
a server side image. There is no separate copy of each image
inside the X server. So the fact that you are using 2 XImages
means nothing. If the target of your put() is the same then
the data is getting overwritten.  This behavior is a little
different since the i810 double buffers the overlay, but the
point is that the number of XvImages you are using has nothing
to do with what happens inside the server. They are just memory
areas of a specific format.

Third, the i810 only has one overlay engine. Think again of the
projector... it can only project one image to one place. If you
try to use it twice (which you should not be able to do if you
grab the port as you are supposed to do) you make the projector
point to one place then the other, back and forth.

Last, The blue is the colorkey. If the projector is displaying
on top of your desktop then you could never make a window be
"on top" of the projected image. This would make it impossible
to ever cover up a portion of your video window. The solution
is the colorkey. The overlay only projects onto pixels that are
of a specific color. All other pixels will not be covered up.
The default colorkey is blue and when you do an XvPutImage the
X server paints your actual window blue so that the overlay will
draw "on top" of those pixels. When you point the overlay to the
second window the first window still has the blue pixels in it
so that is what you get.

It would be nice to have a software fallback so that you could
do as many Xv's as you wanted (slowly) but that isn't the way
Xv was designed. You'll have to convert the YUV data into RGB
and do a regular XShmPutImage in the second window.

 -Matt



-----Original Message-----
From: Michael Zayats [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 18, 2001 3:46 AM
To: [EMAIL PROTECTED]
Subject: [Xpert]very strange XVideo behaviour (i810)


well I am trying to draw 2 streams of yuv420 frames to 2 windows

I am doing XvShmPutImage , once to first window and once to another once to
first, once to another etc.

I use separate shared memories for each window.

I am doing it very slowly (usleep(3000000) between each draw). the strange
thing is that when I draw to one of the windows the second goes BLUE! the
more interesting is that if I get one of the windows behind something such
that clipping eats it all) the second behaves normally and doesn't present
anything blue.


it seems to me that there is some problem in i810_video driver, I just can't
think of anything else!

(First guess was that I get Exposure events and doesn't respond to them, but
after checking I know that I don't get them at all (only when I raise the
window again)).

any thoughs?

Michael


_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert

Reply via email to