用于循环图像序列的无损压缩编解码器

我有14个PNG图像（这里但是并不重要）我想以15 fps的速度进行2分钟的循环。

Photoshop CS3似乎是最好的工具，所以我打开它们作为图像序列*并做了文件 - ＆gt;出口 - ＆gt;渲染视频并导出为AVI。

但是我只有14张图片所以我使用了一个脚本（这里但并不重要）将它们复制为1805张图像（约2分钟的视频）。

当我重复Photoshop步骤时，生成的文件大小为55 MB而不是原始的429 KB。

所有视频实际需要的是前14个文件链接然后重复（无损）。

我可以使用哪种编解码器来执行此操作？我该如何使用该编解码器？（我在OS X Lion上）。

我需要它作为视频，而不是GIF。

_{*（打开 - ＆gt;第一个文件 - ＆gt;勾选图像序列）}

— gadgetmo
source

你需要它完全损失吗？或者一个质量非常好的视频，正常的人眼看不到足够的损失？

— d33pika

图像的大小是多少？为什么你期望它是429KB？

— d33pika

@ d33pika 429 KB是我导出前14个图像为AVI时的大小。它根本不需要高质量，它只是一个动画GIF。我建议无损，因为它只需要前14个图像，其余的都是相同的。

— gadgetmo

@ d33pika将55mb文件压缩为具有最高压缩选项的zip，它将其降低到44mb。我尝试了7zip，它降到了327KB。

— gadgetmo

Answers:

无损压缩意味着压缩图像/视频/数据时没有损失， http://en.wikipedia.org/wiki/Lossless_compression 。示例：zip / gzip。这并不意味着重复文件。要使用ffmpeg在此链接中按照以下命令创建图像视频： https://ffmpeg.org/trac/ffmpeg/wiki/Create%20a%20video%20slideshow%20from%20images

在Mac OS X上，您可以按照以下步骤安装ffmpeg： http://www.markszulc.com/blog/2012/09/03/installing-ffmpeg-with-h264-support-on-mac-os-x-mountain-lion/

— d33pika
source

如果您要在网络上放置视频，则可以使用HTML5的视频循环属性： http://www.w3schools.com/tags/att_video_loop.asp

例如 http://cordes.ca/Working/clip.html ，它从音乐作品中循环一个短的x264编码的慢动作片段。

也可以看看将视频转换为apng / png？

AFAICT，没有ffmpeg支持的视频容器格式（例如mp4，mkv，avi，nut，ogm），这些格式在容器元数据中有循环计数。所以你是对的，你必须将重复的输入帧序列馈送到视频编解码器，并希望编码器能够找到大量的冗余。

您可以调用gif，mng和webp视频格式，因为您可以在其中存储任何帧序列。但是，除了为其设计的单个静止图像编解码器之外，这些容器格式都不支持任何内容。它们都支持循环动画，可能都是非循环计数，可以提供你想要的2分钟。

ffmpeg -framerate 15 -loop 1 -i src/b93-'%d.png' -frames 1805 -preset veryslow -crf 23 -movflags +faststart party.mp4
2.5M    party.mp4  # see [1] for the encode log

ffmpeg -framerate 15 -i src/b93-'%d.png' -loop 128 containerloop.gif
684K    containerloop.gif
...
172K    containerloop.webp

ffplay无法播放动画网页，因此请使用vwebp或google chrome。

我不知道为什么你会想要这个。如果你有一个GIF动画，那就玩吧。 ffplay -ignore_loop 0 containerloop.gif 将循环2分钟（因为我用有限的循环计数制作了gif）。

如果您正在为视频编辑项目制作剪辑，我想这是有道理的。

[1] x264具有16个参考帧，最多8个b帧，输入yuv444版本的输入。

frame= 1805 fps=7.2 q=-1.0 Lsize=    2540kB time=00:02:00.20 bitrate= 173.1kbits/s    
video:2518kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.872666%
[libx264 @ 0x1a787e0] frame I:8     Avg QP:21.35  size: 18650
[libx264 @ 0x1a787e0] frame P:515   Avg QP:16.45  size:  1044
[libx264 @ 0x1a787e0] frame B:1282  Avg QP:25.79  size:  1475
[libx264 @ 0x1a787e0] consecutive B-frames:  0.7% 13.9%  0.8% 84.2%  0.0%  0.0%  0.0%  0.4%  0.0%
[libx264 @ 0x1a787e0] mb I  I16..4:  3.4% 64.4% 32.2%
[libx264 @ 0x1a787e0] mb P  I16..4:  0.9% 15.9%  0.9%  P16..4: 80.9%  0.3%  0.6%  0.0%  0.0%    skip: 0.5%
[libx264 @ 0x1a787e0] mb B  I16..4:  0.3%  2.8%  0.5%  B16..8:  4.8%  3.3%  1.9%  direct: 1.2%  skip:85.2%  L0:35.1% L1:64.0% BI: 0.9%
[libx264 @ 0x1a787e0] Weighted P-Frames: Y:75.0% UV:75.0%
[libx264 @ 0x1a787e0] ref P L0:  1.3%  0.1%  0.7%  0.1%  0.3%  0.0% 24.1% 41.7% 27.4%  0.1%  0.0%  0.0%  0.0%  0.4%  3.5%  0.4%
[libx264 @ 0x1a787e0] ref B L0:  8.7%  1.6%  0.8%  0.1%  0.7%  1.2% 74.6%  2.1%  0.0%  0.1%  0.0%  0.0%  0.4%  9.5%
[libx264 @ 0x1a787e0] ref B L1: 99.5%  0.5%
[libx264 @ 0x1a787e0] kb/s:171.40

注意，平均P帧大小小于平均B帧。

无损模式下的x264，rgb或yuv，无法保持其16个参考帧的排列方式，使其能够在不重新编码的情况下继续引用它们。 IDK足够关于解码器图片排序以及确切地保留哪些帧作为参考以理解原因。

— Peter Cordes
source