[linux-dvb] DVB API update

Manu Abraham abraham.manu at gmail.com
Tue Sep 18 14:12:18 CEST 2007

Rudy Zijlstra wrote:
> Manu Abraham wrote:
>> Georg Acher wrote:
>>> On Tue, Sep 18, 2007 at 02:50:09AM +0400, Manu Abraham wrote:
>>>>> The recording filters are exactly the piece from V4 which has the
>>>>> "mmap DMA buffers" zero copy API. But to be honest, I don't think
>>>>> it's important on a PC which can copy > 1GByte/s in RAM. More
>>>>> interesting would be the ability to have multiple independant filtered
>>>>> TS outputs instead of just one dvr device.
>>>> Currently have you tried playing back a High Bit rate H.264 stream
>>>> default of a DVB-S2 stream ? I guess not.
>>>> If you have had, you will see my reasons why i am trying to optimize
>>>> the
>>>> overheads.
>>>> BTW: it is not RAM that matters here, but CPU horsepower
>>> 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.
>> 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)
> 2 systems with each 4 DVB tuners. test system has 3 DVB-S + 1 DVB-C.
> operational its 4x DVB-S
> The DVB-C is capturing H.264 though.... and not problems in capturing.
> capturing and demux is not the problem. Displaying it (postprocessing) is.

True, the issue with post processing seems to be open ended.

More information about the linux-dvb mailing list