- From: Eric Carlson <eric.carlson@apple.com>
- Date: Tue, 03 Sep 2013 21:14:58 -0700
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Jer Noble <jer.noble@apple.com>, Glenn Adams <glenn@skynav.com>, Philip Jägenstedt <philipj@opera.com>, public-html <public-html@w3.org>, Ian Hickson <ian@hixie.ch>, Bob Lund <B.Lund@cablelabs.com>
On Sep 3, 2013, at 5:16 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > On Wed, Sep 4, 2013 at 9:19 AM, Eric Carlson <eric.carlson@apple.com> 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? Yes. > 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? eric
Received on Wednesday, 4 September 2013 04:15:31 UTC