Re: WebVTT endTime = infinity and ability to rewrite cue times

Hi Brendan,

For now, the text tracks community group is a more appropriate list for
WebVTT: http://www.w3.org/community/texttracks/

Best Regards,
Silvia.
On 15 Jan 2014 07:47, "Brendan Long" <self@brendanlong.com> wrote:

>  I hope this is the right mailing list now. My company (CableLabs) wants
> the ability to do live conversion of CEA-708. The biggest problem we have
> right now is that CEA-708 cues don't come with an end time (at a high
> level, cues end when something else is displayed in front of them, or the
> screen is cleared). That's not a problem if we're transcoding a static
> file, but it doesn't work if we're transcoding a live stream. As far as we
> can tell that only requires two changes. I previously emailed about the
> need for an "until the next cue" time, but this solves the problem more
> cleanly.
>
> The way we'd like to handle it is basically like this:
>
>    - When we first see a CEA-708 cue, we create a new cue with an endTime
>    set to a really large number.
>    - When we figure out when the cue ends, we change the endTime to the
>    correct value.
>
> Technically, we can do the first now by setting endTime = maximum double
> value (or maximum WebVTT time value, whichever is smaller), but it would be
> cleaner if we could just set it to infinity. To do this, we'd like to
> change TextTrackCue.endTime to an unrestricted double, and add an
> "infinity" end time value to WebVTT.
>
> The second piece we need is the ability to require a cue's end time. It
> doesn't particularly matter how it works, but the best idea I've had is to
> add a rule that if two cues have the same "id", the later one completely
> overrides the first one:
>
> 1
> 00:00:00 --> 00:00:05
> This text will be displayed until the parse the next cue. If we parse the
> entire file at once, this cue will be completely ignored.
>
> 1
> 00:00:00 --> 00:00:05
> This text will be displayed instead.
>
> Combining the two, we can handle live CEA-708 cues like this:
>
> 1
> 00:00:00 --> infinity
> Example text.
>
> 1
> 00:00:00 --> 00:00:05
> Example text.
>
> The upside is that this would handle any use-case where we want to change
> a cue in any way. Another example would be fixing typos:
>
> 1
> 00:00:00 --> 00:00:05
> Example txet
>
> 1
> 00:00:00 --> 00:00:05
> Example text
>
> I saw other proposals for rewriting just cue text, but I'm not aware of
> any that would let us rewrite the times too. We'd be fine with any change
> that allowed us to change the time in a previous cue.
>
> What do you think?
>