MediaStreamRecorder bitrate configuration does not work
Reported by
jnor...@hirevue.com,
Apr 21 2016
|
||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.86 Safari/537.36 Example URL: https://webrtc.github.io/samples/src/content/getusermedia/record/ Steps to reproduce the problem: 1. Go to the above URL. 2. Put a breakpoint in this code: function startRecording() { var options = {mimeType: 'video/webm'}; recordedBlobs = []; try { mediaRecorder = new MediaRecorder(window.stream, options); // BREAKPOINT HERE 3. Start recording; breakpoint will be hit 4. In the console, type: options.videoBitsPerSecond = 120000 options.audioBitsPerSecond = 120000 5. Continue execution 6. After a bit of time, hit stop recording, and download the file What is the expected behavior? The file has a bitrate that is roughly ~240 kbps What went wrong? The file actually has an _extremely_ high bitrate; much higher than had I actually specified nothing at all. This can be observed by remuxing the file with ffmpeg ("ffmpeg -i input.webm -c:v copy -c:a copy output.webm") and then examining the bitrate with ffprobe ("ffprobe output.webm"), or just computing the bitrate based on file size. The test I did resulted in a bitrate of roughly ~4.8 mbit/sec for a VGA clip. I've attached that file here. Had I specified nothing, I would have had a file with a bitrate around 1 mbit/sec. Did this work before? N/A Is it a problem with Flash or HTML5? HTML5 Does this work in other browsers? N/A Chrome version: 50.0.2661.86 Channel: stable OS Version: OS X 10.9.5 Flash Version: Shockwave Flash 21.0 r0 I've also tried setting the bitrate via MediaRecorder.videoBitsPerSecond/MediaRecorder.audioBitsPerSecond; that doesn't appear to do anything.
,
Apr 21 2016
Oh, I should also mention I tried in Canary; same result.
,
Apr 22 2016
Adding proper label and Cc'ing mcasas@ for help in investigating this further. Thank you!
,
Apr 22 2016
I'm not positive, but I think the issue is in video_track_recorder.cc:
if (bits_per_second_ > 0) {
codec_config_.rc_target_bitrate = bits_per_second_;
} else {
codec_config_.rc_target_bitrate = size.GetArea() *
codec_config_.rc_target_bitrate /
codec_config_.g_w / codec_config_.g_h;
}
However, reading the VP9 documentation, http://www.webmproject.org/docs/webm-sdk/structvpx__codec__enc__cfg.html#ab8339685175d66710f482706cc9f0aed , rc_target_bitrate is in *kilobits*, which would explain why I'm getting massive file sizes.
I tested this code, and it correctly creates a file that's roughly the size I would expect:
if (bits_per_second_ > 0) {
codec_config_.rc_target_bitrate = bits_per_second_ / 1000;
} else {
codec_config_.rc_target_bitrate = size.GetArea() *
codec_config_.rc_target_bitrate /
codec_config_.g_w / codec_config_.g_h;
}
,
Apr 22 2016
Also, one other question: assuming ^^^ is the bug, what's the possibility of hoisting this to Chrome 50? Without the ability to set bitrate, it makes it really hard to make small recordings for screen sharing, so it's going to seriously hurt my ability to use this feature.
,
Apr 22 2016
jnoring@ good analysis. First, note that in [1] the bitrates are clamped and checked for consistency, so keep that in mind if you go for settings |bitsPerSecond| in the options dictionary. Also note that the bitrates must be set before creating the MediaRecorder. You probably know those things, but is good to mention just in case. On #4, this is probably the case. Could you make a CL and upload for review? See [2] for the process. Note that you might need to add your name to the AUTHORS file (see the Legal lines in [3]. M50 is in stable right now so only uber important security fixes could be landed AFAIK. If your CL would land, it'd be in M52 and could be merged back to M51. [1] https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/modules/mediarecorder/MediaRecorder.cpp&sq=package:chromium&type=cs&q=mediarecorder.cpp&l=52 [2] https://www.chromium.org/developers/contributing-code#TOC-Create-a-change-list-CL- [3] https://www.chromium.org/developers/contributing-code#TOC-Get-your-code-ready
,
Apr 22 2016
Okay, I've taken my first stab at a CL: https://codereview.chromium.org/1913233002/ I probably did _something_ wrong so apologies in advance. Thank you so much for the prompt reply, @mcasas!
,
Apr 23 2016
mcasas@ I believe my CL was approved? What's the process for that getting into Canary, and potentially getting it on 51? Thanks again for all your help, hugely appreciated.
,
Apr 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0a58e7128c0559027991ae4671fb7b16274b7ba3 commit 0a58e7128c0559027991ae4671fb7b16274b7ba3 Author: jnoring <jnoring@hirevue.com> Date: Mon Apr 25 03:15:04 2016 Fix MediaRecorder bitrate configuration bug The MediaRecorder API specifies that bitrates be communicated in bits per second, which is correctly plumbed through Chrome. However, VPx encoders expect its arguments to be specified in kilobits per second. This resulted in specifying any bitrate via the javascript API to be off by a thousand, resulting in enormous files. Change it so we convert bits -> kilobits by dividing by 1000 BUG= 605750 R=mcasas@chromium.org Review URL: https://codereview.chromium.org/1913233002 Cr-Commit-Position: refs/heads/master@{#389411} [modify] https://crrev.com/0a58e7128c0559027991ae4671fb7b16274b7ba3/AUTHORS [modify] https://crrev.com/0a58e7128c0559027991ae4671fb7b16274b7ba3/content/renderer/media/video_track_recorder.cc
,
Apr 25 2016
jnoring@ could you please confirm that the change works in the latest Canary? If so, I can request the merge back to M51 since is a small patch with limited risk.
,
Apr 25 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0a58e7128c0559027991ae4671fb7b16274b7ba3 commit 0a58e7128c0559027991ae4671fb7b16274b7ba3 Author: jnoring <jnoring@hirevue.com> Date: Mon Apr 25 03:15:04 2016 Fix MediaRecorder bitrate configuration bug The MediaRecorder API specifies that bitrates be communicated in bits per second, which is correctly plumbed through Chrome. However, VPx encoders expect its arguments to be specified in kilobits per second. This resulted in specifying any bitrate via the javascript API to be off by a thousand, resulting in enormous files. Change it so we convert bits -> kilobits by dividing by 1000 BUG= 605750 R=mcasas@chromium.org Review URL: https://codereview.chromium.org/1913233002 Cr-Commit-Position: refs/heads/master@{#389411} [modify] https://crrev.com/0a58e7128c0559027991ae4671fb7b16274b7ba3/AUTHORS [modify] https://crrev.com/0a58e7128c0559027991ae4671fb7b16274b7ba3/content/renderer/media/video_track_recorder.cc
,
Apr 25 2016
mcasas@ yes, I'll confirm tomorrow when Canary is updated; I must have missed the nightly build for today.
,
Apr 26 2016
Okay, it appears fixed in Canary. I've attached a file that correctly recorded at roughly ~251 kbit/sec after setting the bitrate on audio and video.
,
Apr 26 2016
mcasas@, do you need me to do anything to help get this into 51?
,
Apr 26 2016
thanks jnoring@ I'll take the merge back (it's easy if you're a committer).
,
Apr 26 2016
Your change meets the bar and is auto-approved for M51 (branch: 2704)
,
Apr 26 2016
Please merge your change before 5:00 PM PST today to M51 branch 2704, so we can take it for this week beta. Thank you.
,
Apr 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/60b153f48f8581bc4a781a2d9fa22efdbbedad02 commit 60b153f48f8581bc4a781a2d9fa22efdbbedad02 Author: mcasas <mcasas@google.com> Date: Tue Apr 26 21:27:56 2016 Fix MediaRecorder bitrate configuration bug The MediaRecorder API specifies that bitrates be communicated in bits per second, which is correctly plumbed through Chrome. However, VPx encoders expect its arguments to be specified in kilobits per second. This resulted in specifying any bitrate via the javascript API to be off by a thousand, resulting in enormous files. Change it so we convert bits -> kilobits by dividing by 1000 BUG= 605750 R=mcasas@chromium.org Review URL: https://codereview.chromium.org/1913233002 Cr-Commit-Position: refs/heads/master@{#389411} (cherry picked from commit 0a58e7128c0559027991ae4671fb7b16274b7ba3) NOTRY=true NOPRESUBMIT=true Review URL: https://codereview.chromium.org/1925443002 Cr-Commit-Position: refs/branch-heads/2704@{#253} Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251} [modify] https://crrev.com/60b153f48f8581bc4a781a2d9fa22efdbbedad02/AUTHORS [modify] https://crrev.com/60b153f48f8581bc4a781a2d9fa22efdbbedad02/content/renderer/media/video_track_recorder.cc
,
Apr 29 2016
,
May 24 2016
Renamed component Blink>MediaStreamRecording to Blink>MediaStream>Recording. Moving issues to the new component.
,
Jan 18 2017
,
Jan 18 2017
|
||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||
Comment 1 by jnor...@hirevue.com
, Apr 21 2016