> ## Documentation Index > Fetch the complete documentation index at: https://docs.gcore.com/llms.txt > Use this file to discover all available pages before exploring further. # Create and configure a restream > Create and configure a restream to forward live streams to YouTube, Facebook, Twitch, or RTMP and SRT targets. ## Multiple restreaming Technically, the number of restreams is not limited. The default account limit is three restreams. To increase this limit, contact [technical support](mailto:support@gcore.com) 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](#rtmp-and-srt-restream-targets) 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](https://mintcdn.com/gcore/mB9xUQPpVbdf6kcA/images/docs/streaming/live-streaming/create-and-configure-a-restream-to-social-media/restreaming-abroad.jpeg?fit=max\&auto=format\&n=mB9xUQPpVbdf6kcA\&q=85\&s=f586c0911320cbeccab0cf8ef0fd60bf) ### 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](#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](https://www.facebook.com/business/help/162540111070395?id=1123223941353904) 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](https://support.google.com/youtube/answer/2853702) 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](https://help.twitch.tv/s/article/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.