[Bug 25355] Move TextTrack.inBandMetadataTrackDispatchType to DataCue.type, and make it optional

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25355

--- Comment #5 from Aaron Colwell <acolwell@google.com> ---
(In reply to Brendan Long from comment #3)
> (In reply to Aaron Colwell from comment #1)
> > 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.
> 
> As far as I know, every container format has metadata to say what type of
> data a stream contains (stream_type for MPEG-TS, CodecID for Matroska and
> WebM, Ogg Skeleton has a mime type). By exposing that data, we can tell
> JavaScript what the track contains without knowing how to parse it.

I don't have a problem with TextTrack.inBandMetadataTrackDispatchType. My
assumption is that it would set that attribute based on the fields you've
mentioned here, assuming name conflicts are avoided.

A DataCue.type value seems very different to me than this though. It implies to
me that the UA is able to partially parse Blocks/Samples/Cues or whatever the
container specific concept is called. It seems to me that if the UA is able to
parse the data one level deeper, it should represent this as a format specific
type instead of a generic DataCue. To me DataCue should indicate "I don't know
how to parse this", whereas something like MP2TSPrivateDataCue would indicate
"Here is a transport stream private data cue that has some fields and a block
of data I don't know how to parse."

I feel like being explicit about the types expected in metadata tracks would
greatly facilitate interoperability and make it clearer what the UA does and
does not know.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 16 April 2014 17:36:04 UTC