- From: <bugzilla@jessica.w3.org>
- Date: Sat, 16 Mar 2013 15:56:01 +0000
- To: public-html-bugzilla@w3.org
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