Copying the encoder list takes a while which blocks the main thread.
Doing the copying asynchronously removes instead of blocking the main
thread improves startup performance by about 60ms.
The aac spec has a list of default channel layouts that are implemented
by all aac encoders / decoders.
Unfortunately 2.1 is not in that list. When I wrote the surround sound
support into OBS, as a workaround I decided to encode 2.1 as
AV_CH_LAYOUT_SURROUND = FL+FR+FC.
The LFE channel is encoded as a regular audio channel which uses more
bits but this allows compatibility with all aac decoders.
Recently we updated to the new channel layout API of FFmpeg, but the
mapping of 2.1 to AV_CH_LAYOUT_SURROUND was forgotten in the FFmpeg
native aac encoder. This is remedied here.
Signed-off-by: pkv <pkv@obsproject.com>
The `srt_bstats()` function is not guaranteed to zero the stats object
before filling in stats. If a socket was connected, then disconnected,
without any data being sent over it, the stats object would remain
uninitialized, and weird results could occur.
The gain should be positive for an upward compressor. Initially, the
gain would be zeroe'd below -60 dB to ensure noise is not amplified by
the upward compressor. This created a discontinuity at -60 dB since
just above -60 dB, the audio is boosted by +20 dB (at default
settings). This was fixed in commit 50db097 which decreased smoothly
the gain so that it's 0 dB at -60 dB. However that commit forgot to
limit the gain decrease which was negative below -60 dB.
This is fixed by the current commit.
Additionally initialization allowed -inf gain. We hard limit to positive
gains only as they should be for an upward compressor.
The bugfix was found by R1ch and put in form by pkv.
Co-authored-by: pkv <pkv@obsproject.com>
Signed-off-by: pkv <pkv@obsproject.com>
The upward compressor has a -60 dB threshold to stop increasing the
gain. At the threshold, the gain was not continuous, which is not ideal.
Co-authored-by: pkv <pkv@obsproject.com>
Signed-off-by: pkv <pkv@obsproject.com>
PipeWire supports two flags to signal an invalid buffer:
SPA_META_HEADER_FLAG_CORRUPTED signals that the whole buffer is invalid
and should not be used
SPA_CHUNK_FLAG_CORRUPTED signals that one single buffer plane is invalid
Skipping a buffer because of size 0 was moved to only the SHM case.
For DMA-BUFs the size of a single plane is not relevant and should be
ignored [1].
Compatibility note:
GNOME pre 43 sets the chunk size to 0 when a buffer copy failed.
Luckily GNOME doesn't use the META_Header and thus we can detect if we
should use the new or old style of invalid buffer detection.
This workaround should be dropped when reasonable.
[1] https://docs.pipewire.org/page_dma_buf.html
- Don't repeatedly query version at runtime in case a user installs the
SDK while OBS is running
- Restore default DLL search directory
- Don't show outdated SDK message if the SDK is not found
- Protect minimum version macro with brackets
The DAL plugin-based virtualcamera shares data between OBS and the
plugin using an IOSurface. IOSurface locks are necessary to ensure
race conditions between data generation (OBS side) and consumption
(virtual camera side) and also that an IOSurface is not offloaded to
GPU memory when it is indeed needed in CPU memory.
Also moves the invalidation of the NSMachPort for the frames to after
the IOSurface data has been converted into a pixelbuffer and added to
the frame queue of the virtual camera, as an early invalidation will
cut off access to the pixel data shared with the DAL plugin.
Now uses GetIfEntry2 which supports 64-bit values for reporting speed, so
10+ gbps adapters are now reported correctly in the log. Also added an
additional log line if the interface error counters are non-zero to possibly
help identify physical faults. Finally the transmit and receive speeds are
logged independently so that asynchronous mediums such as Wi-Fi that might
have good RX but poor TX can be better diagnosed.
Remove code forcing x264 and ffmpeg aac encoder. People using custom
ffmpeg output should be able to use other video and audio encoders when
streaming with RTMP, given its h264 or aac.
This fixes a bug reported by R1ch internally.
If someone uses NVIDIA noise suppression filter and later uninstalls
the SDK, there can be a crash because the filter tries to load the
models.
Signed-off-by: pkv <pkv@obsproject.com>
