[jitsi-dev] [jitsi/jitsi-videobridge] Jitsi videobridge will not send video to a client joining with video `recvonly` (#222)


#1

We have the option in our app of joining with video muted, which actually turns off the camera. This all works great if you're the first one to join, but if you join *after* someone else, you never receive video for existing persons.

For clarity, in both scenarios: Alice joins with audio and video, but Charlie joines with audio, but no video

**Scenario 1**
This first webrtc-internals dump is from reproducing the problem the problem:
[webrtc_internals_dump-jitsi-bad.txt](https://github.com/jitsi/jitsi-videobridge/files/221522/webrtc_internals_dump-jitsi-bad.txt)

**Steps: **

1. join the conference with a user (Alice) in audio and video (sendrecv for both)
2. join a second user (Charlie) to the conference with audio (sendrecv) but no video (recvonly)

**Expected result: **

Charlie will receive video

**Observed result: **

Charlie never receives video

**Scenario 2**
This second webrtc-internals dump is from a similar scenario to step 1, but users joining in reverse

[webrtc_internals_dump-jitsi-bad-2.txt](https://github.com/jitsi/jitsi-videobridge/files/221523/webrtc_internals_dump-jitsi-bad-2.txt)

**Steps: **

1. join a user (Charlie) to the conference with audio (sendrecv) but no video (recvonly)
2. join a second user to the conference with a user (Alice) in audio and video (sendrecv for both)

**Expected and observed result: **

Charlie receives video

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/222


#2

This is the simplest example. It has other negative consequences like not being able to join users to conferences if they don't have a camera, or in *listen only* mode, i.e., they have no camera or mic.

The most significant bug here is that the incoming stream has audio and video tracks, but there are no packets received on the video track, so when attached to a video element in the DOM, chrome refuses to play it, waiting for video packets to keep audio and video in sync, so the hacky workaround is to manually remove the incoming video track from the stream in order to get the audio to play.

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/222#issuecomment-210578973


#3

Have you checked that the bridge doesn't send packets for the video stream, or do you just observe that the client fails to render them?

I suspect that this is due to RTCP from the receive-only client not reaching the sender. The receive-only client's setLocalDescription doesn't contain an SSRC, so it will use a default value ("1", I believe, unless this changed) for RTCP reports. Lacking any signaled SSRC the bridge will not be able to demux RTCP packets from the receiver and will drop them. You can check whether this is the case by having another send-receive client join the conference in your Scenario 1. As soon as this happens, Charlie should start rendering both remote videos.

If my suspicion is correct there is not much we can do in the bridge (we could log a warning if we detect such a scenario, I suppose). We solve it In Jitsi-Meet by always including an SSRC in setLocalDescription, even when in receive-only mode. There was a long discussion somewhere on github, but I can't find it right now.

···

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/222#issuecomment-210742622


#4

@bgrozev How would I signal that from a focus controller, or would I have to mangle the SDP on the client before they join?

···

---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/222#issuecomment-219540778


#5

The solution we use in jitsi-meet would involve munging the SDP on the client. Brian's solution, which is probably simpler, just involves adding an SSRC of "1" to each video channel definition in COLIBRI, i.e.:
<channel ...><source xmlns="urn:xmpp:jingle:apps:rtp:ssma:0" ssrc="1"/></channel>

···

---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/222#issuecomment-219548804


#6

erm, did something get lost on that comment?

···

---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/222#issuecomment-219682075


#7

Also did catch into this thank @xdumaine for asking this question :slight_smile: Spent 5 hours on finding out WTF, mad fix in 1 min...

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/issues/222#issuecomment-243636408


#8

We also ran into this and, instead of adding a dummy ssrc to the sdp, we
just also pushed an ssrc of "1" to the bridge for each video channel.

···

On Fri, Apr 15, 2016 at 10:58 PM, bgrozev <notifications@github.com> wrote:

Have you checked that the bridge doesn't send packets for the video
stream, or do you just observe that the client fails to render them?

I suspect that this is due to RTCP from the receive-only client not
reaching the sender. The receive-only client's setLocalDescription doesn't
contain an SSRC, so it will use a default value ("1", I believe, unless
this changed) for RTCP reports. Lacking any signaled SSRC the bridge will
not be able to demux RTCP packets from the receiver and will drop them. You
can check whether this is the case by having another send-receive client
join the conference in your Scenario 1. As soon as this happens, Charlie
should start rendering both remote videos.

If my suspicion is correct there is not much we can do in the bridge (we
could log a warning if we detect such a scenario, I suppose). We solve it
In Jitsi-Meet by always including an SSRC in setLocalDescription, even when
in receive-only mode. There was a long discussion somewhere on github, but
I can't find it right now.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
<https://github.com/jitsi/jitsi-videobridge/issues/222#issuecomment-210742622>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev