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, ...
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.
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.
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 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).
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 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).
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!
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 […]
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.
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.
But first, the current pictures:
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.
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:
We did also a lot of minor things to help the integration of libVLC and VLC in this modern platform.
We are now mainly working on 2 things:
What we are gonna work just after:
They are gonna get shipped soon
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.
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
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:
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.
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.
So, what are we going to work on now:
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.
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.