[HN Gopher] Owncast is a self-hosted live video and web chat server
       ___________________________________________________________________
        
       Owncast is a self-hosted live video and web chat server
        
       Author : memorable
       Score  : 118 points
       Date   : 2022-06-20 14:07 UTC (8 hours ago)
        
 (HTM) web link (owncast.online)
 (TXT) w3m dump (owncast.online)
        
       | throwaway81523 wrote:
       | Can someone explain what makes this different from Jitsi,
       | Nextcloud Chat, and other stuff of that sort? I get that this is
       | a useful software category but it would be good to have a guide
       | to what is what.
        
         | sbarre wrote:
         | I think the goal here is to have an out of the box "self-hosted
         | Twitch" experience.
         | 
         | Spin up their Docker container, connect it to a storage
         | provider, and you're good to go.
         | 
         | Jitsi and Nextcloud are video conferencing solutions if I'm not
         | mistaken, this is livestreaming.. A bit of a different model,
         | where only the broadcaster is sending out video, and everyone
         | else is just watching and maybe using the (text-based) chat
         | room.
        
       | RektBoy wrote:
        
       | foxhop wrote:
       | This seems really cool, I like that it seems to be compatible
       | with the existing twitch APIs in regards to webhooks for
       | automation, not that I've ever used those cabibilities yet on
       | twitch but knowing that the workflows could be written once &
       | work both on twitch & owncast which means migrations are possible
       | for even popular steam channels.
       | 
       | I have half a mind to rig up an old phone to stream my garden &
       | chickens 24/7 to an owncast server as a test.
        
       | lelag wrote:
       | The idea to self-host your own livestream is a great idea in
       | theory but is unlikely to be economical in practice due to
       | bandwidth cost.
       | 
       | Even if you do manage to set everything properly on your own,
       | with a CDN and all, it will become quickly expensive for a
       | moderately popular streamer and the cost with scale up linearity
       | with popularity (hence with your revenue).
       | 
       | Assuming the following:
       | 
       | - you are using AWS and CloudFront as CDN
       | 
       | - your have 300 viewer on average
       | 
       | - your viewer average bandwidth is 3 Mbits
       | 
       | - you just stream a healthy 30 hours per week (pretty low for a
       | popular Twitch streamer)
       | 
       | CDN Bandwidth cost alone would hit 1000 USD per week. To put it
       | another way, every viewer cost you 3 USD per week. Even with a
       | generous community, that's not going to work out financial for
       | most streamers.
       | 
       | Self-hosting would only work for very small community allowing
       | you to stay in the free tier of a cloud provider but that won't
       | take you far.
       | 
       | There is a reason Twitch is almost a monopoly and all powerful:
       | it does not make economic sense to be elsewhere unfortunately.
        
         | Sebguer wrote:
         | > Twitch is almost a monopoly
         | 
         | Calling it Twitch, rather than Amazon, makes it sound better.
         | But really, it's Amazon that's the monopoly - and they're able
         | to use their bandwidth pricing power to prevent anyone else
         | (aside from other mega-scale cloud providers) from getting
         | anywhere close.
        
           | nsriv wrote:
           | This is a great point that I wish was made more often.
        
         | tracerfett wrote:
        
         | jonathantf2 wrote:
         | Why would you be hosting this on AWS? Host it on a normal cloud
         | provider that doesn't rip off it's customers with bandwidth
         | fees and you'll find it's quite affordable.
        
           | eropple wrote:
           | Cloudfront isn't a great option here, but CDN transit fees
           | are still pretty high for this sort of scenario unless you
           | have significant economies of scale.
        
         | melony wrote:
         | Your math is off by an order of magnitude. That pricing is for
         | web apps. For streaming, look towards Bunny CDN and similar for
         | wholesale pricing.
        
         | bityard wrote:
         | > you just stream a healthy 30 hours per week
         | 
         | Unless streaming is somehow your job, I fail to see how that is
         | even remotely healthy.
        
           | looperhacks wrote:
           | For many popular streamers it is indeed their job
        
           | fragmede wrote:
           | "somehow"... Twitch pays about $3.50 per 1,000 views to full-
           | time streamers, starting somewhere around 500 regular
           | viewers. Top end streamers make $5k/mo streaming 40 hrs a
           | week. It's not SF senior dev money, but high-school me would
           | think it's pretty cool to be making money "just" playing
           | video games. (Instead I'm posting on HN for free.)
        
         | bryans wrote:
         | What you're describing isn't very realistic, since nobody would
         | willingly choose the most expensive option(s) for transfer --
         | and CDNs aren't even particularly useful for live video, as the
         | minimal latency increase of using a single location is easily
         | counteracted with larger buffers, all of which is already baked
         | in to the protocols.
         | 
         | Here's some counterpoint math including revenue, using even
         | higher bitrates across a couple cheap load-balanced 4Gbps VPSs.
         | For simplicity, I'll use a single average stream.
         | 
         | Transfer: 300 avg. viewers * 6 hours * 5mbps = 4TB @ $0.01/GB =
         | $40
         | 
         | Revenue: 5,000 total views * 0.01 conversion * ($5 avg.
         | contribution - processing) = $228
         | 
         | That's a $188 margin self-hosted versus approximately $120 via
         | Twitch mechanisms. Presuming 5 streams per week, Twitch is
         | taking a $17,000/year commission. Twitch does provide some
         | other functionality and very minimal discovery, but if you
         | already have a dedicated audience, then self-hosting absolutely
         | makes sense for any sized streamer, especially considering that
         | you're not limited to streaming to only one platform.
        
         | ryukafalz wrote:
         | How about peer-to-peer delivery like with PeerTube? It
         | introduces a 30s-1m delay, which may not be acceptable for some
         | streamers, but in exchange the users watching also participate
         | in distribution.
        
           | Karrot_Kream wrote:
           | A lot of the fun from live streaming is directly interacting
           | with the streamer in chat. 30s-1m variable (I presume this is
           | HLS torrenting?) latency would dash all the fun.
        
           | vorpalhex wrote:
           | I think a cheap streaming solution using bittorrent would be
           | awesome. You would still need a beefy seed host but otherwise
           | I'd love to something like that exist.
           | 
           | For a lot of cases, 60s of latency is fine.
        
             | ryukafalz wrote:
             | This does exist, by the way: https://joinpeertube.org/
        
             | idiotsecant wrote:
             | For streaming I think a big part of the experience is
             | 'chat' all seeing what each other are commenting on the
             | thing that is happening right now, and the streamer's
             | interaction with chat. Throw in a 30-60s delay that is
             | variable depending on user and you destroy that element.
        
               | vorpalhex wrote:
               | It just depends. Obviously "Twitch plays X" sort of
               | content where there is a lot of audience participation
               | isn't great with that much delay, but there are a lot of
               | streamers where chat is more reactive than suggestive and
               | a delay there just doesn't matter much.
               | 
               | You may want to add in an artificial delay to chat though
               | so it's synchronized to the video.
        
           | codemonkey-zeta wrote:
           | On the other hand, it may be a _feature_ for some streamers:
           | 
           | "Our service includes built-in stream-sniper protection by
           | default!"
        
         | jszymborski wrote:
         | It'd likely involve a huge amount of latency, but any chance
         | you can get a livestream working with torrent.js in the way
         | PeerTube does? Maybe using HLS or something? Would certainly
         | address some of the bandwidth concerns.
        
         | oever wrote:
         | Livecasters with a large audience could fund development of
         | multicast support for Owncast.
        
         | xiconfjs wrote:
         | therefore renting a dedicated server from a provider with 100TB
         | traffic included is still useful - there are many of them [1]
         | around ~70EUR/month
         | 
         | [1] https://www.google.com/search?q=100+tb+trafic+server
        
           | candiodari wrote:
           | Something like Hetzner will also work for 30 euro/month and
           | certainly won't run out of bandwidth. Plus this isn't a great
           | amount of traffic, getting a decent VPS should work fine.
        
             | hdjjhhvvhga wrote:
             | I think the times of EUR30/month are over, Hetzner is now a
             | EUR40/month provider (unless you take some hardware from
             | the auction - I did and it was mostly fine, but with much
             | lower specs than their regular offering).
        
         | lrae wrote:
         | While I agree that it's not cheap, no idea why one would choose
         | Cloudfront for live video which is pretty down there in the
         | choices of a CDN for live video.
         | 
         | With Bunny you'd be at what, not even a $100.
        
         | fragmede wrote:
         | > unlikely to be economical in practice
         | 
         | > your have 300 viewer on average
         | 
         | > a healthy 30 hours per week
         | 
         | I get that live-streaming on twitch is a whole thing, but many
         | streamers would be really happy to get 30, or even 3 viewers,
         | and don't stream anywhere near 30 hours a week. If you have a
         | _good_ home connection with a decent, no-cap upload, there 's
         | no need to pay a cloud provider either.
        
           | paulmd wrote:
           | > If you have a good home connection with a decent, no-cap
           | upload, there's no need to pay a cloud provider either.
           | 
           | serving viewers directly from your home IP means they know
           | your home IP, and there's definitely already trends both to
           | fuck with streamers generally, and specifically in games to
           | DDOS people and get them dropped from the game.
           | 
           | Usually the mechanism for leaking IP data is voice chat
           | (since that's often implemented via P2P because game
           | companies are cheap) but you're talking about making your
           | home IP available to everyone who connects to your stream.
           | 
           | "Your computer is broadcasting an IP!" advertisements
           | aside... there _are_ scenarios where that 's a problem,
           | specific IPs can certainly be DDOSed off the internet and
           | that means a streamer won't be able to stream anymore.
        
           | idiotsecant wrote:
           | I think the benefits that twitch provide go beyond just
           | bandwidth. There might be enough bandwidth on a good home
           | connection but onboarding users, building a community,
           | getting sales to advertisers to support the service, etc are
           | all core function that would be quite difficult for a sole
           | provider to handle.
        
         | LinuxBender wrote:
         | That could be true, especially if one live streams 24/7. It
         | might be a nifty proof of concept if they set up a live demo
         | without a CDN on a bog-standard VPS provider like Linode,
         | DigitalOcean, Vultr, etc... Does anyone here have this running
         | in one of the VPS providers?
        
           | mig39 wrote:
           | Also interested to know this. How many people watching can a
           | cheap VPS like Linode handle?
        
           | crtasm wrote:
           | Here's an instance running on Linode:
           | https://live.retrostrange.com/
           | 
           | List of instances: https://directory.owncast.online/
        
             | LinuxBender wrote:
             | Nice! What is the highest number of viewers you have ever
             | seen on a stream at once?
        
               | crtasm wrote:
               | I just found it in the list, wonder the same.
        
           | vel0city wrote:
           | Running the numbers for 300 streamers at ~3Mbps each for ~30
           | hours a week works out to 12,150,000MB. That value * 4 for
           | about monthly bandwidth usage. For a s-4vcpu-8gb instance on
           | DO, that's ~$436 monthly overage on a $40 monthly cost
           | droplet. Not too insane, but you're really stressing out that
           | single droplet. You'd probably want to balance that across a
           | few different instances across the country instead of it all
           | being on a single droplet, in which case you're essentially
           | rolling your own probably crappier CDN and trading CDN costs
           | for your time managing it all.
        
             | thakoppno wrote:
             | For ~300 streamers, wouldn't a single symmetrical fiber
             | 1gbps line, like a residential AT&T install, basically
             | cover it?
             | 
             | The TOS prohibits it but I always figured it'd be fine so
             | long as one didn't get too popular. I guess I'm wondering
             | to what extent increased residential bandwith keeps CDN
             | bandwidth cost in check.
        
               | paulmd wrote:
               | Streamers won't want to serve directly from their home IP
               | because it makes them a DDOS target.
        
               | thakoppno wrote:
               | Ddos prevention never crossed my mind, good point. I
               | don't spend much time in the gaming community. Who would
               | be the most likely attacker, a competitor in the game
               | trying to get an advantage? If so, thats kinda
               | fascinating in a way. It's almost like a cyberwar
               | scenario where the battlefield is virtual and physical.
        
               | paulmd wrote:
               | it's both, competitors in the game (or just trolls) have
               | attacked random in-game players using IPs leaked from
               | things like VOIP chat in games (which is often
               | implemented P2P rather than running through the server)
               | and people also specifically go after streamers to harass
               | them.
               | 
               | https://www.eurogamer.net/dead-by-daylight-streamers-are-
               | bei...
        
               | Karrot_Kream wrote:
               | Other than the DoS attempts the sibling mentioned, the
               | symmetric Gigabit on a home connection varies depending
               | on congestion, and NAT mapping could change changing your
               | IP causing the whole Livestream session to renegotiate.
        
             | LinuxBender wrote:
             | Agreed that was my thought process as well. One could spin
             | up a few dozen instances, start the live stream and then
             | nuke the instances. That should scale to however many
             | viewers one has. I guess that begs the question does this
             | application have the instrumentation or hooks that would
             | make it super simple to scale up nodes on demand? Like an
             | API to query number of viewers and their bandwidth settings
             | to calculate required capacity.
        
           | throwaway81523 wrote:
           | I've livestreamed with ffmpeg and Icecast fanned out to a
           | layer of cheap VPS and that worked ok. Yes there was enough
           | lag to be annoying but not anything like 40 seconds.
        
         | crtasm wrote:
         | Other than preventing some viewers seeing a delayed feed, why
         | do I need a CDN at all? This can run off a single server with a
         | 1Gbps uplink... can't it?
         | 
         | In any case there's plenty of people/organisations who run less
         | regular streams and don't need to serve this many viewers.
        
           | vorpalhex wrote:
           | Latency and scaling, yeah. Depending on stream setting and
           | encoding you might saturate hardware before bandwidth.
        
       | password4321 wrote:
       | I'd like to know what can be supported multiplexing through a
       | Scaleway Stardust instance, "up to 100Mbps" unmetered for
       | EUR2/month.
        
       | pmontra wrote:
       | Is this project affiliated or owned by Facebook / Meta? In the
       | HTML source:                 <meta property="article:publisher"
       | content="https://www.facebook.com/"
       | 
       | Maybe a copy and paste leftover. I noticed it when I pasted the
       | link in Telegram and the preview displayed the Facebook URL.
        
         | jjice wrote:
         | My guess would be that the default is to take a config car
         | that's your Facebook link and append it to the end of that URL.
         | But that's just a complete shot in the dark.
        
         | [deleted]
        
       ___________________________________________________________________
       (page generated 2022-06-20 23:01 UTC)