Re: TextTrackCue discussions

On 20 Sep 2013 21:39, "Philip Jägenstedt" <> wrote:
> On Fri, Sep 20, 2013 at 1:13 PM, Silvia Pfeiffer
> <> wrote:
> > On Fri, Sep 20, 2013 at 5:49 PM, Philip Jägenstedt <>
> >
> >> 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.
In Bob

"We've already implemented in-band captions for MPEG-2 TS where
getCueAsHTML returns a valid doc fragment for Cues containing 708 captions.
We've also implemented a UA that exposes all other MPEG-2 TS text track
data as Base64 encoded text via getCueAsText for text tracks not recognized
by the UA. This is to provide Web applications with the opportunity to
handle text track formats not supported by the UA. There is at least one
3rd party Web app developer that wants to make use of this feature."

(it's a bit difficult to distinguish his contribution from that of others,
but my email client has them separated)

So, not everything is binary.

> What kind of
> MPEG-4 tracks do we expect would be exposed using this interface?

Cyril listed a large number of tracks in this thread:

He found these to be relevant text tracks:

- ISO stuff: Text timed metadata, XML timed metadata, URI identified
metadata, MPEG-4 Systems streams, SVC metadata, text streams
- DVB stuff: Track Level Index Track, Movie level index track,
- 3GPP/OMA: 3GPP Timed Text, OMA Keys,
- DECE Sub-titles (Timed Text),
- Apple 32/64 bit timecode samples

Only some of these are binary, most are text or XML IIUC.

Received on Monday, 23 September 2013 06:45:59 UTC