Keyword - DVBlast

Entries feed - Comments feed

12 October 2015

This week in VideoLAN - 21

21st week of VideoLAN reports

For the 21st time, here is the weekly report of what has happened in the VideoLAN community and VLC development, during the past week.

Features and changes

VLC

Last week started again with Felix committing, this time to port the CAOpenGLLayer to OS X.

The iOS AudioUnit output gain support for a correct mute implementation, and was moved to a modern Objective-C syntax.

The core gained stream_CustomNew(), to create custom streams; it also gained demux_New() and those 2 functions will be used for adaptive streaming, that need slave streams and demux.

The bluray module gained support for Blu-Ray ISO, through the new UDF implementation.

The HLS module now supports HLS discontinuities, which has been a pain to support for us, so far.
We've also added support for WebVTT and TTML in DASH.

The libass version was updated to 0.13.0 and this should remove the infamous "rebuilding font cache" on OS X and Windows Vista (and later). Anime fans will be happy :)

A Text-to-Speech subtitle renderer was added for Windows, like we did for OS X. It's useful for people with visual deficiencies, that can't read those subtitles very well. It's based on the SAPI 5.1 API.

Finally, we also got fixes for HLS, DASH, cache prefetching, Blu-Rays, OS/2, Closed Captioning sizes, Chromecast, TTML probing and the About view of the OS X interface.

DVBlast

DVBlast, the VideoLAN DVB server, had a 3.0 release.

This release is an important version, that was partially rewritten to use the libev library for the event loop.

It's also the first release supporting OS X.

The new features include PID and SID remapping and support for Deltacast ASI cards.

Download it now!

multicat

At the same time, multicat got a 2.1 release.

This release:

  • adds support for FreeBSD and OS X
  • supports changing source address with raw sockets
  • adds packets reordering based on sequence numbers instead of timestamps
  • adds capping, syslog logging, binding to specific interfaces,
  • and quite a few other things (see NEWS file in the tarball).

Tarballs are available now on the project page.

Android

The Android port was busy to prepare a 1.6.0 and a 1.6.1 releases.

The most visible change of last week was a big interface speed up, in the video and audio lists and the thumbnailer, done by limiting the number of threads and removing some unneeded thread barriers.
We've also added an application-wide threadpool to help managing those threads.

libVLCjni was fixed to support and run correctly on Android 6.0. There is still work left to do for the new permissions model, but that will follow quite soon.

We've had numerous fixes for small regressions mentioned during the 1.4.x and 1.5.x development cycles, notably in MKV/FLV support, screen dimming, various crashes, and incomplete metadata.

The releases 1.6.0 and 1.6.1 were pushed in Beta and in Stage-Rollout on the market.

iOS

MobileVLCKit, the libVLC binding for iOS got support again for the VLCAudio class, including mute support.

There has been improvements on the snapshots events and methods.

The port to tvOS has also been worked on, notably by separating more cleanly the interface from the logic in the iOS apps, so we can have a different interface for tvOS.

WinRT

The WinRT port got changes in the theme, and some colors should now be in your roaming settings.

One of the major crash in the Thumbnailer (start of the application) was fixed: it was due to a race condition when seeking to get the snapshot.

The Windows Indexer API is now used on the Windows 10 Mobile version, to get better search results.
We have more strings translated, and an update of the French translation.
Finally, the gestures are now correctly disabled in locked mode.

The releases 1.8.0 and 1.8.1 were pushed on the store, with all the fixes and features of this week and the previous week.

x264

This week, quite a few changes happened to x264.

The largest changes were ARMv7 and ARMv8 optimizations, done by Martin and Janne, which total around 30 commits on the 40 commits pushed this week on x264.

Anton changed the predictors update and the the row VBV algorithms.

Finally, x264 also has received fixes for PowerPC on FreeBSD, and for the high bit depth lookahead cost compensation algorithm.

That's quite a lot for this week! See you next!

7 November 2012

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

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:

  1. git blame
  2. git log
  3. 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.