bug: RTSP stream redirect broken from [1.4.0-beta.6]

[mc-nugget]

Bug description

Switching to core 1.4.0-beta.6 or later kills a working RTSP stream redirect. Switching back to cores 1.2.6, 1.3.1, 1.4.0-beta.3, 1.4.0-beta.5 restores function.

Cam: Very common Dahua IP camera, H264, 5FPS, 1080p, VBR.
Stream URL: rtsp://admin:[email protected]/cam/realmonitor?channel=1&subtype=0
Hardware: Pi 3B, Pi 4 (both tested and fail)

Steps to reproduce

1. Open WebRTC dev UI
2. Add consumer
3. Select TCP only allow protocols
4. Add session for Dahua IP cam redirect

Output with 1.4.0-beta.6 or later:

Status: Session Id arrived: 50911271-595d-48c7-b3fd-1803eaa259c3
Status: Signaller connection closed
Status: Reconnecting to signalling server on ws://10.9.3.3:6021/
Status: Signaller connection closed

Output with 1.4.0-beta.5 or earlier

Status: Session Id arrived: edd926b6-44d7-4da1-88bf-872a8412e705

Primary pain point(s)

No response

Additional context

No response

Prerequisites

• I have checked to make sure that a similar request has not already been filed or fixed.

[joaoantoniocardoso]

Hi, thanks for reporting.

From 1.4.0-beta.5 to 1.4.0-beta.6, mavlink-camera-manager was updated from "t3.16.1" to "t3.17.0" (PR, full changelog).

The initial suspects are:

• mavlink/mavlink-camera-manager@804e37f
• mavlink/mavlink-camera-manager@0f985bd
• mavlink/mavlink-camera-manager@7220e28

I don't have a dahua camera, but I'll try to reproduce it here with the ones I have. If you know how to code in Rust, feel free to play with those commits, maybe reverting those three, since you are not using h265?

Thanks

[joaoantoniocardoso]

Hi @mc-nugget, after failing, could you open chrome://webrtc-internals and copy the "setRemoteDescription" offer's output?

Thanks!

[mc-nugget]

Sure, here it is:

{"type":"offer","sdp":"v=0\r\no=- 519485858869528962 0 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=ice-options:trickle\r\na=group:BUNDLE video0\r\nm=video 9 UDP/TLS/RTP/SAVPF 96 97\r\nc=IN IP4 0.0.0.0\r\na=setup:actpass\r\na=ice-ufrag:jGnq+bogAuDhCzf2n22p9LqLwn2bDN81\r\na=ice-pwd:XUo0bSUnDp0CIMmO4S71mZ9FNA3QC8Z+\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=sendonly\r\na=rtpmap:96 H264/90000\r\na=rtcp-fb:96 nack\r\na=rtcp-fb:96 nack pli\r\na=rtcp-fb:96 ccm fir\r\na=rtcp-fb:96 transport-cc\r\na=packetization-supported:DH\r\na=rtppayload-supported:DH\r\na=x-packetization-supported:IV\r\na=x-rtppayload-supported:IV\r\na=x-summary:Oversea\r\na=framerate:1.000000\r\na=recvonly\r\na=fmtp:96 sprop-parameter-sets=Z01AKKaAeAIn5ZuAgICgAAADACAAAAMAUIAA,aO48gAA=;packetization-mode=1;profile-level-id=42e01f;level-asymmetry-allowed=1\r\na=rtpmap:97 rtx/90000\r\na=fmtp:97 apt=96\r\na=ssrc-group:FID 707343139 970363269\r\na=ssrc:707343139 msid:user3903318780@host-f714b01c webrtctransceiver0\r\na=ssrc:707343139 cname:user3903318780@host-f714b01c\r\na=ssrc:970363269 msid:user3903318780@host-f714b01c webrtctransceiver0\r\na=ssrc:970363269 cname:user3903318780@host-f714b01c\r\na=mid:video0\r\na=fingerprint:sha-256 D8:00:F4:80:5B:2E:16:A9:45:88:AC:A7:02:53:D1:D5:2E:86:9B:41:8D:8F:A9:7C:2C:C0:40:82:43:A7:95:12\r\na=rtcp-mux-only\r\n"}

[joaoantoniocardoso]

Okay, thanks! I have a camera that produces a similar one, and I fixed it yesterday. The master branch is patched, can you download it and test it?

[joaoantoniocardoso]

Hi @mc-nugget, the current BlueOs master is now patched, can you test it?

If it fails, can you provide as much information as you can from chrome://webrtc-internals, as well as the BlueOs system logs?

Thanks!

[mc-nugget]

Master works. Thanks so much!

[joaoantoniocardoso]

Fixed by #3027.