10 ms·

Owncast Instances

71 points by URfejk 6y ago

ekianjo 6y ago
Sharing video content is not an issue per se anymore. The cost of bandwith is when you become even remotely popular.
- simplecto 6y ago
  That is a good problem to have. I admit this is a chasm where cash goes to die. The interesting part is where content creators, personalities, etc own their own rails. They don't need a massive audience to run their own show. Even if I only push 10-20 TB / month that is enough to make a lifestyle "+" business. That is my hypothesis, and 2021 looks like a good time to test it. (Edit - I can't grammar, apparently)
  - throwawaysea 6y ago
    How can creators monetize their shows without Google’s ad ecosystem?
    - import 6y ago
      Check how twitch works.
    - rapsey 6y ago
      Merch, membership and membership only events/videos, tipping, etc.
      - ianbooker 6y ago
        I was inclined to say that you need the right niche with the right culture. See game streaming with it small but frequent donations. But with enough momentum your apparently can create such a culture in quite some topic areas, like classical trained violin playing: https://www.youtube.com/user/twosetviolin https://www.youtube.com/user/twosetviolin. Interesting!
        rapsey 6y ago
        A seminal essay on this topic https://kk.org/thetechnium/1000-true-fans/ https://kk.org/thetechnium/1000-true-fans/
    - iso1210 6y ago
      Looking at https://influencermarketinghub.com/youtube-money-calculator/ https://influencermarketinghub.com/youtube-money-calculator/ suggests you get peanuts for google adverts - suggests 1 cent per view at most.
      - madeofpalk 6y ago
        that seems to be inline with what I expected.
    - simplecto 6y ago
      Lots of ways: direct ad sales and "reads" (old school way of doing it) run pre and mid-roll in the content (again, already done) paid live-streams with ticket sales. Paul Richards from Stream Geeks wrote a book on this. Merch Paid newsletters / content which is marketed in the show. Everything exists -- lots of value in helping creators stitch it all together. I see a similar opportunity how web devs helped grow the e-commerce for small companies, we will see the same growth helping creators stand on their own.
- import 6y ago
  That's true. If you don't have a solid monetization plan things become harder very quickly.
- luplex 6y ago
  A peer-to-peer-relay approach helps with this! Peertube is apparently getting support for live streaming, or already has it. I can't tell. https://joinpeertube.org/en/roadmap https://joinpeertube.org/en/roadmap
  - corobo 6y ago
    How bad's the delay on live p2p? I'd be surprised to hear it getting below 10s and picture it more at 30 This is not a dig at Peertube, they're doing truly great work. My use case is probably different
    - ekianjo 6y ago
      Apparently Peertube claims between 10 and 30 seconds but I have not tested it.
  - remram 6y ago
    You can run the 3.0 release candidate now, which has live streaming [1]. There are official Docker images available as well [2]. [1]: https://github.com/Chocobozzz/PeerTube/releases/tag/v3.0.0-rc.1 https://github.com/Chocobozzz/PeerTube/releases/tag/v3.0.0-r... [2]: https://github.com/Chocobozzz/PeerTube/blob/develop/support/doc/docker.md https://github.com/Chocobozzz/PeerTube/blob/develop/support/...
BerkhanBerkdemi 6y ago
I guess I'm using strict uBlock rules so streams don't load at all
- ptspts 6y ago
  This hypothesis is easy to test: disable uBlock temporarily for thaf site.
Sidhuharjot 6y ago
Can anyone help me to rank on Google My website is https://latestpunjabithoughts.blogspot.com/ https://latestpunjabithoughts.blogspot.com/ Help me
iod 6y ago
I have had good experiences with the free NGINX RTMP Module¹ for basically doing the same thing. I just have a cheap US and EU cloud instance. Stream OBS in multiple qualities to the US endpoint and have it auto pushed to the EU endpoint. Using this module, both endpoints use RTMPS and generate HLS and DASH. Then added a little HLS.js² player and can easily serve a small private viewing party, at multiple stream qualities with auto quality/bandwidth adjustment. ¹ https://github.com/arut/nginx-rtmp-module https://github.com/arut/nginx-rtmp-module ² https://hls-js.netlify.app/demo https://hls-js.netlify.app/demo
- famoreira 6y ago
  This sounds interesting. Do you have pointers to any resources/tutorial to setup something similar to what you have?
  - iod 6y ago
    Being already familiar with NGINX, I found the examples in the docs¹/docs-wiki³ relatively sufficient. If you care about adaptive HLS streaming, make sure to add "hls_variant" directives for each quality level such as: hls_variant _1080p BANDWIDTH=10485760,RESOLUTION=1920x1080; on the OBS/source side you want to match stream names like: rtmp(s)://your-nginx-server/your-publish-endpoint/your-stream_1080p If you care about RTMPS (with TLS), you will want to look at NGINX Stream Core module⁴, with a server "listen" directive with the "ssl" option and a "proxy_pass" to the RTMP endpoint. For sending RTMPS from RTMP you will need another server "listen" with no "ssl" option and "proxy_ssl on", since the module has no native RTMPS capabilities, in order to get RTMPS as both server and sending client. For RTMP auto-publishing to multiple servers, you will want the "push" directive, and don't forget to give it a "name=" option, or it will grump. I struggled to get the "pull" directives to always work consistently and quickly. If you want lower latency, make sure your source stream has small keyframe periods and that they match "buflen" directive; I opt for 2 seconds. But if using HLS, there isn't that much more you can do on that front. ³ https://github.com/arut/nginx-rtmp-module/wiki/Directives https://github.com/arut/nginx-rtmp-module/wiki/Directives ⁴ http://nginx.org/en/docs/stream/ngx_stream_core_module.html http://nginx.org/en/docs/stream/ngx_stream_core_module.html
dontbesquare 6y ago
This looks great! I've been playing around with NGINX RTMP for video streaming a bit but this seems much more manageable. Looking forward to giving it a whirl!
throwaway399401 6y ago
I've been toying with the idea of offering dedicated, managed Owncast hosting but had not considered HNers as a potentially interested community. The comments on this submission have convinced me otherwise! If you would be interested, please drop me a way to get in touch with you: https://forms.gle/2KiR87rRdC4PSoCd6 https://forms.gle/2KiR87rRdC4PSoCd6 (throwaway because I have currently have a day job that is emphatically not keen about side projects)
- corobo 6y ago
  I can't help but read this as "I've noticed I could make money off other peoples work"
- yokem55 6y ago
  The issue here is if you are handling the hosting of these sites, you are the one to get and handle the DMCA mail when (and it's an inevitable when) your customers do something that runs afoul of the contemporary copyright process. Might want to approach it instead as a consulting service that helps folks set it up on hosting that they are responsible for and have their names on.
  - hedora 6y ago
    The DMCA provides some legal protections to content creators that aren’t available via self hosting. Legal consulting to set up the correct corporate shell structure would probably also be a popular value add.
    - throwaway399401 6y ago
      Can you elaborate on this? Do you mean that if I, as a streamer, set up my own entity (LLC or whatever), I would have more leeway in responding to DMCA complaints, even if I ran my stream on something like EC2 or a typical "dedicated server" or colo?
      - hedora 6y ago
hedora 6y ago
I was wondering how they scale the service up (this is the first one of these I’ve seen that’s survived a HN hug of death). The lazy way seems to be to configure owncast to use an S3 compatible service. Some even support CDNs and provide unlimited egress bandwidth: https://owncast.online/docs/s3/ https://owncast.online/docs/s3/
jcrawfordor 6y ago
I have been running for some time a small single-stream video streaming server. When I saw Owncast mentioned here my immediate thought was to switch over to it, because it has features beyond my homegrown solution (based on nginx-rtmp and a Python/Flask application which performs "management" functions such as authentication of the publisher and injecting an "idle" animation when there is no publisher). For reasons largely of laziness I run this on a cheap VPS instead of on the larger machine I have colo'd. Unfortunately I immediately ran into huge performance issues with owncast compared to my solution, with input bitrates stuck at 200-300kbps. I haven't looked into it exhaustively but I think the main problem is that owncast seems to encode the video n+1 times where n is the number of desired quality levels (extra encoding pass on the published stream to smooth out publishing problems), while my solution sends out the original published stream as the high-quality variant and so encodes n-1 times with a couple additional steps of putting the same streams into new containers. Of course I have also set ffmpeg/libx264 to very high performance options, and I think owncast is less conservative here. Really just an FYI for anyone else looking at making a switch or doing something similar. Video encoding is CPU intensive so if you want to run it on a small/inexpensive VPS, it's helpful to 1) architect to absolutely minimize the number of encoding passes required (even when new containers are needed), 2) provide fine-tuning of the encoder settings, since just the change from "fast" to "veryfast" with libx264 makes a pretty big difference on CPU time without a very noticeable difference in the video output. Another issue with owncast is that it has choppy/unreliable response from the video player to the actual stream starting/stopping. My solution has the same problems. We're both using the same frontend video player, and I think it's a combination of limitations of that video player and inherent limitations of HLS/MPEG-DASH (the "download a playlist over and over again" model of HLS has some intrinsic issues when it comes to the generation of the playlist starting and stopping). I almost solved this in my own solution by 1) making it so that, in theory, there is always a video stream because the server "plays a video to itself" when there is no publisher, 2) a very lazy fix of having the frontend page auto-refresh periodically when playback fails to start. These are far from perfect and there is still some choppiness/buffering/repeated playback of a small segment when publishing starts and stops (and thus the management server starts/stops feeding the idle animation). I think the way to really fix these problems is to write a custom demuxer for ffmpeg that uses a small buffer of a "technical difficulties" still or whatever to feed into the processing chain when the stream publisher (whether internal or external) fails to deliver a packet for a certain time period, thus preventing generation of the HLS playlist ever halting for long enough for the video player to stall. I'm currently feeding an ffmpeg encoder with named pipes of uncompressed media streams and this is kind of an off-label use that ffmpeg handles but isn't entirely happy about, and particularly requires some hacking to get ffmpeg to never think the stream ended even when the container says so. A custom demuxer is is on my list of things to do but I'm not much of a C++ person so it's a little daunting for me. Perhaps one day I will publish my solution but it's extremely janky right now and has a lot of hard-coded config. I also think it's fairly easy to come up with on your own with some basic Linux knowledge and a willingness to spend an evening messing around with ffmpeg, pipes, different containers, and just seeing what it lets you get away with. Hint: getting ffmpeg to completely ignore the DTS timestamps on the incoming container was surprisingly confusing, know that the -re and -r flags have special meanings when used on the "input side" of the command. Finally, if you're especially latency/synchronization sensitive (e.g. multiple are watching and you want them to be strictly in sync), HLS and MPEG-DASH both become a nightmare. This is frustrating enough that I originally decided to just provide RTMP and make people use a native client but ofc there's a large portion of people who don't want to expose their computer to anything that isn't a web browser, so instead I spent a lot of time trying to tune the HLS production to both be stable and low latency, and, well, HLS just doesn't do that well. The HLS settings that I got to provide a really stable stream lead to up to 60s, occasionally greater out-of-sync.

Owncast Instances

71 points by URfejk 6y ago

ekianjo 6y ago

Sharing video content is not an issue per se anymore. The cost of bandwith is when you become even remotely popular.

simplecto 6y ago
That is a good problem to have. I admit this is a chasm where cash goes to die. The interesting part is where content creators, personalities, etc own their own rails. They don't need a massive audience to run their own show. Even if I only push 10-20 TB / month that is enough to make a lifestyle "+" business. That is my hypothesis, and 2021 looks like a good time to test it. (Edit - I can't grammar, apparently)
- throwawaysea 6y ago
  How can creators monetize their shows without Google’s ad ecosystem?
  - import 6y ago
    Check how twitch works.
  - rapsey 6y ago
    Merch, membership and membership only events/videos, tipping, etc.
    - ianbooker 6y ago
      I was inclined to say that you need the right niche with the right culture. See game streaming with it small but frequent donations. But with enough momentum your apparently can create such a culture in quite some topic areas, like classical trained violin playing: https://www.youtube.com/user/twosetviolin https://www.youtube.com/user/twosetviolin. Interesting!
      - rapsey 6y ago
        A seminal essay on this topic https://kk.org/thetechnium/1000-true-fans/ https://kk.org/thetechnium/1000-true-fans/
  - iso1210 6y ago
    Looking at https://influencermarketinghub.com/youtube-money-calculator/ https://influencermarketinghub.com/youtube-money-calculator/ suggests you get peanuts for google adverts - suggests 1 cent per view at most.
    - madeofpalk 6y ago
      that seems to be inline with what I expected.
  - simplecto 6y ago
    Lots of ways: direct ad sales and "reads" (old school way of doing it) run pre and mid-roll in the content (again, already done) paid live-streams with ticket sales. Paul Richards from Stream Geeks wrote a book on this. Merch Paid newsletters / content which is marketed in the show. Everything exists -- lots of value in helping creators stitch it all together. I see a similar opportunity how web devs helped grow the e-commerce for small companies, we will see the same growth helping creators stand on their own.
import 6y ago
That's true. If you don't have a solid monetization plan things become harder very quickly.
luplex 6y ago
A peer-to-peer-relay approach helps with this! Peertube is apparently getting support for live streaming, or already has it. I can't tell. https://joinpeertube.org/en/roadmap https://joinpeertube.org/en/roadmap
- corobo 6y ago
  How bad's the delay on live p2p? I'd be surprised to hear it getting below 10s and picture it more at 30 This is not a dig at Peertube, they're doing truly great work. My use case is probably different
  - ekianjo 6y ago
    Apparently Peertube claims between 10 and 30 seconds but I have not tested it.
- remram 6y ago
  You can run the 3.0 release candidate now, which has live streaming [1]. There are official Docker images available as well [2]. [1]: https://github.com/Chocobozzz/PeerTube/releases/tag/v3.0.0-rc.1 https://github.com/Chocobozzz/PeerTube/releases/tag/v3.0.0-r... [2]: https://github.com/Chocobozzz/PeerTube/blob/develop/support/doc/docker.md https://github.com/Chocobozzz/PeerTube/blob/develop/support/...

BerkhanBerkdemi 6y ago

I guess I'm using strict uBlock rules so streams don't load at all

ptspts 6y ago
This hypothesis is easy to test: disable uBlock temporarily for thaf site.

Sidhuharjot 6y ago

Can anyone help me to rank on Google My website is https://latestpunjabithoughts.blogspot.com/ https://latestpunjabithoughts.blogspot.com/ Help me

iod 6y ago

I have had good experiences with the free NGINX RTMP Module¹ for basically doing the same thing. I just have a cheap US and EU cloud instance. Stream OBS in multiple qualities to the US endpoint and have it auto pushed to the EU endpoint. Using this module, both endpoints use RTMPS and generate HLS and DASH. Then added a little HLS.js² player and can easily serve a small private viewing party, at multiple stream qualities with auto quality/bandwidth adjustment. ¹ https://github.com/arut/nginx-rtmp-module https://github.com/arut/nginx-rtmp-module ² https://hls-js.netlify.app/demo https://hls-js.netlify.app/demo

famoreira 6y ago
This sounds interesting. Do you have pointers to any resources/tutorial to setup something similar to what you have?
- iod 6y ago
  Being already familiar with NGINX, I found the examples in the docs¹/docs-wiki³ relatively sufficient. If you care about adaptive HLS streaming, make sure to add "hls_variant" directives for each quality level such as: hls_variant _1080p BANDWIDTH=10485760,RESOLUTION=1920x1080; on the OBS/source side you want to match stream names like: rtmp(s)://your-nginx-server/your-publish-endpoint/your-stream_1080p If you care about RTMPS (with TLS), you will want to look at NGINX Stream Core module⁴, with a server "listen" directive with the "ssl" option and a "proxy_pass" to the RTMP endpoint. For sending RTMPS from RTMP you will need another server "listen" with no "ssl" option and "proxy_ssl on", since the module has no native RTMPS capabilities, in order to get RTMPS as both server and sending client. For RTMP auto-publishing to multiple servers, you will want the "push" directive, and don't forget to give it a "name=" option, or it will grump. I struggled to get the "pull" directives to always work consistently and quickly. If you want lower latency, make sure your source stream has small keyframe periods and that they match "buflen" directive; I opt for 2 seconds. But if using HLS, there isn't that much more you can do on that front. ³ https://github.com/arut/nginx-rtmp-module/wiki/Directives https://github.com/arut/nginx-rtmp-module/wiki/Directives ⁴ http://nginx.org/en/docs/stream/ngx_stream_core_module.html http://nginx.org/en/docs/stream/ngx_stream_core_module.html

dontbesquare 6y ago

This looks great! I've been playing around with NGINX RTMP for video streaming a bit but this seems much more manageable. Looking forward to giving it a whirl!

throwaway399401 6y ago

I've been toying with the idea of offering dedicated, managed Owncast hosting but had not considered HNers as a potentially interested community. The comments on this submission have convinced me otherwise! If you would be interested, please drop me a way to get in touch with you: https://forms.gle/2KiR87rRdC4PSoCd6 https://forms.gle/2KiR87rRdC4PSoCd6 (throwaway because I have currently have a day job that is emphatically not keen about side projects)

corobo 6y ago
I can't help but read this as "I've noticed I could make money off other peoples work"
yokem55 6y ago
The issue here is if you are handling the hosting of these sites, you are the one to get and handle the DMCA mail when (and it's an inevitable when) your customers do something that runs afoul of the contemporary copyright process. Might want to approach it instead as a consulting service that helps folks set it up on hosting that they are responsible for and have their names on.
- hedora 6y ago
  The DMCA provides some legal protections to content creators that aren’t available via self hosting. Legal consulting to set up the correct corporate shell structure would probably also be a popular value add.
  - throwaway399401 6y ago
    Can you elaborate on this? Do you mean that if I, as a streamer, set up my own entity (LLC or whatever), I would have more leeway in responding to DMCA complaints, even if I ran my stream on something like EC2 or a typical "dedicated server" or colo?
    - hedora 6y ago

hedora 6y ago

I was wondering how they scale the service up (this is the first one of these I’ve seen that’s survived a HN hug of death). The lazy way seems to be to configure owncast to use an S3 compatible service. Some even support CDNs and provide unlimited egress bandwidth: https://owncast.online/docs/s3/ https://owncast.online/docs/s3/

jcrawfordor 6y ago

I have been running for some time a small single-stream video streaming server. When I saw Owncast mentioned here my immediate thought was to switch over to it, because it has features beyond my homegrown solution (based on nginx-rtmp and a Python/Flask application which performs "management" functions such as authentication of the publisher and injecting an "idle" animation when there is no publisher). For reasons largely of laziness I run this on a cheap VPS instead of on the larger machine I have colo'd. Unfortunately I immediately ran into huge performance issues with owncast compared to my solution, with input bitrates stuck at 200-300kbps. I haven't looked into it exhaustively but I think the main problem is that owncast seems to encode the video n+1 times where n is the number of desired quality levels (extra encoding pass on the published stream to smooth out publishing problems), while my solution sends out the original published stream as the high-quality variant and so encodes n-1 times with a couple additional steps of putting the same streams into new containers. Of course I have also set ffmpeg/libx264 to very high performance options, and I think owncast is less conservative here. Really just an FYI for anyone else looking at making a switch or doing something similar. Video encoding is CPU intensive so if you want to run it on a small/inexpensive VPS, it's helpful to 1) architect to absolutely minimize the number of encoding passes required (even when new containers are needed), 2) provide fine-tuning of the encoder settings, since just the change from "fast" to "veryfast" with libx264 makes a pretty big difference on CPU time without a very noticeable difference in the video output. Another issue with owncast is that it has choppy/unreliable response from the video player to the actual stream starting/stopping. My solution has the same problems. We're both using the same frontend video player, and I think it's a combination of limitations of that video player and inherent limitations of HLS/MPEG-DASH (the "download a playlist over and over again" model of HLS has some intrinsic issues when it comes to the generation of the playlist starting and stopping). I almost solved this in my own solution by 1) making it so that, in theory, there is always a video stream because the server "plays a video to itself" when there is no publisher, 2) a very lazy fix of having the frontend page auto-refresh periodically when playback fails to start. These are far from perfect and there is still some choppiness/buffering/repeated playback of a small segment when publishing starts and stops (and thus the management server starts/stops feeding the idle animation). I think the way to really fix these problems is to write a custom demuxer for ffmpeg that uses a small buffer of a "technical difficulties" still or whatever to feed into the processing chain when the stream publisher (whether internal or external) fails to deliver a packet for a certain time period, thus preventing generation of the HLS playlist ever halting for long enough for the video player to stall. I'm currently feeding an ffmpeg encoder with named pipes of uncompressed media streams and this is kind of an off-label use that ffmpeg handles but isn't entirely happy about, and particularly requires some hacking to get ffmpeg to never think the stream ended even when the container says so. A custom demuxer is is on my list of things to do but I'm not much of a C++ person so it's a little daunting for me. Perhaps one day I will publish my solution but it's extremely janky right now and has a lot of hard-coded config. I also think it's fairly easy to come up with on your own with some basic Linux knowledge and a willingness to spend an evening messing around with ffmpeg, pipes, different containers, and just seeing what it lets you get away with. Hint: getting ffmpeg to completely ignore the DTS timestamps on the incoming container was surprisingly confusing, know that the -re and -r flags have special meanings when used on the "input side" of the command. Finally, if you're especially latency/synchronization sensitive (e.g. multiple are watching and you want them to be strictly in sync), HLS and MPEG-DASH both become a nightmare. This is frustrating enough that I originally decided to just provide RTMP and make people use a native client but ofc there's a large portion of people who don't want to expose their computer to anything that isn't a web browser, so instead I spent a lot of time trying to tune the HLS production to both be stable and low latency, and, well, HLS just doesn't do that well. The HLS settings that I got to provide a really stable stream lead to up to 60s, occasionally greater out-of-sync.