Why Does My Video Load Slow?

This week I want to talk about something we're working on right now. It's one of the most common complaints we've heard recently - videos pausing and loading while you watch them. We call this problem buffering.

What is buffering?

A buffer is a place to store data. Video buffering means that you've reached the end of the data you've downloaded so far, and you must wait until more data is downloaded before you can keep watching. This can happen if you're watching a video at the same time as you're downloading it (aka how most people watch video these days).

Why do videos buffer?

The two important numbers to know are network bandwidth and video bitrate.

Bandwidth is how many bits of data your internet connection can deliver to your computer, per second. You can check yours here. If your connection is 1Mbps, that means you can download one million bits per second.

Bitrate is how many bits of data a video has, also per second. You can calculate it by dividing the size of the video by the duration. A 30-second video clip thats 60MB in size has a bitrate of 2Mbps. A video's bitrate is affected by many factors, including the dimensions (a larger picture requires more information), quality (more details = more information), and format (compression can reduce the size without losing data). For an extreme example, this 6.3GB video is two seconds long.

Notice that bandwidth and bitrate are both measured in bits per second. They describe the same thing: an amount of information per unit of time. This means you can compare them. If your bandwidth is lower than the video bitrate, then you download slower than you watch, and you'll get buffering. If your bandwidth is higher, then you can download it faster than you can watch it and it is will never have to buffer.

To be pedantic, this all assumes you're watching the video at one second per second. If you listen to interviews or podcasts at 1.5x speed (like I do), you need 50% more bandwidth to avoid buffering.

How to avoid buffering?

Centralized services like Youtube avoid buffering by making several compressed copies of your video with reduced bitrates and serving you the one that best matches your internet bandwidth. They also detect when buffering is happening and switch to a lower bitrate. In a peer-to-peer service like LBRY, that's harder to pull off. Without central servers, compression has to be done client-side. Some low-power clients (like cellphones, which have high-resolution cameras) can't be expected to do it.

Our first step to address the problem was simply to add a message to the lbry.tv upload page that lets you know when your video is too big for a typical internet connection (we targeted 5Mbps as a reasonable bitrate). The arrow shows the day when we shipped the bitrate alert message. We'll be watching this graph over the next few weeks to see how much of an effect it has.

We also added a flag to the SDK to optimize videos for the web. This option does several things including compression (if necessary) and moving the MP4 metadata to the start of the file (helpful for faster video streaming). For more info, see our publishing guide for transcoding instructions and our recommended video settings.

Update March 20, 2020: 12 hours after I wrote this post, we switched from TCP to QUIC for file transfers between the lbry.tv blob cache and the player servers (announcement). That improved bandwidth by 3x, greatly reducing buffering. This improvement is just for lbry.tv for now. It will be in the apps ASAP.

Down the road, we'd like to add more support for automatic client-side compression in the app, including creating multiple versions of each video file for different internet speeds. This would require updates to the claim metadata structure to store information about multiple streams in one claim. Even more long-term, we could encourage the ecosystem to support third-party services that offer to do the transcoding and hosting (for a fee) by making it easier to run and use the necessary infrastructure.

How nerdy do you want it?

Hey readers, I have a quick question for you. This channel is meant for a techincal audience. I want to strike the right balance between explaining things in a simple and accessible way and not boring you with the basics that everyone already knows. Is the post above too detailed, not detailed enough, or just right? What would you want to see more of? Let me know in the comments. Cheers!