- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 13 Aug 2015 09:24:11 +0200
- 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