Re: Resolving TextTrackCue issues

On Sep 3, 2013, at 5:16 PM, Silvia Pfeiffer <> wrote:

> On Wed, Sep 4, 2013 at 9:19 AM, Eric Carlson <> wrote:
>>> Do you expose the existance of these in-band captions somehow to JS?
>>> I'm concerned that if the browser renders captions automatically on
>>> top of video without the JS developer being able to find out about it,
>>> how would the JS developer know that there are captions and to avoid
>>> rendering another lot themselves - or rendering something else in the
>>> space of the captions?
>>  On versions of the OS where it is possible for WebKit to "take over"
>> rendering of in-band captions from the media engine, they behave just like
>> out-of-band tracks: in-band tracks are part of the video.textTracks and the
>> cues are part of track.cues/activeCues (when appropriate).
> So for the JS dev they are exposed as instances of the old
> TextTrackCue interface?


> The VTTCue interface sufficiently satisfies this use case then? 

  True, but the in-bad cues may or may not be WebVTT originally. Is there an advantage to using VTTCue instead of the old TextTrackCue interface?

> What is the content in .text ?
  The cue text.

>>  On versions of the OS where the system frameworks do not have the
>> necessary API to override cue rendering, in-band tracks are part of
>> video.tracks so they can be enabled/disabled by script but cues are rendered
>> by the media engine.
> In this case, I assume only the existence of the track, but not of the
> cues is exposed to JS? I.e. track.cues/activeCues is empty? Or are you
> listing fully-abstract TextTrackCue instances here to at least provide
> starttime/endtime to the JS devs?
  Correct, the cues are not available to WebKit at all in this case.

> And an orthogonal question: you've probably seen the Cablelabs spec
> for exposing MPEG-2 in-band text tracks of different types to HTML[1].
> Seeing as both Cablelabs and the HTML spec are trying to accommodate
> using in-band text tracks in HTML/JS, what do you suggest is the best
> way forward to specify this?
> * Program Map Table: would you suggest to use VTTCue with
> @kind=metadata, GenericCue, or a new PMTCue interface?
  It seems to me that text track content that a UA does not render itself is, by definition, metadata. Again, it is not WebVTT data so is there an advantage to VTTCue versus old TextTrackCue interface?

> * CEA708 track: assuming we don't want to introduce CEA708Cue, how
> would that best be supported?
  Are any browsers planning to support 708 captions natively? 


Received on Wednesday, 4 September 2013 04:15:31 UTC