Switching to a static library that contains version information as
const char strings has multiple benefits:
* The version information provided externally via compiler definitions
will fail compilation early if malformed
* An updated version string (which will happen with every commit) will
not invalidate existing compilation units, because only the static
library is affected by the change
* An update of the version change just requires a recompilation of the
static library and a linker update
* An update of the version will _not_ infect the rest of the codebase
(as it does currently, because everything includes obsconfig.h one
way or another)
* Other modules which used the macro definition directly have been
updated as much as possible to use the proper getter method from
`libobs` instead (some Windows-specific modules use preprocessor
string composition, the value has been added as a compiler definition
directly in those cases)
* Because the impact of a version change due to a commit hash change
is limited to the static library, ccache hit rates should be
improved considerably
The pixel buffer pool is used to create pixel buffers with both the CMIO
extension and the DAL plugin. As such, it is created independent of
which camera type is used, and should be released independent of it as
well.
Meta have filed a patent application on the Go Away feature. This goes
against the spirit of free software and puts the use of this feature in
questionable legal status, so let's remove this code until the patent
situation is resolved.
This reverts commits a593fe6755 and
dada82fec1.
Using UUIDs to store display references in obs-studio's settings file
allows us to "rediscover" devices even between restarts
(as CGDirectDisplayID changes between those) and select the same device.
This deprecates the following functions, replacing them with new
versions:
- `obs_output_can_begin_data_capture()` - now `*capture2()`
- `obs_output_initialize_encoders()` - now `*encoders2()`
- `obs_output_begin_data_capture()` - now `*capture2()`
The flags parameter was initially designed to support audio-only or
video-only operation of an output which had the `OBS_OUTPUT_AV` flag,
however, full support for that was never implemented, and there are
likely fundamental issues with an implementation, mainly that most
outputs are programmed assuming that there will always be at least one
audio and one video track. This requires new flags specifying support
for optional audio/video, among other things.
An implementation to allow audio/video to be optional is best done
using the flag technique above, with audio/video enablement specified
by whether media (raw, `video_t/audio_t`) or encoder (`obs_encoder_t`)
objects are specified.
Since every implementation I could find always specifies `flags` as 0,
I was able to safely conclude that immediately removing the parameter's
functionality is safe to do.
The name of the obs_output_t won't appear in usual operation but some
output types have the translation and others do not. Let's translate
them.
Also translate `FilePath` property name.
A commit 4e140d2ff added AMF error messages but they were never used.
A commit 45d029b1f removed some code but a translation key "Advanced"
was left.
A commit 77fbfbe5c removed code to translate NVENC.TooManyBFrames but
the translation key was left.
A commit 6cc7cf3d5 removed the code to select codecs but the translation
was left.
Camera Extensions require specific entitlements for the hosting app,
which also require a provisioning profile. To avoid breaking local
builds that do not require the camera extension, an additional
entitlements file that will not trigger the provisioning profile
requirement will be used if the virtualcam (but not the Camera
Extension) is configured.
PipeWire supports 10bit colour formats with little endian order.
Adding two new formats required increasing the buffer size for building
PipeWire buffers.
This formats are supported since PipeWire 0.3.41. To allow building
against
older PipeWire versions we will hide those formats. Complications when
running on a host with an older PipeWire version are not expected, since
format negotiation is only done via the numerical values.
If P216 or P416 color formats are selected with QSV, these color formats
were not explicitly handled, so the switch statements would end up in
the default case. If the user had also selected a Rec. 2100 color space,
this would result in the strange error message:
"OBS does not support 8-bit output of Rec. 2100."
This message is confusing and does not correctly reflect the chosen
settings. Let's explicitly handle the P216/P416 cases and provide a more
accurate error message.
If P216 or P416 color formats are selected with AMF, these color formats
were not explicitly handled, so the switch statements would end up in
the default case. If the user had also selected a Rec. 2100 color space,
this would result in the strange error message:
"OBS does not support 8-bit output of Rec. 2100."
This message is confusing and does not correctly reflect the chosen
settings. Let's explicitly handle the P216/P416 cases and provide a more
accurate error message.
If P216 or P416 color formats are selected with NVENC, OBS will fall
back from the native implementation to the FFmpeg implementation. Here,
P216 and P416 were not explicitly handled, so the switch statements
would end up in the default case. If the user had also selected a Rec.
2100 color space, this would result in the strange error message:
"OBS does not support 8-bit output of Rec. 2100."
This message is confusing and does not correctly reflect the chosen
settings. Let's explicitly handle the P216/P416 cases and provide a more
accurate error message.
Compositors did not agree on how to communicate invalid buffers until
recently, so e0a4d8628d resulted in
regressions on KDE. This restores our old behavior which is too
conservative but mostly works on old and new compositors (which contain
similar workarounds to pass in invalid but non-zero sizes for dma-bufs).
Once all old compositors are out of use we can remove this workaround
and then compositors can remove their random size workaround.
Sequence start and end packets never have a valid DTS, but with a
non-zero offset the timestamp in the packet would end up also being
non-zero, which leads to librtmp attempting to calculate a timestamp
delta and underflowing.
As a fix, simply remove the ability to even set a DTS offset for
start/end packets and always keep it at zero.
With the recent change to enforce C17 standard for compilers, default
visibility was also enforced to be hidden. This also automatically hid
the `PlugInMain` symbol required for DAL plugins. Adding the
`__exported` decorator makes the symbol explicitly visible.
This logs that dynamic bitrate is disabled when a codec which does not
support bitrate reconfiguration is used, such as aom, svt-av1 ...
Signed-off-by: pkv <pkv@obsproject.com>
Macros make the code you see different from the code the compiler sees.
Modern C renders traditional uses of macros for constants and utility
functions unnecessary. Macros should only be used when there is no
other solution available.
The header packets are only used within the rtmp-output and do not need
or use the ref counter as the data is manually free'd directly.
The presence of this ref counter causes a crash on *nix platforms due to
our memory alignment hack attempting to free memory but reading the
wrong offset due to the ref counter being there rather than the
alignment offset.
The format is only checked for 10-bit capable formats, which in this
case applies to HEVC only. When HEVC is disabled, then `format` is
not checked and becomes an unused variable otherwise.
Fixes an issue where update/destroy of a media source during reconnect
would block the parent thread until the next reconnect attempt. This
would result in significant quantities of dropped frames, delayed OBS
shutdown, or frozen UI during this period.
Xcode 14.3 and the macOS 13.3 platform SDK introduced a few breaking
changes:
* Updated AppleClang emits warnings about unqualified std cast calls
when using C++ - as `move` is too broad a word, developers are to use
`std::move` to make this explicit. Alas this is exactly what `json11`
uses and because that library is archived, there is no possibility
of an upstream update.
* Apple guarded calls to old screen capture APIs as "available but
deprecated", but seems to have chosen the wrong lower version
boundary: The calls are flagged as being available for macOS 13 and
macOS 14 only.
To fix this, the existing macOS platform SDK header is replaced by a
local copy that uses macOS 11 as the lower boundary (the oldest macOS
version supported by obs-studio anyway)
In avcodec.h, the docs for AVCodecContext->framerate say:
encoding: May be used to signal the framerate of CFR content to an
encoder.
OBS is designed to always output Constant Frame Rate (CFR) content.
Instead of letting this be implied, let's explicitly set the framerate
per the docs.
When using FFmpeg-based NVENC, with b-frames, and a non-1 framerate
numerator (eg. `1001/60000` aka 59.94fps), the DTS values outputted
by FFmpeg result in invalid DTS values.
Detect when using an unpatched FFmpeg build and correct the values
accordingly.
The current method would enum though all devices looking for a matching
uid instead of directly asking for kAudioHardwarePropertyDeviceForUID.
Asking directly instead would also enable finding hidden devices that
can only be found directly via uid and not via enumerating (were we ever
to need to find such a device).
Pipewire desktop portal capture assumes premultiplied alpha, so make
sure to use the right blend equation to make translucent pixels work
correctly.
This is still broken for emissive pixels (alpha < color) since OBS seems
to unpremultiply at some point during blending, but it works properly
for translucent pixels (emissive pixel support requires an end-to-end
premultiplied pipeline).
We were calling avio_close on a field that might have held an
AVIOContext. This commit checks which type was allocated so we
can call the appropriate cleanup function.
