Planet VideoLAN

dav1d 0.5.1: more speed!

Jean-Baptiste Kempf

A few reminders about dav1d

If you follow this blog, you should know everything about dav1d.

The VideoLAN, VLC and FFmpeg communities have been working on a new AV1 decoder, dav1d, to be the best and fastest decoder.

0.5.1

2 weeks ago, we released dav1d 0.5.0.

With 0.5.0, we showed that we were between 3x and 5x faster than aomdec on desktop CPUs, including 32bit CPUs, and between 2.5x and 3x faster on Android and iOS 64bit phones.

We even showed we were a lot faster than the new gav1 decoder on Android 64bit.

However, there were 2 cases where dav1d was not the best:

• desktop without SSSE3 capabilities, aka very old CPUs, in single-thread,
• Android phones in 32bits, in single-thread.

0.5.1 is a small release focused on those cases.

0.5.1 gets up to 50% speed improvements on SSE2 CPUs, which should make dav1d faster than aomdec in all desktop cases, from C to AVX-2.

At the same time, 0.5.1 gets up to 41% speed improvements on ARMv7 CPUs, which makes dav1d at least as fast as gav1.

Of course, in multi-thread, we were already faster

So, yes, dav1d is now faster than all the other decoders in all cases.

October 29, 2019 06:52 AM

dav1d 0.5.0 release: fastest!

Jean-Baptiste Kempf

tl;dr: dav1d is getting even faster

If you want a quick summary of this post, about our AV1 decoder:

• dav1d is still ready for production, and getting used more and more,
• dav1d has a speed gain of 12% on ARM64 mobile CPUs,
• a gain of 22%-40% on SSSE3 processors
• and another gain of 4-7% on AVX-2 processors, which was already quite fast.

Read the following for more details...

A few reminders about dav1d

If you follow this blog, you should know everything about dav1d. Two months after 0.4.0, and Four months after the 0.3.0 release, we show our new release: 0.5.0.

AV1 is a new video codec by the Alliance for Open Media, composed of most of the important Web companies (Google, Facebook, Netflix, Microsoft, Mozilla...). AV1 has show to be 20% better than the HEVC codec, but the patents license is totally free, while HEVC patents licenses are very complex to acquire.

The VideoLAN, VLC and FFmpeg communities have started to work on a new decoder, dav1d, to be the best decoder.

0.5.0

The release 0.3.0 was a very solid release, bringing huge gains in performance, and getting AV1 decoding ready for primetime.

0.4.0 (which I did not blog about, sorry) brought 15% gains on ARM64 and notably reduced the RAM usage by half.

This new release, 0.5.0, aka "Asiatic Cheetah", is bringing even more speed improvements to AV1 decoding.

On AVX-2, I know I said already 2 times that we were at the maximum speed, but we got even faster, notably thanks to improvements on MSAC and CoefDecode. The gains range from 3% to 7% depending on the content.

On SSSE3, we have merged now most of the assembly functions, for both 32-bit and 64-bit architectures. This gives improvements ranging from 20% to 40% on SSSE3.

You can now see that our SSSE3 performance is quite close to our AVX-2 performance. This is, of course, very CPU dependent.

Because you shouldn't blindly believe me, you should really see the Phoronix article on our release.

As you can see, depending on the content, we're between 3 and 5 times faster than aomdec, and 8 times faster than gav1 on desktop CPUs.

ARM64 performance

On ARM64, for mobile, we've continued to merge ASM code too. We've done all the major functions in ASM now.

The speed improvements from 0.3.0 to 0.5.0 are close to 15% in Single-Thread. This can give improvements around 20% in Multi-Thread, depending on the CPU and the content.

If you look at other ARMv8 CPU, we're almost at 1080p30 for the Chimera sample:

AV1 decoding on Android: gav1

As you might have heard, there is a new player in town: Google released gav1 decoder, "optimized" for Android.

As you can see here, on ARM64, the architecture of all the recent smartphones, dav1d is beating gav1 quite largely:

It seems that gav1 is slightly faster on ARM32, but no recent device is running ARM32. So what's the point?

On iOS, we've measured between 30% and 170% increase in Single Thread.

Next?

We need to keep improving, because it will be fun. The next targets for improvements are SSE2 and ARM32, because we still have gains there.

A release in the next 2 months, maybe?

October 14, 2019 05:36 PM

VLC for iOS 3.2: a new hope

Jean-Baptiste Kempf

A new release: 3.2!

VLC for iOS is our port of VLC on the iDevices and has been around for quite some time, and is quite popular.

However, lately, the application development had a bit slowed-down and the interface was outdated. So, we decided to do a massive refresh on the code and on the interface.

Here comes VLC for iOS 3.2!

Interface

This release gives the first part of the interface refresh, focusing notably on the audio and video collection views.

The audio view features a full audio media library, similar to the Android version of VLC, sorting by Artists, Albums, Genres and so on.

As you can see, this is more fitting for modern version of iOS. In addition, you can see that the main menu has moved to a bottom tabbar, instead of the side menu.

The playlists have their own entry on the tab, with network (NAS, URLs, Cloud) and settings.

Dark/Light

Whether you prefer the dark or the light path of the force, we added both modes to VLC:

After?

There are still a lot of changes to be done in the interface, notably for the network section and the video player.
But we couldn't wait to have everything fixed in a single version. Therefore, those views will be refreshed in the version 3.3.

Also, missing features will be added, depending on the user reports.

Under the hood

We focus on the interface, but in this release, a lot of the work was not visible, and was done to improve the code and simplify the future evolutions of the application.

First, as the name indicates, this release is based on libVLC 3, like the current desktop version.
It is not based yet on VLC 4.0, the development version of VLC, as VLC 4.0 is not ready yet.

However, a very large number of bugs have been fixed specifically for the iOS port of VLC, in the VLC 3.0 branch

Swift

The biggest change in the codebase is the move to Swift for all the new code added to the project, in addition to some migration from Obj-C to Swift for some internal classes.

You should look at the changes on the gitlab project.

MediaLibrary

The media management for this version of VLC has moved to the medialibrary project, written in C++, common to Android and iOS, and soon the desktop version of VLC.
This new library replaces the medialibrarykit project.

As it is written in C++, a wrapper for the medialibrary was created, in Obj-C, to be able to use it in our application.

Test it

Because of the large amount of changes, there are probably numerous bugs in this release, so please test and report, so we can fix it quickly!

September 19, 2019 08:47 AM

VLC plug-in for YoutubeDL

Rémi Denis-Courmont

Just a little something I whipped up during my spare time... This VLC plug-in uses YoutubeDL to extract videos and music from websites, supporting a whole lot more sites than VLC's own Lua parsers do.

August 25, 2019 04:30 PM

VLC adaptive HTTP User-Agent injection vulnerability

Rémi Denis-Courmont

VLC 3.0.6 suffers from an HTTP request injection vulnerability.

June 10, 2019 08:00 PM

Hong Kong Open Source Conference 2019

Rémi Denis-Courmont

I will be giving a talk on VLC media player in cooperation with the VideoLAN foundation at the upcoming Hong Kong Open Source Conference on 14-15 June 2016. Follow the link to sign up. See you there.

June 09, 2019 07:00 PM

VLC 3.0.7 and security

Jean-Baptiste Kempf

VLC 3.0.7 release and EU-FOSSA

We just released VLC 3.0.7, a minor update of VLC branch 3.0.x. This release is a bit special, because it has more security issues fixed than any other version of VLC.

This high number of security issues is due to the sponsoring of a bug bounty program funded by the European Commission, during the FOSSA program.

Severity

According to our scale, we have had 33 valid security issues fixed thanks to this program:

• 2 high security issues, (only one was present in 3.0.x),
• 21 medium security issues,
• 10 low security issues.

The 2 more important issues are an Out-of-Bound Write and a Stack Buffer Overflow.

the Out-of-Bound Write is not in the VLC codebase, but in a dependency of VLC, the faad2 library, unmaintained, unfortunately.

the Stack Buffer Overflow is a VLC 4.0-only issue in the new RIST module, and is therefore not impacting actual release of VLC.

The medium security issues are mostly out-of-band reads, heap overflows, NULL-dereference and use-after-free security issues. Those issues should not be exploitable with ASLR, but are important anyway, because they can crash VLC.

The low security issues are mostly integer overflow, division by zero, and other out-of-band reads with no actual impact. Those issues are not exploitable.

The best hacker on the program was https://hackerone.com/ele7enxxh.

Opinion about bug bounties

What follows is my personal opinion about those bug bounties programs, and is not VideoLAN's point-of-view.

Usefulness

If you've listened to some of my talks or spoke to me (I'm sorry for you), you know I'm a bit critic of those programs, because they give money to find the issues, not to fix them.

What about you give money to VLC instead of random hackers?

Well, security is important, so this is cool for our users, but still this is a mixed bag, for me.

So, in order to mitigate that, we gave large extra-bonuses for fixes provided at the same time as issues were found, to improve this problem.

Hackers

During this program, we've had a lot of different hackers, from the best to the worst technically: so many script-kiddies, and people telling us that the VLC source code was visible... but also people who had deep understanding of C, of the stack and of memory issues.

But I would like to focus a bit more on the type of reporter we've seen.
We've had people ranging from the usual security-asshole to some of the nicest guys ever, who cared deeply to help us. And when working with the nicest people, they often send patches to fix too.
At the opposite, some reporters were more than distasteful, insulting, impatient, trying to get 2 times the bounty for the same bug, or even reporting the issues to other programs (Android one) to get more money.

The result of that, is that when you don't know how much to award for a security issue (is it medium or low?), you decide on the niceness of the reporter

Thanks

In the end, I'd like to thank the European Commission, Julia Reda, the nice hackers and the people from the team who fixed all those bugs!

June 07, 2019 07:23 AM