Hacker News Reader

Comment by 12things | Hacker News Reader

A very interesting project, can you elaborate more on how it is getting sub second latency and why youtube/twitch seem to have more than a few seconds of delay.

View on HN

HTTP video streams are split into segments and those segments are delivered whole. Larger segments are easier to cache and scale to bigger number of viewers. The other factor is that youtube and twitch spend more CPU time on compression to achieve lower bitrates.

YouTube and twitch use RTMP which operates over TCP. This means that each time we send a packet we need to ensure that it’s been received which adds latency overhead. Lightspeed uses the FTL protocol which operates over udp thus reducing the latency overhead

So assuming you have packet loss - you just get a paused/blank stream until the flow continues? How does it handle any network issues.

Would it ever be possible to route two stream via different paths to the client and let the client just accept the first packet from either and drop the other in order to add some redundancy to delivery?

This wouldn’t actually solve anything since WebRTC can handle packet loss. The loss is going to be coming from OBS -> Server which unfortunately there isn’t much I can do about that since it uses UDP

Ah thanks.

A diagram of the setup on your page would be helpful...

Multiple streams is BAU with RTP - using smpte-2022-7, or most of the time just firing the packet different times on different routing tables.

Sometimes network paths die. This could be a dodgy router in a third party network that drops streams for 150ms at a time, or a bgp recalculation that knocks it out for maybe a minute or so.

In both cases you need to have multiple routes to keep your latency low.

Reply on news.ycombinator.com