So Twitch has a new “low latency” mode. Except by low latency they mean 2-3 seconds, whereas before it was more like 10 seconds. And for some reason they’re still using HLS. Meanwhile, Mixer has been sub-second for a long time… which is still an order of magnitude over ideal.
-
-
Replying to @comex
there is no cross-browser-compatible streaming protocol that supports loading less than a GoP of latency
1 reply 0 retweets 0 likes -
Replying to @11rcombs
What is GoP? And doesn’t MSE allow for low-latency streaming?
1 reply 0 retweets 0 likes -
Replying to @comex
group of pictures; the span between two keyframes MSE requires you to pass the browser an entire MP4 segment at once; theoretically those are allowed to start on non-keyframes, but in practice browsers flip a shit if they don't
1 reply 0 retweets 0 likes -
Replying to @11rcombs
Hmm, Interesting. Basically this issue? https://bugzilla.mozilla.org/show_bug.cgi?id=1290840 … …oh, wait, what about WebRTC?
1 reply 0 retweets 0 likes -
Replying to @comex
that gets you around it in theory, but it's not ubiquitous in browsers yet (especially mobile), doesn't work on all networks, and adds a large amount of server-side complexity
1 reply 0 retweets 0 likes -
WebRTC works in practice, but is very heavy server-side. We use it for audio (<70ms latency end to end) but it's a lost cause for video with our infra.
1 reply 0 retweets 1 like -
Why is it heavy? Is it an issue with the server software or something more fundamental?
1 reply 0 retweets 0 likes -
It's basically mandatory DTLS, which requires negotiating a 1:1 stream with each client, so multicast doesn't work. The server-side software stacks are a lot less mature than the HTTP ecosystem. It's possible but not nice.
2 replies 0 retweets 1 like
Sorry, DTLS for data, SRTP for media, but the key exchange is over DTLS either way.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.