W3C home > Mailing lists > Public > public-html-media@w3.org > October 2014

Re: [streams-api] Seeking status of the Streams API spec

From: Aaron Colwell <acolwell@google.com>
Date: Tue, 14 Oct 2014 10:01:55 -0700
Message-ID: <CAA0c1bD8U1RhQny7Z-CD_de0M2rGnYOaJY9Lhf6Y+sk8xipoWQ@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Paul Cotton <Paul.Cotton@microsoft.com>, Takeshi Yoshino <tyoshino@google.com>, public-webapps <public-webapps@w3.org>, Arthur Barstow <art.barstow@gmail.com>, Feras Moussa <feras.moussa@hotmail.com>, "public-html-media@w3.org" <public-html-media@w3.org>
On Tue, Oct 14, 2014 at 9:19 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> From: Aaron Colwell [mailto:acolwell@google.com]
> > Yes SourceBuffer is shipping and has been for quite some time in Chrome
> and IE.
> Hmm, window.SourceBuffer is undefined in Chrome.

You can only create SourceBuffer objects via the MediaSource object. That
is why it isn't available on window.

> > I am NOT going to rework it all to be a WritableStream.
> That's a shame, but completely understandable that you wouldn't want to be
> one of the early-adopters. Over time we'll work to convert to using streams
> (in an integrated way) across the ecosystem, but I understand this will
> involve a lot of legwork from my side and from the streams implementers
> (e.g. the Tokyo team at Google).

MSE is just too far along, has already gone through a fair amount of churn,
and has major customers like YouTube and Netflix that I just don't want to
break or force to migrate...again.

> > I am just looking to adjust appendStream() to take whatever object
> replaced the old Stream object that was in the original. It sounds like
> this is ReadableStream so I'll take a look at the latest spec text and
> update MSE accordingly.
> I would suggest just removing appendStream, personally. It does not seem
> to carry its own weight given that it is non-compositional with the rest of
> the stream ecosystem. As an analogy, this would be like adjusting a
> callback-taking method to wait for any promises its callbacks return,
> without actually converting the method to be promise-returning. In other
> words, a very halfhearted integration of a less-important part of the
> promise ecosystem, ignoring the more important part that allows developers
> to use the method seamlessly.

I haven't spent much time looking at the new Stream spec so I can't really
say yet whether I agree with you or not. The main reason why people wanted
to be able to append a stream is to handle larger, open range, appends
without having to make multiple requests or wait for an XHR to complete
before data could be appended. While I understand that you had your reasons
to expand the scope of Streams to be more general, MSE really just needs
them as a "handle" to route bytes being received with XHR to the
SourceBuffer w/o having to actually surface them to JS. It would be really
unfortunate if this was somehow lost in the conversion from the old spec.

> It would be better to wait for a "v2" of MSE that can integrate streams
> more correctly, than to tack on appendStream, IMO.
Perhaps, although I expect that there may be some resistance to dropping
this at this point. Media folks were expecting the Streams API to progress
in such a way that would at least allow appendStream() to still work
especially since it only needs a stream for recieving bytes. I'll dig into
the latest Streams spec so I can better understand the current state of

Received on Tuesday, 14 October 2014 17:02:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:55 UTC