Re: An updated MediaRecorder proposal based on streams

I must emphasise again that MediaRecorder needs to work faster than
real-time for several significant use cases. For example "bouncing" (mixing
down) a multi-track recording in a DAW, or transcoding audio, are
effectively useless at real-time speed (consider working with 1 hr worth of
material in these cases). AFAIK MediaStream can run only in real-time. I
had heard Mozilla were considering passing MediaRecorder an AudioNode from
the Web Audio API such that you could render an OfflineAudioContext in to a
MediaRecorder at faster-than-realtime, which would cover this nicely.
However this would require updating the spec to allow for this case and not
assume that there is always a MediaStream present.

For a "MediaRecorder v2" proposal, I strongly feel faster-than-realtime
recording is an essential requirement.

Ashley



On 12 August 2015 at 21:28, Domenic Denicola <d@domenic.me> wrote:

> 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 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/
>
>