Unlock the full feature set of the YouTube Chat dock in OBS by removing
custom scripting/CSS logic. Enable the signed-in experience for live
streaming content creators while also sharing login credentials with the
YouTube Control panel dock.
This will allow OBS users to utilize features _already_ supported in the
YouTube Chat plugin, such as
* creating polls
* managing Q&A sessions
* a rich emoji set in the input panel
* emoji fountains
* moderation tools
and many more. These features are available to users who are logged-in
to YouTube Chat and/or the YouTube Control panel.
Use the cookie manager shared by service integration browser docks for
YouTube Control Panel.
This will enable users of the YouTube Chat panel have a better (creator
facing) experience for observed chat message latency, for those users
who sign-in to the YouTube Control Panel or YouTube Live Chat.
NOTE: This commit does not have any migration logic for existing
logged-in users of YTCP, they will need to sign-in again. Based on usage
stats, this is not going to affect a large fraction of OBS users.
Instead of first creating the scene item and then finding it again using
a method that's generally problematic (and only works here because we
know that there is only one instance of a source), let's just remember
the scene item in AddNew after we create it, similar to the source
itself.
Scene collection names that are not considered "safe" by OBS Studio
get a changed JSON file name with incompatible characters replaced.
The refactored scene collection implementation uses the Load function to
either activate an existing scene collection or create a new one if it
does not exist.
The Load function however overwrote the scene collection name set in
the profile with its own variant based off the "safe" file name, which
created a mismatch with the code that created the collection data
model.
As the Load function is only called by ActivateSceneCollection (which
itself already sets the name and filename for the collection), removal
of this superfluous code in the Load function also fixes the issue.
Windows and Linux allow the storage of configuration files relative
to the binary location, which is enabled by default on Windows and has
to be explicitly enabled on Linux.
This was originally conflated with the LINUX_PORTABLE build setting
which also allowed the application itself to be run from non-default
locations on a Linux system.
This change reintroduces the functionality behind the
ENABLE_PORTABLE_CONFIG build setting on Linux.
It also adds necessary code to make this setting compatible with the
recently introduced relocatable settings code changes:
When portable mode is enabled, user configuration, scene collections,
and profiles are stored in the config directory created for portable
mode.
`std::clamp` was introduced at 60a45d3aa3 but it caused a runtime
assertion failure on Windows that checks the low value of `std::clamp`
is not greater than the high value.
MbedTLS changed a lot of internals with their LTS version 3.6.0, which
are incompatible with the find module currently shipped with
OBS Studio.
The solution requires several changes to be applied at once:
* Rename the generated target name to MbedTLS::mbedtls to match the
name used by MbedTLS' own CMake package
* Update find module to use the updated target name(s)
* Set CMAKE_FIND_PACKAGE_PREFER_CONFIG to TRUE before trying to find
MbedTLS to ensure that CMake package files are used with priority
(Those are shipped only with MbedTLS 3.6.0 in obs-deps).
* A deprecation warning is emitted if the find module is used with
MbedTLS 3.6.0 available
This change enables loading scene collections from locations different
than OBS' own configuration directory.
It also rewrites profile management in the app to work off an in-memory
collection of profiles found on disk and does not require iterating
over directory contents for most profile interactions by the app.
This change enables loading profiles from locations different than
OBS' own configuration directory.
It also rewrites profile management in the app to work off an in-memory
collection of profiles found on disk and does not require iterating
over directory contents for most profile interactions by the app.
This introduces a split of the current single ConfigFile instance for
all configuration into two separate instances.
The app config instance contains system-wide settings that mainly
concern the working of the app itself, whereas the user config instance
contains settings actually exposed to the user for the configuration.
When using the Auto-Configuration Wizard with the
Twitch service, testing for Enhanced Broadcasting would
always run, even if deselected. Add a conditional check
to only run the test if selected.
This doesn't generally make the speedtest work for Amazon IVS, since
most Amazon IVS channels will be disconnected if the bitrate being
sent exceeds the upper limit for that channel.
Introduce support for delivering BPM (Broadcast
Performance Metrics) over SEI (for AVC/H.264 and
HEVC/H.265) and OBU (for AV1) unregistered messages.
Metrics being sent are the session frame counters,
per-rendition frame counters, and RFC3339-based
timestamping information to support end-to-end
latency measurement.
SEI/OBU messages are generated and sent with each IDR
frame, and the frame counters are diff-based, meaning
the counts reflect the diff between IDRs, not the running
totals.
BPM documentation is available at [1].
BPM relies on the recently introduced encoder packet timing
support and the packet callback mechanism.
BPM injection is enabled for an output by registering
the `bpm_inject()` callback via `obs_output_add_packet_callback()`
function. The callback must be unregistered using
`obs_output_remove_packet_callback()` and `bpm_destroy()`
must be used by the caller to release the BPM structures.
It is important to measure the number of frames successfully
encoded by the obs_encoder_t instances, particularly for
renditions where the encoded frame rate differs from the
canvas frame rate. The encoded_frames counter and
`obs_encoder_get_encoded_frames()` API is introduced
to measure and report this in the encoded rendition
metrics message.
[1] https://d50yg09cghihd.cloudfront.net/other/20240718-MultitrackVideoIntegrationGuide.pdf
When a source file contains an explicit include with a filename
following the "moc_<actual-filename>.cpp" pattern, then CMake's
AUTOMOC generation tool will recognize the matching pair and generate
the replacement header file and add the required include directory
entries.
For all files which do contain Q_OBJECT or similar declarations but do
not have an explicit include directive, the global mocs_compilation.cpp
file will still be generated (which groups all "missing" generated
headers).
The larger this global file is, the more expensive incremental
compilation will be as this file (and all its contained generated
headers) will be re-generated regardless of whether actual changes
occurred.
This adds scrollbars to the preview, so users can move around the
preview without using the spacebar + clicking.
Co-Authored-By: Clayton Groeneveld <19962531+cg2121@users.noreply.github.com>