Intel SNB处理器内置视频编码引擎与纯软件和GPU编码速度和品

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

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

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

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

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的测试结果反映的就是这个问题, 和计算精度没啥关系.
.......

现在的问题就是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附近的高频分量真是早死早超生就可以了

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

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

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

QS比x86好？

啧啧

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

这坑挖的

		自动登录	找回密码
密码			立即注册

[硬件] Intel SNB处理器内置视频编码引擎与纯软件和GPU编码速度和品

浏览过的版块

superkidx superkidx 当前离线禁止发言精华 \| 战斗力鹅 \| 回帖 0 注册时间 2007-5-7 头像被屏蔽	发表于 2011-9-4 20:40 \| 显示全部楼层提示: 作者被禁止或删除内容自动屏蔽

	回复使用道具举报

superkidx superkidx 当前离线禁止发言精华 \| 战斗力鹅 \| 回帖 0 注册时间 2007-5-7 头像被屏蔽	发表于 2011-9-4 22:06 \| 显示全部楼层提示: 作者被禁止或删除内容自动屏蔽

	回复使用道具举报

Elisha Elisha 当前离线禁止发言精华 \| 战斗力鹅 \| 回帖 0 注册时间 2005-8-22 头像被屏蔽	发表于 2011-9-5 00:08 \| 显示全部楼层提示: 作者被禁止或删除内容自动屏蔽

	回复使用道具举报