Patch: dxr3plugin OSD don't turn pink

Message ID 4251702D.7040504@compuserve.de
State New
Headers

Commit Message

Martin Cap April 4, 2005, 4:49 p.m. UTC
  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
> 

> ------------------------------------------------------------------------
> 
> --- dxr3interface_spu_encoder.c.orig	2005-04-04 17:53:35.966868390 +0200
> +++ dxr3interface_spu_encoder.c	2005-04-04 17:57:36.107254910 +0200
> @@ -270,6 +270,8 @@
>  
>  	// set active area to 0
>  	//m_x0 = m_x1 = m_y0 = m_y1 = 0;
> +	//16 Colors max.
> +	m_palManager.SetBpp(4);


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

Comments

Ville Skyttä April 5, 2005, 7:26 p.m. UTC | #1
On Mon, 2005-04-04 at 18:49 +0200, Martin Cap wrote:
> 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...).
[...]
> 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...) :

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 :)
  
Kimmo Vuorinen April 6, 2005, 11:47 a.m. UTC | #2
Ville Skyttä 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!

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
  
Martin Cap April 6, 2005, 12:08 p.m. UTC | #3
Kimmo Vuorinen wrote:
> 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.
> 
Hi,

The last log entry in CVS says : "No sound with DVD plugin is not our 
problem, apparently." .
:)
  
Jukka Tastula April 6, 2005, 12:23 p.m. UTC | #4
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_.
  
Kimmo Vuorinen April 6, 2005, 12:52 p.m. UTC | #5
Jukka Tastula wrote:
> 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. 

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 April 6, 2005, 1:04 p.m. UTC | #6
Kimmo Vuorinen wrote:
> 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.
> 
Hi,

After leaving mplayer (at the end of mplayer.sh), you could call 
'em8300setup -w' to let the card return into widescreen .
  
Kimmo Vuorinen April 6, 2005, 4:53 p.m. UTC | #7
Martin Cap wrote:
> Kimmo Vuorinen 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.
>>
> Hi,
> 
> After leaving mplayer (at the end of mplayer.sh), you could call 
> 'em8300setup -w' to let the card return into widescreen .

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 April 7, 2005, 12:08 p.m. UTC | #8
Kimmo Vuorinen 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:
> 
> Mplayer plugin, 0.9.12:
> No sound after returning to VDR when using digital output.

Sound seems to work again when I change audio to analog and then back to 
digital.
  
Kimmo Vuorinen April 18, 2005, 7:56 a.m. UTC | #9
Kimmo Vuorinen wrote:
> Kimmo Vuorinen 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:
>>
>> Mplayer plugin, 0.9.12:
>> No sound after returning to VDR when using digital output.
> 
> 
> Sound seems to work again when I change audio to analog and then back to 
> digital.

Could someone who knows where to look check that plugin doesn't set dxr3 
hardware to analog audio output when returning from mplayer?

Thanks.
  

Patch

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