Re: Transcoding audio with MediaRecorder

I'm not sure MediaStreamTracks need to be able to run at any speed other
than real-time - for faster processing, OfflineAudioContext already exists
to serve that need, but that cannot feed in to a media stream. In fact it
produces an AudioBuffer after rendering (the same thing you get after
decoding an audio file). As long as MediaRecorder can take an AudioBuffer
instead of a stream, that should solve this use case. On the other hand I'd
imagine making streams run at different rates would be a complex project to
both spec and implement.

Ashley


On 12 March 2015 at 06:59, Harald Alvestrand <harald@alvestrand.no> wrote:

> On 03/12/2015 12:29 AM, Ashley Gullen wrote:
> > I have been experimenting with Firefox's Web Audio (decoding) and
> > MediaRecorder (encoding) APIs to transcode audio between formats, such
> > as transcoding a .wav file to Opus in the browser. A file can be
> > decoded with the Web Audio context's decodeAudioData, and the
> > resulting buffer connected to a media stream destination node, whose
> > stream can be recorded with MediaRecorder.
> >
> > The big problem is this can only transcode audio in real-time. For a
> > tool based on this to be useful, it should be able to transcode as
> > fast as it can. This suggests the use of an OfflineAudioContext, but
> > these cannot create media stream destination nodes (at least in
> > Firefox, when I tried). It's not clear to me, but I get the impression
> > a MediaStream is a real-time stream and cannot go faster-than-realtime
> > anyway.
> >
> > Does there need to be a new API to enable this?
>
> At the moment, the MediaStreamTrack concept doesn't offer any time
> manipulation; it is assumed to run in real time, or as close to it as
> synchronization can manage.
>
> Allowing a MediaStreamTrack to run in another time mode is an
> interesting idea - it would, at a minimum, require access to the
> implicit clocks of the media stream - but I don't think we have any
> chartered work items that look at this issue at this time.
>
> Haral
>
>
>

Received on Thursday, 12 March 2015 09:09:32 UTC