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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg9NCisQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgtNLnoQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgtNL9vwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgtLe3uQoM


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

chromium-webrtc-rel-mac

I see bitrate is much higher than before. I am currently waiting for https://codereview.chromium.org/1818903004/ to address it.

 Issue 611398  has been merged into this issue.

After the latest changes- see  issue 597095  - it looks like goog_frame_rate_sent is fixed as it is stably on 30. However, the others are still different compared to before Hw encode. 

I don't have any explanation to why available_send_bw and available_recv_bw has went up from 2.6m to 3.0m. goog_jitter_buffer_ms and goog_target_delay_ms can be explained through the HW encoder behavior though.

I think this is caused by timestamp inaccuracy. For hardware encoding we end up using the system clock for timestamps instead of the camera driver value. This adds inaccuracy in two ways:
- The software clock is only accurate to 16ms
- We timestamp the frame after encoding, adding more jitter. 

One thing it doesn't explain is the bandwidth estimation change, holmer@ any ideas?

It might be explained by that the bitrate produced by the hw encoder varies more than the sw encoder. BWE will ramp-up to 1.5x the bitrate it receives, so assuming it receives 2 mbps at times, it will be able to ramp up to 3 mbps.

Does that sound like how you've seen it behave?

FYI there's finally a CL up for propagating the timestamp here, so hopefully that can land soon:

https://codereview.chromium.org/1996453003/

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

 Issue 615019  has been merged into this issue.

Re #9, I landed the CL to use correct timestamps for Mac here: https://codereview.chromium.org/2039423002/

However, looking at the bots, it doesn't seem like it made the expected difference in  goog_jitter_buffer_ms or goog_target_delay_ms.
https://chromeperf.appspot.com/group_report?bug_id=611392

Ping. The regression is not yet recovered. 

The correct timestamp usage got reverted here for all platforms: https://codereview.chromium.org/2071953003. I am waiting for it to see if goog_jitter_buffer_ms and goog_target_delay_ms values would change. 

goog_frame_rate_sent is back to stable 30 again. available_send_bw and available_recv_bw can be explained by the comment #8.

Any update on this?  The metrics have not recovered.

This issue has been moved once and is lower than Pri-1. Removing the milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

emircan: ping

goog_frame_rate_sent: Fixed.
available_send_bw and available_recv_bw: See comment #8. It is the expected behavior.
goog_jitter_buffer_ms and goog_target_delay_ms: See comment #7. This behavior might change when we fix the timestamp mismatch. https://codereview.chromium.org/2205623002/ is the CL to address it which is tracked on  issue 597087 . 

I landed the above CL to address the timestamp issue. Since then(08-26), the graphs started acting very inconsistently, see available_send_bw, available_recv_bw, goog_jitter_buffer_ms and goog_current_delay_ms.
https://chromeperf.appspot.com/group_report?bug_id=611392

kjellander@ would you have any idea why this might be happening.

With your CL (https://codereview.chromium.org/2205623002) many metrics start bouncing very randomly between builds (you have to move the mini-view window  to the right a lot in the initial report link to see this).
I really have no idea. The hardware has been the same and there are no machine changes that I'm aware of.

holmer: can you figure out why the perf values became so unstable?

I am going to revert that CL (and merge it to M54) to recover the stats. 

Perf sheriff ping

emircan@: did you revert that CL, and do the graphs (https://chromeperf.appspot.com/group_report?bug_id=611392) look how you expect them to?

I reverted that CL, see 641230. 

As I explained on #18, the metrics recovered except for the ones related to  issue 597087 . I will mark this one as fixed and continue tracking timestamp issue there.