Gert Vervoort writes: > > > > > >As far as framework goes, we're aware of DVB and I looked very briefly at it > >but none of us have any implementation experience with either ( volunteers > >welcome! ;) that or V4L2. I did notice that V4L2 will need some work to deal > >with an MPEG compressed stream. > > > V4L2 can deal perfectly with a MPEG compressed stream. At work I have a > prototype board running with a SAA7134 PCI bridge/video decoder and a > SAA6752 MPEG-2 encoder. It uses the SAA7134 driver: > http://bytesex.org/saa7134/ . > I initialise the MPEG encoder via the I2C user space device and then I > can read a transport stream from the card, by just simply reading from a > V4L2 device: > > cat /dev/video1 | mpeg2dec -t 0x100 > > And this is exactly what a kernel space driver should do; just pass a > compressed stream to user space. The DVB API adds mux/demux > functionality to kernel space, but this is clearly a user space issue > instead of a kernel space issue. > Not if the demux is in hardware. As I said the DVB API makes more sense for the decoder part of the pvr 350. Although you need more for encoding than supporting open and read. If your encoder card has the ability to provide more than one cmpressed format and bitrate (and whatever other parameters you have to set for MPEG encoding) you need an API (i.e. some ioctls) that let you control these features, in my opinion user space I2C is not suitable for that because that would limit you to one particular hardware and would limit the user to root or give to much ability to mess up the system. Marcus -- /--------------------------------------------------------------------\ | Dr. Marcus O.C. Metzler | | |--------------------------------|-----------------------------------| | mocm@xxxxxxxxxxxxxx | http://www.metzlerbros.de/ | \--------------------------------------------------------------------/
