Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform
91–100 of 101 posts
Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform
#92Earlier quoted context omitted.
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…
Is 4-5s latency considered good? It’s an awful experience for video chat.
In broadcast contribution, where you have someone in the studio talking to a person on the screen, anything over a second brings complaints. Typically aim for under 500ms of processing delay for low bitrate contributions, and at 25fps with a bog standard blackmagic card going SDI-IP-SDI, and add in timing, you're looking at 500ms of your budget eaten by the hardware framebuffer. OBE do a better capture card - one which allows access to the data on a line by line basis. If you go for something more hardware based and say a J2K codec you can get your latency down to a couple of frames.
I had a problem a few years ago with lives from Kiev -- the ISP we had kept dropping our packets for 125ms at a time. Didn't matter if we sent 20mbit (so 2000 packets per second) or 2mbit (200pps), the number lost in a row matched the 125ms outage.
Network people laugh when I complain about 125ms outages on the internet, but it meant that standard FEC wouldn't work (maximum of 20 burst packets, even if it recovered every lost packet that would mean errors above a transport stream rate fo 1.6mbit.
Now you can use RIST to dial in resends, but with a 100ms rtt you're looking at needing 300-500ms of buffer to cope with that type of outage (to realise the packets are missing and not just delayed (say 50ms), to ask for the retransmit (50ms), and to get them (50ms, then smear them over time as you can't do an instant retransmit)
Alternatively you can transmit twice and offset, but that still adds 150ms of delay.
Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform
#93Cool! 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?
It's really simple and you can see exactly what's happening on the network.
Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform
#94Earlier 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…
(SRT itself is a defunct file transfer protocol that's had some life brought back into it by Haivision)
Big broadcasters tend to go for "open standards" from groups like SMPTE and DPP. The "DPP001 - Live IP Profile" recommendation has a variety of different profiles depending on the importance of the media and the network that's involved, but it generally revolves around MPEGTS over RTP, with either dual streaming (sending the same packets down two different networks), or RIST (so a NACK based error correction), or perhaps both. Certainly when I broadcasted major international TV events recently, I've gone for both RIST and two networks.
The last thing you want is your signal to drop out for 10 seconds due to a power failure while your network reroutes just as the final touchdown at the superbowl happens - or worse in the the commercials.
Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform
#95Earlier 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.
But not because it's old. IP is old. UDP is old. RTP is old.
Using TCP for live streaming isn't a good thing, same as using TCP for a VPN isn't good.
SRT isn't great, it grew from a file transfer program (UDT). UDP file transfers like UDP and Signiant were popular 15 years ago when TCP window scaling and buffers were more miss than hit. Companies like signiant and filecatalyst were very big on them, and UDT was an attempt to standardise it.
RIST is technically a far nicer protocol than SRT, but suffered massively from the talking-shop development. It came out two years late, and even then didn't have the proper libraries to just drop into your prosumer camera like SRT did.
N.B. It's a shame as their file transfer management systems were good (control, monitoring, security, scheduling etc), but they were going full pelt on the "TCP is slow, UDP is fast" line - to the point that they deliberatly took standard linux distributions like ubuntu and redhat, and changed the default settings to disable tcp window scaling, so show a "side by side" comparison on their sales booths at events.
Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform
#96Cool! 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…
In the world cup in 2018 I was watching an RTP feed direct from the IBC in Moscow on my desktop in VLC. The goal went in, and strangely I recognised it was a goal for England (I don't really do football). Window was open, and I cheered.
A few seconds later the neighbours cheered - they were watching it on TV.
I remember watching a 4K FA Cup final too in parallel to an off air TV feed. Watched the goal go in on the TV. By the time it had gone in on the 4K feed I'd actually forgotten it was a goal, so I guess that wasn't too bad.
That's a problem with streaming. If you're watching a popular live event like a big football match, and your neighbours are too, you need to be receiving it at the same time to avoid "spoilers".
Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform
#97I 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?
This is a function based on the number of viewers. The ingest and transcoding/transmuxing can be thought of as a fixed cost (and in many cases is free) and those operational expenses become rounding errors once the number of viewers surpasses a certain size. The real cost is egress (bandwidth leaving edge servers) and to a much lesser extent mid-gress (the cost of moving bytes between servers, e.g. from an origin to regional distribution server).
> Is that a bad idea?
Almost certainly a bad idea from a financial perspective. You have a bad bargain here. Either you have so few viewers that the bandwidth is manageable (i.e. no revenue) or so many viewers that there is literally no way for you to afford the bandwidth. If there is a goldilocks zone in the middle it is probably a tiny sliver. You have to have the perfect number of viewers and revenue with very little margin for error.
I remember one popular Twitch streamer (sodapoppin) was doing a QA with viewers where he addressed the question. He had hired some people to figure out the costs of setting up his own streaming server and it didn't work out financially for him. Other streamers have investigated it as well (Destiny?) and came to the same conclusion. If those top streamers can't make it work financially, I doubt anyone can to be honest.
Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform
#98Earlier 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…
That's been a feature since the Justin.tv days. Some broadcasters choose to automatically run an ad every 30 minutes, for example. Twitch's broadcaster UI supports this, and has for a very very long time.
If you stream speedrun attempts, a block of ads every 30 minutes probably isn't going to cause viewers to miss anything of significance, so it's probably safe to flip that switch. Of course, when the ads show up at the wrong time in that case, it's probably very upsetting.
But if you stream a show with banter between hosts, and you already manually run ads every hour while preparing for the next segment of the show, and you still get interrupted in the middle of the dialogue by an ad? That's horrible.
If you stream a competitive game (DotA, LoL, Overwatch, Warzone, etc), and your amazing comeback from behind gets interrupted by an ad, you're going to lose both short term and long term revenue.
Long term because viewers will get frustrated and leave. Short term because viewers seeing a great play are more likely to donate and gift subscriptions to celebrate the moment. But if they don't actually see it, you can't get that hype train started, and you lose out and so does Twitch.
Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform
#99Earlier 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?
(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,…
Re: Show HN: Boltstream – Self-hosted full end-to-end live video streaming platform
#100Earlier quoted context omitted.
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…
Is this representative of the state of SRT? https://tools.ietf.org/html/draft-sharabayko-mops-srt-01