Secure Reliable Transport (SRT) is an open-source streaming protocol that solves some of the limitations of RTMP delivery. In contrast to RTMP/RTMPS, SRT is a UDP-based protocol that provides low-latency streaming over unpredictable networks. On Gcore Video Streaming, SRT is also required if you want to use the H265/HVEC codec.

​
SRT PUSH

Gcore Video Streaming provides two endpoints for pushing a stream: the default one and a backup one. The default endpoint is the one closest to your location. The backup endpoint is in a different location and is used if the default one is unavailable. By default, Gcore will route your stream to free ingest points with the lowest latency. If you need to set a fixed ingest point or if you need to set the main and backup ingest points in the same region (i.e., to not send streams outside the EU or US), please contact our support team.

​
Obtain the server URLs

There are two ways to obtain the SRT server URLs: via the Gcore Customer Portal or via the API.

​
Via the Gcore Customer Portal

  1. In the Gcore Customer Portal, navigate to Streaming > Live Streaming.
List of live streams
  1. Click on the stream you want to push to. This will open the Live Stream Settings.
Live stream settings
  1. Ensure that the Ingest type is set to Push.
  2. Ensure that the protocol is set to SRT in the URLs for encoder section.
  3. Copy the server URL from the Push URL SRT field.
URLs for encoder section

​
Via the API

You can also obtain the URL and stream key via the Gcore API. The endpoint returns the complete URLs for the default and backup ingest points, as well as the stream key. Example of the API request: 
GET /streaming/streams/{stream_id}
Example of the API response: 
{
  "push_url_srt": "srt://vp-push-anx2.domain.com/in/123?08cd54f0",
  "backup_push_url_srt": "srt://vp-push-ed1.domain.com/in/123b?08cd54f0",
  ...
}
Read more in the API documentation.

​
SRT PULL

Gcore Video Streaming can pull video data from your external server. Main rules of pulling:
  • The URL of the stream to pull from must be publicly available and return a 200 status for all requests.
  • You can specify multiple media servers (separated with space characters) in the URL input field. The maximum length of all URLs is 255 characters and the round robin is used when polling the list of specified servers.
  • If a stream is closed (i.e., its connection is terminated) or there is no video data in the stream for 30 seconds, then the next attempt will be made in the next steps progressively (10s, 30s, 60s, 5min, 10min).
  • The stream will be deactivated after 24 hours of inactivity.
  • If you need to set an allowlist for access to the stream, please contact support to get an up-to-date list of networks.

​
Setting up a pull stream

There are two ways to set up a pull stream: via the Gcore Customer Portal or via the API.

​
Via the Gcore Customer Portal

  1. In the Gcore Customer Portal, navigate to Streaming > Live Streaming.
List of live streams
  1. Click on the stream you want to pull from. This will open the Live Stream Settings.
Live stream settings
  1. Ensure that the Ingest type is set to Pull.
  2. In the URL field, insert a link to the stream from your media server.
  3. Click the Save changes button on the top right.
URLs for encoder section

​
Via the API

You can also set up a pull stream via the Gcore API. The endpoint accepts the URL of the stream to pull from. Example of the API request: 
PATCH /streaming/streams/{stream_id}

{
  "stream": {
    "pull": true,
    "uri": "srt://example.com/path/to/stream",
    ...
  }
}
Read more in API documentation.

​
SRT Latency

​
Playback problems with SRT

SRT is a low-latency transport protocol by design, but real-world networks are not always stable and the path from a venue to our ingest point may traverse long and unpredictable routes. For this reason, the latency parameter must be tuned to actual network conditions.
  • Too small latency → insufficient buffer for retransmissions under jitter or loss → packet drops and playback errors.
    • Too large latency → excessive buffering → unnecessary end-to-end delay.
    • Manual tuning is recommended rather than relying on defaults, since each environment behaves differently.
Incorrect or low default value is one of the most common reasons for packet loss, frames loss, and bad picture. We therefore recommend setting latency manually rather than relying on the default, to ensure the buffer is correctly sized for your environment. A practical range is 400–2000 ms, with the exact value chosen based on RTT, jitter, and expected packet loss. Recommended latency ranges for SRT ingest based on network conditions.
Network ConditionsTypical RTT (ms)Jitter/LossRecommended Latency (ms)
Same datacenter<20Very low150–400
Same country, stable uplink20–80Low (<0.5% loss)600–1000
Cross-region, higher variability80–200Moderate (<1%)1000–1500
Long-haul international200–350+High (>1% bursts)1500–2000

​
Best Practices for Configuring SRT Latency

Practical setup notes:
  • Rule of thumb: Set latency ≥ 3 × RTT + jitter margin (e.g., RTT 100 ms → latency ~500 ms).
  • Parameter location: Latency must be set on the sender side (caller or listener mode). Receiver should be equal or higher.
  • Default values are often too low (e.g., 120 ms) for WAN paths, which can cause instability.
  • Monitoring: Check SRT statistics for retransmissions, buffer usage, and packet drops. If drops occur, increase latency in steps of 100–200 ms.
  • Encoder settings:
    • Enable tsbpd=1 (timestamp-based delivery).
    • Cap stream bitrate to ~70–80% of available uplink.
    • Redundancy: Configure failover to a backup ingest point or secondary SRT target.
Also check official SRT statistics documentation https://github.com/Haivision/srt/blob/master/docs/API/statistics.md Enable sender-side SRT stats and watch these fields:
  • RTT and jitter: round-trip time, variability. Drives latency sizing. 
  • Loss and retransmissions: pktLoss, pktRetrans, pkt*Drop. Rising values → increase latency or reduce bitrate. 
  • Throughput/bandwidth: current/peak send rate vs configured caps. 
  • Buffer occupancy: send/receive buffer fill vs negotiated latency; approaching 0 under loss means too low latency. 
  • Flight/window size, MSS/packet size: detects fragmentation or congestion.