On Friday 17 June 2005 10:04, Johannes Stezenbach wrote:
> Andreas Oberritter wrote:
> > On Fri, 2005-06-17 at 00:10 +0100, Andrew de Quincey wrote:
> > > The first thing that springs to my mind is something like the
> > > following:
> > >
> > > DVBS: ((frequency / (symbolrate/1000)) << 1) | polarisation
> > > DVBT: (frequency / bandwidth)
> > > DVBC: (frequency / symbolrate)
> >
> > AFAIK there can not be more than one multiplex one frequency except if
> > the polarization differs.
>> Not true for Japan / ARIB. They do funky stuff, below is a quote
>> from a private mail where someone explained this to me a while ago:
> | In the ARIB-T, there is just one transport stream per frequency, so, as
> | you said, transport_stream_id parameter is not needed for tuning
> | purpose.
> |
> | In the ARIB-S and ARIB-C, there are multiple transport streams mux-ed in
> | a frequency. Bandwidth of a frequency is divided into 48 slots, each
> | assigned to any of the transport streams. TMCC describes, for each slot,
> | a transport_stream_id to which a slot belongs. This is explained in ARIB
> | STD-B20. Regretably, there isn't english version.
>> Which means that *the frontend* needs to know the transport_stream_id
> for tuning...
>> (I'm not implying that we should support this.)
eeagh! I reckon support that in a later version if necessary.
Multiplexing multiplexes seems sort of mad though :)