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

From: Aaron Colwell [mailto:acolwell@google.com] 

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

Totally understandable.

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

The way to do this in Streams is to pipe the fetch stream to a writable stream:

    fetch(url)
      .then(response => response.body.pipeTo(writableStream).closed)
      .then(() => console.log("all data written!"))
      .catch(e => console.log("error fetching or piping!", e));

By piping between two UA-controlled streams, you can establish an off-main-thread relationship between them. This is why it would be ideal for SourceBuffer (or a future alternative to it) to be WritableStream, especially given that it already has abort(), appendBuffer(), and various state-like properties that are very similar to what a WritableStream instance has. The benefit here being that people could then use SourceBuffers as generic destinations for any writable-stream-accepting code, since piping to a writable stream is idiomatic.

But that said, given the churn issue I can understand it not being feasible or desirable to take that path.

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

One speculative future evolution would be for SourceBuffer to grow a `.stream` or `.writable` property, which exposes the actual stream. Then appendStream could essentially be redefined as

    SourceBuffer.prototype.appendStream = function (readableStream) {
      readableStream.pipeTo(this.writable);
    };

and similarly appendBuffer could be recast in terms of `this.writable.write`, etc. Then developers who wish to treat the SourceBuffer as a more generic writable stream can just do `myGenericWritableStreamLibrary(mediaSource.sourceBuffers[0].writable)` or similar.

Received on Tuesday, 14 October 2014 17:18:35 UTC