[linux-dvb] Alternative v4 demux API

[Michael Hunold <hunold@convergence.de>]

Hi all,

I'm not quite satisfied with the v4 API specifications regarding the new 
demux api. I'd like to propose a very different approach. I have 
discussed this with Johannes in private, but he did not feel like 
throwing away the things that have been discussed so far. 8-)

So I'm asking all of your for a public discussion about my ideas.

Let's start with some ascii art:

+------------+
| Frontend 0 |
+------------+
     ...
+------------+
| Frontend n |
+------------+

          +------------+
write() ->| Playback 0 |
          +------------+
                ...
          +------------+
write() ->| Playback n |
          +------------+

These are the INPUT devices. I won't discuss the frontend API here. The 
 playback devices" are new. They can be opened for writing,  usually 
you'll write TS or PS data to them. In theory, there might be other 
input devices like Firewire, LVDS, serial input devices and so on.
One important IOCTL:
- QUERY_CAPABILITIES: if this input currently delivers TS, PS, MPEG-1, ...

               +---------+
to input <---- | Demux 0 |
               +---------+
                   ...
               +---------+
to input <---- | Demux n |
               +---------+

The demux devices don't have much do to in my approach, they basically 
select 1 input fromt the n availabe inputs (frontends+playback units).

The following IOCTLs should be supported:
- QUERY_CAPABILITIES: if this demux can handle TS, PS, MPEG-1
- SET_INPUT: use input x for this demux

              +----------------+
              | MPEG Decoder 0 |
to demux  <-- +----------------+
              | APID|VPID|PCR  |
              +-----------------

              +----------------+
              | MPEG Decoder 1 |
to demux  <-- +----------------+
              | APID|VPID|PCR  |
              +-----------------

              +----------------------------+
              | General purpose PID filter |
to demux  <-- +----------------------------+ -> read()
              | PID0 |    ...       | PIDn |
              +----------------------------+

              +--------------------------------+
              | General purpose section filter |
to demux  <-- +--------------------------------+ -> read()
              |           PID                  |
              +--------------------------------+
              | Filter 0 |  .... | Filter n    |
              +--------------------------------+

Now come the "output" devices. They all have to be connected to one 
particular demux:
- SET_DEMUX: use demux x for this output

All of these devices have their own set of (logical) PID filters which 
can be of course map to the same h/w filters. Most of the time, they'll 
have some specialized filters for their special purpose, though.

The MPEG decoders have specialized APID, VPID and PCR filters, which can 
be set in one go:
- SET_APID_VPID_PCR: set all PIDs at once
Of course there are still the VIDEO and AUDIO devices -- they're needed 
to control the actual audio and video flow of the device.

Most of the time, a hardware has a fixed set of PID filters, which can 
be grouped together in very different ways. If you have 32 PID filters 
for example, you can have 32 individual filters (ie. device opens) with 
one PID each, or 16  filters (ie. device opens) with two PIDs each and 
so on.

So you can open the "General purpose PID filter" as many times as you 
want unless the hardware has enough PID filters left.
- ADD_PIDS: this allocates an array(!) of PID filters from the hardware 
pool and associates it with this device open.
- DEL_PIDS: delete an array(!) of PIDs
- START_FILTERING: start PID filtering
- STOP_FILTERING: stop PID filtering
- SET_BUFFER_SIZE: set output buffer size
- SET_THRESHOLD: set threshold for notifications upon poll()/select()
After START_FILTERING, you can poll() / read() from this filehandle and 
get your data.

Something like this goes for the "General purpose section filter", too. 
 You can open the device as many times as you want, unless the PID 
filters and/or section filters are exhausted.

- SET_PID: set the associated PID for this open
- ADD_FILTER: this allocates an array(!) of section filters from the
hardware pool with the usual parameters: filter, mask, mode
- DEL_FILTER: delete an array(!) of section filters
- START_FILTERING: start filtering
- STOP_FILTERING: stop filtering

Sometimes, you have specialized "stream recording units", sometimes this 
is just the same as the general purpose PID filters.

              +------------------+
              | recording        |
to demux  <-- +----------- ------+ -> read()
              | PID0 | ...| PIDn |
              +------------------+

You basically have the same set of IOCTLs as for the general purpose PID 
filters, perhaps you have some special IOCTLs that deal with streaming 
record.

To summarize this:
- mpeg-decoders can be opened once
- recording units can be opened once
- PID filters can be open multiple times, as long as there are PID 
filters available
- section filters can be openend multiple times, as long as there is one 
PID filter per open and enough section filters for satisfying the request

So, applications which use the mpeg decoders have to open them 
explicitely in my approach.
If an application needs x pid filters, it has to open the device x times 
and set the filters accordingly.
Same goes for section filters: open the device for every PID, set as 
many section filters on this PID as the hardware can serve.
The driver, of course, can map these things together again: if two 
applications set section filters on the same PID, the driver may compose 
this to one "logical" section filter if the hardware needs this.

The idea behind this approach is to separate all the different stuff 
away from the demux device, which does not belong there.
Currently, you have the mpeg decoders, PID and section filters in one 
big chunk. If you set a new section filter, you always specify the PID 
again, the dirty work is up to the driver. It's not possible to cleanly 
allocate, set, unset, start and stop filters, because you have to 
provide all informations in one call.
But video/audio/pcr for example has nothing to do with demuxing, it's 
mpeg decoding. Section filters are always bound to one PID, so why not 
one oper per PID?

With my design, all things are separated to where they belong:
video/audio/pcr filters to the decoder, PID and section filtering to 
general PID filters with associated section filters, which you have to 
open as many times as you need different filters.
If there is hardware behind it (like mpeg decoding, stream recording) 
provide multiple devices. If there is some dynamic association like with 
PID and section filters, make the device open multiple times.
Additionally, (if the hardware supports it) you can connect the 
different unit multiple times to the same demux. For example you can do 
live tv, stream recording and general pid and section filtering from one 
demux with a clean interface.

I thought about many different use cases: picture-in-picture live tv, 
live tv with multiple stream recording, general pid filtering for 
teletext in background, different section filters. I think that you can 
do everything with this approach, as long as the hardware supports it.

But I'd really like to hear your opinion where I might have missed 
something.

Thanks for listening,
Michael.



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.