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.
