Re: Xvideo: Autopaint colorkey bug in the Unix version of Helix

Daniel Yek wrote:
> Hi Bankim,
> 
> Right. My understanding is that color key was added to some video 
> drivers after Helix XVideo support was implemented and nobody went back 
> and implemented color key support, except to rely on 
> XV_AUTOPAINT_COLORKEY being a suitable default.
> 
> Unfortunately, Xv attributes are system-global resources (think "global 
> variable") that can be changed outside of an application at anytime, 
> requiring application to be color-key-aware to work correctly, even 
> without benefiting from color key feature.
> 
> The easy case of just setting the XV_AUTOPAINT_COLORKEY attribute in the 
> beginning of every playback should fix the simple case if autopaint is 
> implemented in the video driver, but to make other cases work, 
> application would need to handle video drivers without autopaint by 
> having the application drawing the color key.

Only one application, system wide, can have access to XVideo at a time.
Actually, even within one application (RP for example) we can only have
one overlay. That is, if we have two videos playing only one can have
the overlay (XVideo port open) and the other has to be using the normal
XPutImage RGB stuff (or XShmPutImage). Basically, only one *thing* can
have access to the hardware in that fashion.

> 
> I'm still trying to locate good documentation explaining the concept of 
> color key in XVideo. Do you happen to know what document contains the 
> details of XVideo and color key concept? (Even if it is video adapter 
> specification...)

Not sure at what leve you are looking, but colorkey stuff is pretty
standard. If you can find colorkey docs on DirectX, for example, it
will be the same. Basically, when you send an YUV image to the overlay
surface for it to render, you tell it where you want it and how big.
However, the video hardware will *ONLY* show that video in the parts
of the screen that have a certain color painted to it in the normal
RBG fashion (XPutImage). That certain color is the colorkey. It is usually
chosen to be some very rare color so that the video does not 'show through'
other applications. You can try this, its fun. In the preferences you can
set the colorkey to use, choose black:

  ColorKey=0x00

Now launch RP and play a video, it should look OK. Bring up an xterm
with a black background:

   xterm -fg gold -bg black -sl 1000 -sb

Move that xterm on top of the RP video. You will see the video everywhere
that the xterm has black; the background of the xterm. Pretty cool, you
can work in your xterm, compile, whatever and the background of the
xterm will be that video.

> 
> If autopaint feature is not available in video driver, where the color 
> key should be painted? In the application window through X protocol (as 
> opposed to XVideo port)?

In that case the color key is painted by the surface, this is how
windows does it. DirectX does not have a auto-paint-the-colorkey
feature. So, when we go to show a video, we paint the colorkey inside
the window where the video is suppose to be shown, that allows the
hardware rendered video to *show through* onto the screen. We only
need to paint it once and whenever it gets damaged (exposed or whatever).
You will see lots of code in the site for 'filling' the colorkey. This
works on linux as well.

> 
> Am I understanding it correctly that if the color key is drawn (or 
> somehow appeared) to the root window and video data written to the 
> XVideo port covers that area (absolute coordinates), then (part of the) 
> video will appear in the root window (background), or wherever the color 
> key "shines through"?

Yup, see above.

> 
> For even more robust implementation, is there such a case where a video 
> driver/adapter supports two ports and two application playback videos at 
> the same time while each setting the XV_AUTOPAINT_COLORKEY attribute to 
> different values (race condition)? Is the attribute private per-port or 
> global per driver/adapter?

No, see above. Well, this is true for the way we use it. If you want to
talk about 'textures' then this is not true. Also, it could be in the last
year or so support was added for multiple overlays, but it has never happened
on windows and our site does not support more then one.

I would really like to get rid of overlays all together and start using
textures or something equivalent. OpenGL would be a good replacement I
think......


--greg.

> 
> Sorry for asking you so many questions, but I'm just trying to find more 
> information that is accessible.
> 
> Regarding the question about the next release, are you trying to test 
> the fix in RealPlayer or you need it available to users? The nightly 
> build will contain the fix once it is implemented.
> 
> Thanks.
> 


_______________________________________________
Helix-client-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/helix-client-dev