- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Tue, 06 May 2014 18:21:29 +0200
- To: public-html-media@w3.org
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 ?)
- is set by the application with the TrackDefaultList constructor. When?
before any initialisation segment is appended? or at any time?
- 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? How does it behave when new init
segments are appended?
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:22:01 UTC