使用哪个压缩库压缩 10 到 20 个高度冗余的图像？
我将每分钟左右从低分辨率相机生成一次图像。我想运行 10 到 20 个图像并对其进行压缩，以便通过带宽非常有限的通道进行传输。我曾考虑过使用 x264，但感觉有点过头了。
鉴于我的图像为 320x240，帧之间具有高度冗余，那么最好的方法是什么？
编码不必特别快，更多的是在嵌入式设备上实现的难度和总文件大小的减小之间找到平衡。
我将完全控制查看软件，因此使用某些压缩方案的修改版本就可以了。
我将使用 freeRTOS
I am going to be generating images once every minute or so from a low resolution camera. I would like to take runs of 10 to 20 images and compress them for transmission over a very bandwidth limited channel. I have looked at using x264 but it feels like over kill.
Given that my images are 320x240, with high level of redundancy between frames, what would be the best way to go?
The encoding does not have to be particularly fast, its more about finding a balance between difficulty in implementing on an embedded device, and the reduction in total file size.
I will have full control over the viewing software, so using a modified version of some compression scheme would be ok.
I will be using freeRTOS
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一种简单而可靠的方法是将每个帧编码为 JPEG。这可以呈现为 M-JPEG 流。压缩通常是不错的，即使不是最佳的。如果这对你来说足够好，那就去吧。
A simple and robust way to do this is to just encode each frame as a JPEG. This may be presented as an M-JPEG stream. Compression usually is decent, even if not optimal. If this is good enough for you, go for it.
该设备有 libavcodec 端口吗？我认为它内置了 h.264 编码器。我不认为 h.264 是大材小用。
不过，定义“带宽有限”。如果您有足够的带宽以每像素 1 位进行传输（即以 1 帧/分钟的频率每秒 160 字节），则无需超出 jpeg。如果您的数据甚至少于此数量，则需要进行时间压缩（某种 MPEG）。
Is there a port of libavcodec to that device? I think it has a h.264 encoder built in. I don't think that h.264 is overkill.
Define "bandwidth limited", though. If you have enough bandwidth to transmit at 1 bit per pixel (that would be 160 bytes per second at 1 frame/minute frequency), you don't need to go beyond jpeg. If you have even less than that, temporal compression (some kind of MPEG) is warranted.
为什么 x264 太过分了？它是一个非常高效的编码器，如果您想利用时空冗余，您需要使用 H.264 等压缩算法，而不是一堆 JPEG。
Why is
x264overkill? It's a really efficient encoder and if you want to exploit spatio-temporal redundancy, you need to use compression algorithms like H.264 instead of a bunch of JPEGs.在嵌入式系统中，H.264 是一种过度杀伤力，因为编码需要计算，解码也需要计算。使用 ffmpeg 更重要（因此也是多余的）是 ffmpeg 有大约 150 个编解码器。因此移植它们也成为一个问题。
一个更简单的方法是查看 IJG 是否可以在您的系统中移植。 （因此，这被发现在各种平台上是最可移植的。
在这种情况下，您可以在连续帧之间应用简单的帧差异，并将它们制作为单独的 JPEG。如果存在冗余，则后续 JPEG 的大小将会小得多。
在练习之前移植时，您应该只检查冗余是否确实有助于降低比特率。
In an embedded system, H.264 is an overkill because encoding requires computation and so is decoding. What is even more important (and hence overkill) to use ffmpeg is the fact that ffmpeg has some 150 odd codecs. So porting them becomes a problem too.
A simpler approach is to see if IJG's is portable in your system. (As such this is found to be most portable on various platforms.
In this case, you can apply simple frame difference between consecutive frames and make individual JPEG of them. If there is redundency, the subsequent JPEG's will be much lesser size.
Before exercising the porting, you should just check if the redundancy is indeed helping the reduction of bit rate.