如何使用FFMPEG从一系列1000幅PNG图像中创建未压缩的AVI？
我使用以下命令将input.avi文件转换为一系列PNG帧：
ffmpeg -y -i input.avi -an -vcodec png -s 1024x768 pic%d.png`
现在，我需要知道如何从所有这些PNG帧中制作未压缩的AVI视频。我尝试了这个：
ffmpeg -i pic%d.png -y -f avi -b 1150 -s 1024x768 -r 29.97 -g 12 -qmin 3 -qmax 13 -ab 224 -ar 44100 -ac 2 test.avi
但是，相对于原始AVI，最终的视频质量下降了很多。
Answers:
有几种方法可以从中获取“未压缩的” AVI ffmpeg，但我怀疑您实际上是在说“无损”。正如您将看到的，这两个术语的定义都有相当大的回旋余地。
我将以720p HD版本的Big Buck Bunny来结束本次讨论，因为它是免费提供的视频，我们所有人都可以对其进行测试并获得可以比较的结果。1280×720p视频在24 fps时的原始数据速率非常接近于您在29.97 fps目标下所述的1024×768的原始数据速率，因此我的结果应该是您可以预期的素材数据速率的很好指南。
以下POSIX命令¹为您提供了一个清单，该清单主要与我们下面讨论的内容相匹配：
$ ffmpeg -codecs 2> /dev/null | grep '^..EV..S ' | grep -vE 'bitmap|image'
您可能希望在自己的计算机上运行该命令，以查看您的FFmpeg版本将支持什么。FFmpeg很少在启用每种可能的编码器的情况下构建。
现在让我们讨论这些选项。
如果你的“无压缩”的定义是格式的视频被设置于右侧前它是由数字显示转向光子，我在看到最近的ffmpeg -codecs列表是-c:v r210，r10k，v410，v308，ayuv和v408。这些基本上都是相同的，只是在颜色深度，颜色空间和Alpha通道支持上有所不同。
R210和 R10K是4：4：4 RGB，每个组件（bpc）为10位，因此在我的测试中，它们对于720p都需要大约 708 Mbit / s的速度。（每小时大约hour TB，朋友！）
这些编解码器都将每个像素的3×10位颜色分量打包为一个32位值，以便于计算机进行操作，例如2的幂次方。这些编解码器之间的唯一区别是两个未使用的位在32位字的哪一端打开。毫无疑问，这种微不足道的差异是因为它们分别来自竞争公司Blackmagic Design和AJA Video Systems。
尽管这些是琐碎的编解码器，但您可能必须下载Blackmagic和/或AJA编解码器才能在计算机上使用它们来播放文件。这两家公司都将让您下载自己的编解码器，而不必先买他们的硬件，因为他们知道你可能会处理由客户谁生产的文件做有他们的一些硬件。
V410本质上只是R210 / R10K的YUV版本；它们的数据速率是相同的。但是，此编解码器可能会更快地进行编码，因为ffmpeg在输入帧的颜色空间与该颜色空间之间更可能具有加速的颜色空间转换路径。
但是，我不推荐使用此编解码器，因为即使安装了AJA和Blackmagic编解码器，我也无法在尝试使用的任何软件中播放结果文件。
V308是 V410的8 bpc变体，因此在我的测试中为 518 Mbit / s。与V410一样，我无法使这些文件在普通的视频播放器软件中播放。
AYUV和V408本质上与V308相同，不同之处在于，无论是否需要，它们都包含Alpha通道！如果您的视频不使用透明度，则意味着您要付出上述10 bpc R210 / R10K编解码器的尺寸损失，而无法获得更深的色彩空间的好处。
AYUV确实具有一种优点：它是Windows Media中的“本机”编解码器，因此不需要播放特殊软件。
V408应该是QuickTime的本机，但在Mac上的QuickTime 7或10中都无法播放V408文件。
因此，将所有这些放在一起，如果您的PNG被命名frame0001.png，依此类推：
$ ffmpeg -i frame%04d.png -c:v r10k output.mov
...or... -c:v r210 output.mov
...or... -c:v v410 output.mov
...or... -c:v v408 output.mov
...or... -c:v v308 output.mov
...or... -c:v ayuv output.avi
请注意，对于AYUV，我已经指定了AVI，因为它几乎是仅Windows的编解码器。其他的可以在QuickTime或AVI中工作，具体取决于计算机上的编解码器。如果一种容器格式不起作用，请尝试另一种。
上面的命令（以及下面的命令）都假定您的输入帧已经与输出视频所需的大小相同。如果没有，请-s 1280x720在输出文件名之前在命令中添加类似内容。
如我所怀疑的，如果您实际上是说“无损”而不是“未压缩”，那么比以上任何一种方法都更好的选择是Apple QuickTime Animation，可以通过-c:v qtrle
我知道您说过您想使用AVI，但事实是您可能必须在Windows机器上安装编解码器才能读取此处提到的任何基于AVI的文件格式，而使用QuickTime可以观看视频您选择的应用程序已经知道如何打开QuickTime动画文件。（上面的AYUV编解码器是我所知道的唯一异常，但是它的数据传输率非常高，只是为了获得AVI的好处。）
ffmpeg会qtrle为您填充到AVI容器中，但结果可能不十分兼容。在我的测试中，QuickTime Player将对此类文件有所了解，但是会播放它。不过，奇怪的是，即使VLC部分基于，它也不会播放ffmpeg。对于该编解码器，我会坚持使用QT容器。
QuickTime动画编解码器使用简单的RLE方案，因此对于简单的动画，它应该像下面的Huffyuv一样做。每帧中的颜色越多，它将越接近上述完全未压缩的选项的比特率。在与Big Buck Bunny进行的测试中，我能够通过RGB 4：4：4模式ffmpeg给我一个165 Mbit / s的文件-pix_fmt rgb24。
尽管压缩了这种格式，但由于PNG的无损压缩不会影响像素值，因此也会为您的PNG输入文件提供相同的输出像素值。
该ffmpeg通道的QuickTime动画的实现也支持-pix_fmt argb，它可以让你4：4：4：4 RGB，这意味着它有一个alpha通道。以一种非常粗略的方式，它就是上述的QuickTime等效项-c:v ayuv。但是，由于无损压缩，它的速度仅为214 Mbit / s，不到AYUV数据速率的1/3，而质量或功能方面的损失却为零。
QuickTime Animation有一些变体，每个像素少于 24位，但是最好用于逐渐简化的动画样式。ffmpeg似乎仅支持该规范定义的其他格式之一-pix_fmt rgb555be，即15 bpp大端RGB。对于某些视频来说，它是可以容忍的，并且对于大多数截屏捕获和简单的动画来说，它都很好。如果您可以接受色彩空间抽取，则可能会发现其122 Mbit / s的数据速率具有吸引力。
将所有这些放在一起：
$ ffmpeg -i frame%04d.png -c:v qtrle -pix_fmt rgb24 output.mov
...or... -pix_fmt argb output.mov
...or... -pix_fmt rgb555be output.mov
现在，关于RGB和4：4：4 YUV的事情是，这些编码对于计算机来说非常容易处理，但是它们忽略了关于人类视觉的事实，那就是我们的眼睛对黑白差异比颜色差异更敏感。 。
因此，视频存储和传送系统几乎总是将每个像素用于颜色信息的位数比用于亮度信息的位数少。这称为色度二次采样。最常见的方案是4：2：0和4：2：2。
4：2：0 YUV的数据速率仅比黑白（仅Y）未压缩视频的数据速率高50％，是4：4：4 RGB或YUV数据速率的½。
4：2：2是介于4：2：0和4：4：4之间的一种中间点。它是纯Y视频的数据速率的两倍，是4：4：4的数据速率的两倍。
有时您也会看到4：1：1，就像在旧的DV摄像机标准中一样。4：1：1的未压缩数据速率与4：2：0相同，但是颜色信息的排列方式不同。
所有这些的要点是，如果您从4：2：0 H.264文件开始，则将其重新编码为4：4：4未压缩的RGB绝对不会为您带来4：2：0无损压缩的YUV。即使您知道工作流程为4：4：4 RGB，这也是正确的，因为这是微不足道的转换；视频硬件和软件会定期进行此类转换。
当您在偷看像素或在视频上进行像素级颜色更改时，您实际上只需要4：4：4，并且您需要保留确切的像素值。例如，使用4：4：4像素格式更容易实现视觉效果（VFX），因此高端VFX房屋通常愿意承受其所需的更高数据速率。
当您打开使用颜色抽取的YUV编解码器时，您的选择也会打开。ffmpeg具有许多有效的无损编解码器。
最广泛兼容的选项是Huffyuv。您可以通过获得-c:v huffyuv。
原始的Windows Huffyuv编解码器仅支持两种像素格式：RGB24和YUV 4：2：2。（实际上，它支持两种YUV 4：2：2，仅在磁盘上字节顺序上有所不同。）
较旧的FFmpeg Huffyuv编解码器版本不包含RGB24支持，因此如果尝试使用它，并且FFmpeg告诉您它将使用yuv422p像素格式，则需要升级。
FFmpeg也有一个称为FFVHuff的Huffyuv变种编解码器，它支持YUV 4：2：0。此变体与Windows DirectShow Huffyuv编解码器不兼容，但应在基于libavcodecVLC的任何软件中打开。
RGB24 — RGB 4：4：4与QuickTime Animation的RGB24颜色空间选项基本相同。对于给定的文件，这两个编解码器在压缩方面会有所不同，但是它们通常很接近。
它与上述V308选件使用的YUV 4：4：4模式本质上也是相同的。色彩空间的差异没有实际的差异，因为色彩空间的转换易于实时进行。
由于Huffyuv的无损压缩，我能够在RGB24模式下将测试视频压缩到约251 Mbit / s，其视觉质量与从V308或AYUV获得的视觉质量相同。如果AVI是您绝对需要的东西，那么安装Huffyuv编解码器可能比支付AYUV 3倍数据速率成本的痛苦要小。
YUV 4：2：2-此模式在视频方面比RGB24更加实用，这无疑是ffmpeg开发人员选择首先实现它的原因。正如您从上面讨论的理论减少所期望的那样，我的测试文件编码为173 Mbit / s。如果您考虑到这两个测试之间的音轨没有变化的事实，那就差不多了。
YUV 4：2：0 —此选项可以比4：2：2消除更多的颜色信息，在我的测试中，数据速率降至133 Mbit / s。
将所有这些放在一起：
$ ffmpeg -i frame%04d.png -c:v huffyuv -pix_fmt rgb24 output.avi
...or... -pix_fmt yuv422p output.avi
...or... -c:v ffvhuff -pix_fmt yuv420p output.avi
尽管在ffvhuff撰写本文时编解码器默认为4：2：0，并且实际上仅在我正在使用的发行版中支持该像素格式，但此设置正在更改，因此，如果此默认设置更改，则应包括该标志。
与Huffyuv和FFVHuff相同的精神的最新选择是Ut Video。像Huffyuv一样，有一个Windows视频编解码器，这意味着任何可以播放电影的Windows程序都可以在安装了编解码器的情况下使用此编解码器播放视频。与Huffyuv不同，还有一个Mac视频编解码器，因此您不仅可以使用基于FFmpeg的软件，也可以在Mac上libavcodec读取这些文件。
该编解码器在色彩空间方面非常灵活，因此，我仅举几个常见色彩空间的示例：
4：4：4 RGB via -f avi -c:v utvideo -pix_fmt rgb24提供178 Mbit / sec的输出
4：4：4 YUV via -f avi -c:v utvideo -pix_fmt yuv444p提供153 Mbit / sec的输出
4：2：2 YUV通过-f avi -c:v utvideo -pix_fmt yuv422p提供123 Mbit / sec的输出
4：2：0 YUV via -f avi -c:v utvideo -pix_fmt yuv420p提供100 Mbit / sec的输出
我怀疑在此测试中4：4：4 YUV的效果要好于4：4：4 RGB，尽管两者在技术上是等效的，因为源视频是4：2：0 YUV，因此以YUV格式排列数据可实现更好的无损压缩通过在文件中将部分冗余的U和V通道分组在一起。
在此空间中，另一个有趣的选择是FFmpeg自己的FFV1编解码器。它主要用作存档编解码器，而不是回放或编辑编解码器，但是由于太多软件要么基于libavcodecFFmpeg支持的库，要么可以libavcodec通过诸如的工具捆绑ffdshow使用，无论如何对您来说都是有用的。
默认情况下，ffmpeg使用诸如FFV1之类的灵活编解码器时，将保留输入文件的颜色空间，因此，如果将其馈入使用4：2：0 YUV的官方Big Buck Bunny MP4文件之一，那么您将得到除非你给一个-pix_fmt标志ffmpeg。这将产生63 Mbit / s的输出文件。
如果您使用强制FFV1使用4：4：4 YUV颜色空间-pix_fmt yuv444p，则文件大小最多只能达到86 Mbit / sec，但是在这种情况下，由于我们是从4：2：0原始编码进行编码，因此我们什么也没买。但是，如果您像在原始问题中那样输入一组PNG，则输出文件可能会使用bgra或bgr0颜色空间，这只是上面显示的argb和rgb24颜色空间的重排。
另一个有趣的替代方法是无损H.264。在撰写本文时，这几乎只是x264的事情，但是在编码方面使用FFmpeg的用户可能会libx264在解码方面也使用其他软件，例如VLC。
获取此类文件的最简单方法是：
$ ffmpeg -i frame%04d.png -c:v libx264 -qp 0 -f mp4 output.mp4
该-qp 0标志是关键：较高的值会产生有损压缩。（您也可以给以-crf 0得到相同的效果。）
与FFV1一样，ffmpeg将尝试在给定输入颜色空间的情况下猜测最佳输出颜色空间，因此，为了与上述结果进行比较，我在具有不同颜色空间的Big Buck Bunny源文件上运行了多个编码阶段：
yuv444p：这是ffmpeg您在为其提供RGB PNG流时选择的选项，如原始问题中所述，并且与我们的测试文件一起产生44 Mbit / sec的文件
yuv422p：这类似于Huffyuv的默认颜色空间，但是在这种情况下，我们得到34 Mbit / sec的文件，非常节省！
yuv420p：这是我正在测试的Big Buck Bunny官方MP4的默认设置，并产生29 Mbit / sec的文件。
请注意，为了获得如此小的文件大小，您正在交易很多兼容性。这就是为什么我什至都不想将其填充到AVI或MOV容器中的原因。它与x264紧密相连，因此您最好使用其标准容器类型（MP4）。您也可以使用类似Matroska的东西。
您可以通过添加来牺牲一些比特率，以缩短编码时间-preset ultrafast。这样可以将我的测试文件在YUV 4：2：2模式下的比特率提高到44 Mbit / s，但是按照承诺的那样，编码速度要快得多。文档声称这-preset veryslow也是值得的，但是它导致了更长的编码时间，同时只节省了一点点空间。我不推荐。
ffmpeg还支持Lagarith的仅解码模式和无损JPEG的仅编码模式。这两个编解码器实际上有点相似，并且文件质量要比Huffyuv小一些。如果ffmpeg开发人员曾经添加Lagarith编码，它将是Huffyuv的有力替代方案。但是，我不建议使用无损JPEG，因为它没有广泛的解码支持。
然后是在视觉上无损的编解码器。除非您是像素偷窥者，否则几乎可以肯定地说不出与前两组的视觉效果不同。通过放弃视频捕获传感器和显示设备之间绝对零变化的想法，您可以节省大量成本：
Apple ProRes：-c:v prores或-c:v prores_ks— ProRes是基于配置文件的编解码器，这意味着存在多种变体，每种变体在质量和空间之间进行权衡：
ProRes 4444仅使用 114 Mbit / s编码我们的测试视频，但仍具有 VFX质量。当前prores*，FFmpeg中有三种不同的编解码器，但prores_ks在我撰写此文章时，仅通过-profile:v 4444选件支持ProRes 4444。
如果您想知道为什么不使用ProRes 4444而不使用Lossless H.264，它归结为兼容性，解码速度，可预测性和Alpha通道。
ProRes 422节省了更多空间，仅需 84 Mbit / s即可获得仅通过像素窥视即可从ProRes 4444分辨出的结果。除非您需要ProRes 4444提供的Alpha通道，否则没有理由坚持ProRes 4444。
ProRes 422是上述无损H.264选项的更紧密竞争对手，因为它们都不支持alpha通道。如果您需要与Apple专业视频应用程序兼容，需要较低的CPU编码和解码开销或可预测的比特率，则需要承受ProRes的较高比特率。例如，后者对于硬件编码器很重要。另一方面，如果您可以解决Lossless H.264的兼容性问题，则可以选择使用4：2：0色彩空间，而这在任何ProRes配置文件中都不是。
FFmpeg中的所有三个ProRes编码器都支持ProRes 422配置文件，因此最简单的选择是使用-c:v prores，而不是-c:v prores_ks -profile hq，或者依靠的自动配置文件功能prores_ks来执行正确的操作。
ProRes配置文件甚至更多，但它们既可用于SD视频，也可作为全分辨率文件的代理。
ProRes的主要问题在于，它在Apple和专业视频界之外尚未获得广泛的支持。
Avid的DNxHD与ProRes类似，但与Apple pro视频世界无关。Avid为Windows和Macintosh提供可免费下载的编解码器，而FFmpeg现在可通过来支持它-c:v dnxhd。
由于DNxHD是类似于ProRes的基于配置文件的编解码器，因此您可以从预定义的集合中选择配置文件，并告诉编解码器要使用哪种帧大小，帧速率和比特率。对于Big Buck Bunny测试文件，此-b:v 60M配置文件是最合适的。毫不奇怪，生成的文件约为59 Mbit / s。
低损耗MJPEG：-vcodec mjpeg -qscale:v 1—比无损JPEG更为常见。实际上，这曾经是一种非常普遍的视频编辑编解码器，并且仍被诸如网络流视频摄像机之类的东西频繁使用。所有这些历史记录意味着可以轻松找到支持它的软件。
预计此编解码器的数据速率会有很大的差异。我刚刚在这里进行的一项测试为720p视频提供了25 Mbit / s的速度。如此高的压力足以让我担心损失，但对我来说看起来不错。仅基于数据速率，我想说它的质量可能相当于12 Mbit / s MPEG-2或6 Mbit / s H.264。
将所有这些放在一起：
$ ffmpeg -i frame%04d.png -c:v prores_ks -profile:v 4444 output.mov
...or... -c:v prores_ks -profile:v hq output.mov
...or... -c:v prores output.mov
...or... -c:v dnxhd -b:v 60M output.mov
...or... -c:v mjpeg -qscale:v 1 output.avi
这些方法的底线是，除非您执行非常苛刻的操作，否则“足够好”确实足够了。
脚注和题外话
该命令应该可以在Linux，macOS，BSD和Unix上正常使用。如果您使用的是Windows，则可以通过Cygwin或WSL获得POSIX命令行。
有几个原因导致该命令生成的列表与我上面选择讨论的编解码器集不完全匹配：
第二个grep是要过滤掉不适当的编码器，例如bmp不是“视频”编解码器的编码器，尽管V该编码器已在此列表中进行了标记。从技术上讲，您可能会将其中的许多内容填充到AVI，MP4或MKV之类的容器中以获取单个文件的视频，但基于ffmpeg或的程序只能读取该文件libavcodec。
对此有一些例外，例如，它-f avi -c:v ljpeg提供了您可以称为“无损MJPEG”的名称，但是通常，我们对将许多静止图像文件填充到此处的A / V容器中以制作电影不感兴趣。我们这里需要广泛认可的视频编解码器，而不是语义欺骗。
该命令当前无法过滤掉某些不适当的编码器（例如GIF），因为它们当前未在ffmpeg -codecs输出为bitmap或image文件格式中进行描述。
GIF是一个有趣的情况：它在单个GIF文件中支持多个图像帧，并带有用于运动回放的定时信息，但是由于多种原因，这完全不适合我们在此进行的讨论。
几个正在显示的选项是过时或从来没有真正得到多大吸引力，比如flashsv，dirac和snow，因此它不值得讨论他们以上。
该列表中的某些选项仅用于ffmpeg实例之间或ffmpeg与另一个程序之间的管道中，例如rawvideo和wrapped_avframe，因此不适合我们此处的目的。
在上面讨论的结尾附近，我明智地扩展了问题的范围，以包括一些经过精心选择的有损选项，因此它们不会通过grep上述命令中的第一个过滤器。
因此，我最终回答自己的时间太长了。
TL; DR摘要：要无损地存储图像序列，请使用libx264或libx264rgb与配合使用-preset ultrafast -qp 0。它几乎与ffvhuff一样快，比特率更低，并且解码速度更快。 huffyuv在ffmpeg之外，它得到了更广泛的支持，但不支持ffvhuff。因此，这是使用h.264的另一个原因，假设您的其他工具可以处理High 4:4:4 Predictivex264在无损模式下使用的h.264 配置文件。x264仅在需要快速随机访问任意帧的情况下才可以进行内部。
当从图像目录中读取时，请注意会影响libx264rgb 的ffmpeg错误。（以及谁知道其他情况。）在使用前测试设置中的无损性。（易于ffmpeg -i in -pix_fmt rgb24 -f framemd5在源上进行无损压缩）
编辑：utvideo编码和解码相当快，并且是比h.264简单得多的编解码器。它基本上是现代的huffyuv，支持更多有用的色彩空间。如果您在使用h.264时遇到问题，请尝试使用utvideo接下来的临时文件。
edit2：至少在Sintel预告片上，PNG作为RGB编解码器似乎表现良好。
另请参阅我对类似问题的类似答案：https : //superuser.com/a/860335/20798
沃伦·杨（Warren Young）的答案中有很多有关各种原始格式和编解码器的信息。我认为答案越短越有用，所以我正在做一个新的答案。如果您正在使用不支持无损x264或ffvhuff的软件，那么其中一些信息可能仍然有用。
在这种情况下，“无损”的最有用定义是您可以逐位恢复输入。无论您做什么，零担心视频编码导致的质量下降。
http://en.wikipedia.org/wiki/Chroma_subsampling
理想情况下，避免进行多次色彩空间转换。舍入错误可能会累积。如果您要使用可在RGB颜色空间中使用的滤镜来处理视频，则只要较高的比特率不成问题，将其保留为RGB就很有意义。您最终可能会制作yuv 4:2:0视频，但是根据要应用的滤镜，保持额外的色度分辨率可能很有用。
无论哪种方式，无损X264和ffvhuff都支持RGB和YUV 4:4:4，4:2:2和4:2:0。我建议使用x264，因为它解码速度很快。如果您要实时播放RGB HD视频，请尝试使用opengl而不是xv，因为我系统上的xv仅接受yuv输入。mplayer花费额外的CPU时间进行色彩空间转换。
以下编码器测试的来源：https : //media.xiph.org/。 https://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz 他们忘了为sintel预告片添加y4m文件的gzip文件，因此png tarball实际上要小得多。
ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac \
-c:a copy -c:v libx264rgb -preset ultrafast -qp 0 \
frompng.sintel.264rgb.mkv
例如
peter@tesla:/mnt/GP1TB/p/encoder-sample/sintel$ time ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac -c:a copy -c:v libx264rgb -preset ultrafast -qp 0 frompng.sintel.264rgb.mkv
ffmpeg version N-67983-g2b358b4 Copyright (c) 2000-2015 the FFmpeg developers
built on Jan 10 2015 05:32:37 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000
libavutil 54. 16.100 / 54. 16.100
libavcodec 56. 20.100 / 56. 20.100
libavformat 56. 18.100 / 56. 18.100
libavdevice 56. 3.100 / 56. 3.100
libavfilter 5. 7.100 / 5. 7.100
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Input #0, image2, from '1080/sintel_trailer_2k_%4d.png':
Duration: 00:00:50.12, start: 0.000000, bitrate: N/A
Stream #0:0: Video: png, rgb24, 1920x1080 [SAR 72:72 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 25 tbc
Input #1, flac, from 'sintel_trailer-audio.flac':
Duration: 00:00:52.00, start: 0.000000, bitrate: 721 kb/s
Stream #1:0: Audio: flac, 48000 Hz, stereo, s16
File 'frompng.sintel.264rgb.mkv' already exists. Overwrite ? [y/N] y
No pixel format specified, rgb24 for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264rgb @ 0x2770760] using SAR=1/1
[libx264rgb @ 0x2770760] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[libx264rgb @ 0x2770760] profile High 4:4:4 Predictive, level 4.0, 4:4:4 8-bit
[libx264rgb @ 0x2770760] 264 - core 144 r2525+2 6a4fca8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=0 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=0 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=cqp mbtree=0 qp=0
Output #0, matroska, to 'frompng.sintel.264rgb.mkv':
Metadata:
encoder : Lavf56.18.100
Stream #0:0: Video: h264 (libx264rgb) (H264 / 0x34363248), rgb24, 1920x1080 [SAR 72:72 DAR 16:9], q=-1--1, 25 fps, 1k tbn, 25 tbc
Metadata:
encoder : Lavc56.20.100 libx264rgb
Stream #0:1: Audio: flac ([172][241][0][0] / 0xF1AC), 48000 Hz, stereo (16 bit)
Stream mapping:
Stream #0:0 -> #0:0 (png (native) -> h264 (libx264rgb))
Stream #1:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 1253 fps= 18 q=-1.0 Lsize= 834790kB time=00:00:51.96 bitrate=131592.5kbits/s
video:830198kB audio:4575kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.002025%
[libx264rgb @ 0x2770760] frame I:6 Avg QP: 0.00 size:612470
[libx264rgb @ 0x2770760] frame P:1247 Avg QP: 0.00 size:678787
[libx264rgb @ 0x2770760] mb I I16..4: 100.0% 0.0% 0.0%
[libx264rgb @ 0x2770760] mb P I16..4: 50.3% 0.0% 0.0% P16..4: 12.0% 0.0% 0.0% 0.0% 0.0% skip:37.6%
[libx264rgb @ 0x2770760] coded y,u,v intra: 71.1% 68.2% 70.0% inter: 22.8% 22.8% 23.2%
[libx264rgb @ 0x2770760] i16 v,h,dc,p: 50% 48% 1% 1%
[libx264rgb @ 0x2770760] kb/s:135693.94
请注意，我忘记指定-r 24fps，因此它不会与音频保持AV同步。（并且比特率（但不是文件大小）数字也将关闭。ffmpeg默认为25fps）。本机中的CPU是第1代（conroe）core2duo 2.4GHz（E6600）。
结果：
4.5M sintel_trailer-audio.flac # this is muxed in to every mkv
948M 1080 # the directory of PNGs
940M /var/tmp/dl/sintel_trailer-1080-png.tar.gz
7434M sintel.y4m # yuv444, uncompressed. mplayer gets the colors wrong?
2342M qtrle.mkv # encode went at 16fps, so qtrle is slower and worse filesize
2105M sintel.huff.mkv # ffvhuff with default options, rgb pix fmt
1228M sintel.utvideo.mkv # muxed without audio, I should update the others this way
946M png-copy.mkv # -codec copy makes a MPNG stream. Use -codec png for non-png sources, but it won't make PNGs as small. Decodes very fast
824M lossy.prores_ks.mov # yuv444p10le extremely slow to encode (2.3fps), and worse bitrate.
816M frompng.sintel.264rgb.mkv
735M sintel.x264rgb.medium.nocabac.mkv # encode went at 3.3 fps instead of 18. Better gain than for live-action, though
626M sintel_trailer.rgb.lossless.veryslow.mkv # 1.1fps. With CABAC, 16 ref frames, etc. etc.
512M lossy.prores.mov # yuv422p10le, 12fps
341M sintel.yuv420.x264.lossless.mkv
21M lossy.rgb.crf26.preset=medium.mkv
13M lossy.yuv420.crf26.preset=medium.mkv # remember this is WITH 4.5MB audio
请注意，mediainfo它不知道RGB h.264，但仍说文件是YUV。
检查它确实是无损的：
ffmpeg -i 1080/sintel_trailer_2k_%4d.png -f framemd5 png.framemd5
ffmpeg -i fromhuff.sintel.264rgb.mkv -an -sn -pix_fmt rgb24 -f framemd5 x264rgb.framemd5
diff -s *.framemd5
Files png.framemd5 and x264rgb.framemd5 are identical
因此，您可以通过这种方式恢复原始的PNG输入，即可以使PNG中包含相同的图像数据。
请注意-pix_fmt rgb24x264测试。ffmpeg的h.264解码器输出gbrp（平面，未打包）输出，因此位相同，但顺序不同。framemd5“容器”没有施加任何格式限制，但是如果位的排列方式相同，则只会得到相同的md5。我只是看了ffmpeg告诉我它在供PNG使用时用于pix fmt的意思，然后将其用作-pix_fmt用于解码的arg 。顺便说一句，这就是vlc无法播放RGB h.264文件（直到下一个版本或当前的夜间构建）的原因：它不支持gbrp像素格式。
对于yuv使用libx264，不是libx264rgb。您无需安装RGB版本的x264，实际的库同时支持这两种格式。只是ffmpeg将其实现为两个不同名称的编码器。我认为，如果他们没有这样做，默认的行为是将rgb输入保留为rgb，并以非常慢的速度运行，同时以相同的质量产生更高的比特率输出。（-pix_fmt yuv420p如果需要420，有时仍需要使用，而不是444h.264输出。
除非您要长期存储文件，否则请始终使用-preset ultrafast无损x264。更多的参考系和运动搜索对于无损，对于具有任何噪声的非动画材料来说几乎没有什么区别。CABAC甚至以解码方式都以无损比特率占用大量CPU。仅用于存档目的，不用于暂存文件。（超快速禁用CABAC）。CABAC可节省10％至15％的比特率。
如果需要将每个帧都作为关键帧，请设置-keyint 1。然后，仅想剪切关键帧或w / e的视频编辑软件将不会限制您。
要回答最初的问题：这是在分阶段尝试一些操作时（例如，缓慢的隔行扫描，在尝试其他操作之前保存无损输出的方法）在临时文件周围扔东西的方法：
ffmpeg -i dv-video-source.ts -vf yadif=2:1,mcdeint=3:1:10 -c:a copy -c:v libx264 -preset ultrafast -qp 0 deinterlaced.mkv
如果您确实需要图像文件中的输出，可以使用静止图像工具对其进行修改，那么可以确定将其解码为png。对于每个像素的Y，Cb和Cr值，您将不会损失任何8位最低有效位。
x264在这方面非常出色，因为存在很多带有一些文本的黑色框架，淡入和淡出以及许多帧的大区域之间的完美相似性，即使使用，它也可以利用-preset ultrafast。在实景拍摄中，我仍然看到x264在ffvhuff（yuv420）文件大小的一半。
对于任何好奇的人：高CPU时间无损rgb编码具有（x264核心144 r2525）：
[libx264rgb @ 0x35b97a0] frame I:27 Avg QP: 0.00 size:604367
[libx264rgb @ 0x35b97a0] frame P:1226 Avg QP: 0.00 size:517512
[libx264rgb @ 0x35b97a0] mb I I16..4..PCM: 46.3% 38.1% 15.7% 0.0%
[libx264rgb @ 0x35b97a0] mb P I16..4..PCM: 24.3% 5.4% 4.5% 0.0% P16..4: 10.5% 3.3% 5.7% 0.0% 0.0% skip:46.3%
[libx264rgb @ 0x35b97a0] 8x8 transform intra:17.3% inter:46.1%
[libx264rgb @ 0x35b97a0] coded y,u,v intra: 81.6% 77.5% 80.0% inter: 28.0% 27.7% 28.1%
[libx264rgb @ 0x35b97a0] i16 v,h,dc,p: 35% 64% 1% 0%
[libx264rgb @ 0x35b97a0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 49% 13% 2% 1% 1% 1% 1% 1%
[libx264rgb @ 0x35b97a0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 37% 5% 5% 6% 5% 5% 4% 3%
[libx264rgb @ 0x35b97a0] Weighted P-Frames: Y:41.1% UV:40.7%
[libx264rgb @ 0x35b97a0] ref P L0: 74.5% 4.2% 9.1% 4.1% 2.1% 1.7% 1.2% 0.8% 0.6% 0.5% 0.3% 0.2% 0.2% 0.2% 0.2% 0.1%
[libx264rgb @ 0x35b97a0] kb/s:99721.66
请注意，加权p帧的实际比例很高，并且跳过宏块的比例也很高。每个场景过渡都是淡入淡出，而不是剪切，如果您给x264分配CPU时间来找出方法，则x264会发挥作用。
对于通过剪辑进行向前/向后的擦洗，通常仅使用内部编解码器（utvideo，ffvhuff，mjpeg，jpeg2000，pro-res，AVC-Intra）。我以为具有短GOP（1/2到1秒）的常规AVC也可以很好地进行擦洗，只要软件知道它在做什么（快速擦洗时解码最近的I帧，在GOP内解码即可到达）如果您在时间轴上放大了足够的帧以进行此操作）。
我在此和https://video.stackexchange.com/上发布了一些关于pro-res的负面信息，例如“如果压缩比无损编解码器更慢和更糟，那将是什么意义”，但是它确实具有一些有趣的功能。 苹果公司表示，它可以使用解码完整rez的CPU时间的1/3进行半分辨率解码。
ffmpeg的prores实施在速度上可能不如Apple那样优化，这就是为什么我对ffmpeg进行的测试使它看起来很慢。如果您具有使用基于ffmpeg的工具的免费软件工作流，可能不值得使用，但是如果您使用的是商业软件，则可能值得尝试。
我没有做太多的视频编辑，主要是编码，所以我对适合prores等编解码器的测试不太了解。我猜想，如果短GOP x264无法正常工作，那么mjpeg可能是一个不错的快速选择。Linux发行版中有jpeg的asm加速实现，这是一个非常简单的编解码器。您可以根据需要提高或降低质量，以权衡质量与文件大小+编码/解码速度之间的关系。它很古老，但是如果您想要一个真正快速的仅内部编解码器，它可能会击败x264。
对于x264，我会尝试类似x264 --crf 10 --keyint=1 --preset superfast --tune fastdecode （仅限内部使用，而不会设置任何其他--avcintra-class设置的东西。）请注意superfast（不使用CABAC），或者faster，ultrafast对于有损操作，可能不是最好的选择。我认为，“超快速”会失去很多质量，而没有那么快。使用的质量越低（crf越高），花费更多的CPU时间来寻找更好的编码就越值得。不过，其中很多可能与GOP大小= 1无关。
在GOP大小> 1的情况下，如果您在编码时抛出了很多位，以至于更好的帧间预测在对残差进行编码时不会节省很多位（因为噪声/颗粒/帧之间的细微变化得到了非常准确的保留），那么只是超快可能还好。否则，--keyint=30可能--preset veryfast --crf 12会很有趣。
从理论上讲，在给定的CRF设置下，质量在各个预设之间应保持恒定。如果您正在寻找较小的文件（更快的解码），则需要权衡一些质量和一些编码时间。
ffmpeg -i input.avi -c:v qtrle -pix_fmt rgb24 output.mov。