[linux-dvb] Re: V4 API proposal

[Johannes Stezenbach <js@convergence.de>]

On Fri, Mar 07, 2003 at 02:15:41PM +0100, Haber, Thomas wrote:
> Florian Schirmer wrote:
> > Thomas Haber wrote:
> > >The usage of DMX_GET_SOURCE & DMX_SET_SOURCE is suitable for connecting 
> > >demux to frontend. But how to connect Audio to a Filter ?
> > >I propose to have a common mechanism for every device:
> > > * To set up cascading element easily.
> > > * To be able to stream to differnt devices in parallel.
> > 
> > Difficult item. I've read your proposal. Personally i do not like to
> > sink->source/id idea. We will need an own ioctl+device for every
> > decoder/target to support it. (PCR, TXT, AUDIO, VIDEO, TAP).
> > 
> > Adding an output_t field/map to the filter is what i propose. 
> > But i know
> > that Johannes doesn't like it at all. We need some more oppinions!
> 
> But i think the sink-source approach is pretty appropriate.
> We should not stick on some common use cases.
> What comes after the video decoder ?
> The output ? , a scaler ?, a file ?,
> or maybe am mpeg encoder for dvd writing (transcoding),
> or maybe all of  them in parallel ?
> On audio the same.
> In digital media area we have consecutive elements streaming data.
> For sure this is not easy, especially we may have some elements in one
> hardware and others somewhere else. So elements in one hardware 
> can be connected directly (implicit streaming) and in the other
> case we need to setup a user area bridge (explicit streaming).
> But to have these elements connected in one simple way is pretty needed.
> And there you need to decide the mechanism for all of them.
> 
> In the sink-source approach you say that an element can be connected
> (SET_SOURCE) to an output of another element. And this element
> can offer outputs to his possible sinks.
> 
> One question was how to identify an element ?
>  * the name ???
>  * the fp ???
>  * an id  ???
>  * something else ???

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.

It seems not difficult to implement (look at linux/fs/ioctl.c sys_ioctl()
for how to get the struct inode *inode and struct file *file
from the file descriptor, and thus the internal demux data necessary for
the connection). An additional check will be necessary to ensure the
fd actually referes to a demux device.

The drawback is that there is no other ioctl that uses a similar
technique. So maybe this approach is too weird? Not Linux-like?


> 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?


Johannes


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