[MSE] Alternate proposal for resolving Bug 24370

Hi,

After thinking about the F2F discussion around Bug
24370<https://www.w3.org/Bugs/Public/show_bug.cgi?id=24370>,
I’ve come up with the following alternate proposal. Essentially I’m
proposing that a trackDefaults attribute be added to SourceBuffer. This
attribute contains a list of default values that will be consulted every
time the initialization segment received
algorithm<https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source.html#sourcebuffer-init-segment-received>needs
to create a new AudioTrack, VideoTrack, or TextTrack. If the
initialization segment does not contain language and/or kind information
for the track, then the algorithm will look in the .trackDefaults for a
TrackDefault object with a byteStreamTrackID value that matches the unique
“byte stream level track ID” (ie. track_id in ISOBMFF, TrackNumber in WebM,
PID in MP2TS). If a TrackDefault object is found, then it will assign the
values provided in that object to the respective xxxTrack attributes.


Here is the proposed WebIDL for the new API:

enum TrackDefaultType {
 “audio”,
 “video”,
 “text”
};

interface TrackDefault {
 readonly attribute TrackDefaultType type;
 readonly attribute DOMString byteStreamTrackID;
 readonly attribute DOMString language;
 readonly attribute DOMString kind;
}

interface TrackDefaultList {
 readonly attribute unsigned long length;
 getter TrackDefault (unsigned long index);

 void add(TrackDefaultType type, DOMString byteStreamTrackID, DOMString
language, DOMString kind);
 void remove(TrackDefault trackDefault);
 void clear();
}

partial interface SourceBuffer {
 readonly attribute TrackDefaultList trackDefaults;
}

Notes:
- byteStreamTrackID must be unique and TrackDefaultList.add() will throw an
exception if one tries to add a duplicate. An alternative behavior could be
to replace the existing default with the new values, but I’m not sure if
that is option of least surprise.

- The TrackDefaultType is primarily used to validate kind since the set of
allowed strings is different for each track type. It’s easiest to enforce
this at add() time instead of silently failing at xxxTrack creation time if
the kind does not actually match the underlying track type.

- .trackDefaults cannot be modified while SourceBuffer.updating is true.

- .trackDefaults is only consulted at the moment the new xxxTrack objects
are created. Any changes to the defaults after the xxxTrack objects are
created are not reflected by the track objects.

Please respond to this proposal as soon as possible so I can start
integrating the changes into the spec. If I don’t hear any objections
within a week, I’ll update the editors draft with this proposal.

Aaron