DVB subtitle rendering faulty with xshm

[Mikko Rauhala]

Xine renders DVB subtitles incorrectly when using xshm output. The subtitles seem to be XOR'd over the video (correct colouring is evident on a black background, garbled otherwise) instead of painted over. With xvideo output, the subtitles are properly displayed. (Just the annoyance that xvideo output doesn't work realiably on the Feisty r300 driver, but that's another bug.)

libxine1 1.1.4-2ubuntu3
xine-ui 0.99.4+dfsg+cvs20061111-2ubuntu2

[Mikko Rauhala (mjr-iki)]

Bugger. Should be on libxine1, obviously.

[Durand Burke (durand-burke)]

I am having the same problem. I looked into it a bit and found that the subtitles are not actually being XORed; I think what's happening is that when the subtitles are alpha blended into the image, an 8-bit alpha channel is being passed to a blending function designed for 4-bit alpha channels, causing the pixel values to overflow and wrap around.

The attached patch fixes the DVB subtitles for me, but it is not the correct fix because it has the side effect of making DVD (as opposed to DVB) subtitles very faint (perhaps they actually use the 4-bit alpha the original code expects?). I'm including it anyway just in case it provides some clues that might help someone who understands the code to come up with a real fix.

[Reinhard Tartler (siretart)]

The following message is a courtesy copy of an article
that has been posted to gmane.comp.video.xine.devel as well.

# HG changeset patch
# User Durand Burke
# Date 1205528235 -3600
# Node ID ab7dd74755c712af15e5876399e77f40fea6392b
# Parent df257a6e4008dfdee1cfc9a90e1aebd267f1fedb
Patch found on https://bugs.launchpad.net/bugs/129114

Xine renders DVB subtitles incorrectly when using xshm output. The
subtitles seem to be XOR'd over the video (correct colouring is evident
on a black background, garbled otherwise) instead of painted over. With
xvideo output, the subtitles are properly displayed. (Just the annoyance
that xvideo output doesn't work realiably on the Feisty r300 driver, but
that's another bug.)

I looked into it a bit and found that the subtitles are not actually
being XORed; I think what's happening is that when the subtitles are
alpha blended into the image, an 8-bit alpha channel is being passed to
a blending function designed for 4-bit alpha channels, causing the pixel
values to overflow and wrap around.

The attached patch fixes the DVB subtitles for me, but it is not the
correct fix because it has the side effect of making DVD (as opposed to
DVB) subtitles very faint (perhaps they actually use the 4-bit alpha the
original code expects?). I'm including it anyway just in case it
provides some clues that might help someone who understands the code to
come up with a real fix.

diff --git a/src/xine-engine/alphablend.c b/src/xine-engine/alphablend.c
--- a/src/xine-engine/alphablend.c
+++ b/src/xine-engine/alphablend.c
@@ -40,7 +40,7 @@

 #define BLEND_COLOR(dst, src, mask, o) ((((((src&mask)-(dst&mask))*(o*0x111+1))>>12)+(dst&mask))&mask)

-#define BLEND_BYTE(dst, src, o) (((((src)-(dst))*(o*0x1111+1))>>16)+(dst))
+#define BLEND_BYTE(dst, src, o) (((((src)-(dst))*(o*0x101))>>16)+(dst))

 static void mem_blend16(uint16_t *mem, uint16_t clr, uint8_t o, int len) {
   uint16_t *limit = mem + len;

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Darren Salt (dsalt)]

The following message is a courtesy copy of an article
that has been posted to gmane.comp.video.xine.devel as well.

I demand that Reinhard Tartler may or may not have written...

> Xine renders DVB subtitles incorrectly when using xshm output.

I see no problems. Bugginess in X, since fixed?

[snip]
--
| Darren Salt | linux or ds at | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Use more efficient products. Use less. BE MORE ENERGY EFFICIENT.

I'd like to, but my chocolate-appreciation class meets that night.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[Mikko Rauhala (mjr-iki)]

Yeaah it seems this bug has been fixed at some point, since my current Gutsy system doesn't exhibit it.

[Daniel T Chen (crimsun)]

Which X.Org graphics driver was used [so this issue can be reassigned/affected and closed]?

[Mikko Rauhala (mjr-iki)]

The (free) radeon driver in xserver-xorg-video-ati was used, however I doubt this is/was relevant, since as said, it was the very basic _xshm_ output of Xine that exhibited the bug (so not any accelerated output, just slapping bitmaps onto a X window).

Also, AFAIK Xine renders the subtitles onto the image itself before displaying it anyway. I haven't checked this from code, but at least the behavior seems to be consistent with it (eg. what with using even the Xv driver and moving the video window around, the video _along_ with the subtitles lags behind a bit, and also, if one moves the window so that it's on two monitors when only one is supported with Xv, the subtitles also disappear from one of the slices of the window along with the image).

Just that the code paths don't seem to (have?) been all the same, since even while the Xshm bug was around, Xv still worked...

Ah well, anyway, it's all good now, as said.

[Jonathan Thomas (echidnaman)]

As long as it's fixed... :)