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

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

Silvia Pfeiffer <silviapfeiffer1@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |silviapfeiffer1@gmail.com
           Assignee|dave.null@w3.org            |silviapfeiffer1@gmail.com

--- Comment #1 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
Please register one issue per bug.

(In reply to Graham from comment #0)
> Sometimes native captioning is supported by a decoder for regulatory reasons
> and cannot always physically be made available to the user agent and/or
> application. In addition native inband captions like CEA-708 are often
> highly optimized and converting these to a User Agent format like WebVTT can
> cause performance and captioner intent loss. Also, important cue information
> like endtime might only be available with the start of the next caption and
> trick play operation or continuous live streaming can corrupt cue timing
> accuracy compared to native captioning. 

Live captioning features are still under discussion in other bugs.

> The application or user agent would therefore benefit from making use of
> optimized native captioning.

What is "optimized native captioning"?

> The controls feature offers one way to do this
> at the user agent level however from JS only the TextTrack mode='showing' is
> provided. Yet, setting mode='showing' has other meanings, i.e. the captions
> that are stored in cues are being displayed, some of which may already have
> been created or modified out-of-band. In addition no knowledge of the native
> capability of the platform is being registered to the application in order
> to change this behavior. 
> 
> We need a way for the user agent to convey to JS support for native captions
> and for the application to have a method to turn them on or off. 

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.


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.

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

Received on Monday, 27 January 2014 23:55:23 UTC