3 ms·
Udp is preferred for content that can be lossy. The overhead of tcp for streamable content, especially over WiFi, is too high. I ran into this issue by trying t
by devwastaken 8y ago
Udp is preferred for content that can be lossy. The overhead of tcp for streamable content, especially over WiFi, is too high. I ran into this issue by trying to have a simple video server through nginx on a DigitalOcean droplet. Wouldn't work well over WiFi at range, but YouTube would work easy on chrome.
- colde 8y agoI think that has a lot more to do with YouTube having an a very optimized video player, and using ABR streams. That works fine over WiFi in general. If you are doing MP4 pseudo-streaming, thats really a completely different beast. You don't really want to drop data for streaming video either, sure, in some cases it might not make a huge difference, but if you drop i-frames, you are going to have quality issues.
- devwastaken 8y agoProblem is on wifi that the whole syn/ack pattern gets lost and has to retry. I could have probably optimized this by having a range, but afaik if any in the range fail it has to still re-send that packet and get an ack. I'm not sure if HTTP/3 will have a way to do selective re-sending, but that is how very versatile lossy video streams do it. I-frames can get re-sent while normal frames can be lost.