Yet another blog for JBKempf - Tag - GPU

State of VideoLAN

Jean-Baptiste Kempf — Wed, 11 May 2011 12:42:00 +0200

It's been a long time

It's been a long time since the last time I wrote something long enough around here.
But the cool thing is that it is due to being working quite a lot on VLC and different projects...

So, how well is VideoLAN? How well is VLC?

In this post, I will come back on a few points that happened in our last year.

1. VLC

VLC is doing quite well actually, but some things could be better...

1.1.0

VLC 1.1.0 was out last year, in June.

This release was a tremendous success, and probably the one where we've had the best success for launch.

The focus on GPU decoding and some HD codecs was very well welcomed by users, as was the improved Qt interface.

Of course, 1.1.0 had a lot of bugs, since people still refuse to test our betas and RC versions, and as usual, 1.1.1 was ready and out in less than a month.

1.1.x

The 1.1.x-bugfix branch is quite stable and feature-full.

We still have notorious issues with PulseAudio, DVD Unicode path and Font caching on Windows. But all of them have been fixed in the git master.

1.1.0 to 1.1.9 updates

We've done 9 minor additional releases in 11 months from 1.1.0 to 1.1.9. And 1.1.10 is imminent...

While, this is a bit annoying for the users, seeing the poor update mechanism in VLC, this is mostly due to numerous security issues found and fixed in VLC.

This shows that a very small team, like VLC's can care enough to support and have a strong security focus... Even when people are volunteers.

Numbers

Since the switch to SourceForge, for mirroring the downloads, VLC has been downloaded 237 millions of times, in 11 months.

The repartition per country, is the usual one as seen on my numbers post. And 57% of those downloads were done through the upgrade systems of VLC; the rest came from various websites, including the VideoLAN website.

VLC team and development

Unfortunately, the VLC core team is still very small, and I might say smaller than before. The Bus Factor of VLC is still too low.

However, the number of next-to-core VLC developers and the number of VLC contributors has increased quite a bit.

With this increase, the process for reviewing patches and the quality of code entering VLC has improved a lot. This is good for VLC's maturity.

On the same topic, a lot of code has been cleaned up and outdated modules have been removed.

VLC 1.2.x

I will speak of VLC 1.2.x in a later post. But, you should know that VLC 1.2.0 is in a good shape and development is still happening at a very fast pace.

2. VideoLAN

But VLC isn't the only thing happening in VideoLAN.

The VideoLAN association is in a good shape, having fixed all the assets issue we might have had in the past and allowing developers to work together.

Websites and machines

The main VideoLAN website was redesigned and simplified a lot to stop confusing our users. The users feedback was quite good, on this part.

The other services have been cleaned, removed and improved a lot (major software upgrades, spam fighting, uptime improvements).

The main external websites are now:

Software upgrades: libdvbpsi, libdvbcsa

libdvbpsi has seen one major upgrade and a change of license: it is now LGPLv2.1.

libdvbcsa has seen one major upgrade to increase speed.

Phonon-VLC has seen several upgrades in the last year and is now perfectly working on Linux/KDE, Mac and Windows. Most of the rough edges have been fixed now and it will gain maturity this summer, once again. The amazing work from KDE folks, like apachelogger, is to be noted.

libbluray and libaacs

We have welcomed 2 new libraries into VideoLAN: libaacs and libbluray.

Those 2 libraries are focused on Blu-Ray integration for video players, and are still in early development.

Events

On the communication and community work, VideoLAN schedule has been quite full too.

We've been to various events like FOSDEM, CeBIT and LinuxTag.

We've been part of GSoC 2010 and GSoC 2011, like every year since a few years, and we've been also to participating to the first Google Code-In.

And finally, we've celebrated our 10 years of open source in February.

Conclusion

VideoLAN and VLC are now quite mature projects and the last year has re-stated this matter of fact.

VLC 1.1 was quite an important success for the users, and VLC 1.2 is on the way.

However, the fact that the core team is still mainly composed by a handful of volunteers can be worrisome for the future.

We need your help and we are quite confident for the future!

On the road to VLC 1.1.0 part 1: faster

Jean-Baptiste Kempf — Mon, 15 Mar 2010 07:29:00 +0100

Let’s go on with the first part of my articles to introduce you to VLC 1.1.0.

Decoding HD

In these days of HD video, speeding of decoding is more and more critical, and VLC has not shine on these aspects lately, especially on H.264.

VLC 1.1 should partly fix those issues, with:

faster CPU decoding, especially on Windows,
GPU decoding on Windows Vista/7 and on Linux,
DSP decoding with OpenMax IL on embedded Linux, like Maemo.

GPU decoding

Using DxVA2 on Windows Vista and 7 and VAAPI on Linux, the decoding stage of VLC framework can now be done by the GPU.

If you have a compatible GPU, especially an nVidia, it should go way faster. VLC should consume less than 10% of your CPU and your CPU shouldn’t be at full speed anymore.

It even works on Ion/Atom machines! This is cool for HTPC.

DSP decoding using OpenMax IL

VLC has a new decoder that can use OpenMax IL codecs for DSP decoding

If this is chinese to you, it means that VLC is almost the same speed and energy consumption than the native player on the N900.

OpenMax IL in VLC can decode and encode most of the codecs: Mpeg2, Mpeg4, H264, H263, WMV1, WMV2, WMV3, RV10, RV20, RV30, RV40 and aac, amr, mp3.

Better audio pipeline

Also, the audio pipeline has been reworked, (and accelerated on ARM devices), so that we less conversion occur and better filtering happen.

Of course, audio is not that critical today, but it just makes VLC a better audio player.

Less Ram and Less threads

VLC 1.1 should use less threads as Rémi wrote.

VLC 1.1 should also use less Ram than 1.0.5, even though, this might not be very visible in all situations.

Conclusion

VLC 1.1.0 should be faster to decode, using less CPU and able to leverage GPU and DSPs; it should use less RAM and less threads. What more do you want ?

Update Part 2: Better

Decoding video in VLC using VAAPI and nVidia

Jean-Baptiste Kempf — Sun, 19 Apr 2009 22:51:00 +0200

I know Phoronix people don't come around here, and that most people reading this blog don't care, but anyway...

GPU video decoding on Linux

On linux, decoding video using GPU means different standards:

Fortunately, we can use VDPAU (nVidia) as a backend to VAAPI. And there is a very nice library, named libva.

VLC and VAAPI

So far, most patches were done on MPlayer and FFmpeg, but here we go:

The sample is a M2TS with H.264 encoded at 32Mbps. Decoding is done without audio and subs and with a command line interface.

Performances

The perfs are quite nice, but they might be better. Why?

Because we don't output directly the video, we just take it back from the decoder, so we have a lot of memcpy, which explains why the decoding could be faster, but isn't...

Does this mean I can decode using GPU and then restream using VLC?

In theory, yes. Not tested yet :D