When using MediaRecorder to record a stream of both video and audio, the resulting video blob contains glitches (it's blinking). See: https://jsfiddle.net/56eefo2x/7/ 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.
I wanted to report the same issue but I found this bug report first. The bug can also be seen here: https://simpl.info/mediarecorder/ 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: https://hypermeeting.paldeploy.com/mturk/firefox43.webm https://hypermeeting.paldeploy.com/mturk/firefox44.webm
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: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0a5b448cd09ea78e7ef930c3910b488ac27efebc&tochange=19400ffcf4695ae195d79770c9e7db574b558e66 #1 Regressed by: Bug 953265 #2 Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8d8eb725a4d977944fa4a660d5405fbcb26beb6b&tochange=cc01ca9f3dff6577aa0aaad1f3c68e0bdfa79760 #2 Regressed by: Bug 1218593
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
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)
Assignee: nobody → rjesup
Status: NEW → ASSIGNED
status-firefox44: affected → wontfix
status-firefox45: affected → wontfix
Attachment #8724756 - Flags: review?(roc) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox47: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla47
You need to log in before you can comment on or make changes to this bug.