Why can you just drag the progress bar when watching videos? The video isn't a full file at all. I counted, and in 10 minutes it was cut into 64 pieces

Friday night, I watched cartoons with my kid. The little one wouldn't let me fast-forward, so I took advantage of his time to wash his hands and drag the progress bar to the center. The scene flashed out in an instant. Ten years ago, when you used download software, this was unimaginable—a video file of several hundred MB would have to wait from where you dragged it out. At that moment, I wondered, how on earth is this video being sent to me? Last time I wrote CDN article I clearly explained which server the video comes from, but this time I've uncovered an even more upstream matter: video site never intended to send you a complete file .

to clarify: the "one video" you see is actually a basket of fragments

find a public test video source, and I pulled out its list as is. A 10 minute 34 second 720p video—guess what shape it looks like? 64 small files, each about 10 seconds long, numbered from 462 to 525, not missing a single one. I downloaded three of these clips to check their size: the first was 1.92MB, the middle one was 1.65MB, the last one was only 0.63MB—and the last one was short, only 4.584 seconds, just a fraction of the leftovers.

this cutting method has an industry standard called HLS, which Apple invented for the iPhone back then. The list file file has the .m3u8 extension, which was originally an old format for player plugins and was used as a "goods list"; The suffix for slices is .ts. Most of the video apps and web players you see are running this set or its variants behind the scenes. Bilibili and YouTube use a DASH system, which uses exactly the same approach but has different manifest formats. Bilibili splits the video and audio into two separate tracks and sends them separately. So some downloaders get a pure video and a pure audio file, which you have to merge once before viewing.

the more I think about this cutting method, the more sophisticated it seems. Why not just send the entire file? Do the math: a 45-minute episode at 720p at this bitrate is over 400MB. If you click to read for 3 minutes and find it unpleasant, close it, and the server uploads 400MB for free; You drag it out until the 40th minute, and the first 39 minutes were all empty balls. After slicing into 10-second pieces, it ships wherever you see it, with each slice shipped on demand.

two menus: one for tube clarity, one for each piece of

list actually has two layers, similar to a restaurant's ordering system. The first layer is called the master list. The one I pulled is only 752 bytes, not even a short text message long. It only does one thing: set up the stalls. I counted five resolutions, each with a line of text — 240p says 246440, meaning this mode can max out at 246,000 bits per second; the 1080p level says 6221600, 6.2 Mbits per second, which translates to about 0.78MB per second.

the second layer is the real cargo list. After selecting the 720p file, the file files are 3606 bytes, honestly listing 64 lines, each line with the file name of a segment, and the number of segments indicated before the name. I counted: out of 64 frames, 57 are marked with exactly 10.000 seconds, while the remaining numbers are 9.95 or 10.05—when cutting, you can't cut a keyframe in the middle; you have to cut at the keyframe boundary, so sometimes there's a half-second difference.

By the way, this list itself is a URL, just like URL article, with question marks, parameters, and paths not missing a single item. So the m3u8 file you download from the internet is almost certainly not a video, but a menu—the menu is only a few KB, the video is a few hundred MB, and opening the wrong item is obviously empty.

the moment you drag the progress bar, the player does three things

Now you can understand why the progress bar is dragging so quickly. If you drag the progress bar to the 7th minute, the player pulls out the list and calculates: 7 minutes equals 420 seconds, each film is 10 seconds, so that's the 43rd film. Then it only does one thing—starting from the 43rd slab, it doesn't touch the first 42 slabs. You need to get back 1.9MB, and in just over a second, the screen appears. By the way, these clips use the HTTP protocol, running properly on TCP, just like opening a webpage, so firewalls and routers treat it like regular downloads; Why do video calls go through UDP? TCP discussed in the UDP article; real-time calls can't wait to retransmit, but watching videos is more expensive.

players will also stock up on hand. When playing, it doesn't just play one clip at a time; usually, it pulls three to five extra clips to cushion it, so even a slight shake won't cause it to freeze immediately. If your web page is busy reading and then trying something else, and then you keep streaming and it doesn't lag, it's probably because your stockpile hasn't been fully digested—this is different from browser cache two layers of caching: browsers store web files, video apps store slices. The same principle: having stock on hand means you don't panic.

then why do some content sources just spin around when dragged in? I've stepped on it twice. The first time was a wild site, with the slice cut to a very large size—almost 30 seconds or 7 to 8MB per slice. After dragging it out, you have to wait for a big pile of stuff to arrive, and the experience instantly collapses; There was also one time when the clips didn't match up—the player didn't match the actual time, the image was in the wrong position, and I had to reshoot. How well you cut it directly determines the feel of a source.

Why doesn't

resolution lag? Just changing the menu

halfway through the show, I manually switched from 720p to 1080p, then the screen paused for half a second and the show resumed, with the progress still in place. How did they do it? The player just swapped out the second layer of the list—from the 720p one to the 1080p one, and swapped the next clip for a high bitrate version. You just saw film 43, so continue from the 43rd film on the 1080p list; the progress bar hasn't changed at all.

automatic downshifting follows this logic. During peak evening hours, if your network can't handle 1080p at 0.78MB per second purchase speed, the player calculates: 'Pulled out timed out, stockpile runs low, automatically returns to 480p and continues with the list.' So "the image quality itself is blurry" doesn't mean the phone is broken, but that it uses lowering the graphics to replace the stuttering. The 480p level only costs just over 100,000 bits per second, so it can feed you all kinds of networks. If you think it's dropping too often, first check the broadband megameter article to calculate your own plan, then check if it's time to check WiFi.

My TV used to drop image quality during evening rush hour. At first, I suspected network lag, but later I found out it was because uploads were taken up by cloud drive backups, causing downstream problems—this issue was discussed in the about TV networking. The act of lowering image quality is actually the player's way of protecting your viewing experience—the direction is sound.

half a minute slower in the livestream, it's also the fault of the slices

At the end of the

on-demand list, there was an ENDLIST line, meaning "All 64 films are available, not a single one missing." The livestream list doesn't have this line, and the list itself is alive—refreshing every few seconds, with one or two new sheets added at the end, moving up like a rolling shutter. The streamer produces a small clip every 10 seconds and pushes it to the server. The server adds a line to the list, you refresh the list and pull the latest one. The whole chain rolls down like this.

that's why live streaming is naturally slow. When the host says something, you have to wait for it to be cut into a whole slice, uploaded to the server, distributed on the CDN, and then pulled down by you. Twenty to thirty seconds for this loop is normal. Some people seriously say, "Watching a live match is half a minute slower than my neighbor's cable TV," and the neighbor cheers for a goal, but you're still struggling—this really can't be blamed on your router; it's the inherent cost of slicing live streams, unless the platform cuts the clips very short, but the list refreshes too frequently and the server can't handle it. Latency and smoothness—live streaming platforms always find a balance between these two.

downloader, NAS, and it are two different worlds

understand this principle, a few things become clear. First, those "m3u8 downloaders" online work by pulling down 64 clips from a list one by one and piecing them into a file, so they're slow. Plus, the addresses in the list are time-limited, so if you download an expired list, it's a waste. Second, the movies stored in my NAS are complete files. The TV plays the entire file directly via SMB, which is a different approach from slicing—the advantage of a full file is that wherever you want is stored on your own hard drive, but the downside is that a 4K original disc is 80GB. NAS playback , I wrote about the TV 100Mbps network card choking on it.

Third, when you really encounter video lag, the troubleshooting approach is completely different: dragging the progress bar in circles, most likely because the source is poorly cut or the server is too far; The entire playback is blurry, indicating the bandwidth isn't enough to feed the current level; During the evening rush hour, it never lags during the day. First, check CDN dispatch and exit, then check your own WiFi. Don't restart the router as soon as it gets stuck—that's the most unfortunate step.

the final order: next time the video card drops, first check whether it's a drag card or a playback card, then check if the video quality is secretly downgraded, then the segmented method from the delay to determine whether it's a matter of home or outside, and finally it's time to restart. As for those 64 clips, I deleted them after counting them — knowing what they look like is more useful than keeping them.