VDR developer version 1.7.10 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.10.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.9-1.7.10.diff
WARNING: ========
This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging.
IMPORTANT: ==========
Please remember that the VDR homepage has moved from http://www.cadsoft.de/vdr to http://tvdr.de, and the FTP site has moved from ftp://ftp.cadsoft.de/vdr to ftp://ftp.tvdr.de/vdr. Please update all links to these URLs.
The changes since version 1.7.9:
- Updated the Italian OSD texts (thanks to Diego Pierotto). - Fixed wrong bracketing in cChannel::SubtitlingType() etc. (thanks to Rolf Ahrenberg). - Fixed not logging changes for channels that have no number (reported by Timothy D. Lenz). - Changed the project's URLs and email to tvdr.de. - Added Lithuanian language translations (thanks to Valdemaras Pipiras). - Updated Chinese language texts (thanks to Nan Feng). - Only checking DVB_API_VERSION to be >=5 in order to stay compileable in case the DVB API version number is increased (the API claims to always be backward compatible). - Fixed saving terminal settings when running in background (thanks to Manuel Reimer). - Fixed cFrameDetector::Analyze() to handle video streams where the frame type is not detectable from the first TS packet of a frame. - Fixed writing the PCR pid into the PMT in cPatPmtGenerator::GeneratePmt() (reported by Rene van den Braken). - Added Slovakian language texts (thanks to Milan Hrala). - Fixed EntriesOnSameFileSystem() to avoid using f_fsid, which may be 0 (thanks to Frank Schmirler). - Fixed starting a recording at an I-frame. - Fixed generating the index for recordings from channels that put a whole GOP into one payload unit. - The index file for TS recordings is now regenerated on-the-fly if a recording is replayed that has no index. This can also be used to re-create a broken index file by manually deleting the index file and then replaying the recording (at least until the index file has been generated). - The cRingBufferLinear::Read() function now returns -1 and sets errno to EAGAIN if the buffer is already full. - Fixed handling DVB subtitles for PES recordings (thanks to Rolf Ahrenberg). - Added the audio id to the call of PlayAudio() in cDevice::PlayTsAudio() (thanks to Andreas Schaefers). - Fixed references to old *.vdr file names in MANUAL (reported by Arthur Konovalov). - Reverted "Removed limitation to PAL resolution from SPU handling" because it cause nothing but trouble. Besides, the core VDR doesn't use this, anyway. - Fixed the default value for "Pause key handling" in the MANUAL (reported by Diego Pierotto).
Have fun!
Klaus
Greetings Klaus. Thanks for the new version!
It seems the ffwd/rew crash on certain HDTV recordings is now fixed so thats great news!
However, the problem still exists where if I start replaying a recording while it's still recording, the length increases very quickly to ridiculous numbers. The replay stops at the point in the recording which I started playback. If I delete the index file and have VDR generate a new one, I still get the crazy recording length and the audio/video is out of sync. Maybe VDR should not actually start playback until after the new index file is generated? Although that won't fix the problem of starting playback before the recording has finished.
Best regards, Derek
On 23.11.2009 01:46, VDR User wrote:
Greetings Klaus. Thanks for the new version!
It seems the ffwd/rew crash on certain HDTV recordings is now fixed so thats great news!
Glad to hear that :-)
However, the problem still exists where if I start replaying a recording while it's still recording, the length increases very quickly to ridiculous numbers. The replay stops at the point in the recording which I started playback. If I delete the index file and have VDR generate a new one, I still get the crazy recording length and the audio/video is out of sync. Maybe VDR should not actually start playback until after the new index file is generated? Although that won't fix the problem of starting playback before the recording has finished.
Let's continue this in our original private thread.
Klaus
Hello,
I've patched VDR to record the PCR pid in the TS stream because both my tv set (Samsung B650) and Win7 refuses to play TS streams without PCR (some channel have PCR pid different from Video pid). Why the fix in this version doesn't include the necessary changes in receiver.* and recorder.* to record the PCR pid in case it differs from vpid?
Regards, Giampaolo
-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Klaus Schmidinger Sent: domenica 22 novembre 2009 15.59 To: vdr@linuxtv.org Subject: [vdr] [ANNOUNCE] VDR developer version 1.7.10
VDR developer version 1.7.10 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.10.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.9-1.7.10.diff
WARNING: ========
This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging.
IMPORTANT: ==========
Please remember that the VDR homepage has moved from http://www.cadsoft.de/vdr to http://tvdr.de, and the FTP site has moved from ftp://ftp.cadsoft.de/vdr to ftp://ftp.tvdr.de/vdr. Please update all links to these URLs.
The changes since version 1.7.9:
- Updated the Italian OSD texts (thanks to Diego Pierotto). - Fixed wrong bracketing in cChannel::SubtitlingType() etc. (thanks to Rolf Ahrenberg). - Fixed not logging changes for channels that have no number (reported by Timothy D. Lenz). - Changed the project's URLs and email to tvdr.de. - Added Lithuanian language translations (thanks to Valdemaras Pipiras). - Updated Chinese language texts (thanks to Nan Feng). - Only checking DVB_API_VERSION to be >=5 in order to stay compileable in case the DVB API version number is increased (the API claims to always be backward compatible). - Fixed saving terminal settings when running in background (thanks to Manuel Reimer). - Fixed cFrameDetector::Analyze() to handle video streams where the frame type is not detectable from the first TS packet of a frame. - Fixed writing the PCR pid into the PMT in cPatPmtGenerator::GeneratePmt() (reported by Rene van den Braken). - Added Slovakian language texts (thanks to Milan Hrala). - Fixed EntriesOnSameFileSystem() to avoid using f_fsid, which may be 0 (thanks to Frank Schmirler). - Fixed starting a recording at an I-frame. - Fixed generating the index for recordings from channels that put a whole GOP into one payload unit. - The index file for TS recordings is now regenerated on-the-fly if a recording is replayed that has no index. This can also be used to re-create a broken index file by manually deleting the index file and then replaying the recording (at least until the index file has been generated). - The cRingBufferLinear::Read() function now returns -1 and sets errno to EAGAIN if the buffer is already full. - Fixed handling DVB subtitles for PES recordings (thanks to Rolf Ahrenberg). - Added the audio id to the call of PlayAudio() in cDevice::PlayTsAudio() (thanks to Andreas Schaefers). - Fixed references to old *.vdr file names in MANUAL (reported by Arthur Konovalov). - Reverted "Removed limitation to PAL resolution from SPU handling" because it cause nothing but trouble. Besides, the core VDR doesn't use this, anyway. - Fixed the default value for "Pause key handling" in the MANUAL (reported by Diego Pierotto).
Have fun!
Klaus
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 25.11.2009 14:24, Giampaolo Sica wrote:
Hello,
I've patched VDR to record the PCR pid in the TS stream because both my tv set (Samsung B650) and Win7 refuses to play TS streams without PCR (some channel have PCR pid different from Video pid). Why the fix in this version doesn't include the necessary changes in receiver.* and recorder.* to record the PCR pid in case it differs from vpid?
Maybe because you haven't applied it to your copy of version 1.7.10? ;-)
In hindsight I'm not sure whether the change "Fixed writing the PCR pid into the PMT in cPatPmtGenerator::GeneratePmt()" was a good idea, because VDR doesn't record the PCR pid at all.
I tend to revert that change, because I don't think that a separate PCR pid is necessary in a recording. AFAIK the PCR pid is only for live viewing.
Klaus
Maybe because you haven't applied it to your copy of version 1.7.10? ;-)
:)))
In hindsight I'm not sure whether the change "Fixed writing the PCR pid into the PMT in cPatPmtGenerator::GeneratePmt()" was a good idea, because VDR doesn't record the PCR pid at all.
I tend to revert that change, because I don't think that a separate PCR pid is necessary in a recording. AFAIK the PCR pid is only for live viewing.
Klaus
Yes, you're right if you are replaying recordings on a FF card, but:
1) Some players refuse to play TS streams without PCR information (screen remains black). 2) I'm porting VDR to IPBOX 9000HD (STi710x based STB... yes, I know there is enigma2, but I've been using vdr since 2000 and I love it) and the PCR pid is essential to have the timeline while watching recording, because the ioctl DMX_GET_STC fails and the only way to you get time information is from the video/audio decoder (VIDEO_GET_PTS/ AUDIO_GET_PTS). So, even if I wrote a plugin for this device, I'd have to patch the base classes that is in contrast with the plugins philosophy
Giampaolo
P.S. If someone is interested in the porting to the ipbox, please let me know. If we are more than one I'll create a svn database on the internet.
Giampaolo Sica wrote:
P.S. If someone is interested in the porting to the ipbox, please let me know. If we are more than one I'll create a svn database on the internet.
I would be highly interested to porting VDR to Kathrein UFS-910. Are they using a similar platform?
thanks,
István
On 26.11.2009 13:51, Giampaolo Sica wrote:
Maybe because you haven't applied it to your copy of version 1.7.10? ;-)
:)))
In hindsight I'm not sure whether the change "Fixed writing the PCR pid into the PMT in cPatPmtGenerator::GeneratePmt()" was a good idea, because VDR doesn't record the PCR pid at all.
I tend to revert that change, because I don't think that a separate PCR pid is necessary in a recording. AFAIK the PCR pid is only for live viewing.
Klaus
Yes, you're right if you are replaying recordings on a FF card, but:
- Some players refuse to play TS streams without PCR information (screen
remains black). 2) I'm porting VDR to IPBOX 9000HD (STi710x based STB... yes, I know there is enigma2, but I've been using vdr since 2000 and I love it) and the PCR pid is essential to have the timeline while watching recording, because the ioctl DMX_GET_STC fails and the only way to you get time information is from the video/audio decoder (VIDEO_GET_PTS/ AUDIO_GET_PTS). So, even if I wrote a plugin for this device, I'd have to patch the base classes that is in contrast with the plugins philosophy
Can you please try what happens if you set
int Ppid = 0x1FFF;
in cPatPmtGenerator::GeneratePmt()?
As far as I understand the PCR (please correct me if I'm wrong), it only has a meaning in live mode, where PCR packets arrive at precise points in time and are used to syncronize the player's internal clock. When replaying a recording, it is not defined when the PCR packets arrive at the player, and thus they have no meaning.
Klaus
Hi Klaus,
Thanks for your answer and sorry for replaying so late.
Setting Ppid to 0x1FFF means disable it. The effect is that some mpeg2 players refuse to play vdr recordings.
I think that the PCR pid is more important in recordings than in live viewing, because in live viewing the timing is implicit in the packet time of arrival. When you have a file you lose that information because you try to fill the playing buffer.
What I said is anyway wrong, because PCR is part of the mpeg2 standard and it have to be present in the stream.
Maybe, the particular implementation of the mpeg2 decoder in the DVB FF card derives its internal clock using the framerate of the mpeg2 stream, but it is not standard.
Giampaolo
P.S. I liked very much the architecture of the 1.7.11 regarding the dvb FF support. I think that the more VDR will be hardware agnostic, the more its architecture will be well designed.
-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Klaus Schmidinger Sent: sabato 5 dicembre 2009 12:27 To: vdr@linuxtv.org Subject: Re: [vdr] PCR pid
On 26.11.2009 13:51, Giampaolo Sica wrote:
Maybe because you haven't applied it to your copy of version 1.7.10? ;-)
:)))
In hindsight I'm not sure whether the change "Fixed writing the PCR pid into the PMT in cPatPmtGenerator::GeneratePmt()" was a good idea, because VDR doesn't record the PCR pid at all.
I tend to revert that change, because I don't think that a separate PCR pid is necessary in a recording. AFAIK the PCR pid is only for live viewing.
Klaus
Yes, you're right if you are replaying recordings on a FF card, but:
- Some players refuse to play TS streams without PCR information (screen
remains black). 2) I'm porting VDR to IPBOX 9000HD (STi710x based STB... yes, I know there is enigma2, but I've been using vdr since 2000 and I love it) and the PCR pid is essential to have the timeline while watching recording, because
the
ioctl DMX_GET_STC fails and the only way to you get time information is
from
the video/audio decoder (VIDEO_GET_PTS/ AUDIO_GET_PTS). So, even if I
wrote
a plugin for this device, I'd have to patch the base classes that is in contrast with the plugins philosophy
Can you please try what happens if you set
int Ppid = 0x1FFF;
in cPatPmtGenerator::GeneratePmt()?
As far as I understand the PCR (please correct me if I'm wrong), it only has a meaning in live mode, where PCR packets arrive at precise points in time and are used to syncronize the player's internal clock. When replaying a recording, it is not defined when the PCR packets arrive at the player, and thus they have no meaning.
Klaus
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 08.01.2010 12:19, Giampaolo Sica wrote:
Hi Klaus,
Thanks for your answer and sorry for replaying so late.
Setting Ppid to 0x1FFF means disable it. The effect is that some mpeg2 players refuse to play vdr recordings.
I think that the PCR pid is more important in recordings than in live viewing, because in live viewing the timing is implicit in the packet time of arrival. When you have a file you lose that information because you try to fill the playing buffer.
What I said is anyway wrong, because PCR is part of the mpeg2 standard and it have to be present in the stream.
Maybe, the particular implementation of the mpeg2 decoder in the DVB FF card derives its internal clock using the framerate of the mpeg2 stream, but it is not standard.
Can you point to some documentation that specifies how the PCR data is actually used during replay of a recording? I find it very hard to believe that this can actually be used, because you just can't syncronize a local clock to the PCR if the PCR packets don't arrive in real time.
Klaus
-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Klaus Schmidinger Sent: sabato 5 dicembre 2009 12:27 To: vdr@linuxtv.org Subject: Re: [vdr] PCR pid
On 26.11.2009 13:51, Giampaolo Sica wrote:
Maybe because you haven't applied it to your copy of version 1.7.10? ;-)
:)))
In hindsight I'm not sure whether the change "Fixed writing the PCR pid into the PMT in cPatPmtGenerator::GeneratePmt()" was a good idea, because VDR doesn't record the PCR pid at all. I tend to revert that change, because I don't think that a separate PCR pid is necessary in a recording. AFAIK the PCR pid is only for live viewing. Klaus
Yes, you're right if you are replaying recordings on a FF card, but:
- Some players refuse to play TS streams without PCR information (screen
remains black). 2) I'm porting VDR to IPBOX 9000HD (STi710x based STB... yes, I know there is enigma2, but I've been using vdr since 2000 and I love it) and the PCR pid is essential to have the timeline while watching recording, because
the
ioctl DMX_GET_STC fails and the only way to you get time information is
from
the video/audio decoder (VIDEO_GET_PTS/ AUDIO_GET_PTS). So, even if I
wrote
a plugin for this device, I'd have to patch the base classes that is in contrast with the plugins philosophy
Can you please try what happens if you set
int Ppid = 0x1FFF;
in cPatPmtGenerator::GeneratePmt()?
As far as I understand the PCR (please correct me if I'm wrong), it only has a meaning in live mode, where PCR packets arrive at precise points in time and are used to syncronize the player's internal clock. When replaying a recording, it is not defined when the PCR packets arrive at the player, and thus they have no meaning.
Klaus
Hi Klaus,
in the iso13818-1 (you can find a copy at http://neuron2.net/library/mpeg2/iso13818-1.pdf), in the section 2.4.2.2 Input to the Transport Stream system target decoder, is explained how the PCR is used to reconstruct the transport stream clock.
Giampaolo
-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Klaus Schmidinger Sent: venerdì 8 gennaio 2010 15.01 To: vdr@linuxtv.org Subject: Re: [vdr] PCR pid
On 08.01.2010 12:19, Giampaolo Sica wrote:
Hi Klaus,
Thanks for your answer and sorry for replaying so late.
Setting Ppid to 0x1FFF means disable it. The effect is that some mpeg2 players refuse to play vdr recordings.
I think that the PCR pid is more important in recordings than in live viewing, because in live viewing the timing is implicit in the packet time of arrival. When you have a file you lose that information because you try to fill the playing buffer.
What I said is anyway wrong, because PCR is part of the mpeg2 standard and it have to be present in the stream.
Maybe, the particular implementation of the mpeg2 decoder in the DVB FF
card
derives its internal clock using the framerate of the mpeg2 stream, but it is not standard.
Can you point to some documentation that specifies how the PCR data is actually used during replay of a recording? I find it very hard to believe that this can actually be used, because you just can't syncronize a local clock to the PCR if the PCR packets don't arrive in real time.
Klaus
-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf
Of
Klaus Schmidinger Sent: sabato 5 dicembre 2009 12:27 To: vdr@linuxtv.org Subject: Re: [vdr] PCR pid
On 26.11.2009 13:51, Giampaolo Sica wrote:
Maybe because you haven't applied it to your copy of version 1.7.10? ;-)
:)))
In hindsight I'm not sure whether the change "Fixed writing the PCR pid into the PMT in cPatPmtGenerator::GeneratePmt()" was a good idea,
because
VDR doesn't record the PCR pid at all. I tend to revert that change, because I don't think that a separate PCR pid is necessary in a recording. AFAIK the PCR pid is only for live viewing. Klaus
Yes, you're right if you are replaying recordings on a FF card, but:
- Some players refuse to play TS streams without PCR information (screen
remains black). 2) I'm porting VDR to IPBOX 9000HD (STi710x based STB... yes, I know
there
is enigma2, but I've been using vdr since 2000 and I love it) and the PCR pid is essential to have the timeline while watching recording, because
the
ioctl DMX_GET_STC fails and the only way to you get time information is
from
the video/audio decoder (VIDEO_GET_PTS/ AUDIO_GET_PTS). So, even if I
wrote
a plugin for this device, I'd have to patch the base classes that is in contrast with the plugins philosophy
Can you please try what happens if you set
int Ppid = 0x1FFF;
in cPatPmtGenerator::GeneratePmt()?
As far as I understand the PCR (please correct me if I'm wrong), it only has a meaning in live mode, where PCR packets arrive at precise points in time and are used to syncronize the player's internal clock. When replaying a recording, it is not defined when the PCR packets arrive at the player, and thus they have no meaning.
Klaus
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 08.01.2010 20:16, Giampaolo Sica wrote:
Hi Klaus,
in the iso13818-1 (you can find a copy at http://neuron2.net/library/mpeg2/iso13818-1.pdf), in the section 2.4.2.2 Input to the Transport Stream system target decoder, is explained how the PCR is used to reconstruct the transport stream clock.
Giampaolo
-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Klaus Schmidinger Sent: venerdì 8 gennaio 2010 15.01 To: vdr@linuxtv.org Subject: Re: [vdr] PCR pid
On 08.01.2010 12:19, Giampaolo Sica wrote:
Hi Klaus,
Thanks for your answer and sorry for replaying so late.
Setting Ppid to 0x1FFF means disable it. The effect is that some mpeg2 players refuse to play vdr recordings.
Can you name one that refuses to play such a recording? Kaffeine and gxine apparently have no problem.
Klaus
My Samsung linux based TV set (http://samygo.sourceforge.net/) won't play .TS without PCR (both h.264 and mpeg2). Windows media player in windows 7 can play mpeg2 and H.264 .TS only with PCR pid. I haven't tried any other player.
-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Klaus Schmidinger Sent: sabato 9 gennaio 2010 12.10 To: vdr@linuxtv.org Subject: Re: [vdr] PCR pid
On 08.01.2010 20:16, Giampaolo Sica wrote:
Hi Klaus,
in the iso13818-1 (you can find a copy at http://neuron2.net/library/mpeg2/iso13818-1.pdf), in the section 2.4.2.2 Input to the Transport Stream system target decoder, is explained how the PCR is used to reconstruct the transport stream clock.
Giampaolo
-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf
Of
Klaus Schmidinger Sent: venerdì 8 gennaio 2010 15.01 To: vdr@linuxtv.org Subject: Re: [vdr] PCR pid
On 08.01.2010 12:19, Giampaolo Sica wrote:
Hi Klaus,
Thanks for your answer and sorry for replaying so late.
Setting Ppid to 0x1FFF means disable it. The effect is that some mpeg2 players refuse to play vdr recordings.
Can you name one that refuses to play such a recording? Kaffeine and gxine apparently have no problem.
Klaus
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Sun, Jan 10, 2010 at 12:30 AM, Giampaolo Sica gpsica@tin.it wrote:
My Samsung linux based TV set (http://samygo.sourceforge.net/) won't play .TS without PCR (both h.264 and mpeg2). Windows media player in windows 7 can play mpeg2 and H.264 .TS only with PCR pid. I haven't tried any other player.
I would say your problem should be addressed within your hacked tv firmware. However, if there is a real need for PCR then I'm sure Klaus will consider it.
On 11.01.2010 06:19, VDR User wrote:
On Sun, Jan 10, 2010 at 12:30 AM, Giampaolo Sica gpsica@tin.it wrote:
My Samsung linux based TV set (http://samygo.sourceforge.net/) won't play .TS without PCR (both h.264 and mpeg2). Windows media player in windows 7 can play mpeg2 and H.264 .TS only with PCR pid. I haven't tried any other player.
I would say your problem should be addressed within your hacked tv firmware. However, if there is a real need for PCR then I'm sure Klaus will consider it.
In an attempt to debug this I just made some recordings from channels with VPID==PPID and VPID!=PPID, namely
RTL Television,RTL;RTL World:12187:hC34M2O0S0:S19.2E:27500:163=2:104=deu;106=deu:105:0:12003:1:1089:0 BVN;CANALDIGITAAL:12574:hC56M2O0S0:S19.2E:22000:515+8190=2:96=dut:36:0:5025:53:1109:0
Both recordings were replayed without problems using the Windows Media Player on Windows XP. It didn't even make a difference whether the PCR pid in the PMT was set to an actual value or to 0x1FFF.
I was under the impression that the WMP was one of those players that have problems if there is no PCR, but apparently it plays just fine...
Klaus
Hi Klaus,
On 24.01.2010 16:28, Klaus Schmidinger wrote:
On 11.01.2010 06:19, VDR User wrote:
On Sun, Jan 10, 2010 at 12:30 AM, Giampaolo Sicagpsica@tin.it wrote:
My Samsung linux based TV set (http://samygo.sourceforge.net/) won't play .TS without PCR (both h.264 and mpeg2). Windows media player in windows 7 can play mpeg2 and H.264 .TS only with PCR pid. I haven't tried any other player.
I would say your problem should be addressed within your hacked tv firmware. However, if there is a real need for PCR then I'm sure Klaus will consider it.
In an attempt to debug this I just made some recordings from channels with VPID==PPID and VPID!=PPID, namely
RTL Television,RTL;RTL World:12187:hC34M2O0S0:S19.2E:27500:163=2:104=deu;106=deu:105:0:12003:1:1089:0 BVN;CANALDIGITAAL:12574:hC56M2O0S0:S19.2E:22000:515+8190=2:96=dut:36:0:5025:53:1109:0
Both recordings were replayed without problems using the Windows Media Player on Windows XP. It didn't even make a difference whether the PCR pid in the PMT was set to an actual value or to 0x1FFF.
I was under the impression that the WMP was one of those players that have problems if there is no PCR, but apparently it plays just fine...
Could you please do a quick test with VLC 1.0.3 under Windows? I cannot replay any recordings made from AnixeHD recorded with vdr-1.7.11. Upon replay I only get a still picture of the first recorded frame.
Regards André
On 24.01.2010 17:24, André Weidemann wrote:
Hi Klaus,
On 24.01.2010 16:28, Klaus Schmidinger wrote:
On 11.01.2010 06:19, VDR User wrote:
On Sun, Jan 10, 2010 at 12:30 AM, Giampaolo Sicagpsica@tin.it wrote:
My Samsung linux based TV set (http://samygo.sourceforge.net/) won't play .TS without PCR (both h.264 and mpeg2). Windows media player in windows 7 can play mpeg2 and H.264 .TS only with PCR pid. I haven't tried any other player.
I would say your problem should be addressed within your hacked tv firmware. However, if there is a real need for PCR then I'm sure Klaus will consider it.
In an attempt to debug this I just made some recordings from channels with VPID==PPID and VPID!=PPID, namely
RTL Television,RTL;RTL World:12187:hC34M2O0S0:S19.2E:27500:163=2:104=deu;106=deu:105:0:12003:1:1089:0
BVN;CANALDIGITAAL:12574:hC56M2O0S0:S19.2E:22000:515+8190=2:96=dut:36:0:5025:53:1109:0
Both recordings were replayed without problems using the Windows Media Player on Windows XP. It didn't even make a difference whether the PCR pid in the PMT was set to an actual value or to 0x1FFF.
I was under the impression that the WMP was one of those players that have problems if there is no PCR, but apparently it plays just fine...
Could you please do a quick test with VLC 1.0.3 under Windows? I cannot replay any recordings made from AnixeHD recorded with vdr-1.7.11. Upon replay I only get a still picture of the first recorded frame.
Are you referring to
ANIXE HD;BetaDigital:10832:hC23M5O35S1:S19.2E:22000:767=27:0;771=deu:0:1:61202:1:1057:0
Please try
--- remux.c 2010/01/23 15:39:15 2.38 +++ remux.c 2010/01/24 15:18:29 2.39 @@ -295,7 +295,7 @@ numPmtPackets = 0; if (Channel) { int Vpid = Channel->Vpid(); - int Ppid = 0x1FFF; // no PCR pid + int Ppid = Channel->Ppid(); uchar *p = buf; int i = 0; p[i++] = 0x02; // table id
That should fix it - this channel doesn't have a separate PCR pid.
Klaus
On 24.01.2010 18:14, Klaus Schmidinger wrote:
On 24.01.2010 17:24, André Weidemann wrote:
Hi Klaus,
On 24.01.2010 16:28, Klaus Schmidinger wrote:
On 11.01.2010 06:19, VDR User wrote:
On Sun, Jan 10, 2010 at 12:30 AM, Giampaolo Sicagpsica@tin.it wrote:
My Samsung linux based TV set (http://samygo.sourceforge.net/) won't play .TS without PCR (both h.264 and mpeg2). Windows media player in windows 7 can play mpeg2 and H.264 .TS only with PCR pid. I haven't tried any other player.
I would say your problem should be addressed within your hacked tv firmware. However, if there is a real need for PCR then I'm sure Klaus will consider it.
In an attempt to debug this I just made some recordings from channels with VPID==PPID and VPID!=PPID, namely
RTL Television,RTL;RTL World:12187:hC34M2O0S0:S19.2E:27500:163=2:104=deu;106=deu:105:0:12003:1:1089:0
BVN;CANALDIGITAAL:12574:hC56M2O0S0:S19.2E:22000:515+8190=2:96=dut:36:0:5025:53:1109:0
Both recordings were replayed without problems using the Windows Media Player on Windows XP. It didn't even make a difference whether the PCR pid in the PMT was set to an actual value or to 0x1FFF.
I was under the impression that the WMP was one of those players that have problems if there is no PCR, but apparently it plays just fine...
Could you please do a quick test with VLC 1.0.3 under Windows? I cannot replay any recordings made from AnixeHD recorded with vdr-1.7.11. Upon replay I only get a still picture of the first recorded frame.
Are you referring to
ANIXE HD;BetaDigital:10832:hC23M5O35S1:S19.2E:22000:767=27:0;771=deu:0:1:61202:1:1057:0
Yes, this is it.
--- remux.c 2010/01/23 15:39:15 2.38 +++ remux.c 2010/01/24 15:18:29 2.39 @@ -295,7 +295,7 @@ numPmtPackets = 0; if (Channel) { int Vpid = Channel->Vpid();
int Ppid = 0x1FFF; // no PCR pid
int Ppid = Channel->Ppid(); uchar *p = buf; int i = 0; p[i++] = 0x02; // table idThat should fix it - this channel doesn't have a separate PCR pid.
The above patch fixes the replay problem with VLC. Thank you.
Regards. André
On 24.01.2010 19:22, André Weidemann wrote:
On 24.01.2010 18:14, Klaus Schmidinger wrote:
On 24.01.2010 17:24, André Weidemann wrote:
Hi Klaus,
On 24.01.2010 16:28, Klaus Schmidinger wrote:
On 11.01.2010 06:19, VDR User wrote:
On Sun, Jan 10, 2010 at 12:30 AM, Giampaolo Sicagpsica@tin.it wrote:
My Samsung linux based TV set (http://samygo.sourceforge.net/) won't play .TS without PCR (both h.264 and mpeg2). Windows media player in windows 7 can play mpeg2 and H.264 .TS only with PCR pid. I haven't tried any other player.
I would say your problem should be addressed within your hacked tv firmware. However, if there is a real need for PCR then I'm sure Klaus will consider it.
In an attempt to debug this I just made some recordings from channels with VPID==PPID and VPID!=PPID, namely
RTL Television,RTL;RTL World:12187:hC34M2O0S0:S19.2E:27500:163=2:104=deu;106=deu:105:0:12003:1:1089:0
BVN;CANALDIGITAAL:12574:hC56M2O0S0:S19.2E:22000:515+8190=2:96=dut:36:0:5025:53:1109:0
Both recordings were replayed without problems using the Windows Media Player on Windows XP. It didn't even make a difference whether the PCR pid in the PMT was set to an actual value or to 0x1FFF.
I was under the impression that the WMP was one of those players that have problems if there is no PCR, but apparently it plays just fine...
Could you please do a quick test with VLC 1.0.3 under Windows? I cannot replay any recordings made from AnixeHD recorded with vdr-1.7.11. Upon replay I only get a still picture of the first recorded frame.
Are you referring to
ANIXE HD;BetaDigital:10832:hC23M5O35S1:S19.2E:22000:767=27:0;771=deu:0:1:61202:1:1057:0
Yes, this is it.
--- remux.c 2010/01/23 15:39:15 2.38 +++ remux.c 2010/01/24 15:18:29 2.39 @@ -295,7 +295,7 @@ numPmtPackets = 0; if (Channel) { int Vpid = Channel->Vpid();
int Ppid = 0x1FFF; // no PCR pid
int Ppid = Channel->Ppid(); uchar *p = buf; int i = 0; p[i++] = 0x02; // table idThat should fix it - this channel doesn't have a separate PCR pid.
The above patch fixes the replay problem with VLC. Thank you.
Have you tested with both versions, PPID==VPID and PPID!=VPID?
Klaus
On 26.01.2010 18:36, Klaus Schmidinger wrote:
On 24.01.2010 19:22, André Weidemann wrote:
On 24.01.2010 18:14, Klaus Schmidinger wrote:
On 24.01.2010 17:24, André Weidemann wrote:
Hi Klaus,
On 24.01.2010 16:28, Klaus Schmidinger wrote:
On 11.01.2010 06:19, VDR User wrote:
On Sun, Jan 10, 2010 at 12:30 AM, Giampaolo Sicagpsica@tin.it wrote: > My Samsung linux based TV set (http://samygo.sourceforge.net/) won't > play > .TS without PCR (both h.264 and mpeg2). > Windows media player in windows 7 can play mpeg2 and H.264 .TS only > with PCR > pid. > I haven't tried any other player.
I would say your problem should be addressed within your hacked tv firmware. However, if there is a real need for PCR then I'm sure Klaus will consider it.
In an attempt to debug this I just made some recordings from channels with VPID==PPID and VPID!=PPID, namely
RTL Television,RTL;RTL World:12187:hC34M2O0S0:S19.2E:27500:163=2:104=deu;106=deu:105:0:12003:1:1089:0
BVN;CANALDIGITAAL:12574:hC56M2O0S0:S19.2E:22000:515+8190=2:96=dut:36:0:5025:53:1109:0
Both recordings were replayed without problems using the Windows Media Player on Windows XP. It didn't even make a difference whether the PCR pid in the PMT was set to an actual value or to 0x1FFF.
I was under the impression that the WMP was one of those players that have problems if there is no PCR, but apparently it plays just fine...
Could you please do a quick test with VLC 1.0.3 under Windows? I cannot replay any recordings made from AnixeHD recorded with vdr-1.7.11. Upon replay I only get a still picture of the first recorded frame.
Are you referring to
ANIXEHD;BetaDigital:10832:hC23M5O35S1:S19.2E:22000:767=27:0;771=deu:0:1:61202:1:1057:0
Yes, this is it.
--- remux.c 2010/01/23 15:39:15 2.38 +++ remux.c 2010/01/24 15:18:29 2.39 @@ -295,7 +295,7 @@ numPmtPackets = 0; if (Channel) { int Vpid = Channel->Vpid();
int Ppid = 0x1FFF; // no PCR pid
int Ppid = Channel->Ppid(); uchar *p = buf; int i = 0; p[i++] = 0x02; // table idThat should fix it - this channel doesn't have a separate PCR pid.
The above patch fixes the replay problem with VLC. Thank you.
Have you tested with both versions, PPID==VPID and PPID!=VPID?
I am sorry for the late reply. I had only tested replaying a recording from AnixeHD with the above patch applied. I went through my channels list today, searching for a channel where PPID!=VPID, but could not find one at first glance.
André
Klaus Schmidinger wrote:
I was under the impression that the WMP was one of those players that have problems if there is no PCR, but apparently it plays just fine...
When I used vlc with streamdev (few years ago), vlc refused to play http streams without PCR. But I don't know if recent versions still require PCR.
There is one case where PCR would be useful. When recording is streamed over udp/rtp, one needs to re-generate the original transmission rate. The easiest way to do this is to sync PCR to local clock.
- Petri
On 24.01.2010 18:37, Petri Hintukainen wrote:
Klaus Schmidinger wrote:
I was under the impression that the WMP was one of those players that have problems if there is no PCR, but apparently it plays just fine...
When I used vlc with streamdev (few years ago), vlc refused to play http streams without PCR. But I don't know if recent versions still require PCR.
I have now tested with VLC and apparently it does refuse to play a stream without PCR - although according to http://www.videolan.org/developers/vls/doc/developer/vls-devel/c327.htm it obviously could (see section "Using or not PCRs").
In version 1.7.12 VDR will record the PCR data in case it uses a different PID than the video. With that, VLC can replay such recordings.
Klaus
-
André Weidemann -
Giampaolo Sica -
István Füley -
Klaus Schmidinger -
Petri Hintukainen -
VDR User