[vdr] Patch: dxr3plugin OSD don't turn pink

Martin Cap macap20001 at compuserve.de
Sun Apr 3 18:36:52 CEST 2005


Hi, Luca works great !

I had I another idea last night. Why not use cPalette from VDR (from 
osd.h) itself and completly remove cDxr3PaletteManager ?
I tried it and it works for me(no pink OSD after Mplayer, femon-skins 
work, haven't tried yaepg though), but try for yourself, please.

I substitued cDxr3PaletteManager in dxr3interface_spu_encoder.h with 
cPalette (member m_palManager), and made calls in 
dxr3interface_spu_encoder.c fit the interface of cPalette from VDR 
(changes in dxr3interface_spu_encoder.c mostly around line 315-341).
cPalette lacks something like RemoveColor() AFAIS, but I think it was 
only used to clear the whole palette structure, which is now done 
through cPalette::Reset().

Before adding the color to the palette, it gets converted from RGB to 
YCrCb thru Tools::Rgb2YCrCb().

BTW, I'm just sending you the two files which needed change 
(dxr3interface_spu_encoder.[h|c]) attached to this mail
(you can remove Dxr3PaletteManager.o from the Makefile to see that there 
are no references anymore) .

Comments welcome and highly appreciated.
I'm in a rush kinda, so no long text here, sorry :). If you have 
question, don't hesitate..

Regards,
Martin Cap...

Luca Olivetti wrote:
>>>>
> 
> 
> Here's the patch, to apply with neither yours or Martin's one applied. 
> Since things are starting to get confusing, I'm also attaching the 
> complete files I'm using in a tgz.
> Basically there were 2 problems:
> 1) colors are added multiple times but removed only once[*] when the osd 
> is closed, so the usage count would never get to 0 and the colors would 
> never actually be freed.  The fix is to set m_colors to one instead of 
> incrementing it each time.
> [*]that's not exactly true but it doesn't matter since the osd is being 
> closed anyway.
> 
> 2) RemoveColor expected a color, but the colors in m_window are actually 
> indexes coupled to transparency values. The fix is to change RemoveColor 
> to accept an index instead.
> There's also a futile attempt to use the nearest color when the palette 
> is full, but I doubt it's really useful.
> 
> Bye
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dxr3_palfixx.tgz
Type: application/octet-stream
Size: 6780 bytes
Desc: not available
Url : http://www.linuxtv.org/pipermail/vdr/attachments/20050403/808c8a0c/dxr3_palfixx-0001.obj


More information about the vdr mailing list