From: Aaron Colwell [mailto:[email protected]]
> 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.
