WelcomeUser Guide
ToSPrivacyCanary
DonateBugsLicense

©2025 Poal.co

(post is archived)

[–] 1 pt

That gets me to wondering why more streaming stuff isn't UDP with a little bit of ECC (sort of like CD audio vs. data CD). Maybe the ECC overhead is more than the TCP overhead.

[–] 1 pt

https://www.rfc-editor.org/rfc/rfc9000.pdf

More stuff will be soon. Some already is.

[–] 0 pt

...the speed benefits of UDP over TCP are based on the fact that you're NOT doing error-correction. A error-corrected UDP is much slower than raw UDP. QUIC, huh? We already have that - it is called Transmission Control Protocol (TCP).

[–] 0 pt

https://docs.codavel.com/technology/

Reading over it, it's kind of like UDP+. Their info-graphics help explain it better than I could, so I won't.

[–] 1 pt

Quality of service i'd imagine. Under heavy loads if your stream continues but your data loss exceeds 5-10% your going to complain.

[–] 0 pt

You have bigger problems with those kind of losses. You probably would have trouble with TCP streams then, too.

[–] 0 pt

Well I'm sorry faggot, I don't know correlations of % of packet loss verses stream quality. I just threw a percent out there. I trust that multi billion dollar multimedia companies know a bit more than you or I.

[–] 0 pt

What I've never been able to figure out is why it isn't multicast

[–] 0 pt

Wouldn't that only work for live streams? That won't work when you want your TV show to start streaming at 14:30 and the next guy wants to start watching at 14:37.

[–] 0 pt

For sure. That's what I thought I was talking about. Even in the case of live streams, AFAIK, Multicast is rarely used.