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
