免费视频压缩工具

视频压缩对您的文件究竟做了什么

原始视频是巨量的像素数据。一段 1080p（1920x1080）60fps 的视频约为 1920 x 1080 x 每像素 3 字节 x 每秒 60 帧，每秒未压缩素材约 370 MB。即使 720p 30fps 未压缩也约 80 MB/s。压缩通过利用两种冗余使视频可分享：帧内的空间冗余（相邻像素往往相似）和帧间的时间冗余（大多数像素几乎不变）。现代编解码器每隔几秒编码一个关键帧（完整画面），中间只编码差异。这些差异随后被 DCT 变换、量化（这是丢弃您眼睛较不敏感的高频细节的有损步骤）以及熵编码。您选择的 CRF（恒定速率因子）值控制量化步骤丢弃信息的激进程度。CRF 18 视觉上无损；CRF 23 是 x264 的默认值（对大多数观看者透明）；CRF 28 是可接受的网页质量；超过 CRF 30 您会开始看到暗场景中的方块和文字周围的蚊噪。

分辨率、帧率和比特率是三个独立的旋钮。把分辨率从 1080p 降到 720p 将原始数据减半的四倍（每个轴都减半）。把帧率从 60 降到 30fps 将数据减半。两种减少在精细内容上视觉上明显，但在脱口秀、大部分静态 UI 的屏幕录制或在手机大小屏幕上观看的社交媒体短片上常常不可见。比特率是第三个旋钮：1080p 30fps 视频以 5 Mbps 看起来很好；相同视频以 1 Mbps 显示块状压缩伪影。本工具的质量预设选取目标典型网页可接受比特率的 CRF 值：高预设约 CRF 23（1080p 约 5 Mbps），中等约 CRF 28（约 2 Mbps），低约 CRF 33（约 800 kbps），自定义让您自己拖动滑块。

音频也很重要。带 PCM（未压缩）音频的 10 分钟视频仅音频就有 100 MB。本工具默认把音频重新编码为 128 kbps AAC，相同 10 分钟降到约 10 MB，对大多数内容无可闻损失。容器（视频和音频轨道周围的 MP4 包装）主要是簿记：轨道索引、查找表、编解码器头。MP4 配 H.264 视频加 AAC 音频是 2026 年的通用语：它在您遇到的每个浏览器、手机、智能电视、游戏机和嵌入式播放器上都能播放。WebM 配 VP9 加 Opus 压缩好约 30%，但仍被一些老旧生态系统拒绝。

本工具的工作原理

压缩引擎是 FFmpeg，同一个基于 C 的工具支撑着 Netflix 的编码农场、YouTube 的转码流水线，以及您用过的几乎每一个视频工具。浏览器版本是通过 Emscripten 编译为 WebAssembly 的 FFmpeg（由 Jerome Wu 于 2019 年发起，目前在 4.x 版本），产生约 30 MB 二进制，完全在浏览器标签内运行。当您拖入视频时，文件通过流式读取器被读入 WebAssembly 虚拟文件系统，因此即使 1 GB 文件也不会在上传时撑爆浏览器内存。

文件进入 WASM 文件系统后，工具用类似 -i input.mp4 -c:v libx264 -preset medium -crf 28 -c:a aac -b:a 128k output.mp4 的参数启动 FFmpeg。FFmpeg 逐帧解码源，应用您请求的任何缩放或帧率变化，把帧交给 libx264 进行视频编码，并行通过 AAC 编码音频，并把结果复用到新的 MP4 容器中。进度消息通过 JavaScript 事件监听器从 FFmpeg 的 stderr 流出，实时更新屏幕上的进度条。

ffmpeg.wasm 使用 SharedArrayBuffer 进行多线程编码，因此编码器可以并行使用多个 CPU 核心，就像桌面 FFmpeg 一样。SharedArrayBuffer 出于 Spectre 漏洞相关的安全原因要求页面带两个 HTTP 头（Cross-Origin-Opener-Policy: same-origin 和 Cross-Origin-Embedder-Policy: require-corp）。本站设置了这些头，因此编码使用您所有可用的核心。下载的 blob 在内存中构建，作为合成的 <a download> 链接交给浏览器。

视频压缩简史

• MPEG-1，1993 年。第一个广泛流行的数字视频标准。用于 Video CD（1990 年代亚洲短暂与 VHS 竞争的格式）。目标比特率 1.5 Mbps，352x240 视频。按现代标准质量勉强，但它证明了消费级比特率下的数字视频是可能的。
• MPEG-2，1995 年。用于 DVD（1996 年发售）、数字广播电视（北美的 ATSC、欧洲的 DVB）和标清卫星。SD 视频 4 至 8 Mbps。专利授权从一开始就很复杂，预示了后来的编解码器之战。
• H.264/AVC 获批，2003 年。ITU-T 和 ISO/IEC 的联合成果，这一编解码器把 MPEG-2 的效率翻倍，并在五年内成为主导。蓝光（2006）、iPhone（2007）、YouTube 的过渡（2007 至 2010）和 HTTP 流（2009 年 HLS，2011 年 MPEG-DASH）都建立在 H.264 上。到 2026 年它仍是地球上兼容性最好的编解码器：每个浏览器、每个手机、每个智能电视都能播放它。
• H.265/HEVC，2013 年。相比 H.264 再有约 50% 效率提升，代价是 5 至 10 倍的编码计算量。普及被专利授权混乱拖垮：三个相互竞争的专利池（MPEG-LA、HEVC Advance、Velos）权利主张重叠，劝退了硬件和软件厂商。Apple 在 2017 年承诺（iPhone 7 起的 HEIC/HEVC），但 YouTube、浏览器和开放网络大多跳过 H.265，转向 VP9 和 AV1。
• VP9 和 AV1，2013 和 2018 年。Google 在 2013 年开源 VP9，然后与 Mozilla、Cisco、Microsoft、Netflix、Amazon、Intel 等在开放媒体联盟中合作设计 AV1（2018 年获批）。两者都免版税。AV1 在免费可用的同时在压缩上匹敌或超过 H.265。YouTube 向支持的客户端提供 AV1，Netflix 用它做高级层级，硬件解码器从 2020 年起进入旗舰芯片。
• ffmpeg.wasm，2019 至 2026 年。Jerome Wu 在 2019 年通过 Emscripten 将 FFmpeg 编译为 WebAssembly，发布了第一版 ffmpeg.wasm。早期版本约 50 MB 且慢。4.x 系列稳定在约 30 MB 并支持 SharedArrayBuffer 多线程，使浏览器侧压缩对 1 至 2 GB 文件实用。到 2026 年这一方法已经成熟到像本工具这样的工具可以替代基于云的服务，满足大多数个人压缩需求。

使用方法

1. 上传视频： 选择或拖放需要压缩的视频文件。
2. 设置压缩参数： 选择目标质量级别或文件大小，可选择降低分辨率或帧率。
3. 压缩并下载： 点击“压缩视频”，处理完成后下载更小的视频文件。

为什么使用视频压缩工具？

大视频文件上传缓慢、存储成本高、在移动网络上播放不流畅。社交媒体平台、电子邮件附件和网站托管都有文件大小限制。视频压缩通过调整比特率、分辨率和编解码器效率来减小文件大小，通常可以在视觉质量损失极小的情况下实现 60～80% 的大小减少。这个基于浏览器的压缩工具会处理所有技术细节，您只需设置期望的质量并下载结果即可。

功能特点

• 质量预设： 提供高、中、低和自定义质量设置，并显示预估输出大小。
• 分辨率缩小： 可选择缩小到 1080p、720p、480p 或 360p 以进一步减小文件。
• 帧率调整： 将帧率从 60fps 降低到 30fps 或 24fps 以减少数据量。
• 文件大小对比： 显示原始和压缩后的文件大小以及实现的压缩比。
• 本地处理： 压缩完全在您的浏览器中运行，无需云端上传。

真实世界的压缩工作流

• 突破 Discord 的 25 MB 限制。压缩视频最常见的原因。一段 2 分钟的屏幕录制或手机短片常常 60 至 200 MB。CRF 28 加可选的 720p 降采样通常把 2 分钟的 1080p 短片做到 8 至 15 MB。CRF 30 至 32 加 480p 降采样甚至能处理高动态内容。本工具的中等预设正是为这个用例校准的。
• 邮件附件大小限制。Gmail 和大多数企业邮件服务器把附件上限定在 20 至 25 MB 左右。要把快速演示或操作视频发给非技术同事，把 90 MB 手机视频用中等质量预设降到 15 MB MP4 是阻力最小的路径。
• 网页托管成本和加载时间。自托管在作品集网站或产品页上的视频，按 5 MB 比按 50 MB 服务便宜得多（CDN 带宽、移动加载时间、Core Web Vitals）。对于静音循环的背景英雄视频，CRF 30 至 32 加静音音频和 720p 降采样能在便携文件大小下给出广播级外观。
• 个人存档。旧的手机视频吞噬手机和云存储。把一年的家庭视频按 CRF 23（对大多数内容视觉无损）重新编码常常把存档削减 50 至 70%，无可察觉的质量变化。iCloud 的 50 GB 层级突然变得好用多了。
• 社交媒体上传。Instagram、TikTok 和 X 都会重新编码您上传的内容，但从压缩到他们建议比特率以下的源（1080p 通常 5 至 10 Mbps）开始意味着更快的上传，并避免他们的算法用自己激进的重新编码毁掉您的视频。高预设在仍然削减文件大小的同时保持最大质量。
• 蜂窝网络的移动数据节省。在蜂窝网络上发送视频：50 MB 在 4G 上需要 20 至 40 秒，吃掉相当多数据，信号差时可能失败。压缩到 5 至 8 MB 即使信号差也能在 2 至 3 秒内可靠发送。在用受限套餐的朋友间发短信视频前值得做。

常见陷阱及其含义

• 重新压缩造成的代际损失。每次压缩传递都增加量化噪声。压缩已经压缩过的视频（TikTok 下载、屏幕录制应用已编码的输出、手机导出）以可见的质量损失换取更小的增量压缩。始终从您手中质量最高的源开始。
• 把 CRF 推得太高。高于 CRF 30 的设置会产生可见的压缩伪影：暗场景中的方块、文字和锐边周围的蚊噪、渐变天空中的色带。对小屏幕尺寸的预览短片您可以用 CRF 32 至 35 蒙混过关；对任何会在电视或显示器上全屏观看的内容，把 CRF 保持在 28 或以下。
• 忘了音频比特率。带未压缩 PCM 音频的 10 分钟视频仅音频就 100 MB。许多手机导出包含未压缩或轻度压缩的音频。重新编码为 128 kbps AAC 把音频降到约 10 MB，对语音和大多数音乐无可闻差异。本工具始终重新编码音频。
• 可变帧率源。屏幕录制和一些手机摄像头输出可变帧率（fps 随动作变化）。一些编码器处理得不好，产生重复帧或卡顿。本工具规范化为恒定帧率以避免这个问题。
• HDR 到 SDR 的管线。手机摄像头现在录制 10 位 HDR（iPhone 上的 Dolby Vision、Android 上的 HDR10）。把 HDR 短片扔进未做正确色调映射的 8 位 SDR 管线产生褪色或奇怪饱和的输出。对于 HDR 源，要获得最佳效果，请先在设备上做色调映射再压缩，或接受 SDR 输出会与原始看起来不同。
• 超大文件遇到浏览器内存墙。ffmpeg.wasm 在浏览器内存中运行。约 2 GB 以上的文件常常撞上浏览器每标签内存上限（桌面通常 4 GB，移动更少）并在编码中途失败。对更大的文件，请使用桌面 HandBrake 或可以从磁盘流式读取的 FFmpeg CLI。

隐私：您的视频从不离开您的设备

每个基于云的视频压缩服务（FreeConvert、Clipchamp、OnlineConverter、CompressVideo.io 等数十个）都遵循相同流水线：您上传整段视频，他们的服务器运行 FFmpeg 或类似工具，您下载较小的结果。一段 200 MB 的手机视频要通过他们的基础设施上传 200 MB 加下载 50 MB。视频内容常包含敏感材料：家人或同事的脸和地点、对话和通话的音频、私人界面或工作会议的屏幕录制、揭示家或工作地点的 GPS 标记场景。大多数运营商发布隐私政策，承诺在 1 至 24 小时内删除上传并在传输中加密，大型运营商持有 ISO/IEC 27001 认证。他们有强烈的商业动机履行这些政策。但「一小时内删除」不等于「从未被看见」。在那个窗口里文件就在运营商基础设施上，对任何拥有正确权限的进程或人员可访问，并按运营商保留政策出现在日志和备份中。

本工具从不上传任何内容。完整流水线（文件选择、通过浏览器原生读取器解码、通过 ffmpeg.wasm WebAssembly 编码、通过浏览器 blob API 下载）在您的浏览器标签内运行。没有上传，没有携带视频数据的网络请求，没有日志条目。您可以在压缩前打开浏览器开发工具的「网络」标签来验证：没有任何带视频内容的请求离开。唯一的网络流量是页面本身的初始加载，加上 ffmpeg.wasm 约 30 MB 的一次性下载（后续访问缓存）。页面加载后把浏览器切到飞行模式，压缩器仍能在本地文件上工作。

何时另一个工具才是正确选择

• 超过 2 GB 的文件。约 2 GB 以上浏览器内存限制成为真正的墙。请使用桌面 HandBrake（免费、GUI、跨平台）或能从磁盘流式读取并使用所有可用系统 RAM 的 FFmpeg CLI。HandBrake 的质量预设直接对应本工具使用的相同 CRF 值，您的设置可以迁移。
• 对数百个文件的批量压缩。对一个文件夹做系统化的重新编码时，配 shell 循环或使用 subprocess 的 Python 脚本的 FFmpeg 命令行工具显著更快。一行：for f in *.mp4; do ffmpeg -i "$f" -c:v libx264 -crf 28 -c:a aac -b:a 128k "out_$f"; done。也可以用 GPU 编码器（NVENC、QuickSync）获得 10 至 20 倍加速。
• 专业后期制作工作流。Adobe Premiere、DaVinci Resolve、Final Cut Pro 和 Avid Media Composer 都把编码与编辑放在一起。如果您已经在编辑视频，导出时的编码是工作流的一部分。Resolve 的免费层支持 4K 并提供所有相同的编解码器。
• 需要硬件编码器获得最大速度。GPU 加速编码器（Nvidia 上的 NVENC、Intel 上的 QuickSync、AMD 上的 VCN、Apple Silicon 上的 VideoToolbox）比 CPU 编码器快 10 至 20 倍，每比特质量略低。浏览器工具无法访问硬件编码器；对速度比完美质量更重要的任务，请使用启用硬件加速的桌面应用。

常见问题

视频可以压缩多少？

典型的压缩比为 50～80% 的大小减少。100 MB 的视频通常可以在视觉质量损失极小的情况下压缩到 20～40 MB。具体压缩率取决于原始编解码器、内容复杂度和质量设置。

压缩会影响视频质量吗？

在中等质量设置下，大多数观众在正常观看距离下无法区分压缩视频和原片。摄像机或屏幕录制的高比特率素材压缩效果很好。从社交媒体下载的已压缩视频效果较小。

压缩视频的最佳格式是什么？

采用 H.264 编解码器的 MP4 是所有设备和平台上兼容性最高的压缩视频格式。对于网络用途，采用 VP9 的 WebM 提供更高的压缩率，但在某些设备上兼容性较低。

其他常见问题

为什么压缩比视频时长还慢？

软件视频编码在计算上很昂贵。5 分钟 1080p 短片在高质量下可能要 3 至 15 分钟来编码，取决于您的 CPU。FFmpeg 中的 -preset 标志在编码速度和压缩效率之间权衡：ultrafast、superfast、veryfast、faster、fast、medium、slow、slower、veryslow。本工具默认 medium（良好平衡）。桌面应用中的硬件编码器可以快 10 至 20 倍，但在相同质量下产生略大的文件。

我应该选 H.264、H.265 还是 VP9？

为最大兼容性（分享给任何人任何设备），选 H.264。为约 30% 更好的压缩但支持广而非通用，选 H.265（在 Apple 设备和近期 Windows 上好）或 VP9（在 Android 和 Chrome 上好）。为现代兼容下的最小文件，选 AV1。本工具默认 H.264，因为它到处都能播。

压缩会影响帧时序或同步吗？

本工具保留源帧率和音视频同步。如果您的源是可变帧率，编码器在编码期间规范化为恒定帧率，可能引入微小的时序偏移（微秒），但播放时不可见。如果您在压缩后注意到同步漂移，源很可能已经有漂移，编码器只是把它固化了。

我能不重新编码就压缩吗（stream copy）？

本工具不行。Stream copy（FFmpeg 中的 -c copy）只改变容器（例如 MP4 到 MKV）而不重新编码。要真正减小文件，编码器必须以较低比特率或不同编解码器重新编码像素数据。如果您只想改变容器格式而不改变大小，请使用视频格式转换器而不是压缩器。

为什么我压缩的文件有时看起来比预设暗示的更差？

高动态内容（运动、动作、快速场景切换）比静态内容更难压缩。在脱口秀视频上看起来很好的 5 Mbps 比特率，在同样比特率下可能在足球比赛上显示伪影。CRF 模式（本工具使用）会自适应：它给复杂场景分配更多比特，给简单场景分配更少，因此输出是恒定质量但可变文件大小。如果文件大小比恒定质量更重要，请在桌面工具中切换到目标比特率工作流。

有桌面或命令行的等效工具吗？

有，几个。HandBrake 是标准的跨平台 GUI（免费、开源，底层用同样的 FFmpeg）。FFmpeg CLI 是正典的命令行工具。Shutter Encoder 是更友好的 FFmpeg GUI。移动端 VLC 和 CapCut 有基础压缩。批量自动化方面，shell 脚本中的 FFmpeg 无人能敌。所有这些与本浏览器工具产生本质上相同的输出，因为它们共享同一底层编码器。