New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 813522 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Mar 2018
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

34.9%-41.4% regression in video_WebRtcPeerConnectionWithCamera.h264 at 33220001032000000:33430001038800000

Project Member Reported by asapersson@chromium.org, Feb 19 2018

Issue description

See the link to graphs below.
 
Project Member

Comment 1 by 42576172...@developer.gserviceaccount.com, Feb 19 2018

All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=813522

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=6bd8f58d62966c1d64d47c965203ff4b67b2328ac4ec18a71aebf83e36f9df8e


Bot(s) for this bug's original alert(s):

cros-nyan_blaze
Owner: phoglund@chromium.org
phoglund, can you have a look?
Status: WontFix (was: Untriaged)
There are 78 (!) WebRTC rolls in the range, Chromium changes notwithstanding. I'll add an OKR to find some way to deal with this insanity. I'll close this one for now. We're not that interested in the total number of frames anyway; we're more interested if all of them are black or frozen.
Cc: emir...@chromium.org
There seems to be another regression for this metric. phoglund@ can you explain what total num frames stand for and why we arent interested in that?

https://chromeperf.appspot.com/report?sid=c674a75c9ef6ee9d42fd0e75c8c4c24526a034dd56afa5ab34203dc499f9b7c7&start_rev=33190001030400000&end_rev=34040001061000000
total num frames = the number of frames analyzed during the test. The test has a fixed duration of 20 seconds, and frames are analyzed with 

setInterval(analyze_func, 20); 

function analyze_func() {
  ...
  this.totalNumFrames++;
}

So totalNumFrames is how many times analyze_func ran, and is only interesting when compared to num_black_frames or num_frozen_frames.

When I think of it, it would make more sense to not track totalNumFrames at all, but track percentage_black_frames instead (i.e. num_black_frames / num_frozen_frames).
Project Member

Comment 6 by bugdroid1@chromium.org, May 4 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/3ea606cb08875467ac4f3119371be98cedd57226

commit 3ea606cb08875467ac4f3119371be98cedd57226
Author: Patrik Höglund <phoglund@google.com>
Date: Fri May 04 10:02:50 2018

Change black frames and frozen frames to report percentages.

The total_num_frames metric isn't interesting on its own, only
in relation to frozen + black frames.

After landing: update WebRTC perf test information.

BUG= chromium:813522 
TEST=Not at all, didn't have a CrOS laptop configured.

Change-Id: I631dddf38646b5957cecc860cd603b10608f00db
Reviewed-on: https://chromium-review.googlesource.com/1034683
Commit-Ready: Patrik Höglund <phoglund@chromium.org>
Tested-by: Patrik Höglund <phoglund@chromium.org>
Reviewed-by: Kristoffer Erlandsson <kerl@google.com>

[modify] https://crrev.com/3ea606cb08875467ac4f3119371be98cedd57226/client/site_tests/video_WebRtcCamera/video_WebRtcCamera.py

Sign in to add a comment