- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 3 Apr 2013 18:09:33 +0100
- To: public-media-capture@w3.org
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. 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 Wednesday, 3 April 2013 17:10:00 UTC