Klaus Schmidinger wrote:
> 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
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.
Klaus
--
_______________________________________________________________
Klaus Schmidinger Phone: +49-8635-6989-10
CadSoft Computer GmbH Fax: +49-8635-6989-40
Hofmark 2 Email: kls@xxxxxxxxxx
D-84568 Pleiskirchen, Germany URL: www.cadsoft.de
_______________________________________________________________
