[e10s](canvas.captureStream) Dropped frames in recording when the window is blurred

NEW
Unassigned

Status

()

P3
normal
Rank:
15
2 years ago
a month ago

People

(Reporter: tristan.fraipont, Unassigned)

Tracking

({regression, stale-bug})

51 Branch
x86
Mac OS X
regression, stale-bug
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
Created attachment 8843650 [details]
Complete example + static image exporting

MediaRecorder drops frames when the main window looses focus (e.g when we switch to an other tab).

This looks like it has the same limitations as requestAnimationFrame about this.

In the attached example, the canvas animation is ticked to an audioContext based timer (which is not limited by this focus issue).

When we loose focus, the Recorder drops the frames, even when stream.requestFrame is manually called. However, if we call canvas.toBlob(), we can see that all the frames are presented and rendered on the canvas, but somehow they're not passed to the recorder.


Note :
- Since chrome has fixed this bug (https://bugs.chromium.org/p/chromium/issues/detail?id=653548) it does work for them.

- I am pretty sure it did work on beta channel around november of 2016, however I was unable to find a working release with moz-regression...

A minimal version can be found here : https://jsfiddle.net/qnzz47pw/
(Reporter)

Comment 1

2 years ago
Created attachment 8843651 [details]
Output video
Note, only the fiddle in comment 0 reproduces for me (OSX). The attachment is always silky smooth, no framedrops!

Furthermore, the fiddle problem seems e10s related. If I open a new non-e10s window then it works fine.

I tried as far back as 2016-07-12 (which is as far as mozregression successfully run builds for me for some reason), which puts it at 51, and with e10s it's broken, and with non-e10s it works. This might explain why you saw it working in a beta, but couldn't find a regression range.

The Chrome bug you reference seems different, not producing any frames at all.
Has STR: --- → yes
Rank: 15
Flags: needinfo?(tristan.fraipont)
Keywords: regression
Priority: -- → P1
Summary: (canvas.captureStream) Dropped frames in recording when the window is blurred → [e10s](canvas.captureStream) Dropped frames in recording when the window is blurred
Version: 54 Branch → 51 Branch
Flags: needinfo?(tristan.fraipont)
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 3

2 years ago
Yes e10s seems to be the trouble-maker.  
I disabled it and the number of dropped frames considerably lowered. (I still have some though)

Also if I pointed to the not directly related chrome bug, it's because in their current stable version, this bug makes it impossible to test, while in canary, with shipped fix, we can see it works smoothly.
This is a P1 bug without an assignee. 

P1 are bugs which are being worked on for the current release cycle/iteration/sprint. 

If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.
Keywords: stale-bug
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.