Hacker News Reader

Comment by thefourthchime | Hacker News Reader

Audio is much easier to stream though. You need nearly no data to start streaming audio, and it's likely you're internet will keep up.

The video is very different, the overhead is a lot more, 128kbit vs 2Mbps for example. On top of that, a video player will try to buffer ahead enough video to make sure you won't get and buffering later on, which means it needs to measure your bandwidth and try to guess how much.

UDP can be nearly instant except in for b-frames, however if it's over UDP is probably over transport stream which has it's own buffering levels built in to make sure the decoder has a large enough buffer.

View on HN

> Audio is much easier to stream though.

This isn't even remotely true. The brain will happily interpolate all kinds of visual information that is missing which allows you to drop frames with abandon as long as you display an older frame instead of a 'blank space'.

Audio isn't nearly as forgiving and even a relatively modest jitter or number of lost packets will result in an un-intelligible stream of audio.

I've spent many years of my life pumping video and audio across the net, even when that wasn't yet considered normal (or even an intended purpose of the net), and I've rarely heard complaints about video quality. But audio delivery requires top notch connectivity, low latency and sufficient throughput if you intend to hold a conversation with someone that does not result in irritation. Video is far more forgiving.

For something like live video conferencing, it's true the packet loss is worse for audio then video. I was responding to the previous comment about how his streaming experience over TCP was nearly instant. In the TCP case, of course you don't need to worry about loss.

> In the TCP case, of course you don't need to worry about loss.

You do, because TCP packets get lost at roughly the same rate as UDP packets do (though, there are some caveats here: on some congested links UDP packets tend to be dropped earlier).

The only major difference is that TCP will cause the packet to be - eventually - resent. The price of this complexity is added latency due to the requirement to buffer for a longer time than it could conceivably take to re-transmit packets so you can continue to stream. If you ever exhaust that time a TCP based system will grind to a halt.

In live video / real time conferencing such latency is really annoying and if it gets too long can be killing.

Elaborating on the "on some congested links UDP packets tend to be dropped earlier" ...

In our testing of lots of internet connections in the US, we've found that many of the "free" modems/wifi-routers that cable and phone companies supply really, really discriminate against UDP. It's not completely clear whether this is intentional, at least in part, or whether it's just buggy behavior.

There are several models of routers that you can reliable cause to just stop delivering UDP for a while, if you send enough UDP through them. This happens on their little internal Ethernet switches as well as over WiFi, so it's a firmware thing. Some of these routers will perk up and behave perfectly well right away, if you access one of the well-known DSL speed test sites, while flooding them with UDP packets. :-)

> however if it's over UDP is probably over transport stream

RTP is more commonly used for video calls, which doesn't have inherent buffering (but most implementations have a small jitter/reorder buffer if needed). Transport streams are better suited for broadcast, which has looser latency tolerances.

So the overhead to begin a video stream is due to the size of video data? Would video behave generally more like audio data (could stream immidiately) if the typical user bandwidth was larger?

Yes. Although it still might not be as good due to TCP's slow start.

In reality it's the size yes, but there is an inherent delay because of the way B-frames work. You'll need to buffer 2-3 frames worth 33ms each (for NTSC), so 66-99ms delay regardless of throughput.

Audio doesn't have such a concept, you get 33ms worth of audio, you can play it right away.

Of course, you can opt to not have b-frames and negate that issue.

most (all?) of the video codecs designed for low latency don't use b-frames for this reason.

It's just a setting, all codecs can optionally not use b-frames.

Reply on news.ycombinator.com