hardcoded NTSC/PAL values in VDR?

Message ID 44324322.6080605@syphir.sytes.net
State New
Headers

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

Klaus Schmidinger April 5, 2006, 8:53 p.m. UTC | #1
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; }
  
Linux TV June 20, 2006, 6:35 p.m. UTC | #2
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)?
  
Klaus Schmidinger June 20, 2006, 6:40 p.m. UTC | #3
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
  
VDRU VDRU June 20, 2006, 9:11 p.m. UTC | #4
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
>
  
Klaus Schmidinger June 20, 2006, 9:24 p.m. UTC | #5
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
  
Udo Richter June 20, 2006, 10:57 p.m. UTC | #6
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
  
André Weidemann June 21, 2006, 7:56 a.m. UTC | #7
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é
  
VDRU VDRU June 23, 2006, 4:46 p.m. UTC | #8
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.
>
  
Udo Richter June 23, 2006, 11:26 p.m. UTC | #9
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
  

Patch

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