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) _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
