Live data from Hacker News

Show HN: Overpass – a self-hosted video live streaming app

github.com

21–30 of 35 posts

Re: Show HN: Overpass – a self-hosted video live streaming app

#21
post #18

Earlier quoted context omitted.

Why can't your friend use Discord streaming? Don't think there's copyright takedowns,

The quality isn't good enough. We also wanted an archive of every stream we've done.

Curious if you considered Mux: https://mux.com/live or IVS: https://aws.amazon.com/ivs/ for your project? If so what made them not compelling options?

Re: Show HN: Overpass – a self-hosted video live streaming app

#22

I need this at work, but with very low latency. Teams does low latency well enough, but the frame rate is ~3-5 FPS which is abysmal when you're trying to follow someone's mouse cursor to see what they're actually doing. anyone know of anything?

MS acquired Peer5 for Teams recently so I imagine improvement on the horizon.

I built an nginx-rtmp oss project a few years ago and it worked well—simulcasted out to Twitch and YouTube and saw comparable latency (YouTube: 3 2 1 ispooge live is faster). I used a dedicated encoder box, recorded and proxied via my raspi3 and served from home fiber behind CloudFlare CDN with caching to prevent much origin traffic, 2sec HLS chunks were like 1-2Mb at 720p30.

Re: Show HN: Overpass – a self-hosted video live streaming app

#23
post #13
post #11

Earlier quoted context omitted.

Very interesting! Can you tell me about that Cloudflare Workers setup? Would you have some sort of worker process the ingress video? Very new to the concept of serverless computing, so I would love to learn more.

The workers would handle both ingress and egress. The ingress feed should already be encoded for distribution by whatever system is pushing it. The durable objects in the middle would hold a moderate buffer of content which would be referred to on the egress routes. Archival would be a separate system that listens to all egress sessions at the same time. A 3rd websocket CF worker route could be used to exclusively ma…

> the jpeg frames with appropriate timing via a 2-3 frame buffer

Oh people have tried this many times. Don’t bother. Both x264 and NVENC can encode with no buffering (1 frame at a time) and get the same latency benefits without killing quality and bandwidth. JPEGs just look terrible unless they’re lossless.

That aside, you brought up the real issue with open source DASH client implementations: They have terrible buffering algorithms that keep several seconds of video in memory instead of 2-3 frames even though the user might have a decent connection. Oh and by default they use the HTTP Date header for time synchronization between client/server so you only get 1 second resolution lol

Part of the issue is that the majority of nontechnical users are on a shitty connection (WiFi or mobile data). They’ll always have to buffer >1 second (>60 frames) due to packet loss so they won’t see any benefits from a better implementation.

Re: Show HN: Overpass – a self-hosted video live streaming app

#24

I need this at work, but with very low latency. Teams does low latency well enough, but the frame rate is ~3-5 FPS which is abysmal when you're trying to follow someone's mouse cursor to see what they're actually doing. anyone know of anything?

YC company: https://www.daily.co/

Re: Show HN: Overpass – a self-hosted video live streaming app

#25

I need this at work, but with very low latency. Teams does low latency well enough, but the frame rate is ~3-5 FPS which is abysmal when you're trying to follow someone's mouse cursor to see what they're actually doing. anyone know of anything?

YC company: https://www.daily.co/

oh, uh, I forgot to mention: I need it to be self-hosted entirely.

otherwise this looks very promising.

thank you.

ah, screego is probably what I'm after.

Re: Show HN: Overpass – a self-hosted video live streaming app

#26
post #21
post #18

Earlier quoted context omitted.

The quality isn't good enough. We also wanted an archive of every stream we've done.

Curious if you considered Mux: https://mux.com/live or IVS: https://aws.amazon.com/ivs/ for your project? If so what made them not compelling options?

I think the main reason was that I already have a dedicated server, so it made sense to use the already existing infrastructure for cost saving purposes.

I've also looked at Cloudflare and BunnyCDN's options. Could be worth thinking about if I ever move away from owning my current server.

Re: Show HN: Overpass – a self-hosted video live streaming app

#27
post #3

This is pretty well done! Coincidentally, I've been working on a very similar project for a friend of mine, for the exact same reasons. Self-hosted live streaming is definitely the way to go (~8% costs versus ~50% Twitch fees), so it's great to see more independent and open source solutions popping up! I do think it's important to note, however, that self-hosting doesn't legally absolve the streamer from PRO fees for…

I wonder how do you calculate 8% costs. Also is it possible to include in the calculation the "discovery" service that twitch provides?

Re: Show HN: Overpass – a self-hosted video live streaming app

#28
post #3

This is pretty well done! Coincidentally, I've been working on a very similar project for a friend of mine, for the exact same reasons. Self-hosted live streaming is definitely the way to go (~8% costs versus ~50% Twitch fees), so it's great to see more independent and open source solutions popping up! I do think it's important to note, however, that self-hosting doesn't legally absolve the streamer from PRO fees for…

Twitch has 0 costs, and provide you with avenues to earn revenue (ads, bits, subs).

Your self-hosted platform has some costs, and doesn't have any way to directly monetize via ads or similar.

Re: Show HN: Overpass – a self-hosted video live streaming app

#29
post #8

Earlier quoted context omitted.

Most important thing for me is the latency of the streaming solution. Discord seem to do really well here, with <1 second latency times. You done any measurements with your solution to suggest how much latency there is between the server and the client?

If you're connecting to the RTMP server directly, you can get about 1-2s latency. However, due to the additional overhead of the conversion process to HLS, I'm getting about 6-10 seconds of latency. I have considered looking into WebRTC, but it seems a bit more complicated to work with than just running an RTMP server and calling it a day. Both Apple and Twitch have their own implementation of low latency HLS, so it…

Lowering hls_fragment[1] to 1s should help out a little with the latency. This is what I've done in the past with a similar project as yours, Open Streaming Platform[2], with good results.

Since you mentioned WebRTC for streaming to provide even lower latency, this is what I believe Project Lightspeed has achieved[3]. Might be something you'd be interested in, if you hadn't already seen it.

[1] https://wiki.openstreamingplatform.com/Usage/Streaming#osp-n...

[2] https://wiki.openstreamingplatform.com/Usage/Streaming#osp-n...

[3] https://github.com/GRVYDEV/Project-Lightspeed

Re: Show HN: Overpass – a self-hosted video live streaming app

#30
post #8

Earlier quoted context omitted.

If you're connecting to the RTMP server directly, you can get about 1-2s latency. However, due to the additional overhead of the conversion process to HLS, I'm getting about 6-10 seconds of latency. I have considered looking into WebRTC, but it seems a bit more complicated to work with than just running an RTMP server and calling it a day. Both Apple and Twitch have their own implementation of low latency HLS, so it…

Lowering hls_fragment[1] to 1s should help out a little with the latency. This is what I've done in the past with a similar project as yours, Open Streaming Platform[2], with good results. Since you mentioned WebRTC for streaming to provide even lower latency, this is what I believe Project Lightspeed has achieved[3]. Might be something you'd be interested in, if you hadn't already seen it. [1] https://wiki.openstrea…

I've experimented a bit with lowering the hls_fragment value and the playlist length, and found that fragments smaller than 2 seconds caused too much buffering on the end client for it to be stable - which resulted in higher latency than before.

I'm looking into the latency issues and I've started drafting up possible solutions. Low latency MPEG-DASH might be something to experiment with. It won't reach sub-second latency, but it will definitely be better than HLS.

Post reply on HN