VLC for Android

WinRT still advances As people who follow @videolan know, we keep working quite a bit on our port to the WinRT platforms. It is probably the port where the most effort is spent on those days, and is probably the most difficult. The good news is ... [More] that we are improving quite a bit, and we are closer to having something on the store. Precision about VLC ports Some people said that we stopped working on WinRT to ship VLC on iOS... This is totally wrong, because those are not the same people working on it. VLC development is closer to a bazaar than to a cathedral building, and while the core advances altogether, people, who are volunteers, work on what they want, and on the features they want. This is very often true for VLC modules, and this is even more true for the ports to the mobile platforms. Notably: VLC for Android is mostly developed by Ludovic Fauvet, Sébastien Toque and Edward Wang; VLC for iOS is mostly the work of Felix Kühne and Gleb Pinigin; VLC for WinRT is mostly developed by Rafaël Carré, Geoffroy Couprie, Kellen and me. Therefore, doing work on one platform does not slow down the development of other platforms ports. On the contrary, porting VLC to more platforms improves the portability of VLC, and helps finding weird bugs or misdesigns that benefit all the other ports, when they are fixed! For example, the work on OpenGL ES for Android helped the port to iOS. Or the work on WinRT helped the normal VLC for Windows. WinRT calls So, last time we spoke about our advance, we had to fix 16 forbidden calls to 4 Windows dll, from 5 dlls and all the socket code. And those required WinRT direct calls from C. We fixed most of the issues, including the WinRT static calls, meaning that we rewrote a lot of idl, idl tools and header files. We are at 5 forbidden calls (3 tonight, I hope), to 1 Windows dll, from only the VLC core. We still have the socket code to fix though. The remaining calls are on the threading initialization, and so far, we are not able to create those WinRT objects from a C codebase. We are looking at alternatives, including using a C++ library to work-around this issue. For the socket code, we have an idea for that too, and I hope I can share it soon to you. As soon as we are down to 0 calls, we can upload something on the store, for the backers to test it. Goodies We've done another round of sending of goodies. Therefore, if you had a certificate, a key-holder, a mug or a cone, you should have received them before the end of the week. If you had a t-shirt or a hoodie, they might not have reached you yet. Note that, if you had one of these, the keyholder and certificate will arrive at the same time. If you have not received your goodies, please e-mail us about it, to the email where you received your confirmation from. If you are at a total loss, please mail me or contact me Sorry again for the delay, but we're doing the best we can, so far. Have fun! [Less]

Today, we've published quite a few version of VLC, for your pleasure. VLC 2.0.8 The first release is a stable release of VLC: 2.0.8. This is a necessary update to fix a few crashes and security issues that are important enough to deserve an ... [More] upgrade. Moreover, as VLC 2.1.0 is slowly approaching, upgrading the stable branch is important for many GNU/Linux distributions, or for OS and architectures that won't be supported in 2.1.0 anymore. Unfortunately, there is no much fun in this release Still, grab your version of VLC 2.0.8! VLC for Android 0.1.3 As you might have seen, Android 4.3 was released last week, with numerous improvements and fixes. Unfortunately, this broke the video output of VLC on Android. Moreover, the saddest part was that Google started deploying the upgrade right away on the Nexus devices. Therefore, we had to do a quick bugfix branch and a 0.1.3 release to fix this problem. Get it now on our website or on the Google Play store. VLC 2.1.0-pre2 But the most interesting release is probably the second pre-release of VLC 2.1.0, named "Rincewind". Rincewind by tarthiev. Features Many features are present in this new branch. I will describe the highlights. VLC 2.1.0 development cycle allowed us to ports VLC to mobile OSes, including Android, iOS (again) and WinRT (ongoing).This is important because it will help VLC to be more portable for tablets, phones, smartTVs or boxes. Following the numerous issues on the audio side of VLC 2.0, the audio core has been mostly rewritten, including a rewrite of most audio output modules, and of many audio filters. This should allow us to fix volume delay, crackling, multi-channels issues and improve performance. We introduced many hardware decoders and encoders, for performance reasons, for mobiles and desktop in order to decrease the power usage when using VLC. This includes OpenMaX for Linux and Android, Media SDK on Windows and VDA on Mac OS X. We added support for numerous new codecs, formats and protocols, including a preparation for Ultra-HD, notably for new codecs, like VP9 or HEVC, that are arriving soon. A few new video and audio outputs, filters and converters, to increase VLC capabilities, have been addded. Some interfaces, notably the Mac OS one, got a bit of polishing, to solve the few rough edges VLC has. A relicense of most of the libVLC library code license to LGPL has happened, to allow wider spreading of our technology.This also extends to numerous language bindings. Some important improvements on the Webplugins, including windowless mode and increasing reliability, are also part of the package, to please our web developers friends. Stats Fun fact: there have been 6999 commits since the split of 2.0.0 from master and the tagging ofr 2.1.0-pre1, creating a diff of more than 4 million lines Download You can download this preversion now! [Less]

So there we are. We have come a long way. Today, it’s my pleasure to announce that VLC for iOS is back on the App Store. It’s available free of charge in any country, requires iOS 5.1 or later and runs on any iPhone, iPad or iPod touch. This is more than an upgrade of […]

Complete VDPAU has just landed in the VLC development tree.

This is a straight answer from me about the blogpost from Secunia. I will not comment much about the methods of this company or the fears they try to push onto their users. They are using the same tactics of other companies of this security ... [More] business. I will therefore go straight to the point. SA51464 Intro A crashing PoC against VLC 2.0.4 was sent on the full disclosure mailing list on the December 7th. You can get the POC here. Note that this is a crash for swf, a format that VLC was never officially able to open (no extensions assignation, not present in the open dialog,...) and one cannot open it automatically or by mistake. You can see the stacktrace on our bugtracker. The crash is in libavformat/libavcodec libraries, from the FFmpeg/libav projects. Not at all in VLC. FFmpeg/libav are used by thousands of projects, including your TV, your smartphone, your DVD player and quite likely your browser. The list of projects includes Chrome, all Smart TVs from Samsung and LG, all media players codecs packs, all media players on Linux, most video editors, every video converter, most DVD players that play DivX or MKV files, etc... The normal thing to do is to report those kind of issues upstream, of course. This is what responsible security researchers do, because the issues are then fixed in all software... But that does not include Secunia. Fix I provided a fix that you can see here on December 11th. As you see, this IS NOT the same fix that Secunia shows on their blog and claim we used: FFmpeg patch. This is the first lie of Secunia: they don't even look at our codebase, while we are open source! Then, Secunia does its advisory on the December 12th : ie AFTER. And calls it unpatched, while a patch is ready and public, as you could see above. This is the second lie of Secunia: they don't even check their advisories. Release I did the release on the 14th December of VLC 2.0.5. 7 days after the full-disclosure POC. That's quite nice for a hobbyists project, no? You can download the VLC 2.0.5 for Windows here. Try it yourself! You have the POC, you have the VLC release 2.0.5. It does not crash at all. I just retested on Windows 8. Aftermath But they refused to close their advisory: When the VLC team released version 2.0.5, which claimed to fix SA51464, Secunia Research contacted the VLC security team and informed them about the incorrect patch. However, VLC apparently disregarded our mail. This is the third lie of Secunia: the PoC was not crashing at all. Moreover, I have no idea what mail they are speaking about: I have received no mail from Secunia in December, January or February. That means the next 3 months after their advisory was out, and they did not change anything in it, nor tried to communicate, while we tried, people in their comments and forum did, repeatedly. Who is failing at doing coordination between vendors and researchers ? The mail from Secunia in March that they quoted even mentions: "Following my line of argument I hold the view that SA51464 has to be seen as fixed with VLC 2.0.5." Then, they said, again, in their blogpost: However, they failed to understand the root cause and provided a patch which did not fix the core issue. This is, once again, wrong: we saw the crash they gave us and we fixed it. Seriously, try it yourself with VLC 2.0.5. You can also download VLC 2.0.6 for Windows. You can also download VLC 2.0.7 for Windows. You will see that this is fixed in all those versions. The next day we re-visited the issue, ... in version 2.0.6. However, since we could not prove exploitation, we decided to change the status to “Patched”. ...concluded that the issue is exploitable even in the newly released version 2.0.7. This is the fourth lie of Secunia. No regression post 2.0.5 on this particular file. I seriously have no idea what they mean. The thing seems to be so confused on their side that they already changed 3 times the status of this advisory. After that, I decided that I could not do much against Secunia, except being very annoyed by all this situation. Secunia and MKV: SA52956 Then comes more WTF from Secunia. Someone came to Secunia with a supposedly PoC on MKV. This PoC crashes VLC, indeed, but does nothing more. The issue was an uncaught exception in C++ in the MKV demuxer. We asked for some times, to fix the issue. We fixed and committed the issue here on April 27th. Only 4 days after. As you can see, this is not an integer overflow error, but an uncaught exception and I doubt that it is exploitable. This uncaught exception makes VLC abort, not execute random code. This was told to Secunia on several occasions, including on the phone. They never came with an exploit, yet they did not change any word of their advisory or gravity of the issue. To me, Secunia does not even understand their core business and refuses to discuss technical points. Secunia attacking VideoLAN on Twitter Then, on May 22nd, Secunia started lying and misguiding our users as you can see on Twitter, while VLC did not appear on the US report... When we mentioned the mistake, they did acknowledge but they did not even apologize. As you can imagine, we were quite pissed against Secunia.... This is exactly what I call defamation. EDIT: But, you know what, they re-edited their report on May 29th to make VLC show on the US report... Look at the date on the right-end corner, it is not the 22nd... Why else would they say "You are right"? What kind of security company edits their reports afterwards to change the results? If they knew that they were clean, why doing that? MKV issue fixed At end of May, we were contacted again about the MKV situation, and we said that this was a crash, not an exploitable security issue. You can find the PoC here. We gave them the revision of the patch in which VLC had the crash fixed, and a proper build, but they kept saying it was "unpatched". They decided to publish their advisory, while a version fixing VLC was published (we publish nightly builds every night), a very simple workaround for VLC 2.0.7 existed (remove the libmkv_plugin.dll) and with a PoC that was crashing VLC but not exploiting it. Moreover, they refused to hold the advisory until VLC 2.1.0 was out, and published it anyway. Final insults and attack Finally, today they blog about us saying: That VLC apparently doesn’t think vulnerabilities in third party libraries, for example FFmpeg (which is statically linked), are issues they would need to warn their users about, but only vulnerabilities in the “main” VLC code, is obviously not the right thing to do, and gives a false image on the security status of VLC. This is so patently untrue it is not funny. Can you explain this patch or that one? And we don't statically link on all platforms. Moreover, why not sending the issue to FFmpeg? There is a lot of code in VLC, and they are probably a lot of security issues in VLC, noone is denying that, but the way Secunia deals with this was outrageous and I think I have all the rights to be pissed and claim that they do not work "with vendors". It might be easier to attack a group of hobbyists than big companies. [Less]

This is just a very short post (almost a bookmark-post) to share that we finished the releasing of the VLC engine on Android to LGPL. This is now live in the release that was done today, named 0.1.2. It mostly includes: the Java code in the ... [More] org.videolan.libvlc namespace, the jni code gluing between libVLC and the Java code. The corresponding commits are here and there. This should allow to use the VLC engine in any other application on Android. But be warned: so far, it is very difficult to build [Less]

Today, we published VLC 2.0.7. 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 our main website for manual downloads. The in-app announcement […]

News Hello, Like last post, I've spent too much time working on VLC than writing updates and communicating, and I'm sorry again. We are still working a lot of time, with almost a couple of persons spending most of their time on the WinRT port of ... [More] VLC media player. The biggest issue is that we have not managed to pass the store validation yet, because the VLC backend is not ready yet. I'll explain in this blog post where we are. VLC backend on WinRT Reminder: So, the core of VLC and most of the modules, named libVLC, are the target to adapt to run on WinRT. The UI will integrate this core to show the videos. As I previously explained, the build process of VLC is not integrated with Windows Tools, notably Visual Studio, because VLC uses Unix Tools to run on all platforms. This is one of the reasons why VLC media player works on Windows, Linux, BSD, Solaris, iOS, Android, OS/2 and so many other operating systems. The main objective of the KickStarter was the compliance of this core to the WinRT Store Application limitations. We're almost there, but not quite. The issues we were facing with the compliance were mainly 2 things: Extra Security, Forbidden APIs. The security enforcements (SafeSEH, packagedlibraries) where quickly done (and backported to the main VLC port). The forbidden symbols were a bit more complex. Forbidden calls When we started the project, we had over 600 unique symbols (Windows API calls) used in VLC, for a total of over 15000. We are now at 16 left. And 32 more if we activate the networking code. This is cool, but not enough, since we must be at 0 to enter the store. I'll explain now how we did it. Simple symbols replacements Some symbols were easy to replace, when you knew that you are targeting only Windows 8, because they had some similar methods. So, for each symbol, we provided a replacement with a newer API. This was quite long, but easy to do You can see the result of our work here: mingw-w64 code. Removal of code and Unicode The second part was to remove some code in VLC that was not meant to be used in WinRT mode; this was mostly the code for the Console, the multimedia timers and some NT services. This improved the port of VLC media player for Windows, not only the one on WinRT. We also removed some code from libVLC to move it to VLC, when it made sense. This is a good move for libVLC, in general. Finally, we moved all the code of VLC and the dependencies (8 millions LoC) to UNICODE and Wide Chars. Once again, a task not too difficult, but a bit boring and long. Most of that part was done mid-March. Then we hit a wall. MSVCRT The wall is called MSVCRT, aka Microsoft C Runtime, the equivalent of the libc, the C standard library, Every version of Visual Studio and Windows comes with a new version, with version numbers from 2.0 to 11.0. It is often a dependency headache for big projects. Most open source projects use the old version named msvcrt.dll, the version 6.0. But on WinRT, one MUST use MSVCRT 11.0 in order to pass the validation. This meant that we had to modify our compiler and toolchain to be able to link with this version. This took us weeks of work, reading documentation, testing, asking Microsoft, doing it step by step and finally arriving to the result. First, we had some mismatch between Debug and Release versions of the libraries when trying the validation. But as we were doing it manually, it was quite hard to understand what was going on, and the documentation was very scarce. And then, running the application with MSVCRT 110 was just crashing without meaningful messages or usable debug reports or crashes. When we asked Microsoft, some engineers told us that this could not possibly succeed, since the validation would not allow application compiled with 3rd party compilers to link with MSVCRT110. We did not want to believe them, since this would have killed the project. And, they were wrong. We did it, but this took us way more time than anything we had anticipated. The final work was shared and integrated in our toolchain, Mingw-W64. All other open source applications will benefit from that, from now on. COM RoAPI So, the final piece is composed of symbols that only have replacements using the WinRT APIs. Those WinRT APIs are a bit like extensions of Windows COM APIs. They work in a similar way, and are usable with methods similar to CoCreateInstance, named RoActivateInstance. However, they are not the same. People using Visual Studio, use a language named C++/CX that has a bit of magic to hide all the details. But, of course, we need Visual Studio to use C++/CX. And we have GCC, targeting C code :D Again, accessing those APIs directly from C code compiled with GCC should not be possible (according to some engineers), but we have been trying that path for quite a bit of time. 2 weeks ago, we had a good success: we were able to call a simple functions from a sample code, using RoActivateInstance. So, the hardest part was done. What we are doing now is just rewriting the Microsoft WinRT headers and adapting the toolchain to munch those and call those symbols. We're working full time on that part! Conclusion: tl;dr It's been a hard time working on this port, with many more technical issues than expected. Therefore, we've been slower than expected. We've done things that people (even from Microsoft) advised us against, and so far we've passed all the issues. So a great outcome is arriving! We have a bit of work still to go on rewriting the headers to call the new WinRT APIs, and kill the remaining 16 symbols. We're working full time to fix those! [Less]

Members of the VideoLAN team and our friends from Tomahawk will attend our favorite summer geek conference: Akademy. This year, it’s in Bilbao, Spain starting on July 13. In addition to the usual KDE conferencing and geeking, Qt Contributors Summit will take place at the same venue! We are looking forward to what’s new in […]

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 ... [More] 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!   [Less]