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