首页 > 解决方案 > ffmpeg 输出文件小于输入文件

问题描述

我正在使用 ffmpeg 在 Python 脚本中将视频旋转 90 度或 180 度。它工作得很好。但是,我很好奇为什么输出文件的字节数比输入文件少。

以下是我使用的命令:

180度:

ffmpeg -i ./input.mp4 -preset veryslow -vf "transpose=2,transpose=2,format=yuv420p" -metadata:s:v rotate=0 -codec:v libx264 -codec:a copy ./output.mp4

90度:

ffmpeg -i ./input.mp4 -vf "transpose=2" ./output.mp4

例如,GoPro Hero 3 MP4 文件最初为 2.0 GB。生成的输出文件为 480.9 MB。另一个 GoPro 文件是 2.0,其生成的文件是 671.5 MB。这可能是因为 GoPro 文件是 2.0 但包含空白空间,有点像某些 NTFS 文件系统如何制作最小的 4k 文件,即使其中的字节数较少?

如果这不是 GoPro Hero 3,我如何将文件旋转 90 或 180 度但确保输出文件大小相同?或者,是否会丢失数据?数据丢失是否与格式有关?

请注意,视频的质量似乎没有损坏,这很好。所以,我有兴趣更多地了解为什么会发生这种情况,然后我可以阅读与此相关的 ffmpeg 文档部分。

谢谢!

标签: ffmpeggopro

解决方案


比特率从一开始就被忽略

ffmpeg将输入完全解码为未压缩的原始视频和音频(流复制时除外- 更多信息见下文)。输入格式或比特率无关紧要:它适用于所有格式。然后编码器从这些原始的解码帧开始工作。见图表

H.264 与 H.264

您的输入和输出都是 H.264。诸如 H.264 之类的格式是由编码器创建的。任何人都可以制作编码器。然而,并不是所有的编码器都是平等的。给定相同的输入,一个 H.264 编码器的输出可能与另一个 H.264 编码器的输出具有相同的质量,但比特率可能小几倍。

GoPro H.264 编码器可在硬件有限的平台上工作。这意味着为了速度和质量而牺牲比特率(文件大小)。x264 是终极的 H.264 编码器:没有什么能比得上它的质量比特率。

无需重新编码即可旋转

您可以同时流式复制(重新复用)和旋转。旋转由元数据/sidedata 处理:

ffmpeg -i input.mp4 -metadata:s:v rotate=90 -c copy output.mp4

缺点是您的播放器/设备可能会忽略旋转,因此您可能必须使用需要重新编码的过滤器进行物理旋转,因此无法使用流复制。


推荐阅读