Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2933213003:
Handle zero timestamp in RTCVideoEncoder timestamp matching & add UMA (Closed)
|
Created:
3 years, 6 months ago by emircan Modified:
3 years, 6 months ago CC:
chromium-reviews, mlamouri+watch-content_chromium.org, posciak+watch_chromium.org, jam, feature-media-reviews_chromium.org, darin-cc_chromium.org, asvitkine+watch_chromium.org, piman+watch_chromium.org Target Ref:
refs/heads/master Project:
chromium Visibility:
Public. |
DescriptionHandle 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}
Committed: https://chromium.googlesource.com/chromium/src/+/115c560f5886afd3c512d054c988439893974f24
Patch Set 1 #
Total comments: 2
Patch Set 2 : #
Messages
Total messages: 23 (17 generated)
The CQ bit was checked by emircan@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== timestamps. BUG= ========== to ========== Handle zero timestamp in RTCVideoEncoder timestamp matching 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 ==========
emircan@chromium.org changed reviewers: + pbos@chromium.org
emircan@chromium.org changed reviewers: + asvitkine@chromium.org
pbos@ PTAL at rtc_video_encoder changes. asvitkine@ PTAL at UMA usage.
Description was changed from ========== Handle zero timestamp in RTCVideoEncoder timestamp matching 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 ========== to ========== Handle zero timestamp in RTCVideoEncoder timestamp matching 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 metric on guado using Hangouts screenshare. ==========
Description was changed from ========== Handle zero timestamp in RTCVideoEncoder timestamp matching 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 metric on guado using Hangouts screenshare. ========== to ========== Handle zero timestamp in RTCVideoEncoder timestamp matching 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. ==========
Description was changed from ========== Handle zero timestamp in RTCVideoEncoder timestamp matching 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. ========== to ========== 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. ==========
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
lgtm https://codereview.chromium.org/2933213003/diff/1/tools/metrics/histograms/hi... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/2933213003/diff/1/tools/metrics/histograms/hi... tools/metrics/histograms/histograms.xml:29560: + video encoder session. Expand description to mention when it's logged (looks like when the session is destroyed/ended).
lgtm
The CQ bit was checked by emircan@chromium.org to run a CQ dry run
https://codereview.chromium.org/2933213003/diff/1/tools/metrics/histograms/hi... File tools/metrics/histograms/histograms.xml (right): https://codereview.chromium.org/2933213003/diff/1/tools/metrics/histograms/hi... tools/metrics/histograms/histograms.xml:29560: + video encoder session. On 2017/06/13 15:15:36, Alexei Svitkine (slow) wrote: > Expand description to mention when it's logged (looks like when the session is > destroyed/ended). Done.
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by emircan@chromium.org
The CQ bit was checked by emircan@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from asvitkine@chromium.org, pbos@chromium.org Link to the patchset: https://codereview.chromium.org/2933213003/#ps20001 (title: " ")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 20001, "attempt_start_ts": 1497376843695440,
"parent_rev": "aee671743ba1c7bc1cb08d691ab4f64500aefc56", "commit_rev":
"115c560f5886afd3c512d054c988439893974f24"}
Message was sent while issue was closed.
Description was changed from ========== 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. ========== to ========== 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} Committed: https://chromium.googlesource.com/chromium/src/+/115c560f5886afd3c512d054c988... ==========
Message was sent while issue was closed.
Committed patchset #2 (id:20001) as https://chromium.googlesource.com/chromium/src/+/115c560f5886afd3c512d054c988... |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
