[linux-dvb] Re: Alternative v4 demux API

[Andreas Oberritter <andreas@oberritter.de>]

On Thu, 2003-10-09 at 21:11, Michael Hunold wrote:
>                +----------------+
>                | 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). 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.

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

What about teletext PIDs? Some demultiplexers have a dedicated teletext
queue.

> - SET_APID_VPID_PCR: set all PIDs at once

What about selection of different audio tracks? (multi language, ac3..)

> The idea behind this approach is to separate all the different stuff 
> away from the demux device, which does not belong there.

why?

> 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

that's because PIDs may vary.

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

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

Regards,
Andreas



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