Use the new `OBS_ENCODER_CAP_MULTITRACK_DYN_BITRATE` flag when
streaming with multiple tracks, instead of relying on the single-
track `OBS_ENCODER_CAP_DYN_BITRATE` flag. In multitrack cases where
multiple codecs are being used (e.g. mixed AVC and HEVC), all encoders
must support the multitrack capability flag otherwise the dynamic
bitrate (DBR) feature is disabled for the streaming session.
When network optimizations are enabled, `new_socket_loop` is enabled,
and an accurate total output bitrate is required. Include the audio
bitrates in this calculation.
Removes flag guard to enable HDR streaming for HEVC over enhanced-RTMP.
This functionality is currently only supported by YouTube. See
github.com/veovera/enhanced-rtmp for the enhanced-RTMP spec.
Sends color metadata before the video header for RTMP streams. Only
applicable to HDR RTMP streams. Ensures the server sees the correctly
configured color metadata first, in cases where the decoder config in
the video header has incorrect or missing color information. Mitigates a
bug that users with outdated AMD drivers may encounter.
Removes flag guard to enable HDR streaming for HEVC over Enhanced RTMP.
This functionality is currently only supported by YouTube.
See github.com/veovera/enhanced-rtmp for the Enhanced RTMP spec.
Effectively reverting parts of d314d47, this commit removes the new
functions that got added to remove the flags parameter. Instead, it just
marks the parameter as unused and documents this. Having what is
effectively an API break just to remove a parameter is a bit overkill.
The other parts of d314d47 which cleaned up the usage of the flags
parameter are untouched here.
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.
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.
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.
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>
"New Socket Loop" and "Low Latency Mode" RTMP options are only available
on Windows.
Those options should be ignored and forced-disabled on non-Windows
builds.
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.
The dynamic increment timeout does not need to be 30 seconds. Change it
to 4 seconds instead to make dynamic bitrate something that people
actually want to use.
This commit fixes what is arguably a long-winded series of previous
commits that have possibly caused just as many problems as they have
fixed. I'll spare the details, but basically, there's no reason that
any of the RTMP object should ever be used across socket sessions.
This provides a slight enhancement by removing the `RTMP_Init` call
in `rtmp_stream_create()`, since it effectively just initializes TLS
just for `try_connect` to deinitialize it before it is even used.
This also fixes the current `SO_RCVTIMEO` timeout functionality by
making sure that `RTMP_Reset` is called last.
A race condition can occur in obs-outputs where the send_thread is in
the process of (re)connecting but the encoder was shut down in the
meantime. This causes the expected header data to be garbage, resulting
in a crash.
The silent reconnect (GOAWAY) is supposed to be used for switching the
connection to a different server. As such, cleanly shutting down the
RTMP connection can destroy state that needs to be preserved in order
for the GOAWAY-enabled server to properly resume the same stream on
reconnect.
This commit closes the TLS/TCP connection before calling RTMP_Close,
causing librtmp to skip the FCUnpublish and deleteStream messages.
Sometimes when reconnecting the internal RTMP data is not cleared
(particularly the TLS data). This can cause TLS data to carry over from
one connection to another, causing issues with the secondary connection.
From Windows 7 onwards, dynamic send buffering is enabled. By setting
SO_SNDBUF explicitly, we actually disabled the dynamic send buffering
feature which results in reduced throughput. Thankfully this did not
affect the majority of users since the default send buffer is usually
already 64k.
This commit replaces the setting of SO_SNDBUF with log output showing
the current value of SO_SNDBUF at stream start and end. This will aid in
debugging throughput issues caused by a buffer that isn't big enough,
perhaps as a result of the user disabling dynamic send buffering
system-wide.
Alex Luccisano
Ruwen Hahn
Ruwen Hahn
Ryan Foster
Norihiro Kamae
derrod
John Bradley
nquah
James Hurley
PatTheMav
gxalpha
Richard Stanway
tt2468
Lain
pkv
Yuriy Chumak
tytan652
Richard Stanway
Jim
Vainock
Richard Stanway
liu.haibin
jpark37