Re: [MSE] Alternate proposal for resolving Bug 24370

Here is another slight tweak to the proposal based on a side channel
discussion with Pierre and Silvia about handling a track that might have
multiple kinds associated with it. The only change is that an array of
kinds is stored instead of a single kind.

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

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

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

partial interface SourceBuffer {
  attribute TrackDefaultList trackDefaults;
}

Aaron



On Fri, Apr 25, 2014 at 9:50 AM, Aaron Colwell <acolwell@google.com> wrote:

> 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.
>>>>
>>>
>>>
>>
>