[jitsi-dev] [jitsi-videobridge] Adaptive simulcast (#161)


#1

This adds a new implementation of adaptive simulcast in AdaptiveSimulcastBitrateController. The class previously named BitrateController is renamed to LastNBitrateController. The intention is to eventually refactor the classes in the ratecontrol package.

Note that this depends on libjitsi PR 95 and shouldn't be merged without it (it won't compile): skip ci
You can view, comment on, or merge this pull request online at:

  https://github.com/jitsi/jitsi-videobridge/pull/161

-- Commit Summary --

  * Minor clean-up and clarifications to the documentation.
  * Exposes the target order of a SimulcastSender, and the map of SimulcastSenders from a SimulcastSenderManager.
  * Update jitsi-protocol-jabber (fixes adaptive-simulcast signalling).
  * Renames BitrateController to LastNBitrateController and implements adaptive simulcast (in AdaptiveSimulcastBitrateController).

-- File Changes --

    M doc/adaptive-last-n.md (12)
    M pom.xml (2)
    M src/main/java/org/jitsi/videobridge/LastNController.java (23)
    M src/main/java/org/jitsi/videobridge/VideoChannel.java (23)
    A src/main/java/org/jitsi/videobridge/ratecontrol/AdaptiveSimulcastBitrateController.java (546)
    M src/main/java/org/jitsi/videobridge/ratecontrol/BitrateController.java (594)
    A src/main/java/org/jitsi/videobridge/ratecontrol/LastNBitrateController.java (613)
    M src/main/java/org/jitsi/videobridge/ratecontrol/SimulcastAdaptor.java (4)
    M src/main/java/org/jitsi/videobridge/ratecontrol/VideoChannelLastNAdaptor.java (8)
    M src/main/java/org/jitsi/videobridge/simulcast/SimulcastReceiver.java (6)
    M src/main/java/org/jitsi/videobridge/simulcast/SimulcastSender.java (8)
    M src/main/java/org/jitsi/videobridge/simulcast/SimulcastSenderManager.java (17)

-- Patch Links --

https://github.com/jitsi/jitsi-videobridge/pull/161.patch
https://github.com/jitsi/jitsi-videobridge/pull/161.diff

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/161


#2

+ @Override
+ public void close()
+ {
+ recurringProcessibleExecutor.deRegisterRecurringProcessible(this);
+ }
+
+ /**
+ * Notifies this instance that the estimation of the available bandwidth
+ * has changed.
+ *
+ * @param bwe the new estimation of the available bandwidth in bits per second.
+ */
+ @Override
+ public void bandwidthEstimationChanged(long bwe)
+ {
+ latestBwe = bwe;

Why do we care about the remote send bandwidth estimation (that's what the bandwidth estimation algorithm running at the bridge is calculating)? We can't use those estimations to figure out if we're oversending, instead we need to take into account the values in the REMBs. Or am I missing something obvious?

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/161/files#r55271773


#3

+ @Override
+ public void close()
+ {
+ recurringProcessibleExecutor.deRegisterRecurringProcessible(this);
+ }
+
+ /**
+ * Notifies this instance that the estimation of the available bandwidth
+ * has changed.
+ *
+ * @param bwe the new estimation of the available bandwidth in bits per second.
+ */
+ @Override
+ public void bandwidthEstimationChanged(long bwe)
+ {
+ latestBwe = bwe;

Thanks for explaining @bgrozev, I thought it was the remote bitrate estimator that was giving those values.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/161/files#r55273202


#4

Thanks, @gp! I think the latest commits should address these issues.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/161#issuecomment-193531998


#5

Merged #161.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi-videobridge/pull/161#event-581886484