如何压缩视频文件，用于邮件附件和 Discord

实际上限比别人告诉您的数字更小

邮件服务器不会把您的文件按原始字节发送。附件在发出时会经过 base64 编码，而 base64 要用四个字符才能承载三个字节，所以真正在网络上传输的邮件会比您磁盘上的文件大出约三分之一。Gmail 那个广为人知的 25 MB 上限，针对的是编码后的整封邮件，而不是您在文件选择窗口里选中的那个文件。实际能稳妥发出去的视频，最大也就 18 MB 左右，邮件头和正文还会再多占一点空间。

其他服务各有各的上限，而且会调整。Discord 免费用户的上传上限就改过不止一次。Outlook、iCloud Mail 和企业内部的 Exchange 服务器都各自设定上限，公司 IT 部门还可能把它设得更低。请以应用拒收文件时显示的数字为准，而不是您几年前记住的那个数字。

能调的只有三个旋钮

任何视频压缩工具，无论是否在浏览器里运行，能动的都是同样三样东西：每一帧有多少像素，编码器每秒可以花多少比特，以及视频有多长。第三样往往最划算，却也最常被忽略。把开头四十秒摆弄三脚架的画面剪掉，省下的空间比怎么调画质都多，何况本来也没人想看那一段。

本站的压缩器不会给您摆出一排滑块，而是替您拧好了前两个旋钮。画面长边的上限是 720 像素，所以 1080p 的视频输出后宽度为 720 像素。比特预算不是一个固定数字，而是根据源视频轨实际用掉的码率算出来的；对于手机拍摄的典型 1080p 视频，结果大约是原视频码率的五分之一。预算还设了封顶，确保它永远不会接近源视频的码率。之所以要封顶，是因为以前有一个固定的码率下限，比某些本已编码得很高效的视频的码率还高，结果越压缩文件越大。

音轨决定了体积的下限

走快速路径时，音频会原样复制过去：不解码、不重新编码，也不缩减。这样声音和原来完全一样，也不占用处理时间，但这也意味着音频是一笔固定开销，在这里没法靠压缩去掉。如果是一段对着镜头说话的长视频，画面几乎不动，人声一直不停，那么剩下的体积里大部分可能都是音频。如果输出仍然太大，而画面已经发虚，再怎么压缩视频也救不回来。

速度取决于您的设备，而不是文件

这个工具通过 WebCodecs API 调用浏览器自带的视频编解码器，而不是用页面附带的编译型编码器。如果您的设备为浏览器提供硬件视频编码，处理一段视频的速度会是播放速度的好几倍。如果没有，软件编码可能比直接把视频看一遍还慢。

工具在运行过程中会测量自己的速度。如果预估会比实时播放还慢，它就放弃这条路径，改为从 Canvas 录制视频。这种备用方式耗时至少等于视频时长，因为它是以播放速度录制一路实时流。三分钟的视频，就意味着要等三分钟。这期间请让标签页保持在前台，因为浏览器会限制后台标签页的运行速度，时间会拖得更长。

它的能力边界在哪里

整个文件会被读入内存，解封装后的帧保存在内存中，生成的 MP4 也是在内存中拼装好再交给您。峰值内存占用可达源文件大小的数倍。手机拍的视频或录屏处理起来很轻松。半小时的 4K 文件对浏览器标签页来说就是强人所难，它本来就不是为这种任务设计的，结果不是慢如蜗牛，就是直接崩溃。

开始之前，还有几个限制值得了解：

• 快速路径需要 MP4 或 MOV 容器。WebM 和 MKV 文件会改走较慢的实时路径。
• 只有一个预设，没有画质选项，所以如果结果超出了目标大小，也没有旋钮可以微调。
• 关闭标签页或让电脑进入睡眠，任务就会中止。中途不会保存任何进度。
• 非 AAC 的音频无法直接复制，这会让整个任务改走较慢的路径。

什么时候桌面软件是更好的选择

HandBrake 和 ffmpeg 命中目标文件大小的精度远高于这个工具，因为它们可以做两遍编码：第一遍分析视频，第二遍把比特花在真正需要的地方。它们能处理长达一小时的文件，也能处理装满这类文件的整个文件夹，允许您选择编解码器和编码档次，而且不受浏览器标签页可分配内存的限制。如果您不只是偶尔压缩视频，就装一个吧。

有时候，正确的做法是根本不压缩。如果文件有 2 GB，无论怎么压，都没法在不变成一团马赛克的前提下塞进一封邮件。把它放到共享网盘里，然后发送链接。压缩适合接近上限的视频，而不是超出上限五十倍的那种。

您的视频不会离开您的设备

视频从不上传。以上所有步骤都在您已经打开的这个页面里完成。如果视频是医学影像、录下来的证词或孩子的学校演出，这一点比听起来重要得多。您不必只听我们这么说：打开浏览器的开发者工具，切换到网络面板，然后随便压缩一个视频。没有任何请求携带您的文件，因为根本不存在这样的请求。