If a browser version can not handle the pointer events, it becomes detected and that browser uses the mouse event etc.
For these browser is no palm rejection provided. All other browser use the pointer events.
* add button to the toolbar to switch palm rejection mode
* add a message for that new button to the locales/en
* add boolean palmRejection to state of the toolbar
* save that boolean also to the session storage, so it is ready to use it in the input handler
This incorporates only the audio desync related changes from #11626
* Add the aresample filter with async option to fill in timestamp gaps
* Use the libopus decoder for opus audio instead of ffmpeg's builtin
decoder
This gives the following advantages over the previous code:
* The ffmpeg input filters are loaded from a filter "script" file instead
of passed on the command line. This fixes some cases of recordings
failing to process because the ffmpeg command line generated for the
audio processing exceeded the max command line length limit. (Although
that only really happens due to BBB bugs...)
* Use absolute positions when trimming audio segments for cuts.
Previously segments were trimmed to the length of the segment, and the
results were concatenated. There's some possibility of accumulated
errors in the segment lengths causing audio desync over time. The new
code incrementally concatenates the segments, and cuts each segment
end based on the absolute time since the start of the meeting, to
avoid error accumulation.
Modified the previous implementation of the whiteboard individual access to remove
multiple Collections dependency on this feature. Multi-user whiteboard is now an
array instead of a boolean value and most of the access control can be synchronized
and handled by akka-apps.
New config called paginationThreshold defines classes of page sizes that depend on the number of participants of a meeting
The rationale is pretty much the same as the cameraQualityThresholds, but the thresholds are users here and the ceilings are the page sizes
I was shown a case just now where `CreateNewPresentationPodEvtMsg` can happen prior to the full add of a meeting. This log line becomes relevant once again
Disabled `'Backend meeting queue had not been initialized'` which was added to pinpoint an issue with handling of meeting create events, but the issue seems to be unrelated (and has not been hit after resolving a memory leak)
