为什么图片视频不直接使用类似 huffman 这种熵编码压缩呢？

[nthhdy]

假如不考虑图片视频利用人类视觉特点的有损压缩，只讨论无损压缩。

熵编码实现压缩，是利用了数据流里“重复出现的部分”，把这些重复部分代换成更短且能一对一无歧义还原的片段，就实现了压缩。

那么图片、视频中其实也有“重复的部分“。比如，视频压缩中利用相邻帧之间变化很小这一特点，那是不是可以说，相邻帧之间“重复的部分”非常多呢？（虽然不是完全重复，至少可以说很类似。）既然重复的部分很多，是不是可以用更 smart 的熵编码算法来直接压缩呢？

[ipwx]

@nthhdy 其实如果外延一下的话，上面的乱七八糟的讨论和条件熵有关。

H[X|Y] = H[X,Y] - H[Y]

已知 Y: 数据是视频。

所蕴含的信息量其实是非常非常巨大的。同样的文件，没有 Y 这个信息的话，你无法自动推断出 “帧与帧之间有图像相似性” 这个结论的。因为每张图的 0-1 串其实相差巨大。图片就是这个样子，上面的 object 移动一个像素，二进制串就一大堆变化（而且还不是连续的二进制位发生变化）。通用压缩算法几乎不可能在有限的时间里面去 discover 这种信息。

[yukiww233]

已经用了; 比如视频，H.264 压缩对比原始数据甚至小于 1/100, 靠无损编码是没可能达到的

[yangzzzzzzzt1]

作为一个专门研究编码器的人表示槽点太多无从吐起

[unco020511]

不仅仅是媒体文件,好多压缩算法都是这个原理吧

[misdake]

“为什么不能只用熵编码这一个步骤”
因为只用这一个步骤的话，压缩比太低。
想要提高压缩比，允许有损压缩，就会有那些频率域上的操作和前后运动估算之类的方法。

[nthhdy]

@yangzzzzzzzt1

基本上每个人都会误解我的问题，请先看一下 18 楼。
若还是觉得槽点太多，欢迎一一吐之。

[nthhdy]

@misdake

你说的对。问题就在于，那些压缩算法对文本都挺好的，对图片和视频就不行？道理是什么？

> 想要提高压缩比，允许有损压缩，就会有那些频率域上的操作和前后运动估算之类的方法。
我的理解是，引入运动预测等机制，即使无损也能一定程度上提高压缩比。所以并不仅仅是有损无损的问题。

[nthhdy]

@yangzzzzzzzt1 看错了，14 楼

[nthhdy]

@ipwx 这个回答非常有用，待我理解一下

[littlefishcc]

图片：单个文件压缩算法，不就是帧内压缩， 能压缩就那么大。
视频：压缩体积大的原因，通过帧间压缩。
自己写一个手机协同工具，开始用一张张图片压缩后传送到 PC ，网络传送可以大概一直是 8M ，后面欢用 h264 基本就是 200 多 KB 。
h264 说白就是 前和图片有关联只要传送变化就可以了， 以前看远程控制的软件，没有用 h264 ，自己写压缩算法，就是计算前后图片的改变内容，然后传送改变的 rbg 值。。。

[misdake]

另外开阔眼界的话，png 里面用到的压缩方法也挺有意思，还有最近的 qoi 压缩，都是很针对图片的压缩方法。可能比熵编码更好一点
How PNG Works: Compromising Speed for Quality: <amp-youtube data-videoid="EFUYNoFRHQI" layout="responsive" width="480" height="270"></amp-youtube>

[oldshensheep]

楼主大概的意思是把 一捆图片 打个压缩包（固实压缩），然后就变成了视频吧。（大概）
然后楼主认为，压缩程序应该能够提取出这些图片间的相似处，达到更高的压缩率。所以我们为什么不用压缩软件来压缩视频？

[TK4E]

二进制数据体积很大 所以用了无损压缩
无损压缩的数据体积很大 所以用了有损压缩
而视频编码里也有使用去重这一操作

[kkocdko]

这个问题就像水洗煤一样。。。

建议先拓宽自己的知识面，起码先看看 h264 ，或者看看 vp8 也许更简单一些（对的其实我并不懂 h264 ），就会发现从前的自己是多么渺小。你所指出的这一切都是非常原始的说法，贻笑大方罢了。

[zhs227]

单 Huffman 无法消除时域上的重叠。而视频压缩中的 I/P/B 是利用了时域上有很大相似性的特点来达到更高的压缩比。所以，为什么不能只用 Huffman ，因为 Huffman 的限定范围在一帧之内。

[misdake]

@nthhdy

文本有无损的硬性需求，即使压缩率低也没办法。
图片和视频没有无损的硬性需求，相反，尤其是视频因为原始内容太大太大，超高压缩率是很多情况下的硬性要求。

另外你说的运动预测你说的是对的，不管有损无损，都可以提高压缩比。（不过这个就不是熵编码的范畴啦）
不少提到的方法最后都要经过一次熵编码，但感觉就像是最后的万金油方法或者兜底方法，而不是真正压缩数据的地方。

[tinybaby365]

jpeg 格式里面就有使用 huffman 编码啊，但 jpeg 中主要压缩的方法是离散余弦变换（用信号处理的方式实现有损压缩）

[microxiaoxiao]

你这个套路明显有问题，可以适合已知所有图片。但是真实的环境中存在大量实时视频，比如监控，直播，会议等，码流持续产生。那你这时候咋计算，或者大幅运动的情况下，你那种商编也不行了，有损压缩能大福提高传输，存储效率。

[microxiaoxiao]

编码器里面有多趟编码的说法，可以进一步压缩。和你说的这个商编码套路有点类似。不适合实时编码。实时编码主要就靠压缩，补偿，然后不断插入 I 帧，然后 P ，B 帧前后预测比对，编码标准本身会对各种场景和业务形态进行不同处理。

[systemcall]

你知道一分钟的 1080p30 RGB888 ，是多大吗？
你可以用 bmp 格式保存一段视频的每帧画面，看看有多大，再丢到 7zip 或者 WinRAR ，看能压缩多少