Re: [MSE] Alternate proposal for resolving Bug 24370

Hi Mark,

You raise a good point here. While trying to come up with modifications to
my proposal to accomodate your request, I discovered that this can make the
semantics for TrackDefaltList.add() a little awkward because it requires
incrementally enforce constaints to keep the contents of the list sane.
I've decided to rework the proposal to eliminate this.

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

[Constructor(TrackDefaultType type, DOMString language, DOMString kind,
optional DOMString byteStreamTrackID)]
interface TrackDefault {
 readonly attribute TrackDefaultType type;
 readonly attribute DOMString byteStreamTrackID;
 readonly attribute DOMString language;
 readonly attribute DOMString kind;
}

[Constructor(sequence<TrackDefault> trackDefaults)]
interface TrackDefaultList {
 readonly attribute unsigned long length;
 getter TrackDefault (unsigned long index);
}

partial interface SourceBuffer {
  attribute TrackDefaultList trackDefaults;
}

Primary changes:
- TrackDefaultList is immutable so validation is only required on
construction.
- SourceBuffer.trackDefaults attribute is now mutable. Defaults are updated
by setting the attribute with a new TrackDefaultList instance instead of
using add(), remove(), and clear(). The attribute is initialized with a
TrackDefaultList constucted with an empty sequence.
- TrackDefault actually specifies a constructor now so JS can actually
create instances of this object.
- TrackDefaultList has a constructor now so that JS can create instances.
- byteStreamTrackID is optional.
- The TrackDefaultList constructor will throw an exception if the
trackDefaults sequence contains two or more TrackDefault objects with the
same .type and no .byteStreamTrackID specified. This makes sure that only
one byteStreamTrackID-less default is provided for each TrackDefaultType.
- When a xxxTrack needs to be created, the SourceBuffer first looks for an
object, with the appropriate .type, that has a matching byteStreamTrackID.
If a matching object is not found, then it searches for an object, with the
appropriate .type, with byteStreamTrackID not set and uses that as the
default instead. If an TrackDefault object still isn't found then .language
will be "". and .kind wil be whatever HTML5 says the default kind value
should be.

I believe this addresses your concern and makes the API a little cleaner.

Aaron

On Fri, Apr 25, 2014 at 7:58 AM, Mark Watson <watsonm@netflix.com> wrote:

> HI Aaron,
>
> I think the proposal works but I think that byteStreamTrackID should be
> optional in the case that only one set of default track settings is
> provided. In that case, if there is only one track in the stream, it gets
> the provided defaults and if there is more than one track in the stream the
> defaults are ignored.
>
> This would avoid the need to know the byteStreamTrackID for the common
> case where there is only one track for each SourceBuffer.
>
> ...Mark
>
>
>
> On Fri, Apr 25, 2014 at 7:25 AM, Aaron Colwell <acolwell@google.com>wrote:
>
>> On Thu, Apr 24, 2014 at 9:46 PM, Silvia Pfeiffer <
>> silviapfeiffer1@gmail.com> wrote:
>>
>>> On Fri, Apr 25, 2014 at 2:32 PM, Aaron Colwell <acolwell@google.com>
>>> wrote:
>>> >
>>> > 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 is invoked.)
>>>
>>> OK, thanks, I get it. Why would .trackDefaults be in every
>>> SourceBuffer object rather than just in the MediaSource ?
>>>
>>
>> Because different SourceBuffer objects can have byte streams that contain
>> the same underlying byteStreamTrackID and there would be no way to
>> differentiate the two.
>> For example, in the case were a SourceBuffer is used for the audio track
>> and a different SourceBuffer is used for the video track, it is highly
>> likely that the track in each byte stream will have a byteStreamTrackID of
>> '1' because in each case there is only 1 track. Putting the defaults on the
>> MediaSource would require specifying a SourceBuffer parameter to
>> TrackDefaultList to disambiguate this case, which seems a little odd to me
>> since this is really a matter that is internal to the SourceBuffer and not
>> a MediaSource wide concern.
>>
>> Aaron
>>
>>
>>>
>>> Silvia.
>>>
>>
>>
>