Re: Still about "id" format

From: Giuseppe Pascale <giuseppep@opera.com<mailto:giuseppep@opera.com>>
Date: Wednesday, November 13, 2013 9:30 AM
To: Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>
Cc: Jon Piesing <Jon.Piesing@tpvision.com<mailto:Jon.Piesing@tpvision.com>>, Brendan Long <B.Long@cablelabs.com<mailto:B.Long@cablelabs.com>>, "team-liaisons@w3.org<mailto:team-liaisons@w3.org>" <team-liaisons@w3.org<mailto:team-liaisons@w3.org>>, "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>, "liaisons@oipf.tv<mailto:liaisons@oipf.tv>" <liaisons@oipf.tv<mailto:liaisons@oipf.tv>>
Subject: Re: Still about "id" format

On Wed, Nov 13, 2013 at 10:13 PM, Bob Lund <B.Lund@cablelabs.com<mailto: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<http://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?

Received on Wednesday, 13 November 2013 16:50:43 UTC