Re: Track "id" format?

I'm concerned about having id clashes. If the page contains a out-of-band track that has an id that matches the one we generate we could have problems. Both the in-band and out-of-band text tracks would have the same id.

From: Brendan Long <b.long@cablelabs.com<mailto:b.long@cablelabs.com>>
Date: Monday, November 11, 2013 2:31 PM
To: Eric Winkelman <e.winkelman@cablelabs.com<mailto:e.winkelman@cablelabs.com>>, Bob Lund <B.Lund@CableLabs.com<mailto:B.Lund@CableLabs.com>>, "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Subject: RE: Track "id" format?

> I agree on using a string, and personally lean toward using a hex representation.

I think it would be best if the translation between binary-in-the-file to track id was format-specific, so we can use the most appropriate representation for each format. For example, it seems reasonable to represent Matroska TrackUID's as decimal numbers, but for Ogg Skeleton files it could be the name<https://wiki.xiph.org/SkeletonHeaders#Name> (which can be anything, as long as it's per-file unique).

Or maybe it would be useful if the ID was always a number? For Ogg we can use the stream serial number if we wanted to, but the current HTML spec says we should use the name header. The stream serial number has the advantage of always existing.