You have too much network bandwidth!!

@erik_squires 

Generally speaking, buffered audio/video uses TCP.  This means video streaming and audio streaming from a service like Netflix or Qobuz, Disney+, what have you

It also means these services have to provide their own custom app at the client end to handle TCP!

Strictly, every TCP packet has to be acknowledged as received and correct in an individual message sent back to the server,

The practical maximum packet size is about 1500 Bytes, or 12,000 bits, if Ethernet is involved.  Given Netflix streams 4K video at 16 million bits per second, that’s well over 1000 acknowledgment messages per second.  CD quality streaming would need about 100!

@richardbrand 

I’d just add that TCP requires every client to send a message back to the server for every packet they have successfully received.  Not an efficient use of the Internet nor server resources and the planet is suffering as a result

My speculation on what their goals were:

1) Reducing video glitches through TCP and buffering content

2) Better control of content  (DRM) although on the internet you can easily find every bit of content that Netflix has, but for the average person that's probably good-enough DRM

I have to admit, I no longer subscribe to Netflix; I have plenty of content with what’s on my cable TV, and I have less patience with trying to navigate between various services;  my cable has roughly a 1,000 channels, and when combined with a Tivo satisfies my wife and me

Hey @richardbrand 

It also means these services have to provide their own custom app at the client end to handle TCP!

Strictly, every TCP packet has to be acknowledged as received and correct in an individual message sent back to the server,

I believe this is not fully correct.  The TCP stack at the client and server handle some buffering and out of order re-assembly.  For every packet received at the client, the TCP stack sends bacn an acknowledgement (ACK).  If a packet is not ACK’d in time the sender will attempt to re-transmit until it gets an ACK for that specific packet. 

Of course, there are limits and time outs, but this is the process handled most of the time for all TCP streams, until things get TOO bad to fix.   What the client app (Netflix, Roon, etc.) does is try to buffer enough of the stream, say 10 seconds as an example, so that when these packets are delayed they don’t affect playback.

The TCP/IP stream may have built in resiliency, but it’s HIGH JITTER (i’m using this term metaphorically, not specifically.  That is, if you loose 5 packets, or end up with packets taking 2 separate routs which means constant re-ordering this causes stuttering, or pauses in the network pipeline. 

If you have ever started a large download and watched the progress bar you may have noticed that it seems to go quickly, then pause, then run again, then slow down.  All this is being handled by the TCP layer for the most part, but you certainly don’t want to hear music or watch a TV stream like that. 

The role of the client software buffers is to remove that network induced jitter, to to the human consuming the media it sounds and looks like one complete uninterrupted presentation. 

When watching Hulu, or listening to Qobuz, a little delay at the start is preferable to stuttering, but when in a meeting, we want our video and audio in real time, and we're happier to simply loose packets than to wait for them to be reassembled.   That's why there's a difference in TCP vs. UDP for media playback. 

One last thing worht mentioning.  How much a stream is delayed at the start is not an indicator of how big a buffer the client may keep.  For instance, Netflix may try to keep a 10 second buffer, but delay playing by only 2 seconds or less.  It may backfill after starting, or you may have high enough bandwidth that the first 10 seconds of data (say 50 MB) comes in a second... so it starts playback as soon as it can. 

Kind of neat how buffering and TCP packet management hide all of this from the consumer until things go really wrong.  This process is happening all the time around us and we don't even know it.

@richardbrand - 1000 times per second is literally 0.000001% of the bandwidth. Besides, streaming does not require ACK confirmation, protocols can work without it.