[Bug 21300] lack of clarity around appendStream

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21300

Aaron Colwell <acolwell@chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |acolwell@chromium.org
           Assignee|adrianba@microsoft.com      |acolwell@chromium.org

--- Comment #1 from Aaron Colwell <acolwell@chromium.org> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 16 March 2013 15:56:02 UTC