Notable changes:
* deps.windows: Disable x86 build slice for dependencies
* deps.qt: Disable x86 build slice for Qt6
* CI: Remove Windows x86 slices for Qt6 and FFmpeg builds
* deps.ffmpeg: Disable Windows x86 build slice for FFmpeg dependencies
* deps.ffmpeg: Update libvpx to v1.14.1
* deps.ffmpeg: Update SVT-AV1 to 2.2.1
* deps.ffmpeg: Update aom to 3.9.1
* deps.ffmpeg: Update AMF to 1.4.34
* deps.ffmpeg: Update FFmpeg to 7.0.2
* deps.macos: Update LuaJIT to 2.1 f725e44cda
* deps.macos: Update FreeType to 2.13.3
* deps.macos: Update Asio to 1.31.0
* deps.macos: Update qrcodegen-cmake to v1.8.0-cmake3
* deps.macos: Update Sparkle to 2.6.4
* deps.qt: Update Qt to 6.7.2 for macOS
* deps.qt: Update Qt to 6.7.2 for Windows
* deps.windows: Update FreeType to 2.13.3
* deps.windows: Update curl to 8.9.1
* deps.windows: Update LuaJIT to 2.1 f725e44cda
* deps.windows: Update Asio to 1.31.0
* deps.windows: Update qrcodegen-cmake to v1.8.0-cmake3
* deps.windows: Update WIL to v1.0.240803.1
* deps.ffmpeg: Remove MbedTLS CMake files from macOS FFmpeg package
Also update Sparkle to match the obs-deps version.
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
Packet callbacks are invoked in `send_interleaved()` and
are useful for any plugin to extend functionality at the
packet processing level without needing to modify code in
libobs. Closed caption support is one candidate that is
suitable for migration to a packet callback.
The packet callback also supports the new encoder packet
timing feature. This means a registered callback will have
access to both the compressed encoder packet and the associated
encoder packet timing information.
Introduce support for the `encoder_packet_time` struct
to capture timing information for each frame, starting
from the composition of each frame, through the encoder,
to the queueing of the frame data to each output_t.
Timestamps for each of the following events are based on
`os_gettime_ns()`:
CTS: Composition time stamp (in the encoder render threads)
FER: Frame encode request
FERC: Frame encoder request completely
PIR: Packet interleave request (`send_interleaved()`)
Frame times are forwarded through encoder callbacks in the
context that runs on the relevant encoder thread, ensuring
no race conditions with accessing per encoder array happen.
All per-output processing happens on data that is owned by
the output.
Co-authored-by: Ruwen Hahn <haruwenz@twitch.tv>
Prevents Display capture from capturing the first display on creation.
This issue is due to the properties view combo box automatically
selecting the first item in the list by default, but this needs explicit
text anyway to indicate display, so this adds a "[Select a display]"
item that will prevent that from happening and tell the user to select a
display.
This is due to the property view widget not having an item to select, so
it selects the first one, but we want to have specific text for this
anyway, so changing it here is still appropriate. (I don't want to touch
the properties view widget right now for the sake of my sanity)
Like xcomposite, this was programmed to select the first display by
default. Change it to not capture any display unless explicitly selected
by the user.
There are two situations where xcomposite window capture will capture
random windows: on first creation, and when going to the properties when
the current window is invalid. The first happens because for whatever
reason someone decided to just make it capture the first top-level
window if there is no set value. The second happens because the
properties widget cannot find the value it's looking for and defaults to
the first one when the properties are opened, thus selecting and
capturing the first window in the list (which is probably something we
should fix in the properties view at some point but I don't want to dive
into code that's even *more* cursed than xcomposite code right now)
I think that this was a major oversight and that whoever wrote it
however many countless years ago did not realize that this is something
that maybe users don't want to have happen.
So instead, this diff makes it so that on first creation, it creates a
value that says "[Select a window to capture]" that keeps the capture
inactive until a user actually chooses a window rather than the
top-level window. It also makes it so that if the user has a window that
is no longer valid, it will keep that window in the list and as the
currently selected value, which prevents it from automatically selecting
the first window in the list when properties are opened.
(Have I mentioned xcomposite is cursed? Trying to debug xcomposite code
in a debugger freezes my window compositor and forces me to do a hard
restart of my entire computer, so I was forced to use printf debugging.
Absolute nightmare-inducing code in here.)
This is cursed. Window ID storage for xcomposite capture is absolutely
cursed. It should not be storing the window handle with this. I'm pretty
sure that whoever wrote it at the time decided to store the god-forsaken
window handle (which does not persist after the window closes) as part
of the ID because they were afraid it might capture the wrong window if
they close OBS and open it up again while the window still exists.
Again, xcomposite capture is absolutely cursed.
Moves the window handle/name/class decoding code out of the
xcb_find_window() function and into its own dedicated function so it can
be used elsewhere. This s*** is cursed.
The CEF module is also modified to:
- Use the pre-built wrapper included in the tarball
- Preserve debug symbols inside its binaries
- The copy done later by OBS Studio build-system will be split from
its debug symbols
98d94a4 - Enable Qt message loop on Linux
8e2b31f - Set the right Ozone platform on Linux
6451941 - Wait on shutdown for docks to close on Linux
174e6a8 - Remove CMake legacy code path
e4e523d - Update version to 2.24.2
Changes the icon rendering for the properties view "question mark" icon
from Qt label HTML to use the IconLabel widget. This makes the label
high DPI.
Unfortunately the properties view code is a complete nightmare and in a
way, this PR makes this worse by adding the "leftWidget" widget as a
placeholder for what the "normal" label used to be, but you can't easily
replace that label with the icon label (while retaining prior
modifications from other nightmare code) so here we are. The entire
thing needs to be burnt to the ground and be rebuilt from the ground up
but that's a task for another day.
Deprecated in 28.0, documentation erroneously states 27.2.
The following functions were erroneously not marked as deprecated in
the header:
- obs_sceneitem_set_show_transition()
- obs_sceneitem_set_show_transition_duration()
A recent obs-deps change removed all non-essential x86 deps. This caused
the x86 subproject(s) on Windows to fail to configure due to being
unable to find x86 dependencies that do not exist.
Co-authored-by: PatTheMav <PatTheMav@users.noreply.github.com>
The code prior to this change would never add virtualcam.c to the
win-dshow target, which resulted in the virtualcam_output not being
registered and thus Virtual Camera not working.
Co-authored-by: PatTheMav <PatTheMav@users.noreply.github.com>
Ruwen Hahn
tytan652
Ryan Foster
Alex Luccisano
Lain
derrod
gxalpha
