The workers run in separate threads meaning if any significant change is made
(e.g. parameters changing, or even closing the program), these workers may still
be mid-render. This is particularly problematic when closing since the nodes a
worker is rendering may be deleted mid-render. Render backends now have a
function that pauses the main thread (but starts a second event loop so the UI
isn't frozen) until the worker threads are all finished. This way, massive
changes can be made safely without race conditions.
We try to handle aspect ratios in metadata (e.g. stretching 1440x1080 videos
out to 1920x1080 when requested), and FFmpeg will usually return a 1/1
aspect ratio even if it can't determine an aspect ratio. However, as mentioned
in the documentation, sometimes it returns a 0/0 aspect ratio when it can't
determine an aspect ratio, which we didn't handle and would lead to the code
allocating a buffer with a 0px height. This commit handles both 1/1 and 0/0
aspect ratios in accordance with the FFmpeg documentation.
Reference: https://www.ffmpeg.org/doxygen/4.0/structAVFrame.html#a62f9c20541a83d37db7072126ff0060d
`rational` is supposed to "fix signs" and "reduce" whenever its values are set,
but I neglected to do this when its values were set by an AVRational. Now it
will do so on both.
Implementation isn't perfect yet, viewer/renderer doesn't update yet when
the preference is changed so a sequence needs to be re-opened for the change to
take effect.
By using one thread per logical CPU thread, we seemed to completely saturate
the CPU which would kill the performance of the main/GUI thread (despite the
other threads being low priority). We now use half of the logical threads, which
still sees good CPU usage and minimal performance impact while allowing the
main thread to respond to user actions.
Footage is a special case where the node parameters can reference objects that
exist outside of the graph. Therefore specific code is needed to
serialize/deserialize.
The import function was written early on in the rewrite as a multithreaded
background task that was considered somewhat flawed. While it worked for the
most part, there were possibilities of race conditions that could have
potentially been fatal, particularly since media could theoretically be
deleted while the import/probe tasks were running in the background.
With the save/load functions coming in, it became even more complicated as
projects may include metadata about the footage that can't be implemented
easily when the footage is imported/probed in the background. Making importing
a modal task fixes all of these issues, it's still done in a background thread
to not hang the GUI thread, but the GUI thread can be briefly "paused" in a
user friendly way so that all these functions can be safer.
Since rationals aren't a known Qt format, the QVariant container can't
automatically convert them to and from strings (for XML serialization). We have
to hijack these functions and do the conversion manually for those types.
Also moved the block name type to a node input, which means it's serialized
and copied by default (I'm not sure why it wasn't already like this).
Since we load in a separate thread, when the QObject based objects are
instantiated, they're created with affinity to that separate thread. Now we
specifically ensure they are moved to the main thread after their creation.
Implemented the file dialog, save progress dialog, and separate thread to save
in (saving needs to be done in a separate thread so the main/GUI thread doesn't
get blocked).
We use Qt's built in zlib compression on the fastest setting (it was found that
higher compression took 5x as long with a negligible decrease in size). This
helps keep disk cache sizes low.
While there are clear efficiencies in storing the frame out of the codec,
there's little benefit to storing it in a format higher than its native pixel
format since the pixel conversion is generally fairly quick. This commit will
index all frames in their native pixel format.
A few commits ago, the render behavior was changed to only render within a
user-specified range of the playhead. This works well, but it would still
render from the start of the range (usually before the playhead) to the end,
meaning it couldn't keep up with the playhead as well as it should. This
commit prioritizes frames close to the playhead and renders outwards to
address this.
This index system will have awareness of the disk cache state and be able to
fill in and store frames as necessary while keeping the disk cache under
user defined limits.
Previously we had no disk management whatsoever, so we cleared the cache on
every close just to prevent clogging up tester disk space. Now that we are
implementing disk management, there are better things to do on close regarding
disk cache. However, some users may still wish for the app to delete the cache
on close, so it's provided as an option.
This functions more or less identically to using a media out value, but the
desired speed is preserved through block length changes, even if the block's
length is reduced to zero (i.e. no rounding errors).
itsmattkc