Re: File API: reading a Blob

On Thu, Sep 11, 2014 at 8:47 AM, Aymeric Vitte <vitteaymeric@gmail.com>
wrote:

>  Does your experimentation pipe the XHR stream to MSE? Obviously that
> should be the target for yt, this would be a first real application of the
> Streams API.
>

It's not yet updated to use the new Streams. Here's our layout test for
MSE. responseType = 'legacystream' makes the XHR return the old version of
the stream.

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/http/tests/media/media-source/mediasource-append-legacystream.html&q=createMediaXHR&sq=package:chromium&type=cs&l=12

You can find the following call in the file.

sourceBuffer.appendStream(xhr.response);


>
> Because the Streams API does not define how to apply back pressure to XHR,
> but does define how to apply back pressure between XHR and MSE.
>
> Probably the spec should handle on a per case basis what should be the
> behavior in term of back pressure for things coming from outside of the
> browser (xhr, websockets, webrtc, etc , not specified as far as I know) and
> for things going on inside the browser (already specified)
>
> Le 08/09/2014 06:58, Takeshi Yoshino a écrit :
>
>  On Thu, Sep 4, 2014 at 7:02 AM, Aymeric Vitte <vitteaymeric@gmail.com>
> wrote:
>
>> The fact is that most of the W3C groups impacted by streams (File,
>> indexedDB, MSE, WebRTC, WebCrypto, Workers, XHR, WebSockets, Media Stream,
>> etc, I must forget a lot here) seem not to care a lot about it and maybe
>> just expect streams to land in the right place in the APIs when they are
>> available, by some unknown magic.
>>
>> I still think that the effort should start from now for all the APIs (as
>> well as the implementation inside browsers, which apparently has started
>> for Chrome, but Chrome was supposed to have started some implementation of
>> the previous Streams APIs, so it's not very clear), and that it should be
>> very clearly synchronized, disregarding vague assumptions from the groups
>> about low/high level and Vx releases, eluding the issue.
>
>
>  Chrome has an experimental implementation [1] of the new Streams API [2]
> integrated with XHR [3] behind a flag.
>
>  We receive data from the browser process over IPC (both network and blob
> case). The size of data chunks and arrival timing depend on various
> factors. The received chunks are passed to the XMLHttpRequest class on the
> same thread as JavaScript runs. We create a new instance of ReadableStream
> [4] on arrival of the first chunk. On every chunk arrival, we create an
> ArrayBuffer from the chunk and then call [[enqueue]](chunk) [5] equivalent
> C++ function to put it into the ReadableStream.
>
>  The ReadableStream is available from the "response" attribute in the
> LOADING and DONE state (if no error). The chunks pushed to the
> ReadableStream become available for read immediately.
>
>  Any problem occurs while loading data from network/blob, we call
> [[error]](e) [6] equivalent C++ function with an exception as defined in
> the XHR spec for sync XHR.
>
>  Currently, XMLHttpRequest doesn't exert any back pressure. We plan to do
> something not to read too much data from disk/network. It might be worth
> specifying something about the flow control in the abstract read from
> blob/network operation at standard level.
>
>  [1]
> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/response-stream.html
>  [2] https://github.com/whatwg/streams
> <https://github.com/whatwg/streams#readablestream>
> [3] https://github.com/tyoshino/streams_integration/
>  [4] https://github.com/whatwg/streams#readablestream
> [5] https://github.com/whatwg/streams#enqueuechunk
>  [6] https://github.com/whatwg/streams#errore
>
>
>
> --
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>
>