Issue metadata
Sign in to add a comment
|
MediaRecorder API throttling issue
Reported by
antonpri...@gmail.com,
Jan 4
|
||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Steps to reproduce the problem:
I'm using it to record the speech from the web page using Chrome, and save it as chunks. I need to be able to play it while and after it is recorded, so it's important to keep those chunks.
Here is the code which is recording data:
navigator.mediaDevices.getUserMedia({ audio: true, video: false }).then(function(stream) {
recorder = new MediaRecorder(stream, { mimeType: 'audio/webm; codecs="opus"' })
var previous_timecode = null
recorder.ondataavailable = function(e) {
duration = previous_timecode ? e.timecode - previous_timecode : null
previous_timecode = e.timecode
// Read blob from `e.data`, decode64 and send to sever;
// Additionally send the duration calculated from the events;
// Duration of first chunk is calculated in a different way.
}
recorder.start(1000)
})
What is the expected behavior?
What went wrong?
The issue actually happened only once, but still it is quite a scary one. The problem was that during 7 minutes of recording i got only 5 minutes of audio. Analyzing the chunks gave me the following input - at some point, the chunks became much smaller then they were expected to be - the data was emitted every second, but the duration of the chunks was arround 400-700ms.
The audio was correct, it did not have any gaps, it just came with a growing delay. At some points the duration of chunk was growing a bit - up 4.8sec in a chunk, but still the total delay grew up to ~2 min.
In the CSV attached you can see the durations of each chunk calculated with ffmpeg (size audio file containing first n chunks minus the size of file containing first n-1 chunks) and also the durations calculated by e.timecode values.
Did this work before? N/A
Chrome version: 71.0.3578.98 Channel: stable
OS Version: OS X 10.14.1
Flash Version:
It looks like some throttling issue - is there something like that in chrome? How could i fix my code to make sure it's not throttled that way?
,
Jan 5
,
Jan 7
,
Jan 7
antonpriadko@ thanks for filing the Issue. I wonder if the 7' recording being squeezed in 5' would not be a sampling frequency difference? Opus is configured to work at 48KHz sampling rate; we have an AudioConverter to adapt the input audio if different. Could you try forcing the getUserMedia() to sample at 48KHz? (Use the |sampleRate| parameter like in [3]). [1] https://cs.chromium.org/chromium/src/content/renderer/media_recorder/audio_track_opus_encoder.cc?sq=package:chromium&dr=CSs&g=0&l=24 [2] https://cs.chromium.org/chromium/src/content/renderer/media_recorder/audio_track_opus_encoder.cc?sq=package:chromium&dr=CSs&g=0&l=115 [3] https://addpipe.com/blog/audio-constraints-getusermedia/
,
Jan 7
Note that forcing |sampleRate| in getUserMedia() works only in M73 and later (currently Canary). However, the sample rate for a track can be obtained with the getSettings() method in older versions.
,
Jan 14
The NextAction date has arrived: 2019-01-14 |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, Jan 4