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] http://www.lrr.in.tum.de/~acher "Oh no, not again !" The bowl of petunias _______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr