This error condition only happens when a peer cancels its outgoing call in the middle of us answering it. We can simply ignore the error and things should nicely fall back into place. Since this race should be pretty rare in normal usage, it's nice to leave a log message, as it might mean we're being fuzzed.
We can prograssively replace more of those asserts by fallbacks and log messages now that everything has been shown to work fine, and the race conditions are harmless.
I feel like writing a novel today. Good thing nobody looks at these!
And properly handle toxav happily delivering things out of order,
like firing a video frame callback right after a callback setting the bitrate to 0,
when the peer sent these commands in the right order
There can now only be one CameraSource running.
Video frames are decoded in their own thread, and then converted by users in the user's threads.
The CameraSource API is entirely thread-safe and controls the video decoding thread.
The video device only stays open as long as there are users subscribed to the CameraSource.
We use a dangerous combination of spinlocks and memory fences to keep things synchronized.
The qTox Project is not associated with the Tox Project in any way, with the
exception of "qTox" using the Tox Projet's "toxcore" collection of libraries.
In particular, the Tox Projet does not own copyright over the qTox Project's
"qTox" collection of software, source code, and assets.
The qTox Project's assets are under the sole copyright of the qTox
contributors, and no partiular rights are granted to the Tox Project.
They were suffering from double-connection syndrom, and the way muting worked was now conflicting with how the output sound level setting works
Fixes#1442
Load the setting's cameria preview opengl context lazily and destroy it when done. Only preallocte Core's video buffer if we have any calls active, free up when all calls are done
Toxcore would incorrectly report the call as a video call in the call settings, and then crash while trying to send a video frame in the audio call. We workaround that by using another API that correctly reports the type of the call
