ffmpeg's libavformat RTMP client (gen_get_stream_length in rtmpproto.c) only sends getStreamLength for seekable/VOD streams, never as an unconditional preamble to play. Some live RTMP servers - notably Reolink cameras - respond to an unsolicited getStreamLength on a live stream by sending TCP FIN ~100-150ms later, killing the connection before the play command can take effect. The rebroadcast prebuffer then enters a tight reconnect loop that never produces a usable stream.
Removing the unconditional getStreamLength send lets Reolink RTMP rebroadcast work indefinitely without disconnects, and should not regress other servers since ffmpeg already runs without it.
Fixes#2055
Co-authored-by: thllxb <223556219+Copilot@users.noreply.github.com>
The Reolink RTMP server does not percent-decode query parameter values - it compares the raw bytes from the URL against the stored password. URLSearchParams.set() percent-encodes values when the URL is serialised (WHATWG application/x-www-form-urlencoded), which corrupts passwords containing characters such as '!' (-> '%21'), '#' (-> '%23'), '+' (-> '%2B'), space, etc.
Affected: users whose firmware causes getLoginParameters to return {user, password} (instead of a Login-API token) and whose password contains any of those characters. Symptom: rebroadcast prebuffer fails with 'Socket received FIN' immediately after 'Sending play command'.
Append the RTMP credential pairs as raw bytes instead of going through URLSearchParams. Token-only path is unaffected (hex tokens contain no characters that require encoding). Mirrors the rationale of #1509 for the HTTP API path.
Fixes#2057
Co-authored-by: thllxb <223556219+Copilot@users.noreply.github.com>
* fix: show stream selection options when synthetic streams are configured
* fix: show stream selection options and enforce FFmpeg parser for synthetic streams
The ReolinkCameraClient never called the Logout API before requesting a
new token, causing stale sessions to accumulate on the camera. When the
camera's session limit was reached (~68 min cycle), it would close the
RTMP/RTSP connection, dropping the stream.
Add a logout() method that releases the old token session before login()
requests a new one, matching the pattern already used by ReolinkNvrClient.
This prevents session buildup and eliminates periodic stream drops.
Fixes#1873
Co-authored-by: Josh Casada <joshcasada@Joshs-Mac-mini.ts.net lan>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
The RTMP client's totalBytesReceived counter grows unbounded as a
JavaScript number. When it exceeds 2^31 (~2.15 GB received), the
writeUInt32BE call in sendAcknowledgementIfNeeded throws a RangeError
because JavaScript bitwise operations produce signed 32-bit integers.
This crashes the RTMP session and drops the video stream.
For a high-bitrate camera like the Reolink D340P (~4 Mbps main stream),
this overflow occurs after approximately 90 minutes of continuous
streaming, causing periodic stream drops at a consistent interval.
Fix by using the unsigned right shift operator (>>> 0) to keep
totalBytesReceived and bytesToAck in the unsigned uint32 range [0,
4294967295], matching the RTMP spec's sequence number wrapping behavior.
Co-authored-by: Josh Casada <joshcasada@Joshs-Mac-mini.ts.net lan>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
