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

On Tue, 2014-01-14 at 21:37 +0000, John Birch wrote:

> 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.

I guess we could completely replace the WebVTT document for every cue,
but it seems like it would be less efficient and harder to implement. It
would be really nice if we could download one file and parse it as we
receive it, with no need to do polling or restarting the parser. Having
everything in one document is also convenient for implementations using
GStreamer, but I'm not sure if that would apply to other media
frameworks.


> 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)

That's a good point. Maybe infinity isn't what we want anyway. I'll
bring this up with my coworkers.

--=-zUdGZMJ/Yz0sAKT+RsfB
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/4.6.6">
</HEAD>
<BODY>
On Tue, 2014-01-14 at 21:37 +0000, John Birch wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
    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.<BR>
</BLOCKQUOTE>
I guess we could completely replace the WebVTT document for every cue, but it seems like it would be less efficient and harder to implement. It would be really nice if we could download one file and parse it as we receive it, with no need to do polling or restarting the parser. Having everything in one document is also convenient for implementations using GStreamer, but I'm not sure if that would apply to other media frameworks.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
    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)<BR>
</BLOCKQUOTE>
That's a good point. Maybe infinity isn't what we want anyway. I'll bring this up with my coworkers.
</BODY>
</HTML>

--=-zUdGZMJ/Yz0sAKT+RsfB--

Received on Tuesday, 14 January 2014 21:50:20 UTC