[linux-dvb] Re: V4 API proposal

["Haber, Thomas" <THaber@tee.toshiba.de>]

Hi Florian,

> 
> Hi,
> 
> >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!
> 

A agree that my proposal was not the best in the world !!!

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

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

> 
> >> A) allow just a single pid per call
> >> B) allow multiple pids per call
> >> C) require multiple pids to be set in a single call
> >> 
> >
> >What way ever. It must be possible to add and remove filters while 
> >recording the program without any interruption to get in sync
> >with updated PMTs (new services in the program).
> 
> This is impossible when using C. So probalby B will make it 
> into the final
> draft.

This should be fine.



Regards,

thomas








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