This replaces the ARB_separate_shader_objects extension with traditional
linked shaders. I was able to get the existing system to use linked
shaders without having to change any libobs graphics API.
This essentially creates a linked list of shader programs with
references to the shaders they link. Before draw, it searches that
linked list for a particular pixel/vertex shader pair, and the linked
program associated with it. If no matching program exists, it creates
the program.
Adds:
ENABLE_UI (on by default) which makes it so that the UI is required, and
will fail if a dependency is not found. This is on by default because
most people are building it with the user interface, and we'll probably
get a lot of issue reports stating "why is there no executable?" if we
don't have this on by default.
DISABLE_UI which forces the UI off.
If neither are set, then the UI will only be built if the dependencies
for it are found, otherwise the UI will be be ignored.
This prevents certain issues I've encountered with devices where they
expect to shut down in a specific thread they started up in, as well as
a number of other issues, such as the configuration dialogs.
The configuration dialogs require that a message loop be present, and
this was not the case previously because everything was in the video
thread, which has no windows-specific code.
Configuration/crossbar/etc dialogs will now execute correctly.
This adds support for dynamic format changes on the fly. Format,
resolution, sample rate, can all now be changed by the current
directshow device on the fly.
On an asynchronous video source, the source resolution is automatically
handled by the core, and set to the resolution of the last video data
that was sent. There is no need to manually specify a resolution.
This is not a com pointer; it should not release/close the handle when
an & operator is used, it should only return the handle value. Clearing
is only used on assignment.
This helps ensure that an asynchronous video source is played as close
to its framerate as possible, reduces the risk of duplication as
much as possible, and helps to ensure that playback is as smooth as
possible.
This prevents multiple needless calls to obs_source_get_frame and other
functions. If the texture has already been processed, then just render
it as-is in any subsequent calls to obs_source_video_render.
This is actually unnecessary now that there's a hard limit on the
maximum offset in which audio can be inserted.
This also assumes too much about the audio; it assumes audio is always
on, where as with some devices (such as the elgato) audio is not on
until the stream starts, and when the video has already incremented the
counter.
Audio that goes below the minimum expecting timing (current time -
buffering time) is automatically removed. However, delayed audio is not
removed regardless of its delay. This puts a hard cap of 6 seconds from
current time that the maximum delay audio can have. This will also
prevent the circular buffer from dynamically growing too large.
Followup to d56432304e6e8ae00ea66bef8c1847894e5cac9f, it apparently
still crashed (on slower machines?) when closing the properties window
via mouse (by clicking the X button)