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

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

--- Comment #6 from Bob Lund <b.lund@cablelabs.com> ---
(In reply to Silvia Pfeiffer from comment #5)
> (In reply to Bob Lund from comment #4)
> > (In reply to Silvia Pfeiffer from comment #3)
> > >
> > > > > 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
> > 
> > These streams are not PSI actually but the principle you outline is
> > correct, and what I tried to convey. So, startTime = '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.
> > 
> > The endTime then wouldn't be known until the next private section arrives.
> > This raises the question of what the endTime should be set to in the
> > intervening time and requires the UA to update the endTime of the prior cue.
> >
> > A preferred alternative would be to set endTime to startTime.
> 
> That would create a cue of duration 0, which would never end up in the list
> of "current cues", but always only in the list of "missed cues" (see the
> "time marches on" algorithm).
> 
> In any case, do you still want a sentence on how to create cues from PSI
> information in MPEG-2 in the spec?

Yes. What about endTime = startTime + 250msec? It really doesn't matter what
the endTime is. The application only needs to know the startTime.

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

Received on Monday, 24 March 2014 16:39:10 UTC