VLC has taken the important first step towards enabling GPU acceleration for various codecs commonly used in high definition videos. However, they have been crippled by their application structure, resulting in the fact that they are unable to provide the same amount of acceleration as other methods like DXVA using MPC-HC / Windows Media Player. While the untested Arrandale provided around 5% CPU usage improvement for VC-1 decode, PureVideo VP2 had speed-ups of around 60% for H264 and 20% for VC1. PureVideo VP4 turned out to be the best of the lot when GPU acceleration is enabled. CPU usage was lesser by a factor more than 65% for H264 and 36% for VC1.

Are these numbers good enough for the occasional HD video watcher? I would say, yes, as soon as the GPU vendors fix their drivers for the remaining minor issues. But, for the HD enthusiast with terabytes of Blu-Ray backups, I would still advise sticking with MPC-HC / Windows Media Player / favourite software Blu-Ray player.

GPU vendors should get their act together and work with the VLC developers to ensure smooth interaction between their drivers and VLC. This has already been done between the MPC-HC / mplayer - VDPAU developers and Nvidia / Intel. VLC, being much more popular, should not have much trouble in this respect (as indicated by how long it took CatalystMaker to tweet regarding Catalyst support for VLC). The vendors and developers should also look into ways to further the performance gains that have been realized with this first release. It will probably not be long before all GPU vendors support this type of acceleration at the basic level. That would be time for the VLC developers to enable GPU acceleration by default, and take away the experimental tag associated with it.

On other HD media aspects related to VLC, it is heartening to note support for WMAPro audio in the past few releases. Would it be wishful thinking to see audio passthrough / HD audio bitstreaming implemented internally in VLC? Hopefully not! Anandtech takes this opportunity to thank the VLC developers for creating and supporting one of the best open source softwares of all time.

Note: Don't forget to check out the update section on the next page, where I have tried to address some comments from readers (both here, and also in private communication)

Playback Performance Update Section: VLC, MPC-HC & Miscellaneous Notes


View All Comments

  • Phynaz - Friday, June 25, 2010 - link

    But I'm afraid this article is so full of misinformation that it should just be pulled.

    At least choose authors that are familiar with the subject they are writing about, as the author of this article knows next to nothing about digital video.
  • ganeshts - Friday, June 25, 2010 - link


    Please do let me know what is wrong with the info in the article.

    Most of it is based on personal testing of a variety of media on different systems, and a lot of information has been gleaned from actual interaction with a VLC developer.

    I have no trouble with criticism, but it needs to be constructive. I am afraid your comments don't give me any insights into where I will need to improve.
  • Phynaz - Friday, June 25, 2010 - link

    Others before me posted comments where the information in this article is just plain wrong. For example your statements that MPC requires codec packs for GPU accelerated decoding, or that modern cpu's have problems decoding HD video.

    Please post the specs of an i7 build that can't decode H.264 or VC-1 video without GPU assistance. Heck, a P4 could play H.264 with version 0.9 of VLC.
  • ganeshts - Friday, June 25, 2010 - link

    There is absolutely no statement that MPC requires codec packs for GPU accelerated decoding.

    The original statements in the article are:

    Users of MPC-HC also had to deal with external codec packs such as CCCP

    This is true if people wanted to play files not supported internally by MPC-HC such as Real Media and other arcane codecs. There also used to be a time when the internal Matroska splitter used in MPC-HC wasn't working properly, and Haali's splitter had to be used, which was again bundled with CCCP. :: I never talked about CCCP for GPU decode here.

    In addition, a large number of options had to be set up correctly in order to get GPU decoding to work.

    This is true, since one had to set the renderer depending on the OS, and disable some internal filters. I have actually lost track of the number of options I played around with before I got DXVA to work with MPC-HC for the first time on my P4 with ATI 3450.

    Onto your next point, modern CPU's have problems decoding HD video:

    This is the exact quote:

    Over the last few years, many people have built up a big library of high definition videos, and one of the complaints against VLC was the fact that all the inbuilt codecs relied completely on the CPU horsepower for decoding. Even the most powerful modern day multi-core processors have trouble decoding HD videos.

    The trouble decoding HD videos is when VLC is used ( and in testing on Windows XP, even when Windows Media Player is used - The WMP in Win7 actually uses the GPU (if available) and not the CPU for majority of the decoding.)

    It is easy to say i7 build can decode H.264 or VC-1 without GPU assistance, but the important thing is not the spec of the build, but the spec of the stream (high definition - 1080p / 720p, bitrate - 10 Mbps / 50 Mbps? and so many other encoding characteristics).

    In the playback performance section, I have indicated the specs of 3 modern day builds which spiked upto 100% CPU utilization for various H264 and VC1 streams.

    By the way, my HTPC is a P4, and it couldn't keep up with playing HD H.264 using VLC. The key here is the HD moniker.

    I don't wish to sound disrespectful, but am not sure how your misunderstanding of 4 simple lines in the article would (i) make the whole article full of misinformation, (ii) brand the author as not being familiar with what they are writing about and on top of that (iii) state that the author knows next to nothing about digital video ;

    I will leave it to the rest of the readers to draw any conclusions in light of my above clarifications.
  • Mumrik - Friday, June 25, 2010 - link

    People seem to have blind irrational loyalty towards MPC and it seems to distort their vision.

    I can't get myself to use either of these two regularly because of the horrible GUIs...
  • Touche - Saturday, June 26, 2010 - link

    Although GUIs could use a little touchup, it really is the content that you are watching. Reply
  • kasakka - Sunday, June 27, 2010 - link

    The GUI in MPC is rather old fashioned and VLC's GUI is not only crappy looking but also rather unintuitive especially in settings. VLC's skins help a bit but most of them seem to be somewhat incomplete too.

    It's truly a shame that many Windows developers seem to be very poor user interface designers, even though they may be wizards at things like codec development and whatnot.
  • jtleon - Tuesday, June 29, 2010 - link

    I will second that - My own HTPC (P4 2Ghz laptop) cannot keep up with my home-made 720P (1280x720) HD videos that I have shrunk using VLC h.264 encoding to 1/10 their motion jpeg size. Now I am faced with upgrading the HTPC, or down-scaling my videos (not!).

    I have found the socket 754 Mobile Semprons (90nm, E-stepping) have absolutely no problem rendering h264 with VLC at HALF the P4 speed!
  • tlmaclennan - Friday, June 25, 2010 - link

    I dropped VLC a long time ago for MPC-HC. Video quality is much better and I have the ability to bitstream via ffdshow. Most players support DXVA now, so sorry VLC but you're a bit too late. Reply
  • Wellsoul2 - Friday, June 25, 2010 - link

    It would be interesting to see the test with a 3GHZ+ Quad core .

    For playing 720P and 1080P single music videos VLC seems to do fine already.

    It tends to crap out after a few videos if you use the playlist feature...I don't know why..

    I still use it alot and like it..so great if it's becoming better.

Log in

Don't have an account? Sign up now