Translation-specific limitations are listed on the Translation outputs page.
Short CPU spikes from host package inventory checks every 10 min
On GCP Ubuntu hosts, google-osconfig-agent.service may periodically run
apt-get update / package inventory checks and briefly consume a large fraction
of one vCPU. On a 4-vCPU VM this can show up as a ~25% CPU spike. This is host
maintenance noise, not a restream pipeline failure.
Temporary live-event mitigation, cleared automatically on reboot:
sudo systemctl stop google-osconfig-agent.service
sudo systemctl mask --runtime google-osconfig-agent.service
If Ubuntu Pro APT/ESM jobs are also noisy:
sudo systemctl mask --runtime apt-news.service esm-cache.service
This temporarily affects GCP OS patch/inventory reporting or Ubuntu Pro update messaging; re-enable after the event or reboot.
An input outage over 5 s makes shared encodes restart when the input returns
SRS closes any publisher that sends no data for 5 s. After an input drops for
longer than that, SRS closes the internal publish of each
shared encode on that pipeline. Each
encode fails with Broken pipe when the input comes back, restarts, and takes its
outputs with it, so every output that reads one records "Shared encode … failed: …
Broken pipe" and reconnects (measured: about 4 s after the input returned).
Everything recovers on its own and other pipelines are unaffected. Outputs that
read the input directly (plain copy, several tracks, or a recipe used by only one
output) are not interrupted. See
Reliability. Workaround: none needed; the
history records are expected after an input outage.
SRS srt_to_rtmp damages audio and video (avoided, not used)
SRS's native srt_to_rtmp remuxes an SRT publish into the RTMP layer so it can
be played back over RTMP. Testing on SRS 6.0-r2 found:
- 48 kHz AAC gets wrong frame timestamps, which breaks the audio (fix submitted upstream, ossrs/srs#4765, not in a release yet).
- Video frames are dropped: about 13 fps instead of 25 for a plain H.264 stream.
- Several audio tracks are interleaved into the one RTMP audio track, so the audio is garbled rather than reduced to one track.
- Non-AAC audio leaves the RTMP side silent, while SRS logs a warning for every audio PES packet (tested with MP2; AC-3 and Opus fail the same codec check).
How it's avoided: srt_to_rtmp is turned off in srs.conf.
- SRT inputs stay in the native SRT/MPEG-TS domain and are pulled back over SRT, which keeps every audio track and the original timestamps.
- Wherever RTMP is needed, FFmpeg does the conversion.
- The HLS preview is generated by the app's own FFmpeg, not by SRS's native HLS.
- RTMP inputs are unaffected and are pulled over RTMP.
See Design decisions.
SRS logs SRTS_BROKEN errors for every SRT play disconnect, including clean ones
The SRS log fills with srt serve error code=6001(SrtIo)(SRT read or write failed) : srt play recv thread : ... socket status=SRTS_BROKEN at a steady background rate.
This is expected noise, not an incident: it fires on every teardown of an SRT
play (pull) connection — including the ffprobe media check this app runs when a
publisher connects to an SRT input, and its retries every
FFPROBE_FAILED_REFRESH_MS while that probe keeps failing — not just on
genuine connection failures.
Confirmed in SRS 6.0 source (src/app/srs_app_srt_conn.cpp,
src/protocol/srs_protocol_srt.cpp): SrsMpegtsSrtConn::cycle() logs at
srs_error() for any non-success return from the play loop, with no branch for
"peer closed cleanly" vs. "connection broke" — and the SRT recv thread treats any
non-timeout read() result (including a normal peer disconnect) as a hard error
that propagates up to that log call. check_error() just stringifies whatever
srt_getsockstate() reports at that instant, and libsrt sets a torn-down read-side
socket to SRTS_BROKEN regardless of how gracefully the peer closed.
No client-side fix exists. SRT socket options like linger only affect
how the closing side waits to flush unsent data — since ffprobe is a
receive-only client, they don't change what SRS observes or logs. This was
verified by adding &linger=1 to the ffprobe pull URL and confirming SRS still
logged SRTS_BROKEN on every probe close. Fixing this would require patching
and rebuilding SRS itself.
Mitigation: filter SRTS_BROKEN / srt play recv thread lines out of log
monitoring/alerting rather than treating them as incidents.