Interview: We chat with the leaders of the VLC Windows 8 team « Neowin
Assuming the campaign is successful, what features does the team expect to put into VLC for Windows 8?
At first, we are going to support all the file playback features known from current versions of VLC as well as most ways to customize playback, be it video filters or a full fledged equalizer. Following this initial step, we will have a closer look at optical media playback as well as network streams. Finally, we'll work on porting to Windows Phone 8.
If the campaign fails, does this mean that we will never see a VLC made for the "Modern" UI or that it will simply take a lot longer for the volunteer team to work on it?
The main reason for this campaign is to speed up the development. It is possible that we will get VLC running on "Modern" UI, but at a normal speed, this will probably take a couple of years, and at this point, we will be at Windows Violet (or something...). Usually, all VLC development is done by volunteers in their spare time, but adapting to Windows 8 is an enormous amount of work, notably because there are no open source development tools for it. Therefore we started this fundraiser in order to contract known developers to work on it full-time, to bootstrap the important parts. Seeing the long time it took to get VLC running on Android, we feared that this would be even worse to get it running on Windows 8 and RT. So, while I assume that we would have something for Windows 8 at a certain point if this fundraising campaigns fails, it clearly wouldn't be publicly available any time soon.
What can you tell us about the plans to make a Windows Phone 8 version?
Well, once the port on ARM will be done, porting to WP8 is not that much work. It will need some work, of course, to pass WACK with our custom toolchain, but most APIs are common, so it might just work. The big part of the work is the port to ARM for our toolchain, not to port to WP8, as far as we can see... We hope not to be too wrong :)
What else is the VLC team working on at the moment?
We have a number of cool features coming up for VLC 2.1, like support for new codecs and formats, (like adaptive streaming and Blu-Ray), a new audio core as well as significant improvements to VLC for Android and iOS... Additionally, we are constantly looking into ways to get VLC available everywhere for our users!
They've done it! :)
A few minutes ago, we passed our goal of £40,000 because of you! Thanks so much for the support from more than 2,500 backers like you!
Right now, we are working on another update to lay out our additional ideas. We are enthusiastically looking forward to work on this project and providing the best VLC possible for you.
-- The VLC for Windows 8 team
Technical update on the WinRT port
Update #9 - For backers only · Feb. 12, 2013 · 6 comments
So, a few weeks have passed, and we 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 we've been very busy on VLC :) So here is what we did, mostly on the technical side :)
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 the main focus of some of us 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:
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.
Next update should have screenshots :)
Thanks a lot
no news is good news i guess?
I just really hope they provide a .appx I can include in an image
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.
VLC for the new Windows 8 User Experience ("Metro") by VideoLAN » Follow-up report about the WinRT port — KickstarterQuote:
Like for the last update, 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 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:
The security enforcements (SafeSEH, packagedlibraries) where quickly done (and backported to the main VLC port). The forbidden symbols were a bit more complex.
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.
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.
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!
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! :)
VLC for Windows 8 passes Microsoft's certification but without its audio output « Neowin
It's been almost a year since the VideoLAN team raised enough money via Kickstarter (close to $76,000) to work on a Windows 8 app for its very popular VLC video player. Since then, we have reported that the development of the app has taken much longer than first predicted, mainly because the team has had to stamp down what are known as "forbidden calls" in the program. Today, VideoLAN President Jean-Baptiste Kempf sent Neowin an exclusive update on their progress and it looks like we are very close to an actual release.
Kempf sent over a link that showed that the VLC app had passed Microsoft's Windows App Certification Kit test, which the page shows was accomplished on September 23rd. That's the good news. The bad news? As Kempf told us, "In order to achieve that, we had to disable the audio output, but we are working on that, for the next couple of weeks."
Hopefully the audio output will be enabled quickly and Kempf assured us that more news on the VLC Windows 8 front will be announced "soon". It has certainly been a long wait for those people who donated money to the Kickstarter campaign so that the all volunteer team at VideoLAN could complete the Windows 8 app. We really do wish them the best of luck as they get close to the finish line.