将两个视频文件端到端地放置听起来像是世界上最便宜的操作，大约五分钟我相信它。 然后我使用最快的方法将一个 1280x720 的剪辑以 30fps 的速度加入到 640x480 的剪辑中，使用最快的方法，复制流并没有重写任何内容。 它产生了一个文件。 该文件声称长为 11 点 9 九 六秒，当两个夹子加起来为 11 时，容器表示 1280x720，而流的第二半部分为 640x480，并且 Muxer 打印了关于第二个夹子的每帧重写时间戳的警告。 加入视频的一切都来自于为什么会发生这种情况。
TL;博士: 廉价连接仅在两个文件已经就编解码器、分辨率、帧速率和时基达成一致时才有效，而来自两个设备的素材从未实现。 诚实的路由解码两者并编码一个新文件，速度较慢并产生播放的内容。 在这里测量：复制方法报告了11.996秒的11秒镜头并声明了错误的分辨率；重新编码在0.63秒内以一个一致的1280x720 生成正好11.000秒。 不同尺寸的夹子必须先安装在一帧中，否则连接会被完全拒绝。 那个 视频编辑器 在浏览器中完成所有这些，最多八个剪辑和三十分钟。
为什么两个剪辑不能只是粘在一起？
因为视频文件不是带有标题的图片流。 它是一个保存编码流的容器，并且编码带有状态。
H.264 通过将大多数帧描述为与其他帧的差异来压缩。 关键帧是独立的；它是相对于之前定义的，直到下一个关键帧为止。 解码器还需要流的参数集，描述分辨率、颜色格式和配置文件，它拥有将每个数据包上的数字转换为秒的时间基。
两个设备制作的两个文件都不同意。 不同的分辨率意味着不同的参数集。 不同的帧速率通常意味着不同的时基。 即使是同一部手机的两个剪辑，相隔一年录制，也可能因相机应用程序更改了其编码器设置而有所不同。
连接字节会给你一个流，它的解码器在标题中被告知一件事，然后再交出一个中途。 有时玩家会应对。 它通常显示第一个剪辑并停止，或者将第二个片段播放为彩色噪音。
快速方法产生了什么？
一个文件，一堆警告和一个错误的持续时间。
ffmpeg's concat 解复用器 流复制是每个“只是加入他们”的在线答案推荐的方法，当输入匹配时，它确实是正确的工具。 指向我成功退出的两个不匹配的剪辑，这是它交还的东西：
| 测量 | 预期 | 生产的 |
|---|---|---|
| 龄 | 11.000 秒 | 11.996 秒 |
| 宣布决议 | 一值，正确 | 1280x720 为 640x480 的流 |
| 时间戳警告 | 没有 | 每帧第二个剪辑 |
警告都说同样的话：
Non-monotonic DTS; previous: 90981, current: 76133; changing to 90982.
This may result in incorrect timestamps in the output file.
第二个剪辑的时间戳从零重新启动，因为它们应该在自己的文件中，并且复用器不会写入时间戳的流向后退。 因此，它发明了新的，一次一帧，实际时间和所发明的时间之间的累积差异是额外秒的来源。
ffmpeg 之后仍然可以对两个半部分进行解码，因为 ffmpeg 具有异常的容忍度。 浏览器不是。 这是在您的机器上播放的文件，并显示一个黑色的矩形供查看者使用。
通过过滤器图表连接的成本是多少，它会买什么？
它需要一个完整的解码和编码。 它购买正确的文件。
不是复制流，而是将每个输入解码成帧，帧被修剪并连接到一个过滤器图中，并从结果中编码一个新流。 每一帧都经过一个解码器和一个编码器，这是真正的工作。
它所买的是输出有一个编解码器、一种分辨率、一个帧速率和一组连续的时间戳，因为它是一次性地从头开始编码的。 在同一两个剪辑上：
| 测量 | 拷贝方法 | 过滤器图表 |
|---|---|---|
| 龄 | 11.996 秒 | 11.000 秒 |
| 决议 | 声明 1280x720，变为 640x480 | 1280x720 全程 |
| 框架 | 305 | 305 |
| 出口时间 | 瞬间 | 0.63 秒 |
| 尺寸 | 较小 | 2.1 MB |
在 11 秒的输出上运行 0.63 秒的工作，在运行 ffmpeg 的桌面上。 在浏览器选项卡通过 WebAssembly 的速度要慢好几倍，这是诚实的交易，也是剪辑数被上限的原因。
为什么每个剪辑都需要重新定位其时间戳？
因为过滤图中的连接会连接流，并且流的时间戳是绝对的。
每个剪辑的帧到达从它们自己的文件的开头测量的携带时间。 从剪辑中间修剪一个部分，这些框架仍然说“这发生在 42 秒”。 将它们加入到一个在 6 秒结束的剪辑中，您的流从 6 跳到 42 秒，中间没有 36 秒。
setpts=PTS-STARTPTS 从每一帧中减去每个剪辑自己的开始，因此每个剪辑在连接之前从零开始。 音频等价物是 asetpts。 没有它们，输出会播放第一个剪辑，然后是长时间的冻结，然后是第二个。 这是手写的ffmpeg join命令中最常见的一个错误，它是静默的：文件是有效的，持续时间是错误的。
当剪辑的大小不同时会发生什么？
加入被拒绝，直到最近，拒绝才是这里的全部故事。
的 连接过滤器 比较其输入，如果视频尺寸或示例宽高比不同意，则不会运行：
Input link in0:v0 parameters (size 640x480, SAR 1:1) do not match the
corresponding output link in0:v0 parameters (1280x720, SAR 1:1)
Failed to configure output pad on Parsed_concat_8
那是中止，而不是警告：没有文件被生成。 两部手机或一个手机夹和一个屏幕录制正是触发它的情况，这也是人们加入剪辑的普通原因。
音频不需要这样的帮助，这是值得了解的，因为它是违反直觉的。 同一图表将 44.1 kHz 单声道连接到 48 kHz 立体声无抱怨，并生成了一个精确的 11.000 秒文件。 只有视频方面是严格的。
解决方法是在整个时间线中设置一帧，并在加入之前将每个剪辑都装入其中。 高度来自您选择的输出分辨率，或保留源分辨率时的第一个剪辑，宽度遵循剪辑的纵横比，因此肖像素材的时间线保持纵向。 然后将每个剪辑缩放以适合该框架内并填充以填充它：
scale=1280:720:force_original_aspect_ratio=decrease,
pad=1280:720:(ow-iw)/2:(oh-ih)/2,setsar=1
装配而不是填充意味着不同形状的夹子是用信箱而不是拉伸的，当 4:3 的剪辑遇到 16:9 的时间线时，这是两个邪恶中的一个较小的部分。 setsar=1 不是装饰：过滤器比较了样本纵横比以及像素尺寸，因此两个剪辑的大小可以相同，但仍然被拒绝。
两个维度都四舍五入到偶数，因为 H.264 4:2:0 的颜色在每个方向上以半分辨率存储颜色，并且无法编码奇数宽度或高度。
为什么只有八个剪辑和三十分钟？
因为每个剪辑在浏览器选项卡中需要一个解码传递，并且该选项卡具有固定数量的内存。
八个输入意味着八个解码器针对同一个滤波器图运行，加上编码器，加上内存中的每个源文件，因为没有磁盘可供流式传输。 30 分钟的输出是编码时间过长的时间点，人们认为页面已挂起。
两种限制都不是格式的规律。 两者都是浏览器构建停止的行，它们是预先声明的，而不是在标签崩溃到导出四十分钟时发现。 短于十分之一秒的剪辑也被拒绝，因为下面它不提供帧和 FFmpeg 错误而不是警告。
对于更大的任何东西，这是错误的工具，桌面编辑器是正确的。
这里的修剪与修剪器有何不同？
连接内的修剪是框架准确的，而且不需要额外的费用。
专用 视频修剪器 提供一种快速模式，可以复制流，只能在关键帧上进行切割，这就是为什么修剪开始有时会提前十秒钟降落的原因。 它的指南 详细介绍了为什么。
这种贸易在这里不存在，因为无论如何，出口都在重新编码一切。 修剪发生在过滤器图表上，在解码帧上，因此在 4.3 秒处进行切割是 4.3 秒的切割。 您可以获得免费的帧精度，作为您已经支付的成本的副作用。
因此，如果您想要修剪一个剪辑而仅此而已，Trimmer 的快速模式会更快。 如果您要加入任何内容，请在此处修剪。
速度变化对音频有什么影响？
必须单独处理，算术与视频不同。
视频速度是时间戳操作： setpts=PTS/2 将每一帧的演示时间减半，并且框架本身是不变的。 音频不能那样工作，因为播放速度的速度两倍会使音高提高一个八度。 那个 atempo 改为过滤重新采样，保持音高并改变持续时间。
atempo 在其大部分生命周期的一次通行证中仅接受 0.5 到 2.0，因此 4x 变化被构建为两个 2 次传球和 0.25 倍的变化，因为两个 0.5x 传球。 目前的建筑提高了上限，FFMPEG 8.1 的范围为 0.5 到 100。 测量在一个夹子上，一个单一的 atempo=4 和一个链式 atempo=2,atempo=2 降落11毫秒。
链仍然是构建的，因为 WebAssembly 核心是在运行时而不是固定到版本的，并且在每个发布过过滤器的构建上乘法传递都是正确的。 提供的速度范围，0.25x 到 4x，是结果仍然是编辑而不是新颖性。
MP4 还是 WebM？
MP4 除非你有特定的原因，而且原因几乎总是许可证而不是质量论证。
| MP4 | 网页 | |
|---|---|---|
| 视频编解码器 | 264 | 视频 |
| 音频编解码器 | 空中交通管制 | 作品 |
| 参与 | 万事 | 浏览器，大多数现代播放器 |
| 在选项卡中编码速度 | 更快 | 慢得多 |
| 尺寸相似的尺寸 | 更大 | 较小 |
VP9 以相同的感知质量生成较小的文件，并且它是免版税的，这对某些项目很重要，对其他项目根本不重要。 ffmpeg 自己的 VP9 编码指南 对速度成本直言不讳。 它不是什么是快。 这里的 WebM 路径在具有实时截止日期的更高 CRF 处运行，并且 cpu-used 5，这是桌面编码会考虑的设置，因为没有它们，选项卡中的 VP9 编码需要足够长的时间来感觉破碎。
MP4 路径使用 -preset veryfast 在 CRF 23 与 yuv420p，加 -movflags +faststart，将索引移动到文件的前面，以便在下载时播放，而不是仅在之后播放。
出口会有多大，需要多长时间？
大小是可以从分辨率中预测的。 时间是无法预测的。
因为导出总是重新编码，所以源文件的大小告诉你结果很少。 显示的估计值来自输出高度：大约 5 Mbps，1080p，2.5，720p，比 1.2，WebM 降落在 MP4 数字的 70% 左右，音频增加了 128 kbps，除非静音。
这是一种估计，被标记为一个，因为内容比任何公式都重要。 静态采访镜头和手持式平底锅以相同分辨率和相同的 CRF 几倍不同，因为 CRF 以质量水平为目标，并花费任何比特率。
时间取决于您的机器、分辨率、剪辑数量以及选项卡是否有其他事情要做。 原生的ffmpeg在0.63秒内运行在管理的11秒输出上；预计浏览器会比这慢几倍，并期望WebM再次变慢。
这不做什么
它连接、修剪、重新排序、缩放、改变速度和丢弃音频。 这就是整个功能集，它与视频编辑器之间的差距值得明确。
没有过渡，没有标题，没有音乐曲目，没有颜色校正，没有裁剪，没有每个剪辑音量，没有关键帧的任何东西，没有预览完成的时间线。 每个剪辑都被修剪和放置，一组输出设置应用于所有剪辑，结果被编码。
这涵盖了一项真实而常见的工作：需要成为一个文件的几张录音，以正确的顺序修剪到有用的部分，以某种尺寸的尺寸接受。 对于任何涉及创造性决定的事情，请使用编辑器。
剪辑的顺序是什么，你能改变它吗？
您添加它们的顺序，是的，每个剪辑上都有向上和向下按钮。
重新排序是列表操作，而不是视频：移动剪辑会更改其在过滤器图中占用的输入索引，并且在导出运行之前没有重新读取或重新解码。 因此，移动是即时的，无论文件大小，您都可以免费重新排列时间线。
按钮而不是拖放是最多八个项目列表的深思熟虑的选择。 每个都带有一个标签，命名它移动的剪辑，因此顺序可以通过键盘更改和屏幕阅读器可读，这两种拖动手柄都没有给你大量额外的工作。
导出前值得检查的是序列的方向。 同一事件的几条录音通常按字母顺序从文件选择器到达，这是相机文件名的发生顺序，并不总是产生录音的顺序。
为什么会在浏览器中运行？
因为素材通常是你不想上传的那种，工作不需要服务器。
这里的每一个操作都是ffmpeg和ffmpeg 编译成 WebAssembly。 文件从您的磁盘中读取到选项卡中，在那里解码，在那里加入，在那里编码，并作为下载回交。 没有上传，没有队列保存您的素材，也没有您无法控制的机器上的副本。
人们加入的剪辑是采访、咨询、家庭录音、内部软件的屏幕截图、禁运的草稿。 通常的替代方法将数百兆字节上传到免费服务，将其转换为您一无所知的硬件，并将其保留在没有人阅读的条件下。
成本是八个剪辑和三十分钟的上限，以及比桌面级的编码慢的编码。 两者都在您开始之前说明，这是值得采取的交易。
