[Bug 23113] Deal with mode for TextTrackCues that are not VTTCues

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

--- Comment #4 from Graham <graham.clift@am.sony.com> ---
(In reply to Philip Jägenstedt from comment #3)
> (In reply to Graham from comment #2)
> > I think the mode='showing' approach is really a band-aid that helps but
> > doesn't solve all the problems. So maybe the starting point here is to
> > define some of the problems that I believe we need to solve:
> > 
> > Problem1: App needs to know whether the UA is already showing these captions
> > by itself. Currently the app can set mode='showing' and not know the result
> > in the UA.
> > 
> > Problem2: App needs to know whether the UA is capable of showing these
> > captions if requested to turn them on. There is no way interrogate the UA
> > capabilities in order to, say,allow for loading a captioning display library
> > in advance. 
> 
> I don't think either of these problem will appear in current
> implementations, since everyone who exposes VTTCue will also render it when
> mode=='showing'. If we just avoid adding interfaces which some browsers will
> render and some won't, then just looking at the interface will be enough.
>
So are you suggesting then that if the UA cannot render the inband captions
then it should not expose them to the application? That would prevent the
scenario where a JavaScript library handles the raw caption data when a UA
cannot handle the format. 

> > Problem3: App needs to know whether the platform supports native captioning
> > in one type and and whether it is capable of and whether it does convert
> > these to another format when presenting to JS. For example: A UA might be
> > able to leverage the platform's native display of CEA-708 captions when the
> > video is presented fullscreen but not in partial screen mode. Support for
> > captioning in the partial screen mode might be done by converting captions
> > to WebVTT or TTML cues in order to make use of the UA's native captioning
> > ability.
> 
> The fullscreen API just makes a website occupy the full screen but is still
> just rendering as usual, so it seems unlikely that the ability to render
> captions would be affected by it. As for querying which kinds of captions
> are supported, just looking for the existence of its cue interface seems
> sufficient, so e.g. if window.TTMLCue exist then the browser knows how to
> parse and render TTML.
(Just be be clear, I gave the fullscreen API as an example of the problem
only.) In my experience some UA's do treat rendering video fullscreen uniquely
to allow for higher performing native video pipeline processing capabilities of
the device. In these cases higher performing native captioning can be leveraged
also.

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

Received on Thursday, 12 September 2013 16:12:48 UTC