Is there a patch available with your modifications?
On So, Mär 18, 2007 at 04:30:02 +0100, Georg
> On Sun, Mar 18, 2007 at 01:26:03PM +0100, Reinhard Nissl wrote:
> > > I switched the repacking off in my vdr... I don't think that it is
> > > necessary.
> > Maybe you are right. The benefit of avoiding memcpys when repacking is
> > done already during the TS to PES transformation is void as long as one
> > cannot rely on getting repacked packets all the time.
> Due to the limited power of the Geode with 300MHz of the Reelbox, I've
> analyzed the TS-path in the vdr with gprof/oprofile and re-wrote the
> repacker from scratch and changed some of the related TS code in
> device/dvbdevice. It has a lot of optimizations:
> - The ringbuffer works with packet granularity (no single bytes), no extra
> sync checks are needed. Multiple memcpy of the same data is avoided as much
> as possible, especially for the video part.
> - The MPEG-sequence code search (ScanVideoPacket) is optimized for "simple"
> CPUs where the raw number of memory accesses and instructions is important
> (no memchr, that's slower on the Geode)
> - The video packer detects if the PES-flag in the TS header actually starts
> a new PES packet with I, P and B-frames at the TS beginning. After this
> detection, the search for start-of-picture is no longer done and the
> PES-flag only determines the separation. Since a lot of broadcasters are
> using the flag this way (especially the hingh bandwidth ones like ARD and
> ZDF in Germany) this saves a lot of CPU time. Services which don't allow
> this usually have low bandwidth anyway and are IMO not that important anyway
> (CNBC, Gods Channel, etc ;-) )...
> - There's one ringbuffer (and thus one data copying) eliminated in the way
> from the DVB-device to the TS receivers. Multiple ringbuffers in a row only
> give the illusion of better buffering...
> - The TS-dispatcher in cDevice::Action looks for bursts of TS-packets
> with the same PID and only does one Lock() and one Receive()-call for this
> burst instead for each single packet. Video data usually comes in bursts, so
> this saves a lot of unnecessary overhead. As the receiver function allows
> multiple packets (length parameter) this is perfectly legal. Unfortunately,
> some plugins don't respect the length parameter (older femon comes to mind,
> I don't know about the latest version). But that is easily fixed...
> The new repacker may have some issues with AC3 or some audio-only channels,
> but maybe it's worth to have a look at its code...
> svn co svn://[EMAIL PROTECTED]/testing/src/vdr-1.4/
> Georg Acher, [EMAIL PROTECTED]
> "Oh no, not again !" The bowl of petunias
> vdr mailing list
halim.sahin (at) t-online.de
vdr mailing list