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.
When setting up the capture, the plugin will now query pulse for the default
format of the specific source instead of the server.
This is useful if a source has different settings than what the defaults are
for the server, e.g. when the source is an output with 5.1 surround sound
and the microphone input is mono while the server defaults to stereo sound.
the pos_x and pos_y variables were somewhat deceptive, because they were
not actually the poition of the cursor. They represented the position
of the cursor's bitmap on the screen, not the position of the cursor.
This implements audio support, allowing not only the ability to capture
the built-in audio from the video device's audio capture pin, but also
the ability to override the default audio with a custom audio device.
The DShowInput::Update function was split up and refactored a bit, as it
was getting a bit large and messy.
This fixes a bug where the pulseaudio plugin always reported
a speaker layout of stereo to obs, regardless of how many channels
pulseaudio actually recorded.
If the default number of channels was different to 2 this would
cause audio distortion.
Originally, I tested the fontconfig code on mac and it was working
swimmingly. However, it seems to be related to the fact that I am using
the ports/homebrew version of fontconfig. Most users do not have that
version, and instead use the system built-in version of fontconfig,
which apparently does not find any mac fonts.. at all. So, this
reverts the mac code to the older mac code we were using to manually
find and associate fonts with font files on the mac.
GCC marks fread as a function that will throw a warning if you do not
use its return value. This is most likely done as a measure to ensure
code security.
If tune or preset is invalid it'll just cause x264 to not load at all,
which I feel is a bit over the top. Instead, if the values aren't
valid, then just make it default to no tune if the tune is invalid, and
'veryfast' preset if the preset is invalid.
This should probably be reevaluated once we have
global hotkeys or other functions that would require
OBS to not be sent to sleep while in the background
without having any sort of encoder running
