Cuts down on a lot of duplicate code between
TimelineWidget/ViewerWidget/CurveWidget/NodeParamView
and TimelinePanel/ViewerPanel/CurvePanel/ParamPanel since they all use similar
time functions.
When dragging a value in the UI, we use a "single frame update" because we want
to prioritize the currently visible frame to give visual feedback as soon as
possible. Previously, we generated a single frame InvalidateCache() signal
from the widgets themselves, but this had the major downside of not necessarily
emitting the time that the viewer was actually showing (due to either node time
transformations or times differing between the effects panels and the viewer
panels). Now, we send a different signal that viewers can handle themselves to
update the time that they're currently showing. This means the fast updating
will work no matter how many viewers are connected at whatever time each viewer
is set to.
Previews don't need to be rendered full resolution, particularly since the
preview is hardly ever 1:1 size of the sequence. The functionality to render
at lower resolutions already existed, but there was no UI for it. This commit
implements UI to set the resolution divider on the viewer.
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.
transparent cuts through the main window on linux
For some reason, setting not visible *after* setting floating would cause this
issue. The other way around does not.
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.
When adjusting a slider, keyframe time, or curve value, it is undesirable to
re-cache the entire affected area while the user is still dragging UI objects.
Since the video is unlikely to be playing, the priority must go to the
currently active frame so the user gets visual feedback on the rendered image
as soon as possible. This was implemented in some areas, but this commit should
have that functionality in all areas.
The workers run in separate threads meaning if any significant change is made
(e.g. parameters changing, or even closing the program), these workers may still
be mid-render. This is particularly problematic when closing since the nodes a
worker is rendering may be deleted mid-render. Render backends now have a
function that pauses the main thread (but starts a second event loop so the UI
isn't frozen) until the worker threads are all finished. This way, massive
changes can be made safely without race conditions.
We try to handle aspect ratios in metadata (e.g. stretching 1440x1080 videos
out to 1920x1080 when requested), and FFmpeg will usually return a 1/1
aspect ratio even if it can't determine an aspect ratio. However, as mentioned
in the documentation, sometimes it returns a 0/0 aspect ratio when it can't
determine an aspect ratio, which we didn't handle and would lead to the code
allocating a buffer with a 0px height. This commit handles both 1/1 and 0/0
aspect ratios in accordance with the FFmpeg documentation.
Reference: https://www.ffmpeg.org/doxygen/4.0/structAVFrame.html#a62f9c20541a83d37db7072126ff0060d
`rational` is supposed to "fix signs" and "reduce" whenever its values are set,
but I neglected to do this when its values were set by an AVRational. Now it
will do so on both.
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.
By using one thread per logical CPU thread, we seemed to completely saturate
the CPU which would kill the performance of the main/GUI thread (despite the
other threads being low priority). We now use half of the logical threads, which
still sees good CPU usage and minimal performance impact while allowing the
main thread to respond to user actions.
itsmattkc