Marcel Wiesweg wrote:
>>>Actually, the component descriptor from EIT and the stream identifier
>>>descriptor from PMT are associated via the component_tag.
>>>
>>>Is there a reason this is not used, or did it just slip attention?
>>>(It definitely slipped my attention when I skimmed the mail at that time)
>>>
>>>Anyway, the current solution is working pretty well, so this is low
>>>priority, but at least, if some stations are reversing the order but
>>>provide the required descriptors, we should not blame them.
>>>
>>>Marcel
>>
>>So far VDR doesn't use the StreamIdentifierDescriptor.
>>Can you suggest where this would fit into VDR/pat.c?
>>
>
>
> The descriptor is contained in the descriptor loop of the PMT::Stream object,
> so it needs to be read inside the loop pat.c, 335
> for (SI::Loop::Iterator it; pmt.streamLoop.getNext(stream, it); ) {
> just like the other descriptors in the loops
> for (SI::Loop::Iterator it; (d = stream.streamDescriptors.getNext(it)); ) {
> int pat.c, 346 and 380.
>
> case SI::ComponentDescriptorTag: {
> SI::ComponentDescriptor *cd = (SI::ComponentDescriptor *)d;
> Channel->DoSomethingWithComponentTag(stream.getPid(),
> cd->getComponentTag());
> }
>
> Then, extend tComponent and the relevant methods of cComponent(s) with an
> uchar componentTag.
>
> I would have written some code to integrate this, but I do not know how you
> want to store the component tag value.
> For core VDR, it will at the moment only be used to associate with the
> component descriptor of audio streams.
> On the one hand the component tag is used in some other descriptors to
> identify streams (Announcement support descriptor, data broadcast descriptor,
> multilingual component descriptor), where it is be used by plugins, though
> probably not only for the audio and video streams. On the other hand, plugins
> can easily retrieve the PAT and PMT themselves.
> One possibility is to add a component_tag <-> pid list to each channel object.
> I don't think this needs to be stored in a config file because the PMT of the
> current channel is fast and always received, unless you need the association
> for other channels than the current.
>
> Marcel
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?
Klaus
