For the media source device, I propose 2 devices: One is raw TS dump device. There you can always get raw dump directly as it is received by the vpeirq().
Second device is not a single device, but a directory of many demuxed devices, dynamically created/removed upon current TS autodetection (scan) or when user forces creation, by ioctl or preferrably from the shell just by touch /proc/<path>/<device> in special directory. This directory is analogous to usb devices directory. If you plug in some USB device, it will appear, if you unplug it it will disappear. usbdevfs can be used for this. Insted of usb devices, we will have demuxed PIDs so /dev/dvb/adapter0/vpid245, vpid245, apid482 etc should appear from the kernel demux automata. Those devices will have raw mpeg dump or whatever appears as the PID. We can go thru usb high layer for them, so something like /proc/bus/usb/dvb0vpid245 would be created that is equivalent to /dev/dvb/adapter0/vpid245. Creation of such devices will trigger kernel hotplug mechanism which in turn calls some shell script to start mpeg decoding or playback Important thing in the above approach is that we have DVB tuning, reception demux and packet source stuff independent from video4linux layer. Only consumer sink devices (record and playback devices) will depend on video4linux layer. For the consumer sink devices (video0) devices, I propose a pseudo-tty mechanism which is a mature unix technology. We can call it pseudo consumer device. The pseudo consumer device is actually internal kernel pipe connecting two end devices. source end of pseudo consumer device (pcsrc) is connected to userspace mpeg decoder decoder daemon (transcode mpg321 etc) sink end of pseudo (pcsink) consumer device is connected to the consumer application viewers (mplayer, xawtv, recorders, video out playback device etc). *** THE SCENARIO *** Suppose you tune to some station, userspace mpeg decoder daemon that reads raw TS device will scan available PIDs and determine how many pseudo consumer source-sink device pairs are needed. Then, userspace decode daemon creates each pcsrc device. When pcsrc is created, automagically pcsink is created by the kernel and connected with the internal pipe. high bandwidth block copy will happen there. Also, upon tuning, demuxed PID source devices will be created, hotplug action could be triggered and some additional or specific userspace decoders can be started. raw TS reception and hotplug autodetection daemons can exist at the same time and each can create its own pseudo consumer devices provided they are smart enough to choose different device names. In order not to waste CPU for unneeded decoding, mpeg is not generated at the source endpoint until user opens the sink endpoint device end attempts to read some data or use it for overlay screen display. All this can be done using methods already present in usbdevfs and devpts (usb high layer can be directly used to generate video0 sink device as if it were hotplugged like some usb camera). >From there on, you can use any v4l compatible application recorder/viewer/player. The Royal linux DVB V4 (or V5) API implementation will let you use web browser to tune to some frequency, and after 2-3 seconds it will display a mosaic of icons embedded in browser, each icon displaying each PID live for the tuned frequency. Then you click on one of the live icon pids to maximize the picture and hear the sound. Emard -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
