Keyword - x264

Entries feed - Comments feed

19 April 2016

This week in VideoLAN - 41

41st week of VideoLAN reports

Another week, another weekly report about VideoLAN and VLC development.

Features

VLC

We started the week with fixes to build libVLC for WinRT.

Then, after the work from last week, the DVB scanning was improved again, notably to manage timeouts; and the DTV module was fixed accordingly.

The input core was also simplified, removing muteces, reducing the number of functions to create an input, and fixing some preparsing issues (and adding the related tests). One now should just use input_item_AddOptions and the aliases named input_item_New* instead of the input_item_NewWithType or input_item_NewWithTypeExt functions.

libVLC users can now use libvlc_media_get_parsed_status and the new libvlc_MediaParsedStatus event to monitor the item preparsing.

We've had playback fixes for MPEG-SL AAC streams inside TS (#16809), we now support playback of forced subtitles in MP4 (#16803) and support RTP Reception Hint Tracks inside MP4.

We've extended our AVI muxer to support the A-law and ╬╝-law codecs.

Finally, we improved the bluray, SMB, keystore and Qt modules.

Colorimetry

During the week-end, a small team went to Helsinki to work on the colorimetry support for VLC.

As we're moving to UltraHD (4K), the videos are shifting to new, wider, colorspaces. In the past, we just ignored the small differences and took the sane defaults.

It's not possible to do that anymore with the Rec.2020 and the new HDR colorspaces.

Therefore, during the week-end, we laid out the base to support those colorspaces inside the core.

Android

On Android, we started by fixing the navigation with the keyboards and keypads, for the classic android version.

We also added a next and a previous button in the video player, when playing a video playlist.

Then, we added support for subtitles download, from internet subtitle databases.

Finally, we fixed a few bugs, notably on focus and and metadata.

All those changes will be pushed on the store in the version 1.9.8.

iOS

This week, we pushed VLC 2.7.4 for iOS and VLC 1.0.3 for tvOS.

The tvOS release adds notably S/PDIF pass-through and support for finding subtitles over network shares.

The iOS release adds:

  • 3D Touch Quick actions
  • "play all" features for OneDrive and network shares
  • finding subtitles over network shares,
  • stability improvements for SMB shares,
  • numerous fixes notably for video filters, downloads and interface issues.

WinRT

The WinRT code was quite active last week.

A lot of work is not visible, but is done on the libVLC backend, so that the VLC/WinRT code is closer to the Win32 code. We expect that to give us quite a boost in performances.

Another large part of the work on the interface is also not very visible, but is done to improving the medialibrary code, and clean the split between interface and the backend. This should reduce the number of crashes we are seeing.

Finally, last week, we've spent time on the design and look of the application. Here is a screenshot of the current code. AlbumsLight.png

x264

Last week, just before the NAB show, we pushed some new code in the x264 codebase.

The most visible changes are:

  • SSE2 and AVX optimizations for dct, notably for 4:2:2 encoding
  • SSSE3 and AVX2 optimizations for mbtree fixed point conversions
  • improvements pf the b-adapt 1 algorithm, giving better quality without changing the speed,
  • improvements for Windows and Visual Studio compatibility

libbluray

The work on libbluray this week was mostly going on improving the BD-J menus.

This work was visible in the javax.tv namespace, but also in general where many errors were denoted to warnings, and should improve compatibility with more disks.

Finally, there is now a seek event for BD-J.

We'll have a release soon with all these improvements.

That's quite a bit for this week! Thanks a lot and see you next!

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!

24 August 2015

This week in VideoLAN - 15

15th week of VideoLAN reports

Yet another week, and yet another weekly report of what's happening in the VideoLAN community and VLC development teams!

We're going back to one report per week, as holidays are over.
But, to be honest, this week has not been the busiest, I guess mostly because of holidays.

Features and changes

VLC

Yet another week started with MediaCodec fixes, which prevented all MediaCodec decoding on most Samsung devices! Ooops :)

Fran├žois fixed numerous issues with Closed Captions, in the decoder and the text renderer.
This also fixed some background alignment issues that we've had for years...

Felix merged his 0-copy code for the hardware decoding for iOS. This should get very good performances on iOS.

We had a couple of important fixes for the pulseaudio module, that were backported to 2.2.2; and we're now generating Diffie-Hellman parameters dynamically, instead of hardcoding them.

Finally, we had a MKV subtitles regression, an H.264 extradata parsing issue and a large number of memory leaks, that are now past history.

Android

The Android project was moved to the latest version of the Android SDK, and to the last version of AppCompat and we had a few compatibility issues to fix.

We also updated our buildsystem to gradle 2.6, and updated the build-tools and gradle plugins accordingly.

We eventually fixed the loading for playlists and added an option to not rescan the database, if necessary.

In the end, we released VLC for Android 1.5.2 to the store, as a beta version.

iOS

As mentioned above, the most important part for iOS this week is the addition of 0-copy hardware decoding.

We also saw a small bug fixed that could make some files invisible from the media library.

That's not much, but the complete hardware decoding is big enough to explain this :)

WinRT

WinRT was way more interesting, with a couple of releases.

After the 1.5.0 version for Windows, we published a version named 1.6.0, and then one 1.6.1, fixing numerous issues, notably:

  • fixing subtitles display for SRT and SSA, and external subtitles loading,
  • more stable hardware decoding,
  • reworking the main interface, the mini player, and the file explorer,
  • fixing hundreds of bugs found by testers,
  • and fixing a weird crash on Windows RT, coming from the Windows Runtime.

We also published a beta for Windows Phone, named 1.6.0, introducing hardware decoding (disabled by default), and all the updates from the Windows world.

The code between Windows Phone and Windows is now more than 90% the same code.

Expect 1.6.2 and 1.7.0 quite soon.

x264

The x264 project also received almost 20 commits, this week; mostly to fix build issues with Visual Studio, inclusion in C++ projects, and a few other minor bugs.

4 August 2015

This week in VideoLAN - 13

13th week of VideoLAN reports

Yet another week, and yet another weekly report of what's happening in the VideoLAN community and VLC development teams!

Features and changes

VLC

Another week started with MediaCodec fixes, which went on for a few days and terminated with the addition of hardware accelerated Audio decoding on Android.

libVLC received new events for audio corking, muting, volume changing and audio devices: libvlc_MediaPlayerCorked, libvlc_MediaPlayerUncorked, libvlc_MediaPlayerMuted, libvlc_MediaPlayerUnmuted, libvlc_MediaPlayerAudioVolume, libvlc_MediaPlayerAudioDevice.
I backported the first few to libVLC 2.2.2.

The internal of VLC subtitles were completely rewritten, changing the way we're passing the text information from demuxers to decoders to text renderers.
We are now passing some structured text around, with styles information attached to it, instead of pseudo-HTML. This allowed to remove a large piece of duplicated code from text renderers, and put the complexity on the parsing side, not on the rendering side.

The H.264 NAL parsing was largely improved to fix the remaining problems of VideoToolbox for OS X and iOS, notably for frame re-ordering.
The VideoToolbox decoder should now be totally usable.

We added a new speech-to-text subtitle renderer for OS X, that speaks the subtitles instead of showing them on the screen. Of course, this is not for everyone, but it should help in accessibility cases for vision-impaired people.

The OS X interface cleanup work was continued during the whole week, by David, and will probably go on the next weeks.

Finally, we got fixes for AudioTrack (once again), notably for SPDIF support; for numerous memory leaks and some uninitialized variables.

Android

This week was rather calm (but not too calm) on the Android side of things, mainly because of the work on the other projects.

First, we integrated the VLC core changes to improve performance. VLC 1.5.1 should be quite competitive on this matter.

Then, we rewrote completely most of the video player advanced options, using icons in a new single panel.

We also improved the integration of vlc:// protocol and the Intents for 3rd party apps and websites when they try to launch VLC.

Finally, we improved the libVLC JNI API to support SurfaceTexture directly.

iOS

The work for VLC for iOS 2.7.0 was continued greatly this week. And VLC 2.6.3 was pushed on the store.

A large amount of work was done to support RTL languages, as it was announced for iOS 9.
This requires more usage of AutoLayout in our code.

Also, the thumbnail cache was improved, the side menu is getting a lift and a few crashes were fixed.

Some important work was done on MobileVLCKit to make it usable as a shared library framework.

Finally, the integration of VideoToolbox was merged for the iOS project.

WinRT

Like last week, the WinRT port received quite a few changes.

Most of the changes are about the interface, to prepare the integration for Windows 10, to get a more consistent interface, and to listen to user's feedback.

The rest of the changes are on the Direct3D11 hardware decoding.

We'll see how all this gets merged and released soon.

x264

x264 got a new release, and a bit of code merged in the master branch.

It notably adds:

  • NV21 input support,
  • Experimental NASM support,
  • Fixes for some CAVLC overflow, some memory leaks, and file handle leaks,
  • SSSE3 and AVX2 implementations of plane_copy_swap, for NV21 support,
  • Support for MSA MIPS architecture, for SIMD on MIPS,
  • Early Power8 support.

That's all for this week! Have fun!

Don't forget to register now for VDD, this September, in Paris.

16 November 2014

10 years of GSoC and VideoLAN

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.

I thought it would be a good occasion to share what we've achieved around VideoLAN and VLC during those summer of code programs.

Continue reading...

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.

- page 1 of 2