- From: Sean Hayes <Sean.Hayes@microsoft.com>
- Date: Tue, 1 Mar 2011 17:43:55 +0000
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, David Singer <singer@apple.com>
- CC: Bob Lund <B.Lund@cablelabs.com>, "public-html@w3.org" <public-html@w3.org>
[Silvia] "For both of the below to work, the browser has to implement an extraction of the cues from the binary media resource into a TextTrack with TextTrackCues, which then exposes it to the browser and to JavaScript. Since by default only TextTracks of @kind=subtitles or @kind=captions are rendered and these can only contain raw text, it probably makes sense to declare both the content advisory descriptor and the image-based caption as @kind=metadata." I disagree, while they may carried as text resources, there is no reason or statement that captions and subtitles cannot encode images, or indeed for an in-band track, a binary format like 608 or its SCC text-file equivalent. SMPTE-TT is a text format but it can carry encoded images of this form (as well as the Unicode text representation), the image forms part of the caption, so labeling this as metadata is incorrect. [Silvia] "In the case of image-based captions, I am uncertain how the images can actually be exposed to the browser. " The track format parser would know what to do with them, and would expose them with the getCueasHTML() method. [Silvia] "Anyway, these two are special use cases which IIUC rely on special track types. I am not sure how much of these special track types browser vendors actually would want to implement support for." I don't think images in captions relies on special track types, the 'kind'=captions is its role to the user. SMPTE added this feature as requirement of the content producers; and users and authors are supposed to trump implementers. But in any case I at least am implementing support for SMPTE-TT. Thanks, Sean.
Received on Tuesday, 1 March 2011 17:44:32 UTC