[Bug 24416] Ambiguous support for native in-band captioning.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24416

--- Comment #5 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
(In reply to Graham from comment #2)
> (In reply to Silvia Pfeiffer from comment #1)
> 
> > 
> > What is "optimized native captioning"?
> > 
> 
> As described in the first paragraph, optimized native captions relieves the
> application from having to handle the captions or the user agent from having
> to convert them, both of which can suffer from performance loss and
> captioner's intent.


I don't know of any user agent that converts a caption format. Also, I am not
aware of any user agents that make use of native caption rendering. Can you
give me some concrete examples?


> > If none of the browser-provided captioning functionality works for you
> > (WebVTT, the <track> element, TextTracks, inband tracks, etc) you are always
> > free to run your own captioning feature fully through JavaScript.
> >
> 
> Are you suggesting to run a captioning feature fully through JavaScript
> without creating an API to control or test this feature?

Yes. Many existing video players on the Web provide this, e.g. JWPlayer
(http://www.longtailvideo.com/support/jw-player/28845/adding-video-captions/)
or Sublime (http://docs.sublimevideo.net/subtitles) or video.js
(http://blog.videojs.com/post/35883671470/version-3-2-update) and many
proprietary video players.


> How would an
> application know that a user agent can support closed captions in this
> native fashion without this?

What "application" are we talking about? The Web page is the application and
thus knows what it is using and displaying and makes use of the JS
functionality. Also, this is not "native", but JS provided.


> This is being raised from a browser implementer, TV manufacturer and TV
> standards perspective as opposed to an web application developer
> perspective. We need a standard way of allowing in-band captions to be
> handled natively that doesn't conflict with the existing specification and
> allows the application to assess that these captions are being handled even
> though they are not cued.

Right. The spec is written in such a way that in-band captions are handled
exactly the same way as captions provided through the <track> element. There is
no conflict. These captions are cued the same way as captions coming through
the <track> element.

The browser will parse the media file, extract the captions with their start
and end time, add them to a TextTrack object and - if the track is activated by
the user - display them.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Sunday, 16 February 2014 01:22:44 UTC