Re: How to handle independent CA devices

[Oliver Endriss <o.endriss@gmx.de>]

On Saturday 18 September 2010 14:23:29 Manu Abraham wrote:
> On Sat, Sep 18, 2010 at 6:17 AM, rjkm <rjkm@metzlerbros.de> wrote:
> > Manu Abraham writes:
> >
> >  > > You still need a mechanism to decide which tuner gets it. First one
> >  > > which opens its own ca device?
> >  > > Sharing the CI (multi-stream decoding) in such an automatic way
> >  > > would also be complicated.
> >  > > I think I will only add such a feature if there is very high demand
> >  > > and rather look into the separate API solution.
> >  >
> >  >
> >  > It would be advantageous, if we do have just a simple input path,
> >  > where it is not restricted for CA/CI alone. I have some hardware over
> >  > here, where it has a DMA_TO_DEVICE channel (other than for the SG
> >  > table), where it can write a TS to any post-processor connected to it,
> >  > such as a CA/CI device, or even a decoder, for example. In short, it
> >  > could be anything, to put short.
> >  >
> >  > In this case, the device can accept processed stream (muxed TS for
> >  > multi-TP TS) for CA, or a single TS/PS for decode on a decoder. You
> >  > can flip some registers for the device, for it to read from userspace,
> >  > or for that DMA channel to read from the hardware page tables of
> >  > another DMA channel which is coming from the tuner.
> >  >
> >  > Maybe, we just need a simple mechanism/ioctl to select the CA/CI input
> >  > for the stream to the bridge. ie like a MUX: a 1:n select per adapter,
> >  > where the CA/CI device has 1 input and there are 'n' sources.
> >
> >
> > It would be nice to have a more general output device. But I have
> > currently no plans to support something like transparent streaming
> > from one input to the output and back inside the driver.
> 
> 
> Maybe it wasn't very clear ... (Streaming from one input to the output
> and back inside the driver what you are implementing is not what I had
> in mind.)
> 
> Currently for any independant CA device what you need is a stream to
> the bridge where it can route the same to the CI slot.
> For a generic device capable of doing any other gimmicks also, what
> you need is an input to the bridge.
> 
> So, what I was trying to say is that, let's not limit the input path
> to CA alone. For explanation sale let's term in as TS_IN
> 
> The TS_In interface is a simple interface where an application can
> just write to the TS_IN interface, which goes to the DVB_ringbuffer
> and hence to the bridge. I think, this is all what it should do.
> 
> We have 3 application uses cases here, based on different hardware types.
> 
> 1. Bridge is reading from TS_IN (from a user space application,
> streams from a single TS) for sending stream to CA, the normal way
> (All things are fine)
> 
> 2. Bridge is reading from TS_IN (from a user space application,
> streams from multiple TS's) for sending to CA. This is also same as
> (1) but just that the user space application is writing a "remuxed"
> stream to TS_IN
> 
> 3. Bridge is reading from TS_IN (from a userspace application) The
> bridge has multiple DMA channels. The bridge driver can load page
> tables from another channel, whereby the bridge is routing to another
> interface itself completely. This is a hardware feature, so we don't
> need to get data manually in software from one interface to the other.
> 
> 
> All this just needs the input path to be generic. An input interface
> such as TS_IN can feed the stream to an onboard decoder or any other
> post-processor as described with (3)
> 
> Only in the case of (2) the application really needs to do some thing
> in real life, ie to "Remux". But you can omit out the application to
> handle (2). Where somebody can implement it any later stage of time,
> if there's any interest. I guess nGene can do (1) and (2)
> 
> So, I wonder whether we should name the interface CA itself, where
> otherwise it can suit other application use cases as well. In such a
> case it becomes not limited to CA alone, to put short. Implementing a
> simple buffering alone (the rest of the necessities with the driver),
> will make the interface generic.

There is already an implementation for some kind of TS input:
dvb-apps/test/test_dvr_play.c can be used to write a TS stream to the
decoder of the old full-featured card (ttpci driver) through the dvr
device. Wouldn't it make sense to use this feature for TS input?

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------