> > Maybe it would be enough to simply sort the components and the PIDs by > > their > > respective tags, so that the sequence is guaranteed to be the same. That > > would save us from having to store these otherwise unnecessary tags. > > > > But I guess I won't change that before version 1.4, unless there actually > > is a station that broadcasts these out of sync. But then again, why > > would they > > do that? Ok, according to the standard they could, but what would be the > > benefit > > of that? There is certainly no explicit benefit, but someday someone might decide to write software which produces the descriptors in random order, without too much thinking about that. > > > > Klaus > > One more thing: apparently there are stations that set the tags to the same > value for all components. In the following examples, the first column is > the number of the component, the second and third column are stream content > and component type, and the fourth one is the component tag: > > 1 02 03 255 'ita' '' > 2 01 03 255 '???' '' > 1 01 01 0 'pol' '' > 2 02 01 0 'pol' '' > > So an Italian station sets them all to 255, while a Polish station sets > them all to 0. I don't think this conforming to the spec, but it is not too bad. There is only one audio stream for either, and additionally, the two streams can be differentiated by the stream content. Channels which want to do great things like broadcasting multiple audio tracks or a DSMCC carousel should better send proper stream identifiers. Moreover, "The descriptor is mandatory only if the service contains more than one stream of the same type and there are component descriptors for that type of stream within the EIT." (Etsi TR 101 211, guidelines for SI). Still we cannot know that all channels will adher :-). Marcel > > Klaus
