RTCP channel in streaming plugin not working when simulcast

[trankkilou]

The PR #1331 works very well for handling FIR and PLI request in streaming/mountpoint context + videoroom RTP forwarding (typical use case)

However with simulcast (2) activated It doesn't work.

First , with or without RTCP port configured, the ripc.c claims for getting SR from 3 ssrc instead of one :
for instance my 3 ssrc are
SSRC: 1546260563 (rid h)
SSRC: 3240455566 (rid m)
SSRC: 2871358614 (rid l)

every secondes I have tons of lines like in logs
[WARN] Incoming RTCP SR SSRC (3240455566) does not match the expected one (2871358614) video=1
[WARN] Incoming RTCP SR SSRC (1546260563) does not match the expected one (2871358614) video=1

meaning rtcp is not happy to get SR from "h" and "m" layers in this chan.

Moreover, FIR request, even for "l" layer are never seen nor relayed to videoroom plugin.

If we follow the logic of an outbound channel to handle FIR request, like in the PR above, I guess we need to add 2 others RTCP ports to handle them ?

[lminiero]

It does work. You only need 1 port because we only send PLI/FIR for one SSRC, and it works for all of them. Closing.

[trankkilou]

Sorry by on the RTCP channel, I can receive REMB from videoroom but FIR request are never sent from the client. So to get the streams display it takes random times, up to 60 sec like when you don't have any rtcp channel.

[trankkilou]

I still don't understand why you remain this ticket closed. Maybe I didn't explain the case very well but there still a bug. So let me explain again :
Here the setup
publisher -> videoroom -> rtp Forwarding -> mount point "A"
viewer -> streaming plugin -> mount point "A"
if Mountpoint is configured with simulcast = false + rtcp channel -> it works. The FIR message is well relayed by the Mount point A to the videoroom
If Mountpoint is configured with simulcast = true + rtcp channel ->IT DOESN'T WORK. I MEAN I got the pictures DISPLAYED AFTER AGES (60 sec). This is because The FIR message is never relayed by the Mount point A to the videoroom
I m using the streaming demo to display feed from mount point juste for info.
I have made pcap (clear using your system and encrypted) on both side. I have janus log also. So please reopen the ticket, thanks.

[lminiero]

The streaming plugin doesn't care if the mountpoint is simulcast or not: if incoming_rtcp is receiving a PLI, it will forward it via RTCP on the other side. If the PLI is sent, the VideoRoom sends the PLI exactly as it does in all other cases, whether it's simulcast or not. As such, not sure what you'd like me to fix. And even if this is opened, I'm not going to work on it anyway as I'm busy, so you may want to prepare a PR instead.

[lminiero]

Wait, I think I know what the issue very likely is. Thinking about your description again, the problem is not in the RTCP support (which does work, when used), but in the fact your Streaming plugin viewer is not sending any PLI at all: since they don't send the Streaming plugin a PLI, the PLI is not forwarded to the VideoRoom, and so the VideoRoom has nothing to send to the publisher.

I'm pretty sure this is because of the different way the Streaming plugin relays media when simulcast is involved. Normally, the Streaming plugin forwards just anything: so viewers will start receiving media before a keyframe, and just discard it, and possibly send a PLI. When simulcast is used, the core helper code is used, and that prevents any layer from being forwarded until a keyframe is received. So this is why the keyframe mechanism seems not to be working for you: when the viewer connects, we're not getting any keyframe from the VideoRoom, and so we don't relay any packet to the viewer; since the viewer is not receiving any media, a PLI is never sent, because they don't know they need one (the decoder was never passed packets).

The fix should be relatively easy: basically, we need to ensure that a PLI is sent by the Streaming plugin for a new viewer when they connect, whether they sent a PLI or not: this is more in line with how the VideoRoom plugin works for its own subscribers. I guess we were both right, eventually 🤣

[lminiero]

This commit should fix it. Please let me know if that's not the case.

[trankkilou]

Wait, I think I know what the issue very likely is. Thinking about your description again, the problem is not in the RTCP support (which does work, when used), but in the fact your Streaming plugin viewer is not sending any PLI at all: since they don't send the Streaming plugin a PLI, the PLI is not forwarded to the VideoRoom, and so the VideoRoom has nothing to send to the publisher.

I'm pretty sure this is because of the different way the Streaming plugin relays media when simulcast is involved. Normally, the Streaming plugin forwards just anything: so viewers will start receiving media before a keyframe, and just discard it, and possibly send a PLI. When simulcast is used, the core helper code is used, and that prevents any layer from being forwarded until a keyframe is received. So this is why the keyframe mechanism seems not to be working for you: when the viewer connects, we're not getting any keyframe from the VideoRoom, and so we don't relay any packet to the viewer; since the viewer is not receiving any media, a PLI is never sent, because they don't know they need one (the decoder was never passed packets).

The fix should be relatively easy: basically, we need to ensure that a PLI is sent by the Streaming plugin for a new viewer when they connect, whether they sent a PLI or not: this is more in line with how the VideoRoom plugin works for its own subscribers. I guess we were both right, eventually 🤣

it's ok for me :) it is hard to find out a FIR request in the cyphered trafic as this is in the extension part. We thought we were looking a the 192 PT packets but it seems not :)

[trankkilou]

This commit should fix it. Please let me know if that's not the case.

it works ! many thanks for this PR, we would have spend a lot of time to find it :)
It remains a minor issue: the logs. I think rtcp.c is not happy and blast a lot of messages like this :
[WARN] Incoming RTCP SR SSRC (xxxxxx) does not match the expected one (xxxxxx) video=1
I can ignore them but it's not clean ;)