| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Elmer Miroslav Mosher Golovin <miroslav@mishamosher.com>
|
|
Signed-off-by: Elmer Miroslav Mosher Golovin <miroslav@mishamosher.com>
|
|
Signed-off-by: Joas Schilling <coding@schilljs.com>
|
|
Signed-off-by: Elmer Miroslav Mosher Golovin <miroslav@mishamosher.com>
|
|
Signed-off-by: Elmer Miroslav Mosher Golovin <miroslav@mishamosher.com>
|
|
Signed-off-by: Elmer Miroslav Mosher Golovin <miroslav@mishamosher.com>
|
|
Signed-off-by: Elmer Miroslav Mosher Golovin <miroslav@mishamosher.com>
|
|
Signed-off-by: Elmer Miroslav Mosher Golovin <miroslav@mishamosher.com>
|
|
Signed-off-by: Elmer Miroslav Mosher Golovin <miroslav@mishamosher.com>
|
|
Signed-off-by: Elmer Miroslav Mosher Golovin <miroslav@mishamosher.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
The benchmark tool can be used to check the resources needed by the
recorder process with different configurations, as well as to verify the
quality of the recorded file.
Unlike a real call recording the benchmark helper does not launch a
browser and joins an actual call; instead a video file is played.
Therefore it can not be used to check the whole usage of resources
during a call recording, but only the resources used by the recorder
itself.
On the other hand, playing a video file eases performing the tests, as
it does not require an actual call to be running, and also helps to
compare the quality between different configurations, as they can all be
based on the same input.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
This will make easier to override the values set in the configuration
for specific runs.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Rather than providing some values and then composing the final name from
them now the recorder log name is explicitly provided.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Rather than providing some values and then composing the final name from
them now the sink name is explicitly provided.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
The recording is stopped in a different thread than it is started.
Stopping the recording stops the helpers, like the display, but if they
are stopped at the same time that they are being started there could be
a race condition in which the helper is tried to be stopped in one
thread and, immediately after that, the helper is started in the other
thread. This is now handled by explicitly checking if the recording was
stopped after starting each helper and aborting the start if it was.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
When the recording is stopped the helpers, like the display or the
browser, are stopped. This might cause an exception to be thrown, but if
the recording was still starting and it was not fully started yet there
is no need to notify that failure to the Nextcloud server.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
VP8 encoder now uses the "Constant quality mode" to ensure that every
frame gets the needed bitrate to achieve certain quality level rather
than forcing the whole stream to have an average bitrate.
The maximum bitrate is set to 1Mbit/s, which should be enough to get
clear images even with FullHD screen shares (although this might still
compress some screen shares, as the default bitrate for screen shares in
the HPB is set to 2Mbit/s, but it should be enough for typical screen
shares of slides).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
The Nextcloud server expects a notification to be sent by the recording
server once a recording is stopped. However, if the recording server
does not know about certain recording the Nextcloud server did not
change the recording status, and the recording was kept active (even if
it was not).
To solve that now the recording server returns a 404 when trying to stop
an unknown recording (although not if the recording is being stopped),
and in that case the Nextcloud server updates the recording status to
"failed".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Although recordings should not fail in some cases they could (for
example, if the configuration is wrong, the disk is full...). A new
recording status, "failed", has been added to notify that situation to
the Nextcloud server from the recording server.
Typically call participants will not be able to do anything about the
failure, so the clients can just show a notification to the moderators
and hint about asking the system administrators.
In any case, even if the recording status is "failed" further recordings
can be started, which will behave as if the recording was started from
the "none" status.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
The participant will be in turn forwarded again to the Nextcloud server
once notified that the recording started or stopped so it retains the
proper participant (for example, in system messages) rather than using
the recording server.
The actor is optional when stopping the recording, as the recording
could be implicitly stopped when the last participant leaves the call.
Nevertheless, this causes the system message to be assigned to a guest
(as the request comes from the recording server), which is unexpected,
so this may need to be adjusted.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Before the recording status was immediately changed by the Nextcloud
server when a recording was started or stopped. However starting or
stopping (but mostly starting) can take some time due to the
initialization of the display and audio device, starting the browser,
joining the call... so the recording status did not match the actual
status.
To address that now the recording server sends a notification back to
the Nextcloud server when the recording actually started or stopped, and
only then the Nextcloud server changes the recording status.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
nextcloud/use-internal-client-of-signaling-server-for-recording
Use internal client of signaling server for recording
|
|
Signed-off-by: Joas Schilling <213943+nickvergessen@users.noreply.github.com>
|
|
The previous wrapping of the script in an async function swallowed the
exception thrown by the script. If a Promise is passed to the last
argument "execute_async_script" will return the resolved value and throw
the rejected value, so now the async function is, in turn, wrapped by a
Promise which is resolved or rejected as needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
The recording participant now uses an internal client rather than a
guest participant.
Internal clients are specific to the signaling server and do not have a
counterpart Nextcloud user/session. Authentication is done with a random
string and a token, which is the random string hashed with the internal
secret of the signaling server.
Due to its special nature an internal client is able to join any call,
so using an internal client makes possible to record calls other than
public ones.
Besides that, this also fixes stopping a recording when the last
participant leaves, as the recording participant is no longer a regular
participant known to Nextcloud and therefore does not prevent the call
from ending when the rest left.
Finally, the recording participant is no longer shown in the call either
for the rest of participants, as internal clients are not shown in the
UI (or, at least, they should not be; this may need to be adjusted in
the mobile apps).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
This will be used to authenticate as an internal client in the signaling
server rather than having to authenticate as a regular participant.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Instead of joining the call in the main Talk page now a specific page to
be used only by the recording server was added.
This will make possible to use a specific UI tailored for call
recording, but also to use an internal client of the external signaling
server rather than a normal participant.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Chromium does not seem to play all Theora files (might be related to
timestamp problems), while VP8 is supported in both Firefox and
Chromium.
Similarly Firefox can not play Matroska containers, while webm is
supported in both Firefox and Chromium.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
The script creates a Docker container and installs all the needed
dependencies as well as the recording backend inside it.
Once the container has been created running the script will just launch
the recording backend again in the existing container, without setting
it up.
Note that the configuration (/etc/nextcloud-talk-recording/server.conf)
needs to be customized as needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
To record a call a virtual display server and an audio sink are created.
Then a browser is launched inside the virtual display server, and its
audio is routed to the audio sink. This ensures that several browsers
can be running at the same time without interfering with each other.
Then the call is joined by the browser, and an FFMPEG process to record
the virtual display driver and the audio sink is started.
Once the recording is stopped it is uploaded to the Nextcloud server.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Based on the real participant class (and related) from
"Talkbuchet-cli.py", but with some adjustments, like using kiosk mode,
loading the browser with specific environment variables (which will make
possible to load the browser in a specific display and to send the audio
to a specific device) or preventing any microphone or camera from being
used.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
"server.conf.in" is provided as an example file with a description of
all the configurations. Some descriptions were copied from
https://github.com/strukturag/nextcloud-spreed-signaling/blob/v1.0.0/server.conf.in,
which is also licensed under the GNU AGPLv3.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
|
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
|
