The VideoLAN Forums

Dear developers,

first of all let me express my thankfulness for the fantastic job you've done with the v1.0.0-rc1 release. I'm still testing it, but as far as I've come, a lot of things look quite accomplished. So, here is a small performance issue:

Background info on my system: Win2000 SP4, Athlon 64 CPU+3800, 1,5 GB RAM, Radeon 9250, LCD 1680x1050 32bit.

The last version I tried (v.0.9.8a) could play MKV video files (1280x720 pixel) with the AVC1 video codec perfectly, the CPU usage was about 65 to 90%.
The new version v.1.0.0-rc1 consumes too much CPU time so that the picture is all choppy and virtually unwatchable (Task Manager shows 100% CPU usage).

Any chance that you could retest the AVC1 codec part and make it less CPU-greedy?

Can you provide a log + a screenshot of the second tab of the messages dialog, please?

I've made message screenshots of both VLC versions in question. Hopefully there's something "conspicuous"?
Otherwise it just may be that the binary code of the codec is more elaborate to handle more things, thus more CPU-consuming?

No, I am afraid that swscale fires up and takes much CPU.
Can you share the file?

I don't know whether it's legal to say: it's one of the TV series season finals that we can't see in Europe yet, like LOST or BONES.

The described phenomenon happens with all of the 1280x720 mkv/avc1 files - the consumption of CPU time in v1.1.0-rc1 appears to be 20% to 50% bigger than in v0.9.8a.

I can confirm this, it does with all mkv/avc1 files I have, even with lower resolution (704x384 or 640x480) ones, not only 1280x720 ones.

my system is:
Vista SP1 32bit
Core 2 Duo E8200
Radeon X1950 Pro

Whenever I open one of those files it takes around 10 sec to start playing (wasn't an issue in 0.9.8a and prior), during those 10 secs task manager reports 50% cpu usage (I read somewhere that vlc doesn't support multi-threading for h264 yet, so it basically means one whole core), after it loads cpu usage drops to and stays during playback at around 40%. I don't experience any issues during playback tho. Whenever I pause playback cpu fan slows down quite a lot.

http://img134.imageshack.us/img134/6200/vlcmt.jpg

I open one of those files it takes around 10 sec to start playing

That is AS.S/SSA subtitle bug. Not AVC one.

I open one of those files it takes around 10 sec to start playing

That is AS.S/SSA subtitle bug. Not AVC one.

I checked and all of them use ssa codec for subtitles so yes that makes sense. Would that one explain high cpu usage during playback too tho?

I open one of those files it takes around 10 sec to start playing

That is AS.S/SSA subtitle bug. Not AVC one.

I checked and all of them use ssa codec for subtitles so yes that makes sense. Would that one explain high cpu usage during playback too tho?

No, this is a bug at starting.

Dear developers,

in order to return from the interlude with the already known startup subtitle bug back to the thread's issue, and to conclude my contribution:
Were you able to confirm the weaker avc1 codec performance in v1.0.0-rc1 compared to v.0.9.8a?

If yes, this is definitely a non-priority to-do-thing as nothing crashes and most of the PCs nowadays are more powerful than mine. In the long run, though, if I may say that, it is of course essential not to "copy" the idiosyncracies of a well-known software company whose products require a stronger PC with each new version.

Were you able to confirm the weaker avc1 codec performance in v1.0.0-rc1 compared to v.0.9.8a?

VLC 1.0.0-rc1 eats more CPU time during H.264 playback than VLC 0.9.9

Were you able to confirm the weaker avc1 codec performance in v1.0.0-rc1 compared to v.0.9.8a?

VLC 1.0.0-rc1 eats more CPU time during H.264 playback than VLC 0.9.9

Really ?

Difference isn't usually very big, but I think on some setups even small changes can be very annoying if playback is already walking on thin line.
http://img38.imageshack.us/img38/7822/vlccpuh264.png
red line is 0.9.9 and blue line is vlc-1.0.0-rc1-20090520-0004, specially the higher peaks might be issue. I only tested playback with TheGreatestGame_HD_AVC.mp4

Hello guys,

first of all congratulations to the official 1.0 release. On behalf of many users I say thank you very much for the efforts you've given to make this happen.

As I had the opportunity to test the new version, I must regretfully say that the AVC1 codec is as weak as in v1.0.0-rc1 and about 30-50% more CPU-consuming than v0.9.9 (had to switch back to that version). Can we expect any time soon that the source code of this codec will be overhauled/optimized?

H.264 decoder isn't developed by VLC team. It is developed by FFmpeg devs.

H.264 decoder isn't developed by VLC team. It is developed by FFmpeg devs.

The problem is that I have some files which are playing fine in other ffmpeg/libavcodec players whilst I have to turn off the loop filter in VLC in order to get a proper playback.

Examples:
http://av.watch.impress.co.jp/docs/20080206/ezsm01.m2ts
http://stfcc.org/misc/00000.cut2.m2ts
http://files.filefront.com/juGGaKNot+4m ... einfo.html

These files are playing fine in MPlayer, in MPC-HC (in software mode) and even in WMP when using ffdshow. All of these with the loop filter enabled. All of these are ffmpeg/libavcodec decoders.
I have NO reason at all to turn off the loop filter with a Core2Duo @ 3 GHz. Not to mention that the loop filter is a part of H.264/AVC specs and to turn it off gives very poor results on low res/bitrate videos.

However, the high CPU usage is not restricted to H264 playback only.
I'm also experiencing problems with some SVQ3 videos which were playing fine with VLC 0.9.9 and also with an old version of QuickTime 6.5 which is using only one of the cores. See ticket #2547 for more informations.

So I believe there is a little devil inside the machine about CPU usage in VLC 1.0.0 which needs to be tracked down, found out and cured.

MPC-HC and ffdshow use multithreaded H.264 decoders. VLC doesn't.