[linux-dvb] Re: C/A routing Question

[Ralph Metzler <rjkm@metzlerbros.de>]

Johannes Stezenbach writes:
 > > - Move the memory frontends to separate devices.
 > >   Either also call them frontend with type memory frontend
 > >   or call them memfrontend, mfrontend, dvrin, ... whatever
 > >   They should offer mmap, write, etc. maybe even a software controlled
 > >   rate control (some chips have it in hardware) to allow for decent 
 > >   non-blocking writing.
 > >   Each demuxN can select which frontend (no matter if real or memory)
 > >   to use as input.
 > 
 > I seen that you've already defined FE_MEMORY and FE_NET in your
 > version of the API header files.
 > 
 > I for one would be happy with a /dev/.../frontend of type FE_MEMORY.
 > How do we handle capabilites, i.e. if we can feed TS, PS and/or AVPES
 > into the frontend? Is this handled by the demux that we connect to
 > the frontend?

Yes, this should be the responsibility of the demux. Just add
capability ioctls there.
The frontend could be rather dumb. Syncing to TS boundaries, etc. can
also be handled by the demux. It will have to do that anyway for 
budget cards which deliver unaligned data (e.g. Bt878/fusion cards).
Demux hardware usually does it by itself.

 
 > I'm not shure how to handle DMA capable playback from HDD or DVD.
 > Maybe someone else has an idea.

Not so easy to answer. mmap only saves one copy.
DMA to/from user mem would of course be best. Wasn't there some
discussion beore how to do that for the HDD side?

 
 > As for FE_NET, I'm not shure, too. Isn't it better to implement
 > the network stuff for DVB-IP in userspace (e.g. a dvb-ip deamon)
 > and feed the TS into the FE_MEMORY frontend?

It probably is but it could be easier to prevent copying when 
handling it all in the kernel.

 
 > > - Keep dvr for output only. 
 > >   Do not allow dvr as output for demux device filters but use separate
 > >   calls. Here it is enough to use a PID bitmask to select PIDs.
 > >   dvrN should still be associated with demuxN since even on hardware with 
 > >   separate "DVR filters" they usually share the input with one demux
 > >   channel.
 > >   On hardware where filters of demuxN have to be used to create the dvrN 
 > >   output the driver hides it and uses them internally. The number of 
 > >   selectable PIDs is restricted by hardware and can be asked via ioctl.
 > >   With software filters one could even allow to have several opens
 > >   of dvrNs and feed different PID arrays to each dvrN. 
 > 
 > I.e. open("/dev/.../dvrN"), then DMX_DVR_SET_PIDS(int num, int16_t pids[])?

Yes. This should make recording all PIDs of one service very easy.
A software filter implementation should also be simple.
Now this kind of filter even seems to fit perfectly to some hardware 
as Rob McConnell described in his mail. 


Ralph


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