If a conversation was previously removed, it couldn't be re-cloned
due to the fact that the sync value can come from a previously
offline device.
Like updateContact in contact_list, use created/removed to determine
if it's a re-added contact to be able to re-sync again.
Change-Id: Ibe16d2bda02cbbe41b16d8b365d9c8ef02b36140
This is very unlikely, but really old conversations with incorrect
commits can cause some crashes. If the commit has no type, it's
something incorrect, in which case nothing should be loaded and the
client must not crash either.
Change-Id: If9e70f023a7ef89b3c777b4e83bea26559de30db
+ Fix recording in an audio only call
+ Fix crash if deinit the recorder without remote video
+ Add some tests
Change-Id: Ie78a632f6a2ecb3eae4f53ae8f25c8ecbf5c5091
GitLab: #719
Since multistream, we can handle several video streams with different
rotations and keyframe requests. the previous callback only managed
one stream.
To identify a stream, we use what is specified in RFC 5168 that we
already use and add a stream_id string when necessary:
https://datatracker.ietf.org/doc/html/rfc5168#page-6
If stream_id is empty, we apply the rotation/request to all streams.
https://git.jami.net/savoirfairelinux/jami-project/-/issues/1429
Change-Id: I8ca8480d128b0a5773e67409e467e26e7726dec4
This patch makes the daemon able to negotiate more than 2 medias
for a call. Basically, this patch includes some major changes:
1. reportMediaNegotiationStatus is also called for conference, so
the client is able to update the mediaList of the conference to
use it later if it needs to change the medias. And the medias
can be retrieven with currentMediaList
2. The conference object correctly updates the video mixer on
media changes, and video inputs are restarted if removed then
re-added.
3. Because previous versions of the daemon only supports two medias,
only negotiate more medias with compatible peers. If the daemon is
not compatible, the medias will not be negotiated anyway.
https://git.jami.net/savoirfairelinux/jami-project/-/issues/1429
Change-Id: I55701d9e6e53b05c9a58adad4e8ea90303e6b9e7
- add signal conversation synchronization ready
- add signal for call peer connection request
- add function to check if manager is running
Change-Id: I47927d5301853d0841819500372fc2b5aa83a110
This patch adds connection type to PeerConnectionRequest, so
iOS notification extension could detect notification type.
Also, it forces sending PeerConnectionRequest when placing a call,
So iOS devices could receive a notification.
Change-Id: I38526c9b3074969a70a678976ae28c259a7f452a
ffmpeg implements two opus decoders. libopusdec is a wrapper around the
libopus reference opus library. opusdec is a native implementation, but
lacks features such as FEC support in some distribution. Depending on
the distribution configuration, ffmpeg can select either decoder for
opus.
This patch forces the use of libopus if it exists. If it does not, the
function will fall back to opusdec.
Issue: #4857
Change-Id: Ia1838a593c9199fc1cbda5f4596c318a8cdd886b
An AVOption has been added to ffmpeg in sept. 2020, making the patch in
contrib redundant. This change is integrated in the contrib ffmpeg
starting from commit 855019860, which updates the used version.
This patch adapts the patches to be applied to ffmpeg and the call to
enable FEC in libopus. Specifically it does the following changes:
- backport the mainline ffmpeg patch that add fec to libopusenc
- add packet_loss reload to adapt its value to network
- modify rules.mak to add patches to the correct platforms
- make media_encoder set the right AVOption to enable fec
Issue: #4857
Change-Id: I614fce2f0cf7fc387973b34323138b07c1767726
Current pjproject's configuration only allow the daemon to negotiate
two medias streams. Which is not enough for multistream.
Modify this limit to 32 streams (2**5) and avoid any potential
crash if the remote tries to negotiate more streams.
Also, fix some loops.
Note: This may not be the best solution for what we want to achieve.
Another approach may be to use a video mixer, mixing all the
medias we want and always negotiate 2 media streams. However, this
patch will not block the other approach and fix some loops.
https://git.jami.net/savoirfairelinux/jami-project/-/issues/1429
Change-Id: I71ff3088bbf5908945656d02872755226f452fc5
In the previous version of the code, the conference was only
supporting 2 video inputs and one audio source.
For multistream, this is not correct and should be as generic as
possible.
https://git.jami.net/savoirfairelinux/jami-project/-/issues/1429
Change-Id: I7f7f7a2547209844a15f734bea3a62d92e456fde
With the previous code, the video mixer only supports 2 inputs via
switchInput and switchSecondaryInputs. Both of those methods are
deprecated in favor of requestMediaChange.
Now, instead of two separate variables to manage, the video mixer
manages a vector of video inputs for the host. This will allow
the conference to have a better management of inputs via
requestMediaChange().
https://git.jami.net/savoirfairelinux/jami-project/-/issues/1429
Change-Id: Ia65b35707bddf979154527c856e0574d96bbe519
Videos in the videoMixer_ were not easy to identify, moreover,
"sinkId" in the participants informations was the concatenation
of the confId and a URI, which is a problem if several devices
from the same account was present in the conference. Finally,
the active stream logic was dirty, with two different variables
used to identify the active stream in the mixer.
This patch introduces a streamId which is (callId_type_idx, e.g.
ca111412_video_0, ca111412_audio_2), so every video shown in the
conference are identified via a unique ID.
Active stream in the video mixer is identified by this ID, not
by the callId or pointer.
This should not change any behaviour, but prepare for multistream.
https://git.jami.net/savoirfairelinux/jami-project/-/issues/1429
Change-Id: I250dd31ad1ea92ed1fd1e94bec2f5abd311d2128
The plugins add translations files to theirs resources,
so now daemon can get the preferences values accordingly
to the system language. In the future we might add a way
to follow the client-qt language which can differ from the
system.
Change-Id: I4caf49b45261a256e422c2f772ea37f1f2e9548c
This fix testInviteFromMessageAfterRemoved (hasHandler was
not correct in checkConversationsEvents because the task was not
cancelled anymore).
Fix ut_scheduler's build
Change-Id: I4dbf3b31180c43fb7fa11061f3ffacb492d925c3
Following the new conference protocol and because a user can
join a conference with several devices, the hand raised is per
device and not per account.
This doesn't change any current behaviour, but is more flexible
for multi-devices support in conference and continue the
implementation of the new conference's protocol.
https://git.jami.net/savoirfairelinux/jami-project/-/issues/1429
Change-Id: Idab49d8d9efd73eda57706c7a77836689d07ddd7
