Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
On Wed, Sep 17, 2008 at 06:09:05PM +0200, Klaus Schmidinger wrote: This whole distributed development idea may be a nice thing, but are we ever going to see *one* *master* repository that actually works? From linux-dvb : liplianindvb, szap2, szap-s2 hg repositories avialable on http://mercurial.intuxication.org/hg/liplianindvb http://mercurial.intuxication.org/hg/szap2 http://mercurial.intuxication.org/hg/szap-s2 -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
On 09/14/08 16:45, Gregoire Favre wrote:
On Sun, Sep 14, 2008 at 04:35:10PM +0200, Klaus Schmidinger wrote:
For some odd reason neither the latest version of multiproto nor
multiproto_plus works here for me. The only one that does work is
multiproto_plus 88821ce4ed8d. See my posting on the linux-dvb ML.
What about
http://liplianindvb.sourceforge.net/cgi-bin/hgwebdir.cgi/liplianindvb/ ?
This gives me:
Traceback (most recent call last):
File /home/groups/l/li/liplianindvb/cgi-bin/hgwebdir.cgi, line 46, in ?
application = hgwebdir('hgweb.config')
File
/home/groups/l/li/liplianindvb/lib/mercurial-1.0.1/mercurial/hgweb/hgwebdir_mod.py,
line 26, in __init__
interactive = False)
File /home/groups/l/li/liplianindvb/lib/mercurial-1.0.1/mercurial/ui.py,
line 50, in __init__
self.readconfig(util.rcpath())
File /home/groups/l/li/liplianindvb/lib/mercurial-1.0.1/mercurial/util.py,
line 1778, in rcpath
_rcpath = os_rcpath()
File /home/groups/l/li/liplianindvb/lib/mercurial-1.0.1/mercurial/util.py,
line 1754, in os_rcpath
path = system_rcpath()
File /home/groups/l/li/liplianindvb/lib/mercurial-1.0.1/mercurial/util.py,
line 1118, in system_rcpath
path.extend(rcfiles(os.path.dirname(sys.argv[0]) +
File /home/groups/l/li/liplianindvb/lib/mercurial-1.0.1/mercurial/util.py,
line 1107, in rcfiles
rcs.extend([os.path.join(rcdir, f)
File
/home/groups/l/li/liplianindvb/lib/mercurial-1.0.1/mercurial/demandimport.py,
line 74, in __getattribute__
self._load()
File
/home/groups/l/li/liplianindvb/lib/mercurial-1.0.1/mercurial/demandimport.py,
line 46, in _load
mod = _origimport(head, globals, locals)
ImportError:
/home/groups/l/li/liplianindvb/lib/mercurial-1.0.1/mercurial/osutil.so: wrong
ELF class: ELFCLASS32
This whole distributed development idea may be a nice thing, but are we ever
going to see *one* *master* repository that actually works?
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
Hi 2008/9/17 Klaus Schmidinger [EMAIL PROTECTED]: What about http://liplianindvb.sourceforge.net/cgi-bin/hgwebdir.cgi/liplianindvb/ ? I don't know. But you can use http://arvdr-dev.free-x.de:8080/testdvb/ it's a copy from liplianindvb Regards Oleg Roitburd ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
En/na Klaus Schmidinger ha escrit:
On 09/07/08 16:48, Luca Olivetti wrote:
El Sun, 07 Sep 2008 12:11:35 +0200
Klaus Schmidinger [EMAIL PROTECTED] escribió:
t.
+ cTransfer no longer uses cRemux, and doesn't run a separate
thread any more. It just generates a PAT/PMT and sends all received
TS packets to the primary device's PlayTs().
Just asking before I try to recompile everything, but does it mean that
output plugins (xine, dxr3, etc.) have to be rewritten?
They can implement cDevice::PlayTs() if they need to handle the TS
packets by themselves. Otherwise the TS payload will be extracted from
the TS, assembled to complete PES packets and delivered via the existing
PlayVideo() and PlayAudio() functions.
Well, I didn't manage to get anything from the dxr3 plugin (no image and
no sound) while xine (0.8.0) has no audio, it manages to get some video
*but* it's stuttering/slow-motion like and it's spitting various FIXME
(it seems it has trouble in recognizing the packets that it receives),
e.g., it fails in a condition like this one:
if (0x00 != Data[ 0 ]
|| 0x00 != Data[ 1 ]
|| 0x01 != Data[ 2 ])
{
VERBOSE_NOP(); -- here it outputs a FIXME
break;
}
Maybe it's the same problem that causes the dxr3 plugin to fail, I don't
know.
Bye
--
Luca
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
On 09/07/08 13:55, Jelle De Loecker wrote: Multiproto_plus is quite outdated, Manu (the maintainer) has done a bunch of updates on the original multiproto tree (http://jusst.de/hg/multiproto) He even added support for the old API (yay) and merged the latest V4L tree with it. Basically, it compiles and it just works with everything :) For some odd reason neither the latest version of multiproto nor multiproto_plus works here for me. The only one that does work is multiproto_plus 88821ce4ed8d. See my posting on the linux-dvb ML. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
On Sun, Sep 14, 2008 at 04:35:10PM +0200, Klaus Schmidinger wrote: For some odd reason neither the latest version of multiproto nor multiproto_plus works here for me. The only one that does work is multiproto_plus 88821ce4ed8d. See my posting on the linux-dvb ML. What about http://liplianindvb.sourceforge.net/cgi-bin/hgwebdir.cgi/liplianindvb/ ? -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
Op Zo, 14 september, 2008 16:45, schreef Gregoire Favre: On Sun, Sep 14, 2008 at 04:35:10PM +0200, Klaus Schmidinger wrote: For some odd reason neither the latest version of multiproto nor multiproto_plus works here for me. The only one that does work is multiproto_plus 88821ce4ed8d. See my posting on the linux-dvb ML. What about http://liplianindvb.sourceforge.net/cgi-bin/hgwebdir.cgi/liplianindvb/ ? -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre I use Igor's repo with VDR 1.7.0 (haven't upgraded to 1.7.1 yet) and it works without any problems at all in combination with my Hauppauge NOVA-HD-S2 Yours, Niels Wagenaar ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 1.7.1
VDR developer version 1.7.1 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.1.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.0-1.7.1.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. This version marks the first step towards using TS (Transport Stream) as recording format. It does this by switching the Transfer Mode to TS and introducing all the necessary cDevice and cPlayer functions to handle TS. Actual recording is still done in PES, though. This should provide a reasonable developing and testing environment for HDTV device plugins to prepare for replaying TS. There appears to be a problem with replaying the payload from TS packets on Full-Featured DVB cards. On some channels this works rather fine (with only very small glitches from time to time), while on other channels there are heavy glitches and sometimes even the audio goes mute. My initial approach to replaying TS on FF cards was to simply strip the TS header and send the payload to the usual PlayVideo() and PlayAudio() functions, since the driver itself examines the data and assembles the 2KB PES packets it sends to the hardware. Since the FF cards can replay the TS data as it comes in from the transponder, my assumption was that the same should be possible in Transfer Mode. But maybe there is something wrong with this assumption? Could this be a driver problem? I don't think that simply throwing memory at the problem is the solution. Any thoughts? The changes since version 1.7.0: - Adapted the tuning code to the new DVBFE_SET_DELSYS API (thanks to Reinhard Nissl). VDR now uses the driver from http://jusst.de/hg/multiproto_plus. - Updated the Italian OSD texts (thanks to Diego Pierotto). - Removed obsolete $(NCURSESLIB) from the Makefile. - Implemented handling the standard component descriptor for AC3 (stream=4), as it will soon be used by the German ARD channels (thanks to Michael Pennewiß for advance information about this change). The previously used Premiere pseudo standard (stream=2, type=5) still works, but has apparently been wrongfully used by broadcasters from the beginning. - Added missing description of the 'S' channel parameter to vdr.5 (reported by Reinhard Nissl). - The SVDRP signon message now indicates the character encoding in use, as in 220 video SVDRP VideoDiskRecorder 1.7.1; Fri May 2 16:17:10 2008; ISO-8859-1. This may be useful for instance for external tools that provide EPG data, so that they can correctly encode the strings. - No longer calling FcFini() to avoid problems with older (broken) versions of fontconfig (suggested by Edgar Toernig). - Removed the compile time option VFAT to allow users of precompiled binary distributions to have full control over whether or not to use the --vfat option at runtime (suggested by Michael Nork). - First step towards switching to TS (Transport Stream) as recording format: + The new function cDevice::PlayTs() is used to play TS packets. + The new functions cDevice::PlayTsVideo() and cDevice::PlayTsAudio() are used to play video and audio TS packets, respectively. + The new function cAudio::PlayTs() is used to play audio TS packets. + The new class cPatPmtGenerator is used to generate a PAT/PMT pair that precedes the TS data in Transfer Mode. + The new class cPatPmtParser is used by cDevice to parse the PAT/PMT data in a TS in order to find out which streams it contains. + The new class cTsToPes is used to convert TS packets to a PES packet. + cTransfer no longer uses cRemux, and doesn't run a separate thread any more. It just generates a PAT/PMT and sends all received TS packets to the primary device's PlayTs(). + Live subtitle display no longer uses a ring buffer and separate thread. + cPesAssembler has been removed. Old VDR recordings only contain complete PES packets. + Since a TS needs to have a PAT/PMT, which requires the video stream type to be explicitly given, the format of the VPID field in the channels.conf file and the SVDRP commands NEWC/MODC/LSTC has been extended. The video stream type now follows the VPID and optional PPID, separated by an '=' sign. - Updated the sources.conf file (thanks to Oleg Roitburd). - Fixed a possible integer overflow in GetAbsTime() (thanks to Alexander Rieger). - Fixed a problem with calling isyslog() from within the SignalHandler() (thanks to Udo Richter). - Replaced the Finnish language code smi with suo (thanks to Rolf Ahrenberg). - Fixed wrong value for TableIdBAT in libsi/si.h (thanks to Winfried Köhler). - Errors in config files no longer keep VDR from starting. - Removed unneeded include files linux/dvb/dmx.h und time.h from remux.h (reported by Tobias
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
On Sun, Sep 07, 2008 at 12:11:35PM +0200, Klaus Schmidinger wrote: This version marks the first step towards using TS (Transport Stream) as recording format. It does this by switching the Transfer Mode to TS and introducing all the necessary cDevice and cPlayer functions to handle TS. Actual recording is still done in PES, though. This should provide a reasonable developing and testing environment for HDTV device plugins to prepare for replaying TS. :-) Thank you very much !!! I'll be trying some other ~VDR clone~ because of the lack of TS in vdr, but for me they are all *censored*... It's great to have this one, thank you very much for all your great work !!! -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
The sky plugin does not compile any more, because it uses PID_MASK_HI
which got renamed to TS_PID_MASK_HI. Patch is attached. A similar
problem strikes for streamdev.
Cheers,
Udo
--- vdr-1.7.1-old/PLUGINS/src/sky/sky.c 2008-09-07 13:34:53.0 +0200
+++ vdr-1.7.1/PLUGINS/src/sky/sky.c 2008-09-07 13:38:23.0 +0200
@@ -160,12 +160,12 @@
Data = tsBuffer-Get();
if (Data) {
// insert the actual PIDs:
-int Pid = (((uint16_t)Data[1] PID_MASK_HI) 8) | Data[2];
+int Pid = (((uint16_t)Data[1] TS_PID_MASK_HI) 8) | Data[2];
if (Pid == DUMMYAPID)
Pid = apid;
else if (Pid == DUMMYVPID)
Pid = vpid;
-Data[1] = ((Pid 8) 0xFF) | (Data[1] ~PID_MASK_HI);
+Data[1] = ((Pid 8) 0xFF) | (Data[1] ~TS_PID_MASK_HI);
Data[2] = Pid 0xFF;
}
return true;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
On 09/07/08 13:48, Udo Richter wrote: The sky plugin does not compile any more, because it uses PID_MASK_HI which got renamed to TS_PID_MASK_HI. Patch is attached. Thanks. At some point I guess I should just drop the sky plugin, since it's of no real use any more... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
On 09/07/08 13:55, Jelle De Loecker wrote: Multiproto_plus is quite outdated, Manu (the maintainer) has done a bunch of updates on the original multiproto tree (http://jusst.de/hg/multiproto) He even added support for the old API (yay) and merged the latest V4L tree with it. Basically, it compiles and it just works with everything :) Thanks. I forgot to update and verify that - I'm still using the one from http://jusst.de/hg/multiproto_plus, dated 2008-04-13 (was just too lazy to recompile a newer one). Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
Multiproto_plus is quite outdated, Manu (the maintainer) has done a bunch of updates on the original multiproto tree (http://jusst.de/hg/multiproto) He even added support for the old API (yay) and merged the latest V4L tree with it. Basically, it compiles and it just works with everything :) /Met vriendelijke groeten,/ *Jelle De Loecker* Kipdola Studios - Tomberg Klaus Schmidinger schreef: VDR developer version 1.7.1 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.1.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.0-1.7.1.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. This version marks the first step towards using TS (Transport Stream) as recording format. It does this by switching the Transfer Mode to TS and introducing all the necessary cDevice and cPlayer functions to handle TS. Actual recording is still done in PES, though. This should provide a reasonable developing and testing environment for HDTV device plugins to prepare for replaying TS. There appears to be a problem with replaying the payload from TS packets on Full-Featured DVB cards. On some channels this works rather fine (with only very small glitches from time to time), while on other channels there are heavy glitches and sometimes even the audio goes mute. My initial approach to replaying TS on FF cards was to simply strip the TS header and send the payload to the usual PlayVideo() and PlayAudio() functions, since the driver itself examines the data and assembles the 2KB PES packets it sends to the hardware. Since the FF cards can replay the TS data as it comes in from the transponder, my assumption was that the same should be possible in Transfer Mode. But maybe there is something wrong with this assumption? Could this be a driver problem? I don't think that simply throwing memory at the problem is the solution. Any thoughts? The changes since version 1.7.0: - Adapted the tuning code to the new DVBFE_SET_DELSYS API (thanks to Reinhard Nissl). VDR now uses the driver from http://jusst.de/hg/multiproto_plus. - Updated the Italian OSD texts (thanks to Diego Pierotto). - Removed obsolete $(NCURSESLIB) from the Makefile. - Implemented handling the standard component descriptor for AC3 (stream=4), as it will soon be used by the German ARD channels (thanks to Michael Pennewiß for advance information about this change). The previously used Premiere pseudo standard (stream=2, type=5) still works, but has apparently been wrongfully used by broadcasters from the beginning. - Added missing description of the 'S' channel parameter to vdr.5 (reported by Reinhard Nissl). - The SVDRP signon message now indicates the character encoding in use, as in 220 video SVDRP VideoDiskRecorder 1.7.1; Fri May 2 16:17:10 2008; ISO-8859-1. This may be useful for instance for external tools that provide EPG data, so that they can correctly encode the strings. - No longer calling FcFini() to avoid problems with older (broken) versions of fontconfig (suggested by Edgar Toernig). - Removed the compile time option VFAT to allow users of precompiled binary distributions to have full control over whether or not to use the --vfat option at runtime (suggested by Michael Nork). - First step towards switching to TS (Transport Stream) as recording format: + The new function cDevice::PlayTs() is used to play TS packets. + The new functions cDevice::PlayTsVideo() and cDevice::PlayTsAudio() are used to play video and audio TS packets, respectively. + The new function cAudio::PlayTs() is used to play audio TS packets. + The new class cPatPmtGenerator is used to generate a PAT/PMT pair that precedes the TS data in Transfer Mode. + The new class cPatPmtParser is used by cDevice to parse the PAT/PMT data in a TS in order to find out which streams it contains. + The new class cTsToPes is used to convert TS packets to a PES packet. + cTransfer no longer uses cRemux, and doesn't run a separate thread any more. It just generates a PAT/PMT and sends all received TS packets to the primary device's PlayTs(). + Live subtitle display no longer uses a ring buffer and separate thread. + cPesAssembler has been removed. Old VDR recordings only contain complete PES packets. + Since a TS needs to have a PAT/PMT, which requires the video stream type to be explicitly given, the format of the VPID field in the channels.conf file and the SVDRP commands NEWC/MODC/LSTC has been extended. The video stream type now follows the VPID and optional PPID, separated by an '=' sign. - Updated the sources.conf file (thanks to Oleg Roitburd). - Fixed a possible integer overflow in GetAbsTime() (thanks to Alexander Rieger). - Fixed a
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.1
On 09/07/08 16:48, Luca Olivetti wrote: El Sun, 07 Sep 2008 12:11:35 +0200 Klaus Schmidinger [EMAIL PROTECTED] escribió: t. + cTransfer no longer uses cRemux, and doesn't run a separate thread any more. It just generates a PAT/PMT and sends all received TS packets to the primary device's PlayTs(). Just asking before I try to recompile everything, but does it mean that output plugins (xine, dxr3, etc.) have to be rewritten? They can implement cDevice::PlayTs() if they need to handle the TS packets by themselves. Otherwise the TS payload will be extracted from the TS, assembled to complete PES packets and delivered via the existing PlayVideo() and PlayAudio() functions. I assume HDTV output plugins will want to handle the TS by themselves - that's the whole point in switching to TS. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
