W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2015

Re: An updated MediaRecorder proposal based on streams

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 13 Aug 2015 09:24:11 +0200
Message-ID: <55CC461B.7060008@alvestrand.no>
To: public-media-capture@w3.org
Den 12. aug. 2015 22:28, skrev Domenic Denicola:
> Hi all,
> There is some interest from Blink [0] in reviving the MediaRecorder proposal [1], currently only implemented in Firefox, by basing it on the streams API [2]. I managed to spend some time drawing up what this would look like:
> https://domenic.github.io/streaming-mediastreams/
> It largely encompasses the use cases and API of MediaRecorder, with only minor tweaks. I believe it can do everything MediaRecorder can do, with the additional benefits of integrating with the standard streaming infrastructure

Just a check: Which browsers implement the "standard streaming
infrastructure" at the moment?

> and having a much more pleasant-to-use API as a consequence, avoiding the potential data loss that the current event-based API can induce.
> I would love for the group to give feedback on this proposal. Does it seem plausible as a "MediaRecorder v2"?
>  [0]: https://groups.google.com/a/chromium.org/d/msg/blink-dev/2l_G_apqk30/G0IsV3lEWNwJ
> [1]: https://w3c.github.io/mediacapture-record/MediaRecorder.html
> [2]: https://streams.spec.whatwg.org/

It does seem like a more pleasant interface.
Note that the congestion control mechanism of Streams is still based on
a pull model: A writer is supposed to notice that a reader isn't
reading, and make appropriate actions (which shouldn't involve occupying
all of memory with video that won't be read). This is the opposite way
round of the MediaRecorder model, where the blobs are produced no matter
what, and it's up to the Javascript to discard them.

The spec should probably say what is intended to happen in this case.
Received on Thursday, 13 August 2015 07:24:49 UTC

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