1427577 - [webrtc] video_receive_ssrcs_ would be corrupted when firefox received more than 2 video streams which led firefox crashed

Status: RESOLVED DUPLICATE of bug 1479853

(Core :: WebRTC: Networking, defect)

Description

[david]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171226083017

Steps to reproduce:

1) Three firefox  endpoints(let's say A/B/C) joined in the same meeting using bundle sdp
2) A&B send their own video stream,and C receives two video streams.seems to be good so far.
3) Then let C quit the conference ,and C crashes
The crash cause by  RTC_CHECK(receive_stream_impl != nullptr); which in Call.cc Line 692


Actual results:

Then let C quit the conference ,and C crashes.
The crash was caused by  RTC_CHECK(receive_stream_impl != nullptr); which in Call.cc Line 692 when call DestroyVideoReceiveStream.
I review the code ,there should be two recv streams in C when join in the meeting  but seems that firefox will call SetRemoteSSRC again which will modify recv stream in video_receive_ssrcs_ .and when C quit the meeting ,there is no corresponding recv stream,and it cause the RTC-check failed.


Expected results:

There should be no crash when more than 2 firefox join the meeting.

Comment 1

[david]

PS,if there more than 2 recv streams,firefox will recv 2 ssrcs in rtp packets ,and sometimes firefox maybe will misjudge that there is a SSRC change case ,so recall the setRemoteSSRC to recreate the recv stream

Comment 2

[Dan Minor [:dminor]]

David, Thank you for your report! I wasn't able to reproduce your crash when I tried just now. I was wondering if you would mind trying to reproduce it again on your end and let me know if you still see it. If so, it would be helpful if you could let us know the service you were using (if any) when it crashed and if you could attach the log from about:webrtc to this bug. Thanks!

Comment 3

[david]

Dan，this case was not reproduced all the time but indeed it still happened at my side particular when C endpoint quit the meeting. 

I use unified plan(bundle peerconnection) to receive multistream in firefox means there are two video M lines in SDP.
When C join the meeting ,it will create two video streams which indicated by ssrs-A and ssrc-B when call .It is OK to construct this two receive streams using setRemoteDescription and storged ssrc informations in video_receive_ssrcs_ map(Call::CreateVideoReceiveStream).
The problem is that when firefox C begin to receive RTP data from A and B(WebrtcVideoConduit::ReceivedRTPPacket),basically one recv stream must receive only one ssrc stream (like ssrc-A or ssrc-B) but sometime  recv stream A will receive ssrc-B rtp data(I guess ) so firefox C think there is a ssrc change case happened ,and it delivered to main thread to update the video_receive_ssrcs_ map which will corrupted the video_receive_ssrcs_ map
when C quit the meeting ,it will call Call::DestroyVideoReceiveStream and RTC_CHECK(receive_stream_impl != nullptr) happened.
I dont know if I have descripted this case clearly。

Comment 4

[david]

Yes,this issue was related to ssrc switching and would likely re-create the VideoReceiveStream which corrupted the initial recv stream.

Comment 5

[david]

(In reply to david from comment #4)
> Yes,this issue was related to ssrc switching and would likely re-create the
> VideoReceiveStream which corrupted the initial recv stream.
with bundle sdp that use the same RTP session

Comment 6

[david]

Thanks for your information,Nils,So how can we deal with this problem next step?At least we don't want this RTC_CHECK failed for our products

Comment 7

[david]

Or do you have plans to solve this issue?

Comment 8

[Nils Ohlmeier [:drno]]

Actually it would be interesting if bug 1394602 fixes your issue. If you are up to it you can either download the try build binaries from that bug report your self, or I can provide the download links here so you can give it a try.

Comment 9

[david]

OK, Nils,could you kindly provide download links ?thanks

Comment 10

[Andreas Pehrson [:pehrsons]]

The treeherder link to that try run is https://treeherder.mozilla.org/#/jobs?repo=try&revision=c997d8271ec5aad747267dbc7263a882a7fe0094

For a Windows x64 build you could try [1], the link is also among the artifacts on the job on [2] (job details tab).

[1] https://queue.taskcluster.net/v1/task/WIo6l2OvQM28dOxiRJU1XQ/runs/0/artifacts/public/build/target.zip
[2] https://treeherder.mozilla.org/#/jobs?repo=try&revision=c997d8271ec5aad747267dbc7263a882a7fe0094&selectedJob=170463741