Message ID | 4251702D.7040504@compuserve.de |
---|---|
State | New |
Headers |
Received: from smtp.compuserve.de ([62.52.27.101] helo=lnxc-641.srv.mediaways.net) by www.linuxtv.org with smtp (Exim 4.34) id 1DIUlZ-0000ER-HX for vdr@linuxtv.org; Mon, 04 Apr 2005 18:49:33 +0200 Received: (qmail 16441 invoked by uid 501); 4 Apr 2005 16:49:43 -0000 X-Authenticated-Sender: macap20001 Received: from dsl-084-058-020-001.arcor-ip.net (dsl-084-058-020-001.arcor-ip.net [84.58.20.1]) by compuserve.de ([10.228.3.105]) with ESMTP via TCP; 04 Apr 2005 16:49:43 -0000 Message-ID: <4251702D.7040504@compuserve.de> Date: Mon, 04 Apr 2005 18:49:49 +0200 From: Martin Cap <macap20001@compuserve.de> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 Thunderbird/0.7 Mnenhy/0.6.0.101 X-Accept-Language: de-de, en-us, en MIME-Version: 1.0 To: Klaus Schmidinger's VDR <vdr@linuxtv.org> Subject: Re: [vdr] Patch: dxr3plugin OSD don't turn pink References: <424A9224.4000608@compuserve.de> <1112217417.31596.17.camel@bobcat.mine.nu> <424E66B0.1030901@ventoso.org> <424E6E6E.9000307@compuserve.de> <424E72B6.8000903@ventoso.org> <424E757F.2040804@ventoso.org> <424E7743.8060801@ventoso.org> <424E7852.60808@ventoso.org> <424E793E.9040202@ventoso.org> <1112448795.23456.48.camel@bobcat.mine.nu> <424ECCA5.1030309@ventoso.org> <1112461894.12964.1.camel@bobcat.mine.nu> <424FD272.2050808@ventoso.org> <424FEA9E.1050207@ventoso.org> <42501BA4.8070902@compuserve.de> <42502096.7030109@ventoso.org> <425022ED.7060008@compuserve.de> <1112556049.24368.75.camel@bobcat.mine.nu> <42505F40.90201@ventoso.org> <42516694.9070900@ventoso.org> In-Reply-To: <42516694.9070900@ventoso.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Klaus Schmidinger's VDR <vdr@linuxtv.org> List-Id: Klaus Schmidinger's VDR <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Mon, 04 Apr 2005 16:49:33 -0000 Status: O X-Status: X-Keywords: X-UID: 1414 |
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
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 :)
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
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." . :)
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: > 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.
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 .
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 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 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.
--- 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