[Bug 25005] Add MPEG-2 TS metadata text track cue generation guideline

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25005

--- Comment #3 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
(In reply to Bob Lund from comment #2)
> (In reply to Silvia Pfeiffer from comment #1)
> > Bob, I don't really understand what the table in [2] means.
> > 
> > I don't follow how a cue is created in DASH or MPEG-4.
> 
> I don't think there is a general rule - it's dependent on the MIME. For
> example, WebVTT (text/vtt) has a cue format, TTML (application/xml+ttml) has
> another cue format. Don't the specs for these formats define how a UA would
> create a cue?

Correct. So, nothing needs to be added to the HTML spec for these.


> > Even for MPEG-2 the statement is strange. What is the time that the cue is
> > created? Where can I find that in the file? Would it be better to say
> > something like "Every PSI section is encapsulated in a DataCue with the
> > cue's start time provided by the activation time of that PSI section and the
> > cue's end time by the deactivation time of that PSI or by a repeat PSI
> > packet."
> > 
> > Does that make sense?
> 
> There is no explicit presentation/activation and deactivation time - the cue
> should fire as soon as the UA can create it, which implies the UA has
> received all TS packets comprising the section data; hence,the proposed
> language. endTime is not defined so could be same as start, a really big
> number or an indication of infinity/no endTime.

Cue start and end time are not about where something happens to be encapsulated
in the media file, but have a semantic meaning. The cue start time means that
at that time the data in the cue becomes active and end time when it becomes
inactive. IIUC the PSI has an implied activation time at the time in the media
stream where it appears and its value is implied to be correct until another
PSI arrives. So, to represent it correctly in a cue, these would need to be
start and end times.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 18 March 2014 10:58:26 UTC