Re: Cues with 'start time' >= 'end time'

On Thu, Apr 26, 2012 at 4:05 PM, Ian Hickson <ian@hixie.ch> wrote:

> That's what implementing a spec is about. Finding way to efficiently
> implement the algorithms written in the spec in a way that results in the
> same output as the spec.
>

It's not an issue of efficiency, it's about testing requirements.


>  Pause-on-exit cues don't exist without the API.
>

If it's purely an API feature, then I'm not sure why it's mentioned in the
WebVTT spec at all.


 On Fri, Apr 27, 2012 at 4:38 AM, Victor Carbune
<victor.carbune@gmail.com>wrote:

> Case 1: missed cue with proper timing (startTime < endTime)
> Step 9 prepares the event ('enter', endTime) (...*later* of the start,
> end time...)
> Step 10 prepares the event ('exit', endTime)
>
> We should keep events properly associated with timings if it is
> nothing wrong with the cue.
>

To give a concrete example:

00:00.002 --> 00:00.010
Cue 1

00:00.005 --> 00:00.008
Cue 2

If the playback time is 0.016 (one frame in), and the previous time is
0.000 (the start), both are missed cues.  This appears to send cue 2's
enter event before cue 2's enter event, unlike the regular (not missed
cues) path.

Depending on the granularity of the playback mechanism a cue might be
> treated once as missed cue and have events dispatched and other time
> be skipped (because the mechanism steps within the cue timing). Making
> it a zero-length cue makes sure it's always a missed cue.
>

What case do you see where cues might be skipped entirely?  Preventing that
is what "missed cues" is for.  Note that reversed cues (where start > end)
are always missed cues, because they can never pass the condition in step 1
(start >= now && now <= end).

-- 
Glenn Maynard