Original Link: https://www.anandtech.com/show/3786/hd-video-decoding-on-gpus-with-vlc-110



It is time for HTPC enthusiasts to rejoice! Videolan announced the availability of VLC 1.1.0 a couple of days back. VLC's popularity soared in the mid-2000s when standard definition videos were all the craze, and CPUs were powerful enough to easily decode them. 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 [Clarification: 'trouble' with CPU decoding might mean dropped frames, stutters, sudden spikes in CPU usage and kicking in of the CPU fan etc. These are more noticeable in single threaded decoder implementations].

HTPC users with GPUs capable of accelerating HD video decode initially relied on the bundled software (from Cyberlink / ArcSoft / Corel). However, the bloatware and container restrictions imposed by these players led enthusiasts to other open source projects such as Media Player Classic - Home Cinema (MPC-HC). These tapped into the GPU capabilities using DXVA / DXVA2 APIs on Windows and VAAPI on Linux. The extent of support provided in these APIs depended on the GPU vendor. Historically, Nvidia has provided much better support than ATI, while Intel was lagging behind for quite some time till late last year. This is evident from one of the popular blog posts used as a reference by people wanting to get DXVA working on their GPUs. Users of MPC-HC also had to deal with external codec packs such as CCCP. In addition, a large number of options had to be set up correctly in order to get GPU decoding to work. There was an urgent need for the big player in this space to come to the party, and Videolan has done that exactly with the 1.1.0 release of the VLC Media Player.

However, all is not well yet in VLC land. Videolan supplied the caveat that the experimental GPU acceleration would work only on Nvidia GPUs as of now. They cited troubles with the ATI drivers and the lack of access to a Intel IGP as the reason for not being able to support non-Nvidia platforms with confidence. With a core developer team of just 5 people, coupled with the fact that most of them are not Windows developers, it is hard to find fault with that reasoning.

At the end of our testing, we found out some unexpected good things. However, there was some disappointment as well. Before going into the details, let us take a look at the test bed and test suite we used for the analysis.



Catalyst 10.6 does not provide any support for VLC's GPU acceleration methodology, but AMD seems to suggest that a update to fix this is coming soon. Knowing ATI's lethargy in fixing drivers for anything not related to gaming, we decided to ignore their GPUs for the time being.

[UPDATE 1: June 26, 2010: We heard back from AMD PR as well as the concerned VLC developer, and we are told that Catalyst 10.7 (expected by mid-July), and VLC 1.1.1 (expected in 3 - 4 days) enable acceleration on ATI GPUs also. Apparently, they have verified that the acceleration works in the labs, and are waiting on final QA. I am now willing to reconsider my earlier opinion on ATI's lethargy and hope that this sort of response is a sign of good things to come for AMD/ATI HTPC users.]

[UPDATE 2: July 2, 2010: AMD provided us with the pre-release Catalyst 10.7, and Jean-Baptiste gave us the VLC 1.1.1 build. On one of AMD's recent Radeon chipsets, GPU acceleration works better than Nvidia's. Also, it looks likely that Radeon 3xxx users will be unable to take advantage of VLC's acceleration. More details will follow once Catalyst 10.7 is officially released].

VLC developers couldn't test their acceleration methodology on the Intel IGPs at all. As end users, we decided to test it out for them.

We utilized 3 test beds for our evaluation

1. Intel IGP - Arrandale ClearVideo: Gateway NV5935u
2. Nvidia - Quadro FX2700M PureVideo VP2: Customised HP 8730w [ Core 2 Duo T9400 / 4GB RAM ]
3. Nvidia - GeForce G210M PureVideo VP4: Sony Vaio VPCCW13FX/R [ PDF ]

The DXVA capabilities of each platform are evident in the screenshots below.

 
Intel i5-430M DXVA Capabilities
 
 
 
Quadro FX2700M DXVA Capabilities
 
 
 
GeForce G210M DXVA Capabilities
 
 

All machines were tested using VLC 1.1.0 on Microsoft Windows 7, using a 37" Toshiba Regza HDTV connected via HDMI through an Onkyo TX-SR606, at 1920x1080p resolution in Extend mode (with the primary screen running at 1366x768). One set of tests was run with GPU acceleration disabled, and another with GPU acceleration enabled. CPU usage was tracked for both runs and the maximum values over the course of playback compared.

GPU acceleration has been provided by VLC for MPEG-2, H.264 and VC-1. Since MPEG-2 is easily handled by even low performance processors, we decided to cover only H.264 and VC-1 in our test suite. Eight different streams were tested, with the following characteristics

1. L4.1 H.264 1080p30 @ 8.3 Mbps (M2TS)
2. L4.1 H.264 1080p24 @ 10.2 Mbps (MKV)
3. L5.1 H.264 1080p60 @ 10 Mbps - 8 reference frames (MKV)
4. L5.1 H.264 1080p24 @ 19 Mbps - 16 reference frames (MKV)
5. VC-1 Main Profile 1080p24 @ 8 Mbps (WMV9)
6. VC-1 Advanced Profile 1080p24 @ 18 Mbps (MKV)
7. VC-1 Advanced Profile 1440 x 576 @ 6 Mbps (WMV)
8. VC-1 Advanced Profile 720p60 @ 15 Mbps (WMV)

We decided not to use any interlaced media in the test suite since VLC does the deinterlacing on the CPU using SSE2 instructions even if GPU acceleration is enabled. This ensures that deinterlaced media playback remains consistent across different cards and driver versions.

The GPU acceleration support provided by VLC on Windows has a very different architecture compared to the one used by programs such as MPC-HC and Windows Media Player. As explained by one of the developers here, VLC prefers a slower method of GPU acceleration in order to maintain the framework aspect. It decodes on the GPU but gets the decoded data back for further processing. Therefore, CPU usage would be worse off when compared with playback using MPC-HC or Windows Media Player. For this reason, the only comparisons we make further down in this piece are within VLC (acceleration on vs. acceleration off), and not with other media playback programs.



After installing VLC 1.1.0, I was surprised to find that Blu-Ray sample clips continued to stutter during playback. I then realized that GPU acceleration was disabled by default. The option is hidden in the Preferences window accessible through the Tools menu.

Experimental GPU Acceleration Option in VLC 1.1.0 > Tools > Preferences


The three graphs below show the maximum CPU usage during the course of playback with and without GPU acceleration (X-axis) for each of the 8 files listed in the previous section (Y-axis). A completely unwatchable video has no entry corresponding to it. Most of the videos showing 100% utilization were watchable except for a few stutterrs and dropped frames.

A quick look at the graph for the Intel i5-430M below show that the VLC - GPU interaction for H.264 is a complete failure. Upon initializing any H.264 stream, the screen turned completely green. On the other hand, VC-1 decode acceleration is not broken like H.264. CPU usage is lesser with acceleration turned on, but not by much. On being contacted with these details, VLC developer Jean-Baptiste Kempf indicated that the issue was quite simple, and was quite confident that the code would work as soon as the developer team had access to an Intel box.

Moving on to Nvidia's PureVideo VP2 decoder in the Quadro FX2700M, we find that both the L4.1 H.264 streams were accelerated without issues. However, L5.1 videos having more than 4 reference frames were rendered unwatchable due to extensive artefacting despite the fact that CPU usage remained low. From the same graph, we also find that VC-1 videos aren't accelerated as well as H264. This is due to the fact that the VP2 decoder doesn't provide VLD acceleration for VC1, but only IDCT. VLC manages to make use of the IDCT acceleration a little bit, but, obviously, the results are not as good as what one could achieve with VLD.

The GeForce G210M has Nvidia's latest PureVideo VP4 decoder (which supports acceleration for even MPEG-4 / DivX, but we are not testing those here). We observe that both H264 and VC-1 get accelerated as expected, but the L5.1 streams still have an issue. Jean-Baptiste Kempf seems to think that the L5.1 problem could be a result of issues with Nvidia's drivers as well as VLC code. A fix is expected once a bug report with a sample file is filed.

 


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)



The first version of this article has elicited passionate responses from many readers. Some people have come out in support of VLC, while others are proponents of MPC-HC or Windows Media Player, with a preference for some codec packs. This is the sort of comparison I really didn't want to make in the article. However, I do feel it is now pertinent to add a few notes.

VLC's Target Audience

VLC is targeted at the lowest common denominator of computer users. We are talking about users for whom the average Anandtech reader actually sets up a newly purchased PC or does tech support for. This is not to say that VLC doesn't have its utility for power users. There is no 'one-size-fits-all' media player. VLC used to be one, but with the advent of HD media, it ceased to be. MPC-HC is trying to be one, but it is not so convincing in its current state.

VLC is Bloatware

A reader in a private communication accuses VLC of being bloatware, and praises MPC-HC for being light and fast. VLC used to be light and fast in its early days too. As more and more functionality is added, and people request more and more features, there is no guarantee that MPC-HC will continue to remain so. Software application development goes through these stages, and past a particular point, it becomes bloatware (Adobe Acrobat Reader is a case in point). At some point or the other, the developers realize this, and rewrite parts of the application / implement acceleration of some sort. I hope (and believe) VLC's development is at that stage now. It is probably too late for VLC to shift to the approach used by MPC-HC / mplayer-VDPAU of having separate development for Windows and Linux platforms. This could have resulted in more efficient code.

One also has to remember that VLC has support for more file formats and containers than any other player considered standalone. It is a framework, with support for scripting in order to further functionality (using Lua). Consider a RMVB file with RMVB video and Cook audio. VLC has had the capability to play such a file since the last 5 or 10 releases. I just tried opening one in MPC-HC, and ended up with a 'cannot render pins in graph because some codec or filter not installed'. On the same system, at the same time, VLC plays back the file without issues. If a tech noob sees this, would you fault him for preferring VLC to MPC-HC?  Despite being a power user, I believe in installing as few programs / codec packs as possible in order to get the file to playback, and VLC fits this criterion. Yes, we all know RMVB is on the way out, but that is no excuse not to support it.

VLC's DXVA Implementation

The VLC developers are more interested in the framework and multi-platform support with a unified code base, rather than just the media player capability. I do have my reservations about their approach, in case they want to compete with MPC-HC's capabilities. I see comments on the article comparing DXVA acceleration on MPC-HC with that of VLC right now, and declarations that MPC-HC is light years ahead. Of course, and that is the reason why MPC-HC is not shown in the graphs. Let us give some chance to VLC to improve their DXVA implementation. MPC-HC has been implementing DXVA since March 2007. It has taken them 3 years to come where it is now. VLC has just started out on this. It is not fair to put them down for this reason.

That said, I am not sure the VLC developers reached out to the GPU vendors enough. A quick search on various AV forums / Google reveals technical contacts for Nvidia and Intel. ATI is a different story, but we do see some marketing managers on Twitter (like CatalystMaker). I am sure all three would have been more than willing to help out a project like VLC. The GPU acceleration could have been in RC versions till all the kinks were ironed out. To the defence of the developers, they do mark the feature as 'experimental'.

Wait! MPC-HC is more popular than VLC!

A reader in a private communication took issue with my statement that VLC is much more popular than MPC-HC. While it might be difficult to quantify this statement, the reader went on to suggest that this was completely false. I was curious and wanted to dig up some numbers. For statistical purposes, as of 25th June, 2010, SourceForge reports less than 10 million downloads of MPC-HC (all standalone filters / 32 and 64 bit versions put together) since v1.0.4 (last 4 years). On the other hand, VLC on the Windows platform seems to have had more than 150 million downloads (and this doesn't include the latest release) since v1.0.0 (last 1 year). Given these statistics, VLC seems to be more popular, though I do agree that MPC-HC has some advanced technical merits.

The reader also happened to mention that, according to MPC-HC's project manager, Microsoft told him MPC-HC is the second most used video player on Windows after WMP (can't beat the bundled apps). I have been keeping track of MPC-HC development on Doom9 on and off, and vaguely remembered something like this being discussed over there. I managed to dig up three posts, one on why MPC-HC's executable name was changed from mplayerc.exe to mpc-hc.exe, and the other two detailing some communication from Microsoft regarding the high volume of MPC-HC crash reports.

Apparently, mplayerc.exe crashed so often on Windows systems a year or two back, that Microsoft got flooded with error reports from customers noting MPC-HC as the culprit. I am unable to find a statement from tetsuo55 (MPC-HC project manager's username on Doom9) on the net backing up what the reader sent in, but if it is true, I think it is easy to see why Microsoft may have reported that MPC-HC is the second most popular media player (I don't think they have any way to track which media player is being used on their OS, other than by using the error reports, right?)

I am not suggesting that MPC-HC is unstable (after all, these error reports were from the original Media Player Classic, and the issues have been fixed for quite some time now) or denying that MPC-HC is currently the best option to play HD videos on Windows, but when one considers the whole ecosystem (SD as well as HD video, and all codecs and file formats), I would think VLC has a much larger installed base. This is also supported by the download statistics at the beginning of this section.

VLC - One of the Best Open Source Softwares?

One reader in a private communication took offence when I termed VLC as one of the best open source softwares of all time, citing that MPC-HC annihilated it on Windows and Mplayer / VDPAU did the same on Linux. He also cited frequent commits and community activity in the MPC-HC repository as indications that MPC-HC deserved recognition as a better open source software than VLC. While his statements on performance may be true, we believe one should not take away credit from VLC, considering where and how it started, and where it is now. MPC-HC is indeed a great program with a very active development community. So, the commits and updates to the program are frequent. However, one also has to note that the project is quite new compared to VLC, which is much more stable and already has had a lot of development behind it.

The problem with VLC is that its initial development was done in the days when GPU acceleration of video decode was unheard of, and HD videos were non-existent. It is now trying to cover lost ground, and this must definitely be appreciated and supported. It has started taking steps on the way to becoming the Swiss army knife of the media player world once again. I would also offer the opinion that VLC developers should take some leaves out of the MPC-HC books in order to implement DXVA better. After all, one of the biggest advantages of being open source is co-operation. There is always space for two players in this field.

Note on Codec Packs

Codec packs are usually a mess to maintain. Even tech savvy users find it very easy to shoot themselves in the foot. What works on one system might conflict with another system (unless it is a clean and fresh OS installation). So, it is probably not something one should consider for the type of users mentioned in the first section on this page.

Just for disclosure purposes, I repeat one of my comments here: On my HTPC, MKV / M2TS files default to MPC-HC, while all other formats open in VLC. No codec packs are installed. I love MPC-HC for providing me with the best interface and experience while watching high definition stuff, but that doesn't mean I consider VLC any less worthy for what it does.

Log in

Don't have an account? Sign up now