Message ID | 44324322.6080605@syphir.sytes.net |
---|---|
State | New |
Headers |
Received: from c-71-197-74-6.hsd1.ca.comcast.net ([71.197.74.6] helo=nofear.bounceme.net) by www.linuxtv.org with esmtp (Exim 4.50) id 1FQiEb-0007lq-7D for vdr@linuxtv.org; Tue, 04 Apr 2006 11:54:01 +0200 Received: from [10.1.1.66] (hades [10.1.1.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by nofear.bounceme.net (Postfix) with ESMTP id EECC773546 for <vdr@linuxtv.org>; Tue, 4 Apr 2006 02:53:47 -0700 (PDT) Message-ID: <44324322.6080605@syphir.sytes.net> Date: Tue, 04 Apr 2006 02:57:54 -0700 From: "C.Y.M" <syphir@syphir.sytes.net> Organization: CooLNeT User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vdr <vdr@linuxtv.org> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/mixed; boundary="------------080605000809090904080902" Subject: [vdr] hardcoded NTSC/PAL values in VDR? X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: syphir@syphir.sytes.net, VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <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: Tue, 04 Apr 2006 09:54:02 -0000 Status: O X-Status: X-Keywords: X-UID: 8715 |
Commit Message
C.Y.M
April 4, 2006, 9:57 a.m. UTC
There seem to be a few hardcoded values for PAL in VDR's source code. Klaus, can you tell me if any of these would make a difference to a NTSC only system? I know that most tv's in Europe can do both NTSC and PAL. Unfortunately, almost all the tv's in America only support NTSC and cant handle the PAL formats. BR.
Comments
C.Y.M wrote: > There seem to be a few hardcoded values for PAL in VDR's source code. Klaus, can > you tell me if any of these would make a difference to a NTSC only system? I > know that most tv's in Europe can do both NTSC and PAL. Unfortunately, almost > all the tv's in America only support NTSC and cant handle the PAL formats. I guess if you have an NTSC only system these changes should be ok for you. Note to self: make these configurable/automatic after version 1.4 ;-) Klaus > diff -ruN vdr-1.3.45.orig/recording.h vdr-1.3.45/recording.h > --- vdr-1.3.45.orig/recording.h 2006-03-26 08:34:35.000000000 -0800 > +++ vdr-1.3.45/recording.h 2006-03-26 08:36:45.000000000 -0800 > @@ -179,7 +179,7 @@ > }; > > //XXX+ > -#define FRAMESPERSEC 25 > +#define FRAMESPERSEC 30 > > // The maximum size of a single frame (up to HDTV 1920x1080): > #define MAXFRAMESIZE KILOBYTE(512) > --- vdr-1.3.45/dvbosd.c.orig 2006-04-04 02:46:01.000000000 -0700 > +++ vdr-1.3.45/dvbosd.c 2006-04-04 02:47:00.000000000 -0700 > @@ -85,7 +85,7 @@ > return oeBppNotSupported; > if ((Areas[i].Width() & (8 / Areas[i].bpp - 1)) != 0) > return oeWrongAlignment; > - if (Areas[i].Width() < 1 || Areas[i].Height() < 1 || Areas[i].Width() > 720 || Areas[i].Height() > 576) > + if (Areas[i].Width() < 1 || Areas[i].Height() < 1 || Areas[i].Width() > 720 || Areas[i].Height() > 480) > return oeWrongAreaSize; > TotalMemory += Areas[i].Width() * Areas[i].Height() / (8 / Areas[i].bpp); > } > --- vdr-1.3.45/dvbspu.c.orig 2006-04-04 02:46:15.000000000 -0700 > +++ vdr-1.3.45/dvbspu.c 2006-04-04 02:47:21.000000000 -0700 > @@ -56,7 +56,7 @@ > #define setMax(a, b) if (a < b) a = b > > #define spuXres 720 > -#define spuYres 576 > +#define spuYres 480 > > #define revRect(r1, r2) { r1.x1 = r2.x2; r1.y1 = r2.y2; r1.x2 = r2.x1; r1.y2 = r2.y1; }
From: "Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de> To: <vdr@linuxtv.org> Sent: Wednesday, April 05, 2006 1:53 PM Subject: Re: [vdr] hardcoded NTSC/PAL values in VDR? > C.Y.M wrote: >> There seem to be a few hardcoded values for PAL in VDR's source code. >> Klaus, can >> you tell me if any of these would make a difference to a NTSC only >> system? I >> know that most tv's in Europe can do both NTSC and PAL. Unfortunately, >> almost >> all the tv's in America only support NTSC and cant handle the PAL >> formats. > > I guess if you have an NTSC only system these changes should be ok for > you. > > Note to self: make these configurable/automatic after version 1.4 ;-) > > Klaus Umm - guess this didn't make in into the current release (vdr-1.4.1)?
Simon Baxter wrote: > From: "Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de> > To: <vdr@linuxtv.org> > Sent: Wednesday, April 05, 2006 1:53 PM > Subject: Re: [vdr] hardcoded NTSC/PAL values in VDR? > > >> C.Y.M wrote: >>> There seem to be a few hardcoded values for PAL in VDR's source code. >>> Klaus, can >>> you tell me if any of these would make a difference to a NTSC only >>> system? I >>> know that most tv's in Europe can do both NTSC and PAL. Unfortunately, >>> almost >>> all the tv's in America only support NTSC and cant handle the PAL >>> formats. >> I guess if you have an NTSC only system these changes should be ok for >> you. >> >> Note to self: make these configurable/automatic after version 1.4 ;-) >> >> Klaus > > Umm - guess this didn't make in into the current release (vdr-1.4.1)? "After version 1.4" actually means "in version 1.5.x" ;-) Klaus
Any reason this can't be added in the next developement version? There are many NTSC vdr users with more appearing all the time. Enough that I would hope fixing any existing NTSC/PAL issues would be a high priority. Especially considering things like 25fps vs. 30fps recordings, and screen resolution are pretty significant! On 6/20/06, Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote: > > Simon Baxter wrote: > > From: "Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de> > > To: <vdr@linuxtv.org> > > Sent: Wednesday, April 05, 2006 1:53 PM > > Subject: Re: [vdr] hardcoded NTSC/PAL values in VDR? > > > > > >> C.Y.M wrote: > >>> There seem to be a few hardcoded values for PAL in VDR's source code. > >>> Klaus, can > >>> you tell me if any of these would make a difference to a NTSC only > >>> system? I > >>> know that most tv's in Europe can do both NTSC and PAL. Unfortunately, > >>> almost > >>> all the tv's in America only support NTSC and cant handle the PAL > >>> formats. > >> I guess if you have an NTSC only system these changes should be ok for > >> you. > >> > >> Note to self: make these configurable/automatic after version 1.4 ;-) > >> > >> Klaus > > > > Umm - guess this didn't make in into the current release (vdr-1.4.1)? > > "After version 1.4" actually means "in version 1.5.x" ;-) > > Klaus > > _______________________________________________ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr >
hotwings wrote: > Any reason this can't be added in the next developement version? There Version 1.5 *is* the next development version ;-) Klaus > are many NTSC vdr users with more appearing all the time. Enough that I > would hope fixing any existing NTSC/PAL issues would be a high > priority. Especially considering things like 25fps vs. 30fps > recordings, and screen resolution are pretty significant! > > On 6/20/06, *Klaus Schmidinger* <Klaus.Schmidinger@cadsoft.de > <mailto:Klaus.Schmidinger@cadsoft.de>> wrote: > > Simon Baxter wrote: > > From: "Klaus Schmidinger" <Klaus.Schmidinger@cadsoft.de > <mailto:Klaus.Schmidinger@cadsoft.de>> > > To: <vdr@linuxtv.org <mailto:vdr@linuxtv.org>> > > Sent: Wednesday, April 05, 2006 1:53 PM > > Subject: Re: [vdr] hardcoded NTSC/PAL values in VDR? > > > > > >> C.Y.M wrote: > >>> There seem to be a few hardcoded values for PAL in VDR's source > code. > >>> Klaus, can > >>> you tell me if any of these would make a difference to a NTSC only > >>> system? I > >>> know that most tv's in Europe can do both NTSC and PAL. > Unfortunately, > >>> almost > >>> all the tv's in America only support NTSC and cant handle the PAL > >>> formats. > >> I guess if you have an NTSC only system these changes should be > ok for > >> you. > >> > >> Note to self: make these configurable/automatic after version > 1.4 ;-) > >> > >> Klaus > > > > Umm - guess this didn't make in into the current release (vdr-1.4.1)? > > "After version 1.4" actually means "in version 1.5.x" ;-) > > Klaus
hotwings wrote:
> Any reason this can't be added in the next developement version?
The idea behind the stable 1.4 development is that only low-risk changes
will go into 1.4.x versions, and no new features. The risk for updaters
has to be as minimal as possible. More progressive development will
start with the 1.5.x builds.
In this situation:
- The patch is available for everyone who wants to try it
- AFAIK, VDR runs on NTSC and just has some minor problems
- A final fix would be considerably more complex (*)
- The chances are fixing it for a few NTSC users vs. risking to break it
for many PAL users. Sorry.
(*) for example, this line:
-#define FRAMESPERSEC 25
+#define FRAMESPERSEC 30
This affects the timeline of recordings, correcting the length (in mins
and secs) of NTSC recordings, but also breaks it for PAL recordings.
Making it configurable is nice, but a 'real' fix should pick the right
value based on the recording itself, so PAL and NTSC recordings can
co-exist.
Cheers,
Udo
C.Y.M wrote: > There seem to be a few hardcoded values for PAL in VDR's source code. Klaus, can > you tell me if any of these would make a difference to a NTSC only system? I > know that most tv's in Europe can do both NTSC and PAL. Unfortunately, almost > all the tv's in America only support NTSC and cant handle the PAL formats. > > BR. There is a plugin out there that handles OSD resizing and everything else necessary to watch NTSC. It was posted to the VDR List by Andreas Brugger on December 31st 2005. You can find it here: http://www.vdr-portal.de/board/thread.php?threadid=43516 I've been using the plugin ever since January and never had any issues with NTSC material. Why don't you give it a try for the time being?! André
It should be noted that there are a LOT more than 'a few NTSC users'. This is a bigger problem than you think and I wouldn't expect europeans to be aware of it unless it's pointed out. Bottom line is this -is- is a significant issue for a lot more users than you may realize. Thankfully Klaus knows this and has said it will be addressed in the next development run. Cheers! On 6/20/06, Udo Richter <udo_richter@gmx.de> wrote: > > - The chances are fixing it for a few NTSC users vs. risking to break it > for many PAL users. Sorry. >
hotwings wrote: > this -is- a significant issue for a lot more users than you may > realize. Thankfully Klaus knows this and has said it will be > addressed in the next development run. Don't get me wrong, I agree that remaining NTSC issues should be fixed. However, VDR is in a stability phase of development, and we cannot afford to break everything again, now that the dust of the 1.3.x development settles. > It should be noted that there are a LOT more than 'a few NTSC users'. I don't see NTSC as 'just a few users', I see it as way too few NTSC users. If we want to get out of the German or European corner, we need to be more attractive to NTSC users. > This is a bigger problem than you think and I wouldn't expect > europeans to be aware of it unless it's pointed out. If you want to speed things up: Use the patch posted in this thread, test it and report all remaining NTSC issues. This will give the NTSC development a quick start as soon as 1.5.x development starts. Cheers, Udo
diff -ruN vdr-1.3.45.orig/recording.h vdr-1.3.45/recording.h --- vdr-1.3.45.orig/recording.h 2006-03-26 08:34:35.000000000 -0800 +++ vdr-1.3.45/recording.h 2006-03-26 08:36:45.000000000 -0800 @@ -179,7 +179,7 @@ }; //XXX+ -#define FRAMESPERSEC 25 +#define FRAMESPERSEC 30 // The maximum size of a single frame (up to HDTV 1920x1080): #define MAXFRAMESIZE KILOBYTE(512) --- vdr-1.3.45/dvbosd.c.orig 2006-04-04 02:46:01.000000000 -0700 +++ vdr-1.3.45/dvbosd.c 2006-04-04 02:47:00.000000000 -0700 @@ -85,7 +85,7 @@ return oeBppNotSupported; if ((Areas[i].Width() & (8 / Areas[i].bpp - 1)) != 0) return oeWrongAlignment; - if (Areas[i].Width() < 1 || Areas[i].Height() < 1 || Areas[i].Width() > 720 || Areas[i].Height() > 576) + if (Areas[i].Width() < 1 || Areas[i].Height() < 1 || Areas[i].Width() > 720 || Areas[i].Height() > 480) return oeWrongAreaSize; TotalMemory += Areas[i].Width() * Areas[i].Height() / (8 / Areas[i].bpp); } --- vdr-1.3.45/dvbspu.c.orig 2006-04-04 02:46:15.000000000 -0700 +++ vdr-1.3.45/dvbspu.c 2006-04-04 02:47:21.000000000 -0700 @@ -56,7 +56,7 @@ #define setMax(a, b) if (a < b) a = b #define spuXres 720 -#define spuYres 576 +#define spuYres 480 #define revRect(r1, r2) { r1.x1 = r2.x2; r1.y1 = r2.y2; r1.x2 = r2.x1; r1.y2 = r2.y1; }