Revert a bug introduced in d126b18d76
where qTox calls tox_bootstrap() and tox_add_relay() with an invalid
argument, which results in qTox not connecting to the bootstrap nodes
from its list of bootsrap nodes and therefore failing to connect to the
Tox DHT network in the case when that list is the only source of nodes
to connect to. The invalid argument is node's public key, which is
non-nullable but is passed a null due to invalid ToxPk object being
constructed. ToxPk's constructor expects the QByteArray argument to be
the byte representation of a public key, but a textual representation
is passed to it instead, which creats an invalid ToxPk that resolves to
null when queried for public key's bytes for calls to tox_bootstrap()
and tox_add_relay().
Fixes#4385
Fix#4327
Description:
- QString::arg call with mulpiple arguments replaced with chained
QString::arg calls;
- dynamic memory allocation for array of names replaced with
allocation on the stack, unfortunately I do not notice this while
making Core refactoring.
Also code style is formatted with script
Brief list of changes:
- removed unnecessary headers from core.h and core.cpp;
- added missing brackets and aligned long lists of parameters;
- some other small changes.
Fix#4010.
qTox use status system, where offline is one of the status, but toxcore
use two different meaning: 'connection' and 'user status'. To correct
qTox status handling we should ignore online connection status.
Fixes#1926 : When an IPC event was processed locally, if the window was closed before the core could start, the event handler would be forever stuck in the background waiting for the core to start. We fix this by substituting QApplication::quit() by a Nexus::quit() function and a Nexus::isRunning() function, which gives us a condition for exiting blocking processEvents() loops. We cannot simply use QApplication::quit(), because this function has no effect before the start of the event loop.
The problem was further exacerbated by the Tox URI event handler being (incorrectly) blocking. The IPC owner would block in this event handler, and the sender of the event would give up waiting and process the event itself a second time, potentially triggering the first bug. We fix the event handlers accordingly to be (mostly) non-blocking.
Also fixes a related deadlock between ~Core and ~Profile in the case of an early exit
This commit removes historykeeper and code only used by it.
BREAKING CHANGE:
qTox can't open old historykeeper chatlogs after this commit. Use
previous versions to migrate to the new database.
Revert needed, since otherwise there is no way to do automatic sorting
of includes.
Also reverted change to the docs, as leaving it would make incorrect
docs.
In case of conflicts, includes were sorted according to the coding
standards from #3839.
This reverts commit b4a9f04f92.
This reverts commit 5921122960.
Makes changes to settings application wide transparent. The properties section is optional in theory, but comes in very handy, if we decide to access settings e.g. from within a script context.
initramfs (26):
feat(video): redesign and improve VideoFrame class
fix(video): fix CoreAV and VideoSurface to conform to new VideoFrame
refactor(video): rename and make the frame alignment propety public
fix(video): fix memory leak caused by unfreed buffers in CoreVideoSource
fix(video): fix slanted video when video size is not divisible by 8
refactor(video): use a new ToxAVFrame structure instead of vpx_image
refactor(video): static cast video dimensions to suppress warnings
feat(video): adds an ID parameter to the VideoSource class
refactor(video): internalize frame reference counting
feat(video): add accessor functions for sourceID and frameID
refactor(video): make type aliases public
refactor(video): use generics to simply VideoFrame conversion functions
refactor(video): rename ToxAVFrame to ToxYUVFrame and add documentation
refactor(video): update documentation to match new format (issue #3559)
refactor(videoframe): correct mistakes in commit documentation format
fix(video): fix a use-after-free with VideoFrame
fix(video): added declaration for missing biglock in CameraSource
docs(video): remove old unnecessary comment pertaining to removed code
fix(video): fix invalid VideoSource ID allocation
fix(video): specify color ranges for pixel formats that are not YUV
fix(video): use a QReadWriteLock to manage camera access
fix(video): force the use of non-deprecated pixel formats for YUV
refactor(video): update code and documentation to honour QSize validity
refactor(videoframe): move all inline/template functions into source
fix(video): guard storeVideoFrame() against freeing in-use memory
feat(video): add a isValid() function to ToxTUVFrame
Instead of misusing an existing structure from another library, defines
a new simpler structure that reflects the capabilities of the ToxAV
transport mechanism.
The filter_audio API is not working for qTox/Tox and thus disabled by default via compiler switch. In current qTox UI, it is not configurable, even when this switch is enabled. According to issue #3194 the library is no longer maintained as well. I don't see any reason to keep it in qTox.
We now subscribe to an event and wait for frames when capturing audio
input, the big avdantage is that we only have to fetch the frames from
the hardware once, and we don't need to cache anything.
The frames are simply dispatched to the client's callbacks immediately.
Also removes some outdated ifdefs that did not apply anymore.
qTox will automatically import the old history on startup.
This new database code is much more robust.
It is very resilient and will not corrupt or disappear after a crash or
power failure, unlike the old code.
The on-disk database format is also much more compact now.
The database sync option in the advanced settings has been removed,
we know run many database operations asynchronously so performance
should not be a problem anymore, but we always ensure resiliency
in case of abrupt termination, so there is no tradeoff anymore.
Double the allowed bitrate, this is especially noticeable on desktop streaming. Desktop streaming is still completely broken, with what looks like iframes silently getting dropped on a regular basis.
Retry 5 times to send a frame when there's an internal toxav lock sync error, this allows us to drop way less frames.
For some users on poor connections, toxav would suggest lower and lower bitratres until reaching zero and disabling audio/video entirely, toxav would then not raise the bitrate back and the only way to re-enable audio/video would have been to change A/V sources or restart the call
We now log toxav's recommendation, but ignore it
Could only be hit by pausing at a key point in a debugger until the call timed-out.
Having one thread going up the call stack and acquiring locks (toxcore callbacks), while another thread goes down taking locks in the other order (CoreAV calling toxav functions) creates some pretty freezy situations.
The deadlock was caused by the GUI thread calling the CoreAV thread, acquiring the CoreAV callback, then right before calling a toxav function, not schedule the thread until the call times out. At this point the toxcore thread fires its state callback to tell us the call is over, locking internal toxcore/toxav mutexes, it reaches our callback function which tries to switch to the CoreAV thread to clean up the call data structures, but has to wait since the CoreAV thread holds its own lock. At this point if we resume the CoreAV thread, it'll be busy calling into a toxav function, which tries to acquire internal toxav locks, those locks are held by the toxcore callback so we deadlock.
Our solution is that when getting a toxcore callback, we immediately switch to a temporary thread, allowing toxcore to release the locks it held, and that temporary thread tries to switch to do work on call data structures. Meanwhile if the CoreAV thread needs internal toxcore locks, it can get them.
A call cancel/accepted race was locking up both UI and AV threads, while the stream thread was shoveling more and more video frames on the AV thread's event queue
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
A race condition would result in trying to remove an element that didn't exist, and thus erasing end (undefined behavior) instead of erasing [end, end) (no-op)
That pull request made qTox crash in a number of ways, with no quick fix
available.
Hopefully there will be a way to fix crash, so that this commit could be
reverted, and fix applied.
And make it saner by not having one global password that has to be set before encrypting/decrypting, which is as racy and poorly designed as it gets
Fixes#1917 's immediate symtoms, which some potential for other regressions due to the mess that is encrypted persistence currently
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.
We now use a binary serialized format to save space and allow clean encryption of the user settings.
All the settings can (and should) be edited from the GUI so there is no loss of functionnality.
It can still read the old .ini format, and will seamlessly upgrade to the new format.
Fixes#1810
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.
