2 ms·
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
by 12things 6y ago
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.
- GRVYDEV 6y agoYouTube 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
- samstave 6y agoSo 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?
- GRVYDEV 6y agoThis 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
- samstave 6y agoAh thanks. A diagram of the setup on your page would be helpful...
- midasuni 6y agoMultiple 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.
- imtringued 6y agoHTTP 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.