mplayer软解高清的负载还真是很奇怪

Totem,mplayer,sopcast,realplayer,bmp
kappa8086
帖子: 308
注册时间: 2008-06-23 14:42

mplayer软解高清的负载还真是很奇怪

#1

帖子 kappa8086 » 2009-11-04 22:30

先看下各环境下mplayer的统计结果。
硬件配置:E5200 oc 3.3GHz, 4GB, 8600GT 256M

Windows 7 x64,NV驱动190.62,mplayer 版本 svn r23811(来自smplayer 0.6.8 portable):
 vo     codec   video   audio   framedrop
 null     58%   0%    2.7%    0
 direct3d   57%   3%    2.2%    5
 gl      56%   23%   1.9%    9

Ubuntu 9.10 amd64,源里的185.18驱动及mplayer 20090426,compiz关闭:
 vo     codec   video   audio   framedrop
 null     71%   0%    0.7%    0
 x11     70%   14%    0.9%   19
 xv      78%   3%    1.2%   1022*
 xv(监视)   78%   3%    1.2%   147
 gl      64%   22%    0.7%   84
 gl(监视)   68%   22%    0.7%   790*
 vdpau    0%    25%   1.3%    1

注:“监视”为打开系统监视器查看CPU负载时的情况;*表示有性能警告。

Windows下的负载相比之下貌似很正常,播放流畅,偶尔掉帧,没感觉。其中gl渲染性能最差。不过任务管理器显示的负载值比这个还低一些,暂且算虚报吧,而且两个核心负载均衡(mplayer难道不是多线程无能?)。。。

Ubuntu下的数据就比较诡异。首先整体比windows下高了一大节,这个数据也直接体现在了流畅度上——掉帧甚至mplayer性能警告是经常发生的。
也许linux下的显示驱动始终不如windows下的成熟,但用-vo null测试的解码负荷就难以理解了,linux下高出20%以上,同样是mplayer,就算版本略有差别(而且是ubuntu下的较新),也不至于差这么多吧;而用gl渲染居然会令解码负载下降,xv增加并不奇怪,渲染都算在解码负载里了;更奇怪的是如果打开系统监视器,xv输出的掉帧现象大减,也没出性能警告,gl渲染则相反,解码负载也上升了。
另:vdpau看起来渲染负载高,是因为CPU负载低进入低频状态导致的。

Linux下的数据均测试两次以上,以避免结论的偶然性(只有声音输出有浮动,基本上是越测越小)。



我最近配一台HTPC,打算系统用Mythbuntu,目前就卡在了只要性能增加一点就能软解的坎上(测试短片码率30Mbps左右)。从这个结果看来却是莫名其妙地短了Windows一寸,导致不及格,郁闷了。。。
kappa8086
帖子: 308
注册时间: 2008-06-23 14:42

Re: mplayer软解高清的负载还真是很奇怪

#2

帖子 kappa8086 » 2009-11-04 23:30

mplayer自己播放时显示的而已
头像
hcym
帖子: 15634
注册时间: 2007-05-06 2:46

Re: mplayer软解高清的负载还真是很奇怪

#3

帖子 hcym » 2009-11-04 23:35

短一寸肯定的

开硬解只能针对特定片源,后患无穷

据说svn版的可以自己编译CoreAVC

效率应该好一些,兼容也不错
kappa8086
帖子: 308
注册时间: 2008-06-23 14:42

Re: mplayer软解高清的负载还真是很奇怪

#4

帖子 kappa8086 » 2009-11-05 10:12

我现在最想知道为什么在-vo null关闭视频渲染的情况下,linux下负载还是高windows那么多?对这个答案的兴趣已经高于软解解决方案的兴趣本身 :?

另:HTPC配置是 785G+ Sempron140,目前硬解也开不了的。(据称xvba-video就在这两天已经完成)
头像
懒蜗牛Gentoo
论坛版主
帖子: 7353
注册时间: 2007-03-02 17:36
系统: Linux Mint

Re: mplayer软解高清的负载还真是很奇怪

#5

帖子 懒蜗牛Gentoo » 2009-11-05 10:25

挺有意思,等待牛人解释
虽然世上没有完美的东西,但这并不影响我们追求完美,因为只有偏执狂才TMD能成功。
10.04新手入门——笨兔兔讲述自己的故事
头像
spectater
帖子: 665
注册时间: 2008-02-03 18:53

Re: mplayer软解高清的负载还真是很奇怪

#6

帖子 spectater » 2009-11-05 10:30

用mplayer +CoreAVC , t1600软解1080p 流畅的飘过。


mplayer仍然只是个壳子,比较不提解码器有何用?
kappa8086 写了:
注:“监视”为打开系统监视器查看CPU负载时的情况;*表示有性能警告。
系统监视器查看 cpu占用。果然是高科技 :em20
上次由 spectater 在 2009-11-05 10:32,总共编辑 1 次。
头像
spectater
帖子: 665
注册时间: 2008-02-03 18:53

Re: mplayer软解高清的负载还真是很奇怪

#7

帖子 spectater » 2009-11-05 10:46

比较适合给电脑报投稿。
kappa8086
帖子: 308
注册时间: 2008-06-23 14:42

Re: mplayer软解高清的负载还真是很奇怪

#8

帖子 kappa8086 » 2009-11-05 14:25

spectater 写了:用mplayer +CoreAVC , t1600软解1080p 流畅的飘过。


mplayer仍然只是个壳子,比较不提解码器有何用?
kappa8086 写了:
注:“监视”为打开系统监视器查看CPU负载时的情况;*表示有性能警告。
系统监视器查看 cpu占用。果然是高科技 :em20
我这当然没用CoreAVC。除了CoreAVC还有什么其他可以提供给这“壳子”的解码器?
都是mplayer默认编译进的,windows下和linux下有不同么?
如果您明白望解释一下。

还有我说了都是mplayer自己的统计数据,系统监视器只是在gl和xv对比时打开参考的。
kappa8086
帖子: 308
注册时间: 2008-06-23 14:42

Re: mplayer软解高清的负载还真是很奇怪

#9

帖子 kappa8086 » 2009-11-05 14:29

qkbeyond 写了:lz 很执着。。。
看看我的是硬解还是软解 正常么?
电影宽高比为 1.78:1 - 预放大到正确的电影宽高比。
VO: [xv] 1280x720 => 1280x720 Planar YV12 [zoom]
A: 3.8 V: 3.8 A-V: 0.000 ct: 0.000 93/ 93 40% 14% 2.8% 0 0
A: 11.2 V: 11.2 A-V: 0.000 ct: 0.000 269/269 35% 12% 2.2% 0 0
xv输出当然是软解了...
kappa8086
帖子: 308
注册时间: 2008-06-23 14:42

Re: mplayer软解高清的负载还真是很奇怪

#10

帖子 kappa8086 » 2009-11-05 14:43

还有,发现9.10下的系统监视器其实比以前的(8.10)CPU占用情况好了许多,通常也就5%。以前那简直就是在监视自己。。。
头像
spectater
帖子: 665
注册时间: 2008-02-03 18:53

Re: mplayer软解高清的负载还真是很奇怪

#11

帖子 spectater » 2009-11-05 15:08

kappa8086 写了:
spectater 写了:用mplayer +CoreAVC , t1600软解1080p 流畅的飘过。


mplayer仍然只是个壳子,比较不提解码器有何用?
kappa8086 写了:
注:“监视”为打开系统监视器查看CPU负载时的情况;*表示有性能警告。
系统监视器查看 cpu占用。果然是高科技 :em20
我这当然没用CoreAVC。除了CoreAVC还有什么其他可以提供给这“壳子”的解码器?
都是mplayer默认编译进的,windows下和linux下有不同么?
如果您明白望解释一下。

还有我说了都是mplayer自己的统计数据,系统监视器只是在gl和xv对比时打开参考的。


win下对高清优化过的解码器有好几种,听说有一种比coreave还要好,理论上mplayer可以用到,我只知道mpalyer coreavc的版本,虽然是调用dll, 但在我看来,mpalyer coreavc仍然是个壳子,以前linux版mplayer盛行的是mplayer+ windll codecs, 现在linux上, mplayer+ffmpeg似乎更流行。

linux下 mplayer如果用linux版的ffmpeg,那壳子的说法更站得住脚

你在win下的mplayer,用的解码器是什么呢?

似乎linux 上的ffmpeg也有多核优化的分支。

我的意思是,解码器更重要, 两种不同平台,就算用mplayer ,不提解码器的对比是没有意义的, 不好意思,冒犯您了
kappa8086
帖子: 308
注册时间: 2008-06-23 14:42

Re: mplayer软解高清的负载还真是很奇怪

#12

帖子 kappa8086 » 2009-11-05 15:20

多核优化的据我所知叫ffmpeg-mt,但是实验性的,所以要么自己编译,要么下第三方编译的mplayer。
我懒,用的都是标配版的。。。测试没自己编译也没指定任何外部解码器的默认情况,因为是h264的片子,调用的应该就是ffmpeg,windows下和linux下都一样。也许不是(记得mplayer的输出里也有FFmpeg H.264)?或者windows下的ffmpeg本身多核优化就很好(看起来确实有优化的样子)?那就是我想知道的~
头像
hcym
帖子: 15634
注册时间: 2007-05-06 2:46

Re: mplayer软解高清的负载还真是很奇怪

#13

帖子 hcym » 2009-11-05 15:31

多核优化其实就是均摊

感觉PowerDVD最好,无论多bt的码率在四核上跑都轻松

就是没见人在linux捣持这玩意
kappa8086
帖子: 308
注册时间: 2008-06-23 14:42

Re: mplayer软解高清的负载还真是很奇怪

#14

帖子 kappa8086 » 2009-11-05 16:27

忽然记起好像WIndows7有内置H.264的解码器,难道mplayer优先调用了这个?回去再重测一次,再仔细看看。如果确实是默认用了不同的解码导致的差异,那就是了。要不真是难以服气为什么操作系统会导致相同硬件条件基本同一份代码性能表现差很大。。。
---------
又想起一件事,就是我试过WMP,放不出来,不报错,但没画面没声音播放时间也不对。这就是Win7内置解码器的表现?又晕了 :em20
kappa8086
帖子: 308
注册时间: 2008-06-23 14:42

Re: mplayer软解高清的负载还真是很奇怪

#15

帖子 kappa8086 » 2009-11-05 20:46

Windows下的输出(mplayer版本和我之前说的出点出入,r29355,似乎比9.10源里的版本新一点):

代码: 全选

MPlayer Sherpya-SVN-r29355-4.5.0 (C) 2000-2009 MPlayer Team
c:\windows\fonts\arial.ttf doesn't look like a bitmap font description, ignoring
.

Playing E:\media\_chd_Pixar.Short.Films.Collection.2002.ts.
TS file format detected.
VIDEO H264(pid=4129) AUDIO A52(pid=4133) NO SUBS (yet)!  PROGRAM N. 1
FPS seems to be: 23.976025
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Opening audio decoder: [liba52] AC3 decoding with liba52
Using SSE optimized IMDCT transform
Using MMX optimized resampler
AUDIO: 48000 Hz, 2 ch, s16le, 640.0 kbit/41.67% (ratio: 80000->192000)
Selected audio codec: [a52] afm: liba52 (AC3-liba52)
==========================================================================
AO: [dsound] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [null] 1920x1080 => 1920x1080 Planar YV12
TS_PARSE: COULDN'T SYNC-0.043 ct: -0.041 5462/5462 58%  0%  2.7% 6 0
A: 228.9 V: 229.9 A-V: -0.955 ct: -0.060 5489/5489 58%  0%  2.7% 6 0

Exiting... (End of file)

就是选择了FFmpeg解码,此文件WMP播放不能(又一邪门症状)。结果和昨天的测试一致,只是丢帧数为6。


Ubuntu下的输出:

代码: 全选

MPlayer UNKNOWN-4.4.1 (C) 2000-2009 MPlayer Team
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing /media/EXT/media/_chd_Pixar.Short.Films.Collection.2002.ts.
TS file format detected.
VIDEO H264(pid=4129) AUDIO A52(pid=4133) NO SUBS (yet)!  PROGRAM N. 1
FPS seems to be: 23.976025
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Opening audio decoder: [liba52] AC3 decoding with liba52
Using SSE optimized IMDCT transform
Using MMX optimized resampler
AUDIO: 48000 Hz, 2 ch, s16le, 640.0 kbit/41.67% (ratio: 80000->192000)
Selected audio codec: [a52] afm: liba52 (AC3-liba52)
==========================================================================
[pulse] working around probably broken pause functionality,
        see http://www.pulseaudio.org/ticket/440
AO: [pulse] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
VDec: vo config request - 1920 x 1080 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
VO: [null] 1920x1080 => 1920x1080 Planar YV12 
TS_PARSE: COULDN'T SYNC-0.047 ct: -0.041 5478/5478 72%  0%  0.8% 0 0 
A: 229.7 V: 229.9 A-V: -0.149 ct: -0.061 5489/5489 71%  0%  0.8% 0 0 

Exiting... (End of file)
这是测两次第二次的成绩,和昨天一致,第一次是73% 0% 3.0% 0 0
回复