Re: Still about "id" format

that's DVB I believe. Probably not applicable to your typical setup?


On Thu, Nov 14, 2013 at 12:49 AM, Bob Lund <B.Lund@cablelabs.com> wrote:

>
>
>   From: Giuseppe Pascale <giuseppep@opera.com>
> Date: Wednesday, November 13, 2013 9:30 AM
> To: Bob Lund <b.lund@cablelabs.com>
> Cc: Jon Piesing <Jon.Piesing@tpvision.com>, Brendan Long <
> B.Long@cablelabs.com>, "team-liaisons@w3.org" <team-liaisons@w3.org>, "
> public-inbandtracks@w3.org" <public-inbandtracks@w3.org>, "
> liaisons@oipf.tv" <liaisons@oipf.tv>
> Subject: Re: Still about "id" format
>
>   On Wed, Nov 13, 2013 at 10:13 PM, Bob Lund <B.Lund@cablelabs.com> wrote:
>
>>
>>    <Bob> If we expose media resource track metadata via a dedicated text
>> track, as is done in the CableLabs' current spec, then there needs to be a
>> way to associate that track metadata with the actual video, audio and text
>> track objects. Assigning the media resource stream id to the track object
>> id attribute seems like a good choice.
>>
>>  If, however, we store the metadata in an attribute of the track object,
>> perhaps by using a generalization of inbandMetadatTrackDispatchType (this
>> has to be the longest attribute name in the HTML5 spec), then I can't think
>> why the Web application would ever need to know the media resource stream
>> id.
>>
>>  It still seems reasonable to set the track.id to the stream id. </Bob>
>>
>>
>  I think we agree we need to set it to the stream ID, the question seems
> to be, which one is best as "stream ID": the PID or the "component_tag
>  field in the stream_identifier_descriptor in PMT" (not sure if the second
> is applicable to north america market though)
>
>
>  I cannot find "component_tag" in T-REC-H1 222 0-200605-I. Can someone
> provide a reference?
>
>
>
>