我将每分钟左右从低分辨率相机生成一次图像。我想运行 10 到 20 张图像并压缩它们,以便在带宽非常有限的通道上传输。我看过使用 x264,但感觉就像杀了一样。
鉴于我的图像是 320x240,帧之间具有高度冗余,那么最好的方法是什么?
编码不必特别快,它更多的是在嵌入式设备上实现的难度和总文件大小的减小之间找到平衡。
我将完全控制查看软件,因此可以使用一些压缩方案的修改版本。
我将使用 freeRTOS
我将每分钟左右从低分辨率相机生成一次图像。我想运行 10 到 20 张图像并压缩它们,以便在带宽非常有限的通道上传输。我看过使用 x264,但感觉就像杀了一样。
鉴于我的图像是 320x240,帧之间具有高度冗余,那么最好的方法是什么?
编码不必特别快,它更多的是在嵌入式设备上实现的难度和总文件大小的减小之间找到平衡。
我将完全控制查看软件,因此可以使用一些压缩方案的修改版本。
我将使用 freeRTOS
一种简单而可靠的方法是将每一帧编码为 JPEG。这可以呈现为M-JPEG流。压缩通常是不错的,即使不是最佳的。如果这对你来说足够好,那就去吧。
该设备是否有 libavcodec 端口?我认为它内置了一个 h.264 编码器。我认为 h.264 并不过分。
不过,请定义“带宽受限”。如果您有足够的带宽以每像素 1 位传输(即 1 帧/分钟频率下每秒 160 字节),则无需超出 jpeg。如果你有更少的,时间压缩(某种MPEG)是有保证的。
为什么是x264
矫枉过正?这是一个非常高效的编码器,如果你想利用时空冗余,你需要使用像 H.264 这样的压缩算法而不是一堆 JPEG。
在嵌入式系统中,H.264是一种过度杀伤力,因为编码需要计算,解码也是如此。使用 ffmpeg 更重要(因此是过度杀伤)是 ffmpeg 有大约 150 个奇怪的编解码器。所以移植它们也成为一个问题。
一种更简单的方法是查看IJG在您的系统中是否可移植。(因此,这被发现在各种平台上最便携。
在这种情况下,您可以在连续帧之间应用简单的帧差,并将它们单独制作为 JPEG。如果存在冗余,则后续 JPEG 的尺寸会小得多。
在执行移植之前,您应该只检查冗余是否确实有助于降低比特率。