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

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

--- Comment #4 from Graham <graham.clift@am.sony.com> ---
(In reply to Silvia Pfeiffer from comment #3)
> (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.

Well the application needs to know that captions are available in the stream so
that it can turn them on or else resort to out-of-band method to provide
captioning. In addition the application needs to know when the captions that
are available in the stream but are not presentable as cues so don't rely upon
'hidden'. 

I will spell it out with an example. An MPEG-2 TS video stream has 708 captions
inband from which the user agent  creates a TextTrack with kind caption. The
captions however cannot be presented as cues to the user agent so the
application needs to rely upon the native capability and not use
mode='hidden'.One way would be for a new 'kind' called 'caption-native-only'.
Here, setting the mode to 'showing' turns them on and setting the mode to
'hidden' or 'disabled' turns them off.  
Another device has native caption support and can provide TextTrack cues
transcoded as VTTCue. Setting the mode to 'showing' results in the device
deciding whether to use the native stream caption decoder capability or to use
the generated VTTCue captions. In 'hidden' the VTTCues are still generated for
the application to either for their own caption rendering library or other
application purposes.

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

Received on Tuesday, 28 January 2014 22:57:23 UTC