tl;dr 服务器生成的 sprite 表，根据需要下载。
我们可以猜测图像是在服务器端生成的。 YouTube 对每个视频的处理比拉几个缩略图要强烈得多。此外，快速的 Google 表明此功能已经存在了几年 - 可能比执行此客户端所需的 HTML5/JS/browser-horsepower 更长。
我在浏览器中点击了Download Tools > Resources，并从我的提要中查看了newly-posted video。有趣的是，还没有预览（当我检查时，视频只播放了大约 20 分钟）。这表明图像可能是在服务器端生成的，只是尚未完成处理。
检查an older video 并查看Resources > Images 并没有发现任何有趣的东西。所以我切换到Timelines 并点击记录，然后开始将鼠标悬停在时间线上并观察网络流量。当我移动鼠标时，*.jpg 文件开始加载，它们包含来自给定视频部分的 25 个缩略图：
我还注意到初始文件M0.jpg 是相同大小的图像，但包含整个视频的大约 100 个缩略图，而不是一个片段的 25 个缩略图。示例：
用一个新视频再次测试，看起来 100 张图片 M0.jpg 被首先下载，并提供基本的低分辨率少粒度缩略图预览。然后，当您将鼠标悬停在视频的不同部分时，会根据需要下载更高分辨率的 M0.jpg、M1.jpg 等。
有趣的是，longer videos 并没有改变，这就解释了为什么缩略图有时会很糟糕。如果您的连接或 YouTube 获取高分辨率缩略图的速度太慢，那么您会被一个非常长的视频的 100 个低分辨率缩略图卡住。不知道这对较短的视频是如何工作的。此外，看看他们从什么分布中提取缩略图可能会很有趣（它只是每 1/100 视频的线性分布？还是其他什么）。
最后一个花絮，我注意到如果你使用一个带有时间码的 url，你不会得到一个完整的 100 图像 M0.jpg 表，而是一个完全不同的大小 M#.jpg 包含大约 25 个低分辨率缩略图从时间码到视频结尾。
我猜他们假设当人们链接到特定时间码时，用户不太可能跳转到视频中的较早点。此外，这比通过发送正常的 100 张图像 M0.jpg 获得的约 75 张图像的粒度要小得多。另一方面，它也只有大约 30% 的大小，所以速度可能很重要。
至于生成缩略图，ffmpeg 是个好方法：
要制作多个屏幕截图并将它们放入单个图像文件（创建图块），您可以使用 FFmpeg 的图块视频过滤器，如下所示：
ffmpeg -ss 00:00:10 -i movie.avi -frames 1 -vf "select=not(mod(n\,1000)),scale=320:240,tile=2x3" out.png
这将在影片中搜索 10 秒，每 1000 帧选择一次，将其缩放为 320x240 像素，并在输出图像 out.png 中创建 2x3 切片，如下所示：