[linux-dvb] Re: Alternative v4 demux API

[Michael Hunold <hunold@convergence.de>]

Hello Andreas,

> >               +----------------+
> >               | MPEG Decoder 0 |
> > to demux  <-- +----------------+
> >               | APID|VPID|PCR  |
> >               +-----------------
>
> Mpeg decoders usually don't parse Transport Streams (I only know one old
> chipset which has some kind of simple demultiplexer built in for single
> program TS). 
Ok, I agree. But that's only a naming game. Because of the fact that the 
 adapter0/video0 and adapter0/audio0 devices are still there, this 
should perhaps called "MPEG demux 0". I'll add a new ascii art below.

FYI: I'll ask some rhetorical question later on, please don't take them 
personally or feel offended.

> Therefore they don't know what a PID is. So why should the
> A/V PIDs be given to the mpeg decoder device? The Transport Demux has to
> know them, so it can deliver the demultiplexed data to the decoder.
The more advanced hardware I know has a design like this:
- multiple "demux" to select from the input sources (so there are more 
like "input selectors" than demuxes)
- general purpose PID filters shared between all demux/input selectors
- general purpose section filters sharded between all demux/input selectors
- specialized APID/VPID/PCR filters for each mpeg decoder (so they 
technically belong to the mpeg demux/decoder, not to the other demux 
devices)

So let's assume you have 3 input selectors/demux, but only 1 mpeg 
decoder. With the old design, you could open all three demuxes and (in 
theory) set VPID/APID/PCR on all three.

Does this make sense?

In practise, only the first call would succeed (and this demux would 
have been connected to the mpeg decoder), and the other calls would have 
been refused.

This is implicit behaviour and therefore bad design. There is only one 
mpeg decoder, so there is only one set of PIDs that can be set. Because 
of this, there should be one specialized "mpeg demux".

> PCR stuff is also up to the demux IMHO. It's at TS level (->demux) what
> PTS is at PES level (->decoder).
Yes.

> What about teletext PIDs? Some demultiplexers have a dedicated teletext
> queue.
               +----------------+
               |   Teletext 0   |
 to demux  <-- +----------------+ <- read()
               |      PID       |
               +-----------------

If it's a specialized teletext decoder, you'll have a dedicated device 
for this. It basically works as the general purpose PID filter, but you 
can only set one PID.
There should be IOCTLs like this available:
- SET_VBI_REINSERTION: automatically re-insert the teletext data to 
video output x

> > - SET_APID_VPID_PCR: set all PIDs at once
> What about selection of different audio tracks? (multi language, ac3..)
The audio decoder can handle only one APID at a time, right? So if you 
want to switch the language or the mode, you simply change the APID.
I don't care if the PIDs can be selcted individually or if we use a 
bitmask on what PIDs to actually set.

> > The idea behind this approach is to separate all the different stuff 
> > away from the demux device, which does not belong there.
> why?
Please refer to my explanation about advanced hardware. General purpose 
PID filters are general purpose, while the MPEG demux/decoder is 
specialized. If you have recording units, they are specialized, too. All 
these should not be available through one common device IMHO, that's bad 
design.

> > Currently, you have the mpeg decoders, PID and section filters in one 
> > big chunk.
> ?
You can open the demux device and control the mpeg decoder(s), PID and 
section filters all at once, although they are independent from an 
outside view.

Take PID filters with the new proposed API for example:
You can specify filters that simply don't make sense. You can set the 
filter type to DVB_DMX_FILTER_TYPE_VIDEO (mpeg decoder stuff), but 
specify DVB_DMX_FULL_TS (general purpose PID filter stuff).

Please explain, why it makes sense to put this into one structure 
instead of clearly separating this?

> > If you set a new section filter, you always specify the PID 
> > again
> that's because PIDs may vary.
Yes, but section filtering is bound to PIDs. So if you want to have 
section filters on different PIDs, you need to have different logical 
instances of a "section filter", right?

The user is aware of this, so there is no need to hide this from him. If 
he wants section filtering on another PID, he needs to open the device 
again.

> > 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?
> video, audio and pcr _do_ have something to do with demuxing, see above.
Agreed, but with the mpeg demux/PID filter, not with the other stuff.

> > With my design, all things are separated to where they belong:
> > video/audio/pcr filters to the decoder
>
> The decoder has nothing to do with filtering but instead is getting the
> filtered data from the demux hardware.
Ok, here comes an updated approach with ascii art:

               +------------------+
to input <---- | Input selector 0 |
               +------------------+
                   ...
               +------------------+
to input <---- | Input selector n |
               +------------------+

(formerly know as demux)

                +----------------+
                | MPEG demux x |
to selector <-- +----------------+
                | APID|VPID|PCR  |
                +-----------------

(formerly known as decoder)

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

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

                 +----------------------+
                 |   Teletext demux x   |
to selector  <-- +----------------------+ <- read()
                 |          PID         |
                 +-----------------------
> Regards,
> Andreas
CU
Michael.



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