W3C home > Mailing lists > Public > public-media-capture@w3.org > April 2013

Re: MediaStream: multiple consumer case

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 4 Apr 2013 13:49:36 +0200
Message-ID: <515D68D0.3060606@ericsson.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:40 UTC