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

Re: MediaStream: multiple consumer case

From: Anne van Kesteren <annevk@annevk.nl>
Date: Wed, 3 Apr 2013 18:09:33 +0100
Message-ID: <CADnb78iSQPJCKW=zB47GnqS1y1FtwYO3Khe7ww58mVsk9VZJQw@mail.gmail.com>
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

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