Live data from Hacker News

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

github.com

41–50 of 101 posts

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

#41
post #35

Earlier quoted context omitted.

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?

No they don't work, I think they literally change the video content on you.

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

#43
post #34

Earlier quoted context omitted.

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 emotio…

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

TikTok is different because you can work on maintaining an audience on something like Instagram and also at the same time try to build an audience on TikTok, even if their social networks are different.

If you are in a contract with Twitch, you cannot stream anywhere else. You are either staying on Twitch and your uses are staying where they are used to the community, or you go to another platform with a different community, different chat and chat emotes, different subscription system, etc.

What I often see cited from people not wanting to leave Twitch is the Twitch emotes and the way chat works on Twitch.

For example, Facebook isn't anonymous so chat tends to be more serious and less meme-y.

Youtube has a far superior player with live rewind, takes less computer resources, and has access to far more viewers than Twitch; but it has an inferior chat with no Twitch emotes. So Twitch viewers are reluctant to make the switch full-time.

That said, YouTube has the best chance to take out Twitch. Google just needs to make a better chat and improve discoverability. Twitch streamers that switch to YouTube, either by choice or by force, can still make a living there.

To add: I know of one streamer that streams on Facebook for their income and streams on Twitch to maintain their old community there and to hopefully take more viewers to Facebook. But they are not gaining income from Twitch because they are not under contract. And that is a grind. It's not something for the average person.

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

#44

Earlier quoted context omitted.

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…

I have been working on https://webrtcforthecurious.com/ to solve that. It approaches WebRTC from the protocol. I also try to give credit/real history at the end!

I played around with https://github.com/Sean-Der/webrtc-uri but I don't have any experience/friends in the IETF/W3C so it is never going to happen. I agree it would be really amazing. It would be great if a company that had influence picked it up!

Yea I work on Pion! Thanks for using it :) I get a real sense of purpose trying to make WebRTC more accessible/easier to use. I love seeing what people build. Also really feel in love with teaching because of it. It sure has taken up a lot of my time, but 100% worth it.

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

#45
post #3

This is really great. I've seen so many of these "self-hosted live video streaming" sites show up here and this is the first one that show the actual backend code. Usually they're just web frontends to some video streaming website. Questions: -[0] How widely deployed is this stack (specifically nginx rtmp/vod) around the live-streaming industry? -[1] You listed under the Feature that it support "Pay-per-view" and "Pa…

[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.

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

#46
post #36

Earlier quoted context omitted.

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.

https://framacolibri.org/t/fonctionnalite-live-retour-dutili...

Its in French but you can understand the screenshots.

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

#47

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…

I work at Mux, though I don't have any special sauce on this. Instead, as a small broadcaster (Twitch and the occasional event--I ran Demuxed this year from my home office!), SRT is a godsend. I throw video around my studio all the time, because NDI has weird frame timing issues and sucks up a lot of bandwidth, and I don't always need real-time video. I would absolutely love it as a predictable, latency-configurable (within some parameters, of course) ingest method for streaming.

I would love more

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

#48

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 the meeting directly to ingest service (like IVS/Elemental). On the AWS side at least, there doesn't seem to be a plan to migrate from RTMP, as it seems that services are being launched that only supports it.

On a sidenote, the official AWS recommended way to stream a Chime SDK meeting to IVS, is to use this[0] docker container, acting as a bridge between WebRTC & RTMP. I find the hackiness of it amazing, as it's mostly just an X11 framebuffer, an instance of Firefox loading the webview for the meeting, and ffmpeg capturing the framebuffer and sending it as an RTMP stream to the configured endpoint.

Also, AWS IVS as a streaming platform is really impressive. It's a fully managed service, and out of the box you get around 4-5s of latency between the source and the player, with an upper limit of 1080p60 @8.5Mbps. It will also downsample the stream to 720p, 480p, 360p & 160p.

[0]: https://github.com/aws-samples/amazon-chime-meeting-broadcas...

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

#50

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?

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

> RTMP is very old as a protocol.

Would you consider that this is, by itself, a reason not to use it?

Post reply on HN