captureStream/MediaRecorder causes canvas drawImage stalling on Chrome 66 OS X
Reported by
kwin...@gmail.com,
May 9 2018
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36 Steps to reproduce the problem: 1. create a canvas 2. begin drawing to the canvas every 1/CANVAS_DRAW_FRAMERATE milliseconds 3. use canvas.captureStream(CANVAS_GRAB_FRAMERATE) to get a stream 4. pass the stream to new MediaRecorder() What is the expected behavior? The canvas should update at approximately the expected framerate. What went wrong? On Mac OS X, if CANVAS_DRAW_FRAMERATE is less than approximately triple CANVAS_GRAB_FRAMERATE, timing of the draws to the canvas are noticeably jittery. In other words, some of the draw calls appear to fail to actually happen. The problem is worse, the lower the draw framerate. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 66.0.3359.139 Channel: stable OS Version: 10.12.6 Flash Version: Note that it is not actually necessary to call mediaRecorderInstance.start(). This sample code does call start() so that it is possible to examine the output of the MediaRecorder, in addition to visually examining the canvas on the web page. In every instance we have looked at, the output of MediaRecorder appears to match what we think we saw while watching the canvas live. This bug appears to be worst on OS X, but also appears to be present on Windows. This test case does not show the bug on Windows -- but in our production application we see jittery frame rates on Windows in Chrome 66 that we did not see in Chrome 65. This bug does not manifest on any of our Linux machines. Our current workaround for our production application is to set CANVAS_DRAW_FRAMERATE to 75 and CANVAS_GRAB_FRAMERATE to 25. In other words, we are rendering to the canvas at 75 fps and recording at 25 fps. Previously, we were rendering at 40 fps and recording at 30 fps. Live test page https://kwindla.github.io/mediarecorder-test/ Click on [ record from canvas ] to see the bug Click on [ record directly from camera ] to see a smooth framerate both on canvas and in video file On the live test page, CANVAS_GRAB_FRAMERATE is 30 and CANVAS_DRAW_FRAMERATE is 20. Source of live test page https://github.com/kwindla/mediarecorder-test
,
May 10 2018
,
May 10 2018
,
May 10 2018
I can reproduce this on 66.0.3359.139 but not on the latest canary. Can you try this on the latest canary? Also, canvas.captureStream(CANVAS_GRAB_FRAMERATE) isn't necessarily the exact frame rate canvas will be captured. It is more like maximum possible frame rate. i.e. if you have captureStream(1), it means there will be maximum 1 frame captured within 1 seconds. If you are drawing to the page with setTimeout(1), but for some reason setTimeout events are a little jittery and 0.95s apart, the second frame will not be captured. This implementation is spelled out in the draft below, take a look at |frameRequestRate| sections. https://w3c.github.io/mediacapture-fromelement/#html-canvas-element-media-capture-extensions
,
May 11 2018
kwindla@ Thanks for the issue. Tested this issue on Mac OS 10.12.6 on the reported version 66.0.3359.139 by following the below steps. 1. Launched Chrome and navigated to https://kwindla.github.io/mediarecorder-test/. 2. Opened Devtools on the page and clicked on 'record from canvas'. 3. Can observe that the recording has started and stopped and the webm file is downloaded to the system. Request you to check and confirm if these are the right steps to reproduce the issue. Also request you to provide the screen cast, details of the issue seen and the expected output which will help us in better understanding and triaging of the issue. Thanks..
,
May 15 2018
Emir, thank you for the additional information about framerate behavior. Makes sense. I have just tested on the latest canary (68.0.3431.0) and the framerate looks good.
,
May 15 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 15 2018
Hi Susan, thank you for trying to reproduce. The issue is with the visible framerate of both the on-screen canvas and the recorded webm file. The bug is that the framerate is very, very low on Chrome 66 on OS 10. Here is a screencast showing the low frame rate on Chrome 66.0.3359.139. In this case we get approximately 2 updates to the canvas over the course of 10 seconds. (The recorded/downloaded webm file when played back looks exactly like the canvas, as well, of course.) https://www.useloom.com/share/5c9fba1db0ff4353b78f0f1648bafbaa Here is a screencast of the same sequence on the same machine, but recorded on Chrome 65.0.3325.181. This shows the expected framerate: https://www.useloom.com/share/6ac5217668ae4c4486e85c07ce418649 Please let me know if you need any more information. As noted above, this issue does appear to be fixed in the latest Canary.
,
May 15 2018
,
Jun 7 2018
[bulk-edit: disregard if N/A] Can the owner please set milestone to this bug if applicable? |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by krajshree@chromium.org
, May 10 2018