Re: [MSE] Alternate proposal for resolving Bug 24370

On Thu, Apr 24, 2014 at 9:05 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> Please get input through the bug tracker, too, both on bugs
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24370 and
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24563 .
>
> I'll post a link to this thread.


>
> Can you explain how that would fix the problem described in the bugs?
>

The xxxTrack.kind and xxxTrack.language attributes won't need to be
mutable. The new SourceBuffer.trackDefaultList allows the application to
specify defaults that are used when the MediaSource code creates the
xxxTrack objects. This proposal would allow both of those bugs to simply be
closed since this new proposal doesn't result in invalid WebIDL and it
doesn't rewire making the .kind and .language attributes mutable.



> Are you saying that when the browser does an initial read of a media
> file and it creates a MediaSource object with lists of SourceBuffer
> objects, it also creates TrackDefaultList objects (one per identified
> track) with the default settings (type, byteStremTrackID, language and
> kind) for all tracks thus far encountered? Or is the user to create
> the TrackDefault objects and tell the browser which ones apply to the
> SourceBuffer objects? I am a bit confused.
>

No. The web application adds default information to the trackDefaultList on
the SourceBuffer. The SourceBuffer code consults these defaults when data
gets appended that would result in xxxTrack objects getting created (ie
when the initialization segment received
algorithm<https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source.html#sourcebuffer-init-segment-received>
is
invoked.)

Aaron


> Cheers,
> Silvia.
>
>
>
> On Fri, Apr 25, 2014 at 6:42 AM, Aaron Colwell <acolwell@google.com>
> wrote:
> > Hi,
> >
> > After thinking about the F2F discussion around Bug 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 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
>