VDR developer version 1.7.4 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.4.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.3-1.7.4.diff
WARNING: ========
This is a *developer* version. Not even *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging.
The main focus of this version is still the switch to Transport Stream (TS) as the recording format. There are still a few glitches, mainly
- Recording files larger than 4GB or with more than 255 separate files hasn't been tested yet. - Recording h.264 broadcasts has been roughly verified to work, but no replaying of such recordings has been tested yet.
DO NOT USE THIS VERSION FOR PRODUCTIVE RECORDINGS!! THE RECORDING OR OTHER FILE FORMATS MAY STILL CHANGE AND ANY RECORDINGS MADE WITH THIS VERSION MIGHT NOT WORK WITH FUTURE VERSIONS! Despite this, I do hope there will be some people who can take a look at the changes and maybe test the new recording format - and report bugs or provide fixes ,-)
IMPORTANT: ==========
You need to patch your driver with
ftp://ftp.cadsoft.de/vdr/Developer/av7110_ts_replay__1.diff
in order to replay TS recordings with full featured DVB cards! Without this patch replaying and Transfer Mode with these cards will not be possible!
The changes since version 1.7.3:
- Removed the '#define FE_CAN_2ND_GEN_MODULATION', since it was wrong and the flag is now in the driver, anyway. - The full-featured DVB cards are now given the TS data directly for replay (thanks to Oliver Endriss for enhancing the av7110 driver to make it replay TS data). The patch from ftp://ftp.cadsoft.de/vdr/Developer/av7110_ts_replay__1.diff implements this change in the driver. The patch av7110_v4ldvb_api5_audiobuf_test_1.diff mentioned in version 1.7.2 is still necessary to avoid audio and video glitches on some channels. - Added a typecast in cUnbufferedFile::Write() to avoid an error message when compiling on 64 bit systems. - Added some missing 'const' statements to cBitmap (thanks to Andreas Regel). - Fixed returning complete PES packets in cTsToPes::GetPes() (thanks to Reinhard Nissl). - Added a missing Detach() in cTransfer::Activate() (thanks to Marco Schlüßler). - Added clearing the TS buffers in cDevice::Detach() (thanks to Marco Schlüßler). - Fixed incrementing the continuity counter in cPatPmtGenerator::GetPmt() (thanks to Johann Friedrichs). - Fixed removing deleted recordings in case there is a problem. Once a recording caused a problem with removing, no others were removed any more and an ongoing recording could fill up the disk and cause other recordings to be deleted automatically (reported by Reinhard Nissl). - Added "DEFINES += -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE" to Make.config.template (thanks to Johann Friedrichs for pointing this out). Plugin authors should add this line to their Makefile or Make.config if they use file access functions that need special versions for 64 bit offsets. - The new command line option -i can be used to set an "instance id", which will be used to distinguish recordings of the same broadcast made by different instances of VDR (suggested by Frank Schmirler). This replaces the use of the "resume id" that was introduced in version 1.7.3. - Added checking mutexCurrentAudioTrack to cDevice::PlayTs() (thanks to Reinhard Nissl for pointing this out). - Fixed handling the pointer field in cPatPmtParser::ParsePmt() (thanks to Frank Schmirler - sorry I swapped two lines when adopting the original patch). - Checking the remaining packet length after processing the pointer field in cPatPmtParser::ParsePat() and cPatPmtParser::ParsePmt() (suggested by Frank Schmirler). - Checking the pointer field in cPatPmtParser::ParsePmt() only in 'payload start' packets (suggested by Frank Schmirler). - Changed cPatPmtGenerator to make sure the PMT pid doesn't collide with any of the actual pids of the channel. - Fixed cDevice::PlayTsAudio() and made cDevice::PlayTsVideo() return 0 if PlayVideo() didn't play anything. - Added an 'int' typecast to calculations involving FramesPerSecond() to avoid compiler warnings (reported by Winfried Koehler). - Fixed detecting frames for pure audio recordings. - Fixed editing PES recordings. The frame type in the index.vdr file generated for the edited PES recording is set to 1 for I-frames and 2 for all others (P- and B-frames). The exact frame type doesn't matter for VDR, it only needs to know if it's an I-frame or not. - The PAT/PMT is now only processed if its version changes (reported by Reinhard Nissl). - Fixed handling the maximum video file size (reported by Udo Richter). - Improved fast-forward/-rewind for audio recordings. The actual data is now sent to the output device, so that it can be replayed and thus cause the proper delay. For pure audio recordings the audio is no longer muted in fast-forward/-rewind mode, so that some orientation regarding the position within the recording is possible. There may still be some offset in the replay position displayed by the progress indicator when switching from fast-forward/-rewind to play mode, as well as in the current position during normal play mode. This is due to the various buffers between the player and the output device and will be addressed later. Note the new function cDevice::IsPlayingVideo(), which is used to inform the player whether there is video data in the currently replayed stream. If a derived cDevice class reimplements PlayTs() or PlayPes(), it also needs to make sure this new function works as expected.
Have fun!
Klaus
Приветствую, Klaus
Danke for your work.
when are you planning to implement in vdr the native h.264 support ? it will be in vdr 1.7.* branch ?
VDR developer version 1.7.4 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.4.tar.bz2A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.3-1.7.4.diff
Goga
On 25.01.2009 14:12, Goga777 wrote:
ðÒÉ×ÅÔÓÔ×ÕÀ, Klaus
Danke for your work.
when are you planning to implement in vdr the native h.264 support ? it will be in vdr 1.7.* branch ?
What do you mean by "native h.264 support"?
VDR just records the TS and sends it to the output device. It doesn't care too much about the actual contents. It's up to the output devices to replay h.264.
Or is there something missing that I'm not seeing at the moment?
Klaus
On Sun, Jan 25, 2009 at 02:13:25PM +0100, Klaus Schmidinger wrote:
What do you mean by "native h.264 support"?
VDR just records the TS and sends it to the output device. It doesn't care too much about the actual contents. It's up to the output devices to replay h.264.
Or is there something missing that I'm not seeing at the moment?
Didn't test vdr-1.7.4 (about to) but since 1.7.3 it works really great with vdr-xine and xine-lib-1.2 :-) (I also use vdpau : http://www.jusst.de/vdpau/files/xine-lib-1.2/ ).
I don't think anything is missing (maybe an easy way to convert all recordings done in h.264 which weren't in TS ?).
Am Sonntag 25 Januar 2009 16:08:30 schrieb Gregoire Favre:
On Sun, Jan 25, 2009 at 02:13:25PM +0100, Klaus Schmidinger wrote:
What do you mean by "native h.264 support"?
Didn't test vdr-1.7.4 (about to) but since 1.7.3 it works really great with vdr-xine and xine-lib-1.2 :-)
Hello,
@ Klaus: many thanks for this great piece of software!
I installed vdr 1.7.3 this weekend, with vdr-xine and xine-lib-1.2, it worked out of the box. Just one thing I found: when jumping between cut-marks or moving them the shown picture is not updated - so when pressing "9" to jump to the next mark I still see the last picture which was shown right before pressing "9". Moving the mark does not update either. This makes editing a bit less charming. Maybe it's gone with 1.7.4 ?
(I also use vdpau : http://www.jusst.de/vdpau/files/xine-lib-1.2/ ).
I also tried vdpau (r181, same url) but it seems to me as if everything was worse with it: SD was jumpy, some frames were ok and smooth, then a break/stutter, then again smooth. Stuttering every second or so. HD (arte 1280x720) was not shown at all - without vdpau it worked stuttering but I got a picture. It seems to work for you - How did you manage?
Cheers,
Ulf
when are you planning to implement in vdr the native h.264 support ? it will be in vdr 1.7.* branch ?
What do you mean by "native h.264 support"?
VDR just records the TS and sends it to the output device. It doesn't care too much about the actual contents. It's up to the output devices to replay h.264.
Or is there something missing that I'm not seeing at the moment?
I kept in mind the h264 patch from Reinhard Nissl for vdr 1.7.0.
As far as I understand you - for vdr 1.7.4 no need to install any patches for h264 support ?
Goga
On Sun, Jan 25, 2009 at 09:02:46PM +0300, Goga777 wrote:
I kept in mind the h264 patch from Reinhard Nissl for vdr 1.7.0.
This was only needed because of the PES issue, with TS it works out of the box :-)
As far as I understand you - for vdr 1.7.4 no need to install any patches for h264 support ?
You're right.
Have VDR-1.7.4 up and running with nexus-s so far. And plenty of timers set so recording & playback testing will be extensive. :)
VDR developer version 1.7.4 is now available at
Something made the hvr-4000 to work with this version of driver. With exactly same drivers and channel.conf file and streamdev-plugin and mplayer, the vdr-1.7.3 is not able to tune dvb-s channels but vdr-1.7.4 works :-)
Mika
Hi Klaus,
Klaus Schmidinger schrieb:
DO NOT USE THIS VERSION FOR PRODUCTIVE RECORDINGS!! THE RECORDING OR OTHER FILE FORMATS MAY STILL CHANGE AND ANY RECORDINGS MADE WITH THIS VERSION MIGHT NOT WORK WITH FUTURE VERSIONS!
do you think that this will really change in the future? If I record now with vdr 1.7.4 normal dvb-s recordings, will I be able to watch them with future versions of VDR?
Best regards, Matthias
On 05.02.2009 08:15, Matthias Fechner wrote:
Hi Klaus,
Klaus Schmidinger schrieb:
DO NOT USE THIS VERSION FOR PRODUCTIVE RECORDINGS!! THE RECORDING OR OTHER FILE FORMATS MAY STILL CHANGE AND ANY RECORDINGS MADE WITH THIS VERSION MIGHT NOT WORK WITH FUTURE VERSIONS!
do you think that this will really change in the future?
I don't know. As you may have seen there were problems with the PAT/PMT, so maybe there are still other problems that haven't surfaced yet.
If I record now with vdr 1.7.4 normal dvb-s recordings, will I be able to watch them with future versions of VDR?
If I knew the answer to that, I guess I wouldn't have had to write the above statement ;-)
Klaus
Hi Klaus,
Klaus Schmidinger schrieb:
If I knew the answer to that, I guess I wouldn't have had to write the above statement ;-)
;) Yeah you are right. I think I will wait for version 1.7.5 and then I will start to test it.
Best regards Matthias
-
Goga777 -
Gregoire Favre -
Klaus Schmidinger -
Matthias Fechner -
Mika Laitio -
Ulf Elsner -
user.vdr