Implements a very basic GLSL deinterlace that simply halves the vertical
resolution and then interpolates between the fields. This can be toggled
on or off.
The reasons for being so basic is:
- Speed, very quick code running in OpenGL
- It would seem the highest quality deinterlacers are temporally based
which doesn't make much sense for the viewer, particularly since we can't
double the frame rate since our timecode is fixed to the frames.
Higher quality interlacing/deinterlacing will be present in the actual
renderer.
Implements the following:
- Sequences have pixel aspect ratios that work in tandem with footage PARs
to render footage correctly. Viewer and export also acknowledge PARs
- Sequences can have interlacing settings. This doesn't do anything yet,
eventually the renderer will need to interlace/deinterlace/reinterlace
appropriately in order to conform all the footage to the sequence. Export
acknowledges interlacing, but this only affects metadata, not the image.
We had support for detecting aspect ratios and respecting them in the
render, but this allows people to not only see the aspect ratio in use,
but also override it with their own.
General code and functionality improvements. Moved more code out of the
OpenGL backend for portability. Implemented audio transitions.
Implemented basic transition animation curve settings.
Previously the OpenGL instance was tied to each render/cache task,
creating and destroying it each time one started and stopped. This was
completely unnecessary since the instance holds no state and can be
shared by all of the render tasks without having to expensively start
a new one.
The nodes now have more control over how their accelerated shaders/sample
functions are run, as well as how items are popped off the value tables.
This allows for various optimizations that we didn't have access to before.
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.
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.
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.
itsmattkc