Issue metadata
Sign in to add a comment
|
2.6%-16.7% regression in webrtc_perf_tests at 13191:13193 |
||||||||||||||||||||
Issue descriptionThere was a fairly sharp perf (but not dramatic) regression in the screenshare stats, with dropped frames increasing from ~18 to ~21 on nexus5 and encode usage increasing from ~35.8% to ~36.7% on windows. The change was blamed on https://chromium.googlesource.com/external/webrtc/+/57c21f9b44621b6415d81d353923eb3975276703 by the perf alerts, so I'm assigning to Per for a closer look. The nearby Chromium roll (including some libvpx change) https://chromium.googlesource.com/external/webrtc/+/0dbc8bfbe52af4699714108d875adcdd8543d63c appears to be outside the range that could possibly cause the regression (but I didn't dig very deep into that).
,
Jun 27 2016
,
Jun 27 2016
Discussed with sprang. These tests are apparently timing sensitive. My cl move the call to start the encoder from one thread to the encoder thread and might change the timing a bit. The observed performance numbers are so small that timing explains the change. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by terelius@chromium.org
, Jun 20 2016