OBS Studio 28 no longer supports Windows 7, 8, or 8.1, and Qt 6 will
fail to run on those versions. Users on those systems being offered the
update will end up in a state where OBS will not run if they install the
update. Let's prevent the updater executable from running on those
versions to avoid that scenario.
This reverts commit a36b5bee99a03a22af50c1c5ed0d8f321d9c129c.
After this commit was merged, apparently devices were not functioning
correctly for some people. Especially regarding their internal settings.
Just revert it for now.
Apparently this annoying, stupid variable was leaking before the ComPtr
was added, which ironically was necessary to ensure devices worked.
After that ComPtr commit some devices stopped capturing properly.
Basically, it implies that this pointer needs to stick around while the
device is in use.
(Jim note: This was one of the most painful things I've ever had to
debug)
Do to multithreading the update process, files of the same hash can
sometimes collide due to race. Ensure the filenames are all unique by
appending an incremented value for each file.
The original change in obsproject/obs-studio#7200 seems to have been
based upon the idea that if the "selected" parameter has no values, then
the "deselected" parameter must have values, which is clearly an unsafe
assumption to have make given that it causes an assert crash in Qt when
both parameters have 0 values contained within them.
Individual sources cannot be used as vcam outputs (yet) due to the fact
that they cannot currnetly scale. If a source is not exactly the same
dimensions as the canvas, there will be blackness on the right and/or
bottom of the source. It's just not currently usable as-is.
Scenes are a much better fit for this because users can transform
sources within scenes as they please to fit the canvas.
At a later point, we'll likely reintroduce this feature as long as
they're automatically transformed or something.
It's about time to get rid of this being labeled as "(new)".
Also rename the FFmpeg variant. And make it more explicit when the
FFmpeg encoder is being used in the log file.
When using EGL the mesa+nvidia stack are unable to offload 32bit
framebuffers despite having this capability on GLX. In practice the X11
server does not support alpha windows so we dont need the alpha
component in our framebuffer. We previously had alpha specified in our
framebuffer since we do alpha texturing but testing shows this isnt
required for mesa/intel or nvidia drivers and we must pick a 24bit
config for users to enable render offloading for mixed gpu systems.
fixes#6984
The script and scene switcher lists were not being styled.
This also sets the spacing to 1 for the filter, script, scene
switcher and properties view lists, the same as other lists.
With the addition of server-side release rate control, having the server
know if the update check was manually initiated can allow it to deliver
the update to the user even if they would normally not be eligible.
Windows only.
When hovering over the source tree items, sometimes the preview
would show the item hovered, sometimes not. This is caused by
the SourceTree mouseMoveEvent/leaveEvent calling the same functions
as the SourceTreeItem enterEvent/leaveEvent, therefore competing
with each other, causing some jankiness.
With HEVC and H264 settings being near-identical, it was impossible to
figure out which codec was being used by context alone. This applies to
both ffmpeg output and jim-nvenc.
Fixes#6976.
The x() and y() values of coordinates for events inside a scrollable
QWidget are relative to viewport's scrolled origin, the coordinates of
the upper left corner of the visible space, not the widget's true
origin. Since we do not allow horizontal scrolling, the value of x() is
okay. However, the value of y() needs to be adjusted by an offset of the
top()/y() value for the first widget in the SceneTree. When not
scrolled, this offset will be 0. When scrolled down, this offset will be
a negative value.
The UI layout math used to determine if scrollbars should be displayed
in the Scenes Dock was off by one pixel. This caused the scrollbar to
disappear when performing actions while scrolled to the bottom, such as
dragging items or resizing the dock.
Calling resizeEvent for SceneTree after a dropEvent has occurred
prevents a dropped item from being displayed in the incorrect location
while in Grid Mode. There might be a better way to fix the incorrectly
displayed location of a dropped item, but we already do this in
SetGridMode and rowsInserted, so this is probably okay.
Attempting to resize the Sources dock to be smaller than when initially
loaded would result in the contents of the list to never shrink.
Switching to another scene & back would temporary fix the sizing.
Fixes an issue introduced in adba393ca8