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).
frames
Previously, when the video renderer received a dirty cache signal, it would
proceed to extract all frames from the range and queue them. However, this could
be extremely slow for long ranges since it had to iterate through the entire
range and calculate the individual frames it contained. Now, we use the same
range combining system as audio and automatically calculate the next frame
within the range only when necessary. Essentially the same work, but split up
over time and done only when needed leading to no discernible UI pause when
invalidating cache.
Previously the audio output manager was a "hybrid device" that acted as a pull
device for audio devices and as a push device and device proxy for the rest of
the application. This approach turned out to be flawed, particularly in the
frequent opening and closing of the audio device (extremely slow). Since we
use both pulling (for constant playback) and pushing (audio scrubbing, short
bursts of sound), it needed a similar but different approach. This approach
will switch the output device from push mode (default) to pull mode (during
playback) only when necessary resulting in far less UI lag (basically
unnoticeable now) than the previous approach.
itsmattkc