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

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


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

chromium-webrtc-trunk-tot-rel-linux

I'm not sure if this is expected. On one hand, I do see stats from the video_rx_H264 bot for some stats, such as goog_current_delay_ms [1]. But on the other hand, I see that even some VP8 goog_max_decode_ms graphs have also flatlined [2].

Sending to hbos@ since this is related to H.264.

[1] https://chromeperf.appspot.com/report?sid=8fa6d8881a8f1a1605d3ac8b9f3a26ecd6978abe723aeefdf958fc825966f827

[2] https://chromeperf.appspot.com/report?sid=a658c8461716a376e6ef24ab3a71f64edf18a3cc0b8b2550866a8e8a54f3797f

The goog_decode_ms is consistently < 2 ms but that varies as expected. Why goog_max_decode_ms went from varying to constant I don't know.

@phoglund: What is goog_max_decode_ms a measurement of?

"Maximum observed frame decode latency."

Source: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc/media/base/mediachannel.h&sq=package:chromium&type=cs&l=738&rcl=1459308500

In the graph linked by tnakamura@ goog_max_decode_ms is always larger than any goog_decode_ms.

Nevermind, but I don't see how the referenced commit range for that data point could have affected this and no webrtc roll. Is the commit range by the graph accurate?
https://chromium.googlesource.com/chromium/src/+log/fd44bb77461947a94342a4ee2e1289097372104e%5E..3990015776de6cd5f1a0e13d5708e3d8079f55ea?pretty=fuller

I think I'm speaking too soon, I'll get back when I've looked at this more carefully.

No activity in a while - is the bug still valid?

ping

The graph, both before and after the reported regression, is consistently almost flat at 2 ms, with the occasional 1-3 ms spike/dip.

During the year that the graph spans there are 3 periods of higher and spikier decode times that last for a few days, with alerts at the beginning and end of those periods.

Going back from the spiky higher decode time to the more consistent ~2 ms decode time looks like a regression has been fixed, not caused. What happened I don't know, none of the CLs look related.

Since I don't know what happened one year ago (that's how old this bug is) and it looks like it is working as intended, I'm closing this bug.