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

Re: MediaStream: multiple consumer case

From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 3 Apr 2013 11:21:29 -0700
Message-ID: <CABkgnnVKnZP5LeNeB_d960JFBg1wiS136xQ=z7W5bjCo2h8a8w@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
The uses you describe for XMLHttpRequest are different to media
streams.  We want media to be "lost" if it isn't played out.  If we
buffered, it would cease to be real-time.

That doesn't preclude the addition of features that enable buffering,
pausing and so forth.

On 3 April 2013 10:09, Anne van Kesteren <annevk@annevk.nl> 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. 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 18:21:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:16 UTC