[linux-dvb] Re: Alternative v4 demux API

[Johannes Stezenbach <js@convergence.de>]

Rob.McConnell@Zarlink.Com wrote:
> 
> 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.... : )

Why would this be useful? I think the board designer decides if he wants
to use serial or parallel FE output and would not connect both?

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

Ralph mentioned this in a previous mail. A separate "playback" device
would allow the same playback stream to be connected to two logical
demux channels at the same time. Some hardware supports this, but I
don't see a practical use for it. Anyway, I'm not opposed to having
playback and other input devices besides frontends.

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

Agreed.

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

I still fail to see the real advantage over having just a single "demux"
device per input channel. For a human who looks at the /dev/dvb tree
it might look nicer, but in software it doesn't matter, IMHO.

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

Minor number encoding will get more difficult because there are other
types of DVB devices besides demux stuff, just look at dvbdev.c.
An easy way out would be a second major number, but we should avoid
this if we can.


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

It will always be possible to add DVB_DMX_SET_FOOBAR_FILTER. It will
be even easier to do if you don not have to add a new device.


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

No way. If you have 32 shared filters and you use them all on the first
logical demux, there will be none left for the second. Because that's
what the user wants. If you reserve filters you actually take away
capabilities that a user might need.


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

No, bad!

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

I never felt the need to do that. E.g. if you want SDTs for some
services you don't care that all those filters are on the same PID,
and you don't want to manage the shared PID filter in your application.
Let the driver do this!


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

That's how I intended it. Output "channels" are managed by connecting
devices to the demux/filter fd, or (in case of recording) by opening
a second fd for the second recodring channel.


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

I hope I did. Even if I just teared Your and Michaels proposals to
shreds ;-}


Regards,
Johannes


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