MediaRecorder video blob has blinking when recording both image and audio

RESOLVED FIXED in Firefox 47



3 years ago
3 years ago


(Reporter: ladybenko, Assigned: jesup)


({DevAdvocacy, regression})

46 Branch
DevAdvocacy, regression
Dependency tree / graph

Firefox Tracking Flags

(firefox44 wontfix, firefox45 wontfix, firefox46 wontfix, firefox47 fixed)



(1 attachment)



3 years ago
When using MediaRecorder to record a stream of both video and audio, the resulting video blob contains glitches (it's blinking).


When recording video only, (asking for just video in getUserMedia) this does not happen.

Also, if the getUserMedia stream is piped to a videotag and we wait till the loadedmetadata event before starting the recording, the video blob is fine.

I'm not sure if this is a bug, but it's somehow counter-intuitive that I don't need to wait for loadedmetadata when recording video only, but I have to when recording both audio and video.


3 years ago
Keywords: DevAdvocacy
Rank: 15
Priority: -- → P1

Comment 1

3 years ago
I wanted to report the same issue but I found this bug report first.  The bug can also be seen here:

In Firefox 43, everything worked fine.  In Firefox 44, it doesn't work on some systems.  Downgrading to Firefox 43 makes it work again.  Rebooting, refreshing settings, uninstall and reinstall of FF 44, using a different user has no effect.

I tried it on four systems running Windows 7.  The two that failed have a Logitech C920 webcam.  Here are sample recordings from before and after the upgrade to FF 44:
Keywords: regressionwindow-wanted

Comment 2

3 years ago
There are 2 regression window,
#1, flicker with very high rate(5-10Hz in my feeling)
#2, slightly improved, but flicker with low rate(2-3 Hz in my feeling)

#1 Regression window:

#1 Regressed by: Bug 953265

#2 Regression window:

#2 Regressed by: Bug 1218593
Blocks: 953265, 1218593
status-firefox44: --- → affected
status-firefox45: --- → affected
status-firefox47: --- → affected
Flags: needinfo?(rjesup)
Flags: needinfo?(alwu)
Keywords: regressionwindow-wanted → regression
OS: Mac OS X → All

Comment 3

3 years ago
Via local build:
Last Good: aa7c3ce047ad
First Bad: 0cf3e430dc22

Regressed by: 0cf3e430dc22	Randell Jesup — Bug 953265: Update webrtc/getUserMedia default audio capture rate to 32KHz r=padenot
Flags: needinfo?(padenot)

Comment 4

3 years ago
Created attachment 8724756 [details] [diff] [review]
Don't pass null images for video encoding, and don't reencode the same image

The proximate cause for the flashing was apparently null frames due to blocking.  While I see them in both working and non-working tests, timings and durations are different and this appears to be timing sensitive.  (For example I didn't see the regression at the 16->32KHz landing.)    Note this patch may cause frames to be encoded with start times slightly earlier than they should be; correcting this as noted in the comment requires either delaying encoding by a frame, or passing in a timestamp instead of a duration.  This should be handled in a followup bug, as we want this patch to uplift to 46.  Nice side-effect - this may improve quality by avoiding re-encoding the same image multiple times.  (Note: borrows heavily from OMXEncoder, which also implies we could remove some duplication in the future.)  In local testing, the flashing is gone with this.
Attachment #8724756 - Flags: review?(roc)


3 years ago
Assignee: nobody → rjesup


3 years ago
status-firefox44: affected → wontfix
status-firefox45: affected → wontfix
Flags: needinfo?(rjesup)
(clearing NI).
Flags: needinfo?(padenot)


3 years ago
Flags: needinfo?(alwu)

Comment 7

3 years ago
Last Resolved: 3 years ago
status-firefox47: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
See Also: → bug 1261007
status-firefox46: affected → wontfix
You need to log in before you can comment on or make changes to this bug.