What makes this approach lower latency than, say, a centralized TURN server in one of those clouds?
At the moment, everyone in the industry is working to figure out how to provide a viewer experience that is similar, or better than the current expectations of live streaming.
Live streaming is hard. Ultra-low-latency is just as hard.
However, I'm still not sure why we need ultra-low-latency. Will it improve the live experience? Maybe. Aside from live-action sports or significant events, do we as content consumers really need ultra-low-latency?
Twitch chat is fun.
Simply for passive viewing probably not. For live streaming in which the viewer is also using actuators, e.g., gamepads, wheel, etc., for controlling the stream capture device, then yes.
1. http://www.wired.co.uk/article/england-vs-croatia-live-strea...
I subscribe to both Formula 1 and MotoGP online streaming services and couldn't care less if the broadcasts were even multiple minutes delayed. They may very well be already and I wouldn't know. As far as I can tell they both just use standard CDNs delivering DASH or similar (basically just short video files played in sequence).
That seems more than enough for sports. Multiple minutes may result in getting real time information from elsewhere (e.g., Twitter, local radio) but anywhere from 10 to 30 seconds seems fine.
We call it the "Twitter effect". Essentially people either see things on social media or app notifications before it happens. Kinda ruins it for some people.
We are working on sub-30 second latency in 4K w/ server side ad insertion, but it's hard work. Especially with encoding with DRM baked in.
For the FA Cup final I had two feeds, one the 4K BBC version, and one on SDI from Wembley. The goal went in, and I'd completely forgotten it by the time the 4K goal went in.
The trouble is, things like twitter, whatsapp etc, will work to the lowest latency, and for a football game that's about 50-600 nanoseconds to the earliest viewer. Twitter can push the message within a few seconds (or the VAR result or whatever)
Latency needs to be in the sub-10 second goal-glass range.
If you delay all your friends by 30s +-2s then that would probably be fine...
That changes the problem somewhat.
If you're not watching with someone else, it doesn't make that much difference; but 30 seconds is plenty for someone to cheer for a goal and the notification to distract you from seeing it.
So given that what you are competing against (cable TV) already has a significant delay I doubt a normal web stream can't reach the same or better latency with just standard HTTP download of video files.
In Santiago, during national soccer matches everyone would watch, goals would reach us through the sound of neighbors rejoicing sooner than they would from actual television coverage because the satellite dish had a latency of say 3 seconds over cable.
And if the problem was actually that serious it would be easier to fix it by just adding additional delay to the faster technologies instead of having to reduce latency in internet streaming at huge cost.
Results in sports can switch from one side to the other end within split second, so whoever has the lowest latency will gain massive advantages. It's very similar to stock trading.
It’s the entire reason that I won’t cut the cord.
For 1->n streaming you just want very high quality broadcast->server and then presumably you want the downstream clients to not have the option to send packets back to the broadcaster. Transcoding is hard though, so consumers might be stuck with just the source video quality. I assume this lib just passes the frames on from the source (twitch did just that through almost all of its pre-acquisition growth).
Some of my details might be a little off, but I did spend a few months trying to build something very similar to this with gstreamer. WebRTC was hard to grok.