W3C home > Mailing lists > Public > public-html@w3.org > March 2011

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 2 Mar 2011 08:13:36 +1100
Message-ID: <AANLkTikMm+0POvoVMmkY2TBZ+aqqeM-GOxdow9deNGHR@mail.gmail.com>
To: Sean Hayes <Sean.Hayes@microsoft.com>
Cc: David Singer <singer@apple.com>, Bob Lund <B.Lund@cablelabs.com>, "public-html@w3.org" <public-html@w3.org>
On Wed, Mar 2, 2011 at 4:43 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
> [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.


I was discussing how this data would be exposed through the existing
TextTrack API. From the POV of that API, data in a cue would be
exposed as exactly the text data that it is. Thus, if you expose a
in-band track that contains a base-64 encoded image as a
@kind=subtitles or @kind=captions TextTrack, the browser will display
the base-64 codes on top of the video as though it was text.
Therefore, it is required to be exposed as @kind=metadata such that it
can be exposed to JavaScript and the Web developer can write a bit of
JS code to transcode it back to binary and display in a custom manner.


>
> [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.

This is not the way in which the spec is currently written. Even if
the browser adds a <img> element into the cue, there remain unsolved
questions:
1. what is the url that you are going to point the <img> element to
for the image resource?
2. A @kind=captions track is automatically rendered as text on top of
the video. Thus, IIUC you will not get an interpreted <img> element,
but a verbatim <img> element displayed on top of the video.

Cheers,
Silvia.
Received on Tuesday, 1 March 2011 21:14:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:23 UTC