Issue metadata
Sign in to add a comment
|
A zero-to-nonzero to 5.4% regression in webrtc_perf_tests at 11921:11921 |
||||||||||||||||||||
Issue descriptionThere is a regression in the webrtc_perf_tests time_between_rendered_frames/screenshare_slides_vp9_2sl...
,
Mar 10 2016
A likely CL that caused this could be https://codereview.webrtc.org/1773743002. Reassigning to tkchin@
,
Mar 10 2016
,
Mar 10 2016
The above CL link was the wrong one. Reassigning back to peah@
,
Mar 10 2016
Reassigning to pbos@ Could you please have a look to see whether this could be related to https://codereview.webrtc.org/1780543003
,
Mar 11 2016
Not related, the code isn't hit in those tests. marpan@ the suspect CL rolls a new libvpx from Chromium, can you take a look?
,
Mar 11 2016
,
Mar 12 2016
It looks like a regression/bug in libvpx regarding scene/slide change detection, which got into the roll mentioned in #7. A fix has been merged into libvpx and should be rolled in next week. Will monitor the graphs after the roll.
,
Mar 12 2016
The issue only affects vp9 under screensharing.
,
Mar 18 2016
This still hasn't recovered, though none of the individual pages appear to have regressed at all. Filed infrastructure issue here: https://github.com/catapult-project/catapult/issues/2151
,
Mar 18 2016
Resolution to the infra bug: The reason why bisect is disabled for those tests is because we don't have bisect bots set up to run the WebRTC perf tests. screenshare_slides_vp9_2sl isn't an aggregate of the other series listed in the legend in those graphs.
,
Mar 25 2016
marpan, re comment 8: graphs do seem much improved. Should this be marked fixed?
,
Mar 25 2016
Yes the improvement corresponds to the libvpx fix rolled into chromium this week. Should be marked as fixed.
,
Mar 25 2016
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by peah@chromium.org
, Mar 10 2016