Re: TextTrackCue discussions

On Fri, Sep 20, 2013 at 5:13 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

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

No. It should return null. As Simon points out, an empty string is a
legitimate value for a cue.


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