Re: TextTrack questions

On 01/16/2014 02:08 PM, Aaron Colwell wrote:
> The file offset of the cue information in the souce file could be used
> to create the unique ID. Just using the start time, end time, and text
> would not necessarily be unique if there are duplicate cues in the file.
Using the file offset would probably work. I don't think this is
possible in GStreamer though. If this is possible in other relevant
media frameworks (FFMPEG, AV Foundation, Media Foundation), then maybe
it's something we should add to GStreamer.

> Does WebVTT or CEA-708 have rules to prevent 2 cues from having the
> exact same timestamps and text? Obviously such duplicate cues would be
> rare, but I'm just trying to understand if they are possible and
> making it clear what the UA behavior should be if they are allowed in
> the underlying formats.
WebVTT seems to allow cues which are exact duplicates:
>
> The WebVTT cue timings part of a WebVTT cue
> <http://dev.w3.org/html5/webvtt/#dfn-webvtt-cue> consists of the
> following components, in the given order:
>
>  1. A WebVTT timestamp
>     <http://dev.w3.org/html5/webvtt/#dfn-webvtt-timestamp>
>     representing the start time offset of the cue. The time
>     represented by this WebVTT timestamp
>     <http://dev.w3.org/html5/webvtt/#dfn-webvtt-timestamp> must be
>     greater than*or equal to* the start time offsets of all previous
>     cues in the file.[emphasis added]
>


--------------030909030800020706010202
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">On 01/16/2014 02:08 PM, Aaron Colwell
      wrote:</div>
    <blockquote
cite="mid:CAA0c1bD+oPYC1f4J+T=8_DFc1R9C4OnN9y=vShrs=KHO29KR3Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">The file offset of the cue information
          in the souce file could be used to create the unique ID. Just
          using the start time, end time, and text would not necessarily
          be unique if there are duplicate cues in the file.</div>
      </div>
    </blockquote>
    Using the file offset would probably work. I don't think this is
    possible in GStreamer though. If this is possible in other relevant
    media frameworks (FFMPEG, AV Foundation, Media Foundation), then
    maybe it's something we should add to GStreamer.<br>
    <br>
    <blockquote
cite="mid:CAA0c1bD+oPYC1f4J+T=8_DFc1R9C4OnN9y=vShrs=KHO29KR3Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>Does WebVTT or CEA-708 have rules to prevent 2 cues
              from having the exact same timestamps and text? Obviously
              such duplicate cues would be rare, but I'm just trying to
              understand if they are possible and making it clear what
              the UA behavior should be if they are allowed in the
              underlying formats.</div>
          </div>
        </div>
      </div>
    </blockquote>
    WebVTT seems to allow cues which are exact duplicates:<br>
    <blockquote type="cite">
      <p>The <dfn id="dfn-webvtt-cue-timings">WebVTT cue timings</dfn>
        part of a <a
          href="http://dev.w3.org/html5/webvtt/#dfn-webvtt-cue"
          class="internalDFN">WebVTT cue</a> consists of the following
        components, in the given order:</p>
      <ol>
        <li>A <a
            href="http://dev.w3.org/html5/webvtt/#dfn-webvtt-timestamp"
            class="internalDFN">WebVTT timestamp</a> representing the
          start time offset of the cue. The time represented by this <a
            href="http://dev.w3.org/html5/webvtt/#dfn-webvtt-timestamp"
            class="internalDFN">WebVTT timestamp</a> must be greater
          than<b> or equal to</b> the start time offsets of all previous
          cues in the file.[emphasis added]<br>
        </li>
      </ol>
    </blockquote>
    <br>
  </body>
</html>

--------------030909030800020706010202--

Received on Thursday, 16 January 2014 21:58:20 UTC