h264无损编码答案

【问题标题】：h264 lossless codingh264无损编码
【发布时间】：2011-10-05 19:40:13
【问题描述】：

是否可以在 h264 中进行完全无损编码？无损，我的意思是如果我给它输入一系列帧并对其进行编码，然后如果我从编码的视频中提取所有帧，我将得到与输入完全相同的帧，逐个像素，逐帧.这真的可能吗？举个例子：

我生成一堆帧，然后将图像序列编码为未压缩的 AVI（使用 virtualdub 之类的东西），然后应用无损 h264（帮助文件声称设置 --qp 0 可以进行无损压缩，但我是不确定这是否意味着在过程的任何一点都没有损失，或者只是量化是无损的）。然后我可以使用 mplayer 从生成的 h264 视频中提取帧。

我先尝试了 Handbrake，但结果证明它不支持无损编码。我试过 x264 但它崩溃了。这可能是因为我的源 AVI 文件是 RGB 颜色空间而不是 YV12。我不知道如何将一系列 YV12 位图以及以什么格式提供给 x264，所以我什至无法尝试。

总而言之，我想知道是否有办法解决

一系列无损位图（在任何颜色空间中）-> 一些转换 -> h264 编码 -> h264 解码 -> 一些转换 -> 原始系列无损位图

如果有办法做到这一点？

编辑：关于无损 H264 有一个非常有效的观点没有太大意义。我很清楚，我无法（仅凭我的眼睛）分辨出未压缩剪辑和另一个在 H264 中以高速率压缩的剪辑之间的区别，但我认为它并非没有用处。例如，它可能有助于存储视频以供编辑，而不会占用大量空间，并且不会在每次保存文件时损失质量和花费太多编码时间。

更新 2：现在 x264 不会崩溃。我可以使用 avisynth 或无损 yv12 lagarith 作为源（以避免颜色空间压缩警告）。但是，即使使用 --qp 0 和 rgb 或 yv12 源，我仍然会得到一些差异，虽然很小但存在。这很麻烦，因为我发现的关于无损预测编码 (--qp 0) 的所有信息都声称整个编码应该是无损的，但我无法验证这一点。

【问题讨论】：

我什至不知道 h.264 定义了无损模式...
我不相信您可以在无损模式下执行 h.264。你为什么要这么做？
有损有什么问题？
电影 CG 工作室经常将他们的作品（通过运输公司）发送到飞机上，因为这比在互联网上发送更便宜、更快捷。当你突然听到这样的故事时，这样的问题就很有意义了。是的，h.264 有无损模式。
这个问题似乎离题了，因为它是关于 FFmpeg 的，更适合 Super User 或 Video Production。

标签： h.264 x264 lossless-compression

【解决方案1】：

在花了一整天试图弄清楚如何将 YUV 4:4:4 像素转换为 x264 之后，我将添加一个较晚的答案。虽然 x264 确实接受文件中的原始 4:2:0 像素，但要传入 4:4:4 像素确实非常困难。使用最新版本的 ffmpeg，以下适用于完全无损编码和提取以验证编码。

首先，将原始 yuv 4:4:4 像素写入平面格式的文件。平面是一组 Y 字节，然后是 U 和 V 字节，其中 U 和 V 使用 128 作为零值。现在，调用 ffmpeg 并传入原始 YUV 帧的大小，因为两次使用“yuv444p”像素格式，如下所示：

ffmpeg -y -s 480x480 -pix_fmt yuv444p -i Tree480.yuv \
-c:v libx264 -pix_fmt yuv444p -profile:v high444 -crf 0 \
-preset:v slow \
Tree480_lossless.m4v

一旦编码为 h264 并包装为 Quicktime 文件，就可以像这样提取完全相同的字节：

ffmpeg -y -i Tree480_lossless.m4v -vcodec rawvideo -pix_fmt yuv444p \
Tree480_m4v_decoded.yuv

最后，用 diff 验证两个二进制文件：

$ diff -s Tree480.yuv Tree480_m4v_decoded.yuv
Files Tree480.yuv and Tree480_m4v_decoded.yuv are identical

请记住，您需要自己将 YUV 字节写入文件，不要让 ffmpeg 对 YUV 值进行任何转换！

【讨论】：

更简单的 ffmpeg 命令是：ffmpeg -i Frame_03d.png -vcodec rawvideo -pix_fmt yuv444p Output.y4m（将 3 更改为文件中的位数）
终于有人验证了！
不，这只会将原始像素转储到 y4m (rawvideo) 文件中。最初的问题是关于如何编码为无损 h.264。您的“更简单”命令不压缩数据，它只是转换为原始未压缩像素。
第一个命令是转换它。第二个是“解压缩”以进行比较:)

【解决方案2】：

如果 x264 进行无损编码但不喜欢您的输入格式，那么您最好的选择是使用ffmpeg 来处理输入文件。尝试从类似的东西开始

ffmpeg -i input.avi -f yuv4mpegpipe -pix_fmt yuv420p -y /dev/stdout \
  | x264 $OPTIONS -o output.264 /dev/stdin

并从那里添加选项。 YUV4MPEG 是一种无损无压缩格式，适用于不同视频工具之间的管道； ffmpeg 知道怎么写，x264 知道怎么读。

【讨论】：

谢谢！到目前为止，我还无法使用 x264 回到我的原始视频（现在它喜欢我的输入格式）。总是有挥之不去（非常非常微妙）的工件，所以也许 ffmpeg 可以帮助我。转换为 yuv420p 时会丢失原始 avi 的颜色信息吗？即使是这种情况，有没有办法从 yuv4mpeg 未压缩流中提取单个帧，以便我可以将它们与 x264 流中的帧进行比较，或者至少从 x264 流中解码 yuv4mpeg。如果 h264 可以真正无损，它们应该是相同的。
在从 RGB 到 YUV 的转换过程中可能会有一些细微的精度损失，但我相信这是不可避免的，因为 YUV 是 H.264 的原生色彩空间。但是，我忘记了 YUV420P 实际上并不是一种完全无损的像素格式——它在一定程度上减少了它存储的色度信息。尝试从ffmpeg -pix_fmts 中选择其他选项，看看 x264 是否会接受它们。 yuv444p 将是一个好的开始；它是 YUV，但每个像素都有完整的色度信息。
我就是这么想的。我尝试执行以下操作来丢弃色彩空间缩减：使用 lagarith（无损 yv12）对视频进行编码，以便我将图像置于适合 h264 的色彩空间中。我从该视频中提取了所有帧并保留了一份副本。我用 x264 --qp0 对视频进行了编码（这次没有发生颜色转换），然后我提取了结果视频的帧。它们与我的备份不匹配。从 YV12 到 RGB 应该不会丢失信息，对吧？我做错了吗？

【解决方案3】：

FFmpeg 具有 x264 的“无损”模式，请参阅 FFmpeg 和 x264 编码指南

§ Lossless H.264

本质上是-crf 0

【讨论】：

你应该仔细阅读OP，它已经包含的唯一命令是-qp 0
错字：crf，不是crt。
错字：qp 0，不是 crf。 crf 不强制支持 10 位无损的 high444。

【解决方案4】：

我不知道您对压缩和解压缩的要求，但通用存档器（如带有 LZMA2 的 7-zip）应该能够压缩到与无损视频编解码器一样小，或者在某些情况下甚至小得多.而且它比整个视频处理链更简单、更安全。缺点是速度要慢得多，并且您必须先提取才能看到它。但是对于图像，我认为您应该尝试一下。

还有无损图像格式，例如 .png。

要使用 x264 编码无损 RGB，您应该使用 x264 的命令行版本（在这种边缘情况下您不能信任 GUI，它们可能会搞砸）r2020 或更高版本，类似这样：

x264 --qp 0 --preset fast --input-csp rgb --output-csp rgb --colormatrix GBR --output "the_lossless_output.mkv" "someinput.avs"

输入和输出之间的任何损失/差异都应该来自某些色彩空间转换（编码之前或播放时）、错误设置或某些标头/元数据丢失。 x264 不支持 RGBA，但是 RGB 是可以的。 YUV 4:4:4 压缩效率更高，但由于您的输入是 RGB，因此您会在色彩空间转换中丢失一些数据。 YV12/i420 要小得多，是迄今为止视频中最常见的色彩空间，但色度分辨率较低。

有关 x264 设置的更多信息： http://mewiki.project357.com/wiki/X264_Settings

另外，请避免使用 lagarith。它使用 x87 浮点......并且有更好的选择。 http://codecs.multimedia.cx/?p=303 http://mod16.org/hurfdurf/?p=142

编辑：我不知道为什么我被否决了。这样做时请留下评论。

【讨论】：

通用压缩算法不能很好地处理视频、音频等。专用算法（如果存在）几乎总是更好。此规则的例外是一些非常古老的算法 + 可能是旨在欺骗编码器的特制输入数据。
@Sarge：我不同意无损视频编解码器，因为如果没有定义要比较的统计数据，更好是毫无意义的。许多无损视频编解码器用于实时捕获，因此只进行轻度压缩。通用压缩器通常会导致文件更小。
@JohnSmith 在这种情况下，他们更快。
主要优点是在查看/使用之前不需要解压缩整个文件。是的，大多数无损视频编解码器都是为实时捕获而设计的，因此速度很快，并且通常比通用存档器更好地压缩自然画面，但幅度不大。但是对于某些内容，例如 2D 屏幕截图，即使是专门的编解码器也无法与 LZMA 的压缩与大字典相匹配。而且您将获得输入视频的精确副本，没有机会搞砸颜色转换、元数据等。根据 OP 的需要，它们可能是最佳选择。

【解决方案5】：

我同意有时数据丢失是可以接受的，但这不仅仅是压缩后的外观问题。

即使是视觉上难以察觉的色彩数据丢失也会降低素材质量，从而使色彩校正、绿屏抠像、跟踪和其他后期任务变得更加困难或不可能，从而增加制作成本。

这实际上取决于您在管道中压缩的时间和方式，但最终归档原始质量是有意义的，因为存储通常比重新拍摄便宜得多。

【讨论】：

好点，我完全同意，但这更多的是评论而不是答案。我猜它是由于缺乏评论权限而发布的？

【解决方案6】：

要使用 HandBrake GUI 生成无损 H.264，请设置视频编解码器：H.264、恒定质量、射频：0、H.264 配置文件：自动。尽管 Apple 本身不支持此文件，但可以将其重新编码为近乎无损的播放方式。

HandBrake GUI 的活动窗口：

H.264 配置文件：自动； 以恒定 RF 0.000000 编码...配置文件高 4:4:4 预测，3.0 级，4:2:0 8 位

H.264 配置文件：高； 以恒定 RF 0.000000 编码...无损需要 high444 配置文件，禁用...配置文件 High，3.0 级

【讨论】：

Profile high 不支持无损:)

【解决方案7】：

如果您无法使用 h.264 编码器和解码器进行无损压缩，也许您可以研究两种选择：

(1) 一些人不是以 h.264 格式传递所有数据，而是尝试用residual "side channel" 传递一些数据：

(h.264 文件) -> h264 解码 -> 一些转换 -> 原始位图系列的有损近似
（压缩残差文件）-->解码器->一系列无损残差位图
对于每个位图中的每个像素，近似像素 + 残差像素 = 与原始像素逐位相等的像素。

(2) 在“无损”模式下使用狄拉克视频压缩格式。

【讨论】：

是的......实际上我最终做了一些非常相似的事情（选项1）。我也尝试使用 Lagarith 编解码器，这可能类似于选项 2。我不在这里写它是不好的。非常感谢您的回答。
这会产生有价值的结果吗？我记得曾经用 MP3 + lzma-compressed 残差尝试过类似的东西，但它总是比普通的 FLAC 差（相差很小）

【解决方案8】：

在 PowerShell 中使用 FFmpeg。输入ffmpeg -h encoder=libx264rgb。可以看Supported pixel formats: bgr0 bgr24 rgb24 当您将 RGB 编码为 YUV 或反之亦然时，您总是会丢失质量。但是如果你使用-pix_fmt yuv444p -profile:v high444p，你的损失最小。但是，如果您使用像素格式为rgb24 的ffmpeg 编码器libx264rgb 的libx264rgb，则不会有任何质量损失。许多应用程序（例如 Davinci Resolve）无法读取 rgb 24 格式的像素。我建议你使用：

ffmpeg -i ["your sequence of rgb image.png"] -c:v libx264rgb -video_size [your size] -framerate [your fps] -r [your fps] -qp 0 -pix_fmt rgb24 -profile:v high444 -preset veryslow -level 6.2 "your_video.mov"

很遗憾，我不知道如何创建序列。但是在FFmpeg中是可以的。

【讨论】：

profile:v high444p 不存在（请更正那个错字），只有 high444 存在，但不起作用，看起来像一个错误，但不能强制 high444！只能使用 -qp 0 强制（并且始终无损）。