- From: Ashley Gullen <ashley@scirra.com>
- Date: Thu, 12 Mar 2015 09:09:04 +0000
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-media-capture@w3.org
- Message-ID: <CAABs73gi4UQuMejvim8==LPfu0cXBteyzO4zC_ztBKHCiQYaXg@mail.gmail.com>
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