-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FireFox publisher removes a video track, janus sends changing simulcast layers on the subscriber side #2923
Comments
In the janus console i see the request for a PLI....
In case i should provide more context (SDP, or larger logs, i am happy to do so) |
and what happens on the network? You know the drill ;-) |
Please use quotes for snippets, since otherwise anything with a hash (e.g. |
That would help, as if the plugin is notifying substream changes it's because it's seeing media in for those SSRCs. |
We are still heavily working on all the changes we need to do for multistreaming. We have a ui that allowed us to capture pcap traces from janus in the past 0.x branch and i will revive that one on monday/tuesday which then allows me to capture unencrypted pcap traces.
Yeah that is what i did read from the Janus logs as well. |
I did a quick test to replicate, and with Wireshark I still do see video traffic coming in. The highest substream in particular (2) seems to have a keyframe sent once every second (I see a 90000 timestamp difference, and many packets with the same timestamp), which would explain why we switch to substream 2 (we see traffic for that substream, and it's what the user wants); it then consistently falls back to 1 because we have an automated fallback when no media for the current substream arrives for 250ms (which is true since Firefox is sending that video stream at 1fps). As such, from what I can see I think Janus is doing what it should, and it sounds like a weird behaviour in Firefox when |
tagging @jan-ivar - looks like reducing the framerate is not a good idea in this case? |
I don´t expect ff to change or improve anything in webRTC... |
What version of Janus is this happening on?
#c684d43d
Have you tested a more recent version of Janus too?
there is none
Was this working before?
Did not see this behaviour in the non multistreaming version
Is there a gdb or libasan trace of the issue?
Not dump but signalling related
Additional context
I have a publisher and a subscriber in the videoroom.
The publisher is using firefox.
The publisher is publishing audio and video and removes video by replaceTrack(null) on the sender in the peerConnection.
There is no SDP exchange involved as the peerConnection handles this without a negotiation request.
Janus then starts to send simulcast layer changes on the subscription each second. It never stops, just goes on and on.
I did not see this if the publisher is using chrome as browser.
Each second janus sends two events.
{
"": "2022-03-18T13:55:36.365Z - ws - in",
"janus": "event",
"plugindata": {
"data": {
"mid": "1",
"room": "R_4209a3ab63ac4db9a4a3756b15021db3",
"substream": 0,
"videoroom": "event"
},
"plugin": "janus.plugin.videoroom"
},
"sender": 5799355206759672,
"session_id": 4856516226201193
}
{
"": "2022-03-18T13:55:36.376Z - ws - in",
"janus": "event",
"plugindata": {
"data": {
"mid": "1",
"room": "R_4209a3ab63ac4db9a4a3756b15021db3",
"substream": 2,
"videoroom": "event"
},
"plugin": "janus.plugin.videoroom"
},
"sender": 5799355206759672,
"session_id": 4856516226201193
}
{
"": "2022-03-18T13:55:37.387Z - ws - in",
"janus": "event",
"plugindata": {
"data": {
"mid": "1",
"room": "R_4209a3ab63ac4db9a4a3756b15021db3",
"substream": 1,
"videoroom": "event"
},
"plugin": "janus.plugin.videoroom"
},
"sender": 5799355206759672,
"session_id": 4856516226201193
}
{
"": "2022-03-18T13:55:37.397Z - ws - in",
"janus": "event",
"plugindata": {
"data": {
"mid": "1",
"room": "R_4209a3ab63ac4db9a4a3756b15021db3",
"substream": 2,
"videoroom": "event"
},
"plugin": "janus.plugin.videoroom"
},
"sender": 5799355206759672,
"session_id": 4856516226201193
}
The text was updated successfully, but these errors were encountered: