[linux-dvb] DVB API update

Georg Acher acher at in.tum.de
Tue Sep 18 14:26:13 CEST 2007


On Tue, Sep 18, 2007 at 03:33:25PM +0400, Manu Abraham wrote:
 
> > I have h.264 playback running on a really slow Geode with 300MHz. For a
> > 15Mbit/s stream, the TS path from the DMA buffers into user space needs
> > about 5% CPU with traditional memcpy(). I wouldn't call that optimization
> > worthy... What really counts is the postprocessing in user space (remuxing,
> > repacking, etc.). The API may support this with single PIDs per
> > read filedescriptor, but I don't think it makes a difference where the data
> > is actually filtered...
> > 
> 
> You are looking at a single DVB-S2 demod. There are dual S2 demods in a
> single chip config.
> Consider that with multiple adapters, even if you ignore post processing.

But you wouldn't use a 300MHz CPU for that anyway, because it has no CPU
power to do something else with the stream. I'm certainly the last who is
against optimization, but I don't see the case here to put much effort in
that.

> If you have a larger number of adapters and you have to do post
> processing, there is quite a large unnecessary overhead, even if you
> don't do software decoding.
> 
> Are there only a very few people having multiple DVB adapters in a PC ?
> (I guess people having dual and quad demods (single demod/chip) on an
> adapter and having multiple adapters can be quite a small fraction)

The Reelbox (with the 300MHz) has up to 4 tuners, the NetCeiver can have up
to 6 tuners (max 40Mbyte/s input rate). I did a lot of profiling
(oprofile/gprof) on the Geode, so I think I know what multi demods can "do"
with the system.

But the real performance problems appear in user space, not in the kernel.
Eg. vdr uses two additional ringbuffers to move the TS around (10% for one
channel). vdr's EPG parsing on the ARD transponder can take initially more
than 40% CPU (on the Geode). Repacking a simple SDTV-Stream with 6Mbits/s
into PES takes another 15-20%. Compared to that, the DVB subsystem is
neglectable... With faster CPUs (better memory system, larger caches) I
expect the impact to be even less.

-- 
         Georg Acher, acher at in.tum.de
         http://www.lrr.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias



More information about the linux-dvb mailing list