[linux-dvb] Re: LinuxDVB V4 API questions (3)

[Michael Hunold <hunold@convergence.de>]

Hello,

On 04/07/04 15:55, Ralph Metzler wrote:
> Alasdair FARMER writes:
>  > 2)  With regard to playback of recordings I am unclear how this will work in the new model...  If a recorded stream were being written to a demux then which instance (given that the handle is actually to a filter rather than a demux itself).  I am not convinced that a memory frontend is the correct or best solution.  The semantic model I am working with is that the frontend is providing a transport stream to a demux which is filtering and passing the appropriate sub streams on to a decoder/storage.  The f
>  > rontend is responsible for presenting a single transport stream to the demux, dealing with any issues of source or routing.  I would actually like to see a write interface on the frontend so that a recorded stream could be written to a frontend (rather than the stream come from a tuner).  This neatly maintains a consistent model and removes some complexity at demux level.  In our scenarios, it is not actually possible to 'write' to a demux anyway, a recorded stream would have to be feed back into what is 
>  > essentially a frontend - so for our hardware solutions, we would need a write api on a frontend anyway.  This also simplifies CA considerations.
>
> I proposed using frontends with type memory as input before. Somebody
> else then thought one should use general input devices (AFAIR 
> Florian Schirmer?). Somehow this got dropped again in favor of 
> directly writing to demuxes. But I just checked and it is still
> mentioned in the dmx.h file. 
>  
> I also think that using the demux for memory input does not make much 
> sense. Usually you have demux unit with several demuxes and several
> inputs and each demux can choose the input it wants to use, 
> including memory input. 
> So, the "frontend" devices, wether there is an actual frontend, 
> memory DMA hardware or something else connected to it (other parallel
> or serial inputs from other devices), should correspond to these
> inputs.
Both solutions (playback trough demux or playback through memory 
frontend device) are basically the same, but with one exception.

Suppose you have 1 "memory frontend", two demuxes and two decoding units 
in hardware. If you make the playback through a memory frontend, then 
for certain hardware it's possible to connect the output of the frontend 
to both demuxes and both demuxes to one mpeg decoder each.

This may be not possible if you playback the data through the demux 
directly, because usually you cannot connect both mpeg decoders to one 
demux.

If it comes to dedicated firewire inputs and other nice things, it 
really might be worth to extend the "memory frontend" approach.

> These devices should then offer calls for rate control as some memory
> DMA interfaces offer them and other calls for other hardware like
> firewire, etc. The question is how general you want to make
> this. Should the device enumerate capabilities and possible settings 
> (like e.g. V4L2 devices) or is it enough to support a standard set 
> of input devices?
Hm, I'm not sure. I'm currently reconstructing the frontend handling in 
dvb-core for the v4 api, so I'm going to enfore the memory frontend 
stuff to see how it's going to be.

> Ralph
CU
Michael.


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