FW: HTML5 support for track metadata

BTW, my proposal just extends what’s already defined in HTML5 and it covers the use cases I’ve seen. There is nothing preventing additional required features as the need is identified. This, I think, is an attractive aspect.

Bob

From: Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>
Date: Tuesday, March 4, 2014 at 2:04 PM
To: Brendan Long <B.Long@cablelabs.com<mailto:B.Long@cablelabs.com>>
Cc: "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Subject: Re: HTML5 support for track metadata



From: Brendan Long <B.Long@cablelabs.com<mailto:B.Long@cablelabs.com>>
Date: Tuesday, March 4, 2014 at 1:53 PM
To: Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>
Cc: "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Subject: Re: HTML5 support for track metadata

On Tue, 2014-03-04 at 20:17 +0000, Bob Lund wrote:
No. I am proposing extending HTML5 support for the 3rd option, i.e. Using inBandMetadataTrackDispatchType for metadata tracks and kind for all other tracks.
I don't see anywhere on the wiki saying what the format will actually be. Presumably it would be the same?

Yes, the inBandMetadataTrackDispatchType format is as defined in HTML5.



Why that option though? I took a look at the pros and cons<https://www.w3.org/community/inbandtracks/wiki/Main_Page>, and I disagree with several of them.

  *   inBandMetadataTrackDispatchType isn't implemented in any UA's I'm aware of (neither are the other two options).

Could any of the folks working for browser vendors comment on this?


  *
  *   Changing the HTML5 spec isn't a big deal because the TextTrack spec is in flux, and no one has implemented in-band metadata yet. Getting it right is more important than changing some attributes

In what sense is my proposal not “getting it right”? What use case is not covered?

  *
  *   The use-case for all three is exactly the same, but it's listed as a pro for inBandMetadataTrackDispatchType and a con for In-band Metadata Attribute.
  *   Accessing the data isn't significantly easier with one or another:

// In-band Metadata TextTrack
binaryData = track.activeCues[0].data;

// In-band Metadata Attribute
binaryData = track.metadata;

// inBandMetadataTrackDispatchType
binaryData = base64DecToArr(track.inBandMetadataTrackDispatchType.split(" ")[1])

The only one that’s defined in W3C is inBandTrackMetadataDispatchType – my proposal.

For inBandMetadataTrackDispatchType, converting from a base64 string to an ArrayBuffer is fairly complicated, but Mozilla provides the code for a base64DecToArr() function<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Base64_encoding_and_decoding>, so that's what I used above. Presumably people will copy and paste that code, or something similar, into their projects.
I'm somewhat biased, because I've been writing patches to support the In-band Metadata TextTrack alternative<https://bugs.webkit.org/show_bug.cgi?id=122001>, but from my perspective the pros and cons are:
Alternative     Pros    Cons
In-band Metadata TextTrack

  *   Allows JS to look at previous and future metadata (possibly not useful?).
  *   Allows us to keep the data as binary.
  *   DataCue was created for this purpose.


  *   Mixing metadata with cues is possibly inelegant.
  *   Possible complexity regarding old cues.


In-band Metadata Attribute

  *   Metadata as an attribute seems more elegant.
  *   Allows us to keep the data as binary.


inBandMetadataTrackDispatchType

  *   Metadata as an attribute seems more elegant.


  *   Need to encode binary as a string.


If we go with one of the attributes, we'll want to add some sort of "change" event to TextTrack, but I don't consider that to be a con, since it's trivial.