鸡蛋灌饼 发表于 2011-1-12 22:22

引用第39楼belatedeffort于2011-01-12 21:01发表的:

看上去QS压出的没x86那么锐利（当然也可能是我眼睛的问题）。不过据某些大大（具体是谁不记得了）说有时候看着比较舒服的柔和恰恰是质量没那么好的体现。 images/back.gif

这个是
看上去柔和那是压制的时候高频没保留下来的缘故

superkidx 发表于 2011-9-4 20:40

sakamoto 发表于 2011-9-4 21:00

压动画请用x264开hi10p，否则惨不忍睹...

superkidx 发表于 2011-9-4 22:06

dahuatttt 发表于 2011-9-4 23:42

有人挖坟！我来mark下。。。

Elisha 发表于 2011-9-5 00:08

eureka9 发表于 2011-9-6 22:06

引用第32楼Castiel于2011-01-12 00:28发表的:
现阶段基于dct的图像压缩, 都是以方块来处理的, 但是要达到合适的质量, 这个方块大小应该是根据图片来的, 然后分成64x64, 32x32, 16x16, 8x8丢给处理线程.
所谓预处理就是来算最合适的分块.
对于CPU来说不同大小分块影响不大, 线程数不多也可以一个个来.
对于cuda来说如果大分块多, 剩下的所有处理单元就要等大分块完成才能进行下一帧, 由于所谓GPGPU单线程性能非常悲剧, 那么并行化得到的性能提升说不定是负的.
如果cuda直接把所有图像都8x8了, 那么的确无比快, 但是损失质量或者码率. 个人觉得anand的测试结果反映的就是这个问题, 和计算精度没啥关系.
....... images/back.gif


现在的问题就是h264标准里面DCT的部分从一开始就是给硬件而非软件设计的，精度不够，扔进帧内/帧间预测负反馈循环里。只要碰上预测这件事并行很难处理的好，大概是因为Synchronize的原因，纵使百千sp，快的总是在等慢的处理完才能进行下一步

不管是4*4和8*8的DCT正交阵都想用尽量少的位运算而不是位长较短的浮点运算来完成，软硬件实现是方便了，CUDA就吃瘪，除非他能定义出自定义位长的RGB值和中间计算值（比如10bit 12bit）之类的去做DCT和预测，DCT精度提高，预测步骤也会极大的节省。

鸡蛋灌饼你h264的pdf看完了么顺便提一句，h264算法具体操作的时候，可以直接高频分量置0，尤其对待警车那种图，简单粗暴有效。一般残差数据只有整数，又比较接近对数正态分布，0附近的高频分量真是早死早超生就可以了

鸡蛋灌饼 发表于 2011-9-7 11:04

引用第46楼eureka9于2011-09-06 22:06发表的:

鸡蛋灌饼你h264的pdf看完了么顺便提一句，h264算法具体操作的时候，可以直接高频分量置0，尤其对待警车那种图，简单粗暴有效。一般残差数据只有整数，又比较接近对数正态分布，0附近的高频分量真是早死早超生就可以了images/back.gif

最近在玩驱动，有阵子不会有精力搞这个……
你们先聊我先走了

AfterFX 发表于 2011-9-7 11:58

警车那个锯齿明显是傻逼小编脑袋进屎 截图完了缩放的时候搞砸了
怎么还有人拿这个说事？

QS比x86好？啧啧

skywolfox 发表于 2011-9-8 15:11

这坑挖的
页: 1 [2]
查看完整版本: Intel SNB处理器内置视频编码引擎与纯软件和GPU编码速度和品