Planet VideoLAN
Welcome on Planet VideoLAN. This page gathers the blogs and feeds of VideoLAN's developers and contributors. As such, it doesn't necessarly represent the opinion of all the developers, the VideoLAN project, ...
May 02, 2013
Ludovic Fauvet
Rethinking the VLC’s mirrors infrastructure
Around 2005 when we started to gather some statistics about VLC, download numbers were around 150,000 downloads per day. Since then this number has increased significantly to reach more than 1M the good days. In the beginning we used few mirrors to handle the file distribution and it was an hassle to manage since back in the days it required a lot of human power to do a VLC release. Mostly because we had to wait several hours (if not days) until all mirrors were synchronized. Frustrated by the situation we moved to SourceForge.net during the month of April, 2010 to simplify the release process. We stayed there for 3 years until recently.
To better understand why we backed off let’s talk a bit about the SourceForge.net business model. Like any other company they have to make money to pay their bills and employees. No problem with that. The way they do it is to put ads on their downloads pages while your download starts. No problem with that either. Except when it comes to ads that are obviously designed to trick the user into believing they are part of the download procedure. Which is indeed bad and misleading. Let’s illustrate what I’m talking about.
VLC’s page on SF.net as taken on April 15, 2013 in France with an IE8 user agent.
Do you see these big buttons? Of course! They are even bigger than the real download link and you have absolutely no idea where they are linking to (Spoiler alert: it’s a scam). Obviously a lot of our users were tricked into clicking these ads and were downloading all kind of crapware. I don’t blame SourceForge for this, this is more a matter of how most advertising programs works on the web nowadays but anyway we care enough about our users to not continue this way. And yes, we asked SF.net many times to be more vigilant about the ads they are showing without much success. This is one of the reason why we (the VideoLAN organization) decided to move away from SourceForge and return to a more typical distribution channel.
Back to the mirrors
We went back to the traditional way of distributing files in the free software world: using mirrors. But we are no traditional software. We have millions of users to serve and tens of terabytes to transmit each day everywhere in the world in a reliable way. That’s not a trivial matter when you have no money for buying servers and bandwidth in every part of the world. So we had to rely on generous sponsors.
Finding the sponsors
Finding sponsors able to setup the mirrors and handle all the related costs (disk storage, bandwidth maintenance) is nothing easy. I’ve sent hundreds of email to hosting providers, network operators and ISPs around the world and surprisingly most of them answered positively. One of the constraint we had to consider is where to put mirrors so that it reflects more or less our current user base in each country (dense areas tend to have more mirrors than others).
Every single server can (and will) fail
The situation of having a failing mirror is scary since you have no easy way to get this information soon enough to disable it without having too much users unable to download the requested files. There is no silver bullet but having good tools can help a lot in those situations. We opted for mirrorbrain, a full featured, battery included, open-source geographic load-balancer. Among its supported features mirrorbrain monitors each server, on a network and file level which is great for availability. If one of our mirror is misbehaving it will be disabled automatically, rerouting the requests to the closest available mirror in a matter of minutes and will be re-enabled as soon as it gets back online.
The setup
The first thing you need to know is that mirrorbrain only works as an Apache module. On a personal level I don’t like the Apache HTTP server, because the configuration is a pain and most of all it scales badly under pressure, hogging your CPU and memory quite fast when the traffic exceeds a certain amount of requests per second. Being scalable was not an option but a requirement so I achieved this by adding a fine-tuned nginx frontend.
Another requirement we had was to show a webpage during the download to show the logo of the selected mirror, a checksum of the file and few ads (we are currently supporting the open-source music player Tomahawk).
Putting things together this is how the actual platform looks like and what happen when you’re downloading VLC or any other software from the VideoLAN website:
Nginx is used as a frontend here, all the incoming requests are served through it. It provides static files (images, css, javascript) itself, forwarding download requests to a web application (the glue) in charge of querying mod_mirrorbrain for the best mirror for the given user and file. Eventually it generates the page containing the redirect, ads and checksum. Only few requests are directly forwarded to the Apache backend without passing by the web app but these are only used for monitoring and debugging purpose and are not part of the standard download process.
Conclusion
One month after we put the whole thing into production we are quite pleased by the result. We’re serving dozens of downloads (and VLC’s updates!) each second everywhere in the world in a reliable way from a total of 42 mirrors provided by awesome sponsors. And we even survived to a DDOS attack without a single downtime!
April 11, 2013
Felix Paul Kühne
VLC 2.0.6
Today, we published VLC 2.0.6. This is an important update to VLC’s 2.0 series, which improves the overall stability, fixes minor annoyances and solves certain security implications. It will be available through the internal updater on Mac OS X later today and is already live on for manual downloads on our main website. The in-app […]
April 02, 2013
Jean-Baptiste Kempf
New report about the WinRT port
News and Excuses
I must start this post by sharing some excuses of not doing enough updates lately.
The main reason is that we've been mostly under-water with the current development, that took most of our time.
News and report
The good news is that we have had tremendous progress...
The bad is that we have still a bit of work to do before sharing it on the store, as I will explain soon.
Pictures
But first, the current pictures:
Current start screen
Fully working playback
Technical update
If you followed closely, our main work, in addition to the UI, was to fight and replace the forbidden symbols not allowed on Windows App Store mode.
We've been quite efficient at that, working closely with Mingw-w64 project and GCC developers.
The biggest result is that we have now cut down 90% of our symbols, that are forbidden on Metro Mode.
We mostly did this by:
- replacing our forbidden calls with newer authorized equivalent calls,
- modifying gcc and Mingw-w64,
- writing new code in a special library of ours,
- writing dummy functions,
- disabling VLC code that would not work on the Metro platform,
- moving VLC to MSVCRT 11.0,
- moving all the VLC codebase to UNICODE and WideChars to fit the new requirements.
We did also a lot of minor things to help the integration of libVLC and VLC in this modern platform.
What are we working on now:
We are now mainly working on 2 things:
- make VLC work with MSVCRT 11.0 without crashing
- write headers and C/C++ code to access the new fashion of COM APIs in which WinRT is written in.
What we are gonna work just after:
- ARM, ARM, ARM,
- WP8
Goodies
They are gonna get shipped soon 
February 13, 2013
Jean-Baptiste Kempf
Over 25000!
After my 20000 mark, I have now over 25,000 posts on the Videolan Forums...
You can check my profile.
Of course, I am getting closer to VLC_help, who is at 25,600+ posts... And the total number of post is above 32000.
The usual amount of trolls, aggressions and misunderstanding are still present, because most people still do not understand the concepts of volunteer, open source and free. But well, haters gonna hate.
February 12, 2013
Jean-Baptiste Kempf
Technical update on the WinRT port
Status
So, a few weeks have passed, and I have not spoken a lot about the port on WinRT/Metro/Windows RT/WP8.
Of course, some of you will complain, but the main reason for that, is that I've been very busy on VLC
So here is what we did
VLC engine
The biggest part of the work resides in the port of the VLC engine to a WinRT compatible runtime.
A lot of the work we've done so far has been on that.
More specifically, we have:
- ported VLC APIs call to UNICODE (wide chars),
- allowed VLC to be compiled for Windows 8 API targets,
- upgraded some VLC Win32 API calls,
- removed some code-path when compiling for WinRT,
- fixed some issues on mingw-w64 toolchain for Windows 8,
- prepared a compatibility library,
- changed our packaging for WinRT,
- improved our audio output for Windows.
Winstore compatibility library
A lot of work has been and will be on this library, so let me speak a bit more about it.
Instead of ifdef-ing the VLC code everywhere for WinRT, we decided to reimplement the forbidden calls in a library that would expose the same old Win32 functions, but implemented with the allowed APIs.
The biggest advantage of this approach is that you don't need to modify a lot of your common codebase, and that you don't need to hack all the libraries that are linked to VLC. And this would have been a huge task. Moreover, it allows to adapt to newer versions of Windows more easily. Moreover, this library will be usable by every other project.
But as you can imagine, doing that is quite tricky, since we don't modify VLC, we don't modify the headers, but we insert it at link time...
We have done some of the work, but we still have a huge amount of work to do, notably on threads and Winsock reimplementation.
This library is hosted in the mingw-w64 repository and will be my focus for a bit of time.
Application
Above the VLC engine (libVLC), we have a CX/C++ wrapper, in order to expose VLC functions to the application, since libVLC is plain C, and it is compiled in Visual Studio.
Above the wrapper, we have the main application.
This application is written in C#, compiled in Visual Studio, and uses the wrapper in order to access playback functions.
So far, the application has a basic media library, and playback support using VLC engine. The media library UI follows more or less what we've shown in the KickStarter. The player UI wasn't shown, but it looks a bit like the normal Video application, in order to match the official style.
The video, so far, is rendered into a memory buffer from libVLC and then is displayed using Direct2D in a video surface. This is not yet the best method, but it is good enough for now.
What's next
So, what are we going to work on now:
- the winstore compat library
- the winstore compat library (threads) ,
- the winstore compat library (MSVCRT),
- the interface, in order to match our promises,
- the audio and video outputs, to go faster.
A lot of the work is going to go faster now that we have done correctly the beginning and a beta as soon as possible for our backers.
February 11, 2013
Jean-Baptiste Kempf
Opinion sur la consultation publique lancée par la Hadopi
Sur l’initiative de la consultation publique
Au début de l’année 2012, VideoLAN a saisi la Hadopi, dans la cadre de sa mission de régulation des mesures techniques de protection, sur la question suivante :
De quelle manière l’association VideoLAN, éditrice du logiciel libre VLC media player, peut-elle mettre à disposition des utilisateurs une version du logiciel VLC media player permettant la lecture de l’ensemble des disques couramment regroupés sous l’appellation « Blu-Ray » et comportant des mesures techniques de protection (MTP), dans le respect de ses statuts et de l’esprit du logiciel ?
Cette question est posée à la Hadopi en sa qualité d’autorité publique indépendante, dotée, par application des dispositions de l’article L.331-36 du Code de la propriété intellectuelle, du pouvoir de rendre un avis sur toute question relative à l’interopérabilité et donc d’interpréter les dispositions en la matière.
Le 6 février 2013, VideoLAN a appris que la Hadopi avait ouvert une consultation publique spécifiquement sur la question qui lui est posée et sur laquelle elle doit répondre depuis maintenant plus d’un an.
Malgré la demande de la Hadopi, VideoLAN ne peut répondre officiellement à cette consultation publique, dans les modalités prescrites. En effet, l’association ne peut être à la fois demandeur à la saisine et consultant « disposant d’une expertise dans ce domaine ».
Ainsi, nous entendons informer le plus grand nombre de son argumentation juridique relative à la notion d’information essentielle à l’interopérabilité.
Vous pouvez trouvez ici, en pdf, une opinion sur le sujet.