Rather than plugging a matrix into the video input node, the matrix is now
multiplied by the video input using a math node. This is probably more
sensible from a user perspective.
This also means the renderer is tolerant of texture sizes that are not equal
to the sequence size, however most nodes will downsample the texture to the
sequence size (and if not, it will be downsampled once it is cached). Textures
will still *always* be in reference space and the sequence's format. This seems
like the best compromise between backend and frontend congruity.
A huge optimization that ensures only the parts of a node graph that have
changed get pushed to the renderer. For thread-safety, the node graph is
copied elsewhere so that users can make changes asynchronously and the graph
can update when its threads are ready. Up until now, if an input value changed,
every node's values would be re-copied, or worse, if a connection was changed,
the entire graph would be recopied. This has been negligible in testing since
we've been largely testing with small graphs, but for massive projects, it's
important that this be as optimized as possible.
This system was kind of janky anyway. It makes more sense ultimately for the
audio management classes to contain the file handle rather than the renderer.
As opposed to simply leaving all values in the table, nodes can now "take"
values that they use to free up memory (e.g. "taking" input buffers if they're
used to produce an output buffer).
This is a fairly large change, expect regressions.
The audio rendering system uses an event-based mechanism where if audio needs
to be converted (i.e. to a different sample rate), it will create a conform
task and re-render that section again when the audio is ready. Unfortunately,
the export code didn't respect this and would start encoding audio once the
initial queue was done. This usually resulted in silent audio, but could also
result in "uninitialized" audio that would crash any float-based encoders
(e.g. AAC). Now we use a different signal that only emits once the queue is done
AND all conforms are done.
Due to an oversight, incoming footage frames were NOT converted to the
working pixel format (usually half or float). For most frames, this meant the
OCIO conversion would occur on frames while they were still in their source
format (usually either RGB8 or RGB16). This leads to rounding error
inaccuracies, but even worse GLSL will clamp integer textures to 1.0 potentially
losing a lot of data.
While later nodes would correctly convert to the appropriate format, by then it
would be too late. This commit corrects this issue, converting the frames to
float during the OCIO shader pass.
itsmattkc