Show HN: Owncast – An open-source, self-hosted live streaming server
60 comments
As a general comment on how you can do this sort of thing super minimally:
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.
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.
If you use nginx as your http server then you don't need ffmpeg to cut up your RTMP streams, the nginx rtmp module will read RTMP streams and serve RTMP, HLS, and DASH. Throw the stream module in front of it and you can do RTMPS.
Was this plugin recently re-licensed from paid to open source?
The source is available here under a BSD style license: https://github.com/arut/nginx-rtmp-module
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.
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.
It was included in nginx plus subscription as far as I remember
this is spot on - I attempted to create an adult entertainment site and this was the crux of it. The security aspect of the entire architecture is a whole different endeavor.
I wonder how much latency is added in when you feed the RTMP into ffmpeg.
Why not just plain old webrtc with the viewing clients muted.
Why not just plain old webrtc with the viewing clients muted.
Not many security cams support webrtc and if doing broadcast (and the server is directly reachable) HLS or MPEG-DASH is usually more efficient anyway since plain file serving is simpler and can be cached/optimized in ways that are harder for protocols like webrtc. HLS/MPEG-DASH are higher latency, but that can be reduced to a few seconds or less with tradeoffs.
There are also things like LL-HLS and others coming down the pipeline that will further reduce latency issues with a lot less complexity than WebRTC. (Maybe not for the security camera not-many-viewers use-case, but certainly for anything being watched by a lot of people)
This is really cool, thanks for pointing this out. Definitely a different use-case but never knew it was this simple to stream video.
For video streaming I would prefer to use WebRTC over RTMP
In the case of home security cams, WebRTC is generally not an option. If it was I’m sure we would have a slew of new browser based monitoring solutions.
As someone who doesn’t know much about the two protocols: how come?
WebRTC is amazing and definitely has its uses in video streaming, but it does present a number of challenges and disadvantages. Simplified, it can have lower latency and higher reliability, but at the cost of compatibility and scalability. (Also, "higher reliability" takes a lot of work to implement properly, whereas out-of-the-box for most users it would likely be lower reliability.)
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.
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.
Here is a good answer https://www.quora.com/Which-is-better-for-live-streaming-RTM...
I guessing it's because Webrtc is near real-time whereas transcoding to HLS would add latency. However the advantage of HLS is that you can offload the serving of the content to a CDN or a Http server and scale horizontally. Whereas serving more webrtc clients would require fatter/bigger webrtc server.
Please note I am only basing my opinion base on what I have read on HN.
Please note I am only basing my opinion base on what I have read on HN.
for the average person, all of those things you listed might as well be magic.
Ah, yes. The Dropbox comment!
The parent comment seems a lot more understanding to different use-cases than the classic dropbox comment. It even ends with
> 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.
> 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.
Perfect :) I was searching for tutorials on how to set up my own OBS streaming proxy just 2 days ago. And Go is so very nice because I can compile all I need into one big monolithic binary.
Thank you :)
Thank you :)
Indeed, I am certainly watching this space. Another “contender” is Boltstream [1] that was posted only a few weeks back. I am itching to take them all for a spin and kick tires!
[1]: https://github.com/benwilber/boltstream
[2]: https://news.ycombinator.com/item?id=25328622
[1]: https://github.com/benwilber/boltstream
[2]: https://news.ycombinator.com/item?id=25328622
Was also considering a stream proxy for OBS and Atem mini pro and thought about the Docker container of this. But you are right, with onw self containes Go binary, what's the point of docker here... Great, have to tinker.
This looks really good! I just set up Open Streaming Platform [0], but I wish I had found this sooner, as setting that up was slightly annoying (nothing against the platform - it's been working great, I just don't need its full power and my server is a huge mess).
Next time I'm setting up a streaming server, I'll definitely be checking this out!
[0] https://openstreamingplatform.com/
Next time I'm setting up a streaming server, I'll definitely be checking this out!
[0] https://openstreamingplatform.com/
Awesome! Let me know if you have any questions when the time comes.
Nice docs. I had no idea you could do this locally. Out of the loop on video streaming, but looks like a webserver serving files(video segments - chopped up based on needs). Just curious roughly how many simultaneous clients can a generic desktop serving lets say one low quality stream (360p?) handle?
I think your last question highlights that you really wouldn’t run this locally. Probably on a VPS or something with a ton of bandwidth.
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’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.
One option is offloading the bandwidth requirements to a S3 provider. You could run your server from home and keep your local outbound requirements low, you'd just be handing off the video to somebody who can handle it. Depending on your scale many S3 providers can be pretty cheap.
I know of one person who does this specific setup and it's been working great for him!
I know of one person who does this specific setup and it's been working great for him!
I noticed that as an option once I started looking closer. That's pretty nice! Just gotta be careful to estimate and monitor costs but depending on the use case it could make a very compelling option.
Your best bet is to run this in a VM somewhere in the cloud. Each stream is going to consume bandwidth, and you'll quickly run out if you do this at home.
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.
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.
BTW paid, fully managed offering for such a service is available courtesy of creators behind Twitch itself - AWS-IVS https://aws.amazon.com/ivs/ demo : https://codepen.io/amazon-ivs/pen/wvMLZLz
AWS's offerings for this are NOT cheap
> The total cost of a two-hour event with Standard input at 1080p and delivered to 200 viewers from the US (100 viewers in SD, 50 viewers in HD, and 50 viewers in Full HD) is $34.00.
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.
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.
DrDisrespect doesn't have 200 viewers. Multiply the numbers and see all donations going to amazon.
This is great! No worries about violating other streaming site's rules and getting banned. One thing that's missing is a discovery engine to find Owncast streamers.
There is actually a directory at https://directory.owncast.online/, although not many people have added their instances to it yet.
https://github.com/arut/nginx-rtmp-module is also great for anyone that wants to setup just a streaming server. However, it doesn't seem to be maintained anymore, but there are some maintained forks.
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
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
This is super nice so congratulations - but I wouldn't it use self-hosted version of Twitch to sell it. I have a few friends who use Twitch and they don't use it beause it is easy to stream, they use it because of all the features related to their suscribers. Email notifications, payments, donations, etc.
Sayings this is the self-hosted version of Twitch is like saying a Wordpress with password is a self-hosted version of Patreon.
Sayings this is the self-hosted version of Twitch is like saying a Wordpress with password is a self-hosted version of Patreon.
not to mention the community that already exists on Twitch would take massive effort to re-build elsewhere.
Very cool! Sorry for the novice question but I checked the docs and FAQ and didn’t see an answer:
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!
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!
A super brief summary of the streaming protocol is that you encode short (3-10 second) clips that are available on a URL, and then clients play these clips in order. For storage of these clips you could use an external storage or CDN - see the docs at https://owncast.online/docs/s3/ for more :)
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.
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.
ffmpeg is able to capture from webcam, desktop, or vod
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
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
Super cool - great answer and thank you!
As someone else mentioned, you'd likely want to run this on a "cloud" server with the necessary bandwidth available.
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.
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.
You just missed the step where you quickly become 10x bigger than any member of the recording industry and become the one telling politicians how to re-write their silly laws.
But I hear you had better luck with your room-sharing app.
But I hear you had better luck with your room-sharing app.
[deleted]
Interconnected self-hosted social networks are the future.
... just like flying cars!
This is nice, I've tried to build a simple streaming server myself, so couple of questions if you don't mind:
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?
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?
1. Websockets
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
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
This looks great! I’ve been looking for a solution to broadcast about 20 IP cams on the web (behind auth). Could this or it’s backbone be used to do that?
This is great! Looking forward to test this :)
How does this relate to PeerTube?
AFAICT PeerTube offers video sharing. This one allows live streaming.
PeerTube has live streaming: https://joinpeertube.org/news#release-3.0rc.
congrats, Gabe -- amazing to see Owncast grow these past few months!!! great work by you and the team!
cool stuff.. PS note XSS by manipulating the img URL of an emoji in the input
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