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

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.

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

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

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

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?

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.

-- 
Daniel Yek.



Bankim Bhavsar wrote:
> Hi Daniel,
> In the 1st iteration of the Xv extension in VMware video driver we
> just had XV_COLORKEY attribute and relied on the application to paint
> the colorkey. With no autopaint feature in the
> driver, videos didn't play with Real Player. So we added the
> XV_AUTOPAINT_COLORKEY attribute. Although the driver starts with
> default value of 1, if some other application (eg Mplayer) changes the
> attribute to 0 then videos will stop working with Real player.
>
> Setting XV_AUTOPAINT_COLORKEY to 1 will solve this problem.
>
> Any idea when is the next release of Real player for Linux coming up?
>
> Thanks,
> Bankim.
>
> On Mon, Jul 21, 2008 at 4:46 PM, Daniel Yek <[email protected]> wrote:
>   
>> Hi Bankim,
>>
>> Yes, I agree that the XV_AUTOPAINT_COLORKEY bug is bad. I'll try looking
>> into fixing it probably by simply setting it to 1 at the start of every
>> playback. At this time, I don't think it is necessary for an app. to restore
>> the value, because any application can set this attribute to a different
>> value after the player started.
>>
>> Thanks for bringing this to my attention.
>>
>> --
>> Daniel Yek.
>>
>>
>>
>> Greg Wright wrote:
>>     
>>> Just adding player-dev since they might be interested in
>>> getting the fix in.
>>>
>>> --greg
>>>
>>>
>>> Bankim Bhavsar wrote:
>>>       
>>>> I hit this autopaint colorkey bug while implementing Xv extensions in
>>>> vmware video driver.
>>>> https://bugs.helixcommunity.org/show_bug.cgi?id=3465&link=0
>>>>
>>>> The patch attached by Tom in this discussion
>>>>
>>>> http://lists.helixcommunity.org/pipermail/helix-client-dev/2007-March/005953.html
>>>> does partially address the bug.
>>>>
>>>> When I browsed through the helix code, I see that the patch is not
>>>> included. This patch
>>>> will be a good improvement.
>>>>
>>>> Thanks,
>>>> Bankim.
>>>>         

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