Skip to main content

Documentation Index

Fetch the complete documentation index at: https://gcore.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

​
About restreams

Restreams is a feature that helps to broadcast your live stream or playlists to external video platforms like YouTube, Facebook, Twitch, and other RTMP, RTMPS, or SRT target points.
Restreams to YouTube
Why use restreams? Use this feature when you want to show the same live event in several places at once, for example on your website, YouTube, and Facebook. Instead of setting up a separate broadcast for each platform, you send one live stream to Gcore Streaming, and we distribute it to the platforms you choose. This makes the workflow simpler and reduces the risk of configuration errors during the broadcast.

​
How restreams work

You get the credentials from the target platform or target media server: stream URL and stream key, or an SRT target URL. Then create a restream in the Gcore Customer Portal. When creating the restream, add the target URL and choose the appropriate live stream. The setup is complete. You can begin the live stream; it will be broadcast on our player and the target platform or server. Here’s how retransmission looks schematically: one stream at the input, many restreams at the output: 
                 +-----------------------+
 RTMP/RTMPS      |                       | -------->  Facebook (RTMP)
     or  ------> |    Gcore Streaming    | -------->  YouTube (RTMPS)
 SRT             |                       | -------->  Media server (SRT)
                 +-----------------------+ -------->  Other RTMP/SRT targets
Features. Restreams can be broadcast on an unlimited number of platforms. The price of the service depends on how many platforms you want to stream to. The fewer platforms there are, the cheaper it is. By default, when you enable the feature, you will be able to stream to one platform. To increase the number of platforms, contact technical support. We will change the limit and the price of the service.
Supported restreaming combinations:
  • RTMP → RTMP
  • RTMPS → RTMPS
  • RTMP → SRT
  • SRT → SRT
  • SRT → RTMP
For SRT target URLs, only mode=caller is supported. Gcore initiates the outbound connection to the external SRT or RTMP target point, so restreaming works as a PUSH from Gcore to your destination.
Restreaming sends the source stream to the destination as is. Make sure the source bitrate, codecs, resolution, keyframe interval, and audio format match the destination requirements.

​
When to use RTMP or SRT targets

Use RTMP or RTMPS for social platforms and short, stable network paths where the destination requires RTMP ingest. It’s a common, useful, and well-known protocol for sending master-streams, if it satisfies your requirements then use it. For cross-country and cross-continental delivery where RTMP can become unstable, switching to SRT ensures stable retransmission. Also, SRT allows you to tune the recovery window explicitly with latency. For more details, see RTMP vs SRT.

​
RTMP target URL format

For RTMP and RTMPS targets, enter the URL and stream key as follows: 
rtmp://<hostname_or_IP>[:<port>]/<application_name>/<stream_key_or_stream_name>
For example, our stream URL is: rtmp://a.rtmp.youtube.com/live2 and stream key is: ab123-cde4-f56g-hi78-90j. So, in the URL field, we should add the following:
stream URL
where:
  • rtmp://a.rtmp.youtube.com/live2 is the URL
  • / is the connecting symbol
  • ab123-cde4-f56g-hi78-90j is the KEY

​
SRT target URL parameters

For SRT restreams, add the parameters required by your target point directly to the SRT URL query string. Common parameters include:
  • mode=caller
  • latency
  • send_buffer_size
  • pkt_size
  • passphrase
  • streamid
Example: 
srt://target.example.com:5001?streamid=1&mode=caller&latency=2500000&passphrase=secret
The target media server defines which parameters are required. For long-distance public internet delivery, increase latency enough to cover round-trip time, jitter, and packet recovery. For example, a 2.5-second SRT latency window is written as latency=2500000 in FFmpeg-style SRT URLs.

​
Configure a restream

1. Get credentials from the target platform or media server for the restream. Our guides for popular platforms describe how to do it: Facebook, YouTube and Twitch. For SRT targets, get the SRT host, port, and any required query parameters from the target media server administrator. For example, we want to broadcast our live stream on YouTube. To do so, we should go to YouTube and click Go live. Then select a Streaming software solution. There we will need the credentials of stream URL and stream key. We will use them in step 5 of this guide. In YouTube Studio, open the live stream you created. The stream key appears in the upper-right corner, where you can copy it by clicking Copy.
Configure a restream
2. Go to the Restreams section and click Create a restream.
Restreams section
The configuration page opens. Complete the remaining steps in it.
remaining steps
3. Turn on the Active toggle if you want to broadcast your video content after configuration. If you don’t turn the toggle off, an inactive restream won’t be broadcasted. 4. Give a name to your restream. 5. Enter the credentials from step 1 of this guide. 6. Select which type of video content you want to restream. You can broadcast live streams and playlists. Note : Playlists must be looped so that you can restream them. 7. Pick a stream or playlist that you want to broadcast from the drop-down list. 8. Save changes. Then you should enable the live stream or playlist (depending on your choice), wait several minutes while the settings are applied, and restart the Restreams page. If everything was set up correctly, you would see the Live label.
Restreams page
You can do this if the live stream or playlist is over, but you want to restream it again in a while. If the key and URL were not changed, and the restream still exists in the Gcore Customer Portal, there are no additional settings. If the key or URL were changed, you should add current credentials in the configuration of restream.
Restreams page

​
Multiple restreaming

Technically, the number of restreams is not limited. By default, we enable one available restream per account. If you want to use more than one, contact technical support and specify the number of restreams. We will notify you when the feature is activated. After that, you will be able to use it for your account.

​
Restream failover

Just like for regular streams, restreams have a failover algorithm too. If there is a problem getting the original stream, it will be re-requested multiple times. Restream retry algorithm:
  1. Original stream is active
  2. If the original stream is unavailable and is down for more than ±3 seconds:
    1. The system will activate the retry mechanism.
  3. The system will attempt to re-request (PULL) the original stream for approximately 60 minutes.
    1. If original stream is back, the timer is reset to zero and the restream is restored.
    2. Otherwise the restream stops permanently. To resume it, you will have to activate it manually or via API.

​
Restream troubleshooting

​
RTMP targets

The main risk with RTMP targets is that the destination can terminate the stream when delivery becomes too slow or unstable. RTMP works best for short, stable paths and moderate bitrates. For public internet restreaming, a practical bitrate is usually around 1-3 Mbps, depending on route quality and the target server. If a restreamed stream’s bitrate is higher than 5 Mbps you can face with stream interruptions. If the problem is caused by latency, jitter, packet loss, or insufficient bandwidth on a long-distance route, use SRT instead of RTMP. Typical comb with packet loss in RTMP for long distance:
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 is too low for the route: Long-distance paths can have high RTT, jitter, or packet loss. If latency is too low, retransmitted packets can arrive too late and the target may report TS loss, service loss, or dejitter buffer resets.
  • Target bandwidth is lower than the source bitrate: Restreaming sends the source stream as is. If the target site cannot reliably receive an 11 Mbps source, use a lower-bitrate source or create a separate transcoded stream for that destination.
  • Firewall or UDP filtering: SRT uses UDP, so the target host and network must allow inbound UDP on the configured SRT port.
  • Encryption parameter mismatch: If the target requires encryption, passphrase and related parameters such as pbkeylen must match the target configuration.
Solutions
  • Use mode=caller in the SRT target URL.
  • Increase latency 2-3 or more seconds for long public internet routes and test under real traffic conditions.
  • Confirm that the target can receive the full source bitrate without sustained packet drops.
  • Verify UDP reachability to the target SRT port.
  • Match all required target parameters, including streamid, passphrase, pbkeylen, pkt_size, and buffer settings.

​
Facebook

Common Issues
  • Expired or invalid stream key/token
    The RTMP connection is rejected if the event is marked as finished in the Facebook UI or if the token/stream key has been regenerated.
  • Keyframe interval exceeds 4 seconds
    Facebook enforces a maximum GOP size of 4 seconds; exceeding this value results in rejection.
  • Unstable or insufficient bitrate
    Significant bitrate 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.
  • Verify correct ingest server selection.
Facebook documentation: https://www.facebook.com/business/help/162540111070395?id=1123223941353904

​
YouTube

Common Issues
  • Invalid stream key or inactive event
    YouTube rejects connections when the key is incorrect or the event is not yet open.
  • 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.
  • Use standard H.264 + AAC encoding.
  • Keep keyframe interval at 2 seconds.
  • Ensure encoder output is stable and avoids bitrate spikes.
  • Enable low-latency only if supported reliably by your pipeline.
Youtube documentation: https://support.google.com/youtube/answer/2853702

​
Twitch

Common Issues
  • Rate limiting or ingest overload
    Frequent connection attempts may trigger temporary limits.
  • Excessive bitrate for account type
    Twitch generally recommends a maximum of 6,000 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
  • Follow Twitch bitrate and profile recommendations.
  • Use a 2-second keyframe interval.
  • Select the closest ingest server.
  • Reduce connection retries to avoid rate limiting.
  • Use CBR and ensure stable network paths.
Twitch documentation: https://help.twitch.tv/s/article/broadcasting-guidelines

​
Other Social Platforms

Common Issues
  • Stream keys are frequently rotated.
  • Strict GOP/keyframe interval requirements (often 2 seconds).
  • Dynamic regional ingest endpoints.
  • Some platforms accept only RTMP or specific RTMP variants.
Solutions
  • Validate the latest stream key before restreaming.
  • Use a standard 2-second keyframe interval unless specified otherwise.
  • Maintain consistent bitrate and resolution.
  • Review platform-specific RTMP error codes for precise causes.