Re: Proposal for initial CG focus

Bob and Cyril,

See inline

On 11/8/13 10:41 AM, "Bob Lund" <B.Lund@CableLabs.com> wrote:

>
>
>On 11/7/13 10:11 AM, "Cyril Concolato"
><cyril.concolato@telecom-paristech.fr> wrote:
>
>>
>>>
>>> For more deterministic handling of inband tracks, the UA could be
>>>required
>>> to:
>>>
>>> * Expose all in-band tracks, in some form.
>>Yes
>>> * Make media resource metadata  associated with the inband tracks
>>> available to Web applications. [1] does this through a TextTrack.
>>> * Provide data so that the Web application can correlate the metadata
>>>data
>>> with the appropriate Track object.
>>I'm not sure I follow you here. I guess this has to do with the notion
>>of "Track Description TextTrack" in [2].
>>
>>This idea is interesting and I see where it comes from. An MPEG-2 TS
>>program can have a time-varying number of streams in a program and
>>stream changes are signaled with a PMT. So indeed, you could consider a
>>PMTTextTrack to signal those changes. If understand correctly, the
>>"Track Description TextTrack" is a generalization of that PMTTextTrack.
>>For MP4, this would correspond to a 'moov'-TextTrack, but in MP4 the
>>moov is static for the whole duration of the file and the number of
>>tracks does not change. I can't think at the moment of file-wide
>>time-varying metadata information that is not represented in the MP4
>>file format as a track. So that "Track Description TextTrack" would have
>>only 1 cue.
>>
>>My initial idea (not sure it covers every case in MPEG-2) was rather to
>>expose the time-varying information related to a track in the track
>>itself. For instance, for MPEG-2 TS, if a PMT updates the descriptor
>>associated to an elementary stream, for which there is already a created
>>TextTrack, I would create a new cue for that new information. So the cue
>>data for every stream would carry two types of information: signaling
>>and/or real data.
>
>I agree your proposal would work and it could even be applied to the
>MPEG-2 TS case. But, there was no texttrack attribute to hold that track's
>metadata. That is the reason I proposed exposing the PMT as a texttrack.
>
>I like your approach because it seems simpler. Also, the addition of the
>metadataTrackDispatchType to HTML5 essentially is the attribute containing
>the track metadata, at least for text tracks of @kind == metatdata. Maybe
>something similar should exist for other types of text tracks, and video
>and audio tracks, and be renamed as trackMetadata.

This approach has a problem when you seek to a new location in the A/V
stream, as you would need to scan through the track's cues looking for
these signaling cues. If there are a lot of data cues to look through,
this could be a performance issue.

I think there are some related track maintenance issues as well, as we
need to ensure we always have a set of signaling cues covering the
seekable range. If signaling cues are mixed in with the data cues, we
would need to selectively remove the data cues while leaving the required
signaling cues in place.

Eric

Received on Friday, 8 November 2013 18:11:08 UTC