4 ms·

I have always wondered why video sites (who don't want downloaders for various reasons) serve their content faster than required for normal speed viewing. Well,

I have always wondered why video sites (who don't want downloaders for various reasons) serve their content faster than required for normal speed viewing. Well, I don't complain, but I wonder.

gattilorenz 5y ago
For buffering, since there might be a network hiccup sometime in the future. But generally also a better user experience if the user wants to skip a few seconds/minutes forward. And I guess the bandwidth required also depends on the video bit rate/format/compression ratio, so you need to implement a lot of smarts to make sure you don't serve something too slow or too fast, and still people would be able to download the video, albeit at a slower speed. So, basically, it's not worth it.
foxfluff 5y ago
The primary reason I've used ytdl is to work around youtube's crappy buffering. In the past you used to be able to leave a youtube page open and it'd buffer the whole video but now it stops at like.. thirty seconds? Have fun watching when their servers can't serve.
kaetemi 5y ago
Video streams are just a series of 2-second-long video files. It's no different from any regular CDN. (The real money is in the compression processes.)
- cube00 5y ago
  I was surprised by just how many small chunks (as you said 2 seconds, a few hundred kilobytes) the browser has to request and string together to make a video stream that play smoothly and that I can skip around. It's kinda amazing when you think about it.
varenc 5y ago
They address this by having the video player stop buffering more than 30 seconds ahead. It's also less compute resources for the servers to send all the bytes for the next 30 seconds to a client at max speed, let the client disconnect and wait 3-5 seconds, then give them the next 3-5 seconds immediately when it's requested. If they only let you download video at a rate slightly faster than video playback rate than all clients would have a constantly open connection downloading video which would tie up more resources.

I have always wondered why video sites (who don't want downloaders for various reasons) serve their content faster than required for normal speed viewing. Well, I don't complain, but I wonder.

gattilorenz 5y ago

For buffering, since there might be a network hiccup sometime in the future. But generally also a better user experience if the user wants to skip a few seconds/minutes forward. And I guess the bandwidth required also depends on the video bit rate/format/compression ratio, so you need to implement a lot of smarts to make sure you don't serve something too slow or too fast, and still people would be able to download the video, albeit at a slower speed. So, basically, it's not worth it.

foxfluff 5y ago

The primary reason I've used ytdl is to work around youtube's crappy buffering. In the past you used to be able to leave a youtube page open and it'd buffer the whole video but now it stops at like.. thirty seconds? Have fun watching when their servers can't serve.

kaetemi 5y ago

Video streams are just a series of 2-second-long video files. It's no different from any regular CDN. (The real money is in the compression processes.)

cube00 5y ago
I was surprised by just how many small chunks (as you said 2 seconds, a few hundred kilobytes) the browser has to request and string together to make a video stream that play smoothly and that I can skip around. It's kinda amazing when you think about it.

varenc 5y ago

They address this by having the video player stop buffering more than 30 seconds ahead. It's also less compute resources for the servers to send all the bytes for the next 30 seconds to a client at max speed, let the client disconnect and wait 3-5 seconds, then give them the next 3-5 seconds immediately when it's requested. If they only let you download video at a rate slightly faster than video playback rate than all clients would have a constantly open connection downloading video which would tie up more resources.