Automated subscription simulcast switching based on remb #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…mb is just a limit on what the client wants to have
fippo
reviewed
Aug 24, 2021
plugins/janus_videoroom.c
Outdated
| @@ -5501,6 +5504,97 @@ void janus_videoroom_incoming_rtp(janus_plugin_session *handle, janus_plugin_rtp | |||
| janus_videoroom_publisher_dereference_nodebug(participant); | |||
| } | |||
|
|
|||
| /* Retrieve the current position in the ramp up ramp down process | |||
| * Ramp positions: | |||
| * Spatial 0 (L) - Temporal 15fps -> 0 | |||
There was a problem hiding this comment.
i think you'll run into issues with this as only chrome restricts itself to two temporal layers while other browsers will use three (which remains the default of libwebrtc)
…ption-simulcast-switching-based-on-remb
…l statistics to the top
…n a dedicated sub struct of the simulcast data (just to have it properly separated)
…nto one function.
…ntation into a dedicated file to have it loosen from the video room and reusable for the other plugins.
…ramp position than the one we currently send
…n in the last commits. Have an own flag that tells me wether the last_bitrate value is valid or not (did we already receive a valid remb package or not)
…handle related - add an option to switch on/off debugging - added tests that have been done (which browser version and whats the finding)
…opt againt the remb.
… janus how to handle the remb adoption from the subscriber side. This is either ignore, ramp_up, or start_high. ignore - no remb adoption ramp_up - the adoptoin starts on the lowest simulcast layer with temporal 15fps and ramps up (for ff) start_high - it starts with what the subscriber wants to have (as chrome and safari delivers a pretty good remb value right from the start)
…ption-simulcast-switching-based-on-remb
…ption-simulcast-switching-based-on-remb
…ption-simulcast-switching-based-on-remb
…ption-simulcast-switching-based-on-remb
…ption-simulcast-switching-based-on-remb
…into feature/CC-2137-automated-subscription-simulcast-switching-based-on-remb
…ption-simulcast-switching-based-on-remb
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a followup from the original one of @sjkummer (meetecho#2735)
Fine tuned the switching and its working smothly but currenty lacks in probing. Therefore as draft PR to discuss where and how to implement probing.
The context and whats currently implemented.
Whats open
The reason for that is that the REMB does not increase to a value that covers the next layer.
if i have layers configured like this: 150/500/1200kbit
REMB does no got above 500 if i am on the lowest layer (max is about 380kbit).
The same happens for the middle layer, REMB does not go above 1200kbit (max is about 950kbit).
Therefore probing would be needed.
The question is therefore: