压缩视频会创建更大的文件

17

我一直在使用GUI（右键单击=>压缩）尝试压缩包含3个视频的tar文件，总计1.7gb（.H264 MP4）。gzip，lrzip，7z等都对文件大小没有任何作用，压缩文件夹也为1.7 gb。

然后，我尝试从命令行运行lrzip（以防gui问题），并使用-z标志（极端压缩），这是我的输出。

在此处输入图片说明

如压缩率所示，压缩文件夹的实际大小大于原始大小！我不知道为什么我没有运气，特别是lrzip根据我阅读的随机评论和官方文档（文件大于100mb，越大越好）-尤其有效-请参阅https：//wiki.archlinux。 org / index.php / Lrzip

为什么我不能压缩文件？

gzip

— 背风处
source

2

就个人而言，我不会费心存档mp4视频，因为这些视频已经被编解码器压缩了。

— 婴儿车2014年

而且，您可以使用FFMpeg之类的视频转换器/压缩器工具来缩小尺寸。

— Jet

pram和Jet是正确的。这是预期的行为。尝试压缩已经很好压缩的东西会适得其反。如果您使用视频转换工具，则可能可以节省空间，但要以牺牲视频质量为准（无论是否明显）。但是，从您拥有的质量最高，压缩最少的副本开始。

— John S Gruber 2014年

25

就像@pram在评论中所说的那样，mp4视频已经被压缩了，其他视频格式也可能在某种程度上使用了压缩。因此，尝试压缩它们不会导致大小的减少（如果有的话）（至少部分地适用于图片和音乐）。在这种情况下，看起来元数据（对于压缩文件本身）可能引起了增加。可能会（并且可能会导致很大的降低）的唯一压缩格式是xz。

另一方面，如果您想减小这些视频的大小，请改用“手刹”之类的方法对视频进行重新编码。

— saiarcot895
source

3

我发现webm通常具有良好的压缩率。比mp4小得多。

— 赛斯2014年

@Seth实际上是MP4（它是AVC aka h.264或更新更好的h.265 aka HEVC编解码器），可以以相同的质量提供较小的文件（或以相同的文件大小提供更好的质量）。

— DavidBalažic'16

@DavidBalažic，当我们尝试谈论橙子时，我们在这里比较苹果和苹果。mp4和webm都是容器，它们与压缩无关。没错，h.264和h.265都是mp4容器中常用的编解码器，但是您无法将h.265和webm进行比较。h.264与webm容器中常用的vp8编解码器相当，就像h.265与webm通常也包含的vp9编解码器相当。tl; dr：在mp4中使用h.265，在webm中使用vp9，您将获得大致相同的质量/效率。

— forresthopkinsa

13

确实，文件已经被压缩的事实并不是关键问题。就是这样：压缩通常仅在数据中具有某种冗余时才有效。对于未压缩的文件，实际上几乎总是这样-但是，冗余的含义并不一定很明显。通用压缩算法主要针对文本文件中显而易见的事物：许多单词不仅出现一次，而且以相同的形式出现很多次，也许单词的短语可以组合，等等。等等。可以将其概括为从中文诗歌的ASCII编码电话号码列表到二进制机器代码的任何内容，但它们可能不适用于任何类型的数据。特别是，媒体文件在概念上是模拟数据，以嘈杂的数字表示。这意味着，根本没有任何文本文件冗余：某些动机可能会重复出现，但总是与传感器噪声的配置略有不同。这就是为什么所有压缩图像/ AV格式通常都基于DCT或小波使用一些巧妙选择的转换作为其第一步编码的原因。粗略地说，这些转换将图片部分和噪声部分移动到了不同的位置，因此可以很好地将它们分开，并通过有损压缩仅保留您认为最“重要”的信息，其中不包括噪声，而“好的信息”具有很多冗余。（这实际上不是它的工作方式，而是类似的。）

如果通用压缩器使用了这些转换，则结果将相反：大多数数字信息实际上会被误分类为某种噪声，因为它缺乏您在模拟信号中发现的“平滑”结构。而且在有损视频压缩之后，显然再也找不到模拟平滑度或数字重现性（如果是的话，编解码器将使用另一个bzip-stage或它们自己的东西！）

— 到处走走
source

12

运气不好的原因是mp4已被压缩，因此无法进一步压缩。您要做的只是将压缩格式的头信息添加到文件中。

由于文件已经被压缩，无法进一步压缩，因此文件大小会增加，因为您要做的只是保留相同的信息并添加更多字节的标题信息。

— 特登
source

5

这是鸽洞原理的一个很好的例子。

由于文件已经（有损）压缩，因此几乎没有减少或没有减少，这意味着您已经是零净收益。如其他提到的那样，压缩格式本身在其自己的元数据中有一定的，通常可以忽略的损失。所有这些加在一起意味着在相等或较小的文件集中可能不存在任何问题，因此，压缩的数据将落入较大的文件集中。

— 利维乌斯
source

4

对不起，但这是对上述原则的错误运用。您可以对充满零的1.7GB文件应用相同的逻辑，并得到不正确的答案。通常使用Pigeonhole原理来证明不可压缩文件的存在，而不是用来证明任何特定文件实际上是不可压缩的。（后者是不可计算的，因为Kolmogorov复杂度函数不是可计算函数）。

— nneonneo 2014年

1

@nneonneo然后随时更正链接的Wikipedia文章。不可压缩文件的存在直接源自该文件，然后您添加了压缩元数据，突然您得到的文件比原始文件大。这正是我说的。在给定算法的给定实现下文件不可进一步压缩的证明是输出不小。当然，元数据也有可能比压缩优势更大，但是我不确定我是否将其描述为面向用户的压缩形式。

— Livius 2014年

@Livius维基百科的文章是正确的：它使用鸽子洞原理来证明任何给定的无损压缩算法都存在不可压缩文件。但是，仅凭信纸孔原理就无法得出任何特定文件的不可压缩性。

— David Richerby 2014年

@DavidRicherby是的，但是文件没有被给定算法的给定实现压缩的事实证明了该文件不可压缩。除非存在其他原因导致无法压缩的文件存在，否则无法进行压缩是由于PP。唯一可能的其他原因是，给定算法看不到减小其大小的方法，这似乎又是“在算法假设下，不存在具有相同信息的较小文件；这种情况必然存在”因为有PP”。

— Livius 2014年

更准确地说，PP强制算法具有其图像不位于较小文件空间中的输入。因此，导致给定文件的图像不适合该空间的每个决定都在某种程度上由PP及其强制执行的折衷驱动（假定压缩算法的理智定义）。这样，任何图像不小于该文件的文件都属于PP不可压缩的集合。给定文件不可压缩的证明是其压缩失败；从广义上讲，不可压缩性始终是PP及其折衷的结果。

— Livius 2014年

4

如果要压缩这些文件，则必须降低质量。

在不知道这些文件有多长时间以及什么格式和内容类型的情况下，很难判断这些文件是否有缩小空间而不会造成明显的质量损失。

具有1080p视频的BluRays往往会超过25GB，因此，您已经达到了H.264最佳的质量尺寸比。

您可以尝试使用ffmpeg或avconv转换文件。

你可以开始 ffmpeg -i input_file.mp4 -preset slower -crf 20 -c:a copy output_file.mp4

该anconv命令将类似地工作。

增加此-crf值以减小文件的大小和质量，我不建议将其设置为25以上。
您可以将预设更改为slow或medium以提高速度，但与slower甚至甚至veryslow（如果您非常有耐心！）相比，文件大小都会受到影响。
可以在这里找到更多设置：http : //mewiki.project357.com/wiki/X264_Settings
我建议远离大多数设置，因为预设提供了理智的默认设置，-tune但例外情况除外。
如果您的内容是电影（-vf hqdn3d），则尝试使用降噪器，与使用高-crf值相比，可以提高视觉质量。
将内容缩小-vf scale=-1:720为720p和-vf scale=-1:480480p，以提高编码速度并保持质量。

— 丹尼尔·希尔
source