Issue metadata
Sign in to add a comment
|
38.2% improvement in webrtc_perf_tests at 18976:18976 |
||||||||||||||||||||
Issue descriptionChromium roll caused all kind of improvements and regressions around. 6 days later another chromium roll reverted all the changes. Original roll with improvements: https://chromium.googlesource.com/external/webrtc/+/f1f9889c447d33dac25bfcfea0cc99f8cc817af0 Revert happened at: https://chromium.googlesource.com/external/webrtc/+/cfd3c327a8660a990a7fdd9d38f7366393cf40f0 Anyone have any idea, what happened?
,
Jul 18 2017
It's especially sad, because it was like magic: increased psnr, reduced encode and decode time, reduced cpu usage.
,
Jul 18 2017
Can we bisect?
,
Jul 18 2017
Re 3#: Do you mean rolling parts of chromium roll? Do you know how to do it in the easiest way?
,
Jul 18 2017
ah, hmm... not sure how to do that. Perhaps kjellander@ could help?
,
Aug 16 2017
We don't have bisection support for the perf tests in client.webrtc.perf waterfall (i.e. standalone WebRTC perf tests). Only Chromium Perf waterfalls has bisection support (and can do it into rolls as well). In this case, I don't think we should spend time on this if it recovered. As we were seeing both regressions and improvements I would guess there were something wrong that traded quality for bandwidth or similar. I suggest we close this. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by 42576172...@developer.gserviceaccount.com
, Jul 18 2017