视频十六进制稍改就不合法，压缩算法不够好？

不限于视频，各类音视频格式都可拿来举例。首先，第一个方面，所谓随便改一改就不合法其实是个运气问题。A.要是运气不佳，修改的数据处于Block或者Token头部的关键信息之处，像是首部验证的幻数（magic numbers）、图片的长与宽、格式类型、音频采样率等，这就极有可能造成格式解析错误。而且，不管是h264、jpg还是png，都带有无损压缩编码，这类编码通常是类似范式哈夫曼（huffman）编码的变种。改动这部分数据的话，哈夫曼树的符号表（symbols table）极有可能重建失败。就如今流媒体比较流行的情况而言，很多音视频都是按照Block、Token、Frame来进行分片存储的。这部分数据一旦被破坏，就很可能致使这部分的Block（Token）解码失败。不过一般来讲问题不大，后续的分片能够正确解码，对整体的观看和收听感受不会有太大的影响（当然，对于帧间编码而言，一帧出错可能会影响好几帧……）。B.要是运气稍微好一点，修改的是数据部分的内容，这其实也分两种情形。如果是运气较好情况里更好一点的，那么数据仍然能够正常解码，不过是一小部分像素或者音频不正确，甚至都看不出来、听不出来差别。可要是运气差一点，就很可能导致无损解码失败，因为数据不一致之后，解码长度很可能也不一致，从而导致后面的数据像滚雪球一样一错全错。所以，很多水平不高的码农，既不想调用比较成熟的解码器解码包，又本事不大野心不小非要自己编写解码器，就很有可能在这部分解码时出问题，进而导致软件崩溃。所以，其实导致稍作修改就出错的最大根源主要在于压缩中的无损压缩部分。因此像bmp这种无压缩的格式，其鲁棒性要强于做了无损压缩的格式。其次，第二个方面，说压缩算法没有任何无用信息，这是不对的！尽管在个别情况下能够逼近到熵编码的理论极限。但是哈夫曼编码的性能和输入数据的概率分布紧密相关。所以在实际应用中，这种极限几乎只存在于理论之中。这也是为什么多数多媒体格式会在哈夫曼编码之前，采用LZW、Zigzag、差分运算对数据进行预处理（例如LZ77有个前向搜索范围，这个范围越大就代表其预处理压缩的效果越好，当然性能消耗也越大）。在当前的压缩体系下，没有一种单一的压缩算法适用于所有信息（没有免费午餐定理），香农无失真信源编码在绝大多数情况下只能无限逼近而无法达到。