W3C home > Mailing lists > Public > public-html@w3.org > September 2013

Re: TextTrackCue discussions

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 20 Sep 2013 21:13:55 +1000
Message-ID: <CAHp8n2=opqZjjRqAUhJEBjNe4MqQ6x2xD8J_n7G14tPRRW03vA@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Glenn Adams <glenn@skynav.com>, Simon Pieters <simonp@opera.com>, Brendan Long <self@brendanlong.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, Eric Carlson <eric.carlson@apple.com>
On Fri, Sep 20, 2013 at 5:49 PM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Fri, Sep 20, 2013 at 5:21 AM, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> On Thu, Sep 19, 2013 at 12:11 AM, Philip Jägenstedt <philipj@opera.com> wrote:
>>> Hmm, this makes we wonder what the property for accessing the data is
>>> supposed to be. If it's a string, then it requires that the UA at
>>> least know what the encoding of the text is, which seems like it might
>>> not be true. RawCue and exposing the data as a typed array .data
>>> property seems OK to me. The other option is to base64-encode cues
>>> which are of an unknown encoding, I guess?
>> ArrayBuffer .data works for me.
>> Should we keep .text as well, because converting from ArrayBuffer to
>> String can be inefficient, see
>> http://updates.html5rocks.com/2012/06/How-to-convert-ArrayBuffer-to-and-from-String
>> ?
> What would the text property contain when the browser doesn't know the
> encoding?

Return an empty string. That can also be used by the JS dev to know
that they need to look at the .data ArrayBuffer.

> I think it's probably simplest to only expose a single
> ArrayBuffer property, and add convenience properties only as the need
> becomes apparent.

What do you mean? All of the examples that we have from MPEG-4 are
text-based, so it's the 90% use case and the need for a convenience
property seems clear.

Received on Friday, 20 September 2013 11:14:43 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:05 UTC