Hi ML, Hi dxr3plugin lovers,
Attached to this posting is a patch which fixes the odd problem making the osd turn pink after returning from mplayer or after hardware-reset of the dxr3-card. I posted this fix in a german-vdr-forum a couple of months ago and it works for other users there, too. I haven't found the time to post it here (other users hadn't either:) )... so, here it is.
Now what this patch does is it changes some behavior of cDxr3PaletteManager. It seems, that after returning from pmExtern_THIS_SHOULD_BE_AVOIDED, palette-data in cDxr3PaletteManager is somehow broken after resuscitation (whatever happens there, the code is a total mess). I avoid this by *not* converting the whole data allover again in cDxr3PaletteManager::GetPalette() through Tools::Rgb2YCrCb() and copy it to m_pal (only when palette-data has changed, indicated by member m_changed, should speed up the whole process a bit additionally).
This patch may be applied to current CVS (HEAD or MAIN, also vdr-dxr3-0-2). Give it a shot ! Bye,
On Wed, 30 Mar 2005, "Martin" == Martin Cap wrote:
Martin> This patch may be applied to current CVS (HEAD or MAIN, also vdr- Martin> dxr3-0-2). Give it a shot ! Bye, --
Yes, this also works fine for me...
Now I have to decide: an actual working vdr-1.3.23 with dxr3 and no hassle with mplayer and working DVD Plugin but no digital sound output at all or a vdr-1.3.12 with AC3 over Digital Out but no DVD and pink osd on mplayer...
Has anyone Digital Out and even AC3 running with dxr3 on vdr >= 1.3.18?
It seems, that Christian aka AustrianCoder has dissappeared somehow...
Regards Steve
On Wed, 2005-03-30 at 13:48 +0200, Martin Cap wrote:
Yep, works for me too, thanks.
However, the patch gave me the creeps, so I dug a little deeper. I found that the only thing needed to fix the pink OSD here was to comment out the "m_users[i] == 0" test in AddColor() and unconditionally setting m_changed to true there, or to set it to true in GetIndex() when the color was found. Both of those were still ugly. Then I noticed that the counters in m_users were not being reset to zero when they IMO should have been, and came up with the attached patch which I think would be more appropriate. (Also applied to the vdr-dxr3-0-2 branch in CVS.)
With this one applied, I no longer get pink OSD after returning from the MPlayer plugin. But after "Reset DXR3", the OSD is still momentarily pink immediately after; things return to normal when the OSD is hidden/shown again.
Reviews/testing welcome...
Ville Skyttä wrote:
Try to use the yaepg plugin: after that the normal osd (only with the st:tng skin) starts doing strange things here (reproducible), like discontinuous transparent background, a small rectangle black in the lower right corner of the channel name in the channel info display and thinner than normal selected lines. Without the patch it doesn't happen.
Bye
Hi,
how about the "original" patch I posted ? Does it happen there ?
Regards,
Martin Cap wrote:
Hi,
how about the "original" patch I posted ? Does it happen there ?
No, it doesn't, but the femon plugin doesn't work anymore with the elchi, deepblue or moronimo skins (only the "classic" one works with this patch).
Bye
Luca Olivetti wrote:
Wait, it doesn't work even without your patch, it works only with Ville's patch.
Bye
Luca Olivetti wrote:
Ville's patch also fixes some colours in some pages with the osd teletext plugin, your doesn't (i.e. it seems it can manage more colours on larger areas at once). Pity for the problem after using the yaepg plugin.
Bye
Luca Olivetti wrote:
I'm lost now. I'm testing your patch and the femon plugin shows correctly with the elchi skin if it's the first one shown, afterwards the yaepg plugin doesn't work (all black). Viceversa, if I use the yaepg plugin first after a restart it's the one working fine but the femon plugin show its texts black with the elchi skin.
Bye
Luca Olivetti wrote:
But then, it's the same even without your patch, so it's not making things worse.
Bye
On Sat, 2005-04-02 at 12:51 +0200, Luca Olivetti wrote:
Yep, that's expected. Before the patch, colors weren't being "freed" in OSD_Close, but were left reserved even though nothing in the OSD was using them any more. That obviously resulted in the whole whopping limit of 16 colors reaching the top sooner than supposed.
Since you're tinkering with the palette stuff, here's something I noticed while looking at Martin's patch:
cDxr3PaletteManager::GetIndex() is supposed to return the index of a given color in the current palette. If the given color is not found, it returns 0, which doesn't make sense to me. It should probably return -1 or something that isn't a valid index. The return value of GetIndex() is used in cSPUEncoder::Cmd(), the OSD_SetPalette case in the big switch statement.
Now, what should be done there if an invalid index is returned (ie. the color is not found in the current palette) is beyond me. Blindly using the returned 0 which is either the first color in the palette or a nonexistent color seems clearly wrong and will almost certainly cause some "effects"... ideas and especially patches welcome :)
Ville Skyttä wrote:
Since freeing colours should be better, then why the strange problem after using the yaepg plugin?
Bye
Ville Skyttä wrote:
Ok, your fix is wrong, I have (what seems to be) the correct one. I will try it a bit more, clean it up a bit and send it later.
Bye
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
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:
Martin Cap wrote:
It works here too, even with yaepg. If you remove the logo display it's also possible to use the elchi skin with text2skin 1.0 (both with cDxr3PaletteManager or cPalette). Unfortunately the other skins available for text2skin 1.0 need more than the 16 colours the dxr3 is capable of showing.
Bye
On Sun, 2005-04-03 at 19:07 +0200, Martin Cap wrote:
Hi !
The OSD still sucks, but I guess we made it suck a little less :)
Indeed, seems so, at least mostly.
This change introduces/triggers one new crash here, though. Not that tvonscreen >= 0.6.0 would be usable with DXR3 here anyway, I gave 0.7.0 a try with Martin's change applied; the exact change against vdr- dxr3-0-2 branch I'm using is attached. Every time the tvonscreen OSD is closed, I get a crash, backtrace attached. If I don't apply the patch, there's no crash, but parts of the tvonscreen OSD remain visible seemingly forever after closing it. Tvonscreen 0.5.2 continues to work pretty much ok with or without the patch applied.
Fixes to the above are of course welcome, but unless I see more new issues while testing this patch some more, I'll go ahead and apply it next week.
Ville Skyttä wrote:
That's why I use yaepg ;-)
[...]
I'm not sure this hunk is correct, the display is cleared various times throughout the osd life, the palette should be freed only upon close, shouldn't it?
Bye
Luca Olivetti wrote:
well, it doesn't harm (it was in Martin's source withot me realizing it) but it works well even without it. I also set the palette to 16 colors now (not that it changes much, but...).
Bye
Luca Olivetti wrote:
You're right, that's the way it should be done.
Another thing I made wrong is "dxr3tools.h" only gets included, if one sets -DUSE_XINE_SCALER in eg. the Makefile, otherwise not. Thus, the include-statement is at the wrong place (I don't think anyone wants to use the old scaling-algorithm, but you never know...) : ----
--- dxr3interface_spu_encoder.c 2005-04-04 18:45:09.526439552 +0200 +++ dxr3interface_spu_encoder.c.orig 2005-04-04 18:44:16.120558480 +0200 @@ -28,7 +28,7 @@
#include "dxr3interface_spu_encoder.h" #include "dxr3memcpy.h" -#include "dxr3tools.h" +
/* ToDo: @@ -47,6 +47,7 @@ #include <signal.h> #include <string>
+#include "dxr3tools.h" #include <vdr/plugin.h>
namespace XineScaler
On Mon, 2005-04-04 at 18:49 +0200, Martin Cap wrote:
[...]
I've just committed the patch I posted previously plus these two changes to the vdr-dxr3-0-2 branch. The tvonscreen crash I noted earlier seems to be also gone, ditto all pink OSD's. Thanks, guys!
One nitpick though: in the future, if it doesn't make your life too hard, it'd make things somewhat easier for me if you could post patches against the vdr-dxr3-0-2 branch in CVS, and include only the absolute minimum changes. It's a bit tedious to try to keep up with various versions people have lying around in their local trees, sometimes patches are reversed, sometimes contain irrelevant changes etc. But in any case, keep the fixes coming :)
Luca Olivetti wrote:
Hu, I tried enElchi yesterday (with and without logos) and had no such luck. I still have areas with wrong colors (especially with channel info, teletext)), menues are fine with enElchi though.
Well, I will investigate on this :).
Ville Skyttä wrote:
When trying dxr3 plugin from the cvs with vdr-1.3.23, I noticed that TODO has shortened somewhat but I still suffer from following problems:
DVD plugin, cvs: No sound, tried both digital and analog output.
Mplayer plugin, 0.9.12: No sound after returning to VDR when using digital output. Wrong aspect ratio after returning to VDR.
Thanks to all developers, Kimmo Vuorinen
On Wednesday 06 April 2005 14:47, Kimmo Vuorinen wrote:
Mplayer plugin, 0.9.12: Wrong aspect ratio after returning to VDR.
This isn't by any chance because you have set in mplayer.sh.conf TV_ASPECT="16/9"? This is a bad idea in any case no matter the shape of your tv.
What it actually does is tells mplayer to scale the image up to 720x576 and then squashes it with the dxr3's hardware letterboxing feature. Useless upscaling causes more cpu usage and worse picture quality. If you set it to 4/3 it just adds black borders which takes less cpu and doesn't destroy the picture by stretching it around.
I don't quite understand what this option is meant to do and how it works on a full dvb card but what I describe is what it does on a dxr3.
I've never had the aspect ratio stay at 16/9 after mplayer quits, though. And I've used it _alot_.
Jukka Tastula wrote:
I have 4:3 tv and I am using my own script to start mplayer and it uses -aspect and -monitoraspect 1.3333 options. After returning to VDR which is tuned into channel with 16:9 transmission, picture is scretched into 4:3. I'll do some more testing later at the evening.
Thanks.
Martin Cap wrote:
with "without logo" I mean commenting out the whole section "channel logo" in enElchi.skin (then adjusting the surrounding areas, channel number and channel name, to fill the void).
Bye
Martin Cap wrote:
To do that I would have to know if currently tuned channel is in 4:3 or 16:9 format when executing the script so script could set correct display mode. I don't know if there is a way to get this information but in my mind it would be quote ugly hack anyway ;)
Kimmo Vuorinen wrote:
Try this patch (it works here).
Bye
Kimmo Vuorinen wrote:
Try this (untested) patch.
Bye