Re: File API: reading a Blob

But I suppose that should be one of the first use case for Google to 
introduce streams with MSE, no?

To be more clear about what I mean by "back pressure for things coming 
from outside of the browser":

- XHR: the Streams API should define how xhr gets chunks using Range 
according to the flow and adapt accordingly transparently for the users

- WebSockets: use something like bufferedAmount but that can be notified 
to the users, so the users can adapt the flow, currently bufferedAmount 
is not extremely usefull since you might need to do some polling to 
check it.


Le 11/09/2014 08:36, Takeshi Yoshino a écrit :
> On Thu, Sep 11, 2014 at 8:47 AM, Aymeric Vitte <vitteaymeric@gmail.com 
> <mailto: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 <mailto: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
>
>

-- 
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