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

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

--- Comment #3 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.

So you're just passing the captions through to the browser as parts of the
video pixels? That means: the browser doesn't know you have captions and
doesn't expose them to JavaScript either.


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

sure.

> without creating an API to control or test this feature?

You would do everything in JavaScript, i.e. you also control your test suite.

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

The User Agent (i.e. the browser) knows nothing about your caption support. It
will be all part of your Web application. Thus, if you application (written in
JavaScript) supports closed caption rendering, then it will also know that it
does so.


> > Assuming that "display native captioning" means that some other application
> > on the platform has caption support, then there is no such thing as "a
> > browser displaying native captions" - unless you use the <embed> tag, which
> > doesn't make use of <track> and TextTrack features.
> > 
> > > Also, if the native cues can be passed to application level in 'hidden' mode
> > > how can we convey that timing accuracy is not guaranteed but the data can be
> > > used by the application for other non-critical timing sensitive uses (like
> > > caption content search)? In this case, what type of 'hidden' TextTrackCue
> > > would we use..dataCue?
> > 
> > You can use DataCue to expose any inband timed data, yes. But the browser
> > won't magically expose it - you have to get browsers to implement it.
> 
> 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.

Why do you need to expose anything to JavaScript then?

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

Received on Tuesday, 28 January 2014 00:49:27 UTC