"applyConstraints" is asynchronous, so calling it several times in a row
tried to apply the constraints again while the constraints for the
previous quality were still being applied. Due to this the constraints
for the same quality could be applied several times. Now applying
further constraints is deferred and collapsed in a single operation
until the previous operation finished.
When several different qualities are deferred there is no need to apply
the full sequence of deferred qualities; only the last quality is
applied, as qualities do not depend on previous qualities and the last
applied quality will always override any other quality previously
applied.
Note that, in general, "applyConstraints(quality)" is not expected to be
called again while the previous constraints are still being applied, so
deferring further calls should rarely happen. However, in practice this
could happen due to bugs in other parts of the code, so it is safer to
guard against it.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"change:XXX" events should be emitted only if XXX actually changed. In
most cases the duplicated events were not a problem, but when background
blur was enabled in a call with more than 5 participants it could cause
the browser to crash.
SentVideoQualityThrottler starts listening to events when video becomes
available, so if "change:videoAvailable(true)" was emitted again the
event handlers were duplicated. One of the handlers was set for the
"speaking" event, which causes the video quality to be adjusted if
needed. When background blur is enabled adjusting the video quality
restarts the effect, which causes the video stream to be recreated,
which in turn caused "change:videoAvailable(true)" to be emitted.
Due to all this, whenever the user spoke in a large call after another
user had spoken the event handlers for the "speaking" event were
duplicated, and each handler execution reset the background blur.
Eventually there were so many event handlers for the "speaking" event
that stopping and starting again the background blur so many times at
once temporary ate all the available memory, even if the objects would
have been garbage collected and the memory freed in a normal way later.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
A new section is added to Talk administration settings for web server
checks.
The check creates a JitsiStreamBackgroundEffect object to ensure that
the background blur files could be initialized, rather than implementing
its own logic to verify the .wasm and .tflite files. Due to this, the
browser running the check needs to support and have WebAssembly enabed,
although it does not need to support the background blur itself (like
Safari, which does not implement the needed canvas filters, but can
anyway be used to do the check).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Nextcloud bot
rakekniven
Marco
Joas Schilling
Joas Schilling
Daniel Calviño Sánchez