- From: <bugzilla@jessica.w3.org>
- Date: Wed, 16 Apr 2014 16:49:31 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25355 --- Comment #2 from Bob Lund <b.lund@cablelabs.com> --- (In reply to Aaron Colwell from comment #1) > I was under the impression that inBandMetadataTrackDispatchType was intended > to be like a MIME-type for track so that the web application could speculate > about the type of data to expect from the track w/o having to receive any > actual cues. inBandTrack...Type contains fields from the track in the media resource that script can use to identify the type of metadata in that track. > I think this is a valuable thing to have and provides something > we could create a registry around that maps inBandMetadataTrackDispatchType > to expected cues exposed by the track. > > I'm concerned about having type strings exposed here. What is the use case > where the UA can determine the type, but not actually be able to parse the > data it is returning? If it understands the type, it seems like it should be > able to return a type specific cue for it. Something like this amplifies my > concern that unspeced protocols will be allowed because this is starting to > look like a "hash map" type interface. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 16 April 2014 16:49:33 UTC