New issue
Advanced search Search tips

Issue 919041 link

Starred by 2 users

Issue metadata

Status: Unconfirmed
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: 2019-01-14
OS: Mac
Pri: 2
Type: Bug



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?
 
1.csv
11.5 KB View Download
Components: -Blink Blink>GetUserMedia
Labels: Needs-Triage-M71
Components: -Blink>GetUserMedia Blink>MediaRecording
Cc: guidou@chromium.org
Labels: Needs-Feedback
NextAction: 2019-01-14
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/
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.
The NextAction date has arrived: 2019-01-14

Sign in to add a comment