为什么S3C6410的JPEG硬解码如此慢??

白植景 2010-08-09 09:14:02
各位早上好,
我在6410上测试JPEG解码速度,发现其所谓的“硬解码”性能实在不敢恭维!不知各位是否进行过测试?我测得其在解码640x480的JPEG图片竟然要平均花费40ms左右,也就是解码性能才25fps,甚至在320x240分辨率下比我们自己的软解码性能还要差(软解10ms,硬解15ms)。这太离谱了?诸位有何高见。
...全文
533 10 打赏 收藏 转发到动态 举报
写回复
用AI写文章
10 条回复
切换为时间正序
请发表友善的回复…
发表回复
knoxlove 2011-09-29
  • 打赏
  • 举报
回复
不知道楼主有没有用6410将YUV420硬编码为JPEG呢? 例程里的好像是YUV422图像才能编码哦
superliuqp 2010-08-23
  • 打赏
  • 举报
回复
我也遇到了类似的问题,解码加显示大概在60~70ms之间,挺慢的。另外我还遇到了另外一个问题,就是我用BSP里的JPGAPI,在解了96张640*480的图片后SsbSipJPEGGetDecodeInBuf这个函数就会返回NULL和DD::JPG VirtualFreeEx(STRM_BUF) returns FALSE.这个提示,然后就不能解码了。SsbSipJPEGGetDecodeInBuf这个函数的内容就是获取Stream Buffer(IOCTL_JPG_GET_STRBUF)。不知道楼主有没有遇到过类似问题。
白植景 2010-08-14
  • 打赏
  • 举报
回复
测试方法很简单,就是读取一帧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耗费最多时间。
难道没有人测试过吗?
chinesedragon2010 2010-08-14
  • 打赏
  • 举报
回复
楼主是如何测试的?不知是否可以告知测试方法?
CyberLogix 2010-08-14
  • 打赏
  • 举报
回复
应该不会这么慢,是不是那里设置的不太对啊,
VCLIFE 2010-08-12
  • 打赏
  • 举报
回复
[Quote=引用 4 楼 fankyo 的回复:]
软解和硬解有啥区别啊?
[/Quote]
区别就是硬和软

硬件直接运算肯定比你编软件快多路
躺着享受 2010-08-12
  • 打赏
  • 举报
回复
软解和硬解有啥区别啊?
myearth 2010-08-09
  • 打赏
  • 举报
回复
[Quote=引用 1 楼 lbqhope 的回复:]
我觉得这是很有可能的,因为MFC就一堆问题,吹嘘多强多强,实际上根本就不是那么回事。
[/Quote]

多举几个例子;
关于jpeg解码我试过,不过没有算时间,你说40ms数据我觉得有问题。
MFC bsp可能有些bug,不过它的性能不是吹嘘的,是实在的。基本的性能的参数没法吹嘘
VCLIFE 2010-08-09
  • 打赏
  • 举报
回复
关注此贴。MFC真的这么差劲?
DAISARU 2010-08-09
  • 打赏
  • 举报
回复
我觉得这是很有可能的,因为MFC就一堆问题,吹嘘多强多强,实际上根本就不是那么回事。

19,502

社区成员

发帖
与我相关
我的任务
社区描述
硬件/嵌入开发 嵌入开发(WinCE)
社区管理员
  • 嵌入开发(WinCE)社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧