Re: [vdr] TV Standards option for vdr-1.5.x
Stone wrote: Hi, In all the prevous versions of VDR, I have had to patch the FRAMESPERSECOND and change the rest of the hardcoded PAL values in VDR for my NTSC television. Is making this an option in VDR on the TODO list? I never had to patch my VDR to make it play NTSC properly. Have you ever tried the videosystem plugin? I have been using it for quite some time and it always worked flawlessly. It can be found here: http://www.vdr-portal.de/board/thread.php?threadid=43516 For VDR > 1.4.4 You need a patch to make it compile without errors. This one can be found here: http://www.linuxtv.org/pipermail/vdr/2006-December/011336.html Simply save the: vdr-videosystem-0.0.1-uint64-0001.bin. Let us know how if it worked and how well. André ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TV Standards option for vdr-1.5.x
On 3/13/07, André Weidemann <[EMAIL PROTECTED]> wrote: I never had to patch my VDR to make it play NTSC properly. Have you ever tried the videosystem plugin? I have been using it for quite some time and it always worked flawlessly. NTSC users shouldn't have to use a plugin to provide NTSC compatibility. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TV Standards option for vdr-1.5.x
I never had to patch my VDR to make it play NTSC properly. Have you ever tried the videosystem plugin? I have been using it for quite some time and it always worked flawlessly. It can be found here: http://www.vdr-portal.de/board/thread.php?threadid=43516 VDR will play video fine w/o patching the code. But, the improper framerate will calculate incorrect times on the video. Also, the OSD will be sized differently when 720x480 is used instead of the hardcoded value of 720x576. Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TV Standards option for vdr-1.5.x
For VDR > 1.4.4 You need a patch to make it compile without errors. This one can be found here: http://www.linuxtv.org/pipermail/vdr/2006-December/011336.html Simply save the: vdr-videosystem-0.0.1-uint64-0001.bin. Let us know how if it worked and how well. It seems this plugin assumes I am currently using PAL. The plugin takes the OSD-Settings from VDR as PAL-settings and calculates the corresponding NTSC-settings. But, my television does not do both PAL and NTSC, so if this plugin assumes that I currently have PAL setup properly, wouldnt it calculate improper values for NTSC? I dont understand how it can generate proper NTSC values from PAL settings that I am not using. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TV Standards option for vdr-1.5.x
Stone wrote: I never had to patch my VDR to make it play NTSC properly. Have you ever tried the videosystem plugin? I have been using it for quite some time and it always worked flawlessly. It can be found here: http://www.vdr-portal.de/board/thread.php?threadid=43516 VDR will play video fine w/o patching the code. But, the improper framerate will calculate incorrect times on the video. Also, the OSD will be sized differently when 720x480 is used instead of the hardcoded value of 720x576. The plugin will take care of the OSD resizing for sure. That was the main reason I installed it. Regarding the time display... I'm not quite sure if the plugin also takes care of the correct calculation of time for the progress bar and such things, but you can give a try and see how it turns out. André ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine 0.7.10 buffering
hi, Reinhard Nissl writes: > If you show the recording's progress menu and switch to play (after a > jump to a cutting mark), you'll see that the progress bar advances very > quickly by 10 seconds, as VDR sends the recording data as fast as > possible (i. e. as fast as your harddisk can supply the data) to xine. Yes, I saw this. As I do not "cut" recordings, the 10s delay does not matter. Yesterday we watched one recording and did not notice any hickups when the recording jumped to another disk drive, so it does seem to work as expected. Of course there is always the possibility that the disks just happened to be running when the time to change arrived... I think this hint could be found in the vdr-xine manual, as it certainly is useful. yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TV Standards option for vdr-1.5.x
Stone wrote: It seems this plugin assumes I am currently using PAL. The plugin takes the OSD-Settings from VDR as PAL-settings and calculates the corresponding NTSC-settings. But, my television does not do both PAL and NTSC, so if this plugin assumes that I currently have PAL setup properly, wouldnt it calculate improper values for NTSC? I dont understand how it can generate proper NTSC values from PAL settings that I am not using. My TV can handle both PAL and NTSC. Nevertheless, the OSD is resized and everything is displayed correctly when playing NTSC content. I might be way off here..., but I assume that since all TV-standard values in VDR are hardcoded to PAL, it is safe to use those values to calculate the correct OSD size for NTSC material. Have you already given the plugin a try? André ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TV Standards option for vdr-1.5.x
On 3/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Stone wrote: > It seems this plugin assumes I am currently using PAL. The plugin takes > the OSD-Settings from VDR as PAL-settings and calculates the > corresponding NTSC-settings. But, my television does not do both PAL > and NTSC, so if this plugin assumes that I currently have PAL setup > properly, wouldnt it calculate improper values for NTSC? I dont > understand how it can generate proper NTSC values from PAL settings that > I am not using. My TV can handle both PAL and NTSC. Nevertheless, the OSD is resized and everything is displayed correctly when playing NTSC content. I might be way off here..., but I assume that since all TV-standard values in VDR are hardcoded to PAL, it is safe to use those values to calculate the correct OSD size for NTSC material. It just seems like I would have to translate my NTSC values into PAL, and then put those PAL values into VDR so that the plugin will read them as PAL and translate them back again to NTSC. Right now they are PAL settings with NTSC values. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TV Standards option for vdr-1.5.x
Stone wrote: It just seems like I would have to translate my NTSC values into PAL, and then put those PAL values into VDR so that the plugin will read them as PAL and translate them back again to NTSC. Right now they are PAL settings with NTSC values. This makes absolutely no sense to me. Why don't you simply grab a plain VDR 1.4.6 without any patches and try the plugin out? It only takes 3-4 minutes to set it up and you'll see whether or not it will work correctly. Using the plugin was only a suggestion for the time being. I thought you might want to use it until things might be changed in some future version of VDR. I thought of it as an easy to use option instead of patching the VDR every time a new version comes out. That's it... André ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TV Standards option for vdr-1.5.x
This makes absolutely no sense to me. Why don't you simply grab a plain VDR 1.4.6 without any patches and try the plugin out? It only takes 3-4 minutes to set it up and you'll see whether or not it will work correctly. Using the plugin was only a suggestion for the time being. I thought you might want to use it until things might be changed in some future version of VDR. I thought of it as an easy to use option instead of patching the VDR every time a new version comes out. That's it... I do appreciate the suggestion and I will take a better look at it. I was just trying to conceptually understand whats going on. All I was trying to say is that I dont think the plugin can generate valid NTSC values from invalid PAL settings. I'll post my results. Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TV Standards option for vdr-1.5.x
I do appreciate the suggestion and I will take a better look at it. I was just trying to conceptually understand whats going on. All I was trying to say is that I dont think the plugin can generate valid NTSC values from invalid PAL settings. I'll post my results. Best Regards. Ok, I have looked at the code and here is what I had to do to make it work. The OSDHeight value that I need to have for NTSC is 425 (what I am currently using). Therefore, I had to reverse the calulation in the videosystem plugin to make that equivalent to the PAL value. Pal.height = (425 * 576) / 480 = 510 So, after reversing the my current NTSC patch (except for the FRAMESPERSEC part), and putting 510 into VDR's OSDHeight, the videosystem plugin now reads the value of 510 (that is PAL) and converts it to 425 (which is the correct value I need for NTSC). That is what I meant when I said I would have to convert my NTSC settings to PAL so the plugin could read them and convert it back to NTSC (since the plugin assumes that PAL is the default). Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
OT: Re: [vdr] TV Standards option for vdr-1.5.x
Hi, Please do not post html mails here!!! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] New plugin remotetimers-0.0.1
Hi, the successor of streamdev's former remote timers feature is finally there. You can get the new remotetimers plugin at http://vdr.schmirler.de. Features: - Add, edit and delete timers on the local (client) VDR and a remote (server) VDR - Move timers between client and server - Assign user IDs to timers. Filter the timer list by user ID. - Support for MainMenuHooks patch. Replace the VDR mainmenus "Schedule" and "Timer" by remotetimers' counterparts. In addition, the plugin comes with its own "Schedule" menu. Adding timers without EPG is not very convenient, is it? All menus are more or less copies of VDR's originals. That should help to keep up with changes in VDR. Credits to Klaus and everyone who contributed to those parts of the code I copied. Remotetimers requires the svdrpservice plugin. So make sure, both plugins are installed. Differences between the original VDR menus and their remotetimers counterparts: The edit timer menu has two additional options: Location determins if the timer is stored on the local or the remote machine. Use this setting to move the timer from client to server or vice versa. Note that you cannot move a running timer. You will have to stop it first. You can assign a user ID to each timer. Every user or client can use its own ID or maybe you want to distinguish timers by genre? Whatever you prefer. You can then filter the timer list by ID. The special ID "0" actually means "no ID". A corresponding timer will always be visible. In the plugin setup you can determine the default values for location and user ID. In the timer list you will see a letter in front of the channel number. "L" indicates a local timer, "R" a remote timer. Use the number keys to filter the list. Press "0" to see all timers. Any other digit will show only timer with a matching ID and timers with ID "0". The menu title shows the current filter setting. In the plugin setup you can configure the default filter. There's nothing special about the schedule menus, of course except for the fact that remote timer matches are marked with "T", too. Note that there's no user ID filter. You will always see all timer matches. Warning: This is the very first release of the plugin. Even though it works perfectly for me, it may not in your environment. Keep this in mind when testing and maybe doublecheck the timer list on the remote VDR. Enjoy, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] how do you get a valid channels.conf?
I have a nexus-s satellite card and am running Ubuntu edgy eft. The card works fine. I can zap to FTA channels using szap using an old incomplete channels.conf I had. I'm trying to create a new channels.conf for echostar 7 at 119w so that I can use vdr to change channels instead of szap. I trie running the scan that comes with dvbutils, dvbscan from Thoraz but they both create channels.conf files that don't work. They are incomplete or have the wrong frequencies. Eg, I've tried ./dvbscan -G -lDBS -o vdr -e 3 -s 1 -x 0 -p dvb-s/echostar-119w > channels.conf.119w For the NASA channel it shows the frequency as 12369 but it should be at 12370. So I manually changed it to 12370. I then ran vdr and changed to NASA but I get a blank screen. Does anyone know why that could happen? the line in /etc/vdr/channels.conf is NASA:12370:v:S119.0W:2:4130:4131:0:0:213:4100:11:1 the .conf file for szap shows nasa as: NASA:12370:v:1:2:4130:4131:213 I'm not sure how I got this .conf file but it works for szap. Questions: 1. does scan or dvbscan work for N.A. satellites? 2. I've read about an nscan. Does that one work? 3. How do you get a valid channels.conf file for N.A. sats? With dvbscan I find that it can't tune to some transponders that are supposed to be on the satellite, or records the wrong frequency in channels.conf and gives incomplete results (maybe because it can't tune to a transponder). thanks, Bob ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] epia ex10000eg - platform for vdr?
hi, during my search for a good vdr plaform I found some epia boards with the cx700 chipset (mpeg2/4 acceleration) the epia drivers for xorg should support the mpeg acceleration is this true? and is it useable togther with softdevice? in the documentation epia says that a patched xine from sourceforge supports the acceleration features thanks marco -- AMMEC - Accessible Multimedia Entertainment Center http://www.ammec.de Email: Marco Skambraks <[EMAIL PROTECTED]> ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TV Standards option for vdr-1.5.x
I think I'll stick to what I said earlier in that support for NTSC should really be a core feature of VDR. I have no interest in running a plugin like this and would rather just stick to patching VDR if Klaus doesn't intend to address this issue. :\ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] how do you get a valid channels.conf?
It would be a big help if you posted your problems scanning channels on NA sats on the v4l mailing list. http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb We've (meaning NA) needed a new, properly working scanner for years but so far no luck. However, the more people who voice this is a problem, the better our chances of getting a resolution. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TV Standards option for vdr-1.5.x
On 3/13/07, VDR User <[EMAIL PROTECTED]> wrote: I think I'll stick to what I said earlier in that support for NTSC should really be a core feature of VDR. I have no interest in running a plugin like this and would rather just stick to patching VDR if Klaus doesn't intend to address this issue. :\ That plugin is only beneficial if you have a dual PAL/NTSC environment. It does not help with the frames per second calculatons at all. Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] TV Standards option for vdr-1.5.x
Hi,
Stone wrote:
> That plugin is only beneficial if you have a dual PAL/NTSC environment.
> It does not help with the frames per second calculatons at all.
You may want to try the attached patch. It determines FramesPerSec by
having a look at the first picture of the recording and falls back to
the FRAMESPERSEC macro otherwise.
The current implementation requires that the recording was taken with
cVideoRepacker enabled. Furthermore it must be MPEG2.
The file marks.vdr still uses FRAMEPERSEC for compatibility. Plugins
like dvd, burn, mp3, mplayer, etc. still use FRAMESPERSEC.
Although this patch is against VDR-1.4.6, it applies with some offset
also against VDR-1.5.1.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
diff -Nurp ../vdr-1.4.6-orig/dvbplayer.c ./dvbplayer.c
--- ../vdr-1.4.6-orig/dvbplayer.c 2006-04-17 14:45:48.0 +0200
+++ ./dvbplayer.c 2007-03-13 23:19:51.0 +0100
@@ -182,8 +182,8 @@ bool cNonBlockingFileReader::WaitForData
#define PLAYERBUFSIZE MEGABYTE(1)
-// The number of frames to back up when resuming an interrupted replay session:
-#define RESUMEBACKUP (10 * FRAMESPERSEC)
+// The number of seconds to back up when resuming an interrupted replay session:
+#define RESUMEBACKUP 10
class cDvbPlayer : public cPlayer, cThread {
private:
@@ -196,6 +196,7 @@ private:
cFileName *fileName;
cIndexFile *index;
cUnbufferedFile *replayFile;
+ int framesPerSec;
bool eof;
bool firstPacket;
ePlayModes playMode;
@@ -225,6 +226,7 @@ public:
void Goto(int Position, bool Still = false);
virtual bool GetIndex(int &Current, int &Total, bool SnapToIFrame = false);
virtual bool GetReplayMode(bool &Play, bool &Forward, int &Speed);
+ int GetFramesPerSec(void) { return framesPerSec; }
};
#define MAX_VIDEO_SLOWMOTION 63 // max. arg to pass to VIDEO_SLOWMOTION // TODO is this value correct?
@@ -253,6 +255,7 @@ cDvbPlayer::cDvbPlayer(const char *FileN
replayFile = fileName->Open();
if (!replayFile)
return;
+ framesPerSec = replayFile->GetFramesPerSec();
ringBuffer = new cRingBufferFrame(PLAYERBUFSIZE);
// Create the index file:
index = new cIndexFile(FileName, false);
@@ -341,7 +344,7 @@ bool cDvbPlayer::Save(void)
if (index) {
int Index = writeIndex;
if (Index >= 0) {
-Index -= RESUMEBACKUP;
+Index -= RESUMEBACKUP * GetFramesPerSec();
if (Index > 0)
Index = index->GetNextIFrame(Index, false);
else
@@ -371,7 +374,7 @@ void cDvbPlayer::Action(void)
readIndex = Resume();
if (readIndex >= 0)
- isyslog("resuming replay at index %d (%s)", readIndex, *IndexToHMSF(readIndex, true));
+ isyslog("resuming replay at index %d (%s)", readIndex, *IndexToHMSF(readIndex, true, GetFramesPerSec()));
nonBlockingFileReader = new cNonBlockingFileReader;
int Length = 0;
@@ -665,7 +668,7 @@ void cDvbPlayer::SkipSeconds(int Seconds
Empty();
int Index = writeIndex;
if (Index >= 0) {
-Index = max(Index + Seconds * FRAMESPERSEC, 0);
+Index = max(Index + Seconds * GetFramesPerSec(), 0);
if (Index > 0)
Index = index->GetNextIFrame(Index, false, NULL, NULL, NULL, true);
if (Index >= 0)
@@ -832,3 +835,10 @@ void cDvbPlayerControl::Goto(int Positio
if (player)
player->Goto(Position, Still);
}
+
+int cDvbPlayerControl::GetFramesPerSec()
+{
+ if (player)
+ return player->GetFramesPerSec();
+ return FRAMESPERSEC;
+}
diff -Nurp ../vdr-1.4.6-orig/dvbplayer.h ./dvbplayer.h
--- ../vdr-1.4.6-orig/dvbplayer.h 2002-06-23 12:13:51.0 +0200
+++ ./dvbplayer.h 2007-03-13 23:19:51.0 +0100
@@ -54,6 +54,8 @@ public:
void Goto(int Index, bool Still = false);
// Positions to the given index and displays that frame as a still picture
// if Still is true.
+ int GetFramesPerSec();
+ // Returns the number of frames per second for the current recording.
};
#endif //__DVBPLAYER_H
diff -Nurp ../vdr-1.4.6-orig/menu.c ./menu.c
--- ../vdr-1.4.6-orig/menu.c 2006-12-02 12:12:02.0 +0100
+++ ./menu.c 2007-03-13 23:19:51.0 +0100
@@ -3931,7 +3931,7 @@ bool cReplayControl::ShowProgress(bool I
lastCurrent = lastTotal = -1;
}
if (Total != lastTotal) {
-displayReplay->SetTotal(IndexToHMSF(Total));
+displayReplay->SetTotal(IndexToHMSF(Total, false, GetFramesPerSec()));
if (!Initial)
displayReplay->Flush();
}
@@ -3939,7 +3939,7 @@ bool cReplayControl::ShowProgress(bool I
displayReplay->SetProgress(Current, Total);
if (!Initial)
displayReplay->Flush();
-displayReplay->SetCurrent(IndexToHMSF(Current, displayFrames));
+displayReplay->SetCurrent(IndexToHMSF(Current, displayFrames, GetFramesPerSec()));
displayReplay->Flush();
lastCurrent = Current;
}
@@ -3971,8 +3971,8 @@ void cReplayControl::TimeSearchProcess(e
{
#define
