functions
Indexing is a lengthy process and had a high chance of getting RenderWorkers
stuck doing it rather than being responsive to cache requests. This commit
introduces a system where workers never index media, but instead signal that
media is not ready to their RenderBackends which ensure that the media gets
indexed and re-queues the affected frames when those indexes are ready.
Previously, FFmpeg decoders needed to wait for the initial index to finish
before they could retrieve frames. Now they can retrieve frames while the
index is occurring, provided the appropriate frame has already been indexed (if
not, the retrieve will need to wait still).
Our renderer system is already heavily multithreaded and prioritized to keep the
main thread active. As a result, FFmpeg receives little benefits from being
multithreaded and is actually detrimental to our main thread as it hasn't been
prioritized to keep the main thread as active as possible.
unexpected data
When "probing" footage, Olive runs it past all of its decoders until one
responds that it can decode this file. However this caused issues when some
OIIO decoders would erroneously pick up incompatible files, try to read them
and segfault the entire app (notable OpenJPEG with MPEG-4 and RLA with WAVE
audio). We now use the file extension to check with OIIO if it "should" be
compatible before actually testing if it is.
This is not a "perfect" solution (i.e. someone could recreate the segfault by
renaming an MPEG-4 file to an image extension like .JPG), but is probably as
much as can be done Olive-side and should filter out all segfaults under normal
circumstances.
OIIO 2.x uses std::unique_ptr while 1.x uses raw pointers. Olive can now handle
both, manually destroying the raw pointers when necessary if running on OIIO
1.x.
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.
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.
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.
The encoder was moved to its own thread and will transcode the PCM from the
audio renderer into the chosen codec while the video frames are still
received. The implementation isn't perfect and could use some cleaning up, but
it is functional at the moment.
itsmattkc