* docs: update test links on release notes and spec files
* docs: add tests for 'what's new on 2.7' features
* Update docs/docs/testing/release-testing.md
Co-authored-by: Anton Georgiev <antobinary@users.noreply.github.com>
* test: pass the bbb version in the doc links
---------
Co-authored-by: Anton Georgiev <antobinary@users.noreply.github.com>
FS has an intermittent issue where unmuting a HELD channel sometimes
takes significantly (seconds) longer than usual.
conference <XYZ> unmute <WVU> simply gets stuck with no FS_API response,
which delays the unmute action whenever transparent listen only is
active.
Apparently, unholding the channel PRIOR TO unmuting works around the
issue - at least it could not be reproduced with the scenario at hand.
The unmute API already triggered an unhold in FS internally, which is
the reason why this was not done beforehand. The aforementioned issue is
way worse than an extra "redudant" API call, though.
Always unhold audio channels manually _before_ unmuting.
Transparent listen only is currently only worth it for meetings with a
number of duplex audio channels larger than a certain value (dependant
on system performance). That is due to the fact that global audio
bridges created for the mechanism also use significant CPU (roughly the
same as an unheld duplex channel), which means it's cost is usually
offset only once there are enough potential channels to be held in a
conference.
This commit adds a new optional feature that introduces some dynamicity
for the mechanism: it'll only be triggered after at least
@voiceConf.transparentListenOnlyThreshold number of muted duplex
audio channels are present in a conference.
The default is 0 (always trigger transparent listen only if the general
mechanism is activated).
There's an issue where permission-less sessions of video-preview
fail to change video profiles. Whenever gUM is on prompt mode,
deviceIds are obfuscated, which means getInitialCamera will need to
infer the deviceId based on the current media stream.
Since the virtual bg worker is now called synchronously (e28a595),
it'll be extracted incorrectly from the virtual effect MediaStream
(rather than the original stream) - which causes getInitialCamera to
use the effect's deviceId rather than the original stream's deviceId.
Guarantee that deviceId inference via MediaStreamTrack uses
BBBVideoStream's originalStream (so that virtual effect streams are
bypassed). Also remove the call to updateDeviceId in getInitialCamera
since it's redundant since commit e28a595.
A change in e28a595b52 introduced an issue where the "Share camera as
content" modal always has it's "share" action flagged as disabled. This
is due to a short-circuit introduced in the initial gUM procedure that
does not clear the "disabled" state before exiting.
Properly reset the "disabled" sharing state after the initial gUM in
video-preview when "Share camera as content" is used, thus fixing the
aforementioned issue.
v2.14.1
---
* fix(screenshare): presenter/viewer stop logs on all scenarios
* refactor(screenshare): add presenter data to viewer logs
* refactor(video): add video negotiation and flowing logs
* build(mediasoup): 3.14.9
* Translate en.json in ar
100% translated source file: 'en.json'
on 'ar'.
* Translate en.json in ar
100% translated source file: 'en.json'
on 'ar'.
---------
Co-authored-by: transifex-integration[bot] <43880903+transifex-integration[bot]@users.noreply.github.com>
* fix(webcam): client failing to apply virtual background effect
* fix: check for already dispatched background
* fix: make webcam start up with last selected virtual background
