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

Greg Wright wrote:
> Daniel, take a look at:

OK, I hadn't read this response and had yet to start looking deeper into 
the code when I commented with my own understanding.

>     m_bNeedColorKeyFilled = FALSE;
> ...
>     //XXXgfw Well, this turns out to be mostly true. With our new fancy
>     //presentation-feature SMIL demo we have a problem where the video 
> can not
>     //be seen until you see the player...
> ...
> It looks like we should be working even without Xv painting the
> color key for us. Is this change, in basesurf.cpp, in your branch?

Nope, this change is not in 150Cay. I'll merge it over.

There was one case where I had to toggle the XV_AUTOPAINT_COLORKEY value 
to 0 and then 1 in order for XVideo to work. It seems like an unusual 
case and I wonder if it is just a video driver problem (where it got 
into a wrong state) and not something that application needs to do to 
toggle the XV_AUTOPAINT_COLORKEY setting.


Greg Wright wrote:
> 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.

OK. This "understanding" isn't really correct anymore -- expired.

>> 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 level you are looking, 

I was looking for anything that allows me to "do my homework" and then 
have adequate background information needed to create good fixes.


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

Yes, that works. One just needs to pay attention to expose two edges of 
the video window so that blitting of the rectangular area happens.

Thanks.

-- 
Daniel Yek.


> 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