VideoLAN

VLC media player development and general info on VideoLAN.

Entries feed - Comments feed

26 October 2018

The VLC Technical Committee

VLC Technical Committee

I'm very proud to present to you the VLC Technical Committee, as elected during the last VDD conference: Denis Charmet, Rémi Denis-Courmont, Hugo Beauzée-Luyssen, Thomas Guillem and David Fuhrmann.

The role of the VLC Technical Committee (TC), is mostly a technical resolution committee, that will arise and decide when there are disagreements and bike-shedding in our community.

Members

The glorious members of this Technical Committee are:

  • Denis Charmet, the wisest of the VLC developers, and the most-tampered, claims to have never been in conflict with anyone in the community. Let's hope that does not change. (And he has the Mon€¥, so we have to like him...)
  • Rémi Denis-Courmont, the biggest contributor to VLC ever (and still the most active non-sponsored developer around VLC); without him, VLC would not exist anymore; the one that knows more about UB, threads and network than 99.999% of the developers.
  • Hugo Beauzée-Luyssen, active on the VideoLAN community since the late 2000s, C++1x lover (yet I saw him write Go, once!), very active on the Medialibrary, compilers, toolchain, CI/CD, code-coverage, fuzzing and other toolings; he also knows about UB, even in C++ :) (some say he is secretly in love with Windows, but he will deny this). Also member of the board, since quite some time now.
  • Thomas Guillem, one of the most (the most?) active on VLC development; knows wayyyyy too much about audio and video outputs, and codecs in VLC, a lot about Android (and too much about Tizen) and other weird OSes (he even has a mac on his desk). Probably the most knowledgeable about VLC, after Rémi. He loves C and will never switch to other punk langages!
  • David Fuhrmann, the youngest of the TC, is the macOS/iOS touch of this TC, and knows this weird language called Objective-C. Some people claims he even understands Xcode and the macOS toolchain! But in his every day life, he knows C++ (don't tell Hugo)!

As you can see, in all fairness:

there are 2 people of the board in the TC, 2 out of 5 are VideoLabs employees, no roots are part of the TC, nor am I. They know about C, C++, obj-C, and Linux, Windows, macOS.

Details

The fine prints of this Technical Committee:

  • The TC can be contacted to take action, or decide by itself to take an action, on any technical subject that did not reach consensus. If no issue there is, there is no need to call the TC.
  • Votes and discussion of the TC are private.
  • You can contact the TC at vlc-tc@videolaɴ.org
  • The VLC TC cannot take action on community issues or CoC.
  • The VLC TC can be fired by the GA or any other VideoLAN meeting with the majority of votes.

May they do good work! Good luck to them!

1 October 2018

Introducing dav1d: a new AV1 decoder

Introducing dav1d

AV1 is a new video codec by the Alliance for Open Media, composed of most of the important Web companies (Google, Facebook, Netflix, Amazon, Microsoft, Mozilla...).

AV1 has the potential to be up to 20% better than the HEVC codec, but the patents license is totally free, while HEVC patents licenses are insanely high and very confusing.

The reference decoder for AV1 is great, but it's a research codebase, so it has a lot to improve.

Therefore, the VideoLAN, VLC and FFmpeg communities have started to work on a new decoder, sponsored by the Alliance of Open Media.

The goal of this new decoder is:

  • be small,
  • be as fast as possible,
  • be very cross-platform,
  • correctly threaded,
  • libre and (actually) Open Source.

Without further ado, the code: https://code.videolan.org/videolan/dav1d

Name

dav1d is called dav1d, because Dav1d is an AV1 Decoder

(Yes, that is a recursive acronym, no need to tell us...)

Video

You can see a talk during VDD 2018 about dav1d:

VDD2018 dav1d presentation.

Technical details

Some technical details about dav1d:

  • written in C99 (without VLAs),
  • has asm in NASM/GAS syntax (no intrinsics),
  • uses meson/ninja as buildsystem,
  • currently works on x86, x64, ARMv7, ARMv8,
  • runs on Windows, Linux, macOS, Android, iOS,
  • licensed under BSD.

Performance

Currently the source code of dav1d is 1/10th of lines of code compared to libaom and its weight is 1/3rd of the binary size of libaom.

It currently uses 1/4th of the memory usage of libaom and uses a very limited amount of stack.

Depending on the threads conditions (see the video talk linked above), dav1d is more or less faster than libaom 1.0.0, but slower than libaom HEAD.
dav1d having almost no assembly code yet, this is not surprising, and is actually a good starting point for the future.

Of course, those metrics will evolve once we add more assembly code, and when the project evolves a bit more.

Questions

Is it production-ready?

Not yet, but you can start testing it and check how the API works for you.

Can I help?

Yes! We need C, ASM developers, but also app integrators and testers to give us feedback.

I need to ship an AV1 decoder with my OS, my hardware, my app. Can I do that?

Yes. dav1d is licensed under BSD for this very reason.

Please talk to us, if you need to get adaptations for your use-case (hybrid decoders, or specific platforms, for example).

BSD is not copyleft, why?

We want AV1 to be as popular as possible. This requires fast decoders, running everywhere. Therefore, we want to help everyone, even non-open-source software.

See RMS opinion on this subject.

19 July 2018

VLC for iOS and UWP 3.1.0 release

VLC 3.1.0 release

After a few months since the release of VLC 3.0, today we release VLC 3.1.0 on 2 mobile OSes: iOS and Windows Store (UWP).

This release brings ChromeCast integration to iOS and UWP, like it was present on desktop and Android versions.

ChromeCast and hardware encoding

However, it supports ChromeCast in a more performant way, because we added hardware encoders to those 2 platforms.
Indeed, here, for local streaming, we care more about speed and battery saving than we care about bandwidth efficiency, si hardware encoding is a good fit.

On iOS, we're using the standard VideoToolbox hardware encoding to produce H.264 streams, muxed in MKV.

On UWP, we're using Quick Sync Video for intel CPUs (that covers almost all CPUs since 3rd core generation).

In fact, VLC has a QSV encoder since 2013, but it's very rarely used, because people usually prefer software encode (x264). Here, we fixed it and modified it to work inside the UWP sandbox.

iOS

You should really read Caro's blogpost here!

But in that version you have:

  • ChromeCast,
  • 360 video support, with sensors,
  • Numerous bugfixes on the playback core (inherited mostly from VLC 3.0.1-3.0.3)
  • Some decoding speed improvements,
  • Quite a few interface bugs (see 3.1.0 milestone)

UWP

The version is similar to the iOS version, in the fact that it has hardware encoding and ChromeCast integration.

As explained, the hardware encoding is done using QSV.

But it features also a large rework of the codebase and fixes a very large number of crashes.

Also, funnily enough, we've worked on the 8.1 version too, and we will push that one soon on the store. This includes SurfaceRT devices, even if Microsoft has forgotten them!

So VLC 3.1.0, UWP version will be out for:

  • Windows 10 Desktop (x86)
  • XBox One
  • Windows 10 Mobile (ARM)
  • Windows 8.1 Desktop (x86)
  • Windows 8.1 RT (ARM)

Once we fixed an issue, we might even do Windows Phone 8.1.

The Windows 10 versions are on the store today, and we're waiting for a deployment issue to be fixed to push the 8.1 versions!

(Note: if you are from Windows Central, you can contact me for more details)

Have fun!

18 July 2018

Welcome back!

After quite a bit of time far from the blog, I am back around here.

The biggest reason for this silence was that this was taking a lot of my time, but I had almost no positive feedback on those posts.

Let's see if we can do better this time :)

Here is a small cone, to make you more happy:

Large Cone

25 August 2016

Last weeks in VideoLAN - 53

53rd VideoLAN report

During the core of the hot European summer, here is a weekly report about the last 2 weeks in the VLC and VideoLAN communities!

It was a bit calm, to be honest; and I'm a bit late to publish. Summer is the cause :)

Features

VLC

The week started by a lot of code cleanup and renaming for the Mac OS interface. We also had improvements focus on the Sierra release.

On the decoding side, we've had some improvement for hardware decoding in Direct3D11, focused on HEVC decoding.

We also had fixes for the OSX VideoToolbox decoder, notably to be able to restart the decoder when required.

A module supporting the AV1 from the Alliance for Open Media was merged too. So far, it's only a decoder, and disabled by default.

On the streaming side, the MP4 muxer timestamps were fixed. It was also backported to the 2.2.x branch.

We now have ARM64 assembly for our deinterlacer, which will be very useful for iOS, Apple TV and Android TV.

Finally, we had fixes for RTSP passwords saving in the keystore, improvements for RTSP support and the H264 packetizer, and we added support for UTF8 filenames in FTP directory listings, and support for DiscNumber and DiscTotal metadata in MP4, and DNxHR!

Android

On Android, we've mostly fixed crashes, updated translations and pushed 2.0.6 in production, on the play store.

The work is mostly done now on the new media library code, that will be merged later.

WinRT

On UWP, the focus has been on the XBox 1, and mostly on how we can upload files on the box, since we don't have access to the filesystem.

The current solution is using an HTTP webserver to upload the files from your browser, and support for USB disks.

That's all for those weeks, see you next!

8 August 2016

Last week in VideoLAN - 52

52nd VideoLAN report

Another summer week passes by and here is a new weekly report about the VLC and VideoLAN communities!

Features

VLC

The week started with numerous additions to the Direct3D video accelerations and video outputs, to continue the support for 10bits decoding and HDR.

Related to those improvements, we added support for hardware decoding of HEVC decoding inside the TS format, by improving our HEVC packetizer.

We fixed (actually added) the support of QuickTime Videos inside MKV, aka MP4-inside-MKV; and also the support for QuickTime Audio inside MKV.

We improved again the ChromeCast support, by fixing small issues, notably when reloading and stopping the stream.

In the core, an important deadlock was killed, that was affecting Windows and Android platforms.

Finally, we also did a fix for hidden chapters in MKV, and improved the MIDI integration for Windows, and reworked a bit our contrib system.

Android

On Android, we finally fixed the support for old x86 Phones like the ZenPhone that claimed to be ARM phones. Those phones lie about their CPU with CPU_ABI, CPU_ABI AND they expose a fake /proc/cpuinfo to the applications! Thanks to a contact at ASUS, we got a phone and coded a work-around.

We also added support for saving audio-delay when using your Bluetooth headphones, so that you have a different audio-delay when using those headphones than without headphones.

Finally, we fixed a few crashes and regressions that were reported against the last release.

WinRT

On UWP, the biggest focus was on cleaning the code and on the Xbox 1 interface.

More to come soon, I hope!

libbluray

We've had a lot of small fixes for libbluray, mostly on fixing issues and crashes reported by static analyzers, but also build issues, Windows issues, and crashes reported by the users.

That's all for this summer week! See you next!

- page 2 of 39 -