分页: 1 / 3

[原创]Windows和Linux下的高清解码CPU负载对比(附图)

发表于 : 2008-04-07 20:47
intel08
最近拿到了一款Intel T2300的嵌入式式平台,虽说是嵌入式平台,但PC该有的接口都有了,插上一堆东西连WinXP和Ubuntu都能装,就当个小台式机用了。

具体配置是CPU Intel T2300 1.66G /945GME /1G RAM .最近要做些涉及高清的作业就顺带着做了下该平台的播放测试。

本人在Linux方面只能算菜鸟级别,测试结果大家随便看看,后面还有些问题要请教大家。

测试用了3种不同码率的片源

片源一 DeepBlue(就是那个深蓝) 码率20Mbps 封装ts 格式H264 FPS:25 分辨率1440x1088

片源二 FishCut(实验室自己录的) 码率10Mbps 封装ts 格式H264 FPS:30 分辨率1920x1088

片源三 PlanetEarth(BBC的) 码率7Mbps 封装mkv 格式H264 FPS:24 分辨率1280x720



WindowsXP下的播放软件为 终极解码7.0908

采用默认配置,其中H264解码器为CoreAVC

三个片源均可流畅播放

三个片源的CPU负载情况如下

片源一 DEEPBLUE

图片

片源二 FISHCUT

图片
片源三 PLANETEARTH

图片



Linux采用的Ubuntu7.10Desktop

播放器 Mplayer pre8 编译安装,解码器来自ffmpeg解码库

片源一和二均出现too many video packets in the buffer的警告,画面延迟严重,也就是说CPU跑不动了

片源三在图像动态较激烈的时候会有很明显的丢帧。

CPU负载情况如下

片源一DEEPBLUE

图片

片源二FISHCUT

图片

片源三PLANETEARTH

图片



大家是不是都发现了,在Windows下,CPU的两个核的负载是较均衡的,也就是说CoreAVC经过了较好的多线程优化,能够充分利用CPU的双核资源进行解码工作。

而在Linux下,始终是一个核再承担解码工作。

这也正是CoreAVC解码效率高的重要原因之一。但是CoreAVC目前只有Windows版本。

如果将VCoreAVC移植到Linux下,不就提高了Linux下的高清解码效率了么~

有位高人已经在Unbuntu上发过一篇CoreAVC for linux的帖子

[url]viewtopic.php?t=86660



这里面通过SVN版本的mplayer成功的使用了CoreAVC解码器。

这两天在按照上面的步骤去做,却始终没能成功。

问题在于没有用过svn,按照网上的说明配置了一下,

当进行

svn checkout http://coreavc-for-linux.googlecode.com/svn/trunk/ coreavc-for-linux

出现如下错误信息:
svn: 对“%$s”的请求 %$s 失败
svn: 对“%$s”的方法 %$s 失败: Could not resolve hostname `coreavc-for-linux.googlecode.com': No address associated with hostname (http://coreavc-for-linux.googlecode.com)
不知是svn配置的不正确还是其他原因?
请各位指教。

发表于 : 2008-04-07 20:54
intel08
哎呀...
图的顺序反了...

发表于 : 2008-04-07 21:07
skyx
codecs 不一回事,这样对比没有任何意义。

发表于 : 2008-04-07 21:51
intel08
这实际上不就是
CoreAVC和ffmpeg两种Codecs效率的对比么

由于解码工作的串行性,本身做Multi-threads优化的难度比较大,但CoreAVC做到了
在MPEG2等格式解码工作量不大的情况下不做Multi-threads优化是可以接受的
但对于码率超过10Mbps的H264视频,依然采用单线程的ffmpeg库,我觉得这是Linux下高清播放的一个瓶颈。

发表于 : 2008-04-07 22:09
eexpress
而在Linux下,始终是一个核再承担解码工作。
不会的。我这里,明显可以看到2个动的。

估计都是些解码器,需要跟进的事情。

发表于 : 2008-04-08 7:30
froce
大概是dns出問題...
自己看看 http://coreavc-for-linux.googlecode.com/svn/trunk/
能不能用firefox進去...

至少在台灣是能svn的...

发表于 : 2008-04-08 9:22
intel08
果然是DNS的问题
现在已经可以checkout了
非常感谢~~~~

发表于 : 2008-04-08 9:25
ildg
楼主说得太对了。
CoreAVC确实很牛的东西,
不过是要钱的哦,
15美刀,
如果真的有linux的版本,
我愿意付钱,
因为我经常看碟。

linux下面确实只用一个cpu解码,
我也注意到了,
不过今天看了这个帖子,
就更加确信了。

发表于 : 2008-04-08 9:32
yiding_he
多核 CPU 不会自行将一个线程的任务进行均衡,大计算任务的并行化需要依靠程序自己来分配。所以楼主提出的问题不在于操作系统本身,而是解码器是否能依据多核环境进行优化。

发表于 : 2008-04-08 11:15
skyx
看来amd的反多核技术能解决这个问题

 反双核应是芯片级,让多个cpu核当一个核用来提升没有针对多核优化程序的性能。

发表于 : 2008-04-08 11:29
hcym
CoreAVC解码器播放H264。

远不是效率最高的,但是比ffmpeg好点。但还属于软解加速的范畴

楼主再试试CyberLink(DXVA)

播放码率峰值过40Mbps 封装ts 格式H264的后窗惊魂

还有个世界自然遗产。

即便关闭CyberLink(DXVA)的硬件加速也比CoreAVC好

唉,在这谈HDTV,没几个靠谱

发表于 : 2008-04-08 12:53
intel08
DXVA指的是硬件视频加速接口吧,硬解效率当然要高,但是驱动和厂商的限制很难让硬解在其在非PC平台上工作。
很多嵌入式平台不会配有PCI-EX16接口,更不会用WinXP系统,
所以软解码依然是很多人研究的热点。

不知道CyberLink在软解码的时候调用的是什么解码器,但264的解码器无非就那几种,
而且264的解码算法不会有质的飞跃,能够提高效率的地方就是多线程优化和解码指令的汇编优化。
个人认为CoreAVC的多线程优化做的很不错了,有兴趣可以用Intel的ThreadCheck对源码检测一下。
至于汇编优化,不知道CoreAVC有没有用到IPP5.3的264解码函数,最近打算试试IPP,看看Intel的汇编优化能做到什么地步。

嘿...大家都有不靠谱的时候嘛.. .能认真谈HDTV,我觉的没吃透H264的白皮书还真不好说

发表于 : 2008-04-08 13:05
intel08
9楼说的对,多线程化在于程序本身而不是操作系统,
但程序的多线程编程的理论和技术目前对很多程序员来讲都算是一个挑战,
虽然有OpenMP这样的标准,但是多线程编程毕竟不符合人类解决问题的思维方式,而且调试起来也很烦
像解码这样串行程度很高的工作,光靠OpenMP的parallize个人感觉好像不合适,我再去看看CoreAVC的代码

反多核技术?? 听上去有搞头~ 我去查查资料~ 谢谢skyx提醒

发表于 : 2008-04-08 13:09
intel08
8楼的朋友也试试CoreAVC for linux嘛,我正按照那个帖子搞,有问题来交流

发表于 : 2008-04-08 13:42
skyx
In April 2006 some rumors emerged that AMD was working on the technology designed to boost performance of single-threaded applications on multi-core processors. According to certain sources familiar with AMD plans, the company is going to offer their own technology that will work in an opposite way to what Intel Hyper-Threading does: it increases performance of dual-core chips in single-threaded applications. If the latter splits resources of a single physical processor core, then AMD’s new know-how will allow combining the resources of the two physical cores to speed up the processing of tasks that work in the most optimal way on single-core CPUs, according to sources.