Re: Question about component descriptor association

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux