Adaptive bitrate encoding at no cost
0,3-4 sec latency
Scalable and reliable streaming
HLS, DASH, WebRTC
Simple dashboard, SDK and API
Scale with us, if you have your own video server and apps. And use our infrastructure with open source demos, if you need to build a new video service from scratch.
RTMP, SRT, WebRTC or multicast broadcasting of your streams to million of viewers.
Simple steps to start
Ready to get started?
14 days free trial
Frequently Asked Questions
You need a streaming software/videocam that sends streams in rtmp/srt.
Or if you’re a pro - you may have a pre-set up server from which we can extract your srt/rtmp stream.
After we get your stream, we transcode it in the qualities you need and to the http-compared protocol (HLS/DASH) which are suitable for web-players and CDN.
Then we deliver this stream to your audience anywhere in the world using our CDN.
We provide you with an iframe of our player to embed into your application. But that’s not mandatory. You can use any other hls.js/dash.js compatible player to place our playlist in.
Here is a step-by-step guide explaining what settings you need to set up in the Control Panel .
We accept any kind of software or videocams. It doesn’t matter what you use - free OBS or Entreprise LiveU, or just a videocam with a pre-set up software.
you just need to make sure that your software works with rtmp or srt. Most modern softwares surely accept these protocols.
If you have something ve-e-ery specific just contact us.
Sure, you can. This protocol is much more stable than RTMP - it doesn’t drop connection if there’s smth wrong with provider routes.
We recommend all our customers to use SRT. But rtmp also works as the most common streaming protocol.
Check, please, whether your software supports SRT. Then send a stream to us in that protocol. For your and our serenity.
From 1 to 100 000 000 or even more. There’s no end-point.
We use our own EdgeNetwork. With PoPs all over the world united into redundant clusters. So our edge-servers share load between each other. That means, that viewers are separated between lots and lots of servers, based on:
- Geography/Topography – which means users get the stream from the nearest location (both geographical and providers routes)
- Overload - if one server in location has full channel, the next viewer from the same geographical point will be balanced to the neighbor server.
And of course, if one server is out of work for any reason, traffic will be re-routed to another server in the same cluster. This means viewers will never get drops in the Live Stream.
No, you don’t.
We have our own CDN. With servers all over the world. You don’t need to look for another provider for your stream’s delivery. It’s all built-in for you.
Our CDN is preset for streaming by default if you’re using our Streaming Platform.
All the settings for caching playlists and chunks are made by us, based on the experience and average streams parameters. We also cache streams not in the HDD/SDD of our servers but in the Operative Memory which means that content will be delivered to viewers faster and with no freezes.
The information will be here soon.
We use our own infrastructure. This means - we can set-up the ingester/transcoder for you in any location where Gcore has Cloud service.
By default, we have ingesters/transcoders in Ashburn (the USA), Luxembourg (to cover Europe) and Singapour (to cover Asia). Of course, they’re united into clusters for redundancy and overcoming huge loads.
Those locations are usually enough for the streamers from the USA/Europe/Asia. And of course, we deliver these streams using our CDN. So, if your streamer is located in the USA and the viewers are in Europe, viewers will get the stream from the European servers.
But If you still want something closer to your streamers, check the map and send a request to us.
We have the following Latency for the following protocols:
- Reduced Latency HLS (the most common for any cases) – 6-8 sec
- Low Latency DASH (the most stable LL, but doesn’t work in native iOS AVPlayer, although it works in Safari, iOS, with our player) – 3-4 sec
- Apple Low Latency HLS (LL working on any device including iOS) – 4 sec
- HESP (special HTTP-based protocol, works only in the specific player) – less than 1 sec
We also have WebRTC for the case with VideoCalls - real-time latency. But that technology isn’t working with CDN. So, it’s better to use WebRTC for real-time communication, not for high-quality streams. Read more on that here.
We don’t charge for our basic transcoding in the basic protocols (that means quality up to 1080, HLS/DASH/LL-HLS).
So, you pay only for the minutes your viewers watch the stream.
Price for 1 min of watching is Є0.001. For example, you had a 1-hour stream and 10 viewers have been watching it from the beginning till the end. So, 60mins * 10viewers * 0.001Є = 0,6Є
We’re charging per month. That means, if during one month there was only one 1-hour stream with 10 viewers - you pay only for that.
If in the next month you expand to ten 100-mins streams with 100 viewers watching each stream from the beginning till the end, you’ll pay 100users * 100mins * 10streams * Є0.001 = 100Є
So, it depends on your consumption. You don’t pay more than you’ve spent.