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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg8N_nowoM


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

webrtc-linux-large-tests

brandtr@: This regression seems related to flexfec. Do you know what CL could have caused it?

This seems to be a H264 on Linux regression, not related to FlexFEC. See the graphs here: https://chromeperf.appspot.com/report?sid=79538484f6034b498822bd148ec88e50afe34e433a93ea04695e5df79f888646. The decode_time changes for all H264 tests at around the same revision, but only on Linux.

The alert is on a Chromium roll, which includes this CL: https://codereview.chromium.org/2651183003. "Reland of Add assembly for x86 to OpenH264 encoder".

(Do the mac/win bots use HW encoders, and therefore we don't see the regression there?)

hta@: Would you mind taking a look at this alert? Is the regression expected?

I added several improvements to this bug that triggered on the same revision.

OpenH264 is only used for encoding, not decoding, so this test (which looks to be decode-only) should not have been affected.

Needs to be looked at by someone who understands the test; it's possible that OpenH264 with assembly produces files that are slower to decode than what's produced w/o assembly, but that would be bizarre.