[linux-dvb] Re: V4 API proposal

[Emard <emard@softhome.net>]

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 listar@linuxtv.org with "unsubscribe linux-dvb" as subject.