Rendering WebRTC simulcast from RTCVideoEncoder freezes between simulcast layers. |
|||||
Issue descriptionRTCVideoEncoder does not propagate RTP timestamps properly for encoded video frames, and as such whenever switching between simulcast layers there's a large timestamp gap that causes the incoming stream to freeze (timestamps look like they're either too far ahead or too far behind the previous frame). Ideally RTCVideoEncoder would propagate these timestamps, but even so, when there's a large timestamp gap it would seem reasonable that the receiver resets quickly and consider this to be a new stream. Anecdotally/for some weird reason rendering resumes whenever I force the tab to re-render (by resizing the window or switching tabs).
,
Mar 28 2017
,
Mar 28 2017
Note that RTP timestamps from RTCVideoEncoder should be working now: https://bugs.chromium.org/p/chromium/issues/detail?id=597087#c34
,
Mar 28 2017
Thanks! FWIW: I think it might still make sense to "fix" the receiver in the case that these issues happen with other implementations or other versions, or if a sender completely restarts (reload tab) but reuses the same SSRC with a new random timestamp.
,
Apr 19 2017
The following revision refers to this bug: https://chromium.googlesource.com/external/webrtc.git/+/067121ab3f97f949a1480502e8a57f11b63a7b35 commit 067121ab3f97f949a1480502e8a57f11b63a7b35 Author: qiangchen <qiangchen@chromium.org> Date: Wed Apr 19 16:57:37 2017 Bug Fix: WebRTC Receiver Timestamp Jump Detection RTCVideoEncoder does not propagate RTP timestamps properly for encoded video frames, and as such whenever switching between simulcast layers there's a large timestamp gap that causes the incoming stream to freeze (timestamps look like they're either too far ahead or too far behind the previous frame). Ideally RTCVideoEncoder would propagate these timestamps, but even so, when there's a large timestamp gap it would seem reasonable that the receiver resets quickly and consider this to be a new stream. This CL detects the large jump for timestamps, if that happens, we reset the time extrapolator, which is the class for convertion from RTP timestamp to clock time. BUG= chromium:705679 Review-Url: https://codereview.webrtc.org/2776813002 Cr-Commit-Position: refs/heads/master@{#17770} [modify] https://crrev.com/067121ab3f97f949a1480502e8a57f11b63a7b35/webrtc/system_wrappers/source/timestamp_extrapolator.cc
,
Apr 24 2017
Bumping to M60 (since the CL in #5 landed in M60). Please correct if that's wrong.
,
Apr 24 2017
,
May 19 2017
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by mflodman@chromium.org
, Mar 28 2017