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

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

--- Comment #5 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
(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?

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

Received on Monday, 24 March 2014 04:09:59 UTC