我们在我们的小型嵌入式平台上使用libjpeg进行JPEG解码。当我们解码大图像时,我们遇到了速度问题。例如,大小为20MB、大小为5000x3000像素的图像需要10秒才能加载。
我需要一些关于如何提高解码速度的提示。在其他性能相似的平台上,我在两秒内加载了相同的镜像。
通过使用更大的读取缓冲区(64 kB而不是默认的4 kB),我们可以从14秒最好地减少到10秒。但其他的都没有帮助。
我们不需要以全分辨率显示图像,因此我们使用scale_num和scale_denom来以较小的尺寸显示它。但我希望能有更好的表现。是否可以使用某种类型的多线程等?不同的解码设置?任何事,我都会想个不停。
发布于 2014-02-26 03:35:14
首先-分析代码。如果您不能明确地确定瓶颈,那么您只剩下猜测。
接下来,在文档中搜索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限制的,那么这个堆栈溢出问题可能会很有趣:Can a high-performance jpeglib-turbo implmentation decompress/compress in <100ms?
发布于 2014-02-25 04:27:55
只有当目标有多个执行单元用于真正的并发执行时,多线程才能帮助解码进程。否则,它只会对现有的CPU资源进行时间切片。它在任何情况下都不会有帮助,除非库是设计或使用它的。
如果从源代码构建库,首先应该确保在打开优化的情况下构建它,并仔细选择编译器选项以使构建与目标及其指令集相匹配,以使编译器能够使用SIMD或FPU等。
此外,您还需要考虑其他可能的瓶颈。例如,这10秒是仅用于解码的时间,还是包括从文件系统或网络读取的时间?考虑到在增加读取缓冲区大小时观察到的改进,在这种情况下,限制的似乎很可能是数据读取而不是解码。
如果文件系统访问实际上是限制因素而不是解码,那么在单独的线程中分离从解码读取的文件并通过管道或队列或多个共享内存缓冲区将数据传递到解码器可能会有一些好处。然后,您可以确保解码器可以对解码进行流式处理,而不必等待文件系统阻塞。
发布于 2014-02-26 18:58:52
看看吧。如果您有支持的硬件,那么在相同的CPU上,它通常比libjpeg快2-4倍。在Pandaboard上,Tipical 12MB jpeg的解码时间不到2秒。你也可以看看各种JPEG解码器的速度分析。
https://stackoverflow.com/questions/21997523
复制相似问题