W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2011

Re: Draft proposal for a Streams API in WebApps WG

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 23 Sep 2011 15:25:05 +0200
Message-ID: <4E7C88B1.5060200@alvestrand.no>
To: public-webrtc@w3.org
On 09/23/11 12:05, Francois Daoust wrote:
> Hi,
>
> FYI, a draft proposal for a generic Streams API has started to be 
> discussed in the WebApps WG.
> Probably something to review and/or monitor for WebRTC. The initial 
> email is archived at:
>  http://html5labs.com/streamsapi/
>
> The initial email, copied below is at:
>  http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1569.html
A quick glance at the spec shows that streams represent a single data 
structure - there are no tracks.

This is of course inconsistent with the usage in the example of playing 
video - video streams have tracks according to HTML5; the author may be 
thinking of the playback of video files, where all the tracks are 
represented inside a container format.

It may be of interest to us as a model for the API of a single media 
stream track.

>
> Francois.
>
> Begin forwarded message:
>> > Resent-From: public-webapps@w3.org
>> > From: Adrian Bateman <adrianba@microsoft.com>
>> > Date: September 22, 2011 20:35:17 GMT+02:00
>> > To: "Web Applications Working Group WG (public-webapps@w3.org)" 
>> <public-webapps@w3.org>
>> > Cc: Feras Moussa <ferasm@microsoft.com>
>> > Subject: Draft Proposal for Streams API
>> > archived-at: 
>> <http://www.w3.org/mid/104E6B5B6535E849970CDFBB1C5216EB4E17C253@TK5EX14MBXC136.redmond.corp.microsoft.com>
>> >
>> > There has been discussion in this group now and again about the 
>> need for stream
>> > support as part of the File APIs including recently in the threads 
>> about Streaming
>> > Blobs [1] and XHR streaming [2]. I've also had several private 
>> conversations with
>> > members of the WG about the need we see for this kind of stream 
>> support.
>> >
>> > Initially, we thought that supporting a streaming Blob was the 
>> correct solution
>> > but we ran into a number of issues with this as we investigated 
>> further. First of
>> > all, people were confused about using the term "Blob" to represent 
>> something of
>> > unknown size. Secondly, we received guidance from a number of 
>> people to keep the
>> > two concepts of Blob and Stream separate.
>> >
>> > Back in March, we provided some suggestions about using streams in 
>> the context of
>> > Media Capture and Speech with our submission to the HTML Speech XG 
>> [3].
>> > Specifically at that time we said:
>> >
>> >  We propose the addition of a stream type. While this document does
>> >  not present a detailed design for this type, we assume a Stream is
>> >  an object that:
>> >
>> >    1. Has a content type;
>> >    2. Has unspecified length;
>> >    3. Can generally be used in the same places Blob can be used, for
>> >       example URL.createObjectURL().
>> >
>> > Over the last six months, we have refined our thinking further and 
>> would like to
>> > submit a proposal for review by the working group that provides 
>> that detailed
>> > design. We believe that this work is part of the chartered 
>> deliverables for File
>> > API (and includes XHR support):
>> >
>> >    Streams API - http://html5labs.com/streamsapi/
>> >
>> > We recognise that there are a number of different proposals for 
>> using stream-like
>> > objects elsewhere in the web platform, usually for very specific 
>> use cases. What
>> > we have tried to define here is a Stream object that is as generic 
>> as the Blob
>> > object defined in the File API spec.
>> >
>> > As we started building applications with richer access to devices 
>> on the system
>> > including files we found the lack of support for an object 
>> representing
>> > asynchronous data of (initially) unknown size was important. 
>> Section 11 of the
>> > proposal provides examples of the scenarios we have in mind. To 
>> start to address
>> > this gap, we have implemented a preview of this mechanism in IE10 
>> Platform
>> > Preview 3 behind a vendor prefix (e.g. MSStream) to gain more 
>> implementation
>> > experience.
>> >
>> > We look forward to hearing feedback on this proposal, which we've 
>> framed mostly
>> > as a delta against existing drafts in this working group.
>> >
>> > Thanks,
>> >
>> > Adrian.
>> >
>> > [1] 
>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0725.html
>> > [2] 
>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html
>> > [3] 
>> http://lists.w3.org/Archives/Public/www-archive/2011Mar/att-0001/microsoft-api-draft-final.html#streams
>> >
>> >
>> >
>> >
>
>
Received on Friday, 23 September 2011 13:25:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC