The current spec does not say how AudioTrack.id & VideoTrack.id are generated. This needs to be defined because the underlying track IDs in the presentation are not necessarily constant (see section 2.4 bullet 2).
My suggestion is for the UA to generate unique ID strings for each track that stay constant throughout the presentation. I think allowing them to change during playback would be very confusing to the web application.
The HTML5 spec says: "The AudioTrack.id and VideoTrack.id attributes must return the identifier of the track, if it has one, or the empty string otherwise. If the media resource is in a format that supports the Media Fragments URI fragment identifier syntax, the identifier returned for a particular track must be the same identifier that would enable the track if used as the name of a track in the track dimension of such a fragment identifier. [MEDIAFRAG]"
Could we say that is a buffer is initialized with a single video/single audio track segment then the initial ID is maintained even if subsequent buffers have a different ID? Then for multi-track segments, the IDs must match. This makes the IDs predictable if the format includes an ID.
Is there a situation where we might need IDs distinct from HTML5, which allows an empty string if an ID is not available?
Based on the discussion at TPAC (http://www.w3.org/2012/11/01-html-wg-minutes.html) I believe the consensus was that the UA should generate unique IDs for the AudioTrack.id & VideoTrack.id properties. These IDs don't change during playback even if the underlying track IDs in the bytestream change.
It was suggested that a containerid property could be added to the AudioTrack & VideoTrack objects to provide a way to expose the track IDs in the bytestream. These are allowed to change during playback based on what track ID in the bytestream currently maps to the specific track object.
Based on the discussion on the media call today (http://www.w3.org/2012/12/04-html-media-minutes.html#item06), I'm planning on adding text to the spec about generating unique ID's for the tracks. We agreed to defer adding the containerid property until we are sure that we actually need it.