Yet another blog for JBKempf

New report about the WinRT port

Jean-Baptiste Kempf — Tue, 02 Apr 2013 17:33:00 +0200

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

Over 25000!

Jean-Baptiste Kempf — Wed, 13 Feb 2013 17:22:00 +0100

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.

Technical update on the WinRT port

Jean-Baptiste Kempf — Tue, 12 Feb 2013 10:37:00 +0100

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.

Opinion sur la consultation publique lancée par la Hadopi

Jean-Baptiste Kempf — Mon, 11 Feb 2013 17:30:00 +0100

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.

Why we need a KickStarter for VLC on Metro

Jean-Baptiste Kempf — Tue, 11 Dec 2012 18:21:00 +0100

KickStarter for VLC on Metro

As you might have heard, some developers of the VideoLAN team have started a kickstarter quest to crowdfound a port of VLC on WinRT.

The reason for this kickstarter is that porting VLC to WinRT will be hard and long, if we don't speed it up.

And yet, quite a few people seem to think the task will be simple, like on neowin or Hacker News.

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.

Roadmap

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,
etc...

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.

Conclusion

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...

Windows Store and the GPL

Jean-Baptiste Kempf — Thu, 22 Nov 2012 10:23:00 +0100

FOSS and AppStore

As more and more software distribution are going through so-called App Stores, the question about the compatibility of their terms and conditions with the open source licenses, notably the GPL, often arise.

Personally I don't like those, but I can understand why they are popular and will continue to be popular.

So far, the Android store is open source friendly, and Apple one is not yet open source friendly.

But there is a new one in town, so I will look at the new Windows Store, that will ship WinRT Metro and Windows Phone 8 applications.

I will look at the 3 main liberties (copy, modify, redistribute) and the unrestricted usage liberty.

Legal analysis

Part 1: Store terms of use for users

The referent document can be found here.

The first reaction that those terms of use are way better than the ones from the competition. I don't really like Windows 8 but this is very well executed.

In section named What are my rights for apps I get from the Windows Store?

All apps made available through the Windows Store are licensed, not sold, to you.

This is quite normal for software.

In most cases, that license includes the right to install and use your app on up to five Windows 8 enabled devices simultaneously. If you try to install an app on more than five devices, it may be deactivated automatically from one of these devices, so that no more than five instances are activated at any one time.

5 device limitation, for most cases. This needs clarification for what other cases are. (see the bottom of this mail)

In limited circumstances, such as when a publisher designates the app as eligible for use on only a certain type of device, apps might not install on other types of devices.

Publishers can be assholes or have not ported to ARM or whatever stupidity we add later on, on our devices.

We provide the name of the app provider licensing each app, which may be Microsoft or a third-party app provider."

Microsoft will always tell you the name of who actually licenses the application.

All apps are licensed to you under the Standard App License Terms at the end of these Terms of Use, unless the provider of an app provides you with access to separate terms or agreements in the app listing page, in which case those terms will apply.

Either there is a correct license, or we force our broken terms.

Those terms might also include a privacy policy. The app publisher is the seller and licensor of the app.

Microsoft is not the seller or licensor, they act as a store.

When a third party is the app provider, Microsoft is an agent of the third party that provides the app to you, but we aren’t a party to the license between you and the app provider, and our privacy statement doesn’t apply to treatment of information you might exchange with the app provider when using the app. In such cases, Microsoft isn’t responsible for the app or its content, your use of the app, any warranties or claims relating to the app, or customer support for the app.

Microsoft is not responsible for 3rd party apps, and does not apply neither its terms of conditions nor privacy policy, if there is a license.

But your relationship with Microsoft and your use of the Windows Store will still be governed by Software License Terms for your Windows operating system and these Terms of Use. Because Microsoft processes the app purchase or, in some cases, the in-app purchase transaction as the agent of the seller, you might see Microsoft listed as the seller on sales records.

But even if it is the case, the Microsoft Store software and Microsoft software are govern by Microsoft SLT.

The rest of the terms is not about apps, and then there is their SLT which is clearly not open source, because of the section 3 that forbids the 3 main liberties.

Part 2: Application Developer Agreement

The referent document can be found here.

The important part is named: 3) g. License to Customer for Windows Store apps.

You, not Microsoft, will license the right to install and use each app to customers. You may provide a license agreement to the customer for your app.

Same as above, restated as a developer point of view.

That license agreement or other terms that govern a customer’s use of your app (including any privacy policy), or a link to them, must be delivered to Microsoft for publication via the product description materials you provide to Microsoft.

You must share the license to MS,

If you do not provide such materials, then the Standard Application License Terms, attached as Exhibit A, will apply between you and customers of your app.

or the SLT will apply, automatically.

If you provide your own license agreement, your license must, at a minimum,

Your license must allow, at minimum (so more can be allowed):

(a) permit the customer to download and run the app on up to five Windows 8 enabled devices that are associated with that customer’s Microsoft account, without payment of any additional fees to you (from either Microsoft or customer),

At least 5 devices.

(b) include "disclaimer of warranty" and "limitation on and exclusion of remedies and damages" sections that are at least as protective as Exhibit A

10. DISCLAIMER OF WARRANTY. TO THE FULLEST EXTENT PERMITTED BY LAW, (A) THE APPLICATION IS LICENSED "AS-IS," "WITH ALL FAULTS," AND "AS AVAILABLE" AND YOU BEAR ALL RISK OF USING IT; (B) THE APPLICATION DEVELOPER, ON BEHALF OF ITSELF, MICROSOFT (IF MICROSOFT IS NOT THE APPLICATION DEVELOPER), AND EACH OF OUR RESPECTIVE AFFILIATES, VENDORS, AGENTS AND SUPPLIERS, GIVES NO EXPRESS WARRANTIES, GUARANTEES, OR CONDITIONS IN RELATION TO THE APPLICATION; (C) YOU MAY HAVE ADDITIONAL CONSUMER RIGHTS UNDER YOUR LOCAL LAWS THAT THIS AGREEMENT CANNOT CHANGE. APPLICATION DEVELOPER AND MICROSOFT EXCLUDE ANY IMPLIED WARRANTIES OR CONDITIONS, INCLUDING THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.

Usual "NO WARRANTY" section.

(c) disclaim any support services from Microsoft and the customer’s device manufacturer and network operator (if applicable).

Be clear on support services and who is in charge of the support.

Your license terms must also not conflict with the Standard Application License Terms, in any way, except if you include FOSS, your license terms may conflict with the limitations set forth in Section 3 of those Terms, but only to the extent required by the FOSS that you use. "FOSS" means any software licensed under an Open Source Initiative Approved License.

Your license should be compatible with the SLT, except if you include FOSS, in which case you can violate the part of the SLT that disallow reverse engineering, decompile.

Here is the part of the SLT that you can explicitly violate:

work around any technical limitations in the application;

reverse engineer, decompile or disassemble the application, except and only to the extent that applicable law expressly permits, despite this limitation;

make more copies of the application than specified in this agreement or allowed by applicable law, despite this limitation;

publish or otherwise make the application available for others to copy; or rent, lease or lend the application.

Technically

Technically, a contrario from what Microsoft is trying to explain people, WinRT applications are Win32 applications, that have artificial limitations imposed by the Windows Store submission process.

They are usually linked to MSVCR110 for standard calls, which is a major component of the operating system on which the executable runs. Those applications don't ship anything else than the usual executables and a few .xml crap.

tl;dr: Summary

Your usages are not limited; except you cannot use the application on more than 5 devices, unless the license clearly says you can use it on more devices. That might need an extra clarification, to check if you can have unlimited devices.

You can reverse engineer, decompile, disassemble the application, make more copies of the application, publish, distribute, rent, lease or lend, as long as you are FOSS.

Therefore, I think it is quite safe, now, to publish a FOSS application on the Windows Store.

How to properly(?) relicense a large open source project - part 3

Jean-Baptiste Kempf — Tue, 20 Nov 2012 17:06:00 +0100

Relicensing VLC to LGPL

As you might know, or might have read, I have spent a lot of my time to relicense libVLC, aka VLC engine, from GPL to LGPL.

This is a continuation of the LGPL posts, please read the previous posts, if you have not done it already.

Here is the last part, that should answer a few questions I've had.

Part 3: numbers and Q/A

How many lines of code were relicensed?

I have not done the total count, but the LGPL modules are now around 230,000 lines of code.

The GPL modules are now around 150,000 lines of code.

Does this mean the VLC will come back on the iOS store?

Well, the honest answer is still maybe. I do not have a crystal ball.

First, I have no checked the compatibility between the AppStore and the LGPL, and then, as far as I know, MobileVLCKit, MediaLibraryKit and the VLC audio and video outputs for iOS are still totally GPL.

And, as far as I know the legality of the AppStore terms and the GPL is still shady.

Did you have to contact companies?

Yes. There was a limited number of people who used their corporate email and therefore, we needed the check from their hierarchy. I can think about SFR, Viotech, BBC, M2X, Jutel and Actech, but their might have been more.

When working for companies, it is probable that you handed over our patrimonial rights to the company. Therefore, we needed to get the OK. Since this is more a singularity than the norm, this went quite smoothly, in all cases.

Are you crazy?

Probably, yes. Why?

Did you have some difficulties to convince some people?

Well, yes. Some people, notably very old contributors, wanted more details and information with the change. But a couple of mail or a call were enough to explain everything.

Do you think the GPL is a bad license?

No, the GPL is a great license, but it is not the magic silver bullet that works all the time. Moreover, times have changed, and a lot of companies know that contributing back is more cost-effective than forking a project, licensed under a more liberal license.

Did you learn stuff doing this?

A lot. Legally, mostly, but also socially and about our community.

What about other modules?

The main question is about the streaming modules. So far, I don't know. It might come, or might not. This will depend a bit of the first reactions on the current relicensing.

Are you available for hire?

Yes

What if you did a mistake?

Well, I am quite sure I did not. I've spent a lot of time to make stuff correctly, and it was long and boring.

Yet, in the unlikely eventuality I did a mistake, here are the failsafes:

I am quite sure of the support of the top 32 (2⁵) contributors of VLC, which account for more than 47200 commits which represent over 91% of all VLC commits,
I have received 230 people agreements, which is a large chunk of coders contributors on VLC, probably more than the half,
The code from people not responding was not relicensed,
The process was correctly done and validated,
VideoLAN and ECP support the change,
VLC would very likely be considered as an Œuvre collective under the direction of VideoLAN by legal ruling in France. I will detail this point in the next part,
Unknown contributors that we haven't heard back from will probably be considered as missing, in a similar case than the case of an œuvre orpheline.

Therefore, I don't think I did a mistake, and if I did a mistake, I think it will be only on a very limited piece of code (easy rewritable), and I think VideoLAN and VLC authors would be allowed to relicense it anyway.

French Authorship law and community projects

NOTA BENE: if you are an idealist developer, you are forbidden to read the following because you will not like it.

There are 3 main cases for intellectual works done by a group of authors: l'œuvre composite, l'œuvre collaborative and l'œuvre collective. Of course, those concepts apply very badly for software.

The composite work is clearly not in the scope of VLC, because the GPL takes care of that.

The collaborative work implies that we only deal with physical entities, which is not true; and that the software is finished, in order to be divulgué, which is clearly not the case for VLC.

The collective work implies that some entity is in charge of publication, which is more or less true, seeing that VIA and VideoLAN have done that so far; but it implies that each contribution cannot be traced back to a single author, which is also not true.

We are in a mix here, because no situation perfectly fit. Seeing the jurisprudence of the last 30 years on this, we would probably be considered to be in the last case by a judge.

Seeing that the very large majority of contributors have agreed, that we have contacted all the contributors (and I have proofs of that), that VideoLAN is doing the coordination, that we are not denaturing the spirit of the final work, a French judge would very likely consider that VideoLAN and the main VLC authors have the rights to relicense the last pieces anyway.

This was confirmed by a few lawyer friends of mine.

Do I like this situation?

Not really, but dura lex sed lex.

And it probably saves us from overzealot annoying people.

Yet, I don't think I did a mistake.

I did it!

Jean-Baptiste Kempf — Wed, 14 Nov 2012 00:26:00 +0100

Hello HN: you should really read part 1, part 2 and part 3 about this change.

This afternoon, I finished the relicensing of most of the code of VLC to LGPL, like promised:

VLC modules LGPL commit.

You should read my posts on this subject.

Thanks to all VLC contributors, especially the important ones!

Last year, I also did the VLC core LGPL commit.

How to properly(?) relicense a large open source project - part 2

Jean-Baptiste Kempf — Thu, 08 Nov 2012 23:57:00 +0100

Relicensing VLC to LGPL

As you might know, or might have read, I am spending a lot of my time to relicense libVLC, aka VLC engine, from GPL to LGPL.

This is a continuation of the LGPL posts, please read the previous post, if you have not done it already.

So, I had a list of contributors on the parts I was considering to relicense, thanks to the previous work.

Cleaning the contributors list

This huge list was dumped in a spreadsheet, using LibreOffice. I used during all the relicensing with crazy big formulas to keep my status up-to-date.

While I thought curating the list was useless, it revealed very important, since some developers use pseudonyms or change e-mail addresses. I thought my list was already unique in the past, but it was not.

Of course, a lot of emails were invalid, so manual corrections where necessary.

Splitting the list

During the core relicensing of VLC, an important number of users allowed us to relicense all the VLC code, so I had to mark them as such in the spreadsheet.

For each group of modules, I had a different blame log, since the complete relicensing seemed too big a task, and logical groups could be relicensed individually.

Then, with an export of the csv, the raw blame.log, a bit of awk, grep, cut, I had a list of people remaining to mail. This list would get update, after every batch of answers.

Mailing

The next step is the obvious one, mailing the developers. I did that with a small Python script made by Ludovic.

This was a short letter, with explanations and a prototype for an answer.

I have mailed no more than 30 contributors in a single batch, because processing the answers (or lack of) could be quite long.

Answers and reactions

In average, the answers were like this:

25% of the emails just bounce,
15% of people answer positively during the next hours,
10% of people answer positively during the next days,
50% do not answer at all.

After a second and a third mail, I usually got around 50% of positive answers.

A few points are interesting:

People answering fast were usually the ones that were GPG-signing their mails (this was asked in the LGPL letter).

Quite a few people were surprised that I would mail them ("I only wrote one small commit", "This was minor code").

Many people explained me they did not care what license the code was under, as long as it was open source. Some of them gave a full VLC relicensing authorization. Two even gave all the transmittable rights to VideoLAN.

A few people thanked me for taking the task of relicensing.

Finding and stalking

Now is probably the harder part, where you will think I am crazy.

So, after the first part, we get usually half of the answers. We need the other half.

For the bouncing emails, finding quickly an updated email online, fixing the videolan aliases solved many issues.

But for the rest...

Techniques for stalking

The first ones are obvious:

Ask older contributors, especially for people from Ecole Centrale Paris for contact
Use google (most of the time, it gives a link to VLC, though)
Look on freecode, github, gitorious for an alternative contact
Find a website (they are geeks!).

Some are a bit intrusive

Use LinkedIn and ask for an introduction
Friend them on Facebook
Create an account on another weird social network
Ask one of their friends and annoy them
Ask their boss.

Or clearly bad:

Find their phone in a Phone Directory
Use whois on some of their domain
Use whois on a domain hosted on the same machine of their domain
Go to their workplace.

Contact

Then, I used IRC, mails on multiple addresses, phones, fax and other means to get them to mail me.

Over, over, over and over, and over.

This could get really annoying to do, to be honest.

Getting rid of people

At some point, you realize that some of the contributors are not going to answer.

So, now, you need to actually analyze their code contributions and starting working on it.

First, is there code still in place and not deleted? Is the license LGPL, by any chance?

Then, is this module very important? Can we drop its priority?

Then, is this feature important or not?

And then, I deleted some code, reverted some commits, rewrote some and or isolated code from them in a separate files to reduce the future impact.

This is not nice? Well, not answering is not nice either.

Follow up

You can read the last part about this relicensing.

How to properly(?) relicense a large open source project - part 1

Jean-Baptiste Kempf — Wed, 07 Nov 2012 15:31:00 +0100

Relicensing VLC to LGPL

As you might know, or might have read, I am spending a lot of my time to relicense libVLC, aka VLC engine, from GPL to LGPL.

There are quite a few good reasons to do so, some more obvious than others, but notably competition, necessity to have more professional developers around VLC and AppStores. Other reasons also exist, but this is not the place and time to discuss those.

This is a crazy task, because every developer keeps all its rights, and VideoLAN has little rights on VLC. This involves contacting a few hundred developers, some who were active only 10 years ago, some with bouncing mails, and people spread across continents, countries, languages, OS...

Yet, I did it. Here is the first part of how I did it...

Copyright, droit d'auteurs, public domain and VLC.

As all VideoLAN projects, like x264 or DVBlast, VLC is governed under the French law, even if some don't like this fact.

This means, we are not under a copyright system, but under an author rights system. As such, every author has moral rights and patrimonial rights. The first ones are nontransferable while the later ones can be transfered to another legal entity. This is quite different from copyright.

Moreover, this explains why public domain is not a valid concept for everyone on this planet.

Unlike a lot of large open source projects, authors of VLC keep all their rights on their code, even if the code is minimal. Therefore, to change the license, one must contact every author, even small contributors. From a community management point-of-view, this also makes sense :).

VLC authors, core and modules

VLC is split in several parts, but most of the code is in the core or in some modules.

The core

The core, that was successfully relicensed last year, involved around 150 developers and 80000 lines of code, and the very vast majority of the code was done by two dozens of people, most of whom I have not lost contact with.

The modules

The modules are a different piece of cake.

Even, if we concentrate on the playback modules, which I did, we speak here of 300 developers and 300000 lines of code and the repartition is distributed more evenly.

Listing the right people

The first step, which is the most important, is to correctly list the authors.

This would seem simple from an external point of view, but it is not, mostly because there was no split between authors and commiters in the CVS and SVN days. Moreover, some code was ~~stolen~~ imported from Xine or MPlayer... And sometimes, the author is not even credited in the commit log.

And this should be the time were you think I am completely crazy.

Tools

To get a proper listing of contributors, I used 3 things:

git blame
git log
grep, awk

on our vlc git repository.

Blaming

The first obvious thing to do, is to use git blame on all the files you care, so you know, lines-by-line who actually wrote the code, even after code copy, code move or re-indentation.

I ran it, with extra protection, like this: git blame -C -C -C20 -M -M10 -e $file.

Of course, as some Git expert told me, this should have been enough: git blame -C -C -M -e $file but I preferred to be extra-safe.

Logging

The second obvious thing to do, was to check all the logs on the specific modules folder or file, in case :

someone did some commits on one module
the code was quite changed, so blaming does not find it
yet the idea behind the code is the same.

This solves what I call the authorship leak.

git shortlog -sne $file was used for that task.

Grepping

Finally, some people where only mentioned in the commits logs or just had their names in the final file.

For this, I grepped "patch", "original" "at", "@" in the commit logs.
I also grepped the author sections of every file to check if there were any other author missing.

Conclusion

After those steps, I had a quite accurate list of people to contact. I'll skip you the de-duplicating step, because this is obvious and boring.

The next posts will be about how I contacted and found people, and how they did react.

VLC media player 2.0.4 and VLC for Android 0.0.6

Jean-Baptiste Kempf — Thu, 18 Oct 2012 12:38:00 +0200

VLC 2.0.4

So, yet another release for VLC is around the corner. Why should you care?

Well, first, it shows that the VLC project is still quite alive and that we care about our users, even if we are focusing on 2.1.0.

Then, a bit of stabilization of the 2.0.x branch cannot be bad.

For a summary of the most important features, you have:

Support for Opus codec, including multi-channel and icecast streams,
Support for MSS1 and MSS2 codecs through DMO on Windows and Linux (this can still be hard to use until 2.1.0).
Support for Youtube Live Streams,
Support for BluRays correctly on OSX,
Karaoke control on OSX interface.

For important fixes, we have also:

Youtube, Vimeo, Koreus and Soundcloud are back,
Ogg duration should be fixed in most cases,
HLS, Dash, HTTPS, MKV and Ogg playback fixes,
Wallpaper is back on Windows 7 and 8,
Huge improvements in the OSX interface,
Lots of fixes in the Qt interface,
Windows 8 look is now correct,
Crashes in subtitles, hardware acceleration fixed,
Web interface improvements,
Audio devices selections fixes and synchronizations,
Security issues.

And of course, translations!

VLC for Android Beta 6

At the same time, you might have seen that we have done quite a few VLC for Android releases:

After 0.0.3 and 0.0.4, 2 weeks ago, 0.0.5 and 0.0.6 have been released in the last week.

So, what are the cool things in?

More devices

One of the big issues we have been facing was to support the maximum of devices with only one package.

The first thing was the port of VLC on Android to Intel x86 chips.

Then, we had to work on NEON autodetection, in order to support all Tegra2 tablets and phones directly. A bit hard to do, but, now, our ARMv7 packages work on both NEON and devices without NEON.

Finally, we've done quite a few fixes for devices like the Nexus 7, that allocate the memory in a different way than other devices...

More Android support

We have also been working quite hard to fix our behaviour on all android versions, from 2.1 to 4.1.

Android 2.1 is really slow and buggy, but we need to support it while adding the coolest features from 4.0 and 4.1.

A lot of fixes for compatibility went in, notably in 0.0.4 and 0.0.5.

New interface

As you can see in the following screenshot, we have also been working in having a better User Interface and User eXperience on both tablets and phones.

This is long and difficult, and we move step-by-step, but we are going in the right direction.

Performance

In terms of video performance, VLC is still in beta, in debug mode, and therefore slower than it should be.

We are also improving there, but it is not easy, especially with the very limited numbers of devices we have on our hands. We have still quite a few ideas to improve.

In terms of the UI, we are decreasing the CPU and the memory used for snapshots and audio cover arts, so that the UI is smoother. You can see that in 0.0.6 and will see it more in 0.0.7.

Our background audio service is now completely asleep when not used, and is awaken on phone calls, as needed.

Still in beta

Yet, as you might know about it, this is still not perfect, and needs some work, so this is still a beta!

VideoLAN on HTTPS

Jean-Baptiste Kempf — Wed, 10 Oct 2012 23:53:00 +0200

HTTPS, Cacert

For quite a bit of time, VideoLAN had its websites available on HTTPS. This is important for forums, wiki and other places were you had to log-in to avoid passwords in clear.

Unfortunately, our certificate was a Cacert certificate, which means that it was not recognized by most browsers.

Then Mozilla started its fight against SSL with the most stupid UI ever (and was followed by Chrome) to force people into this SSL certificate extortion business.

Therefore, when, last week, our Cacert certificate expired, we bought a new SSL certificate from Gandi.net.

Available websites

We have now quite a few service that now work on HTTPS:

PS: VLC and HTTPS

VLC 2.1.0 will play HTTPS in a better way, even with self-signed certificates of your seedboxes

News

Jean-Baptiste Kempf — Wed, 03 Oct 2012 00:41:00 +0200

Phœnix (Long time no see)

It has been more than 7 months that I have not blogged around VLC and VideoLAN.

Why? To be honest, I have been quite busy, both professionally and personally, for the best and the worst. But the truth is that, on the little free time I had, I have been lazy, once again, and this website has not been updated

Back! And, a contrario from the previous point, as you might have seen, I've been more active this year around VideoLAN and VLC.

Around the world

For VideoLAN, since the beginning of the year, I've been around in France, in Belgium, in Brazil, in Germany, in the USA and in Estonia. Most of the time, for conferences, but also for partnerships and meet-ups.

VDD 12

In September, I organized, with etix and Gigi, the 2012 version of the VideoLAN Dev Days. This year was a huge success, since we coupled the event with FOMS, and we invited way more multimedia people than previously.

The result:

there were more non-VLC developers than VLC developers at the conference,
the technical level was high,
a high number of FOSS projects were present,
a lot of great discussions, talks, great food and laughs...

One more time

This year, we finally released VLC 2.0.0 and the subsequent VLC 2.0.1, 2.0.2 and 2.0.3.

A lot of things were in VLC 2.0.0 and it was an interesting release, with multi-threaded decoding, new video rendering engine, new UI on Mac, and so many other important things.

However, we've had more important issues that we expected, because people using VLC have more broken machines/drivers than we thought. We are still sorting some things, and hope to get everything right for 2.1.0.

Robot Rock

As you might have seen, I have spent quite a bit of time on VLC for Android, enough to take again the project and release it

Of course, this is a beta, and we have a long and steep road ahead, but we know where to go. More about that in a future post.

And I hope to be able to bring a surprise on this matter too...

Harder, better, faster, stronger

Of course, I've been:

answering on the forum (over 23333 posts), on our mailing lists, and on IRC,
doing PR and community management,
adapting new codecs and devices for VLC,
discussing partnerships to get devices or software pre-releases,
coding on Windows, Mac, Linux, Android,
moderating the mailing lists, the wiki, the patchwork, the forum, the trac,
insulting a few morons,
relicensing more VideoLAN code to LGPL,
rewriting the Windows compilation howto,
modifying our website,
hacking on other projects, sometimes anonymously,
coding, talking, presenting, testing...
having my hair cut,
bored.... not!

It's over 20,000!

Jean-Baptiste Kempf — Thu, 09 Feb 2012 14:19:00 +0100

I did over 20,000 posts on the Videolan Forums to answer questions...

You can check my profile.

Of course, I am far under VLC_help, who is at 23,700+ posts, but still, it's not too bad...

A lot of trolls and misunderstanding are there too, because many people still do not understand the concepts of volunteer, open source and free. But well, haters gonna hate.

VLC 2.0 pour MacOS X

Jean-Baptiste Kempf — Mon, 06 Feb 2012 12:41:00 +0100

Intro

La nouvelle version de VLC, nommée TwoFlower ou 2.0, apporte de nombreuses améliorations et modifications spécifiques à MacOS X. Ce petit article permet de passer en revue ces améliorations, qui sont souvent peu décrites dans les articles plus généralistes.

Ces dernières années, le développement de VLC sous OSX a été un peu chaotique et incertain, avec un vrai questionnement sur le futur du projet. Néanmoins, sur l'année passée, Félix, aidé par plusieurs autres développeurs externes, par le reste de l'équipe de VLC et par un jeune designer, a pris le taureau par les cornes. Il est évident que de nombreux bugs resteront sur les premières moutures, mais les versions devraient se suivre rapidement pour réparer vos bugs les plus gênants.

Nouvelle Interface

La modification la plus visible de Twoflower est la nouvelle interface. Cette interface remplace l'ancienne interface, qui datait des premières versions de OSX.

Tout d'abord, cette interface se présente en une seule fenêtre, pour mieux coller au look actuel des applis OS X. Ensuite, elle existe en deux couleurs: une version noire, qui ressemble au look QuickTime X, et une version grise, comme pour Lion. De plus, sous Lion, elle permet de choisir entre le plein écran natif Lion ou le plein écran classique de VLC.

La plupart des fenêtres utiles lors de la visualisation des vidéos, notamment les filtres audio et vidéo, ont migré vers le style gris transparent HUD. De nombreuses autres fenêtres ont évolués, mais sans bouleversement.

Extensions

La nouvelle interface supporte les extensions lua de VLC pour créer des nouvelles fenêtres et fonctionnalités, comme l'intégration IMDB, Wikipedia, OpenSubtitles et autres. Ce support a été fait tardivement dans le développement, donc une période de stabilisation sera probablement nécessaire.

Périphériques

Jusqu'ici, sous Mac, VLC ne pouvait lire que la webcam intégrée. À partir de VLC 2.0, un support générique des périphériques QTKit a été ajouté pour l'audio (QTSound) et pour la vidéo (QTCapture). Cela devrait permettre de visionner et de rediffuser les webcams externes USB et FireWire, les microphones ainsi que les cartes DVB et SDI compatibles.

Au niveau du support Blu-Ray, VLC 2.0 permet de lire des disques et des dossiers non chiffrés de façon limitée, sous Linux et Windows. Une fois que certains bugs seront résolus, cela devrait être aussi le cas sous MacOS X, mais probablement seulement sous Snow Leopard et Lion. Pour les Blu-Rays chiffrés, la bibliothèque libaacs, n'est pas encore porté sous MacOS X. Avis aux amateurs!

Codecs

La version MacOS X de VLC 2.0 bénéficiera du même support amélioré des codecs, des formats et des filtres vidéos que les versions des autres plate-formes. La partie la plus intéressante concerne le décodage multi-threadé des codecs majeurs pour profiter des machines modernes multi-cores. De nouveaux codecs sont supportés, comme le ProRes, l'AVC/Intra, les codecs 10bits et certaines nouvelles variantes WMV. Le support des formats de fichiers existants a aussi nettement été amélioré, notamment pour le MKV et le MOV.

Le décodage GPU sous OSX, aka VDADecoder, n'est pas de la partie dans cette version, pour des raisons de priorité de développement. Sébastien, développeur VLC, a porté le code dans FFmpeg, mais la partie VLC n'est pas encore prête. On espère que cela arrivera dans une version mineure suivante.

Sortie vidéo

La sortie vidéo, en OpenGL a subit quelques modifications, simplifications et améliorations. Dorénavant, les sous-titres sont rendus à la taille de la fenêtre de sortie, quel que soit la source et directement fusionnés avec la vidéos en OpenGL. Cela améliore la qualité et la netteté des sous-titres. De plus, l'utilisation de fragment shaders pour faire les conversions d'espace de couleurs, même lorsque la source est en 10bits, devrait améliorer les performances.

Support OS X et PowerPC

Cette version 2.0 est compatible Leopard, Snow Leopard et Lion. La version intel 64 bits est la version prioritaire pour Snow Leopard et Lion, car elle seule a le support natif du plein écran sous Lion. La version intel 32 bits fonctionne quant à elle aussi sous Leopard. Il existe toujours une version powerpc pour Leopard, mais qui n'est testée que sous G5, faute de matériel. Cette version powerpc supporte aussi le multi-threading pour le décodage des formats HD, pour ne pas jeter tout de suite les derniers Mac Pro G5 Il est cependant possible que la prochaine version majeure (2013?) ne supporte plus cette architecture.

Le futur

Plusieurs pistes de travail sont en cours: finir l'interface et la peaufiner pour palier aux manques qui seront forcément présents dans les premières versions, travailler sur le support Blu-Ray qui reste trop basique, intégrer le code pour le décodage GPU et changer la licence de VLCKit vers la LGPL afin de permettre de construire des applications non-GPL au-dessus du moteur de VLC.

Nota Bene: Cet article a été écrit par mes soins et donné gracieusement à MacBidouille et Mac4ever.

VLC 1.2: nouveautés

Jean-Baptiste Kempf — Wed, 14 Dec 2011 13:00:00 +0100

Un an et demi après la dernière version majeure (1.1.0), VLC revient avec une nouvelle version: 1.2.0, disponible en pré-version de test. L'occasion de revenir sur les nouveautés de cette version.

Avec près de 8000 changements fait par 150 développeurs, 600 bugs fermés et près de 200 000 lignes de code modifiées, cette version est une des versions les plus importantes de VLC. Plus d'informations sur les contributeurs de VLC 1.2.

De son petit nom "TwoFlower" (qui vient de l'univers DiscWorld), les principales nouveautés de VLC portent sur les sorties vidéos, les nouveaux codecs, le support des Blu-Ray et les interfaces.

Nota Bene: ce post est un écrit qui a servit de base à un article de PCINpact que vous trouverez en ligne.

Coeur Vidéo

Les modifications les plus importantes, mais aussi moins visibles, portent sur la réécriture du coeur vidéo et les modules d'affichage à l'écran.

Sous-titres

Dans les versions actuelles de VLC, les sous-titres textes ont souvent une mauvaise qualité de rendu, notamment lors de visionnage de vidéo SD sur des écrans HD. En effet, pour des raisons de performance, VLC rend les sous-titres à la taille de la vidéo, puis les intègre dans la vidéo avant de les passer à la carte graphique en une seule texture, qui fait le scaling de l'ensemble. Dans certains cas, les sous-titres sont crénelés et de mauvaise qualité.

Sous TwoFlower, un nouveau mode de rendu est possible: VLC envoie 2 textures à la carte graphique, une pour la vidéo, à sa taille d'origine et une pour les sous-titres, à la taille de l'écran. La carte graphique se charge du scaling de la vidéo et d'afficher l'ensemble. Le résultat est bien plus agréable, mais demande du matériel plus récent.

Ce nouveau mode de rendu est disponible pour les sorties Direct3d pour Windows, OpenGL pour Linux et MacOS X et x11 pour Linux.

Shaders, 3D et performance

Le nouveau coeur vidéo permet aussi des améliorations de performances en déchargeant plus de calculs sur le GPU, lorsque cela est possible.

Par exemple, l'utilisation de shaders ARB dans la sortie vidéo OpenGL permet de faire les conversions YUV vers RGB sur le GPU, même en profondeur de 10 ou 12bits.

De plus, les bases des shaders sous Direct3d et de l'affichage 3D ont été ajoutés pour les prochaines versions. Un fork de VLC permet déjà l'affichage 3D sous nVidia Stereo Vision.

Filtres vidéos

VLC 1.2 voit l'ajout de nombreux filtres vidéos, certains connus, comme hqdn3d (suppression du grain), ou gradfun (suppression des gradients), d'autres originaux comme un nouveau filtre de grain, un filtre d'inverse téléciné ou un filtre de stabilisation pour les caméscopes.

Codecs, Formats

VLC TwoFlower, comme à chaque version, apporte le support de nombreux nouveaux codecs, formats de fichiers et périphériques.

Un support limité des Blu-Rays est donc intégré sur toutes les plate-formes. La configuration est compliquée et peu documentée, et une grosse proportion des Blu-Rays n'est pas supportée du tout. Les menus ne sont pas activés non plus. Ceci étant dit, c'est un premier pas.

L'ajout des protocoles de streaming adaptatifs HLS et DASH, des périphériques de capture de vidéo sous MacOS et des cartes d'acquisition professionnelles de types SDI viennent compléter le tableau au niveau du support des périphériques et protocoles.

Codecs

Au niveau codecs, le décodage multi-coeur est dorénavant possible et activé en H.264, DivX, VP3/Theora, Jpeg2000 et Webm/VP8, ce qui peut apporter des améliorations très importantes en performance, notamment en Full-HD. VLC était, sur ce point là, bien en-dessous des packs de codecs du style CoreAVC.

Autre ajout important, notamment pour les professionnels et les fans d'animation japonaise, les codecs en profondeur 10bits, en H.264, Jpeg2000, DNxHD et ProRes sont dorénavant décodés et correctement affichés.

En plus du support de nouveaux codecs, de très nombreuses améliorations ont été apportés à l'existant, notamment au niveau décodage audio et sous-titres HD, au support des méta-données, des codecs RealVideo, des images fixes et des formats Matroska et MPEG-2 TS.

Enfin, le décodage matériel est dorénavant supporté pour les cartes CrystalHD et les smartphones avec OpenMax IL, sous Android.

Interfaces

Les interfaces de VLC ont toujours été les parents pauvres de ce logiciel, notamment sous Mac OS X.

Cette version introduit donc une réécriture complète des interfaces Mac OS et Web.

L'interface Mac OS se présente dorénavant en une seule fenêtre, avec une barre latérale, comme iTunes ou Mail. 2 styles sont possibles dans les préférences: le noir de QT X et le gris de Lion. La plupart des fenêtres secondaires utilisent la transparence...

Ports

La version 1.2 de VLC apporte le portage de VLC sous iOS, Android, OS/2 et Windows 64bits.

Pour cela, le coeur de VLC a été adapté, des sorties audio et vidéo pour iOS, Android, OS/2 et Direct2d ont été ajoutées, et de nombreuses optimisations assembleurs ARM, ont été écrites.

libVLC en LGPL

La dernière chose importante de VLC 1.2.0, c'est le passage du coeur de VLC (libVLCcore et libVLC) de GPLv2 vers LGPLv2.1. Cela permet aux développeurs utilisant une autre licence que la GPL d'utiliser le moteur de VLC.

VLC 1.2.0 features: part 2, formats

Jean-Baptiste Kempf — Mon, 05 Dec 2011 20:46:00 +0100

VLC 1.2.0

I've spoken already about VLC 1.2.0, especially about video, video again and authoring.

However, I haven't spoken about the format supported in VLC 1.2, even if there were some hints in my last post.

Discs and devices

Blu-Ray

One of the major cool thing of 1.2, will be a (very partial) support for Blu-Rays.

Through the VideoLAN project libbluray, VLC 1.2 should be able to open unencrypted disks and backup folders.

Playback of commercially encrypted disks is also doable, but I won't detail the setup here.

DVDs

The whole stack of DVD playback libraries has been updated for VLC 1.2.0.

The releases of libdvdnav, libdvdread, libdvdcss should help to playback more recent disks and fix quite a few annoying issues.

Capture devices

In addition to quite a few fixes on DirectShow and V4L2 capture modules, QTCapture and QTSound capture modules were added for VLC for MacOS X. Requiring QuickTime 7.6.3, it should allow VLC to play, record and stream any QTKit device.

Decklink and DVEO/Linsys/ComputerModules SDI and SDI-HD cards are now supported as input.

PulseAudio devices are now supported as input too.

File formats and protocols

Adaptive Streaming

VLC 1.2 should support, at least partially:

HTTP live streaming, aka HLS, in both live and VOD mode;
MPEG DASH, aka Dynamic Adaptive Streaming over HTTP, in at least 2 profiles.

Those are still under heavy work, help is welcome.

File formats

First, we will have a completely rewritten support for still images playback. The removal of the old fake module should help to make simpler diaporamas with VLC.

Of course, VLC supports new formats, like caf, mtv, awb, f4v, amr, vro (DVD-VR), VDR recordings folders, EBU subtitles (stl). It also supports sid files, from Commodore 64.

The most important improvements to our existent formats should concern Matroska and TS.

A lot of work has been spent on our Matroska demuxer, to handle split-segments and correct seeking. There is still some work to do, but it should be light-year ahead of VLC 1.1.x.

For broadcast and professional people, in addition to the STL subtitles, we have now durations in the Mpeg2 TS files.

Metadata

Finally, we've worked quite a bit on the Metadata support for most file formats.

APE tags, Ogg tags, seeking in flv, mxf, amr should be better supported. Also, as frequently requested, embedded cover arts in wmv, asf, wma are now correctly detected. The missing bits for cover art support are mainly for MKV and APE formats.

Styles for various subtitles formats are also better supported, especially for simple file formats.

Codecs

Codecs support has also improved quite a bit, but that's for the next blogpost. :D

Disc libraries releases: bluray, aacs, dvdcss

Jean-Baptiste Kempf — Sat, 03 Dec 2011 13:36:00 +0100

So, we are working quite actively on VLC 1.2. Many improvements were merged into VLC 1.2, notably for DVD and Blu-Ray playback.

Therefore, there were a few releases of libraries used by VLC, lately.

libbluray 0.2.1

A contrario of this weird number, this is actually the first release of libbluray that is usable.

libbluray is an open-source library designed for Blu-Ray Discs playback for media players, like VLC, xine or MPlayer.

It could be seen as the equivalent to libdvdnav, but for Blu-Ray Discs.

libaacs 0.3.0

In spite of this weird number too, this is actually the first release of libaacs.

libaacs is an open-source library implementing the AACS specification, for all systems, for interoperability.

True, stand-alone, it is of very little use :D

libdvdcss 1.2.11

I am, de facto, the new maintainer of libdvdcss. Congratz to me!

Therefore, I've done a release: 1.2.11.

This is just a boring release, just to incorporate patches and small maintenance, but shows that the project is still alive.

Other libraries

I just wanted to mention that:

libdvdnav 4.2.0
libdvdread 4.2.0
libdvbpsi 0.2.2 (not disc related)

were released too, in the last weeks.

Those projects are still alive and maintained. Cool.

Who wrote VLC 1.2?

Jean-Baptiste Kempf — Mon, 28 Nov 2011 15:42:00 +0100

VLC 1.2

So, VLC 1.2.x is approaching. But who wrote it? Here are some statistics computed by Rémi. You need iframe to read this.

Dotclear 2.4 upgrade

Jean-Baptiste Kempf — Wed, 23 Nov 2011 14:00:00 +0100

Yet another upgrade of Dotclear for this blog. The version is now 2.4.0.

All went absolutely fine, as usual, except the need to edit the config.php to add a line like this:

define('DC_ADMIN_MAILFROM','foo@bar.com');

And after relogging into the admin section, a new style is there, your dotclear with the same cools things and almost the same issues...