Streamed canvas video jitters when compared to the original canvas object [use to be smooth] |
|||||||||
Issue descriptionChrome Version: 65.0.3325.65 / 10323.30.0 Yuna, Soraka, zako, Tricky, reks OS: Chrome OS (Maybe possible in all chrome devices) Not reproducible in 65.0.3325.51 gLinux, M64 64.0.3282.140 Macbook pro (stable) What steps will reproduce the problem? Open https://webrtc.github.io/samples/src/content/capture/canvas-video/ Click and drag on the canvas (on the left) to move the teapot. What is the expected result? Verify that the video element on the right moves in the same pattern as the canvas element and smooth. What happens instead? Video element on the right is slightly slower than the one on the left. It use to be very smooth and move in parallel with the canvas on the left. p.s: It was working fine in M63. After M64 this is observed. First time this issue was observed is in M64. 10176.41.0 / 64.0.3282.79 Enguarde, Blaze, Stout It is a low priority bug but nice to have it fixed.
,
Feb 14 2018
vasanthakumar@: Does the bug reproduce reliably? If so, can you try bisecting it?
,
Feb 15 2018
Yes it is reproduced every time. Sure I will bisect and update the status soon.
,
Feb 15 2018
Hi Guidou, I am not able to reproduce till now in older versions. I tried to flash all the following builds in Yuna device. Thus its not a regression I guess. Not reproducible in 63.0.3239.140 10032.86.0 Not reproducible in 63.0.3239.116 10032.75.0 Not reproducible in 63.0.3239.26 10032.21.0 62.03202.101 9901.79.0 60.0.3112.101 9592.82.0
,
Feb 19 2018
,
Feb 20 2018
,
Feb 20 2018
vasanthakumar@ based on #4, did you conclude that this isn't a regression? Do you see the flicker in those versions listed as well?
,
Feb 20 2018
Ye I have concluded that it is not a regression. I probably misunderstood that behavior from MacOS or Linux. This is observed only in Chrome OS.
,
Feb 21 2018
If it is not a regression, considering that these are old CrOs device, I am thinking this might be an expected result of the high workload. WebGL, capture, encode and decode happens at the same time on this page. Can you try this other example page? Press "Create Stream ..." and then "Play back ..." to see the performance. This page skips the peer connection altogether. https://cdn.rawgit.com/uysalere/js-demos/master/canvascaptureopaque.html
,
Feb 22 2018
@Emircan: Thanks for your input. I have tried the same in chromebox [Panther] and a chrome book [Candy]. (Both with M65 65.0.3325.65 / 10323.30.0) Chrombox have the delay as mentioned in this ticket, whereas Candy works quite well. Note: Candy is fairly a weak device. Specs: 1. Candy CPU: Intel(R) Celeron(R) CPU N2840 @ 2.16GHz ( x86_64architecture - 2 processors ) Memory: 4.05GB 2. Panther: CPU: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz ( x86_64architecture - 4 processors ) Memory: 4.08GB Kindly share your thoughts on it.
,
Apr 13 2018
Ping! This issue is reproducible in three devices (Link, Leon, and Lars). This is not reproducible in Peach. Chrome Version: 67.0.3383.0 / 10539.0.0
,
Apr 13 2018
I havent tested on these devices but I have CL which should help with this: https://chromium-review.googlesource.com/c/chromium/src/+/1000149
,
May 5 2018
https://chromium-review.googlesource.com/c/chromium/src/+/1000149 landed. issue 824752 was also about lag, but only on CrOS. vasanthakumar@ can you see if that helped? Overall, we don't have any particular code that differentiates between CrOS device families. I am not sure what you mean by jitter in -Link, Leon, and Lars- vs. Peach. We do not see any regression in the canvas capture test running on Lars, so I think performance has always been this way. https://chromeperf.appspot.com/report?sid=94c23e5ccc97ac0e32ab5f2b5048693cd02ac687b70702769f4850658f4bb590
,
May 7 2018
Thanks Emircan. I have verified the issue in 68.0.3421.0 / 10651.0.0 in Leon. The above CL managed to fix the issue. We can close this ticket now. Thanks a lot! |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by vasanthakumar@chromium.org
, Feb 14 2018