Hi, Is there a patch available with your modifications? Thanks Halim On So, M?r 18, 2007 at 04:30:02 +0100, Georg Acher wrote: > 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://anonymous@xxxxxxxxxxx/testing/src/vdr-1.4/ > > -- > Georg Acher, acher@xxxxxxxxx > http://www.lrr.in.tum.de/~acher > "Oh no, not again !" The bowl of petunias > > _______________________________________________ > vdr mailing list > vdr@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Halim Sahin E-Mail: halim.sahin (at) t-online.de
