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.
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
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
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 (:
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
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...
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
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
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.
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
23 matches
Mail list logo