RE: Still about "id" format

If a content provider has content with >1 track of the same type where these cannot be distinguished by standard per-track metadata then having an id that survives passage through the distribution system has value. In DVB markets, PIDs do not have this property. Indeed the same elementary stream may have different PIDs in different geographical areas and when received by different distribution channels (cable / satellite / terrestrial / multicast IP).

Jon
________________________________
From: Brendan Long [B.Long@cablelabs.com]
Sent: 13 November 2013 17:15
To: Giuseppe Pascale; Jon Piesing
Cc: public-inbandtracks@w3.org
Subject: RE: Still about "id" format


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

One case is the media fragments, where it would probably be useful if the ids were controllable (like Matroska TrackUIDs and Ogg Skeleton Names are), or at least stay the same after transcoding. I assume that would make authoring easier.

The other is finding metadata, where it probably doesn't matter if the ids change, just that they are consistent within a single file.