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
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
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 --
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 re
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 -
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=comm
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 M
> 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
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 tha
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
ano
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 differ
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 broadc
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
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 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
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
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
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 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 nv
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?
__
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
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 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...
>>
>> ---
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
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 fra
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 resul
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
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
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, 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 (:
_
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 l
31 matches
Mail list logo
