Unrealistically low CPU usage playing back some videos

[jfs]

I, and at least one other person, have a strange behaviour with VLC playing back videos.
My system is a dual Opteron 248 (2.2 ghz), and I'm using Windows XP 32bit SP1, I'm not sure about the other person.

I play back a 640x480 x264 encoded file (in mp4 container), and looking in the Windows Task Manager, my CPU usage barely exceeds 10 percent. After playback of the video (about 4 minutes long), the total CPU time usage recorded for the VLC process is about 13 seconds.
This is unrealistic. That actually means that an old Pentium 1 CPU at perhaps 133 or 166 MHz should be able to play back the video in real time.

If I play the same video in a DirectShow based player, using a heavily compiler-optimized ffdshow for video decoding, I get about 50-75% CPU usage on one of my CPU's (while the other is mainly idle).

Since the VLC results seem unrealistically low, I and several other people I have talked to think VLC is somehow (unintentionally, hopefully ) fooling the Windows process accounting.
Can anyone explain this behaviour?

[Bump]

Bumping because I'd like to see an answer to this.

[yuh!]

weird, because mine goes straight to 100% CPU Usage on Windows XP Professional and the video stops playing, while the audio continues...i wish i had your "problem"...

[touche]

Check if you have the same behaviour when you enable maximum Post processing (during playback, go to Video->Post processing->6)

[Guest]

The problem I have is that (700mhz p3) plays xvid full motion movies
and other xvid stuff fine, with cpu usage around 10-30% but when i
try to play x264/mp3 (in mp4 container) encoded stuff with bitrates artound 1200, the cpu goes straight to 100% and stays there, sync goes all out of wack it skips and sometimes just crashes. I really dont understand this.

[DJ]

It depends greatly on the resolution and bitrate of the file and the capabilities of your box. VCL is 20 to 30% more efficient than ffdshow using h.264

An easy test is call a 480p file using QuickTime's website and see hoe it plays in QT. If it works you should have no problem in VLC with this and lower resolutions.

[Guest]

Yeah its similar, the stuff I am trying to play is 640x480
enc with x264/mp3 in a mp4 container, bitrates around
1100-1300. THe performance is jsut as bad with ffdshow
so Im not blaming vlc, i like vlc a lot, must just be something
with h264 that taxes the cpu a lot more than other formats.

[Guest]

I play back a 640x480 x264 encoded file (in mp4 container), and looking in the Windows Task Manager, my CPU usage barely exceeds 10 percent. After playback of the video (about 4 minutes long), the total CPU time usage recorded for the VLC process is about 13 seconds.
This is unrealistic. That actually means that an old Pentium 1 CPU at perhaps 133 or 166 MHz should be able to play back the video in real time.

Logic ain't right, there are more issues than CPU speed on MHz point, if you would clock you current CPU to 133 or 166 and compare it to Pentium 1 CPU your CPU would beat Pentium 1 with very clear difference, specially on video decoding/encoding.

[DJ]

There is no doubt or contest! H.264 has a higher CPU load using the same resolution and or bitrate than does DivX or XviD. But if you have tried to put any of the HD resolutions into DivX or XviD you would find that they don't work as well as h.264 if at all above 480p

Windows WMV format has very similar requirements and constraints in the higher resolutions used for HD. However MPEG TS or PS have better hardware support for the higher resolutions, as such the CPU constraints are not as bad.