WEBVTT 00:00.000 --> 00:09.000 It's my second presentation about this project. 00:09.000 --> 00:10.000 I was there last year. 00:10.000 --> 00:13.000 I thought, no, if some of you have seen 00:13.000 --> 00:16.000 the previous presentations. 00:16.000 --> 00:21.000 Last year, we talked about the co-conset of our project. 00:21.000 --> 00:26.000 This presentation will be still about the same project, 00:26.000 --> 00:29.000 but we have made a lot of advance on it. 00:29.000 --> 00:32.000 The topic is announcing web media supports 00:32.000 --> 00:34.000 who web SME, 00:34.000 --> 00:37.000 driven open source frameworks. 00:37.000 --> 00:40.000 We will focus on this presentation about the SDK 00:40.000 --> 00:41.000 that we have produced, 00:41.000 --> 00:46.000 and we want to foster the reuse of filter 00:46.000 --> 00:50.000 to enhance the contribution to this project. 00:51.000 --> 00:55.000 So, let's start by presenting 00:55.000 --> 00:58.000 who am, so I'm John Graham, 00:58.000 --> 01:01.000 a university lecturer and researcher at 01:01.000 --> 01:03.000 Yuli Nguyenia Sal Amir. 01:03.000 --> 01:08.000 This work is the fruit of research I predicted 01:08.000 --> 01:10.000 many years ago during my PhD, 01:10.000 --> 01:13.000 which was about building a universal 01:13.000 --> 01:16.000 virtual machine for Reco-figurable video-connect. 01:16.000 --> 01:19.000 So, I mean, the co-concept is still there, 01:19.000 --> 01:23.000 but we have integrated, like many, many technologies, 01:23.000 --> 01:26.000 to ease the development, 01:26.000 --> 01:30.000 to foster the deployment of staff. 01:30.000 --> 01:34.000 Meanwhile, I've been working for JPEC, 01:34.000 --> 01:39.000 so I was involved in the project of re-architecting 01:39.000 --> 01:43.000 JPEC, you all know about JPEC, 01:43.000 --> 01:48.000 and I have also on a complete niche over the topics. 01:48.000 --> 01:51.000 I have made a plantation yesterday 01:51.000 --> 01:53.000 about completely different topics, 01:53.000 --> 01:55.000 so it was about cookies, 01:55.000 --> 01:57.000 whether you like it or you like it. 01:57.000 --> 02:00.000 You don't like it, watch this plantation, 02:00.000 --> 02:03.000 because I'm a member of the support pool of experts, 02:03.000 --> 02:05.000 so I have made a project 02:05.000 --> 02:09.000 that I've never software to spot cookies. 02:09.000 --> 02:13.000 This work is also supported by Maya Bistrom, 02:13.000 --> 02:16.000 which is the CEO of Barat Technology, 02:16.000 --> 02:19.000 and she also is the co-creator of the platform one 02:19.000 --> 02:21.000 codec, which is a video sharing platform, 02:21.000 --> 02:24.000 so she couldn't be there today, 02:24.000 --> 02:26.000 she's living in Massachusetts, 02:26.000 --> 02:28.000 so it's not like next door, 02:28.000 --> 02:32.000 and I mean, this is not like a sustainable travel 02:32.000 --> 02:34.000 to get to Brussels. 02:34.000 --> 02:38.000 Anyway, so the state of play 02:38.000 --> 02:42.000 I mean, what we discuss in our last plantation 02:42.000 --> 02:45.000 is that browser or gatekeepers 02:45.000 --> 02:48.000 when dealing with formats. 02:48.000 --> 02:51.000 I mean, they can promote or discourage 02:51.000 --> 02:54.000 the supports of format, 02:54.000 --> 02:58.000 so this gives them so a lot of power, 02:58.000 --> 03:04.000 great power to decide the left life or death of format. 03:05.000 --> 03:08.000 So this happens for instance to og and fura 03:08.000 --> 03:10.000 from the exeve foundation, 03:10.000 --> 03:13.000 and also the GPGXL, 03:13.000 --> 03:17.000 for which the support has been dropped recently, 03:17.000 --> 03:23.000 and this induce like a lot of popularity 03:23.000 --> 03:27.000 despite their respective advantage. 03:27.000 --> 03:29.000 So what we propose? 03:29.000 --> 03:34.000 So by only using WFCCWFCC standards 03:34.000 --> 03:36.000 and open source technologies, 03:36.000 --> 03:41.000 we want to fix this problem of gatekeeping. 03:41.000 --> 03:45.000 So this should help everyone to innovate 03:45.000 --> 03:48.000 and use their own standards. 03:48.000 --> 03:52.000 This also will create the ability 03:52.000 --> 03:55.000 to support the gasi-fundars format, 03:55.000 --> 03:58.000 and this also will help people 03:58.000 --> 04:00.000 to deliver new format, 04:00.000 --> 04:03.000 to experiment with new formats. 04:03.000 --> 04:05.000 Okay, so now how it works. 04:05.000 --> 04:09.000 So instead of creating complex script, 04:09.000 --> 04:11.000 creating new tag, having to integrate 04:11.000 --> 04:13.000 like a new framework, 04:13.000 --> 04:18.000 we currently extends the common tag 04:18.000 --> 04:21.000 by using web components. 04:21.000 --> 04:24.000 So we put new attribute to the extract 04:24.000 --> 04:27.000 that will extend that will add some logic 04:27.000 --> 04:29.000 to this commonly used tag. 04:29.000 --> 04:31.000 So this has several advantage 04:31.000 --> 04:34.000 because you don't have, you have fuel impact 04:34.000 --> 04:37.000 on your web page, if you have CSS or JavaScript, 04:37.000 --> 04:39.000 which is attached to this tag, 04:39.000 --> 04:42.000 then you don't have to modify it. 04:42.000 --> 04:45.000 And that sits. 04:45.000 --> 04:49.000 I mean, and it's this work with video, audio, images, 04:49.000 --> 04:52.000 and stuff like this. 04:52.000 --> 04:54.000 And then for the web assembly, 04:54.000 --> 04:57.000 and the media feature parts, 04:57.000 --> 05:02.000 what we do is that we create new attributes to this tag, 05:02.000 --> 05:05.000 which is the using tag and the web tag. 05:05.000 --> 05:08.000 And this will add, 05:08.000 --> 05:13.000 the this will add some clue to this internal logic. 05:13.000 --> 05:17.000 So this attribute will point to external dependencies, 05:17.000 --> 05:22.000 and the idea is to enhance the support 05:22.000 --> 05:24.000 of the browser itself. 05:24.000 --> 05:26.000 So for this example, 05:26.000 --> 05:28.000 we take the medical demo. 05:28.000 --> 05:33.000 The template, which has been uncoded using the MP1 format. 05:33.000 --> 05:37.000 And this MP1 format, as clearly a port is supported. 05:37.000 --> 05:41.000 Now by browser and the tag itself, 05:41.000 --> 05:44.000 I mean, the internal logic is going to test, 05:44.000 --> 05:49.000 which format is currently supported by the browser itself. 05:49.000 --> 05:52.000 So this is where the pack is used. 05:52.000 --> 05:56.000 So the server, where the rule of the server, 05:56.000 --> 06:00.000 will be to resolve the pipeline and to execute efficient 06:00.000 --> 06:02.000 the pipeline. 06:02.000 --> 06:08.000 And by using some library, which are pointed with the web attributes. 06:08.000 --> 06:11.000 So on this example, we have the lib, MP1, 06:11.000 --> 06:15.000 which contains a set of filter related to MP1. 06:15.000 --> 06:18.000 So on this one, we have a MP1, 06:18.000 --> 06:20.000 PS, and TX, the mixer. 06:20.000 --> 06:22.000 We have a reframor. 06:22.000 --> 06:24.000 And then we have a decoder, 06:24.000 --> 06:29.000 an MP1 decoder, which is taken from a subset of MP1. 06:29.000 --> 06:32.000 And same for lib x2, 6,4. 06:32.000 --> 06:34.000 We have an encoder, 06:34.000 --> 06:36.000 taken also from a subset of MP1. 06:36.000 --> 06:39.000 We have a reframor, and we have a mixer, 06:39.000 --> 06:44.000 that will send the result to the browser itself. 06:44.000 --> 06:46.000 So yeah, to summarize, 06:46.000 --> 06:49.000 we have the universal video that will extend the tag, 06:49.000 --> 06:53.000 the solver, which is like an optimised version of jpg, 06:53.000 --> 06:58.000 and then you point to a set of library that do the decoding. 06:58.000 --> 07:03.000 So each filter has specified input, specified output. 07:03.000 --> 07:08.000 It has code inside it, and the idea is to use the solver 07:08.000 --> 07:14.000 to find the right combination of itter to resolve the problem. 07:14.000 --> 07:18.000 So if you just take a step back on this example, 07:18.000 --> 07:23.000 then you might think that transcoding each video inside the browser 07:23.000 --> 07:30.000 to have the normal format, which is supported by the browser, 07:30.000 --> 07:33.000 could be like an overkill process, 07:33.000 --> 07:35.000 because you have to do it for all image, 07:35.000 --> 07:38.000 or video that you are putting inside the browser. 07:38.000 --> 07:43.000 Actually, this is the more challenging use case, 07:43.000 --> 07:45.000 because it's video, because inside video, 07:45.000 --> 07:47.000 you can have like many codex in it, 07:47.000 --> 07:49.000 you can have a AC audio, 07:49.000 --> 07:53.000 you can have h2, 6, or hdc video. 07:53.000 --> 07:57.000 So the idea is ready to have something very modular, 07:57.000 --> 07:59.000 that then once it works, 07:59.000 --> 08:04.000 you can optimize into a single filter to reduce the concise, 08:04.000 --> 08:10.000 and to only take the part that you want. 08:10.000 --> 08:12.000 And if you think about it, 08:12.000 --> 08:16.000 there is many optimization that could be added to that. 08:16.000 --> 08:19.000 And this is what is done with the video tag. 08:19.000 --> 08:24.000 First, we can detect is, for instance, web codec is supported inside the browser, 08:24.000 --> 08:29.000 and if it's supported, then you can just cut, retrieve the frame over there, 08:29.000 --> 08:35.000 and then use the GPU on coding to make it faster. 08:35.000 --> 08:39.000 You can also directly use a canvas, for instance. 08:39.000 --> 08:43.000 So the real idea is that you have something very modular, 08:43.000 --> 08:47.000 and you can add a lot of logic in it to make it work. 08:47.000 --> 08:52.000 And the last thing is that, remember that the HTML 08:52.000 --> 08:55.000 title, this kind of issue of supporting issue, 08:55.000 --> 08:58.000 by only providing some track inside video. 08:58.000 --> 09:02.000 So it means that if one track is not supported, 09:02.000 --> 09:05.000 then it will get another track and stuff like this. 09:05.000 --> 09:09.000 So it means that the only alternative provided by the browser yet 09:09.000 --> 09:13.000 is only to provide several sets of the same video. 09:13.000 --> 09:18.000 With that, everything, I mean, the all the logic is inside the tag, 09:18.000 --> 09:21.000 and you can do a lot of things with that. 09:21.000 --> 09:23.000 And this is the modernizing case, 09:23.000 --> 09:26.000 but when it's used with image, with audio, 09:26.000 --> 09:30.000 this process is almost instance, 09:30.000 --> 09:34.000 because WebAssembly is like gasing fast. 09:34.000 --> 09:37.000 So if you need to be convinced, 09:37.000 --> 09:43.000 about this, I have made a demo website, 09:43.000 --> 09:45.000 where you will find some images, 09:45.000 --> 09:49.000 so you can test it with the URL or with the QR code. 09:49.000 --> 09:53.000 And on this page, you will have a G2K image, 09:53.000 --> 09:56.000 a GXL image, you have an AC-3 audio, 09:56.000 --> 09:58.000 and you have MPEG1 video, 09:58.000 --> 10:01.000 and you will see that on most of the browser, 10:01.000 --> 10:03.000 maybe only on Safari, Safari is, 10:03.000 --> 10:06.000 I think it's about MPEG1 and also a GXL. 10:06.000 --> 10:08.000 But in any of our browser, 10:08.000 --> 10:10.000 such as Firefox, such as Chrome, 10:10.000 --> 10:12.000 nothing will be displayed. 10:12.000 --> 10:15.000 So this one is like using the command tag. 10:15.000 --> 10:20.000 On the right, you will have the real web page of ther.com, 10:20.000 --> 10:22.000 using the universal tag. 10:22.000 --> 10:24.000 And if you test it on your phone, 10:24.000 --> 10:28.000 then you will see that everything will be shown quite instantly. 10:28.000 --> 10:30.000 I can show you how to do it. 10:30.000 --> 10:32.000 I have a time. 10:32.000 --> 10:35.000 So that's it. 10:35.000 --> 10:37.000 Is it used? 10:37.000 --> 10:39.000 The answer is yes. 10:39.000 --> 10:42.000 I mean, if you have the filters to do it, 10:42.000 --> 10:46.000 then you only need to modify the HTML itself. 10:46.000 --> 10:49.000 You don't need to include complex scripts. 10:49.000 --> 10:54.000 You don't need to dive into any framework. 10:54.000 --> 10:57.000 You just need to know your old knowledge, 10:57.000 --> 10:59.000 about your good old knowledge, 10:59.000 --> 11:01.000 about the HTML and place. 11:01.000 --> 11:03.000 You know the filter. 11:03.000 --> 11:08.000 To help you about this tag, 11:08.000 --> 11:11.000 how to build your tag. 11:11.000 --> 11:15.000 We have developed a VS code extension 11:15.000 --> 11:18.000 that will help you to just provide to you the right tag. 11:18.000 --> 11:20.000 To do this integration. 11:20.000 --> 11:22.000 So it's called beta access. 11:22.000 --> 11:25.000 And it's available on the Visual Studio code. 11:25.000 --> 11:28.000 And this is all the structure of this extension. 11:28.000 --> 11:29.000 So you click on a file, 11:29.000 --> 11:32.000 and then you will get the tag that make it work. 11:32.000 --> 11:35.000 So you have a preview and you have the tag. 11:35.000 --> 11:38.000 And then you have a library of existing filter 11:38.000 --> 11:39.000 through the framework. 11:39.000 --> 11:43.000 So I have made a video about just how it works. 11:43.000 --> 11:45.000 So it is. 11:45.000 --> 11:53.000 So I'm just click on a gxl file. 11:53.000 --> 11:57.000 So since Visual Studio code is based on Chromium, 11:57.000 --> 11:59.000 then gxl is not supported. 11:59.000 --> 12:02.000 So then I'm going to install the extension, 12:02.000 --> 12:04.000 the directsess extension. 12:04.000 --> 12:06.000 There it is. 12:06.000 --> 12:07.000 Devon. 12:07.000 --> 12:12.000 You click on it. 12:12.000 --> 12:18.000 And then you click on the same file, 12:18.000 --> 12:19.000 which is in support here. 12:19.000 --> 12:20.000 So you could be audio, 12:20.000 --> 12:21.000 which you will see. 12:21.000 --> 12:24.000 And then you will get the preview. 12:24.000 --> 12:26.000 And it tag itself. 12:26.000 --> 12:27.000 And seven. 12:27.000 --> 12:30.000 Function 80 that will help you to the integration. 12:30.000 --> 12:33.000 If you want to export everything in the installation 12:33.000 --> 12:34.000 and HTML template, 12:34.000 --> 12:37.000 it will distribute the result on your browser. 12:37.000 --> 12:39.000 If you want to test in any of your browser, 12:39.000 --> 12:41.000 if you want to optimize this code, 12:41.000 --> 12:44.000 et cetera. 12:44.000 --> 12:47.000 So yes. 12:47.000 --> 12:50.000 So is it to use the adjunctsware as yes? 12:50.000 --> 12:52.000 When you have existing filter, 12:52.000 --> 12:55.000 then you just have to put some attribute 12:55.000 --> 12:57.000 to the wave, some information, 12:57.000 --> 12:59.000 to the wave attribute. 12:59.000 --> 13:02.000 Now, for if you don't have the filters 13:02.000 --> 13:04.000 to to to handle, 13:04.000 --> 13:07.000 I mean file inside the framework, 13:07.000 --> 13:10.000 It is it's another problem. 13:10.000 --> 13:12.000 I mean, is it easy to develop? 13:12.000 --> 13:15.000 The answer is really like, no. 13:15.000 --> 13:17.000 Not very. 13:17.000 --> 13:20.000 Well, because you have to have like many privacy 13:20.000 --> 13:23.000 quit, precrecaise, 13:23.000 --> 13:25.000 to do your development. 13:25.000 --> 13:28.000 First, you need to install to understand 13:28.000 --> 13:30.000 how xPack is working. 13:30.000 --> 13:33.000 Like, what is the, the, the, the, the, the, 13:33.000 --> 13:36.000 the function that you have to include. 13:36.000 --> 13:37.680 I mean, it's not so complicated. 13:37.680 --> 13:42.080 Usually, you have two functions to get used 13:42.080 --> 13:44.640 is how you recognize a mid-stream. 13:44.640 --> 13:48.720 For instance, what is the magic code of this format 13:48.720 --> 13:51.520 and how you process the stream itself. 13:51.520 --> 13:54.000 And then you have a several other functions 13:54.000 --> 13:56.840 that helps to tweak the filter. 13:56.840 --> 14:00.840 But it's not like the others program. 14:00.840 --> 14:03.800 The others program is really to do the conversion 14:03.800 --> 14:06.840 in a web assembly using a web script. 14:06.840 --> 14:10.440 I mean, I don't know if you have ever used 14:10.440 --> 14:12.680 the web assembly completion. 14:12.680 --> 14:14.920 You have a glue in JavaScript. 14:14.920 --> 14:18.680 And this glue, every change of version, 14:18.680 --> 14:21.240 this glue will be changed also. 14:21.240 --> 14:24.840 And I have put many optimization 14:24.840 --> 14:26.040 inside the web assembly. 14:26.040 --> 14:29.120 So we have to redesign at each new version. 14:29.120 --> 14:31.280 I mean, this glue are the difficult code 14:31.280 --> 14:33.840 that we have done. 14:33.840 --> 14:36.960 And then the last one, the last problem 14:36.960 --> 14:41.960 is also, is there any intellectual property 14:41.960 --> 14:43.280 around this format? 14:43.280 --> 14:48.160 Are you able, are you allowed to distribute it? 14:48.160 --> 14:50.960 And so this is quite a complex question. 14:50.960 --> 14:53.480 And I mean, you take your responsibility 14:53.480 --> 14:58.440 when you create your own filter, you know? 14:58.440 --> 15:02.920 But I mean, there is a lot of license-free filters 15:02.920 --> 15:05.960 that are existing that you can use. 15:05.960 --> 15:10.920 And they talk more, I mean, more efficient than PNG, 15:10.920 --> 15:15.080 than GPEG than I don't know, P3 for you. 15:15.080 --> 15:16.960 And that you can free use. 15:16.960 --> 15:19.120 I mean, there is no restriction about this. 15:19.120 --> 15:22.640 I mean, this is really your responsibility. 15:22.640 --> 15:26.800 But for the web assembly part, for the JPEG 15:26.800 --> 15:31.960 part, we have designed a new interface 15:31.960 --> 15:36.360 to help you to build this new filter. 15:36.360 --> 15:41.480 So this is the interface that we developed. 15:41.480 --> 15:46.120 So the idea behind this is that the tool chain is open source. 15:46.120 --> 15:47.200 Of course, it's open source. 15:47.200 --> 15:49.200 The all this work is open source. 15:49.200 --> 15:50.560 The tool chain is open source. 15:50.560 --> 15:53.720 And you can freely integrate it inside container, 15:53.720 --> 15:56.720 inside, I mean, VM. 15:56.720 --> 16:01.120 And what we choose to do is to integrate this tool chain 16:01.120 --> 16:02.520 inside GitHub. 16:02.520 --> 16:07.840 So this interface will be linked to your GitHub accounts. 16:07.840 --> 16:11.400 And then we will use the GitHub action 16:11.400 --> 16:16.360 to compile the color and get it into the right format 16:16.360 --> 16:19.400 to get it used inside a framework. 16:19.400 --> 16:21.240 So here it is how it looks. 16:21.240 --> 16:25.520 You have several action, and we'll see what the action 16:25.520 --> 16:26.400 is for. 16:26.400 --> 16:30.560 And this is just to follow how I mean, the progression 16:30.560 --> 16:32.440 of your completion, if you have any problem, 16:32.440 --> 16:35.200 that it will be reported over there. 16:35.200 --> 16:39.000 So there will be two main actions to compile the color, 16:39.000 --> 16:43.840 which will be to commit and push to your GitHub repository. 16:43.840 --> 16:46.200 You will have everything compiled with the GitHub 16:46.200 --> 16:46.680 action. 16:46.680 --> 16:50.880 And then you will retrieve the result and put it inside your query. 16:50.880 --> 16:52.680 OK? 16:52.680 --> 16:56.920 So I've made also an example for that. 16:56.920 --> 16:59.480 So what I'm going to do is like consulting 16:59.480 --> 17:03.760 a very simple feature, which is the VMP feature itself. 17:03.760 --> 17:09.440 So I have some C code language to the code VMP. 17:09.440 --> 17:12.800 And you can access to this public repository. 17:12.800 --> 17:14.400 And I can show you. 17:14.400 --> 17:18.760 And the idea is really to build your own filters using 17:18.760 --> 17:20.400 VMP, I mean the SDK. 17:20.400 --> 17:24.440 So we have a compressed VMP inside the media pipeline. 17:24.440 --> 17:27.320 And what we're going to do is to decode it and flip it 17:27.320 --> 17:32.280 to show that this is really this one, which is used. 17:32.280 --> 17:35.640 So I will have again a video for that. 17:35.640 --> 17:43.560 So this is how you get into the SDK of your man. 17:43.560 --> 17:47.800 So first, I have used my users to code. 17:47.800 --> 17:51.280 I have BVR, the BVR extension, which is install in it. 17:51.280 --> 17:52.920 I have a click on VMP. 17:52.920 --> 17:57.440 And what this message means is like, even if 17:57.440 --> 18:03.120 Chromium can decode this image, I'm not using my framework 18:03.120 --> 18:06.240 because there is no VMP filter as a candidate 18:06.240 --> 18:08.920 to use this format. 18:08.920 --> 18:13.200 So let's create our own VMP decode. 18:13.200 --> 18:15.880 So first, I'm going to click on add. 18:15.880 --> 18:18.840 You have two options of that. 18:18.840 --> 18:20.600 So the first one is that if you know, 18:20.600 --> 18:23.920 and you exist in repository that provide the VMP decode, 18:23.920 --> 18:26.880 you can just add this repository and it 18:26.880 --> 18:31.000 will be automatically added inside the list. 18:31.000 --> 18:35.080 But for my case, I will start from scratch 18:35.080 --> 18:37.000 for doing this decode. 18:37.000 --> 18:40.120 So I'm going to create a new project, which 18:40.120 --> 18:41.320 is called the VMP demo. 18:41.320 --> 18:47.160 And then I will enter inside my new interface, 18:47.160 --> 18:50.240 which is like this decant interface. 18:50.240 --> 18:54.160 So it is, so you have a G over there, a B. 18:54.160 --> 18:56.440 And if you click on it, then you will have the full access 18:56.440 --> 18:58.000 to do the completion. 18:58.000 --> 18:59.960 So when you create a new project, it 18:59.960 --> 19:03.040 will be a fork of a base filter of a locust 19:03.040 --> 19:05.480 written of a filter. 19:05.480 --> 19:08.680 And then you can just copy past your code inside it 19:08.680 --> 19:12.480 to make it work inside the full media pipeline. 19:12.480 --> 19:14.960 So you have some C code. 19:14.960 --> 19:17.480 You have some JSON description to be 19:17.480 --> 19:21.520 filled to make to give some clue for the selection 19:21.520 --> 19:22.360 and this file. 19:22.360 --> 19:25.640 So this is like the syntax of the pack. 19:25.640 --> 19:27.480 So some of you may know. 19:30.480 --> 19:38.360 And what I've done is clearly to copy past my code. 19:38.360 --> 19:43.480 I have put like the magic code to spot like BMP file. 19:43.480 --> 19:45.720 It could be using BMP code on the strings, 19:45.720 --> 19:51.080 or having like a reading the extension to see if it 19:51.080 --> 19:52.160 matched with the filter. 19:52.160 --> 19:56.160 And then I have only my processing function, which 19:56.160 --> 19:57.440 will be to decode BMP. 20:01.320 --> 20:01.800 OK? 20:04.360 --> 20:04.960 There is. 20:04.960 --> 20:11.560 So this is not a lot of code, actually. 20:11.560 --> 20:14.560 So I've put some metadata on it. 20:14.560 --> 20:16.840 And then what I want to show you is this, 20:16.840 --> 20:21.360 just to make it sure that it's clear for everyone. 20:21.360 --> 20:26.240 When you create a new filter, you will fork the base filter 20:26.240 --> 20:30.520 and you will fork this filter inside your own icons. 20:30.520 --> 20:34.880 Which means that you can trigger a GitHub action 20:34.880 --> 20:36.000 to do the completion. 20:40.480 --> 20:43.240 So it is, so you don't need to go on GitHub. 20:43.240 --> 20:44.960 I mean, everything will be done on the background. 20:44.960 --> 20:47.640 It's just to show you how it works. 20:47.640 --> 20:48.640 So I'm going there. 20:48.640 --> 20:52.320 What I'm going to do now is to commit and push 20:52.320 --> 20:54.800 my modification inside my repository. 20:58.240 --> 20:58.680 Let's go. 20:58.680 --> 21:06.800 And then push in, and then this will trigger the GitHub action. 21:10.440 --> 21:16.960 So this is to convert from C to my framework 21:16.960 --> 21:20.440 of the BBR framework. 21:20.440 --> 21:23.640 You will see all the building step inside the extension 21:23.640 --> 21:24.680 itself. 21:24.680 --> 21:28.640 And once it's done, then you can add the result. 21:28.800 --> 21:36.240 To the list, you can add to this list. 21:36.240 --> 21:38.480 And now you see that the BMP is flipped. 21:38.480 --> 21:40.640 So it means that we are using the BMP remote 21:40.640 --> 21:42.560 that we just built. 21:42.560 --> 21:43.760 OK? 21:43.760 --> 21:47.400 So this is the general ID. 21:47.400 --> 21:50.720 And the general ID is really to based on fork 21:50.720 --> 21:53.960 because every fork that will be created 21:53.960 --> 21:54.880 has to be public. 21:54.880 --> 21:57.080 You know, it's a limitation from GitHub. 21:57.080 --> 22:01.200 So what we really want is to have many features, 22:01.200 --> 22:02.040 which are built. 22:02.040 --> 22:06.800 And the more filter, that will be produced, 22:06.800 --> 22:09.560 the more this framework will be used. 22:09.560 --> 22:16.760 And the more you will be able to do with it. 22:16.760 --> 22:20.560 So it is. 22:20.560 --> 22:24.640 So I mean, I've really worked on the documentation 22:24.640 --> 22:29.800 of this project, just to show you how to do it by yourself. 22:29.800 --> 22:32.960 So on this part, the developer part, 22:32.960 --> 22:35.560 you will have all the steps that I've shown 22:35.560 --> 22:37.440 to create your own decorator. 22:37.440 --> 22:39.400 The BMP decoder is something simple, 22:39.400 --> 22:44.400 but usually what you will have to do is you know a library 22:44.400 --> 22:47.440 and that doing that is doing something, you know? 22:47.440 --> 22:49.840 And you just have to integrate this library. 22:49.840 --> 22:52.840 I mean, do the update session between the process 22:52.840 --> 22:55.440 function and the library itself. 22:55.440 --> 23:01.640 And this is most, if you have like existing secode. 23:01.640 --> 23:04.800 I mean, under the project is not only limited to seeds, 23:04.800 --> 23:06.760 can be used in rust, can be used. 23:06.760 --> 23:09.760 And I think that could be combined was as long, 23:09.760 --> 23:15.000 as you respect, you know, the API of the project. 23:15.000 --> 23:17.080 So this is where you can find us. 23:17.080 --> 23:18.600 Everything is explained on this. 23:18.600 --> 23:21.720 So this is an open source project. 23:21.720 --> 23:25.200 So all the filters that we have currently released. 23:25.200 --> 23:28.560 So there's many filters, which are existing, 23:28.560 --> 23:31.080 but we have limited the release to the one 23:31.080 --> 23:32.760 which are free to use. 23:32.760 --> 23:37.280 Where there is no limitation to distribute your project. 23:37.280 --> 23:39.480 The glue by itself is based on JPEG, 23:39.480 --> 23:42.160 but it could be based on everything else. 23:42.160 --> 23:45.200 It's just that JPEG has many advantage to do this 23:45.200 --> 23:47.520 integration because it's all written in C. 23:47.520 --> 23:49.200 There is very few dependency. 23:49.200 --> 23:52.280 The filter itself is very, very small, 23:52.280 --> 23:55.600 very, very few, I mean, things well contained. 23:55.600 --> 23:57.320 And that's it. 23:57.320 --> 24:03.320 And the tool chain to build your filter is available 24:03.320 --> 24:05.120 on the player repository. 24:05.120 --> 24:07.440 So you can use it locally. 24:07.440 --> 24:10.680 And I mean, this is the same thing, 24:10.680 --> 24:14.240 which is attached to the GitHub action. 24:14.240 --> 24:18.360 So how it is, if you produce new filters, of course, 24:18.360 --> 24:19.600 it will be your filters. 24:19.600 --> 24:22.800 We don't, I mean, we first do the terms of services, 24:22.800 --> 24:25.120 but it's like prior growth, everything is open source. 24:25.120 --> 24:26.760 So you can do everything that you want. 24:26.760 --> 24:28.840 If, I mean, for the filter parts, 24:28.840 --> 24:32.640 if you want us to reference it, I mean, of course, 24:32.640 --> 24:36.640 we will just review just for security reasons. 24:36.640 --> 24:40.400 But I mean, everything is very open. 24:40.400 --> 24:45.400 So I think I've been quite fast on it. 24:45.400 --> 24:51.520 But I mean, it's like all for today. 24:51.520 --> 24:55.560 We really open, we are really open to all contribution. 24:55.560 --> 24:58.320 I mean, if you are working in a research, 24:58.320 --> 25:01.800 if you are like an artist, like for the effect glitch, 25:01.800 --> 25:04.400 if you want to create your own filter, 25:04.400 --> 25:07.800 to have dynamic glitch inside your web page, 25:07.800 --> 25:09.840 you know, it's something that is doable. 25:09.840 --> 25:11.080 In there is a lot of opportunity, 25:11.080 --> 25:15.280 it's based on this framework. 25:15.320 --> 25:18.040 So I think that's all for me. 25:18.040 --> 25:20.800 I'm like, open to question. 25:20.800 --> 25:24.400 If you have ideas, want to contribute, 25:24.400 --> 25:29.400 have many, any question, like, give you the mic, yeah? 25:36.400 --> 25:37.400 Are you convinced? 25:37.400 --> 25:38.400 Yeah. 25:45.400 --> 25:46.400 OK? 25:46.400 --> 25:47.400 Yeah. 25:51.400 --> 25:52.400 Yeah. 25:52.400 --> 25:54.400 We're doing a web page. 25:54.400 --> 25:57.400 All the way in better history. 25:57.400 --> 26:00.400 How did you work in a web page? 26:00.400 --> 26:01.400 Yeah, yeah. 26:01.400 --> 26:05.400 That's a good question. 26:05.400 --> 26:08.400 So if I have created a new page, 26:08.400 --> 26:13.400 how to include this filter in the, yeah, 26:13.400 --> 26:17.400 how to include these filters inside the new page. 26:17.400 --> 26:18.400 So that's it. 26:18.400 --> 26:21.400 You have like the universal tags.js. 26:21.400 --> 26:23.400 And this is the only integration that we will do 26:23.400 --> 26:24.400 on the page. 26:24.400 --> 26:28.400 And then you can extend any of your image tag, 26:28.400 --> 26:34.400 audio tag, video tag with this new attributes, you know? 26:34.400 --> 26:39.400 So you have to have this script inside the page. 26:39.400 --> 26:43.400 And then you have to have your filters available somewhere. 26:43.400 --> 26:46.400 I mean, it will just get the filters where it is. 26:46.400 --> 26:49.400 And you will, like, retrieve it, compile it, 26:49.400 --> 26:52.400 and then execute it, you know? 26:52.400 --> 26:56.400 So you need to have, like, as a material, the JavaScript, 26:56.400 --> 26:59.400 and then all the, the, the, the, the, the wasn't file, 26:59.400 --> 27:00.400 which is the server. 27:00.400 --> 27:03.400 And I mean, the separate wasn't file, you see? 27:04.400 --> 27:07.400 But you can distribute it from any place like from a CDN, 27:07.400 --> 27:10.400 from, even from GitHub, you know, it work from GitHub.