New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 732552 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug



Sign in to add a comment

Handle zero timestamp in RTCVideoEncoder timestamp matching

Project Member Reported by emir...@chromium.org, Jun 12 2017

Issue description

We do not calculate googEncodeMs and googEncodeUsagePercent properly for tab/desktop capture when HW encoder is used due to:
- When using tab capture, timestamp of the first frame can be zero[0]. 
- When we are matching capture timestamp to RTP timestamp in RTCVideoEncoder, zero is used to indicate that HW encoder didn't preserve timestamp[1].

A quick fix would be to change default value from zero to base::TimeDelta::Max().

[0] https://cs.chromium.org/chromium/src/content/browser/media/capture/desktop_capture_device.cc?rcl=72b0661cd1fbc0297200f9ca88be19bdeb865508&l=346
[1] https://cs.chromium.org/chromium/src/content/renderer/media/gpu/rtc_video_encoder.cc?rcl=927ddf0ccfa6947292f0551c83e427822ac18045&l=515
 
Project Member

Comment 1 by bugdroid1@chromium.org, Jun 13 2017

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

commit 115c560f5886afd3c512d054c988439893974f24
Author: emircan <emircan@chromium.org>
Date: Tue Jun 13 19:34:38 2017

Handle zero timestamp in RTCVideoEncoder timestamp matching & add UMA

Desktop/tab capture can send zero as the first frame's capture timestamp. This CL
changes treating zero as the default timestamp to handle those cases.

If a platform doesn't preserve and return 0 as the timestamp, i.e. Android, the first
frame will be matched and calculated correctly. However, second value(which is
nonzero) will fail to match and stop.

Additionally, this CL adds a UMA to track the platforms and cases where this might
fail.

BUG= 732552 
TEST=Observed chrome://webrtc-internals metrics on guado using Hangouts
screenshare.

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

[modify] https://crrev.com/115c560f5886afd3c512d054c988439893974f24/content/renderer/media/gpu/rtc_video_encoder.cc
[modify] https://crrev.com/115c560f5886afd3c512d054c988439893974f24/tools/metrics/histograms/histograms.xml

Labels: M-60 M-61 Merge-Request-60
Project Member

Comment 3 by sheriffbot@chromium.org, Jun 14 2017

Labels: -Merge-Request-60 Hotlist-Merge-Review Merge-Review-60
This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Merge-Review-60 Merge-Rejected-60
Thanks for the fix - Can you please provide more details of why this is urgent for M60? We've already branched, so please specify why this is critical to be merged for M60. Rejecting merge for now, but please re-request if required.  
Labels: -Merge-Rejected-60 Merge-Request-60
Without this fix, googEncodeMs and googEncodeUsagePercent stats are broken for tab/desktop capture when HW encoder is used. This real time stats are tracked by webrtc internally and can be tracked by devs via chrome://webrtc-internals. It is a safe merge touching a very specific file, rtcvideoencoder.cc. Therefore, re-requesting merge again.
Project Member

Comment 6 by sheriffbot@chromium.org, Jun 14 2017

Labels: -Merge-Request-60 Merge-Review-60
This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Merge-Review-60 Merge-Approved-60
Thanks for details - based on comment 5, approving merge for M60. 
Status: Fixed (was: Started)
Project Member

Comment 9 by sheriffbot@chromium.org, Jun 20 2017

Cc: abdulsyed@chromium.org
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Merge-Approved-60 merge-merged-3112
Merge already done: https://codereview.chromium.org/2948623002/. It looks like the bot is lagging.

Sign in to add a comment