Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: [RFC] Limitations of current filtering



On 05 Dec 2003 15:06:58 +0000
Luca Abeni <lucabe72@email.it> wrote:

> Sorry, I am not an expert, but I think this kind of demultiplexing shoud
> be done in user space. In other words: I think that a single dvr device
> is ok: we can select all the pids that we need and then a user-space
> program can read the dvr device and generate all the desired TSs (it is
> pretty simple, I think).

This only works if you know all the pids at the start.
Consider this: I want to watch channel 1, so
  szap -r channel1
  mplayer -cache 1200 /dev/dvb/adapter0/dvr0
after some time I want to record channel2. How can I do it? (without
interrupting mplayer, if possible).

Obviously it can be done in user space, but with your reasoning
I could just have a "hub" daemon in user space which reads the entire ts
(pid=8192) and then handles requests from clients. The kernel code
could be extremely small if we avoid any filtering.
Why so much complication?

Consider tcpdump, I can run many istances on the same interface and
for every one of them I can specify what type of filtering (if any) I
want.

> I suspect that any other solution would require to move this simple
> demultiplexing code from user space to kernel space. But, as I said, I
> am not an expert (just a random user) hence I might be completely wrong.

Yes, some kernel support is needed (this is why this thread exists).
But kernel space is the right place for this work (you used the word
"simple" yourself).

-- 
   Roberto Ragusa    r.ragusa at libero.it


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index