In general appendStream() doesn't care what the source of the Stream object is. It could be from an XMLHttpRequest, a File object, a WebSocket, or whatever else happens to be able to create instances of Stream. Technically MSE only has a dependency on the Stream interface and not any particular spec that specifies how instances of these objects are created. 

Practically though, the expectation is that the primary use case for this method is with a Stream object created by XMLHttpRequest. The details on how XMLHttpRequest's Stream object behave are outside the scope of the MSE. If I were to speculate though, I'd assume that if the network buffers for the request were full, then it would simply stop reading from the socket until the Source Buffer consumed enough of the data from the Stream to free up space. When more space was available then the UA would start reading from the socket again. If the server closes the connection because the UA hasn't read in a while, then I'd expect the normal error handling to occur and the Source Buffer to trigger an error event because the append was aborted early.

If the request is so large that it starts causing evictions in the Source Buffer then I'd expect the UA to do its best to keep the most important time ranges around to avoid playback disruptions, but it would be highly likely that some of the data in the request would not be in the Source Buffer when the append completes. This behavior should provide the necessary incentive to avoid huge appends and unnecessarily large media segment sizes.

I will make the dependency on the Streams API spec more obvious by putting a biblio link to the spec right next to the Stream link in appendStream()'s description.

(In reply to comment #1)
<snip>
> Practically though, the expectation is that the primary use case for this
> method is with a Stream object created by XMLHttpRequest. The details on how
> XMLHttpRequest's Stream object behave are outside the scope of the MSE.

I agree that formally they're outside the scope of MSE however if MSE is making assumptions about this behaviour then those assumptions should be documented *somewhere* otherwise you will get implementations of XMLHttpRequest's stream object that are fine as far as the XHR spec is concerned but fail in strange subtle ways with MSE. 

Also in most organisations, non-documented assumptions can't have tests written for them which results in inter-operability issues once there is more than one implementation.

> If I
> were to speculate though, I'd assume that if the network buffers for the
> request were full, then it would simply stop reading from the socket until
> the Source Buffer consumed enough of the data from the Stream to free up
> space. When more space was available then the UA would start reading from
> the socket again.

In your view, would this allow use-cases where the data from the stream that has been copied into the Source Buffer starts being copied to the Decoder Buffer before the last data from the stream has been read in?

(In reply to comment #2)
> (In reply to comment #1)
> <snip>
> > Practically though, the expectation is that the primary use case for this
> > method is with a Stream object created by XMLHttpRequest. The details on how
> > XMLHttpRequest's Stream object behave are outside the scope of the MSE.
> 
> I agree that formally they're outside the scope of MSE however if MSE is
> making assumptions about this behaviour then those assumptions should be
> documented *somewhere* otherwise you will get implementations of
> XMLHttpRequest's stream object that are fine as far as the XHR spec is
> concerned but fail in strange subtle ways with MSE. 
> 
> Also in most organisations, non-documented assumptions can't have tests
> written for them which results in inter-operability issues once there is
> more than one implementation.

I don't believe that MSE is making any such assumptions. Please can you articulate some and propose how they should be described?

> > If I
> > were to speculate though, I'd assume that if the network buffers for the
> > request were full, then it would simply stop reading from the socket until
> > the Source Buffer consumed enough of the data from the Stream to free up
> > space. When more space was available then the UA would start reading from
> > the socket again.
> 
> In your view, would this allow use-cases where the data from the stream that
> has been copied into the Source Buffer starts being copied to the Decoder
> Buffer before the last data from the stream has been read in?

Optimisations like this are deliberately not required but one would expect higher quality implementations to include them. The goal of including Stream support was to allow the UA to copy from network buffer to media engine buffer without having an intermediate ArrayBuffer available to JavaScript for other purposes (which would imply additional copying). Since the Stream type is designed for situations where data may be processed before it is all received your scenario is a valid one. However, the implementation of whatever is providing the Stream will determine how and where buffering needs to happen.

Marking as NEEDSINFO since we need more information from Jon before we can determine what needs to be changed in the spec.