Hacker News new | ask | show | jobs
by jkarneges 4225 days ago
TCP is more efficient than UDP if you don't need low-latency delivery, because you can compress more data at once and waiting for retransmitted packets isn't a problem. This also ensures you get a high quality stream through the viewing experience unless there are major congestion problems.

A video chat will always prefer UDP transmission for the lowest latency possible, but quality may vary and bandwidth usage can technically be higher.

1 comments

"TCP is more efficient than UDP if you don't need low-latency delivery, because you can compress more data at once and waiting for retransmitted packets isn't a problem."

Would you care to elaborate what you mean by any of those things? I happen to have some background in protocols but I honestly can't make sense of any part of that sentence.

If you know that the receiver is going to receive all of the data that you send (or at least a lot of it at once, for example if you have a 5-second buffer), then you can more efficiently compress all of the media being sent.

Typically, a UDP-based video stream will have less dependency among the packets, so that even if a packet is dropped, the next packet is still decodable. This means that there is more redundant information per-packet as a durability measure.

UDP-based streams also often have something called forward error correction (FEC). This is where you encode lower quality versions of media samples in subsequent packets. Again this is trading more bandwidth for realtime durability. If you miss a packet, then the next packet probably has the same media sample in a lower quality, and your 100ms jitter buffer gives you just enough time to make use of it. This is far more time-efficient than requiring the receiver to ask the sender to retransmit a missed packet.

To the point about retransmission: in UDP cases, it's often not worth bothering about. By the time you round-trip the request, you've probably already received more recent media.

I should say that this isn't about TCP vs UDP so much as it is about buffered vs realtime streaming.

"If you know that the receiver is going to receive all of the data that you send (or at least a lot of it at once, for example if you have a 5-second buffer), then you can more efficiently compress all of the media being sent."

That has nothing to do with the underlying transport.

"Typically, a UDP-based video stream will have..." "UDP-based streams also often have something..." "in UDP cases, it's often not worth bothering about... "

Here you're describing a bunch of possible properties a hypothetical protocol written on top of unreliable datagrams would/should have.

"I should say that this isn't about TCP vs UDP so much as..."

This part is correct. You should keep this part.

"..it is about buffered vs realtime streaming."

Right. Let's not conflate transport protocols with media streaming methodologies please.