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

31–40 of 101 posts

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

#31

Post by toomuchtodo »

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?

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

#32

Post by grogenaut »

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?

Spenczar might know better but SRT seems very interesting for modern protocols. RTMP is very old as a protocol.

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

#33

Post by spenczar5 »

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?

Well, to be fair, there isn't a clear winner.

Maybe SRT, but it doesn't have much platform support itself, and its spec is pretty strange. I get weird Adobe flashbacks about it, since it seems so heavily pushed by Haivision, and it's really made for a different use case - it's made for big broadcasters like ESPN and TV networks, not for web startups.

The current motion seems to be towards hacking WebRTC to accommodate broadcast ingest. But WebRTC is really huge and complicated and you only want a tiny sliver of it for this use case. Pretty much all implementations are buggy because its such a gigantic kitchen-sink design.

There's also RIST (for those who love working groups) and Zixi (for those who love closed source protocols?).

I honestly think that something like HLS could do pretty well (broadcaster slices video into 1-second TS segments and just ships em with HTTP POST), but it's not something I ever saw anyone do. Definitely doesn't meet the TV networks' needs, but its really easy to scale and straightforward to secure, which is maybe more important.

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

#34

Post by holler »

lovehashbrowns wrote: post #24
eli_front wrote: post #16

How secure do you think Twitch (Amazon), Facebook Gaming (Facebook), and Youtube Live (Google) are at the top of the streaming world? We’ve recently seen Mixer (Microsoft) fall, and it feels like the creators are the only thing keeping these platforms great, so what’s stopping a new streaming platform from rising above all the others other than the creator’s fear of losing stability? Why couldn’t a new streaming serv…

There are so many things. First, the network effect. Going from an established platform to a new one means you lose a lot of viewers that aren't going to switch and the potential to gain new ones since the other platform is new. Secondly, well-established payment methods such as Twitch Prime which provide a lot of revenue for streamers on Twitch. Third, existing contracts with Twitch. Fourth, streaming platforms are…

> Fourth, streaming platforms are incredibly expensive to create, maintain, and promote. They will not be profitable for a long, long time, on top of requiring mountains of cash to start.

I agree with that and unless you have founders who possess the required expertise + motivation, it will be expensive.

> And finally, users "get used" to a specific platform, e.g. Twitch chat, and it's difficult to break these emotional attachments.

Yes and no, I think if you build a quality product, people will try it, and if it works and is delightful, they'll come back. Look at TikTok.

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

#35

Post by keyle »

reificator wrote: post #11
keyle wrote: post #6

It's a chicken and egg problem where there is not much point in building your own whizbang streaming platform and have no one come to it. Twitch is getting increasingly ad-nnoying and you can _ad_ barely _ad_ watch _ad_ it _ad_ an _ad_ ymore. That said that's still where you get the viewers and that's what people will pick. The ad-revenue sharing being the carrot here which will probably mean it's going to be success…

I run an adblocker but I'm sympathetic to Twitch's plight here. Or at least I was until they started interrupting streams in the middle of the action with no human input to show ads. When the broadcaster clicks the ad button, it's a good time to run ads. They're probably taking a break anyway, there's nothing critical or even interesting happening, so watching some ads is fine. But randomly interrupting in the middle…

mid stream randomly, you get thrown 30+ seconds of ads, great if you were having a conversation with the host.

then if the stream breaks, refresh, new set of ads.

pop the popout player, ads.

It's totally rooted. The suits run the show and they're milking the cow. The only reason they're going so hard at it, I speculate, is that they're being hit by big DMCA fees.

I can't otherwise explain with logic why they'd run ads literally on DJ streams with thousands of viewers.

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

#36

Post by m3adow »

2Gkashmiri wrote: post #22
InitEnabler wrote: post #15

Earlier quoted context omitted.

Yea, I'm looking forward to that feature. If they can implement that with a peer to peer stream that would be great.

P2p is already a thing and is working much better than expected. https://framacolibri.org/uploads/default/original/2X/9/9530f... Here is some peer watching a stream (in french) and look at the stats.

404s for me.

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

#37

Post by Sean-Der »

spenczar5 wrote: post #33
toomuchtodo wrote: post #31

Earlier quoted context omitted.

> 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?

Well, to be fair, there isn't a clear winner. Maybe SRT, but it doesn't have much platform support itself, and its spec is pretty strange. I get weird Adobe flashbacks about it, since it seems so heavily pushed by Haivision, and it's really made for a different use case - it's made for big broadcasters like ESPN and TV networks, not for web startups. The current motion seems to be towards hacking WebRTC to accommodat…

WebRTC really isn't that big. Google's implementation just is targeted at their needs. If you are doing it for ingest you just need

* Basic SDP library, ICE-Lite, DTLS, SRTP

If you ship RIST you pretty much end up with the same thing!

If you go with WebRTC you have implementations in lots of languages as well (not just bindings)

* Go, Python, Pure C/Embedded, Java, Rust, C++

Also WebRTC could let you do SVC or Simulcast. It would be a lot better for scaling if the uploader sent all the different quality feeds (and let congestion control ensure they don't oversend).

I really feel that there has been a concentrated marketing effort that has hurt WebRTC on multiple fronts.

* Google oversells what they have done. They bundled up a bunch of existing protocols. That doesn't get as my promotions/awards though. It also helps them control the standard. If they paint 'Google WebRTC === WebRTC' then they make a change and everyone else has to play ball.

* WebRTC competitors want to paint it in a bad light so they can sell $x

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

#38

Post by moneywoes »

keyle wrote: post #35
reificator wrote: post #11

Earlier quoted context omitted.

I run an adblocker but I'm sympathetic to Twitch's plight here. Or at least I was until they started interrupting streams in the middle of the action with no human input to show ads. When the broadcaster clicks the ad button, it's a good time to run ads. They're probably taking a break anyway, there's nothing critical or even interesting happening, so watching some ads is fine. But randomly interrupting in the middle…

mid stream randomly, you get thrown 30+ seconds of ads, great if you were having a conversation with the host. then if the stream breaks, refresh, new set of ads. pop the popout player, ads. It's totally rooted. The suits run the show and they're milking the cow. The only reason they're going so hard at it, I speculate, is that they're being hit by big DMCA fees. I can't otherwise explain with logic why they'd run ad…

Is there any adblockers that work for these?

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

#40

Post by spenczar5 »

Sean-Der wrote: post #37
spenczar5 wrote: post #33

Earlier quoted context omitted.

Well, to be fair, there isn't a clear winner. Maybe SRT, but it doesn't have much platform support itself, and its spec is pretty strange. I get weird Adobe flashbacks about it, since it seems so heavily pushed by Haivision, and it's really made for a different use case - it's made for big broadcasters like ESPN and TV networks, not for web startups. The current motion seems to be towards hacking WebRTC to accommodat…

WebRTC really isn't that big. Google's implementation just is targeted at their needs. If you are doing it for ingest you just need * Basic SDP library, ICE-Lite, DTLS, SRTP If you ship RIST you pretty much end up with the same thing! If you go with WebRTC you have implementations in lots of languages as well (not just bindings) * Go, Python, Pure C/Embedded, Java, Rust, C++ Also WebRTC could let you do SVC or Simulc…

I dunno, https://www.w3.org/TR/webrtc/ seems pretty huge to me. And then there are all the RFCs and notes you need to also read and understand, and then you realize that the real spec seems to be Google’s implementation... that at least was how things felt in 2018. They totally might have progressed since then.

Yes, you can pick from the WebRTC buffet and build a good ingest protocol, but you need a lot of knowledge to do that - I would guess a tiny tiny number of people who read your comment know what DTLS or even STUN are.

I also agree that there is a branding problem, but I think part of it is that we don’t have a good name for this WebRTC ingest pattern. It deserves a name and some attempt at standardization so tools and software can start building towards it without supporting everything in WebRTC.

Because yeah, I think its the least-bad thing we have right now.

I think you must be the same Sean-Der who works on the Go WebRTC library? Thanks a ton - that’s serious open source work.

Post reply on HN