我有 14 张 PNG 图像（这里但并不重要），我想将其以 15 fps 的速度放入 2 分钟的循环中。
Photoshop CS3 似乎是实现这一目的的最佳工具，因此我将它们作为图像序列*打开，然后执行文件 -> 导出 -> 渲染视频并导出为 AVI。
但是我只有 14 张图片，所以我使用了一个脚本（这里但并不重要）将它们复制为 1805 张图像（约 2 分钟的视频）。
当我重复 Photoshop 步骤时，生成的文件大小为 55 MB，而不是原来的 429 KB。
视频实际上需要的是前 14 个文件链接然后重复（无损）。
我可以使用哪种编解码器来实现这一点？我如何使用该编解码器？（我使用的是 OS X Lion）。
我需要的是视频格式，而不是 GIF 格式。
*（打开 -> 第一个文件 -> 勾选图像序列）
答案1
无损压缩意味着图像/视频/数据在压缩时没有损失，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/
答案2
如果您要将视频发布到网络上，则可以使用 HTML5 的视频循环属性： http://www.w3schools.com/tags/att_video_loop.asp
例如http://cordes.ca/Working/clip.html，循环播放音乐剧《Working》中一小段 x264 编码的慢动作片段。
也可以看看将视频转换为 apng/png？
据我所知，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 无法播放动画 webp，因此请使用 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 个参考帧排列整齐，从而让它可以继续引用它们而无需重新编码。我对解码器图片排序以及哪些帧被保留为参考不太了解，因此无法理解原因。