视频剪辑器，免费

通过设置起止时间剪辑视频文件。支持快速或精确模式。

您的文件从不离开设备

将视频文件拖到此处

或点击浏览 · MP4、WebM、MOV、AVI、MKV（最大 2 GB）

工作原理

  1. 加载视频文件：从您的设备选择任意 MP4、WebM、MOV 或 AVI 文件 · 不上传服务器。
  2. 设置剪辑点：使用时间线把手，或输入精确的起止时间定义要保留的片段。
  3. 预览剪辑：播放选定片段，在导出前确认效果。
  4. 下载片段：将剪辑后的视频以原格式直接导出到您的设备。

为什么使用视频剪辑器？

大多数视频编辑应用需要安装、订阅或上传到云服务器。此基于浏览器的剪辑器通过 WebCodecs 和 FFmpeg.wasm 完全在您的设备上处理视频 · 您的画面从不离开本机。它非常适合快速剪掉片头片尾、截取社交媒体片段、去除录制中不需要的部分，以及分享前的裁剪。如果不选择不同的输出格式，重新编码不会造成质量损失；除了设备的可用内存之外，没有大小限制。

支持的格式

剪切、修剪、分割，以及这些词为何重要

在日常用语中「修剪」、「剪切」和「分割」是可互换的。在视频工具中它们描述三种不同的操作。修剪从开头和/或结尾移除内容并保留中间部分。在编辑术语中剪切是成品编辑中两个相邻镜头之间的边界。分割把一个剪辑在选定的点上分成两个剪辑。从用户的角度，本工具执行修剪：您设置开始和结束，它保留两者之间的内容。

有趣的问题是它如何移除不需要的字节。两种根本不同的方法产生不同的文件。

Fast（流复制）vs Precise（重新编码）

流复制，即「Fast」模式，根本不看图像。它打开容器，找到对应请求时间窗口的字节范围，把这些字节逐字复制到新容器中，修复索引和时间戳，并写出结果。没有解码、没有重新编码、没有质量损失。在现代机器上，500 MB 的 H.264 文件可以用这种方法在远低于一秒内修剪，因为工作本质上是文件 I/O，不是算术。问题在于：复制操作只能在某些帧上开始和结束，特别是 I-frame：而这些不一定在您指向的位置。所以结果剪辑的开头可能向前或向后偏移零到十秒，取决于文件最初编码时使用的编解码器设置。

重新编码，即「Precise」模式，把整个受影响的部分解码回原始像素，丢弃请求开始之前和请求结束之后的帧，然后重新编码剩余部分。这产生一个在所选帧上精确开始和结束的剪辑（在行业术语中称为帧精确）代价是一次完整编码。完整编码比流复制慢数百或数千倍，并引入一代压缩损失，因为有损编解码器不是幂等的：对相同图像编码、解码和重新编码不会还给您完全相同的图像。损失在高比特率下很小，但不为零，如果同一文件被反复修剪它会累积。

对于 95% 的情况，用户在移除片头、片尾或粗略的开头和结尾材料并不在乎切割是否离指定位置半秒，Fast 路径是正确的。Precise 路径在需要切割落在特定帧上时是正确的工具：一个笑点、一个音效、一个下游编辑的同步标记。

I-frame、P-frame、B-frame 和 GOP

每个现代视频编解码器（H.264、H.265 (HEVC)、VP9、AV1）通过利用连续帧几乎是同一图像的事实来压缩视频。编解码器不是独立编码每一帧，而是完整编码一小部分帧，其余作为相对邻居的差异编码。完整帧是 I-frame（内编码）。差异帧有两种：P-frame（仅从较早帧预测）和 B-frame（双向预测编码，可以引用较早和较晚的帧）。序列「I，然后一连串的 P 和 B 帧，然后另一个 I」称为 Group of Pictures 或 GOP。在 GOP 内，没有帧可以在不参考开头 I-frame 的情况下解码。跨 GOP 之间没有依赖：播放器可以在任何 I-frame 进入文件并从那里开始解码。

这就是为什么流复制修剪受关键帧边界限制。要在非 I-frame 启动新文件，您必须解码 GOP 开头的 I-frame，然后解码每个 P 和 B 帧到您选择的点，然后开始写入，这正是 Precise 路径做的。典型的 H.264 文件使用 2 到 4 秒的 GOP 长度。FFmpeg 的 libx264 默认大约 250 帧（25 fps 约 10 秒，30 fps 约 8.3 秒）。流媒体提供商将其缩短到两秒以对齐 HLS 和 DASH 分段边界。H.265 更高效地容忍更长的 GOP，通常配置为 4 到 10 秒。VP9（libvpx）默认最大关键帧距离为 240 帧。AV1 通常落在 2-6 秒范围内。实际含义是：要求在分 1 秒 30 切割的用户可能根据文件最初编码内容，最终得到一个在分 1 秒 24 到分 1 秒 32 之间任何位置开始的流复制结果。

FFmpeg 简史

FFmpeg 由 Fabrice Bellard 于 2000 年 12 月 20 日启动，这位法国计算机科学家此前编写过 QEMU 虚拟化器和 TCC C 编译器。他以 Gérard Lantau 的笔名提交。名字来自「FF」即快进和「mpeg」即它最初设计处理的编解码器系列。架构从一开始就把编解码器实现（libavcodec）与容器解析（libavformat）分开，这就是为什么 FFmpeg 多年来如此容易扩展。Bellard 在 2004 年将维护权交给 Michael Niedermayer。该项目在 2011 年经历了一次著名的分叉，一群开发者因治理分歧分出了 Libav 项目；两个项目到 2018 年在精神上（如果不是形式上）重新合并，Libav 的大部分改进被上游到 FFmpeg。

如今 FFmpeg 是世界视频巨大部分背后的沉默基础设施，YouTube、Netflix、VLC、OBS Studio、Audacity、HandBrake、Plex 和大多数专业广播管线都在其堆栈中某处使用它。截至 2026 年，当前稳定版本在 8.x 系列。许可证是双重 LGPL-2.1-or-later 或 GPL-2.0-or-later，取决于编译时启用的可选组件。

FFmpeg.wasm：浏览器中的 FFmpeg

2020 年 11 月，一位名叫 Jerome Wu 的台湾工程师：因 Tesseract OCR 引擎的 Tesseract.js 端口而已经知名，发布了 FFmpeg.wasm 的首个版本，这是 FFmpeg 的 WebAssembly 编译，完全在浏览器内运行。他在 2020 年 11 月 4 日宣布了该项目。到 2026 年该项目已显著成熟，当前版本在 0.12 系列，并有活跃的社区分叉。npm 包现在打包核心 WebAssembly 二进制、处理主线程与运行 WASM 的 worker 线程之间消息传递的 JavaScript 包装器，以及让用户使用普通 JavaScript Blob 和 File 对象移动文件进出的虚拟文件系统。

该项目有一个臭名昭著的要求，每个第一次尝试部署它的开发者都会被它绊倒。FFmpeg.wasm 使用 SharedArrayBuffer，即用于在主线程和 worker 线程之间共享内存的 JavaScript API。在 2018 年披露 Spectre 和 Meltdown CPU 漏洞后，浏览器收紧了条件：页面必须用两个特定的 HTTP 头提供服务，Cross-Origin-Opener-Policy: same-origin 和 Cross-Origin-Embedder-Policy: require-corp，并且页面上的每个跨源资源必须通过 CORS 选择加入或来自同一源。没有这些头，SharedArrayBuffer 是 undefined，FFmpeg.wasm 不会初始化。Chrome 严格执行；Firefox 和 Edge 跟随 Chrome；Safari 从 15.2 版本开始加入。

容器格式

容器是文件包装。它不编码图像；它把编码的图像和音频与时序及元数据打包在一起。

浏览器视频 API，实际可用的内容

HTML5 <video> 元素于 2014 年 10 月 28 日成为 W3C 推荐标准，经过大约十年的开发。在 HTML5 之前，嵌入视频意味着 Adobe Flash 或 Microsoft Silverlight。该元素本身没有编辑 API，没有 video.trim(start, end) 方法，没有 video.cut()，没有内置的方式提取片段。要做超出播放、暂停和搜索的任何事情，开发者必须求助于较低级别的 API 或将 FFmpeg 编译到页面中。

Media Source Extensions (MSE) 是 W3C 规范，让 JavaScript 构造馈送 <video> 元素的字节流。2014 年达到候选推荐；YouTube 早在 2013 年 9 月在生产中使用，Netflix 从 2014 年 6 月开始。其主要用例是自适应流（它不暴露解码帧，所以它不能自己执行重新编码。WebCodecs 是较低级别的替代品）直接向 JavaScript 暴露浏览器内置的视频和音频编解码器实现，使用 VideoDecoder 和 VideoEncoder 接口。WebCodecs 在 Chrome 93 的 origin trial 之后于 2021 年 9 月 21 日在 Chrome 94 中正式发布，并已扩展到 Firefox 和 Safari。当前最先进的做法是工具在可用且编解码器受支持时使用 WebCodecs，否则回退到 FFmpeg.wasm。本工具两者都用。

社交平台长度限制，人们打开 trimmer 的原因

对基于浏览器的修剪的大量需求来自为社交平台上传准备视频，每个平台都有自己的最大长度：

这些数字随着平台迭代不断变化，但「平台 X 将拒绝您的上传如果超过 Y 分钟」的一般模式是持久的，并且是最终用户首先打开 trimmer 的最常见原因之一。

何时桌面编辑器是更好的工具

对于浏览器 trimmer 不足的用户，专业生态系统围绕几个既定的桌面应用程序展开。Apple ProRes 是 Apple 于 2007 年 4 月与 Final Cut Studio 2 一起推出的中间编解码器系列，专为编辑设计，而非交付。Final Cut Pro 最初于 1999 年由 Macromedia 发布，一年后被 Apple 收购，于 2011 年 6 月 21 日作为 Final Cut Pro X 重建并重新发布；仅限 macOS，是纪录片和广播世界大部分领域的标准编辑器。DaVinci Resolve 最初是高端色彩分级系统，于 2009 年被 Blackmagic Design 收购，并逐步重建为完整的编辑/音频后期/视觉效果/分级套件，可用于 macOS、Windows 和 Linux，免费基础版本大幅改变了编辑市场的经济学。Adobe Premiere Pro 是第三大主要玩家，主导电影和电视行业的大部分领域。这些都不适合想在发布到 TikTok 之前从手机录制的剪辑中删除前十秒的用户，这正是浏览器 trimmer 填补的空白。

为什么「不上传」在这里特别重要

基于浏览器的视频 trimmer 最重要的属性是文件不离开用户的机器。视频数据从 File 输入直接加载到 JavaScript 内存中，由浏览器进程内的 WebAssembly 处理，结果作为下载提供。没有上传，没有可以读取文件的第三方，没有随用户数量扩展的云费用，没有要编写或审计的数据保留政策。对于敏感内容（录制的会议、个人录像、由于法律或合同原因不能上传给第三方的任何东西），这是唯一合理的架构。

缺点是用户承担计算成本。在服务器农场上运行的 trimmer 可以在几秒钟内重新编码 4K 剪辑，因为它可以访问 GPU 编码硬件；在笔记本 CPU 上运行软件中的 FFmpeg.wasm 相同操作可能需要一两分钟。Fast（流复制）路径通过完全避免编码在很大程度上回避了这一点，这就是为什么它对几乎每个偶尔修剪用例都是正确的默认值。Precise（重新编码）路径仅在用户明确需要帧精度并愿意等待时才是正确的默认值。

更多问题

为什么我的 Fast 修剪开始比我要求的更早或更晚？

因为 Fast 模式（流复制）只能在关键帧（I-frame）上开始，而您请求开始之前最近的关键帧可能在一个完整 GOP 之前，根据源的编码方式，可以是 2 到 10 秒之间的任何地方。如果您需要在特定帧切割，请切换到 Precise 模式，它重新编码并精确落在所选帧上，代价是较长的等待和一点压缩损失。

为什么 Fast 修剪后音频不同步？

通常是因为切割点落在视频 GOP 内部，并且该时间戳的音频帧与视频关键帧不对齐。Fast 模式将视频开始移到最近的关键帧，但可能保持音频时间戳不变，产生偏移。标准 FFmpeg 修复是 -avoid_negative_ts make_zero 标志，它重新基准化所有时间戳，使第一个为零。如果同步至关重要，Precise 模式重新采样音频以与新开始对齐，避免这类问题。

我可以导出与输入不同的格式吗？

对于格式转换，Video Converter 工具是专门构建的，并暴露更多选项。Trimmer 针对相同编解码器、相同容器的情况进行了优化（Fast 模式完全保留原始编码）或在 Precise 模式下重新编码为一小组对 web 友好的输出。重新编码总是花费 CPU 时间和一代质量损失；如果您只需要在不重新编码图像的情况下更改容器，ffmpeg -c copy 等效工具是正确的工具。

为什么 AVI 输入有效但 AVI 输出无效？

AVI 早于大多数现代编解码器功能（B-frame 笨拙，4 GB 以上音频同步脆弱，索引格式有限），现代工具通常仅将其视为传统输入格式。AVI 输入正常读取；输出默认为 MP4 或 WebM，这些是积极维护的 ISOBMFF/Matroska 系列，在每个现代浏览器和播放器中播放。

相关工具

视频转换器 GIF 制作器 视频 → 文字 音频剪辑