> > > > 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, whether 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. >
Sounds promising... For our purposes we have no option but to feed data in through a frontend, our hardware does not allow writing directly to the demux. A demux takes an input from a frontend, that frontend might have as its source either a tuner, data fed directly to an IO port (we refer to this as a SW transport stream) or a 1394 port. We have no other way to deal with 'memory frontends', in addition, obviously, the CA is directly coupled to the data passing through the demux hardware - so we couldn't fake something up either. Ali. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
