Re: [vdr] Frames per second PAL vs. NTSC
On 05/01/2009, Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote: In order to correctly handle the progress indicator for NTSC recordings I'm now determining the frame rate from the actual data. With PAL's 25 frames per second the distance between two frames is 3600 ticks of 1/9s. With NTSC this number is 3003, which results in 29.97002997003 fps. Is NTSC's frame rate really that odd? I thought it would be an even 30 fps. Klaus Yes http://en.wikipedia.org/wiki/Frame_rate http://en.wikipedia.org/wiki/NTSC ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Frames per second PAL vs. NTSC
Klaus Schmidinger wrote:
Detecting the frame rate is done by looking at the PTS values, so
it is independent of the actual broadcast system.
Using this code for converting frame numbers into hh:mm:ss.ff...
#include math.h
#include stdio.h
int main(void)
{
double FramesPerSecond = double(9) / 3003;
//FramesPerSecond = 25;
for (int Index = 0; Index 1; Index++) {
double Seconds;
int f = round(modf(Index / FramesPerSecond, Seconds) *
FramesPerSecond) + 1;
int s = int(Seconds);
int m = s / 60 % 60;
int h = s / 3600;
s %= 60;
printf(%3d , Index);
printf(%15.9f , Index / FramesPerSecond);
printf(%d:%02d:%02d.%02d, h, m, s, f);
if (f 30) printf( *);
printf(\n);
}
}
... sometimes results in a 31st frame:
9978 332.93260 0:05:32.29
9979 332.96597 0:05:32.30
9980 332.99933 0:05:32.31 *
9981 333.03270 0:05:33.02
9982 333.06607 0:05:33.03
Any ideas how to fix this?
eg
- int f = round(modf(Index / FramesPerSecond, Seconds) * FramesPerSecond) + 1;
+ int f = round(modf(Index / FramesPerSecond, Seconds) * FramesPerSecond + 0.5
);
note that some 'seconds' will contain only 29 frames. (see index 510 in the
original
and 1019 in the fixed version)
artur
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Which extension for TS files?
On 05.01.2009 11:01, Klaus Schmidinger wrote: On 05.01.2009 00:34, Malte Schröder wrote: On Sun, 04 Jan 2009 22:34:17 +0100 Klaus Schmidinger Klaus.Schmidinger at cadsoft.de wrote: I think the option is clearly defined now. I little thing that always annoyed me was that every recoding file had the .vdr extension, whatever the actual contents (it seemed like the file name was used as an extension). See: index.vdr info.vdr marks.vdr resume.vdr Maybe you will find an opportunity to improve this at the same time... Well, how about leaving the .vdr part away altogether? I would vote for that. Having .ts for the recording has the nice effect that media-players and who knows what can just handle the recordings. The other files I would consider VDR private data which is not standardized like TS. So I do not see a point in them having any extension at all. If they are in a .rec-directory it should be pretty clear what a file named index contains. I also strongly tend to drop the '.vdr' extensions and have the files just named plain index, info, marks and resume. dropping the extensions is bad for windows users, since files without extension cannot be assigned to a specific application (like notepad). so i vote for the suggestion of Matthias Schniedermeyer: .dat for binary (e.g. index.dat) .txt for text content (e.g. info.txt) Greets Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Which extension for TS files?
On 05/01/2009, Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote: I also strongly tend to drop the '.vdr' extensions and have the files just named plain index, info, marks and resume. Klaus I suppose if the manual page is updated accordingly it shouldn't be a problem (: ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Frames per second PAL vs. NTSC
On 05.01.2009 11:57, Theunis Potgieter wrote:
On 05/01/2009, Theunis Potgieter theunis.potgie...@gmail.com wrote:
On 05/01/2009, Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote:
In order to correctly handle the progress indicator for NTSC
recordings I'm now determining the frame rate from the
actual data. With PAL's 25 frames per second the distance
between two frames is 3600 ticks of 1/9s. With NTSC
this number is 3003, which results in 29.97002997003 fps.
Is NTSC's frame rate really that odd? I thought it would
be an even 30 fps.
Klaus
Yes
http://en.wikipedia.org/wiki/Frame_rate
http://en.wikipedia.org/wiki/NTSC
http://en.wikipedia.org/wiki/Sampling_frequency
Please do not always _assume_ that it is actually PAL or NTSC, since
PAL or NTSC defines colour encoding, but the most of the time the
usual frame rates are associated with the colour encoding. However
like I've stated before nvidia on their newer drivers output PAL on
60Hz (on the tv-out of the card), not even 59.94006Hz, or 50Hz like
PAL is supposed to be for interlaced. The older CRT TVs (interlaced
monitors) expect PAL to run 50Hz. You can confirm this with xvidtune.
Detecting the frame rate is done by looking at the PTS values, so
it is independent of the actual broadcast system.
Using this code for converting frame numbers into hh:mm:ss.ff...
#include math.h
#include stdio.h
int main(void)
{
double FramesPerSecond = double(9) / 3003;
//FramesPerSecond = 25;
for (int Index = 0; Index 1; Index++) {
double Seconds;
int f = round(modf(Index / FramesPerSecond, Seconds) * FramesPerSecond)
+ 1;
int s = int(Seconds);
int m = s / 60 % 60;
int h = s / 3600;
s %= 60;
printf(%3d , Index);
printf(%15.9f , Index / FramesPerSecond);
printf(%d:%02d:%02d.%02d, h, m, s, f);
if (f 30) printf( *);
printf(\n);
}
}
... sometimes results in a 31st frame:
9978 332.93260 0:05:32.29
9979 332.96597 0:05:32.30
9980 332.99933 0:05:32.31 *
9981 333.03270 0:05:33.02
9982 333.06607 0:05:33.03
Any ideas how to fix this?
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Frames per second PAL vs. NTSC
Klaus Schmidinger wrote:
On 05.01.2009 13:31, Artur Skawina wrote:
Klaus Schmidinger wrote:
Detecting the frame rate is done by looking at the PTS values, so
it is independent of the actual broadcast system.
Using this code for converting frame numbers into hh:mm:ss.ff...
#include math.h
#include stdio.h
int main(void)
{
double FramesPerSecond = double(9) / 3003;
//FramesPerSecond = 25;
for (int Index = 0; Index 1; Index++) {
double Seconds;
int f = round(modf(Index / FramesPerSecond, Seconds) *
FramesPerSecond) + 1;
int s = int(Seconds);
int m = s / 60 % 60;
int h = s / 3600;
s %= 60;
printf(%3d , Index);
printf(%15.9f , Index / FramesPerSecond);
printf(%d:%02d:%02d.%02d, h, m, s, f);
if (f 30) printf( *);
printf(\n);
}
}
... sometimes results in a 31st frame:
9978 332.93260 0:05:32.29
9979 332.96597 0:05:32.30
9980 332.99933 0:05:32.31 *
9981 333.03270 0:05:33.02
9982 333.06607 0:05:33.03
Any ideas how to fix this?
eg
- int f = round(modf(Index / FramesPerSecond, Seconds) * FramesPerSecond) +
1;
+ int f = round(modf(Index / FramesPerSecond, Seconds) * FramesPerSecond +
0.5 );
note that some 'seconds' will contain only 29 frames. (see index 510 in the
original
and 1019 in the fixed version)
I'm afraid this isn't feasible. The '+1' is done to make the first frame
(at Index 0) have number '1'. With your change it would be numbered '0'.
Klaus
no, try it :)
and you can also drop the round call:
- int f = round(modf(Index / FramesPerSecond, Seconds) * FramesPerSecond) + 1;
+ int f = modf((Index + 0.5) / FramesPerSecond, Seconds) * FramesPerSecond + 1;
which will move the 'missing' frames to the same locations as in the original.
artur
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Frames per second PAL vs. NTSC
On Mon, 5 Jan 2009 12:57:41 +0200 Theunis Potgieter theunis.potgie...@gmail.com wrote: Please do not always _assume_ that it is actually PAL or NTSC, since PAL or NTSC defines colour encoding, but the most of the time the usual frame rates are associated with the colour encoding. However like I've stated before nvidia on their newer drivers output PAL on 60Hz (on the tv-out of the card), not even 59.94006Hz, or 50Hz like PAL is supposed to be for interlaced. The older CRT TVs (interlaced monitors) expect PAL to run 50Hz. You can confirm this with xvidtune. I expect you've already checked this, but have you set the TVStandard option in xorg.conf? Also, it may not be treating the TV as the primary display but locking the frequency to whatever it thinks is the primary display, and if it's an LCD, by default the Nvidia driver always outputs the maximum resolution, scaling the configure resolution to fill it, unless you add: Option FlatPanelProperties Scaling = Native And xrandr will report refresh rates incorrectly unless you add: Option DynamicTwinView false -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Support for different frame rates? (Re: Frames per second PAL vs. NTSC)
On Mon, 05 Jan 2009 20:48:57 +0200 Pasi Juppo p...@juppo.fi wrote: Partly question and partly proposal. Maybe this is not VDR related but e.g. xineliboutput etc. related. I'm not an expert on satellite systems but I'd assume that there are different frame rates in satellite systems available (shall be compared to cable and terresterial as well). Instead of doing pull-down/pull-up conversions it would be nice to playback according to the framerate of the material. This should be an option as it is fully dependant on the output and display devices whether they support this feature or not. The same applies also to mplayer-plugin. Would this be possible to implement? Yes, boxstar does this, but it's a bit limited by its current reliance on external players. DirectFB players can set the screen mode, while in X boxstar sets it first with xrandr. Boxstar has to be able to use mplayer -identify on the stream first to determine the frame rate and it can't change it midstream. Boxstar can't tell the frame rate of what vdr-sxfe or whatever is using, so it has to use an option. Luckily most people receive transmissions all in the same frame rate even if they watch foreign DVDs or downloaded videos, so boxstar can cope with this. -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Frames per second PAL vs. NTSC
On Monday 05 January 2009 18:35:26 Tony Houghton wrote: I expect you've already checked this, but have you set the TVStandard option in xorg.conf? Also it seems that 640x480 even in PAL mode comes out at 60Hz. Set it to 800x600 instead and you get full field rate at 50Hz. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Which extension for TS files?
On 05.01.2009 00:34, Malte Schröder wrote: On Sun, 04 Jan 2009 22:34:17 +0100 Klaus Schmidinger klaus.schmidin...@cadsoft.de wrote: I think the option is clearly defined now. I little thing that always annoyed me was that every recoding file had the .vdr extension, whatever the actual contents (it seemed like the file name was used as an extension). See: index.vdr info.vdr marks.vdr resume.vdr Maybe you will find an opportunity to improve this at the same time... Well, how about leaving the .vdr part away altogether? I would vote for that. Having .ts for the recording has the nice effect that media-players and who knows what can just handle the recordings. The other files I would consider VDR private data which is not standardized like TS. So I do not see a point in them having any extension at all. If they are in a .rec-directory it should be pretty clear what a file named index contains. I also strongly tend to drop the '.vdr' extensions and have the files just named plain index, info, marks and resume. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Frames per second PAL vs. NTSC
Klaus Schmidinger wrote: In order to correctly handle the progress indicator for NTSC recordings I'm now determining the frame rate from the actual data. With PAL's 25 frames per second the distance between two frames is 3600 ticks of 1/9s. With NTSC this number is 3003, which results in 29.97002997003 fps. Is NTSC's frame rate really that odd? I thought it would be an even 30 fps. Klaus The last paragraph under Color Encoding explains the odd number for the NTSC frame rate: http://en.wikipedia.org/wiki/NTSC#Color_encoding While taking care of the correct display of time for NTSC and PAL, please also adjust the OSD for PAL and NTSC. Right now it takes a plugin called videosystem, which does not seem to be maintained anymore to alter the size of the OSD when playing back NTSC video. Without this plugin parts of the OSD will be out of bounds. André ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Support for different frame rates? (Re: Frames per second PAL vs. NTSC)
On Mon, 5 Jan 2009, Pasi Juppo wrote: Would this be possible to implement? There's already a modeswitching patch using xrandr for vdr-sxfe available on VDR-Portal. However, it lacks support for interpreting frame rate of source video, but it could be added... BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Frames per second PAL vs. NTSC
On 05.01.2009 13:49, Artur Skawina wrote:
Klaus Schmidinger wrote:
On 05.01.2009 13:31, Artur Skawina wrote:
Klaus Schmidinger wrote:
Detecting the frame rate is done by looking at the PTS values, so
it is independent of the actual broadcast system.
Using this code for converting frame numbers into hh:mm:ss.ff...
#include math.h
#include stdio.h
int main(void)
{
double FramesPerSecond = double(9) / 3003;
//FramesPerSecond = 25;
for (int Index = 0; Index 1; Index++) {
double Seconds;
int f = round(modf(Index / FramesPerSecond, Seconds) *
FramesPerSecond) + 1;
int s = int(Seconds);
int m = s / 60 % 60;
int h = s / 3600;
s %= 60;
printf(%3d , Index);
printf(%15.9f , Index / FramesPerSecond);
printf(%d:%02d:%02d.%02d, h, m, s, f);
if (f 30) printf( *);
printf(\n);
}
}
... sometimes results in a 31st frame:
9978 332.93260 0:05:32.29
9979 332.96597 0:05:32.30
9980 332.99933 0:05:32.31 *
9981 333.03270 0:05:33.02
9982 333.06607 0:05:33.03
Any ideas how to fix this?
eg
- int f = round(modf(Index / FramesPerSecond, Seconds) * FramesPerSecond)
+ 1;
+ int f = round(modf(Index / FramesPerSecond, Seconds) * FramesPerSecond +
0.5 );
note that some 'seconds' will contain only 29 frames. (see index 510 in the
original
and 1019 in the fixed version)
I'm afraid this isn't feasible. The '+1' is done to make the first frame
(at Index 0) have number '1'. With your change it would be numbered '0'.
Klaus
no, try it :)
I did - but I just replaced 1 with 0.5 and totally missed that you have also
changed the bracketing - sorry.
and you can also drop the round call:
- int f = round(modf(Index / FramesPerSecond, Seconds) * FramesPerSecond) +
1;
+ int f = modf((Index + 0.5) / FramesPerSecond, Seconds) * FramesPerSecond +
1;
which will move the 'missing' frames to the same locations as in the original.
This looks good!
Thanks.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Frames per second PAL vs. NTSC
In order to correctly handle the progress indicator for NTSC recordings I'm now determining the frame rate from the actual data. With PAL's 25 frames per second the distance between two frames is 3600 ticks of 1/9s. With NTSC this number is 3003, which results in 29.97002997003 fps. Is NTSC's frame rate really that odd? I thought it would be an even 30 fps. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Which extension for TS files?
On 05.01.2009 19:06, Andreas Besse wrote: On 05.01.2009 11:01, Klaus Schmidinger wrote: On 05.01.2009 00:34, Malte Schröder wrote: On Sun, 04 Jan 2009 22:34:17 +0100 Klaus Schmidinger Klaus.Schmidinger at cadsoft.de wrote: I think the option is clearly defined now. I little thing that always annoyed me was that every recoding file had the .vdr extension, whatever the actual contents (it seemed like the file name was used as an extension). See: index.vdr info.vdr marks.vdr resume.vdr Maybe you will find an opportunity to improve this at the same time... Well, how about leaving the .vdr part away altogether? I would vote for that. Having .ts for the recording has the nice effect that media-players and who knows what can just handle the recordings. The other files I would consider VDR private data which is not standardized like TS. So I do not see a point in them having any extension at all. If they are in a .rec-directory it should be pretty clear what a file named index contains. I also strongly tend to drop the '.vdr' extensions and have the files just named plain index, info, marks and resume. dropping the extensions is bad for windows users, since files without extension cannot be assigned to a specific application (like notepad). so i vote for the suggestion of Matthias Schniedermeyer: .dat for binary (e.g. index.dat) .txt for text content (e.g. info.txt) I've already dropped them. Besides, these files are just auxiliary internal files for VDR's very own purposes. There should normally be no need to edit them at all. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] 1:1 pixel mapping - a waste of time?
As Im just starting to get vdr working, I was wondering if 1:1 pixel mapping between the video card (nvidia onboard HDMI output) and my flat panel (Samsung plasma) is a waste of time. When looking at a computer generated image like the desktop, its going to make a difference, but with broadcast material (SD mostly), I imagine that the material is scaled anyway to fit the resolution of the panel (which in my case I think is 1024x720, but that has a bit of overscan). So it wont be 1:1 anyway, or am I wrong here? I know this is a bit off topic, but there seems to be a fair bit of experience here. -- Scott ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1:1 pixel mapping - a waste of time?
2009/1/6 Scott sc...@waye.co.uk: As Im just starting to get vdr working, I was wondering if 1:1 pixel mapping between the video card (nvidia onboard HDMI output) and my flat panel (Samsung plasma) is a waste of time. When looking at a computer generated image like the desktop, its going to make a difference, but with broadcast material (SD mostly), I imagine that the material is scaled anyway to fit the resolution of the panel (which in my case I think is 1024x720, but that has a bit of overscan). So it wont be 1:1 anyway, or am I wrong here?I know this is a bit off topic, but there seems to be a fair bit of experience here. I'd say it's not a waste of time. In general, it is a good idea to avoid any (unnecessary) processing. If you do not setup your video card to your display 1:1 to your panel's native resolution, you're most likely going to get an extra scaling of the video image (which is totally unnecessary and degrades the image). For example, if your panel is 1024 x 720, and your video card is setup for 1280 x 768, then you'd end up first scanling a PAL/NTSC/whatever video to the 1280 x 768 and then your panel is going to scale it to 1024 x 720. You'd get better results if you'll scale straight to the native resolution of the panel via the video card, or set the video card to the native resolution of the source material and let the panel do all the scaling. I don't know how to do the latter, and even if it is possible in all cases. In my setup, I have set up my video card to 1:1 to the panel I have (fullHD), since I have material in several different resolutions, and also use a desktop on my VDR box.It's more hassle free this way, if I would have chosen the latter case, then I would be constantly chancing resolution. It should be quite easy to setup 1:1 pixel mapping with any reasonably new display, video card and X.org, since the X.org uses EDID information quite well these days. Though, in practice, the DVB broadcasts are so much degraded by the mpeg compressing process at least here where I live, so it doesn't actually matter that much how you do the scaling ;=). YMMV. In any case, a (single) scaling process gives better results than 2 x a scaling process. -- Ville Aakko - ville.aa...@gmail.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 1:1 pixel mapping - a waste of time?
On Tue, 6 Jan 2009 01:17:52 +0200 Jukka Vaisanen jukka.vaisa...@exomi.com wrote: HDMI uses DVI signalling for the video (and audio is hidden in a vertical blanking time slot believe it or not) so it may seem like just another connector.. however in their finite wisdom the HDMI standardization people decided that HDMI will not support arbitrary resolutions, but instead only the existing (and back then, planned) broadcast resolutions: - 576i/p (pal) and 480i/p (ntsc) - 720p (1280x720) - 1080i and 1080p (1920x1080) How is 24p (ie 24fps) managed? -- TH * http://www.realh.co.uk ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ANNOUNCE vdr-ttxtsubs 0.0.8
Hello! A new version of the VDR Teletext Subtitles plug-in was just released. Development site: http://projects.vdr-developer.org/projects/show/plg-ttxtsubs Recent Changes: - Updated Italien translation provided by Diego Pierotto - Updated Russian translation provided by Oleg Roitburd (Closes #47) - Fixed displaying of multiple rows when antialiasing is enabled by aquiring a single OSD area for all rows - Thx to Rolf Ahrenberg (Closes #24) On gentoo distri was on ttxtsubs-0.0.5 any patches for the scandinavien users needed. http://www.saunalahti.fi/~rahrenbe/vdr/patches/ - vdr-ttxtsubs-0.0.5-lusikkahaarukka-edition.diff.gz - vdr-ttxtsubs-0.0.5-raastinrauta-edition.diff.gz Befor i will add the new version to the gentoo portage, can a user from the northern countrys confirm, that no patches for some fixes needed? Thanks Joerg -- Regards Gentoo Developer Joerg Bornkessel hd_bru...@gentoo.org ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ANNOUNCE vdr-ttxtsubs 0.0.8
Joerg Bornkessel wrote: http://www.saunalahti.fi/~rahrenbe/vdr/patches/ - vdr-ttxtsubs-0.0.5-lusikkahaarukka-edition.diff.gz - vdr-ttxtsubs-0.0.5-raastinrauta-edition.diff.gz The raastinrauta-edition-patch is included: http://projects.vdr-developer.org/git/?p=vdr-plugin-ttxtsubs.git;a=commit;h=fa04d4b0ec432c4115eb52c3ec848e3e9f7b515e Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ANNOUNCE vdr-ttxtsubs 0.0.8
Hello Tobias,
Tobi schrieb:
A new version of the VDR Teletext Subtitles plug-in was just released.
Downloads:
http://projects.vdr-developer.org/projects/list_files/plg-ttxtsubs
seems not to compile, I get errormessages:
video:/usr/local/video/VDR/PLUGINS/src/ttxtsubs# make
g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c
-DPLUGIN_NAME_I18N='ttxtsubs'
-I/usr/local/src/v4l-dvb-3cc7daa31234/linux/include -I../../../include
-I/usr/local/src/v4l-dvb-3cc7daa31234/linux/include ttxtsubs.c
ttxtsubs.c:23:34: error: vdr/vdrttxtsubshooks.h: No such file or directory
ttxtsubsrecorder.h:26: error: expected class-name before '{' token
ttxtsubs.c:115: error: expected class-name before ',' token
ttxtsubs.c:150: error: ISO C++ forbids declaration of
'cTtxtSubsRecorderBase' with no type
ttxtsubs.c:150: error: 'cTtxtSubsRecorderBase' declared as a 'virtual' field
ttxtsubs.c:150: error: expected ';' before '*' token
ttxtsubs.c: In member function 'virtual bool cPluginTtxtsubs::Start()':
ttxtsubs.c:269: error: 'HookAttach' was not declared in this scope
ttxtsubs.c: At global scope:
ttxtsubs.c:479: error: expected constructor, destructor, or type
conversion before '*' token
make: *** [ttxtsubs.o] Error 1
Is that plugin a replacement for vdr-osdteletext-0.6.0.tgz?
Bye
Matthias
--
Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the universe trying to
produce bigger and better idiots. So far, the universe is winning. --
Rich Cook
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ANNOUNCE vdr-ttxtsubs 0.0.8
On Tue, Jan 06, 2009 at 01:51:25AM +0100, Matthias Fechner wrote: seems not to compile, I get errormessages: ... ttxtsubs.c:23:34: error: vdr/vdrttxtsubshooks.h: No such file or directory ... You haven't applied patch to the vdr core. It's included in the package. Is that plugin a replacement for vdr-osdteletext-0.6.0.tgz? No. osdteletext is to view teletext pages on OSD, ttxtsubs is to show teletext subtitles. It's subtitles which are sent in teletext pages (of course you can see those with osdteletext too, but it looks ugly and can't include subtitles in recordings etc..) And while we're at the topic, is it possible to have border colour for the text in ttxtsubs? When i select white as text color, i can't see anything when there's something white on video under text. Solution so far has been to use little transparent background, but it looks ugly, not like normal text should look like (white text with few pixels thick black border) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Support for different frame rates? (Re: Frames per second PAL vs. NTSC)
Rolf Ahrenberg wrote: On Mon, 5 Jan 2009, Pasi Juppo wrote: Would this be possible to implement? There's already a modeswitching patch using xrandr for vdr-sxfe available on VDR-Portal. However, it lacks support for interpreting frame rate of source video, but it could be added... Half way there already! Hopefully someone can add the support to interprete the frame rate of the source. This would be quite unique feature to my understanding. Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
