我们在小型嵌入式平台上使用libjpeg进行JPEG解码。解码大图像时,速度有问题。例如,大小为20 MB且尺寸为5000x3000像素的图像需要10秒钟才能加载。
我需要一些关于如何提高解码速度的技巧。在具有类似性能的其他平台上,我在两秒钟内拥有相同的图像负载。
从使用更大的读缓冲区(64 kB而不是默认4 kB)获得的最佳时间从14秒减少到10秒。但没有别的帮助。
我们不需要以全分辨率显示图像,因此我们使用scale_num和scale_denom以较小的尺寸显示它。但我希望有更多的表现。是否可以使用某种多线程等?不同的解码设置?什么,我的想法。
答案 0 :(得分:4)
首先 - 描述代码。如果你无法明确地确定瓶颈,那么你只剩下猜测。
接下来,搜索libjpeg加速机会的文档。您提到了scale_num
和scale_denom
。解压缩器dct_method
怎么样?我发现DCT_FASTEST
选项很好。还有其他选项需要检查:do_fancy_upsampling
,do_block_smoothing
,dither_mode
,two_pass_quantize
等。根据您的系统,libjpeg可能对您有用。版本等
如果分析工具不可用,仍有一些事情要尝试。首先,我怀疑你的瓶颈与非CPU有关。要确认,请将未压缩的图像加载到RAM缓冲区中,然后像往常一样从那里解压缩。这是否显着改善了减压时间?如果是这样,罪魁祸首似乎是图像存储介质的读取操作。根据您的系统,从USB(或SD等)读取可能会很慢。 (请注意,我假设从外部媒体读取 - 虽然硬件细节很少。)请务必优化相关的总线参数(SPI时钟,配置等)。
如果您正在阅读内部闪存(即NAND)等内容,还需要检查其他一些内容。你的NAND控制器是如何配置的?您是否确保控制器配置为最快的操作?检查等待状态,时间等。请注意,总线和/或内存争用也是一个问题 - 所以也要检查它们各自的配置。
最后,如果您认为您的系统实际上是CPU绑定的,那么这个stackoverflow问题可能会引起关注: Can a high-performance jpeglib-turbo implmentation decompress/compress in <100ms?
答案 1 :(得分:2)
如果目标有多个执行单元用于真正的并发执行,则多线程只能帮助解码过程。否则它只会对现有的CPU资源进行时间分片。除非图书馆的设计是利用它,否则无论如何都无济于事。
如果你从源代码构建了库,首先应该确保在开启优化的情况下构建它,并仔细选择编译器选项以使构建与目标及其指令集相匹配,以使编译器能够使用SIMD或例如FPU。
此外,您还需要考虑其他可能的瓶颈。 10秒只是解码的时间,还是包括从文件系统或网络读取的时间?鉴于当您增加读取缓冲区大小时观察到的改进,似乎很可能它是数据读取而不是在这种情况下限制的解码。
如果实际上文件系统访问是限制因素而不是解码,那么在单独的线程中分离从解码中读取的文件并通过管道传递数据可能会有一些好处或队列或多个共享内存缓冲区到解码器。然后,您可以确保解码器可以流式传输解码,而无需等待文件系统阻塞。
答案 2 :(得分:2)
查看 libjpeg-turbo 。如果您支持硬件,那么它通常比同一CPU上的libjpeg快2-4倍。 Tipand 12MB jpeg在Pandaboard上的解码时间不到2秒。您还可以查看各种JPEG解码器 here 的速度分析。