A few weeks ago, the 10 years Google Summer of Code Reunion was held in San Jose. To celebrate for the 10 seasons of GSoC, this event replaced the usual Google Summer of Code summit.
Sunday, November 16 2014
Friday, October 3 2014
A new release
This is the second major release of this application. While still beta, it should be way more stable than the previous one.
The major changes are:
- using libVLC 2.2.0 core,
- redesign of the interface,
- huge performance improvements,
- use of Winsock for networking instead of WinRTsock,
- use of Windows 8.1 widgets,
- move the interface code to Universal to prepare Windows Phone 8.1 port.
To get more stability, the performance improvements and the preparation to port for WP8.1, we had to move the application to Windows 8.1-only.
Be careful, this is still not as perfect and stable as the desktop release.
While this release is still x86-only, we've made great advances on the ARM port. More news soon.
Get it on the Windows Store.
Saturday, March 15 2014
After the first beta release a couple of days ago, a second build fixing the most important crashes has been submitted to the store, for certification.
It should notably fix the crash on start, on some machines, but other stability issues, on the music side too!
We'd like to thank the new contributors that helped.
It should appear automagically in a few hours on the store.
Next release, next week!
Have a nice week-end!
Monday, March 10 2014
Oh boy, this has been a long and bumpy ride!
Today, the first Beta of VLC for WinRT is getting deployed on the store.
As many of you know, the road to come to this point has been long... Very long.
I've been driving or helping some ports of VLC on mobile, but this port has been the hardest, by an order of magnitude.
I'll speak a bit more about the lateness of this port, another time. Today, I'll introduce a bit to this application.
Tuesday, February 12 2013
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:
- 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.
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.
Tuesday, December 11 2012
KickStarter for VLC on Metro
The reason for this kickstarter is that porting VLC to WinRT will be hard and long, if we don't speed it up.
I'm all for funding 40k pounds for VLC (they deserve it), but 40k under the guise of Metro seems a bit much, no?
I dont know but just creating a metro UI shouldn't be that hard should it?
The Windows RT app should be trivial to make... As long as they aren't using Win32 API's, it should just be a matter of recompiling for RT and correcting whatever few bugs they encounter.
Well, no, this is not too much.
We are not the kind of person asking money for nothing, I think we've proven that during all those years.
Let me explain why.
Why we need a KickStarter for VLC on Metro
Designing a UI above VLC, for the "Modern Experience" is quite easy, and we've already done a few proofs of concept.
Finding a designer would be simple and 1k$ for the project would be too much already It would take a couple of months and we would be done with it.
The issue is to get on the store. And this is hard.
Why is that?
VLC (and its underlying libraries, including codecs, networking access or demuxers) represents around 7 Million Lines of Code in C, C++ and ASM languages. And all of this code is following C99 standard and has inline ASM.
Visual Studio cannot eat that code in any way. Believe me, we tried. A lot. So we need to compile the VLC for Windows on Linux, using gcc and mingw.
Unfortunately, this does not work on WinRT ("Modern UI" or whatever you like to call it). WinRT restricts a lot the Win32 APIs. And only the Windows Store knows which ones are allowed.
For example, the BSD sockets are gone... Yes, this is not a joke.
They work on Linux, Windows, Mac, iOS, Solaris, Android, QNX, WP8, WinCE but not WinRT.
So, we need to:
- change and update our toolchains,
- fix MingW for WinRT, in the best way we can,
- link to the newer Windows runtime,
- list the problematic APIs,
- rewrite the code that is using Win32 APIs since 10 years (and in all underlying libraries too...),
- drop some modules or isolate some code,
- write new replacement code,
- write a new interface above all this,
- design the interface correctly,
- fix the code using windows HWND,
- port the audio and video outputs,
- work-around the sandbox for DVD and BluRay playback,
- probably write a WinSock2 replacement library to build all the cross-platform libraries that expect a BSD-socket-like library,
- port to ARM,
Add to that the need to modify MingW to output dlls that we can load on ARM (Windows RT) and do the same project for the different APIs present on WP8.
As you can see, a lot of the work is not really on VLC, but on being able to compile for WinRT with open source tools, since Microsoft tools are not enough. And a lot of work will be work-around the limitations of WinRT.
Of course, a lot of the work will be re-usable to other projects.
So, yes, we will need quite a few developers to do all that. We can do the Android route, and it might take a couple of years to get it there, or we can try to get some money to speed it up...
« previous entries - page 1 of 3