Improve TestVideoDisplayPerf* metrics |
||
Issue descriptionhttps://chromeperf.appspot.com/report?sid=c8f0993eedc9f49dda5b70ef7607e58e0ae23ed0ce706a2933b1d04e80d10b24 These tests are running fine and catching regressions, but there are some issues that can improve: - We should try to narrow the range for "Total Controlled Latency". - We should specify if lower or higher is better for accurate alerts. - Win bots don't have GPUMemoryBuffer capabilities which local tests seem to have. sadrul@ can I get your help on defining "Total Controlled Latency" boundaries? I am thinking of this as the time we have active code running regardless of vsync interval and expect consistent results. For instance, render algorithm holds onto the frame coming from the network until the vsync interval is up and UpdateCurrentFrame() is called. I define that interval as "Render Algorithm Latency" and it expectedly has a wide range. I exclude that from "Total Controlled Latency" time. Time between "VideoResourceUpdater::ObtainFrameResources" and "Display::DrawAndSwap" is defined as "Vsync Latency". ObtainFrameResources() is triggered by WillDraw() and I expected it to be close to vsync interval. Although I thought this time should be consistent as it is preparing similar compositor resources, the results show that it jumps between 200 μs and 1400 μs, see the graph linked above. Is that expected? Is there a subset of this portion which I can track and expect to be consistent, or should I just expect this to be random as well and exclude from my "Total Controlled Latency" sum?
,
Apr 17 2018
Swapping me out for nednguyen@, who has a lot more context about this area of the code.
,
Apr 17 2018
My understanding is: VideoResourceUpdater::ObtainFrameResources() happens in the renderer process, and Display::DrawAndSwap() happens in the browser process (or in the gpu-process for viz/OOP-D). So issues like ipc-delay, queueing-delay on the receiving end, etc. can affect the latency numbers here.
,
Apr 18 2018
sadrul@, thanks for taking a look. I also followed the path to verify that. VideoLayerImpl::WillDraw() and Display::DrawAndSwap() has different stacks: cc::Scheduler::OnBeginImplFrameDeadline() and viz::DisplayScheduler::OnBeginFrameDeadline(). However, this is a page with only a <video> element in html. I would expect this to be at least a narrow range, but 200 μs to 1400 μs is significant difference. Is it worth looking into what is causing this? Are there others who might have input? Also, I am still not sure if I should take this time out of "Total Controlled Latency". It would be worth tracking if Chrome improves/regresses in this portion, but the results being so random is a blocker for that. charliea@ thanks for forwarding.
,
May 11 2018
Additional item: we should test with set playout-delay extension used.
,
May 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0335ee276b38e02265d5f2dbb2e85d948c4c69e5 commit 0335ee276b38e02265d5f2dbb2e85d948c4c69e5 Author: Emircan Uysaler <emircan@chromium.org> Date: Wed May 23 19:06:50 2018 Add disable smoothness case to WebRtcVideoDisplayPerfBrowserTest When playout-delay is set to 0, we disable render smoothness algorithm. This CL add that case to the tests. Bug: 833635 Change-Id: I2b4bd95af311b1522754fe9291f306b8c77d8d97 Reviewed-on: https://chromium-review.googlesource.com/1066680 Reviewed-by: Dan Sanders <sandersd@chromium.org> Commit-Queue: Emircan Uysaler <emircan@chromium.org> Cr-Commit-Position: refs/heads/master@{#561190} [modify] https://crrev.com/0335ee276b38e02265d5f2dbb2e85d948c4c69e5/chrome/browser/media/webrtc/webrtc_video_display_perf_browsertest.cc |
||
►
Sign in to add a comment |
||
Comment 1 by emir...@chromium.org
, Apr 16 2018