If size is 0 after popping data from the front or back, set the
start/end points to 0 as well to ensure that any subsequent buffer
pushes start from the beginning of the buffer rather than the middle of
the buffer. Reduces potential unnecessary operations in that case.
Additionally, this fixes a bug with circulebuf_pop_back where if start
position was 0, and all the data was popped off the buffer (equal to the
capacity), the end position would be equal to the original size. As an
example to replicate the bug, push 5, pop 5, then push 10. The
start/end points will be invalid.
Closesjp9000/obs-studio#954
If a source is created with settings, default values would not be set on
data items that already had values set. The check here was supposed to
be a not equal rather than an equal because you're not supposed to be
able to set a default value of one type on an item that already exists
but is of a different type.
This bug would make it so that if a particular setting was removed,
there would be no default value to fall back on, and it would always be
0 or NULL for all values.
It's likely this bug wasn't encountered until now because before now
there had been no reason to clear or remove settings on most things.
(Edit by Jim: Removed "Fullscreen Preview" because that's already sort
of served by the normal fullscreen projector option via the preview
context menu)
Closesjp9000/obs-studio#846
(Edit by Jim: Changed it to just add the fullscreen projector sub-menu
like when right-clicking the preview, that way it doesn't have to add
new locale text for translators, and allows the users to specify which
monitor to use)
Closesjp9000/obs-studio#845
If a video card is unsupported, it will attempt to initialize the stats
window, querying values from a video subsystem that doesn't exist, and
crash instead of alerting the user that their hardware is unsupported.
Sometimes when rebuilding a texture, it often has to fall back and
create a temporary texture, but it'll fail when trying to create a
shader resource for it. The suspicion is because it's due to not having
the proper shader binding flag when creating that temporary texture, so
this fixes that possible loophole.
There's no need to display this property at the moment, the default
amount is more than sufficient for most cases. That and most people
wouldn't know what to do with it anyway.
This version fixes the code applying the streaming services settings, which would incorrectly always be applied due to left over obs_data_set_* lines. It also adds a safety check into SetIDRPeriod for H264 that fixes being able to set an IDR Period of 0 which is simply not supported (we would never be able to stop streaming or recording).
If the user changes one of the devices in audio settings, it would reset
all of its data, including settings, filters, flags, and all that. This
changes the handling so that the source and all of its other settings
are preserved if the user just changes the device. (Note that if the
user disables the device, settings will be lost; this only applies to
when the user changes the device to a different device for whatever
reason)
In the media source, do not pre-cache frames if the source is set to
close the file when inactive because that setting is designed to allow
the file to be replaced by the user. If it's replaced, it can
unintentionally keep the old precache frame, playing the frame from the
older video when it starts up.
When the statistics window starts up for the first time, it reset values
at that very moment so that stray lagged frames due to OBS' startup
wouldn't be displayed. However, that's really a bad place to reset
those values because the user could want to view the stats window after
a long stream, and having those values reset when he/she views the
window for the first time would sort of make the point of viewing your
stats moot.
Instead, reset the values only when applicable, such as after OBSInit or
when video is reset.
When hooking DXGI-based graphics programs in the hook, the first hook
point is IDXGISwapChain::Present. To be able to initiate a capture, a
pointer to the device context that created the swap chain is required,
which can be retrieved via IDXGISwapChain::GetDevice. Determining
whether the device context was D3D10 or D3D11 has always been somewhat
of an issue due to D3D10 and D3D11 being nearly identical, as well as
their interoperability/interchangeability. The GetDevice function would
first be called with the UUID of ID3D10Device, then if that failed,
the UUID of ID3D11Device.
However, with certain specific D3D11 games, GetDevice would for some
unknown reason succeed with the UUID of ID3D10Device, which would cause
capture to fail. (Conversely, attempting to call GetDevice with the
UUID of ID3D11Device on a device that's actually ID3D10Device would
always succeed, so reversing the order of the test was not an option).
There were originally three known D3D11 games that would erroneously
succeed when querying a D3D10 device interface: Call of Duty: Ghosts,
Just Cause 3, and theHunter: Call of the Wild. All other known D3D11
games would work correctly. Because it was only these three games, a
hack was originally implemented in the form of an executable exception
list that would force them to capture D3D11.
Unfortunately, Oculus games are now failing under the same circumstance
as well, so a simple hack will no longer work. To fix this, a more
reliable method of detecting which context it is had to be discovered:
simply check the feature level using ID3D11Device::GetFeatureLevel. If
the feature level is D3D_FEATURE_LEVEL_11_0 or D3D_FEATURE_LEVEL_11_1,
the device is definitely a D3D11 device. Otherwise, continue the tests
as they were before. Successfully tested with many D3D10 games, many
D3D11 games, and especially those three D3D11 games that previously were
detected as D3D10 erroneously.
VS2017 supports this natively.
VS2015 and earlier can use this with the editorconfig extension.
Most other popular IDEs support this natively or via a plug-in.
For more details please visit: http://editorconfig.org/
Preloading is designed to overwrite the current internal render texture
of the source so it'll be ready to play the first frame right when the
source is first displayed.
However, When the media source is set to pause on the last frame, it
keeps that current render texture visible, so preloading it with the
first frame will essentially overwrite the current render, causing it to
inadvertently show and pause on the first frame rather than the last
frame. So instead, just disable preloading when the user has it set to
pause on the last frame.
The recent changes in 88ae9af causes av_read_frame to check for
m->stopping, and fail with AVERROR_EXIT if true, which would happen
after each reset. Moving mp_media_prepare_frames to a line after
m->stopping is reset to false fixes the issue.
With certain media files (wmv in particular), the very last frame will
have a timestamp of AV_NOPTS_VALUE. This could cause the media to stick
on that frame indefinitely. Instead, use the estimated next timestamp
that was calculated in the previous frame.
Media files that have a very low framerate or very long interval between
frames would cause the media playback to stall indefinitely until the
next frame is played. This adds a 200ms timeout to ensure that the
media can be destroyed without being forced to wait indefinitely for the
next frame.
