On Thu, Mar 13, 2003 at 04:21:39PM +0000, Franck Arnaud wrote: > Emard: > > > I would also suggest the global idea should be > > to try to optimize the api for budget-type cards only, > > and silently discard any onbard mpeg or hardware > > demux as if we already had mpeg2 decoder and descrambler > > in open source either in the kernel or as external application. > > Could it be possible to modularize the drivers into > distinct player and source interfaces that do not > depend on each other? Playing would be like > cat /dev/tsreceiver0/source | /dev/mpeg0/sink, I > wonder if there is a way in Linux to do that > with zero copy or otherwise efficiently, which > could allow this separation even when both functions > are implemented by the same chip(set).
I think it is good to distinct the source of packets on the source media (cable, lnb, terrestrial) from the sink, on the consumer media, the video display or recorder. Besides, some frontends are bidirectional, like DVB-C cable modems or upcoming sat broadband interactive So the backwards path should be possible, from the video camera/player consumer media packets can travel back into to the source media (cable, transmitter). Not only to receive a packet from the source but also to transmit the whole stream back into the source media should be done easy: cat stream.ts > /dev/dvb/adapter0/media This is analogy as the networking. There is raw socket that is capable of reception and transmission of every and any packet, while tcp/ip layer with firewalling is there to selectively receive, route and transmit. In analogy, DVB V4 api has to be capable of raw stream reception and transmission over a special RAW media socket/device while it would also have all higher DVB layers with demuxing, pid reception on another high-level automatic device directory. so it will be possible for external user-space mpeg daemon to take whole stream, demultiplex internally and mpeg decode all stream pids simultaneously and pipe that back to the sink. for lower CPU capacity, demux should autodetect pids in TS and register discrete pid stream devices for every PID it can find, (something like usbdevfs) for some of those separate devices a hotplug shell script can be configured to automatically start single stream mpeg decompression via e.g. mplayer and pipe it back to 'sink' devices for recording or display. It will involve lots of block copy operations, I know, but dual channel high bandwidth DDR memory controllers on P4 and AMD will handle it all in the background so the user won't even notice anything. > frontend it seems inconsistent now: diseqc is > user space (you build diseqc command and send > them through a generic "send diseqc command" > API, you could have ioctls for each diseqc function > instead) while the frontend itself is kernel space I think currently there's a mess. I'd like luxury /proc frontend just with text parsing device like: echo "19.2E" > /proc/dvb/adapter0/tuner echo "12345.500 H 22000" > /proc/dvb/adapter0/tuner tuner will be controlled from a http-based php4 script, featuring also initial motor calibration funcitions User will tune (zap) using the web browser. Emard -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
