Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform

github.com

Post reply on HN
Print view View original

71–80 of 101 posts

Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform

#71

Post by Wouter33 »

echelon wrote: post #66

I have some questions for people in this field. Is there a good way to broadcast to Twitch, YouTube, and Reddit simultaneously? Is it a bad idea to target multiple communities? How expensive is it to run your own single-tenant stream on your own website? Is that a bad idea? Are users revolting on Twitch against the ads and RIAA take downs? Or is it unlikely to ever be unseated?

Lot's of people are using restream.io. Good solution to stream to multiple places at the same time.

Doing you own single-tenant stream is hard to manage and scale in general.

Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform

#74

Post by captn3m0 »

nowahe wrote: post #48
spenczar5 wrote: post #27

Cool! Some thoughts from a former Twitch engineer: - Probably the hardest part of running these things is managing outbound bandwidth costs. You'll need to either limit inbound bitrate or transcode video down to a manageable rate, or else you'll quickly spend a lot of money on shipping 4k video for people. - Right now, your nginx hosts both do ingest and playback, if I understand it right. You might want to separate…

Having worked with AWS IVS, which is using the same infrastructure design as Twitch (or the other way around), it only accepts RTMP (well RTMPS to be fair) as an input. To me it would seem that the industry is going the opposite way, and doubling down on RTMP. An RTMP connector is planned on the Chime SDK as well (a framework & infrastructure based on Chime to create your own custom meetings), to be able to stream th…

>to use this[0] docker container

In a similar vein, Jitsi's video recording solution is pretty much the same thing[0].

>It works by launching a Chrome instance rendered in a virtual framebuffer and capturing and encoding the output with ffmpeg. It is intended to be run on a separate machine (or a VM), with no other applications using the display or audio devices. Only one recording at a time is supported on a single jibri.

We are severely lacking stand-alone webRTC implementations - the best implementation is in the Chrome codebase.

[0]: https://github.com/jitsi/jibri

Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform

#75

Post by TrevizeGP »

Slightly connected: Does anyone found a good way to distribute HLS segments to multiple servers in almost real time? Let's say you have a setup with Nginx managing input RTMP and producing HLS segments in a local directory and you want those distributed to different "edge" servers. I can think of using inotify + rsync or pushing into an object store and let in handle replication (not sure if it would be fast enough?).

For various reasons (and for now) I would like to skip pushing them into S3 and use Cloudflare/Cloudfront.

Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform

#76

Post by gizah »

toomuchtodo wrote: post #31
spenczar5 wrote: post #27

Cool! Some thoughts from a former Twitch engineer: - Probably the hardest part of running these things is managing outbound bandwidth costs. You'll need to either limit inbound bitrate or transcode video down to a manageable rate, or else you'll quickly spend a lot of money on shipping 4k video for people. - Right now, your nginx hosts both do ingest and playback, if I understand it right. You might want to separate…

> Please don't keep using RTMP. ... You might consider accepting an alternative modern protocol. What would you recommend as an alternative modern protocol to RTMP for shipping video between a broadcast endpoint and transcoding/distribution infra?

(disclaimer: I'm participating in the libRIST development) RIST! It's a well thought out protocol without technical debt (which SRT has), supports multicast (if you need it), null packet deletion, encryption via PSK or DTLS and multiplexing (multiplexing support in libRIST is not fully there yet, it's on the roadmap together with DTLS). Next iteration of the RIST protocol will support "backpressure" on your encoder, so if you have too much packet loss your encoding can scale it's video bitrate down, while together with null packet deletion you'll be able to keep your bitrate perfectly CBR.

Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform

#77

Post by jawngee »

ddorian43 wrote: post #68
ta123523567 wrote: post #45

Earlier quoted context omitted.

Facebook live ( https://engineering.fb.com/2015/12/03/ios/under-the-hood-bro... ) and several others use nginx-rtmp. It's fairly common in china as well from what I've seen. RTMP is still the best protocol for publishing live streams IMO, and in my experience http-flv blows HLS out of the water for < 1 sec latency. The protocol is old but at least you aren't 15 seconds behind the action.

nginx-rtmp hasn't seen a commit in 3 years, kinda unmaintained.

There are well maintained forks.

Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform

#78

Post by chaz6 »

sneak wrote: post #57
spenczar5 wrote: post #27

Cool! Some thoughts from a former Twitch engineer: - Probably the hardest part of running these things is managing outbound bandwidth costs. You'll need to either limit inbound bitrate or transcode video down to a manageable rate, or else you'll quickly spend a lot of money on shipping 4k video for people. - Right now, your nginx hosts both do ingest and playback, if I understand it right. You might want to separate…

> Probably the hardest part of running these things is managing outbound bandwidth costs. This might be a good time to mention that Hetzner (where I host) has a lot of unmetered gigabit options. I'm not affiliated, just a happy (long term) customer. Sadly Germany has some laws that censor certain types of harmless content, so that's one downside, but that's not Hetzner's fault, just something to consider depending on…

I can attest to Hetzner. I pay €35 per month for a dedicated server, and one of the things I run is a (non-exit) Tor relay, which consumes 3.5TiB per day on average.

Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform

#79

Post by bronco21016 »

ddorian43 wrote: post #68
ta123523567 wrote: post #45

Earlier quoted context omitted.

Facebook live ( https://engineering.fb.com/2015/12/03/ios/under-the-hood-bro... ) and several others use nginx-rtmp. It's fairly common in china as well from what I've seen. RTMP is still the best protocol for publishing live streams IMO, and in my experience http-flv blows HLS out of the water for < 1 sec latency. The protocol is old but at least you aren't 15 seconds behind the action.

nginx-rtmp hasn't seen a commit in 3 years, kinda unmaintained.

I admit I do the same thing when looking at projects. When was the last commit? Is that the best measure though? For something like this maybe there doesn’t need to be any more activity?

Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform

#80

Post by spenczar5 »

ta123523567 wrote: post #45
spenczar5 wrote: post #28

Earlier quoted context omitted.

[0] RTMP is common; `nginx-rtmp` is not common in industry to my knowledge. RTMP ingest is a pretty different task from HTTP reverse proxying. Wowza used to be the common software that was used. Twitch moved off of Wowza and wrote their own ingest stack when I worked there.

Facebook live ( https://engineering.fb.com/2015/12/03/ios/under-the-hood-bro... ) and several others use nginx-rtmp. It's fairly common in china as well from what I've seen. RTMP is still the best protocol for publishing live streams IMO, and in my experience http-flv blows HLS out of the water for < 1 sec latency. The protocol is old but at least you aren't 15 seconds behind the action.

FB live says there that they use a modified version of nginx-rtmp for delivery. I don’t know about ingest.

I still think RTMP is a tough choice for delivery. I winder if they are still doing that, 5 years later? I would be surprised, but maybe.

There are lots of ways to make HLS run at much less than 15 seconds. With some clever tricks, a cooperative player, and good network conditions, it can be under 0.5s. Hitting 2-4s latency is relatively straightforward. The strategies here are sometimes bundled under the term “LHLS,” and Apple’s LLHLS incorporates some (not all, grrr) of them.

Post reply on HN