[linux-dvb] Re: Alternative v4 demux API

[Rob.McConnell@Zarlink.Com]

Hi Folks,

I have finally had some time to have a look at your proposal Michael and
think it is better than what we have at the moment.  It certainly seems to
fit the hardware requirements from our end, so I will comment appropriately
below.  Please accept my apologies for a long email this is going to
be.........  : )

> 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,
...

Having the ability to select the delivery format (parallel or serial) of
the TS/PS to a potential input/selector device would be useful. I guess
this would be an ioctl on the front-end device. That's one ioctl for the
front-end device API.... : )

Having separate input devices even for playback would be useful.  Some
hardware allow DMAs from memory to demux hardware to occur for playback in
PVR applications.  Others, you cannot write to the demux device, but
instead to a "front-end" block that then forwards the data to the demux
packet filters (aka PID/section/PCR filters) and then on to the A/V
decoders.

I personally think that for PVR playback, the write() syscall would
probably not be used but instead ioctl's to setup a DMA transaction on the
device to achieve the throughput would be needed.  These ioctls could setup
the source memory address, the size of each transaction and a count of
transactions to perform. Hardware would then perform the necessary ACK/REQ
handshaking to control the flow of data.

Having a separate playback device would also allow ioctls such as speed
control to be incorporated in the design.  You could setup the playback
device to allow different transfer rates of data to allow for trick modes
on PVR playback.

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

OK, so this is what is known as a router or input selector.  You can have
say 8 different input sources (TS/PS/...)  but only 3 physical demux units
or maybe only 1 physical demux unit that can accept 2 streams in.

In the latter case where you only have 1 physical demux unit that can
handle only a subset of the possible input streams to the router/input
selector block, then having "logical" demux devices for each input stream
would be required.  This should follow the current V4 proposal.

> 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

Yes, this is fine.  I would also have an ioctl to query what input sources
are available.  For example, you may only have h/w that can accept a single
TS from a single frontend.  In this case, a GET_CAPS ioctl with the number
of front-end devices returned would be needed.  This could also be used for
the number of "playback" devices as well.

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

I like the idea of the "output" devices.  However, I think we can
implicitly route the output from a demux device/input selector to the input
of an "output" device as follows:

Let's create a /dev structure for 2 demux devices.  The first can provide
filtered data to A/V decoders and to memory.  The second demux device can
only provide filtered data to memory (no path for A/V decoders).

Let's keep the "/dev/dvb/adapter0/demux0" nomenclature and we shall make up
new device names for the specific filters (e.g. pidfilter, secfilter,
mpgfilter, recfilter) and for the input selector/router (e.g. router).

We get:

/dev/dvb/adapter0/demux0/router
/dev/dvb/adapter0/demux0/mpgfilter
/dev/dvb/adapter0/demux0/pidfilter
/dev/dvb/adapter0/demux0/secfilter

/dev/dvb/adapter0/demux1/router
/dev/dvb/adapter0/demux1/pidfilter
/dev/dvb/adapter0/demux1/secfilter

Now through this dir hierarchy we can see that demux0 (the first demux
device unit) can handle filtering of data (TS/PS) for mpeg decoders, pid
filters and section filters.  The 2nd device cannot handle filtering of
data for mpeg decoders as there isn't a route to them in hardware (say).

We can implicitly connect these "output" filter devices to the required
input selector "demux" device by just looking at the minor number.

e.g.

[ ][ ]             [ ][ ]           [ ][ ][ ][ ]

2 bits            2 bits            4 bits for dvbdev type
for adapter       for dvbdev
number            number

For /dev/dvb/adapter0/demux0/mpgfilter we could have (e.g. where mpgfilter
type is 1):

[0][0]             [0][0]           [0][0][0][1]

For /dev/dvb/adapter0/demux1/mpgfilter we could have:

[0][0]             [0][1]           [0][0][0][1]


So when we open a "mpgfilter" device we know immediately that it is
connected to either demux0 or demux1 by looking at the minor number.  We
would not have to have an explicit "SET_SOURCE" ioctl on the "output"
filter device.

In this way, we can group the filtering capabilities of a demux device
together quite nicely and there is also room for adding new device types if
and when required in the future. Some hardware that I have seen also has
"string" filtering capabilities where the filtered data is scanned for a
string to match before outputting to memory.

How does this look? Comments?

> So you can open the "General purpose PID filter" as many times as you
> want unless the hardware has enough PID filters left.

What about "logical" demux devices that share a pool of filters?  In this
case, we would have to ensure that there is a minimum amount of filters per
"logical" demux device to get the job done.  From what I have seen, the
hardware usually has more than just 32 PID filters in this case. Just
divide up the filters evenly amongst the "logical" demux devices.

> - 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

What would this be used for other than recording a muxed stream to hdd?
Wouldn't you use the "recording" filter to do this?  Would it not be
simpler to just have the DVB_DMX_SET_PID_FILTER ioctl that accepts a simple
filter spec with a single PID entry?

> - START_FILTERING: start PID filtering
> - STOP_FILTERING: stop PID filtering

Maybe not required now if only a single PID filter can be setup.  No need
to sync multiple PID filters together.  You could keep it just to be
consistent with the section filters below, though.

> 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

Good.

> 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.

Agreed, you may want to simply change the section filter spec without
wanting to change the PID entry.  This is common practice when only wanting
to receive section tables that have a different "version number" from the
current one.

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


I also have another scenario where your proposal would fit the hardware
better than the current V4 one.

Take a demux unit where each PID filter can choose one of 2 input streams
and each PID filter can output to one of 2 output channels.  In this case,
you have 4 output channels coming from the different sources:

           |--------| Stream #1  |----------|
TS #1 ---> | Router |----------->|          |-------> From stream #1 to
channel #1
           |        |            | PID      |-------> From stream #1 to
channel #2
TS #2 ---> |        |            | Filters  |
...                              |          |
                      Stream #2  |          |-------> From stream #2 to
channel #3
TS #N ---> |        |----------->|          |-------> From stream #2 to
channel #4
           ----------            |----------|

In the current V4 API, we would have to create either:

1) Create 2 "logical" demux devices with each one having a dedicated stream
input.  All PID filters associated with this logical demux device (shared
PID filters between devices) would share the same input.  However, you
would have to specify an output channel somehow when setting up a PID
filter.  This would have to be an additional parameter to pass in the pid
filter structure. Not nice and only suits specific h/w.

2) Create 4 "logical" demux devices with 2 pairs sharing the same input
stream.  In this case, you would have "logical" demux devices #0 and #1
sharing stream #1 input and "logical" demux devices #2 and #3 sharing
stream input #2.  In this case, you cannot issue a DVB_DMX_SET_SOURCE ioctl
on the one device of the pair without affecting the other. You cannot issue
DVB_DMX_SET_SOURCE on "logical" demux device #1 without affecting the
source routing of "logical" demux device #0.

Do you prevent one "logical" device from allowing this ioctl to proceed?
Do you see, its gets complicated.  The output of each "logical" demux
device would be a dedicated channel from #1 to #4, hence the need to have 4
"logical" demux devices all sharing the same PID filters.

With the new V4 proposal:

Create 2 "logical" demux devices (router/ input selectors) with each one
having a dedicated stream input (like in case 1 above).  Create "output"
filter devices #1 and #2 for the 2 possible output channels associate with
this device.  The user application can open up the desired number of PID
filters for the required output channels (#1 through to #4 quite easily).

e.g. /dev/dvb/adapter0/demux0/pidfilter0   -> source stream #1, output
channel #1.
     /dev/dvb/adapter0/demux0/pidfilter1   -> source stream #1, output
channel #2.

     /dev/dvb/adapter0/demux1/pidfilter0   -> source stream #2, output
channel #3.
     /dev/dvb/adapter0/demux1/pidfilter1   -> source stream #2, output
channel #4.



I have also run this over other h/w that I know and it seems to fit the
bill.  Please make any constructive comments...

Good work Guys!

Rob : )






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