Slowlink and Bandwidth detection

[Chad Furman]

Is there any good documentation on how slowlink works?  When it kicks in?  Sometimes in a conversation the browser clients get overloaded, send lots of PLIs, drop packets, and then even occasionally disconnect.  Also, if someone is hotspotting with their mobile phone to their laptop, their bandwidth will be severely limited.  And in heavy-traffic networks without a lot of bandwidht, etc, I'd want to lower the bitrate, as well as stream resolution.

Is all of this possible with Slow Link?  If not, are there alternatives you could suggest?

[Lorenzo Miniero]

No docs around for that, I'm afraid.

There are two different kinds of "slowlink" events. One is sent from the core, one from (some) plugins. The one sent by plugins may have some more info (e.g., in videoroom or record&play) , and it's plugin specific. In general, the event is triggered whenever Janus sends or receives too many NACKs, which suggests problems, as it indicates possibly severe packet loss that one of the peers is trying to recover from. One of the things you can do when that happens is reduce the video bitrate, for instance: for an example of this, check the record&play demo code.

L.

[Chad Furman]

Alright, and NACK is different from PLI -- I'm seeing PLI requests coming through when my PeerConnections see frozen videos and choppy audio.  Maybe I can add some PLI handling code to the incoming_rtcp function where if I start getting 10 or 20 or so PLIs on the same session, then downgrade stream quality...

Will have to explore, thank you!

[Chad Furman]

So I looked into this a bit.

There seems to be several different approaches here.  In recordplay, the client adjusts the bitrate only for publisher connections.  In videoroom, there's a slow_link message sent to both publishers and viewers, but neither one handles it.  Easy enough to handle the publishers, as there's a bitrate field.  No such luck on viewers...

How could I add a bitrate to listeners?  Ignoring for the moment adding the field to the struct and updating it on "configure".

It seems that incoming_rtp uses the bitrate field for setting up janus_rtcp_remb -- but this doesn't seem relevant to listener streams?  Maybe I need to read up more on REMB?

[Lorenzo Miniero]

Not sure I understand what you mean. Viewers don't send anything, so why would you want to send them a REMB? They have no bitrate to adapt their encoder to.

L.

[Chad Furman]

I want to adjust the bandwidth requirements of downlinks.  I can (relatively) easily alter the uplink bandwidth requirements with bitrate.  The downlink is dependent on the uplink strength of the other publishers, however.  If I detect a slow downlink on a viewer, do I have to downgrade the bitrate of every publisher that the viewer subscribes to?  Is there another way of lowering bandwidth requirements of downlinks?

[Lorenzo Miniero]

The source is the same for all viewers, so you can't possibly alter the bitrate for a single viewer without transcoding. If a user is suffering, you either decrease the bitrate on the publisher, or you decide to leave it as it is if it's ok for most of your users. Either way, there's nothing you can do by sending a REMB to a viewer, which has no use. You can receive REMB from viewers, though, and that gives you an indication of the bitrate that specific viewer is assumed to be able to digest (which is what Janus does when sending a REMB to publishers).

L.

[Anand Setlur]

Lorenzo,

when we have an active videoroom of publishers ,does the following curl command alter/halve the bitrate of just this one publisher(which is having slowlink issues) or does this bitrate setting affect the whole room including other publishers ?

curl -H Content-Type: application/json' -X POST -d '{"body":{"request":"configure","room":1234,"id":950845122531696,"secret":"adminpwd", "bitrate":256000},"janus":"message","apisecret" : "janusrocks","transaction":"o4vup0qoomd"}' https://servername:8089/janus/8191220116814602/7844085035125687

[Anand Setlur]

I am answering my own question. The curl command only affects the specific  publisher_id and not the whole room. It would still be handy if janus incorporated some across the board strategy for slowlink events(with an adaptive REMB or proper bandwidth estimation for the benefit of the remote peer) instead of putting the onus on the application to deal with it.

[Lorenzo Miniero]

This was done on purpose to give each application the flexibility to do what they want the way they want. Some may want to decrease the publisher bitrate, others do the same but up to a certain point, others leave the publisher as it is but RTP forward it to an external transcoder that can generate a lower bitrate stream, others have the publisher generate another lower quality stream and have problematic users go there, others drop some videos and fallback to a switch-based single viewer, etc. etc.. There are so many legitimate ways to react, all depending on the very specific application scenario one has in mind, that it would be impossible (and counter productive, as any change would require recompiling) to hardcode some logic in the plugin itself. While it may make sense to have a couple optional logics in the plugin itself, they're not a priority for us right now. Bandwidth estimation is definitely not in the plans, instead.

L.