Re: [vdr] [ANNOUNCE] VDR developer version 1.7.32

2012-11-20 Thread Marx

On 19.11.2012 09:17, Klaus Schmidinger wrote:

On 19.11.2012 08:51, Marx wrote:

Sorry for small off-topic but can you recommend editor which can edit
TS stream, mainly by cutting off adverts? Besides VDR I have Enigma
based tuner and it saves TS stream, but differently from VDR so I
can't use VDR to edit.


Maybe this is the same problem as somebody else already reported,
with the PAT containing several PMT PIDs? I'm going to take care
of this in the next developer version of VDR.
Can you provide a short sample of such a recording (like a minute or so)?


It isn't problem with stream but how file is stored on disc. VDR saves 
0001.ts alltogether with some nfo files in named directory, while Enigma 
uses flat structure naming all files with date/time+film name.


Personally I prefer to cut video files on PC because UI is usually 
faster. I used to use VirtualDub and while it can work ok for mpeg2, 
it's rather useless for H.264 because can't work without recompression.

Marx


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.32

2012-11-19 Thread Lars Hanisch
Hi,

Am 19.11.2012 08:51, schrieb Marx:
> Sorry for small off-topic but can you recommend editor which can edit TS 
> stream, mainly by cutting off adverts? Besides
> VDR I have Enigma based tuner and it saves TS stream, but differently from 
> VDR so I can't use VDR to edit.
> Marx

 I have a workflow (on Windows) which generates really good videos.
- demux with ProjectX
- cut with Cuttermaran
- mux with mencoder (to mpg actually)

 But this will work only with SD/mpeg2 material.

 TS-Doctor ist good for repairing HD-Streams and Smart Cutter seems to be an 
analog solution like Cuttermaran, but I
haven't tested it yet. Smart Cutter and Cuttermaran reencodes only the GOP with 
the cut out/in and leave the rest of the
stream  unchanged. They allow cutting even on B frames so you can remove ads 
and you won't recognize the cut afterwards.

Lars.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.32

2012-11-19 Thread Klaus Schmidinger

On 19.11.2012 08:51, Marx wrote:

Sorry for small off-topic but can you recommend editor which can edit TS 
stream, mainly by cutting off adverts? Besides VDR I have Enigma based tuner 
and it saves TS stream, but differently from VDR so I can't use VDR to edit.


Maybe this is the same problem as somebody else already reported,
with the PAT containing several PMT PIDs? I'm going to take care
of this in the next developer version of VDR.
Can you provide a short sample of such a recording (like a minute or so)?

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.32

2012-11-19 Thread Marx
Sorry for small off-topic but can you recommend editor which can edit TS 
stream, mainly by cutting off adverts? Besides VDR I have Enigma based 
tuner and it saves TS stream, but differently from VDR so I can't use 
VDR to edit.

Marx


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


[vdr] [ANNOUNCE] VDR developer version 1.7.32

2012-11-18 Thread Klaus Schmidinger

VDR developer version 1.7.32 is now available at

  ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.32.tar.bz2

A 'diff' against the previous version is available at

  ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.31-1.7.32.diff

MD5 checksums:

068ba78fd427694dcc480fe3b2d07148  vdr-1.7.32.tar.bz2
222f1e9b4d4edaa6fe57286409614cc7  vdr-1.7.31-1.7.32.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.


The main focus of this version is on an improved frame detection code,
and improvements to the cutting process. When cutting a recording, VDR
now removes any "dangling" TS packets from the beginning of an editing
sequence and pulls in any "pending" TS packets at the end of a sequence.
It also fixes all timestamps and continuity counters.
However, while the results look much better now in, for instance, Kaffeine,
the TT S2-6400 still shows some video artifacts at the editing points, and
the Mac video player sometimes totally chokes on edited material.
I did spend a lot of time trying to find out what could still be wrong here,
but couldn't come up with any new ideas. So I think it's now time to invite
others to test this new cutting code, read the source code and try to find
out what's still going wrong here. Maybe (hopefully ;-) it's just some stupid
little error... ;-)


The changes since version 1.7.31:

- Pressing the Play key during normal live viewing mode now opens the 
Recordings menu
  if there is no "last viewed" recording (thanks to Alexander Wenzel).
  The same behavior has been implemented for the Blue key in the main menu.
- cIoThrottle::Engaged() is now also checked in 
cRemoveDeletedRecordingsThread::Action(),
  to suspend removing deleted recordings in case this is necessary to make room 
for
  new, ongoing recordings (suggested by Udo Richter).
- The cThread constructor now has an additional boolean parameter that can be 
set to
  true to have this thread run at a lower priority. Plugin authors that use low
  priority threads may want to use this instead of the calls to SetPriority(19) 
and
  SetIOPriority(7). The priority of a thread ("low" or "high") is now logged 
when the
  thread starts.
- Changed DTV_DVBT2_PLP_ID to DTV_STREAM_ID in dvbdevice.c to adapt to an 
incompatible
  change in DVB API 5.8 (reported by Derek Kelly).
  Removed the meanwhile obsolete definition of FE_CAN_TURBO_FEC.
- Fixed some compiler warnings under gcc version 4.7.1.
- Fixed setting the video format in the dvbhdffdevice (thanks to Torsten Lang).
- Fixed 'make install' to not overwrite existing configuration files (thanks to 
Peter
  Münster).
- Added including the Make.global and Make.config files to the dvbdhffdevice's
  libhdffcmd/Makefile.
- Added options to build a 32-bit version of VDR on a 64-bit machine to
  Make.config.template.
- Fixed handling VPS timers in case the running status of an event goes to '1' 
(not
  running) and later goes to '4' (running).
- If a frame position in the 'marks' file of a recording doesn't point to an 
I-frame,
  it will now be shifted towards the next I-frame, either up or down, whichever 
is
  closer (suggested by Udo Richter).
- Fixed a possible memory leak in SI::StructureLoop::getNextAsPointer() 
(reported by
  Sundararaj Reel).
- Fixed handling timers in case an event is modified and "phased out" while the 
timer
  is recording.
- Improved frame detection by parsing just far enough into the MPEG-4 NAL units 
to get
  the necessary information about frames and slices.
- The initial syncing of the frame detector is now done immediately after the 
first
  complete GOP has been seen. This makes recordings and especially pausing live 
video
  start up to twice as fast as before.
- Updated the Romanian OSD texts (thanks to Lucian Muresan).
- Fixed handling the very last entry in a recording index.
- The return type of cMarks::Add() has been changed to void, since due to the 
sorting
  of the list of marks the returned pointer might have pointed to a totally 
different
  mark. Besides, the return value was never actually used.
- Improved editing TS recordings by
  + stripping dangling TS packets from the beginning of a sequence
  + including pending TS packets at the end of a sequence
  + fixing all timestamps and continuity counters
  + generating editing marks for the edited version in such a way that each 
cutting
point is marked by an "end" and "begin" mark with the same offset
  + no longer generating an editing mark at the "end" of the edited recording 
(this
was actually generated at the beginning of the last GOP, so that a 
subsequent
edit would have cut off the last GOP)
  + no longer generating any editing marks if the edited recording results on 
just
one single sequence
  + ignoring pairs of editing marks that are placed at exactly the same 
position of
a recording when actually cutting the re