Re: Track "id" format?

On Wed, Nov 13, 2013 at 10:03 AM, Cyril Concolato
<cyril.concolato@telecom-paristech.fr> wrote:
> Hi Brendan,
>
> Le 12/11/2013 16:41, Brendan Long a écrit :
>
>>> Regarding clashes, does the Track.id attribute have to be unique in the
>>> page? or in the list of Tracks to which the Track belongs (AudioTracks,
>>> VideoTracks or TextTracks)? It doesn't make much sense to have a
>>> page-wide id, does it?
>>
>> Interestingly, the spec currently doesn't require the track "id" to be
>> unique:
>>
>>> 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.
>>
>> http://www.w3.org/TR/html5/embedded-content-0.html#dom-audiotrack-id
>>
>>> Anyway, I had thought for the 'id' value to use a fragment identifier
>>> like 'file.mp4#track_id=1' or 'file.ts#pid=120'. That would avoid
>>> clashes.
>>
>> I think right now the format is just "file.mp4#track=1" or
>> "file.ts#track=120":
>>
>> http://www.w3.org/TR/2011/CR-media-frags-20111201/#naming-track
>
> Thanks for digging that information. I agree with the small caveat that
> using a fragment identifier as defined by the Media Fragment Identifier
> spec, only applies if the MIME type supports that. In particular, I need to
> check for MP4 and MPEG-2 TS.

Even if MPEG hasn't defined the support for media fragments, I
strongly suggest to make this work for MPEG, too, just to allow Web
app developers a uniform means of dealing with this situation.

Cheers,
Silvia.

Received on Wednesday, 13 November 2013 02:29:31 UTC