1234230 - MediaRecorder video blob has blinking when recording both image and audio

Status: RESOLVED FIXED

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

Description

[Belén [:ladybenko]]

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.

Comment 1

[Andreas Girgensohn]

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

Comment 2

[Alice0775 White]

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

Comment 3

[Alice0775 White]

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

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Attachment: 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.

Comment 5

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0ac27aa6a4d8

Comment 6

[Paul Adenot (:padenot)]

(clearing NI).

Comment 7

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/0ac27aa6a4d8