mikeX
25th November 2004, 19:42
I just installed VLC 8.1 on the following box:
P4 1.8, 256 MB Ram, GeForce4 Ti 4200 (64MB), WinXP sp1a
and i couldn't help noticing how F A S T it runs! I mean CPU usage is kept at a bare minimum, fluxuating from 0 to 20 % for clips that eat up 20-60% when played through a Directshow based player!
The clip is XviD 1.0.2 encoded (without any decoding intensive features such as QPel enabled) and with a resolution of 624x352. Vorbis audio (~64kbps) and VobSub subtitles are also demuxed and decoded at the same time...
So it's ffmpeg [libavcodec], libvorbis (& whatever is used for VobSub) vs ffdshow [libavcodec] or XviD dshow decoder, corevorbis and vsfilter (all through MediaPlayerClassic 6.4.8.2).
Even when there is no colorspace conversion (selecting YV12 as output colorspace through XviD decoder, or selecting Overlay Mixer Output through MPC), the DirectShow playback chain still uses 20-35% CPU time.
VLC output is left at default (DirectX hardware YUV overlay).
I don't think it has to do with SIMD extensions either, since both ffdshow and xvid dshow are compiled with sse, 3dnow and whatever, optimizations... Furthermore, disabling SSE2 in VLC doesn't appear to influence the cpu load.
A Debian package of VLC 8.0 on an AMD AthlonXP 1800+[only lacking SSE2 from the P4's SIMDs], 256 Ram [linux 2.6.7, X 4.3.0.1] wGeForce2 (64MB) and the proprietary Nvidia drivers [with XV output] uses 15-30% of the cpu time for similar clips, which is at the same level as others libavcodec based players like mplayer and xine.
I think the difference in CPU load in this case has to do with incomplete hardware acceleration support, or the older chipset in the GeForce2.
Can the DirectShow overhead make that much of a difference? Or is something else to blame?
In either case, the VLC devs are doing some excellent work [i'm only missing proper seeking in matroska files atm] ; )
P4 1.8, 256 MB Ram, GeForce4 Ti 4200 (64MB), WinXP sp1a
and i couldn't help noticing how F A S T it runs! I mean CPU usage is kept at a bare minimum, fluxuating from 0 to 20 % for clips that eat up 20-60% when played through a Directshow based player!
The clip is XviD 1.0.2 encoded (without any decoding intensive features such as QPel enabled) and with a resolution of 624x352. Vorbis audio (~64kbps) and VobSub subtitles are also demuxed and decoded at the same time...
So it's ffmpeg [libavcodec], libvorbis (& whatever is used for VobSub) vs ffdshow [libavcodec] or XviD dshow decoder, corevorbis and vsfilter (all through MediaPlayerClassic 6.4.8.2).
Even when there is no colorspace conversion (selecting YV12 as output colorspace through XviD decoder, or selecting Overlay Mixer Output through MPC), the DirectShow playback chain still uses 20-35% CPU time.
VLC output is left at default (DirectX hardware YUV overlay).
I don't think it has to do with SIMD extensions either, since both ffdshow and xvid dshow are compiled with sse, 3dnow and whatever, optimizations... Furthermore, disabling SSE2 in VLC doesn't appear to influence the cpu load.
A Debian package of VLC 8.0 on an AMD AthlonXP 1800+[only lacking SSE2 from the P4's SIMDs], 256 Ram [linux 2.6.7, X 4.3.0.1] wGeForce2 (64MB) and the proprietary Nvidia drivers [with XV output] uses 15-30% of the cpu time for similar clips, which is at the same level as others libavcodec based players like mplayer and xine.
I think the difference in CPU load in this case has to do with incomplete hardware acceleration support, or the older chipset in the GeForce2.
Can the DirectShow overhead make that much of a difference? Or is something else to blame?
In either case, the VLC devs are doing some excellent work [i'm only missing proper seeking in matroska files atm] ; )