With simulcast the connection stats reported by Firefox only contain one
"outbound-rtp" and one "remote-inbound-rtp" stat for video, just like
when simulcast is not in use. However, the stats reported by Chromium
contain several entries, one for each stream quality. As the
PeerConnectionAnalyzer assumed that a single entry of each kind will be
reported the stat for the last stream overrode the other ones.
Moreover, in some cases no packets could be sent in one of the streams,
yet the others could be working fine, so the receivers would be able to
still see the video by falling back to any of the other streams. But if
the stopped stream is reported in last place it will override the other
values and the connection will be seen as stopped.
Therefore, now the packet count is aggregated between all the
"outbound-rtp" and "remote-inbound-rtp" stats; for simplicity (that is,
to avoid calculating the average), and as they should be pretty similar,
only the longer round trip time is taken into account.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Currently whether the local user is in the call or not from the point of
view of the Nextcloud server is mostly ignored; the UI is based only on
whether the user explicitly joined or left the call. The reason is that
after the user joined the response from a previous request to get the
room information done when the user had not joined yet could be
received, so honouring that could make the UI jump between "in the call"
and "not in the call" (as it happened in older versions).
However, in the WebRTC related code whether the local user is in the
call or not is only based on the user events sent by the signaling
server, so in that case the state is always up to date.
Due to this, it is possible to detect whether the local user was kicked
out from the call by a moderator (for example, because the call was
ended for everyone) by comparing the local state ("localUserInCall",
which is updated when locally joining and leaving a call) with the
remote state provided by the signaling server.
Note that there is no rollback of "localUserInCall" if the join or leave
call request fails; the error is currently ignored by other parts of the
code, so handling it here does not provide any benefit.
An alternative approach would have been to ignore the "in call" state
provided by the server while a "join call" request is on-going, so the
local state and the server state would match except when the user was
kicked out from the call. This would have required deeper changes, so
even if it could be a better approach in the end for now the simpler
(but less clean) approach was used.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When "videosCap" is set it was always applied, no matter the actual
number of videos. Due to this, even if there was just a single remote
video, as the available size was calculated based on the limit rather
than on the actual number of videos a mostly empty grid was shown.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The hard limit can be enabled with OCC with "occ config:app:set spreed
--value=yes grid_videos_limit_enforced". The changes will take effect
once the user reloads the page
The grid videos limit by default is a fuzzy limit, as the number of
videos shown could be larger due to the available space and aspect ratio
to distribute the videos on. When the limit is made a hard limit the
distributed slots will be the same as before, but only as many videos as
allowed by the limit will be filled in each page.
However, note that with the hard limit the grid may look "broken", as
there is still space to be filled with videos yet they are in the next
page.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The limit can be set with OCC like "occ config:app:set spreed
--value=XXX grid_videos_limit". The changes will take effect once the
user reloads the page.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>