我在6410上测试JPEG解码速度，发现其所谓的“硬解码”性能实在不敢恭维！不知各位是否进行过测试？我测得其在解码640x480的JPEG图片竟然要平均花费40ms左右，也就是解码性能才25fps，甚至在320x240分辨率下比我们自己的软解码性能还要差(软解10ms，硬解15ms)。这太离谱了？诸位有何高见。
10 个解决方案
#1
我觉得这是很有可能的，因为MFC就一堆问题，吹嘘多强多强，实际上根本就不是那么回事。
#2
关注此贴。MFC真的这么差劲？
#3
多举几个例子；
关于jpeg解码我试过，不过没有算时间，你说40ms数据我觉得有问题。
MFC bsp可能有些bug，不过它的性能不是吹嘘的，是实在的。基本的性能的参数没法吹嘘
#4
软解和硬解有啥区别啊？
#5
区别就是硬和软
硬件直接运算肯定比你编软件快多路
#6
应该不会这么慢，是不是那里设置的不太对啊，
#7
楼主是如何测试的？不知是否可以告知测试方法？
#8
测试方法很简单，就是读取一帧JPEG图片送到JPEG解码器进行解码，测试解码耗费的时间即可。6410的JPEG解码过程如下：初始化用CreateFile打开"JPG1:"解码驱动，每次解码首先要获取Stream Buffer(IOCTL_JPG_GET_STRBUF)，将JPEG数据拷贝到Stream Buffer，接着调用解码(IOCTL_JPG_DECODE)，最后通过获取Frame Buffer(IOCTL_JPG_GET_FRMBUF)得到解码后数据。整个过程中获取Stream Buffer和Frame Buffer的时间耗费非常少，主要是Decode耗费最多时间。
难道没有人测试过吗？
难道没有人测试过吗？
#9
我也遇到了类似的问题，解码加显示大概在60~70ms之间，挺慢的。另外我还遇到了另外一个问题，就是我用BSP里的JPGAPI，在解了96张640*480的图片后SsbSipJPEGGetDecodeInBuf这个函数就会返回NULL和DD::JPG VirtualFreeEx(STRM_BUF) returns FALSE.这个提示，然后就不能解码了。SsbSipJPEGGetDecodeInBuf这个函数的内容就是获取Stream Buffer(IOCTL_JPG_GET_STRBUF)。不知道楼主有没有遇到过类似问题。
#10
不知道楼主有没有用6410将YUV420硬编码为JPEG呢？ 例程里的好像是YUV422图像才能编码哦
#1
我觉得这是很有可能的，因为MFC就一堆问题，吹嘘多强多强，实际上根本就不是那么回事。
#2
关注此贴。MFC真的这么差劲？
#3
多举几个例子；
关于jpeg解码我试过，不过没有算时间，你说40ms数据我觉得有问题。
MFC bsp可能有些bug，不过它的性能不是吹嘘的，是实在的。基本的性能的参数没法吹嘘
#4
软解和硬解有啥区别啊？
#5
区别就是硬和软
硬件直接运算肯定比你编软件快多路
#6
应该不会这么慢，是不是那里设置的不太对啊，
#7
楼主是如何测试的？不知是否可以告知测试方法？
#8
测试方法很简单，就是读取一帧JPEG图片送到JPEG解码器进行解码，测试解码耗费的时间即可。6410的JPEG解码过程如下：初始化用CreateFile打开"JPG1:"解码驱动，每次解码首先要获取Stream Buffer(IOCTL_JPG_GET_STRBUF)，将JPEG数据拷贝到Stream Buffer，接着调用解码(IOCTL_JPG_DECODE)，最后通过获取Frame Buffer(IOCTL_JPG_GET_FRMBUF)得到解码后数据。整个过程中获取Stream Buffer和Frame Buffer的时间耗费非常少，主要是Decode耗费最多时间。
难道没有人测试过吗？
难道没有人测试过吗？
#9
我也遇到了类似的问题，解码加显示大概在60~70ms之间，挺慢的。另外我还遇到了另外一个问题，就是我用BSP里的JPGAPI，在解了96张640*480的图片后SsbSipJPEGGetDecodeInBuf这个函数就会返回NULL和DD::JPG VirtualFreeEx(STRM_BUF) returns FALSE.这个提示，然后就不能解码了。SsbSipJPEGGetDecodeInBuf这个函数的内容就是获取Stream Buffer(IOCTL_JPG_GET_STRBUF)。不知道楼主有没有遇到过类似问题。
#10
不知道楼主有没有用6410将YUV420硬编码为JPEG呢？ 例程里的好像是YUV422图像才能编码哦