Re: [MSE] Alternate proposal for resolving Bug 24370

For the record, here is one final tweak to the API based on the discussion
on today's teleconference call. The only change is to specify the default
value for the optional byteStreamTrackID parameter in the constructor.

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;
}

I will start working on integrating this proposal into the spec.

Aaron


On Mon, Apr 28, 2014 at 8:17 AM, Aaron Colwell <acolwell@google.com> wrote:

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