I had this issue where IDXGISwapChain::ResizeBuffers would fail in the
hooks, causing games to crash when they resized their backbuffers
because ResizeBuffers would return an 'invalid call' HRESULT value. In
the ResizeBuffers documentation it says that it will only happen if a
backbuffer currently has any outstanding references, but there's no way
this would happen unless ResizeBuffers internally calls Present or vise
versa.
After ResizeBuffers has been called, the very first call to Present will
somehow seemingly invalidate and/or destroy the current backbuffer.
It's very strange, but that seems to be what's going on, at least for
the game I was testing. So if you are performing a post-overlay
capture, then you must ignore the capture on the very first call to
Present.
It's Microsoft's code so you can't really know what's going on, you just
have to work around these strange issues seemingly in the dark.
Currently, this allows the setting of values such as:
- Audio buffering time
- Color format (still somewhat unsupported)
- YUV color space (if a YUV format)
= YUV color range (if a YUV format)
More color formats will be added in the future, such as RGB and YUV
4:2:2 formats.
Martell changed this function without realizing that this was calling a
function below it, not recursively calling itself. The reason why he
got the warning was because there was no forward declaration of the
function that was being called; I think he's used to C where only one
function definition can exist with the same name. In this case, it was
another function with the same name but with different parameters,
something that's permitted in C++. I wish I had realized this sooner.
This fixes the crashes people have been having with devices.
This fixes the issue where the labels wouldn't have enough space for
localization text in certain circumstances, and also fixes some issues
with alignment
When using multiple video encoders together with a single audio encoder,
the audio wouldn't be in sync.
The reason why this occurred is because the dts_usec variable of the
encoder packet (which is based on system time) would always be reset to
a value based upon the dts (which is not guaranteed to be based on
system time) in the apply_interleaved_packet_offset function. This
would then in turn cause it to miscalculate the starting audio/video
offsets, which are required to calculate sync.
So instead of calling that function unnecessarily, separate the check
for whether audio/video has been received in to a new function, and only
start applying the interleaved offsets after audio and video have
actually started up and the starting offsets have been calculated.
Add a checkbox named "Enforce streaming service encoder settings"
checkbox to advanced output. Disabling this checkbox allows the user to
optionally disable the enforcement of streaming service encoder
settings. I had a user complain that they didn't want to always have
the service's preferred encoder settings forced on them.
Ensures that the current service's encoder settings are applied to the
encoders used with the simple output. This is always on for simple
output so users don't have to mess with it themselves.
clicked() is the wrong signal to use, it only activates on actual user
click, not when the value is changed. toggle() activates whenever the
value itself is changed.
Instead of having services automatically apply encoder settings on
initialization (whether the output wants to or not), instead make it
something that must be explicitly called by the developer. There are
cases where the developer may not wish to apply the service-specific
settings, or may wish to override them for whatever reason.
