Rework sync so uploading multiple files at once or several moderators
uploading files simultaneously doesn't break synchronization.
The current room metadata plugin operates on <key,value> pairs and we
were using a generic "files" key and using a nested object as our value.
Since with every operation the entire object is replaced it's easy to
get out of sync because one needs to be sure to have the full state
before overwriting it.
This is not realistic.
We'll look into making the metadata plugin more flexible in order to
support add / delete operations also on nested objects, but for the time
being the following will suffice:
Use a key prefix, so each file has en entry in the room metadata, like
so: "files.<the file ID> -> file metadata". This means that when a file
is deleted we just empty the metadata. The metadata plugin doesn't
currently support removing existing keys.
After a lot of back and forth, WebM seems to be the only option we
really have. In terms of containers and codecs, here is the rundown:
- WebM, any codec: the resulting file is not seekable
- MKV, any codec: the resulting file is not seekable
- MP4, vp9 + opus: video artifacts and audio clipping, file is seekable
- MP4, av1 + AAC: all good, but not supported on Linux :-/
MP4 looked very promising but there is no combination that leads to
something that works reliably everywhere, oh well. In addition, MP4
files can be opened with QuickTime on macOS, but not with the codec
combination we'd use, so that is somewhat a disadvantage.
So, we are back to where we started: WebM with VP8 and opus. But we need
to fix the duration in a potentially long file... the trick is to _only_
fix the duration. We can do that by inserting the right segment in the
metadata section. Something we cannot do without reading the whole file
is create cue points, but players like VLC seem to work well without
them.
Setting the UA string in Electron doesn't propagate the change to the
iframe where the meeting is loaded (🤦).
Thus make it more resilient by trying different things:
- A freshly introduced "iAmSpot" config option, similar to Jibri
- The app ID is present in the UA string, so we can test for that
- As a last-ditch effort, check if the display name is the default
"Meeting Room"
* Revert "feat(base/ui/native): Convert rem to px (#15934)"
This reverts commit 057dc0e4d2.
* Revert "fix(StageParticipantNameLabel): size"
This reverts commit a01f4468a0.
* Revert "fix(subtitles): position part1"
This reverts commit 6c6ed8d7a8.
* Revert "fix(ITypographyType): wrong type of fontSize and lineHeight props"
This reverts commit bffcc9092b.
* revert(Tokens): font sizes and line heights back to px from rem
Turns out there are many places that does not expect rem. Temporary reverting this change from commit 6fa94b0bb4. We should bring it back along with proper handling of rem everywhere.
In the 1st incarnation of local recordings we used to use VP8 as the
video encoder. Upon switching to MP4 that combiantion is not supported
for some reason, so I used VP9 instead.
Some anecdotal evidence suggests VP9 is behqaving more erratically, with
rendering errors and fixes.
Turns out Chrome also supports the Matroska container! And VP8 inside it
at that! The bonus we get from using it is that QuickTime on macOS won't
try to open it, thus avoiding some confusion with MP4 files, which it
recognizes, but cannot open due to the video codec.
Fixes an issue where StageParticipantNameLabel is smaller. This is caused because the font size and line height props are calculated to an invalid (NaN) value after we started using rem instead of px for lineHeight and fontSize in theme.
Reference: #15917
Fixes an issue where subtitles are displayed in the middle of the screen. This is caused because the bottom prop is calculated to an invalid (NaN) value after we started using rem instead of px for theme.spacing.
Reference: https://github.com/jitsi/jitsi-meet/pull/15934
Fixes an issue where subtitles are displayed in the middle of the screen. This is caused because the bottom prop is calculated to an invalid (NaN) value after we started using rem instead of px for lineHeight in theme.
Reference: https://github.com/jitsi/jitsi-meet/pull/15917
In a previous comit about accessibility we changed the fint size and line height to use rem (expressed as string) instead of numbers for px but the types for the interface were not updated.
Currently the clientWidth is not representing the window width but it is representing the available video space width since we are subtracting the width of the participants pane and chat area.
