Ask HN: Recommend video streaming CDN service
I would like to provide users with video streaming but would like to avoid the hustle of running the infrastructure.
Can you recommend a cheap CDN service for video streaming?
The way I imagine it is that a user will request a video stream instance, I will set it up via automated API calls and provide the user with access details for OBS(or similar software). The user then starts the video stream. Other users/audience will be able to watch it on my platform via embedded video player that will be streaming the video from this video cdn service. And I will be charged per use(although I would prefer something more predictable, rather than actual per-data pricing to not go bankrupt in case of sudden extreme interest in some video stream).
https://github.com/cannonbeach/ott-packager Then feed that into any CDN which works with HLS, which should be all of them.
All CDNs are going to charge based on usage, that's how they work, some offer a free tier but you have to take responsibility for managing your costs and ensuring your revenue scales (otherwise just use YouTube)
Alternatively there's also: https://www.mux.com/live
Mux founder here, thanks for the mention!
The cost bit is one hear a lot, and it's tough. There's no way around it, video can just get expensive at scale. Services that try to get away from charging for usage are just trying to play an averages game; once you cost them enough you'll hear from them.[1]
We are looking at ways to help developers limit the risk of a runaway bill and just generally manage their cost shape a little more. If you're up for chatting about it feel free to shoot me a note (matt at mux).
[1] https://www.theverge.com/2022/3/15/22979126/vimeo-patreon-cr...
Since you care more about cost and don't mind building it yourself, just build it yourself.
ffmpeg -> MPEG-DASH -> nginx + MPEG-DASH -> your own video player.
If the video isn’t streaming IN, then you can use anything that can serve https
This isn't true.
Using ffmpeg you can transcode one stream to HLS stream.
Example: https://www.martin-riedl.de/2018/08/24/using-ffmpeg-as-a-hls...
> The data is delivered over a HTTP/HTTPS connection, so it can be also perfectly cached on server side or used in combination with an CDN.
We are not in disagreement.
Nothing prevents you from doing this live either though, except maybe if you need very low latency.
From what I've noticed in our setup latency these days is in the encoder. Everyone is pretty good at pumping out segments and stuffing them into disk.
Of course, I'm on AWS using SSDs, MediaStore, and CloudFront (as a testbed; we use medialive for production). If you're on a spinning disk you'll have contention and throughput issues (ie: you can't expect to write and read to that guy effectively).
I'd suggest dropping to 24fps, since you're not doing fast action sports. Also, use the Apple HLS authoring guidelines as a baseline for your bandwidth settings. Overall they seem to be pretty good.
As with any compression, high quality in is better, because it gives the encoders more data to work with.
360p is pretty worthless.
What you can try and do, if you want to ride the edge of legality, is start an unlisted youtube livestream then extract the m3u8 out of it and send it to your clients.
+1
You most likely want https://antmedia.io/ Ant Media WebRTC streaming library. It's the back-end for most adult streaming sites and alternative livestreaming sites. Cheapest option by FAR if done on budget hosts, especially if bandwidth is free or cheap (ex. Hetzner Cloud US gives 10TB free).
Some other options:
Free:
https://jitsi.org/jitsi-meet/ Free/Open Source, built for video calls but also works for livestreaming*
https://livekit.io/ Free SDK, similar complexity to Jitsi but tailored specifically for live streaming
https://www.ovenmediaengine.com/olk Roll-Your-Own auto-scaling live-streaming solution
...
API as a Service:
https://www.100ms.live/ Super low-latency livestreaming API with premium pricing
https://castr.io/ All-In-One, ok pricing
https://www.api.stream/ Good, pay as you go pricing
https://liveapi.com/pricing/ Good, pay-as-you-go pricing
https://www.simplelive.co/livestream One click embedded live stream start-up, pricing seems too good to be true
...
* Example repo which used Jitsi for livestreaming to thousands: https://gitlab.com/guardianproject-ops/jitsi-aws-deployment
...
All of the options will run ~$100 to $3000/month for streaming 100 hours a month to 1000 users, with APIs costing the most and bandwidth being the main cost of self-hosted solutions.
<$100/mo is possible by self-hosting on Hetzner or another free bandwidth host.
Using AWS, Azure, or Google Cloud anywhere in your stack can easily 2-3x your costs above the high bound.
Don't know any service that would be considered cheap or even affordable that doesn't charge by the byte or watch time. But I'd certainly like to be proven wrong!
It would be hard to find anything that wouldn't be at least 2x more expensive than running your own, at least the origin/ingest and transcoding side (as well as origin for DVR/recording/VOD). Depending on the scale, running your own edge servers for delivery to viewers might also be a lot cheaper.
i am not afraid of handling the infra myself but the problem is that the tech is still outdated so you have to do h264 and multicast. in other words you have to use old codec(h264), not vp8, vp9 or av1 and you have to transcode the ingress into different resolutions to serve slow clients instead of doing Scalable Video Coding where you have one source and you simply drop some data out of it for slow clients on the egress per client while they still can consume the same source in lower quality. and i just don' want to be doing that entire transcoding and multiple egress streams.
You are mixing things up now. In the OP you mentioned OBS, SVC isn't available there (or pretty much anywhere). It now sounds a lot more like you want to deploy a WebRTC solution, were CDNs play no role.
I am not mixing anything. SVC is on the egress side, not on the ingress side. WebRTC is just a protocol. Seems you are the one mixing terms here ,)
I've been running streaming infrastructure for 14 years. The encoded incoming stream needs to be SVC with subset bitstreams for the server to selectively deliver bitstreams from it.
obviously...
just for fun i checked cloudflare's streaming offer. 6h stream with 1000 viewers would cost 360$.
streaming live is hell expensive
yep, some other cdn(don't remember which) added up to $100. better than 360 but still outside of a budget for daily use. as a one-off, sure, price is not that important. but if i would have just one user streaming once a day for 6h i'd go bankrupt in no time.
right now i am thinking i would simply do 1:1 streaming. so no transcoding. what you put out is what the audience gets. so if you stream with too high if a bitrate, tough luck. i could handle it with couple of cheap VPSs.
So far I think the best option will be to do it on my own. But I would do it this way - the source would have to be VBR, not CBR since no transcoding would take place. What is put in is also what will be put out. With 1Mbit recommended quality.. The ingress will simply chunk the stream into 1-2 second segments and those will be sent to my "CDN" servers which will serve it from memory only with about 30sec buffer. The data would be pumped out via websocket(so i can easily send binary data) into MediaSource js object as uri for html video src. If the client is too slow consumer, he'll buffer the video. I don't need to provide youtube level of service.
--
Just did a small test with 10 sec desktop video recording in OBS:
CBR 3.35 MB
VBR 343 kB
ABR 840 kB
CRF 344 kB
So by not using CBR the data stream can deliver the same quality at 10x lower size(VBR, CRF) or 3.9x in case of ABR. CBR is needed for transcoding due to speed needed for that process but if I would pipe the data 1:1 as I said, then CBR is detrimental.
Note that if you use VBR instead of CBR the video player will have more trouble with buffering logic because (many players) will buffer a fixed duration or number of segments. When there's lots of action the bitrate will be high and when it's idle it will be low, so the variability causes buffer challenges.
Capped VBR is one of the most common ways to do VBR on live streaming.
i understand. the ingress will chunk the stream into those segments(1-2 seconds long), remember the encoded video is packed in mp4 container, and pass them on to the egress/edge/cdn servers into their in-memory buffers. so the only processing will be done in regards to those chunks.
I looked into this a few years ago and it was pretty rough. There are free platforms like YouTube, then there are extremely expensive options. The least expensive of the expensive options I found was just digital ocean, but I found playback didn’t work under a vpn
Let us know what you find
Azure Media Services?
https://azure.microsoft.com/en-us/pricing/details/media-serv...
Supports HEVC (H.265) output.
https://learn.microsoft.com/en-us/azure/media-services/lates...
You can put budget alerts in place on Azure resources to handle costs.
For live video, bandwidth is a killer. If you have volume and do an upfront committment you can negotiate down to < .01/GB and below.
It's crazy how much people make off of bandwidth. From what I understand, that and RAM are huge margin products for AWS.
Also, you need to do the "get three quotes" thing. Akamai, fastly, and AWS will match/beat each other if you ask.
Cloudflare Stream? Seems perfect for your, and they do not charge per bandwidth, as usual by cloudflare.
bunny.net Video Streaming service might also be interesting for you
i did, 6h stream at 1Mbit with 1000 viewers would be 108$. i can have 3 powerful VPSs with 2Gbit unlimited bandwidth in OVH. so far it seems there is no service that makes financial sense :(
Fastly
YouTube?