On Wed, Mar 19, 2003 at 03:42:40PM +0100, Haber, Thomas wrote: > Hi Johannes, > > i'm still not sure about it. > > > I've spent some time thinking about this. IMHO the most > > "natural" approach > > would be to use the demux file descriptor where you have set the > > appropriate filters, e.g. for video PES, and pass it to the SET_SOURCE > > ioctl for e.g. the video MPEG decoder. > > > Yes, but what about connecting the demux to the frontend ? > In the same way ? > I would prefer to do all the connection in the same style.
It would be more consistent to do so, but on a functional level it seems unnecessary because the frontend output can only go to the demux, and there will only be a very limited number of frontends in a system. So for DMX_SET_SOURCE it will be sufficient to specify the frontend _number_. For the demux outputs it's entirely different, because there are many of them, and they have no natural identification number associated with them. > > > How do we setup user area bridges ? (to override hardware barriers) > > > * a thread reading and writing ??? for sure not appropriate for > > > streams from the frontend but for other streams it is > > > > This is an implementation detail that would have to be solved in > > an individual device driver. Bridging via copy-to-userspace-and-back > > should be avoided, yes? > > What about drivers that don't know each other (differnt hardware - one > demux, one decoder)? What I meant to say is that we would probably want to have support for copying data within the kernel/driver, without having to copy data to userspace from one driver and back into the kernel to the other driver. E.g. VDR currently does a lot of copying in "transfer mode", and it works fine, but it's not particularly efficient. A more interesting related issue is bridging the gap between demux input/output and HDD read/write. With all of linux' filesystem stuff in between this will be challenging. Still, it is not important to decide how to implement it, or even *if* to implement it. It's just that the API should allow for it to be implemented. Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.