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
Re: [vdr] Support for different frame rates? (Re: Frames per second PAL vs. NTSC)
Tony Houghton wrote: > On Mon, 05 Jan 2009 20:48:57 +0200 > Pasi Juppo 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. > > I checked boxstar web-page (http://boxstar.sourceforge.net/index.html) and I have to say that the goal of the project is ambiguous. Hopefully the developer can actually do it. Br, Pasi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Frames per second PAL vs. NTSC
Maybe these links will help: http://cnyack.homestead.com/files/modulation/ntsc_sig.htm http://en.wikipedia.org/wiki/Frame_rate http://en.wikipedia.org/wiki/NTSC http://www.afterdawn.com/glossary/terms/ntsc.cfm http://www.fixya.com/support/t174610-ntsc_frame_rate_29_97_hz - Original Message - From: "Klaus Schmidinger" To: Sent: Monday, January 05, 2009 3:31 AM Subject: [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 ___ 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] 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
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] 1:1 pixel mapping - a waste of time?
24p is just a framerate, in HD it's actually 1080p but with 24 frames per second instead of 60. There are also NTSC DVDs with 24p video but that's a whole different story that we won't get into.. - Vaizki P.S. Sorry for the awful Outlook quote style.. Will work on fixing it. -Original Message- From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Tony Houghton Sent: 6. tammikuuta 2009 2:08 To: vdr@linuxtv.org Subject: Re: [vdr] 1:1 pixel mapping - a waste of time? On Tue, 6 Jan 2009 01:17:52 +0200 "Jukka Vaisanen" 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 ___ 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 ___ 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" 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] 1:1 pixel mapping - a waste of time?
Yes, it's a good idea to get 1:1 pixel mapping on your display. Double scaling (first pc, then display) is not a good idea, ever. But, some problems arise: 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) The world is full of TVs with 1366x768 and other weird resolutions. There are also plasmas with 1024x768 etc "standard computer resolutions". The big surprise to many people is that even though DVI signalling could carry these native resolutions, the displays themselves won't accept / sync to them. And they don't advertise them in the EDID data so you have to force your computer to that resolution / refresh to even try it (and fail). The only true 720p displays I have seen are rear-projection TVs and data/av projectors. They will accept their native resolution of 1280x720 over HDMI, however getting rid of overscan to get 1:1 is another matter.. Then a solution: I used to have a Panasonic plasma with a similar non-standard resolution and I used the VGA port with it to automatically get a 1:1 pixel display as it's intended for PC display use. Yes VGA is not optimal but at that resolution and a 1 meter cable, who cares... Today I have a full HD 1920x1080 panel with an option for "exact scan" which gives me 1:1 pixels (without overscan) out of the box over HDMI, I just run normal 1920x1...@60hz out of my computers. And finally a question: If someone can tell me how to get 576i over HDMI out from VDR, please do. That way I could use my external HQV Reon video scaler to upscale it.. Of course it would need to allow me to switch modes for 720p and 1080i also based on broadcast resolution ;) - Vaizki From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf Of Scott Sent: 6. tammikuuta 2009 6:30 To: vdr@linuxtv.org Subject: [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 : > 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
[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] 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 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
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] Support for different frame rates? (Re: Frames per second PAL vs. NTSC)
On Mon, 05 Jan 2009 20:48:57 +0200 Pasi Juppo 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
[vdr] Support for different frame rates? (Re: Frames per second PAL vs. NTSC)
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? Br, Pasi ___ 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 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] 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] Frames per second PAL vs. NTSC
On Mon, 5 Jan 2009 12:57:41 +0200 "Theunis Potgieter" 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
[vdr] Plugins API
Hello All! I want to use an plugin for vdr, lets say x but when I tray to compile it, it says wrong api or old api. Question: 1. is ther any api specification or documentation for vdr for plugin development? 2. or how to port old plugins to new api? ___ 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
#include
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
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
>>> #include
>>>
>>> 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 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
>> #include
>>
>> 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
___
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
> #include
>
> 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
Re: [vdr] Frames per second PAL vs. NTSC
On 05.01.2009 11:57, Theunis Potgieter wrote:
> On 05/01/2009, Theunis Potgieter wrote:
>> On 05/01/2009, 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
>>
>>
>> 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
#include
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: > 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] Frames per second PAL vs. NTSC
On 05/01/2009, Theunis Potgieter wrote: > On 05/01/2009, 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 > > > 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. ___ 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, 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 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
[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, Klaus Schmidinger 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] 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 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
