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

In EBU-TT the proposal for live is to use a single document per subtitle and avoid dependencies on Id values... Only one document is allowed to be valid in the decoder at any one time so the new document automatically replaces the old one.

Wrt to end time it might be better to set an end time some reasonable point in the future (e.g. 10 or 20 seconds) to avoid the problem of a hanging subtitle if the revised cue never gets sent (e.g. Service switch)

Best regards,
John


From: Brendan Long [mailto:self@brendanlong.com]
Sent: Tuesday, January 14, 2014 09:46 PM
To: Timed Text Working Group <public-tt@w3.org>
Subject: WebVTT endTime = infinity and ability to rewrite cue times

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?
John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 270 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems


Visit us at
BVE, Excel London, 25-27 February 2014, Stand M15

P Before printing, think about the environment


This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ