Welcome on Planet VideoLAN. This page gathers the blogs and feeds of VideoLAN's developers and contributors. As such, it doesn't necessarly represent the opinion of all the developers, the VideoLAN project, ...
2 weeks ago, we released dav1d 0.5.0.
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:
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.
If you want a quick summary of this post, about our AV1 decoder:
Read the following for more details...
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 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.
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:
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.
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?
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!
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.
Whether you prefer the dark or the light path of the force, we added both modes to VLC:
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.
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.
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.
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.
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!
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.
VLC 3.0.6 suffers from an HTTP request injection vulnerability.
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.
According to our scale, we have had 33 valid security issues fixed thanks to this program:
The 2 more important issues are an Out-of-Bound Write and a Stack Buffer Overflow.
the is not in the VLC codebase, but in a dependency of VLC, the faad2 library, unmaintained, unfortunately.
the 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.
What follows is my personal opinion about those bug bounties programs, and is not VideoLAN's point-of-view.
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.
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
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!