- From: Aaron Colwell <acolwell@google.com>
- Date: Tue, 14 Oct 2014 10:01:55 -0700
- 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>
- Message-ID: <CAA0c1bD8U1RhQny7Z-CD_de0M2rGnYOaJY9Lhf6Y+sk8xipoWQ@mail.gmail.com>
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 things. Aaron
Received on Tuesday, 14 October 2014 17:02:26 UTC