[linux-dvb] Re: V4 API proposal

[Emard <emard@softhome.net>]

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