Re: Draft proposal for a Streams API in WebApps WG

+1 on it being very interesting as an extension of the MediaStreamTrack
API.  

I'd also be keen to see it resolved against the MediaStream Processing
API proposed by Robert O'Callahan in some way too.
http://hg.mozilla.org/users/rocallahan_mozilla.com/specs/raw-file/tip/StreamProcessing/StreamProcessing.html


roBman


On Fri, 2011-09-23 at 15:25 +0200, Harald Alvestrand wrote:
> 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:57:46 UTC