 Tim Mirthro Ansel has come all the way from Australia to talk to us about dissecting HDMI and developing an open FPGA-based capture hardware for sharing talks outside of the room. And he will be explaining how to dissect it and I'm looking forward to hearing the talk in a second. So please give Tim a round of applause again. Thank you. I'm Tim. In theory, if my slides change, you would see that here. And I kind of have two projects and I'm going to be discussing one of them. And I'm going to be discussing one of them today. This is a different project, where I gave a talk to a friend of mine earlier. If you're interested, you can take a look at it. And people wanted to know when you could look at it. So first of all, what I have to say is that I'm a software developer. I'm not a hardware developer. I don't make FPGAs. I'm not a professional. So I'm not a professional in one of my areas. I'm mainly a software developer. So this is my hobby. And this information comes from other projects that I started, where I didn't leave the main job. And I'm only telling you about it today, because the other people are too shy to tell you yourself. So thank you very much to all these people who helped me. And the whole blue thing is on the left. So if you're at home, you can follow the URL and click on the links. And of course there are other people that I haven't forgotten. I'm sorry. So this lecture could be called Software Developed Hardware and complain. I really thought about this lecture for a long time. But that's how it happened. That's a bit of a story. So how do I end up doing the HDMI stuff? So Timvideos is a group of projects that try to take live streams and conferences and it's very easy to do. We want the awesome team that is doing what we're doing here. We want to do it without the walk-in, which is so great that we want to do it the way we want to do it. We want to do it there where people have no idea of how they're recording. And we want to make sure that it just works. And that's an effort we would, for example, take the whole thing. I'm going to talk about these two things, the HDMI to USB converters that we've built up. They take the camera off and also the photos. And HDMI to USB is FOSS hardware to take the HDMI off. It has a bit of a story with the CCC. Because the whole thing was inspired by Bunny. He spoke on his NET TV on 28C3, what an attack on HDMI was, an end in the middle attack. If you're interested, take a look at the talk. You can see what Bunny did, mine is more basic, and I don't need to get any HDMI experience here. The whole thing does the same thing as Bunny does, but Bunny decided to take things off, but we just want to take the pictures. You close it between the laptop of the interpreter and the recording, and there's a high resolution output. And it's an FPGA, and that's basically the software problem, instead of the hardware problem, because I'm a software developer. It's a webcam, so you can use Skype and Hangouts, and it doesn't need a driver, and it works with Max and Linux systems. On Windows you need a driver that uses the internal driver, and also a serial port. You can switch from input to output on any output you go to. This is the open source hardware that we designed, you can find it on GitHub. I'm quite proud of it, I'm quite proud of it, it looks really good. We don't use all the features yet, but it's really cool. And it's in use. It works, and we use it. We use this technology for a whole series of conferences. Caption in Australia, DebianConf, DipConf, PyConf, LinuxConf. In Australia, South Africa is also used, and a whole series of other people around the world use it. It's really cool. That's why I wanted it to be open source, so that other people can use it and learn from it. And the problems can be solved, because there are a lot of problems. This is all full of Python. We use Python to create the firmware for the FPGA. We use Python to make the firmware for the FPGA. If you want to find out something, then come to the PyCon, which was recorded with this hardware. As I said, there are a lot of problems. If people still use VGA, that makes me sad. Because VGA is not HDMI, it was invented in 1987, and it's a analog signal. HDMI already has a bit of a common history with VGI, but you can't use it yourself to capture it. Why do we still use it? It's old, it's bad. We developed a VGA extension board, which can also be used to capture video. We have designed it, but no one finished the firmware. So this design exists. If you can help, that would be great. There is another problem. I want to do this in open source, as I said. The HDMI ecosystem has commercial cores that you can buy, but you don't get the source code. Or if you get the source code, you can't continue. I also want to do this in open source, because we want to solve the problems that people have when they plug in their laptop. And the commercial cores allow us to give the ability to solve those problems. They are not designed so that you can fix them permanently. So, it's a new implementation. If you made a new implementation, that means you get new errors. This talk should actually be called the debugging HDMI, because there is a lot of information about what went wrong. That's why it's the introduction, why we are here today, and why we are talking about it. How does HDMI work? HDMI is a few times old. In 2002, it was specified. The specifications are based on the DVI specification. It's back in 1999. It's almost 17 years old. And DVI should replace VGA. And there is a lot of common history. DVI is backwards compatible. It's electric, but it's used by other connectors. The HDMI connector, you've probably already seen it. If you look closely, there are 19 connectors in there. This is the first one. These five pins are for ground, for mass. One pin is for the five-volt supply, with 15 milliampere. You can't do much with two pins. You can sometimes adapt and convert a microcontroller. That doesn't work if you want to take out a whole ampere. So be careful with that. There are three high-speed data connections, which have a common tag, and then there are five pins with high-speed data, and then there are five pins for low-speed data. And then there are five pins on the HDMI connector. Maybe you noticed that there are a lot of different things I said there. And there are a lot of different things I said here. And you have to understand a lot of different protocols to understand the HDMI. There are a lot of low-speed protocols. And high-speed protocols. I'm not going to talk about all of those protocols, because it's too much and I don't have the time to talk about them. I'm not going to talk about low-speed protocols. I'm not going to talk about CEC. I'm not going to talk about the auxiliary and data protocols. And HDCP, I'm not going to talk about them. Look at the Banyan's report. It's a lot better. I'm not going to talk about Ethernet. The first one is EDIT, DDC, the 8-bit 10B, the encoder of the pixel data and the 2-bit 10B encoder of the control data. That is actually DVI. We're not talking about HDMI, but DVI. I'm going to explain how DVI works. So, starting with the low speed, we start with the slowest protocol, EDIT or DDC. You can, these two, I'm going to express these two together, so these are equivalent in my opinion. This is what HDMI from VGA gave, it was added to VGA in 1994 for plug-and-play monitors, so that you could just put it in and it worked. Instead of having to tell your graphics card what kind of resolution the monitor has and that it works. The whole thing is I2C and a small EEPROM. It's used the PINs 15 and 16 with 15 as clock pin and 16 as the data pin. And the 5V will be at least around the small speaker. And 17 is the ground pin and 19 is to see if there is anything to it. I2C is a slow data protocol with 100 kHz or 400 kHz. So it's technically not exactly I2C, but actually because it only supports 100 kHz. So I'm going to explain in detail. It was well explained, so I'm not going to explain it here. I'm not going to explain how to implement it. The EEPROM is a 420. It comes from the 420 series. It has an I2C address of 0.50. That's 256 by the speaker. How to talk to one is very well described. So I'm not going to describe it here. I'm not going to explain it here. If you use EEPROMs over I2C, it's very likely that you use an EEPROM. So like a 16-width one, but EEDD only supports 18 with EEPROMs. The interesting thing about it is the data structure. It's a binary format where the whole thing is described on Wikipedia. So I'm not going to explain it here. But the important thing is the resolution, the frequency and the format to talk to the screen. That's really important, because if you try and solve the wrong data, it doesn't work. That's why you use EEDD. So this is where things start getting a bit hairy. So the first thing you see anybody asking is what resolution do I use? At the beginning they always ask me what resolution should I use, where you can choose from such a list. And the thing is, despite your monitor saying that it supports many formats, I don't know why. I don't know. Projectors are a lot more than northerners. I don't know why they're even more lying than a monitor. I don't know why that's so. So that's what a supported format looks like. Really, really great. As well I care about capturing the data. I want things in the format that are easy for me to capture. But of course I don't want to scale things too high, because the whole thing makes it unreadable. If you have a bad resolution and it's high-scaled, you know how it looks. It makes text unreadable, of course. And people are known for using really small scripts. So how we solve this is we simulate our own e-prom and send our own edit data. This is what we support. And we show it in the contract that there's only one resolution and that it solves our problem, that you can borrow something from it. It makes it hard to choose the wrong one. So that makes sure that people don't get the wrong option. So one problem less. Now we have another problem. We recorded Picon and we found out that some Mac-Laptops just didn't want to work. To understand the reason, you have to understand how the world works. There are two frequencies in the world. There are 50 Hz and 60 Hz. 50 Hz is like the rest of the world and 60 Hz is like America. That's pretty rough. And a laptop that's sold in Australia makes 50 Hz. And then you think that a laptop that only had 40 Hz could work. And of course, you expect everything to work globally today. So it doesn't matter where I connect my laptop. It should work everywhere. Yeah, but unfortunately not. So we solved it. Claiming that we're American and it's 14 seconds per second, brother. 60 frames per second instead of 50 frames per second. That's pretty hard to solve. We rolled out the whole thing on Friday evening and on Saturday, Wednesday, and on Saturday all the problems we had were gone. So that was a good solution and one of the advantages was that it was very hard to control. So there's not really a difference between 60 and 50 Hz because no one gets 50 slides per second. And one problem that they still had was that it was really hard to control. And the main reason why a laptop can't talk to the beamer is that it deserves a trophy. To find out why that is, we created Edit.tv to put up edit data. It comes from the Google Code Project 2013 where we created a program that can just start with a laptop and upload the whole thing. But I haven't worked on it since the assembly of code. We would like to have an open database where we can collect all the edit data. So there are a few keys, and I could pay for it, but I would like to have an open library for it. So you don't need a lot of recording equipment and the C3 has a version. I have a version that is edit overrided. I have a version for HDMI. It has a cheap microprocessor with EEPROM. DisplayPort is not HDMI. You shouldn't change it. There's an auxiliary channel, similar to Edit and CEC. To decode them here at CCC. So if you're interested in that, if you want to talk about it, you can do similar things. So that's the slow speed protocol. Now to the fast protocols. What about the high speed data? So each pixel in your screen is basically three colors, DVI standard, red, green and blue, and each one is a byte in size. Each of the colors goes on a HDMI connector, on your own channel, and I painted it red, green and blue. Each channel is a differential pair, plus and minus and a shield. And that is a twist and pair to hide the signal-to-noise ratio. And we also have a better shield. And so this is kind of where it gets the differential signal-to-noise that is the code name for the internal protocol that is used on the fast protocol. Also, all these channels share a code. So this code is a pixel code. But each of these channels is a serial channel and transmits data by 10 bits. So every clock cycle, every clock cycle, 10 bits on each of these channels. Each of the channels is running at the same time. So this is kind of what the whole system looks like. So you get the red and green and the blue channels. You get the eight bits of input data. You convert them to 10 bits that will then be transmitted across the cable and then it goes through the cable and then you decode it on the other side. So the question is, what does 8 bit to 10 bit encoding look like? And how do you understand that? How can you understand that? So this diagram here describes that. It's a little bit smaller. So I make it a little bit bigger here. So it looks like this. What? This diagram... I've spent hours looking at this and it is extremely hard diagram to understand. It's very, very hard to understand. And it turns out that the encoding protocol is actually quite easy. It's just three simple steps. So I'm going to show you all how to write a encoder or decoder. I'm going to show you how it works. This diagram is simply a diagram that is not the inverse of this for the code. It's not the inverse of this for the code. You can't read it again. So three steps first. We have to decide whether to control or pixel. Either we have to encode a control or pixel data. So following important points first. The input data, no matter how wide they are, are always converted to 10 bit symbols. Data goes to symbols when we're talking about data and pixels and data and so on. What we need to be kept DC balance. Also everything has to be DC balanced. So I'm going to tell you why. It's 10 bits. I'll explain why the pixel is 8 bits. I'll explain that later in the pixel section, but I'm always transmitting 10 bits. I'm always transmitting 10 bits. I'm always transmitting 10 every clock cycle. I'm always transmitting 10 every clock cycle. So the VEVCOM is going to flow from one to four zeros of fat. So long sequence of zero or one, and all this, I'm going to cover it. I'm going to cover it. It isn't basic coupled, it's not really basic coupled. It's not to recover clock. We have a clock care. That is you have a signal from the internet. That's the way of the reason. We're going to keep DC balance because of clock. We're going to keep DC balance because of clock. We're going to keep DC balance because of clock. So what does DC balance mean? A symbol which has lots of ones throws and or lots of zeros. That's what we call DC bias, that's why it's called DC bias. So if we look at the symbol here, and by looking at it, the symbol has lots of ones, and if we look at the single ones, we can see that there's a positive weight. we would have overhung in the negative areas and then we get over time, we get overhung and there are problems. So these are two important things. So first thing we need to do out is how we can choose between control data or pixel data. So what's happening in your display is if we transmit something bigger than what you see on the screen. This is not marshal data, it's much smaller, the control data is smaller. The control data is in the orange area and the purple area. So why does it exist? Why is it like this? This is because of the old tube monitors. So those of you who were born as an after-tube monitor, that's how they look. And how they work, they have an electron beam that goes over the tube and then it lights up. So this electron beam can go back to the other side of the screen, so it's in zero time. And we need time for that. And this time, we need time to get ready for it so that the beam can go back to the next set of data. And then the next set of data comes. And so that's why it exists. Why do we care? The main reasons for control and pixel data are actually the fact that the encodings for the pixel and for the control data are pretty different. The main difference is this one here. I'll come back to that later, but the important thing is that despite the encoding scheme being quite different, although the encoding scheme is different, there are ten bits at the end. So that first step, choosing whether it's pixel or there is control or pixel data, is through this small part of the diagram, as you can see, not the first part of the diagram. So how do you control data that you control? How can I change control data and control symbols? So next, I have to know what control data is. These are horizontal signals or vertical signals. And they control the horizontal and vertical pixel sizes. That comes from VGA. You don't really need a HDMI or a DVI to know how big the display is. Because we can find that out differently from the differences between control and pixel data. But there are just backwards compatibility reasons. This means that we have two bits of data that we have to convert to ten bits of data. So a two-bit, ten-bit scheme. And how do they do it? Well, they just chose four different symbols. These are the four symbols. There are a few interesting properties. First of all, they are roughly the same amount of data without the same amount of data. So we don't have to worry about the same amount of data. They also chose to have seven or more transitions from zero to one. Why is this important? This number of transitions allows the phase relationship of the channels to be determined. It's important when we... It's like a signal signal. And even if the transmitter would transfer everything at the same time, the cable is not ideal and would have a few signs later on. And now that you have so many transitions, you can find these phases and dependencies between the channels and reconstruct the data. That's why these control symbols have a lot of transitions between zero and one. But we'll get back to that later. So this part of the diagram is the control data. What about pixel data? Again, in the DVI, the channel of the pixel has eight bits. And the encoding scheme is described by the basic coding scheme. But actually, it's really simple. This encoding scheme is called 8-bit, 10-bit. 8-bit to 10-bit to convert. But big danger, IBM has developed such a standard. But it's used for something else, for example in display ports. So it's not the same as what we have here. It's a very long attempt to transfer it to the IBM coding scheme, but it just doesn't work because it's different things. So the pixel to encode is two, three steps to process. The first step is to reduce the transitions. And so how do we do this? Why do we do this? Again, this is a high-speed channel. We want to find the cross-talk between the channels, because they are very close to each other. When we reduce the transitions, we also reduce the probability that the signal on another channel is overflowing. How do we do this? We choose one of two encoding schemes, either an XOR or an XNOR. So how do we do the XOR encoding scheme? It's actually pretty simple. We set the encoding bit, what the start-bit is, and the next bit is the first data bit, XOR, with the first encoder bit. And we do that until we are through our 8-bit. And the XOR encoding is exactly the same except that we instead use XOR or XNOR. And how do we choose what we want to use? If our input data is less than 4.1, then we use XOR. Then we use XOR, and then there's another case, again, the XOR is the same. This method is lit up by a data bit. So every pixel has a one mapping to any pixel, and then we append a bit on the encoder, then we append a bit and then we hang a bit in the back to show if we used x0 or x0. That means we can invert our 8-bit input to 9 bits of encoded data. Our 8-bit encoded sequence and then our 8-bit encoded sequence and then the bit that we used x0 or x0. So that's it there. This encoding is actually very good at reducing, this encoding is actually quite good at reducing transits. In average we had 8 transits and now we have about 3 transits. So that's really cool, I have no idea how many of you saw it. So there was probably a really, really great mathematician who found it out. Because we don't know how many of you saw it. But that describes the top part of this diagram. And that's where we're in the TMDS. The TMDS stands for Transition Minimization, so Transport Minimization. We need to keep the channel dc balanced. So how do we do that? Because our pixels are not guaranteed that the dc is balanced. We do that by keeping a channel and then if we have a positive dc bias and if we have a positive dc bias and if we have a negative dc bias then we invert the bit. So if we do this until the 9th, the reason we do this, if we invert a symbol, it becomes a negative dc bias and we have a positive dc bias. Because we were all negative and the thing was negative and the whole negative thing was negative, that means that we move the dc bias towards zero again. And that means that we try to keep the dc bias from oscillating so that we keep the dc bias from zero. Then to indicate whether or not we invert it or if we invert the bit straight through or we invert it, we add a bit on the end to show if we invert it or not. And that's how we get to the 10 bits. We have the 8 bits of the encoded data and the 1 bit of fx or xnor to indicate whether or not we invert it to simple. And then of course the 1 bit of the symbol we invert it or not. That explains the bottom part of this diagram. And as you can see, it's why the whole thing is a little confusing. Well, I think of a logical diagram, which might be a little bit hard to understand the protocol, but you have to get a little bit of a climb to understand the whole thing completely, but it's really not a good diagram to explain it. And as you see, it's actually pretty simple. And in summary, this is the interesting, the two encoded schemes, because we minimized the transition to pixel data and actually tell control data to be a part by how many transitions are possible if it has six or more transitions to be controlled. If it has six or more transitions to be controlled, it must be a pixel data and if it has less, it must be a pixel data. Now you know how to encode TMS data and how to decode TMS data. Now you know how to encode TMS data and decode TMS data. If you want to decode the whole thing, do it backwards. Congratulations. So how do you actually implement this? Well, you can just write the general logic and the logic that keeps track of the TMS data by all that type of thing. You know how to decode TMS data as an FPGA that we're not going to have much time because I don't have much time. But if you follow the process that I've given you, which I've shown you, it should be easy. But this is what we use currently. You could also use a lookup table or you could also use a pixel data to decode TMS data to a pixel data to convert TMS to a lookup table. So as a lookup user, FPGA is a really good lookup table to extend this system to do those other protocol and then you can expand the whole thing to the other protocol level. So we're looking at that right now. It's a few more resources, but it's a lot more powerful. This is like your encoder, aussie and your decoder. It's really simple. It takes your 8 bits of data and the 2 bits of control data and the data type. If you went into our design and looked at our design and said, I think you're probably looking at a higher level and you're at a DC bias count that you have to keep track of, but then you're at a DC bias count that you have to keep track of and then you're at a DC bias that you have to decode. The data come in and on the other side we're out. So simple is that. And yeah, this kind of extends to auxiliary data, auxiliary data or also with errors. There are 124 symbols that you can have as 10 bit data. Not all of them are valid. That means if one of these doesn't get valid symbols you know there's an error. But things happen relatively fast when 7 bits are multiplied. So our pixel clock is 150 megahertz. If you multiply it with 10, it comes to 1,000 megabits per second. When you do 720 pixel resolution you have 745 megabits per channel and 750 that's multiplied by 10 that's 750 megabits per second. And FPGAs are fast but they're really they're not not so fast that I can handle. I'm pretty sure that the military controller has these as fast but I'm not that rich for them. But there's a nice hack that you can do the whole thing. O-Serders convert parallel data into serial data. That's how the box looks like. And you give me parallel data and we can do the whole thing into serial and fast data. And they're cheap they're easy to use. And the best thing is of course you can find it all configured for a new FPGA. There's really good documentation to use and they're unique for the FPGA. So different FPGAs have different control mechanisms. So if you use my chip for configuring this there's a link to it. And as I said remember how I said that our system has this system because we have this system we can really look deep into what's happening in the system and bring it out. And so this is a debug from one of our systems. You can see the first thing is the phase between the channels whether it's a lead signal and on each of the channels and then we have the error rate for the channels whether all channels are synchronized in a few additional situations. As you can see there's a 64 MHz clock and that's in three pieces because it has a red, blue and green channel. There are a few interesting debug possibilities when we connect to the cable and you get errors for example in the blue channel and otherwise nowhere then it's very likely that the cable is broken that allows us to figure out what's going wrong in a system. That's not what you can do with a commercial but what are the errors about now is a little bit experimental that might be about what we can do now because we have complete control over our decoder. So what's possible in 1024 are valid pixels symbols and 565 symbols should never be seen. Those are already 56% that could never be seen in the whole field but it's actually better than that because we have the DC bias in the run there are 256 valid pixels in each state. You can't you can't have the negative symbols that have the DC bias so that half of our space can't even be used by the methods we use. That means that many of the invalid symbols only have one other valid symbol. That means we can assume that this symbol was the symbol because we have so much selection that it's a bitfailer and we can lift these errors we can lift about 70% of the bitflip errors but there are some errors that we can't lift but we can determine that we got invalid pixel data so the fact that there is an error is important in this case you can have two pixels that you can see right one that you see wrong one where we know it's wrong and two where we got them right so the blue channel the first two were really blue then the decoded the decoded value gives a very light blue and that's bad that was probably also a whole blue block one pixel but a pixel is probably no valid value so we can cover the two pixels we can take the two pixels take them together and correct them and with that we can make a lot more errors that appear here and if we put this data into a jpeg encoder this does actually affect the quality of the image so other things that you would otherwise see we can do without the quality loss so that's really interesting information about how you can fix some errors and how you can fix some errors and we can do it even better because it's an open source project and the idea is how to improve the performance or how to do TDMS decoding with less power it's an open source you can look at the code and you can do it better and we would be happy if you could I have a lot of time but I don't have a lot of time if you have a lot of time but no hardware I think we can solve the problem these are the hdmi projects and everything that I proposed you can find on github our entire hardware and everything on open source and here are some bonus screenshots that I couldn't put into the presentation you can see that was a big mistake small mistake small mistake that happens when the ddr memory if the memory is broken yes but yes and that is my talk and that was it from me thank you very much thank you very much as you've noticed if you have any questions please put them in the mic and I'll answer your questions yes thank you do you know if normal monitors do you know if normal monitors do you know commercial implementation and the commercial implementation that many people have for the commercial people is the goal They can do that too, because they don't have to deal with the angry speakers, because they never see the annoying speakers who then get upset about the slides, they look weird. And besides, they probably have better quality in the hardware. We do that as cheap as possible, and that's why we're pushing boundaries of the devices we use, and that's why we get more mistakes. We have quite a lot of questions to remember. We still have a lot of questions. So don't think about it. Just ask no comment. There's nothing coming up right now. Yes. Yes, thank you. Sorry, I don't quite understand what's going on. Sorry, I don't understand what's happening right now. Do we have the opportunity to do that? I'll be around afterwards. If you want to talk to me, just go ahead. And we might do that right to you on the computer afterwards. Next question from microphone number three, please. Can you determine the quality of the HDMI card? Yes, we can. The quality of the HDMI cables should be at 0-bit. So everything that has more than 0-bit is gone. It gets interesting when you have very long cable connections. We can see that the longer the cable is, the more difficult it will be to stay at 0-bit. So yes, we can look at the quality of the cable. But it's also a bit complicated because it depends on what the sender is doing. If the sender has a bad quality and the cable is also bad, then you make a big mistake. But if you have a good sender and the cable is bad, then it can still work. So we can't just say that it's a good cable because we don't know how good the sender is on this device. If we could turn the sender down a bit and see how it works, then it would be really cool. If you want to look at it and build something like that, I would like to help you with that. Can you ask me another question from Micronome5? Can you order your HDMI to USB hardware online? Or do you have to solder it yourself? You can't solder it by hand. You are much better than me. It has ball grid area parts because it's FPGA. You can buy it. We work together with a manufacturer who manufactures it in India. We worked with them. And that worked really well. We are also developing new hardware. I have a whole series of new hardware here. Take a look at the other one. And we will also have thousands of them in the hall. Once again, if you are interested in hardware, and if you have a news case, then let's talk. Because I would like to solve problems of people who don't have hardware. And also, my employer gives me too much money. My work gives me too much money. And it's so much fun to help other people with open source stuff. We have a lot more questions. Niko from number 3. Do you think it would be possible to get around 180p images of the open source hardware? I think so. But we have to do some hard work. We haven't had hard work. We don't have time for that. 720p at 50 frames per second is good enough. The USB connection is limited without bandwidth. Because we only have H.264. So if someone wants to write a WebM encoder, open source, that would be much more interesting. We also have Gigabit Ethernet on the board. It should be relatively easy to stream the data via Ethernet. But I also need help. The Ethernet controller works. We can use a Telnet. We need to control the board. But we need someone who really gets the data out of it. We use it for debugging and so on. Once again, Mike Hamsterfield. Thank you very much, Mike Hamsterfield. He is a great designer. He built 1080p. It works really well on a hardware that is very similar to ours. He also developed a 4,000 pixel display port. What we can do on our board now. If you only need one or two of the 180p display ports, then you can connect it to HDMI and then work on it. It is possible, but open source, we are hobbyists, amateurs, we need developers. We'll take one question for you. Thank you. Have you considered JPEG 2,000? No, we don't. Especially because I want to be a webcam. That's a USB webcam standard. It doesn't support JPEG 2,000. There's no reason we couldn't support JPEG 2,000. We could still use a driver to and JPEG 2,000. I don't know if there's any source that supports JPEG 2,000. That's also a problem. If you want to, come by. We'll let you talk. I would very much love to do the chat. I would soul the class if I could read your problems. Also, we have t-shirts. I have a t-shirt on. Anyone who helps gets a t-shirt. Whether it's on our website, whether it's documentation, whether it's helping people, setting up the sport, whatever. You don't have to be an expert. You don't have to be an FPGA expert to help. We also have a small project on MicroPython on the FPGA. If you're interested in MicroPython, I would love to do that. I would love to help you. We just need more support. We have two more questions from Microphone 1. Is there some sort of dedicated processor or is there a certain processor or do you use the open source software? We use an open source software, one of three. We can change that. We can use either the Lattice Micro32, which is made by Lattice. We can also use the OpenRisk 1K or the Risk5 processor. We generally default to LM32, because most performance has the smallest FPGA resources. Traders are western, but if you like the Risk5 more or the OpenRisk 1K5, then you can also use Linux. If you don't want to use Linux, you can do that with a single-seller changes. We are looking at if we can add a J-Core support next year. J-Core is pretty big in terms of LM32, so it probably doesn't fit on the small devices. The last question is about the FPGA. Our new board will be R-Tex7, but we are still in the process of making it. Our Bani32 is also supporting the J-Core. It's really cool. It showed that it's possible. One more question. Do you have any plans to add HDTS? Yes, HDTS, yes or no? We have plans and ideas that we can do it, but HDTS and HDTS are much more difficult for the consumer and we want to keep the costs low, as low as possible. HDMI is consumer electronic that's everywhere. It can be run on Raspberry Pi. HDMI is probably the solution for the SDI course that we haven't developed yet. I can't tell you that we're doing something. But if you're interested, please, I would like to see that someone does it. One more question. We have two minutes left. The question is not about HDMI but about FPgas. FPgas is written in high-complex language and then it's compiled. That's why every manufacturer has compiled for their own hardware. Can you tell us about FPgas compilers? Yes, if anyone knows about it, he knows that the compilers are proprietary and the proprietary compilers are terrible. As software engineer, if I find a mistake in GCC, I can just fix it and continue. Or at least I can find out what's wrong with FPGA compilers. FPGA compilers that we've used are not deterministic. You can give the compilers the same source code and there are two different outputs. It would be nice if I could explain why this is possible because I've removed all the coincidences but the compilers make different things anyway. I'm impressed. This is an open source FPGA cool chain for the latest S stick thing. He says he will work on Atrix 7 FPGA. Please write half of it. If that exists, I'll give you a million beers because it's faster to move the toolchain and it would make my hobby much nicer. Please help. And a big applause.