Re: TextTrackCue discussions

On Fri, Sep 20, 2013 at 1:13 PM, Silvia Pfeiffer
<> wrote:
> On Fri, Sep 20, 2013 at 5:49 PM, Philip Jägenstedt <> wrote:
>> On Fri, Sep 20, 2013 at 5:21 AM, Silvia Pfeiffer
>> <> wrote:
>>> On Thu, Sep 19, 2013 at 12:11 AM, Philip Jägenstedt <> 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
>>> ?
>> 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.

I must have missed something again. The only concrete things to use
this new cue type that I remember are the open-ended extra tracks in
MPEG-2 streams, which I understood to be binary data. What kind of
MPEG-4 tracks do we expect would be exposed using this interface?


Received on Friday, 20 September 2013 11:39:40 UTC