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>
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.
Some send() errors are not treated as fatal but the connection gets shut
down regardless. When this happens, librtmp may send an FCunpublish
message which various services interpret as an "end of stream" message
and disable features like "disconnect protection". Instead, let's
explicitly close the socket so that the remote end is aware that this is
an unclean disconnect.
"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.
The obs-outputs-config.h.in file is not actually used. It only
defines the FTL_FOUND variable, but the build system takes care
of that by setting a compiler argument for that.
Drop that file.
Replaces the usage of SO_SNDTIMEO with TCP_USER_TIMEOUT on Linux.
- Noted as more effective than SO_SNDTIMEO by multiple sources.
- Drops TCP connection on timeout instead of returning send() errors,
meaning more predictable reconnect timing and reconnect.
- Timeout period actually reflected in practice. SO_SNDTIMEO takes
double the timeout time than actually requested to time out on
unix, whereas WinSock actually waits the specified time.
When trying to update to mbedTLS 3.2.1, I ran into failures with RTMPS
output. After consulting an mbedTLS implementation example, I determined
that we were not setting up the SSL/TLS context config in the correct
order, causing the connection to fail. Performing the setup in the
recommended order fixes that.
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.
This fixes a bug where the RTMP send thread can deadlock upon the
underlying TCP connection being broken. By introducing a send timeout,
this allows the thread to unblock and give up, triggering a reconnect
as normal. The correct solution to this problem would be to rewrite
librtmp with asynchronous IO, but that seems like something unlikely
to happen.
**Before**:
- Start stream in OBS
- Use tool (pfSense) to invalidate connection state
- OBS bitrate drops to 0
- Output does not respond to stop signals, and hangs for an undefined
amount of time (usually multiple minutes) before finally giving up
**After**:
- Start stream in OBS
- Use tool (pfSense) to invalidate connection state
- OBS bitrate drops to 0
- Output sits in blocked state for maximum of 8 seconds, then cleans
up and triggers the reconnect logic
Details in #6226, basically this fixes an issue where OBS links
to the system-installed librtmp1, which is incompatible with our
librtmp.
Co-authored-by: ewhac <ewhac@ewhac.org>
Status output related to OBS configuration is prefixed with the string
"OBS" and added padding for enabled and disabled features. This padding
was not aligned between platforms.
By moving the padding and prefix decoration into its own function,
both elements are controlled in a single place. CMake scripts were
changed to use this new function `obs_status` instead of using CMake's
`message` function directly.
derrod