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:33:52 +1100
Message-ID: <AANLkTikMNrxnHimsQFd6CsdvKWDcm_EbQJMK+vHFKE_w@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 8:25 AM, Sean Hayes <Sean.Hayes@microsoft.com> wrote:
> That behavior is dependent on the parser allotted to the text track; which depends on the type of caption data. Since <track> is format independent, then it would not render the image as base 64 text if the format parser knows what that means, as SMPTE-TT does. I believe you are conflating the general text track behavior with a specific  text track parser.
>
> "1. what is the url that you are going to point the <img> element to
> for the image resource?"
> For example:
> data:image/png;base64,iVBORw0KGg....

Ah ok, as inline data. I guess that works...


> "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."
>
> From the spec: "Associated with the list are the rules for updating the text track rendering appropriate for the format in question; for WebVTT, this is the rules for updating the display of WebVTT text tracks. "
>
> The rules for updating are specific to each track format. By implication, for something other than WebVTT, the rules will be whatever that format requires.

Fair enough - I did overlook this. It seems indeed possible.
Implementations will tell if it's practical.

Cheers,
Silvia.
Received on Tuesday, 1 March 2011 21:34:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:23 GMT