When the audio is set as available it is followed by a call to
"setAudioEnabled(bool)", so the state of the audio button just set was
always immediately overriden. Moreover, as only the button state but not
the related attribute was set the view was left in an inconsistent
state.
It is currently not possible to directly call "setVideoEnabled(bool)"
from "hasVideo()", so for consistency both "hasAudio()" and "hasVideo()"
expect "setXXXEnabled(bool)" to be explicitly called after they are
called.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The audio and video are explicitly set as disabled before they are set
as not available, so there is no need to set them as disabled again.
Moreover, even if they were not explicitly set as disabled it would not
be really necessary to disable the audio and video when they are not
available.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The condition passes when the video is available, but it will only be
executed anyway if the video is available due to the initial condition
in the method.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The proper name was being used in the "constructor" to initialize the
attributes to false, but not in the rest of the file; this caused the
attributes to be undefined when they were first used, which
coincidentally in those cases it was the same as if they were false, so
the typo caused no issues.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When calling "disableVideo" the video was hidden even if it was not
possible to disable the video; this was done to hide the video even if
WebRTC was not started yet when "disableVideo" was called. Now that the
video is disabled when joining the call in a room with more than five
participants instead of just when entering a room with more than five
participants that special behaviour is no longer needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Until now, when entering a room with more than five participants the
video was disabled. However, if the local video is available it is
enabled when WebRTC starts. Due to this, if WebRTC was also started when
joining the call (that is, no previous calls were made in other rooms
since the last page reload) the video was enabled instead of disabled.
Besides that, if leaving the call with the video enabled and joining it
again the video was still enabled, as the room had not been entered
again to disable the video. To fix both issues now the video is disabled
when joining the call instead of when entering the room.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
This ensures that receiving a screen offer will not abort a delayed
reconnection of the video.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a stale peer reconnects its Peer object, and thus its video view,
is removed and created again. The video view always set the screen icon
as not available and it was later changed to available if a screen offer
was received, so if the peer sent the screen offer before the video
offer the screen icon was never set as available. Now whether the screen
is shared or not is taken into account when setting the initial state of
the video view.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When a screen is shared a new offer is sent, just like when a video (or
audio only) connection starts; any offer coming from the same peer has
the same id, even if the type of the offer is different and separate
Peer objects are created for each offer. Due to this now a peer is stale
only if both the id and type of the new offer matches an existing peer;
otherwise when the screen offer was received the video peer was seen as
stale and removed.
Note, however, that even if the id and type of the new offer matches an
existing peer its participant should not be marked as disconnected, as
that removes all its Peer objects. If that happens then the connection
becames unstable with the peers sending offers back and forth due to the
difference in how they are started (immediately or delayed for video
depending on the ids of both peer, immediately for screens but only for
the peer that shares), the removal of Peers when a new offer is
received, and the creation of new Peers (and, with them, new offers)
when the signaling returns the user list.
Moreover, if a stale peer is found it is going to be replaced by a fresh
peer, so there it is not really needed to perform the whole
disconnection process. Therefore, now the stale peer object is simply
ended instead (and in the case of video peers their video and speaker
are explicitly removed; this should probably be done automatically when
handling the peer end, like done for screen peers, but for the time
being an explicit call is used just like in other areas of the file).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Daniel Calviño Sánchez
Ivan Sein
Joas Schilling
Nextcloud bot
Joas Schilling