W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Streams and Blobs

From: Aaron Colwell <acolwell@chromium.org>
Date: Tue, 26 Feb 2013 08:50:03 -0800
Message-ID: <CAA0c1bAP2Q8KYgbgOf1ygXaTWQ6msNrTKmAORsnaU2aMvbz7qQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Glenn Maynard <glenn@zewt.org>, WebApps WG <public-webapps@w3.org>
On Tue, Feb 26, 2013 at 8:38 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Tue, Feb 26, 2013 at 3:53 PM, Glenn Maynard <glenn@zewt.org> wrote:
> > On Tue, Feb 26, 2013 at 4:56 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> > I suppose a use case would be making a POST request or a request with
> > special headers set to access a video stream.  You can createObjectURL on
> > the resulting Stream and pass that to <video>.
> Fair point.
One other data point is that we are using the Stream as an opaque handle
for routing data to the Media Source
(See SourceBuffer.appendStream()<https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source.html#widl-SourceBuffer-appendStream-void-Stream-stream-unsigned-long-long-maxSize>).
The idea here is that it allows the data from an XHR to be transferred to
the SourceBuffer object w/o having to surface the data to JavaScript. The
Stream object seemed like a nice abstraction for this since it doesn't have
the immutable properties implied by Blobs. It also hides the source of the
data from MSE which is nice. I'm not saying that Stream is the only way to
handle this, but it is why parts of the Streams API are attractive to MSE.

Received on Tuesday, 26 February 2013 16:50:36 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:52 UTC