 Hi, I'm going to do a presentation about Videoland and VLC. I'm from the Videoland project. I'm the president and I've been working on VLC for a long time, a bit too long probably. So this presentation is going to be full of cones and other nice stories. Please stop me if you don't understand what I'm saying or if I'm going too slow or too fast. If you stop me and ask questions, it means that you're still alive and that's great and I prefer that. So this is a story that takes place in 1996, 5-6. Basically here you can see is the campus of the École Centrale Paris which is an engineering school in the south of Paris. Basically it's one of the best engineering schools. In the 1960s the state said, well it's named Centrale and we don't have any place to put it in Paris. So we're going to put it in the middle of France. The alumnae said, oh no way you can do that, we want you to stay. What the alumnae did was they bought this piece of land and then told the French government, hey we bought this land, we're going to build a campus and at the top of the campus you can build the school. Don't worry I'm still speaking about VLC. And because of that the school does not own the campus. And the campus when it was installed at the network that was managed by students was installed in the 1980s. It was amazing with a great technology called tokenaring. I don't know if anyone here still remembers those things. It's a great thing and it was amazing however it's very bad if you want to play video games and especially when you're going to play Doom. So in 1992 and 1993 the students started to ask the school, hey can we have a new network? And the school said, ah we're really sorry this campus is not owned by us so we can't do anything for you. So they went and see a lot of partners and then there was someone from TF1 which is one of the main broadcasting networks in France said, okay if you're able to destroy your tokenaring network by sending video on it, I pay you a new network. And we are in 1994 so there is Pancham but no other mix. Decoding Mbeck 2 in software was almost impossible and we are like 10 years before YouTube. But they say okay let's do that. So they start the project and after two years they managed to have some streaming of the DVB satellite and it was really cool. It was able to play 35 seconds of video and then crash because no memory left. But that's fine because the demo was 30 seconds and it was working. It was even a multi-platform, I mean Linux and BOS. And after that they say well okay that's great. Let's start again and actually do that for other people. So this rebooted the project in 1998 with a few ideas. The first one was open source. The second one was modularity which is one of the base of VLC and this is one of the reason why VLC became popular. And it was still network oriented because it was just a client for a streaming solution online. In 2001 after two, three years of battling with the school they managed to re-license all the projects under GPL because the school said well sorry but you are our students, the IP is for us. But the students won. Proprietary. The idea of the school is that they wanted to sell an Mbeck 2 decoder video and audio because some guy of MIT made that for the Mbeck 1 decoder. Yes, sure. But VLC is just one of the projects of the video land project. VLC was at the beginning just a video land client and of course there was a server. There were some completely crazy projects that are dead like VLCS which was a way to do basically multicast of a network that is not multicast by abusing VLANs and changing directly people from VLAN when you wanted to play a video. But more, lots of libraries for developers including the famous libdvcss to work around the DVD encryption and decryption. But also x2so, probably the most used encoder in the world now. And other stuff. We have a software libraries for decoding Dolby, DTS and also all the Blu-ray stack. So at the beginning this was basically the video land streaming solution. So on your left you got the inputs which could be anything basically whether it would be DVD, Blu-ray, acquisition card, DVD or even satellites. And then the restreaming on the network after transcoding or not. A lot was focused on the multicast network that we had at the École Centrale Paris. And then you have a few clients whether they are VLC or not VLC. So that's more or less the story of the project. The problem is that we have to work with multimedia. So I guess everyone is familiar a lot with multimedia around here? Yes? It's okay, fine. So what is multimedia? Multimedia is stupidity at max. So there are two things that I will tell which is the first one is in multimedia if there is a stupid way to do something someone will do it badly and will complain until this is a standard and is supported. This is the thing we have to deal every day. Great ideas about having some wave audio put in MP4 formats remixed in MKV or WebM and then stream over adaptive streaming with a different codec for audio of course that is going to change every time you change the bitrate. Stuff like that. And also the problem also is that in multimedia everyone thinks he understands everything but actually no one does. The more I do multimedia the more I realize that I don't know anything. The problem is that many people including from big companies including people from YouTube and so on believe they know everything and then try to do something and then they realize that it is complex. So the result of that is that in multimedia technically everything is broken. There are 42 ways to do something. Container is basically the box of format to put the different video and audio tracks. All of them are between complete crap and to somehow broken. The worst of course are AVI but at least it has the excuse of being from the 1980s. FLV which is probably the one the most used on the web those days great. Or AUG. Also too many codecs have bad designs. Most of the codecs are badly encoded because someone found a script online and I did a few stuff and many just put something inside something else. The reason is that for example you have an encoder that is very expensive but everything else in your post processing channel is only understanding these formats and you should buy a new compatible encoder but it's going to cost you money. So it's easier to work around and hack it in order to put it in it. So for example we have amazing stuff like H265 put in FLVs or AVI using the direct show format of Windows 95 and people complain on the mailing list all the time to support that. Yes. The rest is that it's not about only codecs and containers but metadata also is very broken. How do you put an image inside FLV or AUG? Well it's great because AUG has metadata that is only comments, text comments. So you're going to take your image basically base 64 it and put it in a text field inside a binary format. Amazing. There are two ways of having basically the metadata of H264 and some encoders even on the same platform some decoders want it in one format or on the other one. For example on Android depending on the chip that is going to do the hardware decoding you need to put one format or the other. And so on. I don't even speak about DRM because DRM is always bad but the thing is open source is absolutely everywhere. It's used by almost everyone, all the TVs most of the smartphone have some part of open source codecs that were developed by the FFMPEG and the LibEvi project. And it's used in large kind of domains from TV station to hospitals to education. However, there is a big problem. The first one is the USA. The multimedia community is underrepresented in the USA because of patents mostly and everyone is afraid of that. So a lot of multimedia engineers in the USA who work on FFMPEG are basically working on wrappers around codecs in order to never touch the codecs. A lot of the projects are abandoned. We have a lot of forks. And we can't say that most of the open source software media are easy to use and VLC, I'm also to blame on that. Also the professional in the broadcast is still fighting against open source software on their field. But that's not really important. Multimedia is not that difficult technically. Of course because I'm working on that but it's mostly about knowing a lot of those quirks. Knowing a lot of those formats and have those subtitles. It's easier to code on VLC or even on some codec than working on a kernel, for example. Anyway, VLC. So VLC is a media player. It used to be the video line client. Usually when I go and introduce myself and say, well, you know, I work on VLC. No one knows about that. Yeah, yeah, you know the code that play videos? Oh yes, that works every time. It's insanely popular. The reason the code was selected is a very old story of the call Central Paris that I can't really explain on a microphone. But yes, there was a bit too much alcohol in this story. But it's great because it is completely stupid to decide to take a code as a logo for a software but it's amazing idea because it's so recognizable. Everyone knows, I mean, no other media player has a cone. Everyone has just a play, basically a play button somewhere. So that was a great marketing idea by people who had no clue what they were doing. VLC is known because it's everything. Mostly it was, so in the beginning, of course, it was only on the right platforms, Linux and BOS as I was saying. But VLC integrated all the codecs on Windows and so you didn't have to download something else. And even if you were downloading something else, it wouldn't change VLC. Everything is self-contained inside VLC and that made it popular. So we play most of the formats and we're working on that. So VLC tries to play everything and also tries to play it everywhere. Everywhere including OS 2 because the last version of VLC has finally been fixed on OS 2. The three developers are very happy. They don't have any users yet. But also we are now on Android and iOS. We're working on Windows 4 and everywhere. And also, of course, on Linux, which was an original board. So how big is VLC? VLC is around one million downloads per day on our website and that's not counting, of course, any Linux distribution. It's not counting every download.com and all those other places. When we started counting in 2006, since then we've had some two billion downloads, which is kind of nice knowing that we are a very small team. So VLC can play audio CD, DVDs, Blu-rays, lately, mostly non-encrypted, but if you're smart you can have them decrypted also, network stream, external hardware for the DVB satellites, the TV inputs, also the cameras. So basically everything that you could play we tried to make it playable. So I'm going to show you a few historical viewers of VLC. So here you can see the first DVDs that was played with video land client as you can see. It's, of course, a GoldenEye DVD and that's the reason why all of the code names of VLC until 1.0 were from GoldenEye characters. It's a GNOME, I don't know, one something maybe, or something very, very old. And this one is, I think, the GTK UI we had in early GNOME 2. That is, of course, amazing design as usual. But what's interesting is that it's basically a playback of a multimedia TSTream Direct Live. This is the first UI we had on Mac and you still see it said our video land client. This is the version that is based on Wits that was the most known and was the one that most people use when VLC became popular. It was great and stayed a long time until we switched to Qt in 2008-2009. And, well, VLC runs also on the GNOME 3 and it's the best thing because you know, ponies. So it's important to say that we are mostly volunteers and very, very, very large part of us are volunteers back on our free time. So we are really on the bazaar side of the scope even if we have one of the most used software for normal users. Since 2009, we have now a nonprofit organization that is behind who gets a bit of donation in order to send people to LCA. And that's the main goal, of course. We organize video land dev days, which is a big conference about multimedia where most of the people from the multimedia community, most of the people from FMPEG, LibAvy, X264, come by. Everything we do, basically all the collaboration is done, of course, online since very early. We've moved to Git in 2007, so a bit before everyone else except the Linux channel, of course. And everything we do is on IRC, and mainly if you're not on IRC, basically you're not in the project. And we have a few simple rules. The core team of VLC is between five and 10, depending on how you count, or maybe three if you count differently. But we have a lot of these contributors arriving, 150 per year, they come, they give us a patch, and they go away, which makes it a bit weird on how we accept code. The way we accept code is not based on is this feature really useful, but it's mostly, is this feature going to be maintainable? Because of course everyone comes and say, well, I'm going to maintain this patch. Yes, sure. I'm going to stick, yeah, technically no one does. So we have absolutely no marketing team, almost no legal team, but what's important is that the technical code is correct and standard, and people who code more have the more power in the community. Most of the time we arrive through consensus, and sometimes we offer some people to fork, but so far there is no important VLC fork, except BIOS. We use Git in a SVN way, which is we always rebase before committing, so we don't have a lot of merge commits, and we have basically a master that we break and commit to and a stable branch where we cherry pick commits. I think that's pretty standard. So one of the main question is why is VLC, why did it become so popular? And there are weird reasons, but there are also technical reasons, and the main ones are because it was modular, because it was network oriented, and because it was written in the same language. So why is the networking oriented important? Mostly because, well, when you were in the 2003 and 2004, and you were using Emule or Idonki, of course no one of you were doing that, I'm sure, and you started to download something, it would take, I don't know, half a day or a day or more, and if you try to play it with any other player, it will just complain that the file is not complete. But as VLC was developed as a network engine, a playback engine, it would just like ignore and try to go directly. So for example, if you were downloading a Disney movie, like only 50 megabytes or maybe even less, you were able to see if it was actually a Disney movie and not an adult one, or if you were looking for an adult one, then it was not a Disney movie. So that's quite important, and that helped a lot in having VLC used. The other reason, it was mostly on macOS, that it was the only way to play DVDs for a long time. So, VLC does not exist, and I'm sorry to say that, VLC is a 200 lines of code wrapper around LibVLC, which is our API to basically create media players. LibVLC is a very stable API above the core, and everything else is done in modules. This module design is one of the reasons why VLC also was popular, is that when you want to do a cross-platform video engine, for example, you're going to take, I don't know, one idea is to say, well, I'm going to pick OpenGL, because OpenGL works everywhere. Well, if you ever use OpenGL on Windows or even on some Linux card, you know that's not the case. So having different modules is that you can take the best technology on every platform. This is why we're able to maintain an OS2 port without destroying the code base, because basically it's modules that no one cares about, except the OS2 maintainers. This helped VLC to spread on numerous platforms, numerous platforms, and especially on non-open source ones. It's also good because it helps the code maintainability, because then most of the units are 1,000 lines of code, more or less. So the core, LibVLC core, yes. As you've seen, the project is very bad with names. So it was video land client that became VLC, and then everything is LibVLC, LibVLC core. So the core is quite light. It's basically doing the operating system abstraction. It's able to do memory allocations, mostly networking, thread handlings, and loading modules depending on the platform. It's also able to do clock synchronization, which is basically synchronizing audio and video together. Everything else is outside. So the core of VLC doesn't support any codec, doesn't understand what a codec is almost, and is quite simple. Above that, we have a stable API. So LibVLC core is not stable. We break the API and the API quite often. But above that, we have the simple multimedia framework, LibVLC, that is done to actually write applications. And then we have bindings for all the major languages, especially because we have a binding in SWIG where we can generate them for other people. To give you an idea, in an usual VLC installation on Linux, you have 300 modules that goes from codec to IO, video output. And if you want a new feature or format of, I don't know, Commodore 64 mod chip files like people did, you just add a new module and submit it to the play. VLC is around 820,000 lines of code. So the core is 100, 120,000, and everything else is inside the modules. What's also quite interesting is that the core depends on almost nothing except libc and iconv. But the modules depend on a lot of external libraries, including LibVl codec, LibVl format, and so many others. When you compile the whole VLC for Windows or for a number of Linux, usually it's 10 to 12 million lines of code that you build. The VLC on Android version is a bit less because we don't have streaming, so it's 6 million and a half. Most of it is C, like 50%, and then the rest is C++. And assembly. So VLC's code is in this amazing language called C-minus, or call it as you want, some C-object, which is basically abusing C in order to have a kind of object abstraction and having pointer-to-function objects that are pointing to other opaque structures. And that's how we do different modules, but it seems to work quite fine. Most of the modules have their own private data on each session. And this is mostly how it works. A lot of media players are written in C++, for example. And when VLC was starting, the C++ compilers were more limited. And when we see, of course, when we compile C++ modules in VLC, they are very important. So having that helped also on importability because ports were done without C++ at all. So how does technically VLC does video output? It's a network-oriented graph that is built at runtime when you want to play something. This is quite similar to what G-streamer, QuickTime, Directional Media Phone is doing, is based on what is probing and from the stream going to ask for different modules. So the first part is usually the protocol, HTTP but also file or DVB. It's basically a way to get from a URL, get a stream, a row stream. Then you've got the format, which is basically the thing that is going to split the video and audio tracks and subtitle tracks. And then based on that, it's going to have a video decoder or audio decoder, subtitle decoder, that are going then to video filters and then to the output or for audio filters, the same audio filters and the output. For subtitles that are text-based, we usually have something, a text renderer like free type and then we blend it on the video output in order to display it. But also with VLC, because it's full media framework, you can re-encode directly and re-stream, remux and re-stream if you want to use VLC to do streaming. As you can see, interfaces are also modules in VLC, which is something that people usually don't expect. And interfaces are a module of LibVLC Core and it's not the interface that is built on LibVLC. There is a small difference from other media players and other multimedia frameworks is that if you look closely on the left, you're going to see that the first two arrows are basically not in the right direction. Basically, it's the format, the demuxer, that is going to ask for more data from the protocol layer, saying, hey, you know what, I need data and is going to ask it data. So for example, when you go on YouTube, it's basically doing a lot of stuff on the server side that you get most of the data soon and then going to throttle your connection. If you're going to launch a YouTube video and you have lots of connections, what's going to happen is that you're going to download almost everything without playing back and so if you close, you lose a lot of resources. On VLC, it's not done like that. Basically, you have for every protocol a set caching that is done in milliseconds. So for example, for a file, we're going to need 300 milliseconds or for HTTP, two seconds. As soon as we miss data, we're going to ask the protocol layer to get this fixed caching. That's interesting because it helps saving resources and network resources. I'm not sure people actually care about that anymore, but that's something. So how do we do module probing? So every module has what we call a capability. Basically, it's the category of the module. It's going to be an access, so protocol, DMAX, format opener, codecs, or filters, mainly. And it has a capability and a score. So what the core of VLC is going is that it's going to ask for all the modules of the right capability and in decreasing score order and then it's going to run the probe function and check if it's yes or no. If it's yes, then fine. If it's no, it'll go to the next one. And that's pretty simple because you can add new categories if you want to have some special modules. But the problem is that as you can see, it can be quite slow, which is why we have a module cache in VLC so that when you're going to open the codecs, you're not going to open every module but just the right ones. So VLC is almost a full Multimedia framework. So why do I say almost is that in theory you could do everything that all the Multimedia framework in practice, the API so far is mostly done for playback. So basically, you want to play a video inside an application or you want to do a different media player based on VLC. So it's mostly playback, filters, all the control you want with LibVLC. But, well, there is very limited streaming. We've done DVD reapers and CD reapers based on LibVLC. We've done subnailers also for LibVLC, so in Nautilus or in GNOME. And it's also directly used in the port of VLC on iOS, on Android, and Windows Phone, and the others. It's also used by Phonon. We have a Phonon backend that is probably not the best one. And it's also used by XML projects that we don't know about because LibVLC is LGPL, so people can use it as they wish. So just to give you an idea, LibVLC is extremely simple to use for the main use case, which is basically you create a VLC instance, which is LibVLC new. Once again, amazing names, as you can see. And then we create one or more media players because in an application you might want to play more than one video. And then we create a media, which is basically usually get a new media from a location, which is a URL. We set it and we play. We have an example of LibVLC to have an almost full media playback for GTK, based on a text 150 lines of code that play, pause, stop, and even synchronization of audio. So it is done for that. It is very simple to do for that. And it's even simpler if you reflect it with Python and so. Questions? Still alive? Okay, we'll see. So now I'm going to show you a few stuff that you don't know about VLC that are quite funny. For certain definitions of funny, of course. VLC is extendable in Lua, so all the internal APIs are mostly exposed, so you can do and sharing on Twitter, and also to do parsing of websites. So if you put a YouTube URL inside VLC, VLC is going to act like a web browser that just is able to play video, and it's going inside and then with a Lua and some regex is basically going to give you the URL and play it without destroying your machine because you're still using Flash. VLC also has something called service discovery, so basically you can find playlists, or it's really used for UPNP, Samba, but also SAP. And also you could do playlists directly, and it can give you some stuff like that where you have a repository or video of podcasts and you integrate directly with VLC in crypto. VLC can do screencasting, which is completely useless because VLC screencasting is very bad, but it gives you the unique opportunity of doing this joke that is used, but everyone loves, which is an infinite VLC. So every, I don't know, every six months there is some guy on Reddit or Twitter doing that and then retweeted everywhere. It's useless, therefore it's great. We can do Mosaic in VLC, and that's important because now you see that VLC is not just a media player. Because to do a Mosaic, basically you need to have not one input, but here 20 inputs that are decoded in 20 different decoders and then merge at the display time and then you can even, instead of displaying, re-encode that. So people do Mosaics directly in VLC instead of buying some, and that's by default in VLC and you don't need to code anything to get that. We can do, of course, picture-in-pictures or world filters, so that's really cool if you want to not have big screens and not spend too much money and you have just a few HDMI TVs. We play karaoke because why not? We, of course, play media because it's the most important format on Earth. We have, of course, a console and curses interface because, well, we live in common line, right? We need a UI. Actually, I don't, but it's still using X11 or OpenGL to output, so if you're over SSH, well, you're going to use Lipkaka directly, which allows you to be able to watch a movie directly on the server through SSH. Amazing, very useful. I want to end this as key art. We have, of course, a web interface where either you can control and have it playing locally or re-stream and re-encode in video HTML5 or VLC-compatible format. And so many other weird features that we have that are useless but great to use. Especially in the next version of VLC, we have a VHS filter. The idea of the VHS filter is basically you take your good video that full HD and then you add artifacts and random problems on it to remind you of the VHS times. We also have a puzzle interface because, well, basically you're watching a movie and it's boring, but you want to watch it so you can actually click and move the... I can show you after if we have time, I'm not sure. A bit more serious, we've spent a bit too much time lately on VLC and Android. So VLC and Android is completely open source. We work and support from 2.1 to 5.0. It has all the format that VLC does except it doesn't do streaming yet. And the biggest difference is it has an actual media library for audio so you actually can use it for audio while on the desktop, not much. Porting to Android was difficult, mostly because the Lipsy of Android is very bad and because instead of taking one that was already used, they decided to rewrite one and they had no clue what they were doing. So there is no good way to output audio on Android yet. It's very difficult to output YUV in a standard way on Android. But after almost two years, we are finally able to... So we released something in July 2012 as a beta and then it quickly evolved to be less ugly. That was the version that was quite popular and now we almost finished the... Google of two years ago and they changed it again. The good news is that we already are on the next design. Yes, so... Yes, we have a lot of... I think we have three users on Android, which is quite nice. We also have a port on iOS, which is bad but quite interesting because it works faster than Android even without hardware decoding. And lately we've been porting to VLC on Windows RT, which is the Metro UI. We don't really care about the Metro UI, but what we care about is mostly Windows 1. Future projects? Well, one of them is the port on Windows RT, Windows Phone, I was saying. We are not going to work on Firefox OS because porting VLC to JavaScript with no thread is not... VLC for Ubuntu Phone, or maybe it's called Touch Now, we don't know if there is anything actually to do. BlackBerry probably not because they can now run Android application directly, and for Chrome OS we hope to do exactly the same. So, almost my last slide. Should contribute to VLC and to libvlc. The first thing is to use it and promote it and say it's also... I didn't put it... to your friends, report bugs because, you know, there are lots of... send samples. And also code on VLC or use libvlc in your next project. Thank you. I think we have five minutes for questions. You want? No one wants. This is the way. Is there any traction on... So, we have a Chromecast streaming module in VLC. So, the problem is that the... the goal of Chromecast is basically to play something from the cloud, right? So, it's a full... So, it's basically... the Chromecast is going to pull and it's really not done for pushing to it, right? So, for VLC and Android it's very simple. We know where the file is, we could just send it, right? But then it's only the compatible part. So, what we did is a full streaming module that is merged in VLC 3.0 and that is able to push and re-encode all the time to the right format. However, because of that, when you seek or when you pause, basically on the Chromecast you're posing on the Chromecast, right? And so, the streaming is still going on. So, when you resume, there is a lot of issue because of the timestamp that should increase. And, of course, and also the Chromecast is very broken in the type format they support. And so, it is coming and you can try it already. It works, but I'm not sure it's actually working for like normal end users. Okay, thank you. Other questions? No questions? Yes, sure. By C minus minus, is there a separate place where that's documented or is it just a set of conventions for the way that you guys do object stuff? No, it's mostly an internal joke. It's not really standardized. I know a lot of projects are doing it. A lot of the older VLC developers were really against C++ but the way it's done is mostly a funny joke and it works fine for our use case, which is to have like a minimal abstraction for modules where you don't know what's inside without having a big inheritance and so on. And in terms of hardware acceleration, is there much in the way of the module support for 2D and 3D acceleration? You mentioned GL, but it's not everywhere. So what do you mean by acceleration? Well, I just mean... I've been at a talk recently about OpenCL and stuff, so I'm just always interested in why it's offloading, CPU load. So when we speak about... So for the Militia Media Bear project, when they speak about hardware acceleration, what they want is decoding acceleration because for a long time we already have... we already have hardware acceleration for the display, which is direct 3D or OpenGL or X-video, which are basically... So we can actually ask the GPU to mostly do the chroma conversion or scale because doing that on the CPU is stupid and takes a lot of... But the biggest discussion lately, especially on Linux, where we have two or three different APIs, is hardware acceleration, which is a decoding part. And the problem is that most of the codecs are very difficult to do in OpenCL, for example. So usually it's kind of DSP parts directly inside the GPU. VLC supports hardware acceleration or all platforms, but on some platform it does it in a bad way, which is it sends the data to the GPU, ask it for decode, and then gets the data back from the GPU, do the filtering, and then displays it. But most of the time this get data back is very slow because it's not what you use to do for GPUs. It's called GPUs, usually you send stuff, you never get it back. And also it's doing mem copies, and as we say in multimedia, mem copies murder because it's basically murdering your CPU. So what we do is what we call the full GPU acceleration where you send the data, you made it decode by the GPU and then you're going to control the GPU in a different way to when it's going to display it. And we have that but not in all platforms and not all the APIs. It's going to get fixed for 3.0 for all of them. Yes, maybe I can show you the puzzle if I find it. Again, I'm still taking questions if you want. Yes. No, no questions. I hope it's going to work, and no it's not going to work. So of course I broke my tree because it's not funny. And yes, okay, so I don't have a working VLC, which is not that surprising. I don't watch video anymore, I think. I have never time, and every time I got it, I break it. Oh yes, I do. Yes, so then I can do that. And this is probably going to be around here, right? And yeah, it's supposed to be an easy video and there will be something written on it. But oh yes, I got a corner. So yeah, wow, I got one corner, right? And then what? Yes, we're getting there, right? So anyway, completely useless, but therefore completely necessary. If there is no questions, I will stop on that. Yes, there is one question. Yes. How do you go about getting add-ons like that? This is a video filter. So basically it's taking video frames in and then doing video frames out and then all the video filters can actually capture the mouse and the clicks, and that's how we do it. And then there is some kind of bezier thing to draw it. But the code is open, so you can check it out and I can help you to improve it. Thank you. And on behalf of LCA, we just have a small token. Oh, thank you. How do I disconnect that?