W3C home > Mailing lists > Public > public-html-media@w3.org > April 2014

Re: [MSE] Alternate proposal for resolving Bug 24370

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Fri, 25 Apr 2014 14:05:00 +1000
Message-ID: <CAHp8n2mGxMxp3VUb993g6sWaPN1OOkVMat19kmNRnumSnejwqw@mail.gmail.com>
To: Aaron Colwell <acolwell@google.com>
Cc: "<public-html-media@w3.org>" <public-html-media@w3.org>
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 .


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

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.

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
Received on Friday, 25 April 2014 04:05:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:03 UTC