- From: Aaron Colwell <acolwell@google.com>
- Date: Tue, 6 May 2014 09:54:56 -0700
- To: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Cc: "<public-html-media@w3.org>" <public-html-media@w3.org>
- Message-ID: <CAA0c1bAZ24K9tkc96tJXDTkdkDphcBCy+UekT=ucTeEs+0GdOQ@mail.gmail.com>
Hi Cyril,
Comments inline..
On Tue, May 6, 2014 at 9:21 AM, Cyril Concolato <
cyril.concolato@telecom-paristech.fr> wrote:
> Hi Aaron,
>
> Following my comment today, I understand the following. Correct me if I'm
> wrong.
>
> SourceBuffer.trackDefaults:
> - points to an empty TrackDefaultList at the creation of the SourceBuffer
> (or is null ?)
>
It would point to an empty TrackDefaultList.
> - is set by the application with the TrackDefaultList constructor. When?
> before any initialisation segment is appended? or at any time?
>
SourceBuffer. trackDefaults can be set at any time that
SourceBuffer.updating equals false and the SourceBuffer is still listed in
the sourceBuffers attribute of the parent media source. Since this
information will only be accessed in the initialization segment
received<https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source.html#sourcebuffer-init-segment-received>algorithm
I think it is safe to allow modification whenever the
SourceBuffer isn't appending data.
> - is modified (or is a new TrackDefaultList created? or only new
> TrackDefault objects are created and replace the existing ones in the
> list?) by the implementation based on the information in the file when an
> initialization segment is passed?
The defaults are modified by assigning a new TrackDefaultList instance to
the trackDefaults attribute. I intentially made this object immutable so
that validation of the TrackDefault sequence only has to happen during
construction. As I indicated in my response to Mark's email, the defaults
will only be consulted when an xxxTrack needs to be create and there is no
kind/language information in the byte stream itself.
> How does it behave when new init segments are appended?
>
The defaults only come into play when new xxxTrack objects are created. My
initial assumption is that tracks only tend to get created on the first
initialization segment because the number of tracks in a SourceBuffer is
required to stay constant. I realize now though that if the language and
kind is actually in the byte stream, tracks would have to be destroyed and
recreated with the new info. The track defaults should probably be
considered on each initialization segment so that similar behavior can be
triggered when the language/kind info is outside of the byte stream. I
don't have the exact details worked out here, but I expect this to become
clearer once I start updating the spec.
Aaron
>
> Cyril
>
> Le 06/05/2014 17:53, Aaron Colwell a écrit :
>
>> 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<mailto:
>> 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 <mailto: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 <mailto: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 <mailto:acolwell@google.com>> wrote:
>>
>> On Thu, Apr 24, 2014 at 9:46 PM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com
>> <mailto:silviapfeiffer1@gmail.com>> wrote:
>>
>> On Fri, Apr 25, 2014 at 2:32 PM, Aaron Colwell
>> <acolwell@google.com <mailto: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.
>>
>>
>>
>>
>>
>>
>>
>
> --
> Cyril Concolato
> Multimedia Group / Telecom ParisTech
> http://concolato.wp.mines-telecom.fr/
> @cconcolato
>
>
>
Received on Tuesday, 6 May 2014 16:55:25 UTC