fix(network): stop handing librist a byte count as buffer_size

[datagutt]

Every rist:// ingest failed to open with "Result too large":

[irl-source] Connecting to: rist://.../
[irl-source] Failed to open input: Result too large
[irl-source] Reconnecting in 2s...

apply_demuxer_options set "buffer_size" to network_buffer_mb in bytes for every URL. Four things in FFmpeg 9.0's libavformat declare that option name, and three of them agree it is a byte count: udp.c (which feeds it to setsockopt SO_RCVBUF), rtpproto.c and rtsp.c (which both forward it to the udp:// they open). librist.c is the outlier — there it is the RIST recovery window in milliseconds, declared 0..30000:

{ "buffer_size", "set buffer_size in ms", OFFSET(buffer_size),
AV_OPT_TYPE_INT, {.i64=0}, 0, 30000, .flags = D|E },

2 MB is 2097152, so av_opt_set_dict() on the URLContext rejected it with AVERROR(ERANGE) and ffurl_open failed before librist opened a socket. The byte-semantic protocols all declare -1..INT_MAX and had been taking the value silently, which is why only RIST surfaced it. rist:// now keeps librist's own recovery default, tuned per stream by the URL's buffer= parameter that rist_parse_address2() reads.

While here, extend the receive buffer to the TCP-based protocols. It was only ever applied to srt:// as "recv_buffer_size", but tcp.c declares that same option (SO_RCVBUF), and rtmp_open, http_open_cnx and ff_tls_open_underlying each thread the caller's option dictionary down into the transport they open. So one unconditional set now gives the buffer effect on rtmp(s)://, http(s):// and tcp:// as well, where "buffer_size" had been landing in the dictionary unread. Only tcp.c and libsrt.c declare the name and both are -1..INT_MAX, so it cannot ERANGE the way buffer_size did.

The srt:// test also moves from strstr(url, "srt://") to a scheme-prefix check, so a path segment or query parameter can no longer decide which protocol options apply.

Summary by CodeRabbit

• Bug Fixes
  • Improved URL scheme detection so query and path text no longer incorrectly triggers protocol-specific settings.
  • Enhanced network buffering configuration for more consistent receive performance.
  • Refined SRT latency handling to apply only to valid SRT URLs.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: af08840f-ba14-4b13-8141-5a1bd5663dbb

📥 Commits

Reviewing files that changed from the base of the PR and between 97deae9 and 0053e09.

📒 Files selected for processing (1)

• src/receiver-stream.c

---

Walkthrough

The receiver stream now detects URL schemes only at the URL start. Network buffer options apply according to protocol, and SRT latency uses exact scheme detection.

Changes

Network option handling

Layer / File(s)	Summary
Exact scheme matching and buffer setup src/receiver-stream.c	Adds url_has_scheme for exact scheme checks. Applies recv_buffer_size to configured network buffers, omits buffer_size for RIST, and detects SRT latency with exact matching.

Estimated code review effort: 2 (Simple) | ~10 minutes

Poem

I’m a rabbit tuning streams tonight,
With schemes matched clean and buffers right.
RIST skips one, SRT waits true,
Queries no longer change the view.
Hop, hop, the receiver flows anew!

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/rist-buffer-size

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}