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.
When turned on, the consent dialog won't be displayed for the users who
are already in the meeting, it will only be displayed to those who join
after the recording was started.
Flush the file after the 'stop' event is emitted, which happens _after_
the last 'dataavailable' has been emitted, and thus when the
MediaRecorder is really done.
In addition, lower the time slice as added precaution against crashes.
It's OK if we don't have any local audio track, we'll add it to the
mixer later.
The original bug / limitation that prompted the previous code no longer
applies since we always have a MediaStream (with audio tracks) which
we are recording.
Capture the tab audio, which will include all participants and sound
effects, YouTube videos, anything playing in the tab.
This requires the `suppressLocalAudioPlayback` constraint since
otherwise the shared tab won't keep playing audio.
Local audio still needs to be injected seprarately, since it's not
played back to the local user.
A given recording should only trigger a single consent request.
The mechanism to notify about recording status updates may fire multiple
times since it's tied to XMPP presence and may send updates such as when
the live stream view URL is set.
Rather than trying to handle all possible corner cases to make sure we
only show the consent dialog once, keep track of the recording session
IDs for which we _have_ asked for consent and skip the dialog in case we
have done it already.
Use the `showSaveFilePicker` File System Access API to pre-select the
file for download and stream the contents there. The browser uses a
temporary file as the buffer, thus not requiring us to buffer the
contents in memory.
Also change the container to MP4, since we have no way to fix the
seeking problem since we don't have the file in memory. Good news is
that it's supported since Chrome 126 and we can feature detect it!
Finally, add a helper `isSupprted` method which feature-detects
everything we need to make this work.
Ref: https://developer.mozilla.org/en-US/docs/Web/API/Window/showSaveFilePicker
Ref: https://groups.google.com/a/chromium.org/g/blink-dev/c/p1OMVj1FrMI/m/6FdLk7rZAQAJ
We either expose those events in LJM or live with strings since they
match standard WebRTC states, but depending on the package just for 3
events is just not right.
If the desktop picker window is closed before we load the sources, a JS error is thrown. From there the app goes into a broken state where when the screen sharing button is pressed nothing happens. Explanation:
When the error from the _onCloseModal handler is thrown we don't reach the line to call the onSourceChoose callback. The result is that we never call the callback received by setDisplayMediaRequestHandler. It seems that when this happens on subsequent gDM calls electron won't call the setDisplayMediaRequestHandler and therefore we don't display the desktop picker.
* style(general) Replaced font-size fixed units with rem
* style(general) Replaced font-size fixed units with rem in the tokens
* style(general) Replaced line-height fixed units with rem
