Show HN: Owncast – An open-source, self-hosted live streaming server
I've been little by little chipping away at building an easy to use and super useful live streaming server for individuals. It's still early days, but some recent updates include a dashboard where you can see some basic viewer metrics, configuration settings, and how your hardware is handling all that video crunching. We all know working with video can be intensive on the hardware side, so hopefully this helps people keep tabs on things.
There's a demo server if you're curious what it's like. But if you're a streamer, or even have a little interest in the space, I'd love for you to give it a spin. Feedback is highly appreciated!
If you want to learn more about the project check out the documentation, and of course all the source, issues and additional discussion are over on Github.
Demo: https://watch.owncast.online
Github: https://github.com/owncast/owncast
Documentation: https://owncast.online
60 comments
[ 3.0 ms ] story [ 134 ms ] threadThank you :)
[1]: https://github.com/benwilber/boltstream
[2]: https://news.ycombinator.com/item?id=25328622
I’m sure someone else will have better usage benchmarks but bandwidth is likely to be the biggest constraint. Number of streamers is roughly going to be available bandwidth divided by bitrate of stream.
I know of one person who does this specific setup and it's been working great for him!
About 10 years ago, I did a live stream to about 200 people, streamed up via a cellphone link (it was new stuff back then), then to a Windows Server instance on Amazon ECS, and out to all the users.
It seem you should be able to handle similar numbers these days.
1. What technology are you using for communication of chat text and video ? WebRTC/Web Sockets/ RMTP or something else.
2. Whats the latency like for videos?
3. Does the project has any controls/customization for video player?
2. Depends on the size of chunks and amount of files in the HLS playlist. Both are configurable values. Anywhere between 3 and 20 seconds
3. Not yet, but it's planned
Can you explain a bit the dynamics of streaming from your own server? How does bandwidth / broadcast work? Do you need enough upstream bandwidth to support (Stream bitrate * # of clients)? Or is there a broadcast protocol that takes advantage of a CDN? My understanding of the commercial services is that their value isn’t just in providing a server, but it’s the huge amount of bandwidth required to support N simultaneous high bitrate streams. But maybe I have a misunderstanding.
Thanks!
Edit: Of course this means that this
> Do you need enough upstream bandwidth to support (Stream bitrate * # of clients)?
is indeed the case, but you can offload that to the external storage.
you only need the correct software and public ip , and upload bandwidth to stream properly
how would you do this ?
install ffmpeg , setup a bash script to capture from webcam or device, install nginx or lighttpd to serve basic html with the HLS video.js player. map your ip or dynamic to your www.myname.com , to make it better you would also add a cheap cdn, such as bunnyCDN.com 5euros per month for 1TB
you create a add your domain.com on bunnycdn.com, and create a new subdomain cdn.domain.com which directs to the bunnycdn.com/username they provide you. thats it.
the file segments would be offloaded on their servers basically , they provide feature on how long you want to keep the segments on their global servers.
the same way all this works, could be done with webtorrent live streaming on webRTC, some adult sites live streaming adult sites have already started to use this method webRTC peer to peer
Reminds me of running a Shoutcast station back in the early/mid 2000's. At first I was just playing around and had the Winamp plugin configured to stream to the server running on the same PC. I think I used one of those dynamic DNS services to keep it accessible to the outside world but I may have just updated it when my WAN IP occasionally changed (oh...those sweet, naive days of not worrying when I opened those kinds of ports). A 128kbps mp3 stream to a few people at a time was workable.
Eventually a guy I knew from some web forum offered to host the server for me. He worked for a small-ish ISP and hosting company and said they'd never notice or care if I bounced it off their server because even 10 or 20 people streaming 128kbps at once wouldn't even show up on their radar. Sure enough, I had no issues and never even had anyone come complaining that I was streaming my personal selection of music without paying any licensing fees.
That said, I eventually got a little worried and began to research the cost of licensing. I didn't like the idea of getting sued and this was still the time of RIAA lawsuits against p2p services. Unfortunately, it was also the time when they lobbied hard to increase the cost of legit licensing for streaming. Whereas radio only pays for a blanket license, streamers had to be able to track per-song-per-listener numbers and also pay royalties, unlike terrestrial radio.
That sorta put the kibosh on my streaming radio ambitions. A nerdy personal experiment was one thing, but I was starting to get enough listeners that I wasn't eager to end up on the wrong end of a nasty letter from someone's legal department. The cost of going "legit" had become too high and honestly, I didn't have enough original/local/whatever content to offer anything unique. At best it was like having "free" XM radio back when that was all the rage before Youtube and Spotify made such things irrelevant.
But I hear you had better luck with your room-sharing app.
You can use ffmpeg on the command line to transcode anything it can read (including streams) to an HLS playlist + segments, and serve those HLS playlist + segments statically using any HTTP server. Then you can write a simple HTML page that uses a video player to play it back in a browser.
I used this to create a simple dashboard page for my home security cams (they provide an RTMP stream I can feed right into ffmpeg) after I got sick of the software I had eating too much CPU (I use '-v:copy -a:copy', so no actually re-encoding happens).
Obviously, this owncast is cool for probably being easier to setup, definitely better looking, and having more features, like chat. I just wanted convey there's nothing magic to doing your own streaming video. More people should do it instead of feeding into the YouTube/Twitch behemoths and untrustworthy cloud IoT stuff.
Please note I am only basing my opinion base on what I have read on HN.
For the use-cases mentioned about home security cameras and other personal or low-volume situations where you also have knowledge of and control over the playback devices, sure, you can get away with it no problem. But if you are building a streaming platform for public consumption or something, we just aren't there yet. Delivering video over WebRTC to tons of clients is much more complex than serving them chunked flat files. With HLS/DASH, your clients are just downloading tiny video files over HTTP, and they can be live or be served up by anywhere -- nginx, S3, anything. It's not much different on the server-side than how file serving has always been. WebRTC though requires each client to be connected in constant 2-way communication with the server, and the logic/work the server has to do goes up tremendously since it will be attempting to chop up and serve the exact number of bytes of video each individual client needs on-the-fly rather than each client getting the same identical 1- to 4-second chunks. This presents even more challenges if your clients are at different parts of the stream, have crappy bandwidth, etc.
In terms of compatibility, WebRTC is widely prevalent, but not nearly the same as HLS/DASH. Many clients that do support it have their own quirks, limitations, etc. that need to be catered to slightly differently, especially on mobile devices.
For these reasons and others, you currently see WebRTC used for broadcast right now mostly at the scale of dozens to maybe hundreds, but not more than that.
What WebRTC is very useful for is p2p. It has enabled things like WebTorrent to have users be serving video to peers while they are themselves watching, reducing strain/cost on the provider. It is also clearly beneficial for things like conference calls, where there is a small number of clients talking to each other multidirectionally.
Why not just plain old webrtc with the viewing clients muted.
I don't know the paid/OS history of the module but all I had to do to get it was check a checkbox on FreeBSD since it was configured as an option in the port.
> Obviously, this owncast is cool for probably being easier to setup, definitely better looking, and having more features, like chat. I just wanted convey there's nothing magic to doing your own streaming video.
Mentioning the dropbox comment seems to have become a way to dismiss comments without actually replying to them.
Depends who you are. DrDisrespect could have the cost of a day's streaming covered in 15 minutes of donations.
I've got a gigabit link I can play with, so for me it's "free", but for those who just want to stream a few times per month it's potentially a winner.
Next time I'm setting up a streaming server, I'll definitely be checking this out!
[0] https://openstreamingplatform.com/
Sayings this is the self-hosted version of Twitch is like saying a Wordpress with password is a self-hosted version of Patreon.
I made a Docker setup a while back to simplify the configuration with basic settings for anyone curious: https://github.com/alfg/docker-nginx-rtmp