Back in the day the setting to prefer H.264 was added as a technology
preview; it was not a finished feature, but a preview of a feature that
could be added in the future. However, H.264 does not work when the HPB
is used, it overrides the preference order already decided by the
browser and it does so by altering the SDP, which could lead to problems
if its format changes. Due to all that preferring H.264 is no longer
available.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When "prefer_h264" is set the SDP is modified to place H.264 as the
preferred codec. However, this change in the SDP clashes with the
changes done to enable simulcast with Chromium and sometimes causes
creating the offer to fail. Given that preferring H.264 has no effect
when the HPB is used (as only VP8 is supported in that case) and that
simulcast can be enabled only with the HPB now "prefer_h264" is ignored
when simulcast is used.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
Nextcloud bot
Joas Schilling
Marco
Daniel Calviño Sánchez
Christopher Ng
Joas Schilling
Vincent Petry
dependabot[bot]