[vdr] [ANNOUNCE] VDR developer version 1.7.1

Jelle De Loecker skerit at kipdola.com
Sun Sep 7 13:55:11 CEST 2008

Multiproto_plus is quite outdated, Manu (the maintainer) has done a 
bunch of updates on the original multiproto tree 
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
> ========
> 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 Grimm).
> Have fun!
> Klaus
> _______________________________________________
> vdr mailing list
> vdr at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxtv.org/pipermail/vdr/attachments/20080907/6796d3a5/attachment-0001.htm 

More information about the vdr mailing list