Change MediaInput::footage() to MediaInput::stream() and
MediaInput::SetFootage() to MediaInput::SetStream() as they access
streams not footage.
Also update all instances of access methods to reflect this change.
Image streams were initially separated from video streams, but they're now
joined with a parameter defining if they're a still image, image sequence,
or regular video. The image sequence import process has also improved so
that if images from the same sequence are imported too, they'll either be
ignored or the user won't be asked again for those if they should be an
image sequence (fixes#1193). Also shifts decoder "probe" process to return
an item, useful if the decoder returns a non-footage item.
Shifted from CacheTask to functionality built into RenderBackend. It was
a lot easier to control behavior this way without having to juggle a ton
of threads and race conditions.
Could likely be multithreaded further.
I think there was an earlier commit with a similar name but turns out
I'd only done foundational work in that commit and never actually
properly set it up. Of course once I did, there were several issues that
needed fixing to make it work correctly, but now it works as expected.
Heavily optimizes larger projects by allowing cache jobs to only copy
what has changed.
Since auto-cache events start and stop fairly frequently (and are somewhat
heavy to create/destroy), we can save a lot of cycles over time by sharing
the same backend between them all.
There were a lot of issues that arose from trying to make GUI changes
from another thread (even though we ran those functions in the right
thread). Now we store layout information until the end of the load and
make the changes then. This works much better from both a business logic
and user experience perspective.
Also prevents multiple sequences from taking focus during load and
starting a render job.
Previously, audio was all queued first and would therefore all have to
finish before any video frames could start caching. No longer! Now they're
queued side by side so users won't have to wait for audio to finish before
their cached frames come in.
These are two changes that speed up when frames start getting rendered
and processed (particularly for larger scale projects):
* Sorting of time beforehand was done to optimize decoding but is actually
unnecessary since the frames are already sequential when they're retrieved
from the range. As long as we maintain that order, no sorting is required.
This speeds up caching IMMENSELY.
* Evaluate hashes concurrently while retrieving frames. Before, this was
done before any rendering and could therefore delay rendering by several
seconds. Doing them concurrently means frames start rendering almost
immediately and further hashes can be analyzed while we wait for frames to
finish rendering.
With this commit, we save to a temporary file first and then cat the end
run a copy to overwrite the source file. If the save somehow fails or the
program crashes mid-save, this will prevent the user's project file from
getting corrupted.
Removed proxy task and replaced with a true honest-to-god pre-cache for
footage. This footage is pre-cached to a sequence and therefore 100% ready
for use in it once the task is done.
itsmattkc