Skip to main content

​
Multiple restreaming

Technically, the number of restreams is not limited. The default account limit is three restreams. To increase this limit, contact technical support and specify the number of restreams needed. Gcore support will update the limit and notify when the change is active.

​
Source stream recovery

If the source stream becomes unavailable, Gcore retries the source before stopping the restream. Recovery behavior:
  • Original stream is active.
  • If the original stream is unavailable and is down for more than ±3 seconds, the retry mechanism activates.
  • The system retries the source stream for approximately 60 minutes:
    • If the original stream recovers, the timer resets and restreaming resumes automatically.
    • Otherwise the restream stops permanently. To resume it, activate it manually or via API.

​
Restream troubleshooting

​
RTMP targets

Common issues:
  • Destination drops the stream: RTMP destinations terminate the stream when delivery is too slow or unstable. For public internet routes, bitrates above 5 Mbps frequently cause interruptions; a practical limit for stable delivery is 1–3 Mbps.
  • Long-distance instability: High latency, jitter, or packet loss on cross-continental paths causes buffering and disconnects. For these routes, SRT is more reliable — the protocol guide covers the trade-offs.
Solutions:
  • Keep the source bitrate within the range the destination and network route can sustain.
  • For long-distance or unstable routes, switch the restream URI to an SRT endpoint.
Typical packet-loss pattern for RTMP over a long-distance connection:
RTMP falls

​
SRT targets

Common issues:
  • Wrong SRT mode: Gcore supports only mode=caller for SRT restream targets. The destination must listen for the incoming SRT connection.
  • Latency too low: Long-distance paths have high RTT, jitter, or packet loss. If latency is too low, retransmitted packets arrive late and the target may report TS loss or dejitter buffer resets.
  • Target bandwidth lower than source bitrate: Restreaming sends the source stream as-is. Use a lower-bitrate source or a transcoded stream if the target cannot sustain the full bitrate.
  • Firewall or UDP filtering: SRT uses UDP; the target host and network must allow inbound UDP on the configured port.
  • Encryption mismatch: If the target requires encryption, passphrase and pbkeylen must match the target configuration.
Solutions:
  • Use mode=caller in the SRT target URI.
  • Increase latency to a value appropriate for the route — the SRT latency section lists recommended ranges.
  • Verify UDP reachability to the target SRT port.
  • Match all required target parameters: streamid, passphrase, pbkeylen, pkt_size, buffer settings.

​
Facebook

Common issues:
  • Expired or invalid stream key: The connection is rejected if the event is marked finished in Facebook UI or the stream key was regenerated.
  • Keyframe interval exceeds 4 seconds: Facebook enforces a maximum GOP size of 4 seconds.
  • Unstable or insufficient bitrate: Significant drops may cause Facebook to terminate the stream.
  • Incorrect event configuration: Using an outdated or incorrect stream key leads to immediate connection failure.
Solutions:
  • Confirm the stream key is active and the event is in Live or Preview state.
  • Set keyframe interval to 2 seconds (recommended) or 4 seconds (maximum).
  • Maintain a stable, constant bitrate.
  • Update stream keys after Facebook regenerates them.
Facebook live docs cover additional requirements and limits.

​
YouTube

Common issues:
  • Invalid stream key or inactive event: YouTube rejects connections when the key is incorrect or the event is not yet open.
  • Missing audio track: YouTube rejects incoming streams that lack an audio track. When disabling restream audio via API, no_audio_mode must be set to "silence".
  • Unsupported codec or profile: YouTube requires H.264 (Baseline/Main/High) and AAC audio.
  • Unstable input bitrate: Bitrate drops cause buffering and disconnects.
  • High keyframe interval: YouTube recommends a GOP of 2 seconds.
Solutions:
  • Verify the stream key and event status before connecting.
  • When disabling audio on a restream to YouTube, set no_audio_mode: "silence" instead of dropping the audio track.
  • Use H.264 + AAC encoding.
  • Set keyframe interval to 2 seconds.
  • Verify encoder output is stable and avoids bitrate spikes.
YouTube encoder settings list the full codec and bitrate requirements.

​
Twitch

Common issues:
  • Rate limiting: Frequent connection attempts may trigger temporary limits.
  • Excessive bitrate: Twitch recommends a maximum of 6000 Kbps for non-partners.
  • Unsupported codec settings: Twitch requires H.264 + AAC.
  • Disconnects due to unstable upstream: Twitch is sensitive to jitter and packet loss.
Solutions:
  • Keep bitrate at or below 6000 Kbps.
  • Use a two-second keyframe interval and H.264 + AAC.
  • If Twitch disconnects due to upstream instability, consider switching to a closer Twitch ingest server.
Twitch broadcasting guidelines list ingest server addresses and bitrate requirements.

​
Other platforms

Common issues:
  • Stream key expired or rotated — the destination rejects the connection immediately.
  • GOP size exceeds the destination’s limit — most platforms require a keyframe interval of 2 seconds.
  • Destination accepts only a specific RTMP variant (RTMP vs RTMPS) or requires a non-standard port.
Solutions:
  • Verify the stream key is current before starting the restream.
  • Use a two-second keyframe interval unless the destination specifies otherwise.
  • Check the destination’s RTMP ingest documentation for the required URL scheme and port.