第一次为客户端转换屏幕录制时，我按照每个人的方式进行：将 MOV 放入转换器中，等待 11 分钟，然后发送 MP4。 该文件小了 40%，而且明显更柔软，客户问演示中的文本为什么看起来很模糊。 答案是首先不需要转换。 该 MOV 中的视频已经是 H.264，这正是 MP4 的支持。 11 分钟的重新编码已经放弃了质量，以生成一个在大约两秒钟内可以字节相同的文件。 这就是背后的整个想法 视频转换器 上 Toolz.dev，值得了解您使用的任何工具。
TL;博士: 大多数 MOV 文件已经包含 H.264 视频和 AAC 音频，这与 MP4 包含的内容相同，因此在它们之间进行转换根本不需要重新编码。 流被复制到一个新的容器中，一个称为 remuxing 的过程。 它需要几秒而不是几分钟，不会损失任何像素，因为没有像素被解码或重新压缩。 工具z 视频转换器 默认情况下，只有在格式需要时才会重新编码，并且它通过编译为 WebAssembly 的 WebAssembly 编译为 WebAssembly 的 WebAssembly，因此视频永远不会上传。
什么是容器，为什么它很重要？
视频文件有两层，几乎所有关于视频转换的混乱都来自于混合它们。
的 笼 是包装器。 它保存流，记录它们的长度，每帧开始的位置，音轨的语言以及显示的缩略图。 MP4、MOV、WebM、AVI 和 MKV 是容器。 文件的扩展名命名为容器，而不是视频。
的 编解码器 是内部压缩。 H.264、H.265、VP9 和 AV1 压缩图片。 AAC、OPUS、MP3 和 FLAC 压缩声音。 编解码器决定了文件是否在给定设备上播放，需要时间来改变。
一旦你分开了这两个想法，有用的问题就不再是“这是什么格式？”变成“我要改变哪一层？”改变容器是便宜的。 更改编解码器是昂贵且有损的。 一个不区分它们的工具每次都会向你收取昂贵的操作费用。
为什么 MOV 到 MP4 几乎是即时的？
因为 MOV 和 MP4 是近亲。 文件格式是 ISO 基础媒体文件格式的基础，MP4 是建立在它的基础上的，因此两个容器以几乎相同的方式组织它们的数据。 其中的流通常是相同的流：iPhone 录制、Mac 屏幕捕获、数码单反剪辑和 Premiere 导出通常都可以使用 AAC 音频生成 H.264 视频，无论它们是将其包装在 .mov 还是 .mp4 中。
所以转换是一个 混音：读取每个流的开始和结束的位置，将这些字节写入一个新容器，写一个新的索引。 没有帧被解码。 没有检查像素。 输出是不同包装中的相同视频数据，并且在严格意义上是解码帧是逐位相同的，它是无损的。
在实践中，这意味着一个两分钟的剪辑在大约一秒钟或更长时间内完成，文件大小几乎不会移动，因为视频数据没有改变。 一个转换器需要几分钟的时间并交还一个较小的文件，它重新编码了它，并且大小下降是您不再拥有的质量。
这是每条路径适用的时候。
| 来源 | 目标 | 发生了什么 | 速度 | 品质成本 |
|---|---|---|---|---|
| MOV (H.264/AAC) | MP4 | remux，复制流 | 秒 | 没有 |
| MP4 (H.264/AAC) | 搬 | remux，复制流 | 秒 | 没有 |
| 移动或 MP4 | 网页 | 再 - 编码到 VP9/Opus | 分钟 | 有些，取决于设置 |
| 任何视频 | 动图 | 再 - 编码，调色板减少到256种颜色 | 分钟 | 严肃的，设计上 |
| 动图 | MP4 | 再 - 编码为 H.264 | 秒到一分钟 | 小，一般看不见 |
什么时候必须重新编码？
三种情况，只有三种。
目标容器无法容纳编解码器。 WebM 接受 VP8、VP9 和 AV1 用于视频和 Vorbis 或 Opus 的音频。 它不接受 H.264。 所以MP4到WebM总是一个真正的转换，它需要实时的。
H.264 包装器中的源编解码器不是 H.264。 一个 ProRes 从相机、DV 捕捉、一个旧的 DivX AVI 移除：那些在某些情况下可以携带 MP4 的编解码器，但大多数玩家会拒绝。 转换它们意味着解码和重新压缩。
你故意改变画面。 降低分辨率，降低比特率，更改帧速率。 没有重新压缩视频就无法使视频更小，这就是为什么缩小文件与更改其格式不同的工作。 为此，使用 视频压缩器，正是因为压缩和转换是人们合理混淆的不同操作。
为什么转换为 GIF 比听起来更糟糕？
整个图像最多可容纳 256 种颜色。 也就是说，在 GIF89A 规格 在 1989 年，没有编码器可以解决它。 因此，从视频到 GIF 的每次转换都必须选择源可能包含的 1670 万种颜色中的 256 种颜色。
一帧一帧地完成，每帧选择自己最好的256。 结果是同一件衬衫在连续帧中的颜色略有不同，整个画面似乎爬行和闪烁。 这是对视频到 GIF 输出的最常见的抱怨，它完全是每帧调色板的伪影。
修复是一个两遍编码：首先扫描整个剪辑，构建一个服务所有它的调色板，然后根据共享调色板对每一帧进行编码。 爬行消失，因为颜色停止移动。 Toolz 转换器运行两个通道，这就是为什么它的 GIF 比单通道工具需要更长的时间并且看起来更稳定。
第二个惊喜是大小。 GIF 存储整个帧而不是它们之间的差异，没有任何使现代视频编解码器高效的运动补偿。 一个 400 KB 作为 MP4 的 5 秒剪辑通常是 4 MB 作为 GIF。 这导致转换比人们意识到的更频繁地做。
我应该将gif转换为mp4吗？
几乎总是，是的。 与 H.264 编码的相同动画通常是大小的十分之一，在大型 GIF 停顿或被限制的移动浏览器上内联播放，并支持硬件解码，因此它不会加热手机。 正是因为这些原因，每个主要的社交平台都会悄悄地将您上传的 GIF 转换为视频，这是一个合理的信号，说明哪种格式适合这项工作。
一个细节决定了转换是否有效。 H.264 需要均匀的像素尺寸，因为 标准 组织色度采样，GIF 经常有奇怪的：601 像素宽的 GIF 是完全正常的。 一个编码器传送的奇数维度要么直接失败，要么用一个神秘的消息彻底失败，要么是默默地填充帧。 在这里，转换器将大小舍入到编码前的最接近的偶数，这是一种没有人能看到的单像素裁剪以及文件和错误之间的区别。
视频是否会在任何地方上传？
不，这是改变您使用它的方式的部分。 转换贯穿 编译为 WebAssembly 的 ffmpeg，在浏览器选项卡中执行。 文件从您的磁盘读取到页面内存中，在那里转换，并作为下载返回。
这具有三个实际的后果：
- 没有什么能离开你的机器。 打开 DevTools，切换到网络面板，转换文件，然后观看：没有请求携带视频。 对于 NDA 下的视频，未发布的产品演示，其中任何不同意第三方上传的人的视频，这是可用和不允许的区别。
- 没有队列，也没有尺寸上限。 您不是在等待其他人的工作，也没有计划将您限制在 100 MB。 真正的限制是您的浏览器选项卡的内存，在普通笔记本电脑上可以舒适地处理数百兆字节的文件。
- 第一次运行比其他运行慢。 ffmpeg WebAssembly 捆绑包必须下载一次，即几秒钟。 之后，它被缓存，后续的转换立即开始。
交易是诚实的：具有专用编码器的服务器在非常大的文件上更快。 对于大多数人转换的剪辑，上传和下载的往返时间比编码节省的时间更多。
哪些设置有所不同？
对于 remux，没有。 没有什么可以配置的，因为没有重新决定。
对于重新编码，两个。
决议 比任何其他设置都做得更多。 将宽度和高度减半像素数，文件大致跟随。 从 1080p 到 720p 是最有效的变化，在手机屏幕上很难看到差异。
比特率或质量目标 是另一个。 大多数工具将其作为质量滑块而不是数字来揭露，这是正确的调用：固定的比特率浪费了一些简单的场景并饿死了复杂的，而一个质量目标则花费了每个场景需要的东西。
帧速率是人们达到的第三个杠杆，通常不应该。 将帧的速度降低到 15fps 的速度减半，但使运动明显停滞不前，并且节省的分辨率比分辨率变化更小，因为无论如何连续的帧相互压缩很好。
# What a remux looks like at the command line. -c copy is the whole trick:
# copy the streams, do not decode them.
ffmpeg -i input.mov -c copy output.mp4
# Compare to a real conversion, which decodes and re-compresses every frame.
ffmpeg -i input.mov -c:v libx264 -crf 23 -c:a aac output.mp4
第一个命令在读取文件所需的时间大约完成。 第二个需要视频，只要视频很复杂。 任何值得使用的基于浏览器的转换器在内部也有同样的区别，并且 视频转换器 做。
容器更改时音频会发生什么？
在 remux 上，什么都没有。 AAC 轨道与视频一起跨字节复制，这就是 MOV 到 MP4 转换无法降级声音的原因：相同的压缩音频数据最终会出现在新包装中。
在重新编码时，它取决于目标。 WebM 不能携带 AAC，因此将音频重新压缩到 Opus，这是应用于已经有损音频的一个有损步骤。 它很少在语音上听到，偶尔在音乐中可以听到，有很多高频细节，比如钹。
有时音频是您唯一想要的。 录制的采访，但将作为播客、您想要的讲座在手机上发布，您正在抄写的配乐。 转换整个视频然后丢弃图片是慢路。 那个 音频提取器 直接拉出声音，对于 MP4 和 MOV 源，它可以将现有的 AAC 轨道复制到 M4A 中，而无需重新编码，这与 Remux 完全相同。 如果您拥有的文件已经是音频并且只有格式错误，则 音频转换器 处理那一面。
值得了解的一件事：视频文件可以携带多种音轨，用于不同的语言或单独的评论。 大多数基于浏览器的工具，包括这个工具，都可以使用第一条轨道。 如果您的源代码超过一个并且您需要一个特定的，那么这是一个带有显式流选择器的命令行的ffmpeg的作业。
您应该发送哪种格式，以及发送给谁？
大多数转换工作实际上是这个问题的伪装。 诚实的答案是，带有 H.264 视频和 AAC 音频的 MP4 是比任何其他组合更频繁的正确选择，因为它是唯一一种几乎无处不在地播放的组合。
| 它要去哪里 | 派遣 | 为什么 |
|---|---|---|
| 客户、同事、电子邮件 | MP4 (H.264/AAC) | 这十年来，每部手机、笔记本电脑和浏览器都能播放 |
| 您控制的网站 | MP4，以 WebM 作为第二个来源 | WebM在相同质量上较小，MP4是后备 |
| 社交平台 | MP4 | 他们重新编码您发送的任何内容，因此请给他们最干净的输入 |
| 编辑时间表 | 原始文件 | 每次编辑之前的转化成本质量您无法取回 |
| 带尺寸上限的聊天应用程序 | MP4，压缩 | 改变大小，而不是格式 |
| 内联在电子邮件签名或自述文件中 | MP4 如果允许，仅在 GIF 时才 | GIF是拒绝视频的地方的后备，而不是一个选择 |
最省心的一行是编辑一行。 人们在导入之前转换素材，失去质量，然后编辑和导出，失去更多。 如果时间轴接受原件，请给它原件并在最后转换一次。
另一个常见的错误是当你打算压缩时转换。 “此文件对于上传限制来说太大”不是格式问题。 将 MOV 更改为 MP4 将无济于事，因为视频数据是相同的。 使其更小意味着故意重新编码它，这就是 视频压缩器 是用于或修剪您不需要的零件 视频修剪器 首先。 30 秒你切割是 30 秒，没有人需要编码，它超过了任何质量设置。
这与转换图像相比如何？
图像存在相同的容器与编解码器拆分，其结果相同：一些转换便宜且无损，其他则丢弃信息。 将 PNG 转换为 BMP 会保留每个像素；将其转换为 JPEG 不会。 那个 图像格式转换器指南 覆盖那一面，并且 图像压缩指南 覆盖了比这里更深入的有损与无损的区别。
实际的区别是规模。 一张糟糕的图像转换会花费您一张照片。 糟糕的视频转换花费了您 11 分钟的时间，而客户会询问文本为什么看起来很模糊。
普通问题
MOV 或 MP4 更好吗？ 对大多数目的来说，它们都不是，因为它们通常包含相同的视频。 MP4 具有更广泛的设备支持，因此它是共享的更安全默认值。 MOV是Apple工具产生的，它带有一些MP4所没有的专业编解码器。
为什么我转换的文件变大了？ 您转换为效率较低的编解码器或容器或 GIF。 remux 永远不会有意义地改变大小；一个较旧的编解码器的编码可以很容易地增长它。
为什么我的 MP4 在旧设备上无法播放？ 容器很好；编解码器不是。 MP4 包装器中的 H.265 流不会在仅解码 H.264 的硬件上播放，即使该扩展看起来很熟悉。 这是最重要的层次的情况。
