这就是问题 - 我想在服务器上生成二进制文件的增量（大小> 1 MB），并通过HTTP将增量发送到内存受限（低RAM和无动态内存）嵌入式设备。 Deltas是首选（而不是从服务器发送完整的二进制文件），因为通过网络传输数据涉及高成本。
麻烦的是，嵌入式设备无法解码增量并在内存中创建新文件的内容。我已经研究了各种二进制增量编码/解码算法，如bsdiff，VCDiff等，但无法找到支持流媒体的库。
也许，而不是询问是否有合适的库，是否有其他方法可以解决原始问题（通过线路发送最少的数据）？虽然如果有合适的delta库支持流解码（用C或C ++编写而不使用动态内存），肯定会有所帮助。
答案 0 :(得分：8)
在嵌入式设备保留的当前文件的服务器上维护一份副本。如果要发送更新，请使用旧版本对文件的新版本进行XOR，并使用任何合理的压缩器压缩生成的流。 （允许高成本编码以允许低成本解码的算法在这里特别有用。）将压缩流发送到嵌入式设备，嵌入式设备读取流，对其进行即时解压缩，并直接对目标进行XOR（副本）文件。
如果您的更新使文件内容随时间变化很小并保留固定结构，则XOR流将主要为零，并且将非常好地压缩：传输的字节数将很小，解压缩的工作量将会很低，嵌入式设备的内存要求将是最小的。你的模型离这些假设越远，这种方法就越少。
答案 1 :(得分：3)
由于你说delta可以是任意随机的（从零delta到完全不同的文件），delta的压缩可能是一个失败的原因。无理压缩随机二进制数据在理论上是不可能的。此外，由于嵌入式设备无论如何都具有有限的内存，因此使用复杂的 - 因此计算上昂贵的 - 用于压缩/解压缩偶尔的“简单”delta的库可能是不可行的。
我建议只是以原始字节格式将新文件发送到设备，并覆盖现有的旧文件。
答案 2 :(得分：2)
正如凯文所说，压缩随机数据不应该是你的目标。关于您使用的数据类型的一些评论会有所帮助。上下文是压缩的关键。
您使用了术语“图像”，这听起来像是经典的视频编解码器挑战。如果您曾经看到过奇怪的视频锯齿效果会影响已更改的帧部分，然后突然一切都会清除。您可能已经目睹了关键帧的概念以及一系列增量帧。三角形框架没有正确应用的地方。
在这个模型中，服务器决定什么更便宜：
delta命令作为一系列写指令进行通信，这些指令可以覆盖客户端现有的缓冲区。
示例格式：
可能有多种方法可用于计算这些delta命令。蛮力方法是：