如果ffmpeg所用的汇编使用nasm/yasm兼容的语法就好了.
不过,对于解静态图像来说,不用汇编优化速度也是可以接受的.

遇到像clannad右键菜单这样的情况，速度还是挺重要的吧。

能不能考虑将比较小的图合并成一张大图，这样能提高压缩率，解码速度并降低cache miss

那种情况做好cache比用汇编优化有效得多.

我觉得合并成大图更有效，只需要解码一次，一个cache

合并成大图管理起来比较麻烦,还不如改用一个比较好的cache策略,比如用LRU代替简单的hash slot.

不是，因为图的大小不同，所以固定的hash slot利用率低。

需要合并的小图文件名上一定有规律，管理起来不麻烦。

当然一切都只是建议

UCI的各个环节已经完成,初步测试发现,使用相同的压缩参数,我解出来的图像比mencoder解出来的质量稍微差一点,可能是因为YUV变换,平均/插值算法不够好.

还是推荐用swscale

好吧,经过尝试和对比,决定使用swscale缩放和YUV转换.
PS: 用VC编译ffmpeg的部分代码速度奇慢.

把GCC内嵌汇编改成VC内嵌汇编

我暂时还没办法转换内嵌汇编,而且工作量很大,对于只解单帧来说,无优化的速度已经可以接受了.hd-photo的源代码也没有汇编优化.
打算再过一周的调整,完善,测试再发布.

ffmpeg用VC编译会遇到大堆的warnings,不知道是开发人员故意忽略还是gcc没有发现这些.
多数是降低精度的类型转换,有无符号整数的比较,未引用的局部变量,不过也见到过使用未初始化局部变量的警告,不知道VC编译之后会不会产生错误的指令,只能期盼测试无误了.

用gcc编译ffmpeg你会被warning刷屏的。
对warning基本都是无视�

目前测试还算不错,swscale的lanczos缩放效果比较理想,速度也很快.
不过像x264这种压缩方式感觉有点像HE-AAC的做法了,就是说开始用欺骗眼睛的手法达到高压缩率下保证最佳的主观图像质量.如果与原图用PSNR对比,x264根本比不过同等文件大小jpeg2000和hd-photo.
我想有损压缩的极限就是要以保证主观感觉为主吧.

D大终于也觉悟了。PSNR，SSIM基本无用，一切以人的感觉为依据，不然也不会有AQ,Psy-RDO了。

另外用psnr来比wavelet绝对是占优势的�