RE: Still about "id" format

________________________________
From: Giuseppe Pascale [giuseppep@opera.com]
Sent: Tuesday, November 12, 2013 8:57 PM
To: Jon Piesing
Cc: Brendan Long; team-liaisons@w3.org; public-inbandtracks@w3.org; liaisons@oipf.tv
Subject: Still about "id" format

On Wed, Nov 13, 2013 at 6:03 AM, Jon Piesing <Jon.Piesing@tpvision.com<mailto:Jon.Piesing@tpvision.com>> wrote:
Brendan,

> MPEG-2 TS
> readonly attribute DOMString id;
> The contents of the component_tag  field in the stream_identifier_descriptor in PMT.
> This seems like an odd choice. Why not the PID?

In DVB networks, my (limited) understanding is that PIDs are changed as a TS passes through the distribution network but component tags remain unchanged. Certainly if you look in the DVB-SI specification, references from descriptors to elementary streams normally use a component tag and not a PID.


I think this discussion raises two questions:

- what is the use case we are trying to address by exposing these info via the track ID attribute? Is the only think we care is to have something that unique locally to the application (in that case it may not matter much if the PID changes along the broadcast value chain as far as each track as a unique PID at the end) or are we trying to convey some other type of information?

- depending on the answer above, do we also need to consider regional variations of the standards?

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

/g