[Bug 21300] lack of clarity around appendStream

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

Adrian Bateman [MSFT] <adrianba@microsoft.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adrianba@microsoft.com

--- Comment #3 from Adrian Bateman [MSFT] <adrianba@microsoft.com> ---
(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.

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

Received on Monday, 18 March 2013 15:10:15 UTC