Issue metadata
Sign in to add a comment
|
MediaRecorder is producing audio files of an incorrect duration (regression)
Reported by
douggerh...@gmail.com,
Nov 21 2017
|
||||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Steps to reproduce the problem:
1. Make a MediaRecorder audio recording, of type webm/opus
2. Note the actual duration of the recording
3. Play the audio file back in Chrome, or decode to wav with ffmpeg
What is the expected behavior?
Audio file duration matches recorded time duration.
What went wrong?
In some cases, the duration of the audio file produced by MediaRecorder is incorrect.
In one example we've documented of this bug, our recording's expected duration is 1517473ms (25:17), while the actual file decodes to a duration of 1651680ms (27:32). The ratio of these two duration values is 0.918745, which is so close to the ratio you get when you divide 44.1kHz by 48kHz (0.91875) that I can't imagine it's a coincidence.
Did this work before? Yes 61.0.3163.100
Does this work in other browsers? Yes
Chrome version: 62.0.3202.94 Channel: stable
OS Version: Windows NT 10.0; Win64; x64
Flash Version:
In the cases where we're seeing this happen, the users in question produced files without trouble on M61, and have only seen this begin to occur since upgrading to M62.
In both cases (M61 and M62) the same computer and recording hardware (an M-Audio FastTrack) was used.
Here's a quick simplified version of how we're using MediaRecorder:
var streamOptions = {
mandatory: {
googEchoCancellation: false,
googAutoGainControl: false,
googNoiseSuppression: false,
googHighpassFilter: false,
sourceId: "default" // mic device ID goes here
}
};
var mediaRecorderOptions = {
audioBitsPerSecond : 96000,
mimeType: "audio/webm;codecs=opus"
};
var dsMediaRecorder;
navigator.webkitGetUserMedia({audio: streamOptions}, function(stream) {
dsMediaRecorder = new MediaRecorder(stream, mediaRecorderOptions);
dsMediaRecorder.ondataavailable = function(event) {
console.log(event.timecode);
// store event.timecode
// store event.data
};
dsMediaRecorder.onerror = function(event) {
throw event;
};
// later
dsMediaRecorder.start(5000);
}, function(e) {
throw e;
});
,
Nov 22 2017
,
Nov 22 2017
douggerhardt@ do you see a corresponding distortion in the recorded audio? E.g. a lower pitch corresponding to the sampling rate mismatch?
,
Nov 22 2017
mcasas@: No, we're seeing no change to the pitch. Sorry, I should have mentioned that. Using ffmpeg to dump to wav and then running something like the following command: $ sox recording.wav recording.fixed.wav stretch 0.91875 Restores the recording to the correct expected duration and the playback then syncs up as we'd expect it to. We've been trying to do our best to isolate this more, and it appears that another wrinkle is that this only seems to happen when the user is *also* on a WebRTC voice call in the same tab; if they record without a live concurrent call, it produces a recording file that matches its expected duration, and if they record while on a call, even very short (37s) recordings exhibit this behaviour. In the case of the 37s recording, it plays back over 40s (37/0.91875). My presumption is that the user's hardware is being resampled by Chrome from 44.1kHz to 48kHz; we're going to see if they can change the sample rate in hardware to 48kHz and if that changes anything.
,
Nov 23 2017
guidou@: how's a MediaStreamAudioTrack different when plugged into a
remote PeerConnection vs simply capturing? Can the sampling frequency
of the audio MediaStreamTrack from 44.1kHz (without the MediaRecorder
sink being told?
douggerhardt@ - if you could repro consistently, an idea would be to
try disabling fancy getUserMedia() constraints - that might be enabled
without you knowing -, in particular echoCancellation [1], sampleRate [2],
etc, something looking like:
await navigator.mediaDevices.getUserMedia({advanced: [{echoCancellation: {exact: false}}]});
[1] https://developer.mozilla.org/en-US/docs/Web/API/MediaTrackConstraints/echoCancellation
[2] https://developer.mozilla.org/en-US/docs/Web/API/MediaTrackConstraints/sampleRate
,
Nov 23 2017
mcasas@: Thanks, we do seem to have one specific user in the wild that sees this occur consistently, so we'll try disabling those constraints for them and see what happens there.
,
Nov 28 2017
guidou@ ping
,
Nov 29 2017
Sorry for the delay. AFAIK, the MediaStreamAudioTrack is unmodified after being plugged to a peer connection. The audio from the track is put into 10ms chunks before being passed to WebRTC but that is performed by the sink that writes to WebRTC. The track itself should not be affected.
,
Dec 8 2017
cc olka since she has looked at other weird sample rate issues.
,
Dec 13 2017
I noticed what I believe is the same issue when recording videos with MediaRecorder. Whenever I had some heavy js running during recording I got distorted audio in the resulting file. I made a reduced repro script. 1. Open the page, allow mic and cam access. 2. Click record, make some sound and click Compute to hog the main thread. 3. Click stop. The resulting video plays back with no sound gaps. 4. Click download and play that file in something other than Chrome - Vlc, Firefox etc. The sound distorts/stops when main thread was hogged. I also ran the resulting audio through opusinfo utility and got warnings like these, which directed me to this current discussion: WARNING: Sample count ahead of granule (146880>146832) in stream 1 WARNING: Sample count ahead of granule (195840>195792) in stream 1 WARNING: Sample count behind granule (204480<268848) in stream 1 WARNING: Sample count ahead of granule (319680>319632) in stream 1 WARNING: Sample count ahead of granule (417600>417552) in stream 1 WARNING: Sample count ahead of granule (466560>466512) in stream 1 My Chrome version is Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36 If I run the same test in Firefox (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:58.0) Gecko/20100101 Firefox/58.0) I have no problems with sound.
,
Dec 18 2017
[Triage] Guido, assigning to you. Please decide on next steps or re-assign to a suitable owner.
,
Dec 19 2017
douggerhardt@gmail.com: Can you provide a jsfiddle or similar to reproduce the problem?
,
Dec 19 2017
guidou@chromium.org Am I better filing another bug with my related case or it will be looked at as well here?
,
Dec 19 2017
w0rse.t@gmail.com: file another bug unless you're 100% sure it's the same as this one. We can always mark it as duplicate of this one.
,
Dec 19 2017
guidou@: Unfortunately this only occurs on some machines, and while we've seen it in the wild, we can't repro internally. That said, on machines where this occurs, it happens every time since upgrading to 62.
,
Dec 20 2017
douggerhardt@ Is there anything special about those systems where it's 100% reproducible? Do they use a special sound card, USB or bluetooth headset, are they some old OS version -- anything like that?
,
Jul 31
,
Sep 3
The NextAction date has arrived: 2018-09-03
,
Jan 8
Merging into Issue 796474 after reading https://bugs.chromium.org/p/chromium/issues/detail?id=796474#c12 |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by hongchan@chromium.org
, Nov 21 2017Components: Blink>MediaRecording