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.
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.
Since this is activated after starting the output, it assumes there is
no need to read anything from the connection as RTMP is send-only from
that point on. However with TLS, reading protocol messages is required
for proper operation, causing it to immediately fail on RTMPS
connections. This is a complex fix due to the way it interacts with
librtmp and mbedTLS so let's just disable it for now to avoid breaking
things for users.
Fix inet_ntop()/inet_pton() being called with an incorrect argument for
IPv6 addresses.
On Linux, the offset of the sin_addr and sin6_addr fields differ and
the confusion on the inet_ntop() call produces an erroneous IPv6 string
representation such as "0:0:2001:db8::". This is visible on the UI,
Settings -> Advanced -> Network -> Bind to IP.
The same goes for the inet_pton() call.
Bug is caused by the internal connection variables not being reset on
reconnect, leading OBS to both be unable to parse valid packets from and
send valid packets to the remote end. This commit splits RTMP_Init off
into a new RTMP_Reset function, which resets these internal variables
without re-initing the rest of the library. The original RTMP_Init
calls the new function, perfectly preserving the old behaviour while
adding a new reset function to address the issue with.
Fixesobsproject/obs-studio#2865
To support FTL, it needed to be present in-tree to be compiled. This PR
adds support for system-wide installations of libftl. It uses
pkg-config to find the system-wide installation. If pkg-config can't
provide libftl we just fall back to using the in-tree submodule. If
that's also not available it won't be included at all like before.
When connection to FTL ingest is lost, ftl_event() calls
obs_output_signal_stop() to trigger a reconnect. However, during the
reconnect delay, send_thread is still waiting on send_sem semaphore.
After the delay, ftl_stream_start() is called, which in turn resets
the semaphore and creates a new send_thread. Old send_thread now exits
the loop and triggers another reconnect and the whole process repeats
again. The fix resets the semaphore in ftl_event() so the old
send_thread exits immediately.
Certain RTMP status descriptions can contain stream keys. We don't want
to log those normally, so log the description for unhandled status codes
as RTMP_LOGDEBUG. If someone needs to debug an RTMP server's return
messages, they can compile OBS with the RTMP Log Level set to
RTMP_LOGDEBUG.
