RE: Tech Discussions on the Multitrack Media (issue-152)

[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