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

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


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

chromium-webrtc-rel-mac

emircan@: This regression looks related to your CL https://codereview.chromium.org/2205623002. Could you please take a look to see whether that makes sense!

Yes, it is expected to fix some stats, see  issue 597087 . 

I reopened this since there were many other stat changes for this CL, including many related to BWE. 
emircan@: Could you have another look if those stat changes are also expected?

Thanks for bringing up again ivoc@. Yesterday, I found there is some issue re new timestamps usage in Mac H264 HW encoder. That would explain the changes in BWE stats. I am working on a fix now, and will merge to M54 as well. Also, I am updating bug title.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/eb436ddb8b313a81e758b5c5f97ca4349b5203a0

commit eb436ddb8b313a81e758b5c5f97ca4349b5203a0
Author: emircan <emircan@chromium.org>
Date: Wed Aug 31 21:14:18 2016

Revert of Use webrtc::VideoFrame timestamp in RTCVideoEncoder (patchset #7 id:260001 of https://codereview.chromium.org/2205623002/ )

Reason for revert:
This CL caused some regressions regarding BWE stats and HW encoder
performance. Reasons include:
1) Modifying scoped_refptr<media::VideoFrame>'s timestamp causes problems
for other clients using the same media::VideoFrame.
2) WebRTC's RTP timestamp isn't suitable for using as presentation timestamp
in Mac and Win HW encoders.

BUG= 641230 

Original issue's description:
> Use webrtc::VideoFrame timestamp in RTCVideoEncoder
>
> This CL fixes input timestamp mismatch in RTCVideoEncoder, which
> broke googAvgEncodeMs and googEncodeUsagePercent stats in webrtc-internals
> for hardware encoders.
> With this change, we start using WebRTC given timestamp() so that
> OveruseFrameDetector can match the timestamps and calculate the stats.
>
> BUG= 597087 
> TEST=googAvgEncodeMs and googEncodeUsagePercent works on Mac(H264) and
> veyron_jerry(VP8).
>
> Committed: https://crrev.com/e3195490a63d9545fb1bfe560aa21680ba0b5843
> Cr-Commit-Position: refs/heads/master@{#414589}

TBR=wuchengli@chromium.org,pbos@chromium.org,posciak@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 597087 

Review-Url: https://codereview.chromium.org/2296273002
Cr-Commit-Position: refs/heads/master@{#415752}

[modify] https://crrev.com/eb436ddb8b313a81e758b5c5f97ca4349b5203a0/content/renderer/media/gpu/rtc_video_encoder.cc
[modify] https://crrev.com/eb436ddb8b313a81e758b5c5f97ca4349b5203a0/media/gpu/video_encode_accelerator_unittest.cc

Adding a merge request for the revert as this patch made it to the M54 branch.

Re-opening to track the merge.

Your change meets the bar and is auto-approved for M54 (branch: 2840)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/21605fd6c714fb6b6b48cd64bd5b96b7e95f8e66

commit 21605fd6c714fb6b6b48cd64bd5b96b7e95f8e66
Author: emircan <emircan@chromium.org>
Date: Thu Sep 01 21:33:08 2016

Revert of Use webrtc::VideoFrame timestamp in RTCVideoEncoder (patchset #7 id:260001 of https://codereview.chromium.org/2205623002/ )

Reason for revert:
This CL caused some regressions regarding BWE stats and HW encoder
performance. Reasons include:
1) Modifying scoped_refptr<media::VideoFrame>'s timestamp causes problems
for other clients using the same media::VideoFrame.
2) WebRTC's RTP timestamp isn't suitable for using as presentation timestamp
in Mac and Win HW encoders.

BUG= 641230 

Original issue's description:
> Use webrtc::VideoFrame timestamp in RTCVideoEncoder
>
> This CL fixes input timestamp mismatch in RTCVideoEncoder, which
> broke googAvgEncodeMs and googEncodeUsagePercent stats in webrtc-internals
> for hardware encoders.
> With this change, we start using WebRTC given timestamp() so that
> OveruseFrameDetector can match the timestamps and calculate the stats.
>
> BUG= 597087 
> TEST=googAvgEncodeMs and googEncodeUsagePercent works on Mac(H264) and
> veyron_jerry(VP8).
>
> Committed: https://crrev.com/e3195490a63d9545fb1bfe560aa21680ba0b5843
> Cr-Commit-Position: refs/heads/master@{#414589}

TBR=wuchengli@chromium.org,pbos@chromium.org,posciak@chromium.org
BUG= 597087 

Review-Url: https://codereview.chromium.org/2296273002
Cr-Commit-Position: refs/heads/master@{#415752}
(cherry picked from commit eb436ddb8b313a81e758b5c5f97ca4349b5203a0)

NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2303053002
Cr-Commit-Position: refs/branch-heads/2840@{#110}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/21605fd6c714fb6b6b48cd64bd5b96b7e95f8e66/content/renderer/media/gpu/rtc_video_encoder.cc
[modify] https://crrev.com/21605fd6c714fb6b6b48cd64bd5b96b7e95f8e66/media/gpu/video_encode_accelerator_unittest.cc

emircan@ - Is there any manual test steps available to verify this issue ?
If yes, then please provide the steps to verify it from chrome-Te team.

Thanks

krajshree@, I don't think there is any manual tests for this. We can check these graphs to see that they recovered: https://chromeperf.appspot.com/group_report?bug_id=641230

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/21605fd6c714fb6b6b48cd64bd5b96b7e95f8e66

commit 21605fd6c714fb6b6b48cd64bd5b96b7e95f8e66
Author: emircan <emircan@chromium.org>
Date: Thu Sep 01 21:33:08 2016

Revert of Use webrtc::VideoFrame timestamp in RTCVideoEncoder (patchset #7 id:260001 of https://codereview.chromium.org/2205623002/ )

Reason for revert:
This CL caused some regressions regarding BWE stats and HW encoder
performance. Reasons include:
1) Modifying scoped_refptr<media::VideoFrame>'s timestamp causes problems
for other clients using the same media::VideoFrame.
2) WebRTC's RTP timestamp isn't suitable for using as presentation timestamp
in Mac and Win HW encoders.

BUG= 641230 

Original issue's description:
> Use webrtc::VideoFrame timestamp in RTCVideoEncoder
>
> This CL fixes input timestamp mismatch in RTCVideoEncoder, which
> broke googAvgEncodeMs and googEncodeUsagePercent stats in webrtc-internals
> for hardware encoders.
> With this change, we start using WebRTC given timestamp() so that
> OveruseFrameDetector can match the timestamps and calculate the stats.
>
> BUG= 597087 
> TEST=googAvgEncodeMs and googEncodeUsagePercent works on Mac(H264) and
> veyron_jerry(VP8).
>
> Committed: https://crrev.com/e3195490a63d9545fb1bfe560aa21680ba0b5843
> Cr-Commit-Position: refs/heads/master@{#414589}

TBR=wuchengli@chromium.org,pbos@chromium.org,posciak@chromium.org
BUG= 597087 

Review-Url: https://codereview.chromium.org/2296273002
Cr-Commit-Position: refs/heads/master@{#415752}
(cherry picked from commit eb436ddb8b313a81e758b5c5f97ca4349b5203a0)

NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2303053002
Cr-Commit-Position: refs/branch-heads/2840@{#110}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/21605fd6c714fb6b6b48cd64bd5b96b7e95f8e66/content/renderer/media/gpu/rtc_video_encoder.cc
[modify] https://crrev.com/21605fd6c714fb6b6b48cd64bd5b96b7e95f8e66/media/gpu/video_encode_accelerator_unittest.cc