(This commit also modifies UI)
Changes groups to their own independent type, "group". This allows them
to be used like other regular types, and allows the ability to reference
groups in multiple scenes. Before, a group would always be linked to
the scene it was in. This made it cumbersome for users to modify groups
if they had a similar group in multiple scenes (they would have to
modify each group in each scene). Making groups like other source types
makes more sense to solve this issue so they can be referenced in
multiple scenes at once. This also removes a significant amount of
group-specific handling code required for implementing groups in the
front-end.
One limitation however: due to the way sub-items of groups are
seamlessly modifiable and sortable as part of the whole scene, the user
cannot have multiple references to the same group within one scene.
(This commit also modifies UI)
Removes obs_scene::group_sceneitem and replaces it with
obs_scene::is_group. Changes a number of other functions related to
groups so that a group is not inherently tied to a specific scene, and
helps allow a single group to be referenced in multiple scenes if
desired.
As of version 3, libvlc on macOS is linked against libvlccore
differently. Previously libvlccore was referred to via the @loader_path
macro, now @rpath is used. As such, dlopen is no longer able to find
libvlccore. Explicitly load libvlccore so that the symbols that
libvlc needs can be found.
Tested against VLC versions 2.2.8 and 3.0.3.
This fixes the pkg build of obs-browser by properly copying CEF to
`OBS.app/Content/Frameworks/Chromium Embedded Framework.framework`,
rather than `OBS.app/Content/Frameworks`.
This function returns a char *, so it should not be const (the value is
set from a function which also returns a char *, so there is no real
reason for this to be const).
This reverts commit 958167c4f7.
This caused certain transcoders (specifically Twitch's transcoders) to
misinterpret the data and transcode the video incorrectly.
Technically, setting the transparency value via a color property isn't
currently supported. However, some sources/filters will set their alpha
portion of their color value to 0, which would cause the color property
to have a transparent background. Set the alpha value to 255 for now,
at least until we properly implement support for setting transparency
via the color property (if we ever do).
With the recent change to fix showing color in the color property widget
when using different themes (b8f03791ea), a bug was introduced: when
opening filters with a filter that has a color property, it would sort
of "bug out" and recreate over and over. This is likely due to
something internally with Qt and the stacked layout. The stacked layout
really is not necessary, so remove the stacked layout and just use the
color label directly.
When the vertical volume meter was introduced it set in the OBSBasic.ui
mixer dock definition a min width/height that was valid for both
widgets. QStackedWidget hints the minimum size as the higher w/h
of its children so this workaround is necessary.
If the transition point was above or equal to 1.0, it would cause a
divide by 0 error a few lines down. This could cause audio data to
become corrupted with NAN audio data when mixing, which can cause
certain audio encoders (namely the FFmpeg AAC encoder) to fail.
It was possible for the transition point to be above or equal to 1.0 if
the stinger media file was no longer loadable for whatever reason.
When using a macOS running on a case-sensitive filesystem, the project
build fails due to AudioToolBox/AudioQueue.h not being found.
The correct path is AudioToolbox/AudioQueue.h. Since macOS comes with a
case-insensitive filesystem by default, this is a rare ocurrence
among developers who change it to be case-sensitive.
This little change skips returning true immediately when a call to
CoreAudio fails. Instead, it uses similar behavior as further 3 calls
below this change, just checking for unfreed pointers before also
returning true.
Back in an older commit, the default YUV colorspace was changed to 601
in order to ensure correct playback in video players that ignore the
contents of the H264 header.
x264's "undef" is unfortunately not what players that don't ignore the
header expect for BT.601, resulting in incorrect colors when played
back. Setting it to "bt470bg", similar to what is specified in ffmpeg
outputs, remedies this issue.