Closed Bug 1234230 Opened 7 years ago Closed 6 years ago

MediaRecorder video blob has blinking when recording both image and audio


(Core :: Audio/Video: Recording, defect, P1)

46 Branch



Tracking Status
firefox44 --- wontfix
firefox45 --- wontfix
firefox46 --- wontfix
firefox47 --- fixed


(Reporter: ladybenko, Assigned: jesup)



(Keywords: DevAdvocacy, regression)


(1 file)

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.
Keywords: DevAdvocacy
Rank: 15
Priority: -- → P1
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:
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
Flags: needinfo?(rjesup)
Flags: needinfo?(alwu)
OS: Mac OS X → All
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)
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)
Assignee: nobody → rjesup
(clearing NI).
Flags: needinfo?(padenot)
Flags: needinfo?(alwu)
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
See Also: → 1261007
You need to log in before you can comment on or make changes to this bug.