- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Thu, 4 Apr 2013 13:49:36 +0200
- To: public-media-capture@w3.org
On 4/3/13 7:09 PM, Anne van Kesteren wrote: > My apologies for losing context. I was not subscribed to this list (am > now) and I was not cc'd on replies. > > With regards to MediaStream: I guess the only consumers are consumers > that continuously read? E.g. if I pause a <video>, is that <video> > responsible for buffering the data coming out of MediaStream or is > MediaStream storing it, or will it be lost? > > For XMLHttpRequest there's no (new) draft yet. There is > http://www.w3.org/TR/streams-api/ but as far as I can tell that Stream > object is not an actual stream as it does not discard data. > > What we want is a Stream object of which multiple consumers can read, > similarly to MediaStream. One thing that is unclear to me is how multiple consumers work with the StreamBuilder's availableDataSize/threshold. You could create a StreamBuilder, attach its Stream to two consumers consuming at different rates. What remains available in the Stream depends on from what consumer you look. I guess the StreamBuilder would report amount of data available from the perspective of the consumer that has consumed the most, but it is not 100% clear when I read. > Since you can instantiate stream readers > over the course of a stream's life time not all will see the same > data. If a stream reader decides not to read, the data will be kept. > We probably want new readers to not have access to that kept data. > However, it's not entirely clear whether new readers should start > getting content from the point the next task adds something to the > stream or from wherever the latest reader is, or something else. > > I suspect we do not want Stream to be confused with MediaStream in any > way as MediaStream is to some extent designed to be opaque. We do not > want someone to extract its bytes at any given point. However, > endpoints that accept a MediaStream should also accept a Stream in due > course. > > Hopefully the above is somewhat clear. If not, my goal is exposing > streams to the platform that can be read from by multiple consumers > where no data is lost if you do not continuously invoke the read > command from your stream reader (which can be anything, from a > StreamReader object to a <video>). > > > -- > http://annevankesteren.nl/ >
Received on Thursday, 4 April 2013 11:50:02 UTC