Issue metadata
Sign in to add a comment
|
New unsignaled video stream overwrites old previously unsignaled video stream |
||||||||||||||||||||||
Issue descriptionThe last VideoReceiveStream that was created as a default stream for an unsignaled SSRC may be destroyed by receiving an RTP packet on another SSRC that is unsignaled -- even if the first SSRC has been signaled since we received the first RTP packet for that stream. If this happens, the two SSRCs will compete for being the default stream, and neither will display rendered frames. This can happen in multiway calls that eagerly send RTP packets before the streams have been signaled. An example timeline is available in https://bugs.webrtc.org/7725. The regression was introduced in https://codereview.webrtc.org/2692993009, which went into M58. The fix landed in https://codereview.webrtc.org/2906893002, which was rolled into Chrome 61.0.3117.0. The fix has been verified in a multiway setting on a 61.0.3118.0 dev build.
,
Jun 9 2017
Please tag with appropriate OSs. Thanks.
,
Jun 9 2017
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
,
Jun 12 2017
,
Jun 12 2017
Issue 730022 has been merged into this issue.
,
Jun 13 2017
Issue webrtc:7567 has been merged into this issue.
,
Jun 13 2017
The fix has also been verified by an external party: https://bugs.chromium.org/p/webrtc/issues/detail?id=7725#c11
,
Jun 13 2017
Thanks for you all. I will follow this instead of issue 7225 .
,
Jun 14 2017
In my opinoin, this bug fixed can also be useful for following bugs: 1.https://bugs.chromium.org/p/webrtc/issues/detail?id=3476 One alternative solution for this bug is: when hold, remove ssrc; after resume, add ssrc. This solution must be based on this bug fixed to guarantee setsdp action success 2.https://bugs.chromium.org/p/webrtc/issues/detail?id=3563 I had tested in my infrastructure. Even the SRTP error can be avoided by adjust sequence number, the video still could not be rendered sometimes. The solution must be as 1
,
Jun 16 2017
@ brandtr@chromium.org @ deadbeef@chromium.org, Good morning. How about the progress to merge this fix into M60? JP
,
Jun 16 2017
Issue 718341 has been merged into this issue.
,
Jun 16 2017
+bustamante - do you know if this is being reviewed? It's not clear to me from reading the bug and I'm worried we may have missed a push.
,
Jun 18 2017
Approving merge to M60. Marked as a bug regression.
,
Jun 19 2017
@abdulsyed@chromium.org, Thank you very much. Which M60 version can we test in the future? Best Regards
,
Jun 20 2017
The merge (https://codereview.webrtc.org/2943343002/) has now landed on the WebRTC M60 branch: https://chromium.googlesource.com/external/webrtc/+/branch-heads/60. Not sure why the bugdroid hasn't updated here. It should be included in the next beta build.
,
Jun 20 2017
@brandtr@chromium.org, Great! Thank for your effort.
,
Jun 22 2017
@all, I downloaded and tested chrome 60.0.3112.40 beta （64 bit）. The bug is fixed. Thank all of you.
,
Jun 22 2017
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
,
Jun 26 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by brandtr@chromium.org
, Jun 9 2017