WEBVTT 00:00.000 --> 00:11.880 Hey, good morning, everyone, I got 20 minutes to speak about 25 projects, so that's going 00:11.880 --> 00:12.880 to be fast. 00:12.880 --> 00:19.520 I have the unfortunate pleasure of doing a ton of updates of most of the open source teams 00:19.520 --> 00:23.000 who are working too much, and so they don't present themselves. 00:23.000 --> 00:26.440 So my name is JB, I do too many things. 00:27.200 --> 00:33.040 I'm still the president of the Vidalan nonprofit, because no one else wants to deal with legal matters. 00:33.040 --> 00:35.240 I work on a lot of the open source. 00:35.240 --> 00:42.040 We'll see what that software, including VLC, 264, David and so on, maintainer of all the libraries 00:42.040 --> 00:46.560 that no one wants to maintain, we'll talk about that. 00:46.560 --> 00:52.480 And I'm president of several companies, video labs, FF Labs, one called Kiber, and I'll also 00:52.480 --> 00:56.440 now member of the European Open Source Academy, which is great, I have no idea what that 00:56.440 --> 00:59.120 means. 00:59.120 --> 01:03.520 I think it's, I give awards to people, which is cool, right? 01:03.520 --> 01:09.880 Anyway, let's go back a bit, FMP-7.1, which is probably the last one I talked about at 01:09.880 --> 01:14.000 first them, which was probably two years ago, was like the largest FMP release ever, 01:14.000 --> 01:17.560 there were so many new decoders and major ones, right? 01:17.560 --> 01:23.120 A lot of things on Vulcan, a lot of things on VLC and VLC, I am F, and so on. 01:23.120 --> 01:30.000 But also what was more important on the FFMP-7 versions were, everything that was done 01:30.000 --> 01:34.080 by Anton, about the multi-shradding of the CLI, right? 01:34.080 --> 01:38.280 Some of you already heard me talking about that, but this was probably like the largest 01:38.280 --> 01:44.280 modification for normal humans who are using FMP, even if you're using the CLI of FMP, 01:44.280 --> 01:45.280 are you normal? 01:45.280 --> 01:46.280 I don't know. 01:46.280 --> 01:50.240 But still, like so many people, like so much of the community is working, of course, on 01:50.240 --> 01:54.400 the libraries, you may be correct, you may be format and so on, but so many of you try 01:54.400 --> 02:01.560 to use the CLI, or use chatGPT to generate the common line, I know some of you do. 02:01.560 --> 02:07.080 But like the problem was so many companies, including a Marx, bit-moving, all large companies 02:07.080 --> 02:08.080 were, or VMA, right? 02:08.080 --> 02:13.360 There are some of the people, so that's great, to bunch, are using directly like we developed 02:13.360 --> 02:18.720 something about FFMP, because FFMP was, it was basically monosraded, right? 02:18.720 --> 02:23.200 Which means that when you were doing HLS, adaptive streaming, you were waiting for the 02:23.200 --> 02:24.920 lost lowest. 02:24.920 --> 02:28.600 So there was like a huge work from Anton to use strides, right? 02:28.600 --> 02:33.800 Strides are complicated, I bet most of you don't know what strides are, and if you do, I 02:33.800 --> 02:34.800 don't think you do, right? 02:34.800 --> 02:38.560 Yeah, of course, if you do, Anton, you do, but most of you don't. 02:38.560 --> 02:39.560 I don't see that, right? 02:39.560 --> 02:41.560 I think I do, I don't. 02:41.560 --> 02:46.520 But anyway, that was a lot of work that was done on the FFMP.C, and so a lot of companies 02:46.520 --> 02:51.400 now are dropping all their tools that were using on FFMP. 02:51.400 --> 02:53.400 That was in seven. 02:53.400 --> 03:01.800 FFMP H was out in, I think, April, it's a bit less compared to the other ones. 03:01.800 --> 03:07.240 The major work was still on VVC, which is the next generation MPEG codex that no one will 03:07.320 --> 03:13.560 have to use, but get codec engineering maintained and hired, so that's great for them. 03:13.560 --> 03:17.960 But there is the VAPI decoder, which means that if you have a recent card that is going 03:17.960 --> 03:23.120 soon to happen, you might have a accelerated VVC decoding. 03:23.120 --> 03:29.280 There is a support of real video 6 decoder, great, I've never seen any real video 6, 03:29.280 --> 03:32.520 but that's great, right? 03:32.520 --> 03:38.640 Everybody is way more difficult is a FLVV2 or extended FLV. 03:38.640 --> 03:42.760 It's a way that you use the very old FLV and RTMP, and you put every other codex in it, 03:42.760 --> 03:46.200 and multi-audio. 03:46.200 --> 03:51.660 It was a big fight of mine, because I said for years that RTMP and FLVs there for the 03:51.660 --> 03:56.440 next 25 years, and so we need to support more codex and people say, no, we need new things, 03:56.440 --> 04:02.200 and then people have, like, from WebRTC to SRT, to NDI, to whatever, and the thing 04:02.200 --> 04:04.000 is like, RTMP is everywhere, right? 04:04.000 --> 04:05.000 So there is no reason. 04:05.000 --> 04:16.000 So now FLV can, an RTMP can give everyone, and 5.1 audio, only 30 years later, GPXL, it's a very 04:16.000 --> 04:21.000 hot topic, but GPXL is the image format that is going to win for the future, compared 04:21.000 --> 04:27.040 to EVIF and HCIF and so on, because they have the best marketing, are they good 04:27.040 --> 04:32.200 features, but most of these have the best marketing, EVP decoding, FPV decoding, it's time 04:32.200 --> 04:38.160 of Samsung decoder for to compare with ProRes, basically. 04:38.160 --> 04:43.160 And Whisper filter, amazing, in FLV-8, but probably the biggest changes have been done 04:43.160 --> 04:49.520 by Lynn, she was here, yeah, handling about VPA, VP9, everyone, and ProRes RAW decoder 04:49.520 --> 04:58.760 in Vulcan, and having, like, actually GP with decoders inside, FFMP is kind of new. 04:58.760 --> 05:09.720 David, yeah, so David is finished, congratulations to everyone, I mean, like there was almost 05:09.720 --> 05:15.480 no development on David in the last year, because we don't everything we could on X86, 05:15.560 --> 05:19.960 almost everything that Martin could on the on, and so we're at the end of the road. 05:19.960 --> 05:25.640 The only new things that are happening on Whisper, thanks to Remi and Nacer and so on, but 05:25.640 --> 05:30.440 basically I don't think we're doing anything anymore on David, it's insane, it's still 05:30.440 --> 05:38.360 30,000 lines of C and 245,000 lines of handwritten assembly, which is probably the, yes, 05:38.360 --> 05:44.000 the largest codebase of assembly in the world, I guess, to give you an idea, the whole FFMP 05:44.000 --> 05:53.800 is going to be the codec, it's 110,000 lines of assembly for the whole codec, I don't 05:53.800 --> 05:57.240 think we have more to do, right? There is still people doing some poor PC and long-son 05:57.240 --> 06:04.920 work, but this is good, so we have, we can move to the next project, okay, VLC, tomorrow 06:04.920 --> 06:19.920 is the 24-year of VLC, tomorrow there is no actual birthday of VLC, but on the first February 06:19.920 --> 06:26.000 2001 there is a university who allowed to make that as GPL, so for us it's a birthday, right? 06:26.000 --> 06:33.800 We still continue working on the VLC-3, the last version of VLC-3 has 547 million downloads 06:33.800 --> 06:39.040 on our website, because people complain about the numbers we have, right? People are updating 06:39.040 --> 06:45.520 and updating, well those are not updates, so that's quite large, and we did a lot of work 06:45.520 --> 06:55.200 on VLC-3.023, one of the things is basically, sorry, the image doesn't show, we have 06:55.200 --> 07:00.680 a dark mode on Windows, we work on, officially we support Windows on ARM, but mostly we still 07:00.680 --> 07:06.360 work on Windows XP, right? So, the last version of VLC runs from Windows XP to Windows 07:06.360 --> 07:11.520 11 on ARM, right? And when you compare to lazy companies like Google or Microsoft, like 07:11.520 --> 07:15.680 we don't even do that while they have a bit more money than we do. 07:15.680 --> 07:21.000 We're working on VLC-4, sure, it's not dead, this is a screenshot, not a design work of the 07:21.000 --> 07:28.960 last three on MacOS, it has a new clock, a new playlist, a new player, a new media library, 07:28.960 --> 07:34.760 and updated UI, a preposterous that is separated in a separate binary, so that when it crashes 07:34.760 --> 07:37.680 and is scanning your stuff, it doesn't crash your VLC, do you also try to do a 07:37.680 --> 07:44.520 new previous frame, yes, finally previous frames, a lot of new APIs, it supports pipe 07:44.520 --> 07:49.200 wire and wayland, and maybe at some point we'll have a gapless and for subtitle, because 07:49.200 --> 07:53.120 this is what people complain the most, and it takes me time to answer to them, so it's 07:53.120 --> 08:02.280 easy to fix, then do that. When is it out? No idea. Yes, I know, 21st century, okay, that's 08:02.280 --> 08:10.840 okay. Okay, some of the things are happening on VLC on mobile, most of you are not on iOS 08:10.840 --> 08:18.680 I know, but some of you do, and yeah, for the same rate, VLC for iOS, now supports iOS 26, 08:18.680 --> 08:25.520 we see support iOS 9, which of course, like not even Apple is able to do with iOS, that's 08:25.520 --> 08:30.480 why it's so difficult. Kind of things on cloud integration, on codecs, but also lot of things 08:30.480 --> 08:35.560 are happening on the same time for 4.0, HDR, picture and picture, multi-channel audio, dual 08:35.560 --> 08:41.080 subtitle, and vision OS, oh watchOS, right? You remember there was a joke about VLC 08:41.080 --> 08:44.960 running on the watchOS that I did a few years ago, well, someone revised that port, so you 08:44.960 --> 08:57.040 can destroy the battery of your watchOS in 2 minutes. Actually, it's 10, but anyway. And same 08:57.040 --> 09:03.440 things on Android, right? So the Android version has had a lot of work, we have the same 09:03.440 --> 09:09.120 HD web access, remote access so that you can basically upload things without having to 09:09.120 --> 09:17.360 manage the USB nightmare that is on Android. Support for 16K pages, which is a big topic, 09:17.360 --> 09:25.680 lot of work on basically all the APIs, major library favorites, equalizer, lots of work 09:25.680 --> 09:30.800 on the Android Auto, because as you might have seen, a lot of car manufacturers are moving 09:30.800 --> 09:38.120 from their own crap to Android Auto or Android Automotive, you're going to see more and 09:38.120 --> 09:45.960 more of that. And also, we still support Android 4.1, up to Android 16, that's probably 09:45.960 --> 09:54.920 API 21. So yeah, still supporting most of the platform as we could. 09:55.880 --> 10:05.080 Live DVD. Well, yeah, I took some time to maintain them again. It's boring. It's very old code. 10:05.080 --> 10:11.640 It was not designed correctly. Yes, but we had to support for all DVD audio, this summer, 10:11.640 --> 10:17.560 thanks to a G-Sock guy who's from Egypt. And so the thing is, you have to understand that DVDs 10:18.520 --> 10:25.480 are not encrypted with the CSS algorithm. They are in a type of things that is called cpxm, 10:25.480 --> 10:31.000 and which was an open source library that was dropped by someone somewhere, and that was never integrated 10:31.000 --> 10:38.440 any distribution. Also, because, well, no one cares about DVD audio besides me, I guess. 10:39.960 --> 10:45.560 I think there have been only 1,000 issues of audio DVDs, DVD audio in the wild, but still, 10:45.560 --> 10:51.640 like, for long term, it's important to maintain them and have something. So we integrated this 10:51.640 --> 10:57.960 library, rewrite, we would have of it, and put that inside the DVD CSS. And we worked on the 10:57.960 --> 11:03.400 lib DVD read to have all the passing of all the structures, so you can have all of that. 11:04.120 --> 11:11.240 A ton of new APIs, we moved everything to meson, and we spent some time to support UWB, 11:12.040 --> 11:17.640 BSD, and some recent versions. So, I did really see the during the summer of lib DVD CSS read 11:17.640 --> 11:23.880 nav, which we are not updated for four to five years. And we're now working on DVD RV, 11:23.880 --> 11:27.640 which none of you have have heard, but those are the DVD camcorders. 11:28.840 --> 11:32.920 Same for lib Lore. Again, like, and maintain library, I took back the maintenance ship. 11:33.640 --> 11:37.240 Ton of things about new version of java, because I didn't know but java is alive again. 11:37.640 --> 11:44.280 So now we support up to java 23. We've been working, I did a release in 1.4 this summer, 11:44.280 --> 11:52.280 we just did like two days ago, a 1.4.1. We're working on everything related to 3D, SSIF, HDR, 11:52.280 --> 11:58.200 and a ton of java, right, which I am amazingly good at. Now, especially to improve the 11:58.200 --> 12:03.560 capability with new blue rays that are out that have no more features for the menus. 12:04.120 --> 12:08.120 And we are going to work on everything related to HDR 10 and 3D. 12:10.920 --> 12:15.000 We have a new project called check assembly. Check a sim. I don't know how you're supposed to 12:15.000 --> 12:20.280 pronounce it. Check a sim, I guess. And it's not a new project, right? It was like all the tools 12:20.280 --> 12:25.160 that we used to write all the assembly in x to x4 that was taken inside ffm pair and then 12:25.160 --> 12:30.440 moved to David is basically a way to benchmark and run all your assembly code and check if it 12:30.440 --> 12:34.680 matches your C version, right? It's a dark magic thing that no one understands except two people 12:34.680 --> 12:39.880 in the world. It's amazing, but basically it's type of like it's similar to ffsing, right? And it's 12:39.880 --> 12:45.320 going to check that basically the input in the output are the same whether you're doing the C and 12:45.320 --> 12:49.960 all the other functions. And it's very useful because now we don't do just one assembly, but it's 12:49.960 --> 12:55.720 a six arm with neon as a C, this five, there is multiple vector lens. And so this was moved to one 12:55.720 --> 13:00.520 project that is still a video-long project and now it's been integrated back into David. 13:00.520 --> 13:06.360 It's going to be in x to x4 and David 2. Oops. x to x4 is still alive. 13:06.360 --> 13:11.800 Turn off things are happening mostly on neon and SV assembly. And this is going to be important 13:11.800 --> 13:18.600 because the patterns of x to x4 are mostly expired next year, so people will use x to x4 completely 13:19.000 --> 13:29.080 so they will use an open source encoder. David 2. Suppose call it as you want. David 2, 13:29.080 --> 13:37.960 Dave 2D, David, you're French, right? This is also a horrible joke, but it's ready. It's not open. 13:38.520 --> 13:44.280 If you need access, ask me. We're waiting for the official go of the final spec because 13:44.280 --> 13:49.640 only the draft spec or EV2 are ready, but in the next two or three weeks you'll have it's 13:49.640 --> 13:57.960 completely open and mostly working. EV2 is basically everyone and 22% better basically. 14:00.520 --> 14:06.680 Oh come on, 22. I'm happy. Two other libraries that we've talked not often, one is 14:06.680 --> 14:10.920 lip specialist. We did a large release, the first actual release of lip specialist. It's an audio 14:11.000 --> 14:17.880 renderer for everything that is object high order, objects like what you call 3D audio, right? 14:18.680 --> 14:24.360 Dolby 2 at most or whatever the name, right? All those soundbar. There is no open source renderer 14:24.360 --> 14:28.760 and most of the time the renderer where mixed with the codex, like inside AC4 or 3G. 14:29.800 --> 14:35.000 And we did that in a separate library which is doing basically all the rendering. It's also doing 14:35.000 --> 14:41.240 everything like what we call bineralization, which is like when you have headsets and it feels like 14:43.000 --> 14:47.880 it's fixed like spatial while it's not. And so everything is done in library, it's only library 14:47.880 --> 14:52.600 because it's way more complex than you think. It seems easy, it's not, especially because you're 14:52.600 --> 14:56.520 going to have like when you rotate the head you need to rotate your soundfield and have a constant 14:56.520 --> 15:04.680 energy. This is not easy. And so this is the first release that we've done in October and we did a 15:04.680 --> 15:10.680 huge demo because there is a new open source format for 3D audio called IMF. And there is another 15:10.680 --> 15:14.920 library which is probably like the one I've never talked about which is the most, one of the most 15:14.920 --> 15:20.520 active video and project. It's a lip placebo. Lip placebo is basically a GPU filter libraries which 15:20.520 --> 15:25.240 is doing everything HDR tone mapping, reversal mapping and all those crazy things. It's starting to 15:25.240 --> 15:30.840 actually MPV, right? So it's funny now it's a video run project. It has doing all the GPU pipeline 15:30.840 --> 15:35.720 and I have turned off filters and well no one talks about it but like one of the most active 15:35.720 --> 15:42.920 project we have. Just a few two things. I've done a release of mirrored bits, right? I took 15:42.920 --> 15:47.960 over the main tone sheet of mirrored bits which is to do mirrored. It was no releasing six years. 15:47.960 --> 15:52.360 It's done now using tons of distribution to distribute the mirrored so that you don't have to 15:52.360 --> 15:57.400 select the mirrored but you just take one mirrored and it automatically magically gives you the best mirrored 15:58.040 --> 16:07.720 the best file and one of the main features is the support HTTP. No S. And there is a small last 16:07.720 --> 16:13.720 small project or a few other small projects. One is called the summer we did the reverse engineering 16:13.720 --> 16:20.680 of the NDI protocol and we did the library. It was called Lib and DI. I'm not allowed to use that 16:20.680 --> 16:26.600 name anymore because NDI is a patented and trademark project from Visiert and nothing has been endorsed 16:26.920 --> 16:31.640 by them but basically we will reverse and broke the encryption so soon you're going to have 16:31.640 --> 16:39.240 an open source way of using and generating NDI streams. And I guess that's most of the stuff I wanted 16:39.240 --> 16:46.680 to talk about and last thing is a ton of people of you have asked me to get access to Kiber. 16:47.320 --> 16:54.120 It's open right now. Even the website for those who don't know it's an open source framework 16:54.120 --> 16:58.920 to be able to remote control any type of machines. It's basically streaming of all the sensor, 16:58.920 --> 17:05.000 audio, video, subtitle, IoT sensor and everything over one single socket. Completely encrypted 17:05.000 --> 17:11.000 in quick. The goal is the lowest latency possible so that you can control the machines. It has the same 17:11.000 --> 17:16.680 in the same way as all the controls in inputs, game paths, keyboard, mouse and everything. Everything 17:16.680 --> 17:22.280 is fully accelerated and is based on VLC on the client side and FSMPEG on the server size which means 17:22.520 --> 17:29.080 that we have on all the platforms. The server is Windows, Linux, even Wayland, Mac OS and the client 17:29.080 --> 17:34.280 Windows Linux Mac on the way to the TV, Android TV, the web version and everything. So you can have 17:34.280 --> 17:40.680 finally something to replace Citrix or VNC in all the cases. It's fully open source. It's actually 17:40.680 --> 17:45.800 dual-licensed commercial open source. The version that we out is not the final version, right? It's 17:45.800 --> 17:49.560 ton of features that are behind some branches that we're going to merge in next few weeks. The 17:49.640 --> 17:54.360 tip you want to try, you can join or ask questions. Thank you very much. My time is up. 18:11.080 --> 18:18.440 Yeah, I can ask a question, answer a question, Voila and plug. Any question? 18:19.400 --> 18:19.720 Yes? 18:26.600 --> 18:33.240 It's faster. The question was about compared to sunshine and moonlight. It's way easier to use. 18:33.240 --> 18:37.400 It's faster, but mostly it's based on quick, right? It's not using the GeForce 18:37.400 --> 18:41.560 nightmare protocol opening 20 ports, right? It's only one port that is quick with 18:41.560 --> 18:47.400 substream in quick with where we use the same time's quick streams for the inputs and that 18:47.480 --> 18:51.640 ograms for the audio and the video. Yes, of course. 19:01.800 --> 19:06.680 Yet another image format. The question was about GPEG Excel, right? It's a ton of joke, but like, 19:07.960 --> 19:15.400 how many image format did we get in the last four years? Ultra HDR, AVIF, HIF, another version of HIF, 19:15.480 --> 19:21.000 an animated version of it. Some depict 2000. And they're right. And they're just another one 19:21.000 --> 19:26.600 instead of working together. There was flake and so on. So at some point, why another one? 19:26.600 --> 19:31.320 But they have the name and they are, and they work as well as the other ones. So they will win.