Vladimir Stoiakin authored 1 year ago and Sébastien Blin committed 1 year ago

Applies some suggestions based on reviews by vstoiakin regarding concurrent resource access and overall structural simplification.
- Create and handoff ownership of QVideoFrames each frame
- use QReadWriteLocks when multiple reads are possible instead of QMutex
- remove the superfluous layer of unique_ptrs on QVideoFrames which are explicitly shared using QExplicitlySharedDataPointer for their underlying data.

This patch is required to prevent crashes when using Qt 6.4 and up.

Gitlab: #938
Change-Id: Ia9a9f0310344bcee47dbd88ec622bc3daa2ce6d7

We can observe that frame update signals can occur after a VideoOutput component's QVideoSink object has started destruction. The deregistration of the object pointer needs to be synchronized to the object's destruction.

Additionally:
+ scope the frame obj mutex locker around checks for no subs
+ rename (un)registerSink to (un)subscribe
+ subscribe will now remove the previous subscription
+ subscribe with an empty id will unsubscribe

Gitlab: #997
Change-Id: I21460564e49189b9276f153e8c1fd3a5cc52c6b2

Change-Id: Idf38e82631a4e22540aa5dec8ec2db0ab4a38c2e

Nicolas Vengeon authored 2 years ago and Sébastien Blin committed 2 years ago

Change-Id: I790f10542aed306a7416a4ce79f2eaf7a770135a
Gitlab: #698

Andreas Traczyk authored 2 years ago and Adrien Béraud committed 2 years ago

This is an older issue that has resurfaced where mobile device rotation
at the beginning of a call cause a frame-copy to a stale buffer because
the DecodingStarted event is handled asynchronously.

Noticed on Windows but I believe any non-dbus build should have it.

So we make all the connections blocking and adjust some parameters.
This commit also removes the DecodingStarted handler in CallModel which
was causing the client's target video frame to be reallocated for each
account present.

Change-Id: I23ac4e0bd4b446e7a532f0d362f7ecd209d3c790
GitLab: #536

No need to add complex mechanisms for nearly no-ops, the previous
method were bugguy and caused weird crashes. Just re-create the
renderer correctly.

Change-Id: I88738244c7cbaa6f189799c6a28dc9244953667d

Change-Id: I513acc54f1d8236b93832c02f9e658ec39f4db79

In preparation for vendoring libjamiclient into 'src/libclient/'.

GitLab: #734
Change-Id: Ibd956abc8fe9bd454ac0e9a5a28b77a5a74174e7

The photoboothview was bugguy and didn't take photo all the time.
Homogeneize captureVideoFrame with other methods.

GitLab: #727
Change-Id: I742e51e161c17ffc324e911341c5a4a701037f90

The SHM buffer size might be slightly larger than the expected
size due to 16-byte memory alignment used to create the SHM
buffers.

Gitlab: #731

Change-Id: Ida174fd16698cdbe6b19ccfd3c0c266adad68fa2

Mohamed Chibani authored 2 years ago and Sébastien Blin committed 2 years ago

Frames in shared memory have no specific line alignment
(i.e. stride = width), as opposed to the QVideoFrame, so
the copy need to be done accordingly.

Gitlab: #721

Change-Id: Id6576e55c5742a4e99d603feb4bc78f4d2be1ff0

Andreas Traczyk authored 3 years ago and Adrien Béraud committed 3 years ago

Removes the rendermanager and framewrapper objects along with any
QQuickPaintedItem-based QML render widget classes. This simplifies
the video widget stack implementation.

The new mechanism uses the VideoOutput component of QtMultimedia.
By accessing the VideoOutput's QVideoSink object, we update the
mapped buffer data of a sink's QVideoFrame when new frames are
published. Updates to frames and component sink subscriptions are
managed by a new class called VideoProvider.

Gitlab: #500
Also #536

Change-Id: I2391a32294922ea435ab80ac1f876c004ff6c21e