Well, I guess we should just start. I hope you can all hear me. Everything okay? Good. Well, very much people showed up to see our talk, which is a good thing, I guess.

A little bit of pressure, but I'll walk through it. So this is the talk about CODI, formerly XBMC, open source home entertainment center for who doesn't know it. Wow, we've got some nice scrolling going on. Optimal presentation, as you can see.

Who are we? I'm Martijn Keiser. I've been using XBMC since 2011. I'm currently the project manager for the 14 release and probably also the 15 release. Probably. He's just stating that now so that other people won't object. I joined in 2011, so I only used it for a half year. Then I was invited because of what I contributed.

That's basically the story. My name is Eyal de Klerk, username Kip at the forums. I've been using XBMC since XBMC 10, which is not fully through.

I actually did use it on the original Xbox, but I only did that for a short time. And as an end user, then I wasn't involved anymore. I came back around 2011, started supporting, helping on the forums. Picked up a skin I liked, which wasn't supported anymore. Fixed it a little bit.

And then joined the team in the foundation in 2013, first as a forum moderate and almost immediately as a full team member. Because I started doing server maintenance as well. Because I'm a server guy. So for people who don't know it, what is Kodi? We are an award-winning software media player and entertainment hub.

Best game. We won a SourceForge award for best game. We run in a game loop, so we were considered a game. We ran on the Xbox, so we were in the game part.

We actually have the award that says best game. Ever since we've been telling people we're an award-winning software media player, which is funny. It says we're the world's largest open source multimedia project. I guess that's true if you look at code.

We are GPLv2, free and open source. And we basically play back everything. Except Dash. Sorry. Yes. That should be coming soon. So basically what is it? It's an end user GUI to play back media, wherever it is.

Locally stored, internet stored. So what do we run on? Basically everything and free BSD. It will become a little bit more clear why I say that once we get to some details later.

So Linux, Android, iOS, OS X, Windows after Vista, free BSD. If you have hardware that's capable of playing back video. We need OpenGL support. And we still run on the original Xbox. We don't maintain the code anymore, but it was forked. And there's a group, a very dedicated group, called XPMC4 Xbox.

Missing an X, I see. Which is still maintaining the project. Of course the newer versions are doing cool stuff that the original Xbox simply can't do. Like 1080p and stuff like that. So you might know some other media playback things.

Like the cone thing and the Windows thing. What makes us different? We have a unified interface to view pictures, videos and music. Music. We were one of the first players to come with a 10-foot interface.

Remote controlled, control it from your couch, view your media, experience your media that way. Fully skinnable using XML. We have currently for the latest version about 15 skins, I think, that are fully updated. And we use almost the same code base on every platform.

Which basically means you can download the code and compile it for your own platform. There's no separate code base or anything. We support add-ons written in Python. Currently have around a thousand. Which are in our official repository. And there are probably a few hundred more that are not in the official repository for various legal reasons.

You can imagine. Almost the entire program can be controlled through JSON-RPC. That's still a goal, to get everything in JSON-RPC.

More to that later. First to integrate features related to media consumption. Yes. There are some distributions where you can get Kodi on. Most notable OpenALec, which is a minimal Linux distribution directly booting into Kodi.

Runs on nearly anything with ARM x86 that has OpenGL. We have our own distribution called KodiBuntu, which is standard Lubuntu with Kodi on top. Raspbian for the Raspberry Pi. There's a few other distributions for the Raspberry Pi. But Raspbian is, I think, the best.

OpenALec? Well, OpenALec, of course. But if you want to do a little bit more, you can run something like that. We have SPMC, which is an unofficial test fork made by Kuoying, our one and only Android developer. So if you're an Android developer and you're hearing this, then go ahead, they have only one. Yes, we need more.

And several other distributions, which you can see on our wiki. Now, there is no demo. Because we can't do it here. You're welcome to join us in the AW building, where we have a small stand and we can demo the application there. We are currently running it from Amazon Fire TV. The Fire Stick, actually.

Amazon Fire TV Stick. We have the VTEC box. We have MiniEx. Tablets. Android phones. And laptops. Windows laptops. So we can showcase a few different operating systems.

So recommended hardware. This is the question we get most on the forums. What is the recommended hardware? There's none. We don't recommend anything. Anyway, things you should not buy. Apple TVs, because we're not supporting them anymore. Apple TVs have never worked very well after ATV2.

ATV3 hasn't been rooted. And Apple TV code, there was possibility to have a Crystal HD card inside to get more performance out of an original Apple TV. And that Crystal HD was supported by only one person who was basically fighting against issues.

And it was more and more trouble and he just decided to give up on it. So nobody's developing for it. We dropped it. So from 14.1, which is our latest release, code name Helix, we are not supporting Apple TV anymore. Anything running L winner, Android or any non-name brand Android device, I wouldn't buy it.

If you want pass-through audio, you should not buy Android at all, because it's not supported in Android itself. So we can't do it either. From Android 5. It's still not working correctly, I think. Is it?

It is. Okay. I have to change this then. And what I generally don't recommend is running it on slower hardware. A lot of people run Kodi or XBMC older version on Raspberry Pi. Very cheap platform to run it on. Reasonable experience.

Plays video very well. The GUI though, not as snappy, not as responsive as you can get when running it on some more decent hardware. Good for a first try though. Secondary room, that room, whatever. What do we suggest? Run it on an x86 device.

Zotac, Intel NUC, Gigabyte bricks, very popular at the moment. And the Chrome boxes, also very popular on the forums, we see a lot of people buying those. If you're going Android because you don't care about the pass-through or because you're testing the new version that does do it, apparently.

FireATV, Nexus Player, cheap, performant. As it says, low-end ARM devices give you a basic experience. If you want the real experience, get something like x86. Some other hardware. Not to run it on, but additional hardware you can use. Stuff that we really like is the Flirq infrared adapter.

Where you can learn a remote control and then use that to control your XPMC or Kodi installation with. The HDMI CAC adapter, so you can use your existing remote for your TV.

Because not all devices have CAC support. The Raspberry Pi does, the Android FireATV stick does, but that's, I think about it, isn't it? No? Yeah, they're like, you got a developer over there who's like, there's four more, yeah, four.

We have 200 or 2000 Android devices, so there's only a few that do that. So the main question we get at the moment is what happened to XPMC? Well, it's a very simple story. Devices were being sold under the name XPMC without our permission, including add-ons that were streaming piracy video streams.

We are a registered nonprofit foundation, registered in the US. Obviously, this is a problem for us. There were several groups that were claiming they were XPMC, sending emails.

I won't name names, but we had some issues with those. So what we did at one point is we applied for a trademark. And we probably should have researched that better. But what happened was there was another company that had a name that was very, very similar to ours. And they had to protect their trademark. Luckily, this company was very nice to open source.

So what they said is, listen, we have to defend our trademark. We don't want you to use this name anymore. We don't want you to use this name in the future anymore. But you're still allowed to keep using the old name, keep the old sites, but just change your name.

So... Well, they gave us an extraordinarily amount of time to do so. Of course, the company is just legally required to defend their trademark. And they could have just killed us. Take your sites offline, take all the downloads offline, which they didn't do.

So, I guess, I guess. So, for a brief history, where do we come from, where are we going? We started on the original Xbox, as I already said.

I'm not going to say all the stuff that's there, you can read it if you want. In 2001, when the Xbox was released in the US, and by 2002, there was Xbox Media Player 2. Why the original Xbox? At the time when the original Xbox was released, it was one of the cheapest ways to get decent hardware to run video on.

It was a very, very cheap way to get a device that could do all of this. It was also hacked very fast. So, because it was hacked, because it was cheap, a lot of people bought it to run as a media player.

We get this question, I put this in, we get this question a lot, because people say, why doesn't it run on the Xbox 360? Well, that's a totally different story now, is it? It's expensive as a media player, and it's not been hacked. So, yeah, there you go.

So, originally, all homebrew required the Microsoft SDK. You could distribute the source, but needed the SDK to compile, which essentially forced the existence of open source ecosystems. Providing binaries was illegal. Illegal. Microsoft never did anything about it, I think.

XPMC is developed in C, C++. It's still partially structured around the game loop, because on the original Xbox, this was the only way to get it running. Over the years, many parts were taken out, but the original core part, I think it's called C application, right?

I'm not a programmer, I'm looking at him. You have to provide me with programmer details here. Yeah, I think recently there was some guy who, a new guy who came up and said, let's remove C application.

He has. He has. Yeah, no, I think he provided the pull request on GitHub saying, yeah, this gets rid of the old game loop. And he did it for like 60 or 70 or 80 percent. And basically, the minute somebody saw it and saw the quality of the code, he went, yeah, you should be on the team. And then 20 team members went, yes.

That was a very fast, I think that was the fastest new team member we've had. Basically, the response was, he got balls. Yeah, yeah. Like, man, like. Okay. Well, we have a GUI library that defines widgets from XML.

So skinning is relatively easy. It's actually not that easy, but at least it's possible. We have a lot of skins. And there's an embedded Python interpreter for the add-ons, plugin scripts. Playback is done through multiple player cores called DVD player, PA player and M player.

M player has been removed. Yeah, yeah, fair enough. And we rely on, well, quite a few open source libraries. There's a little picture here that shows you the open source libraries that we rely on. I think Python and FFmpeg are probably the biggest.

Between 2003 and 2007, Xbox media player was really becoming quite successful on the Xbox. And the Xboxes were also becoming cheaper because Microsoft was evolving and making their own production cheaper.

New Xboxes were becoming cheaper. Hard drives were becoming cheaper. And streaming media was added. In 2007, the Linux port was started, which started in 2007.

It was in May and was already usable in June, which I think is pretty much incredible. Late 2007 Windows port. Early 2008, OS X port. And in 2008, in November, XPMC 8, the first one to use a code name, Atlantis, was released on Linux, OS X and Windows at the same time.

Now, this talk is also about the difficulties you run into running a big development on multiple platforms and growing as an organization.

So what happened between 2008 and 2009 is that we really grew up as an organization. The development team grew, the community grew, and there was a general consensus that we needed to start looking at the future. Well, not we, but the guys back then. We came later.

We had donations in a personal PayPal account. People were starting to wonder what happens if people leave. How are we going to continue this? There were some companies that said, hey, can we fork your code and can we sponsor you? Keep it open, but can we sponsor you? Yeah. So the foundation was born, the XPMC foundation was born.

Nonprofit foundation registered in the US. Lawyer costs originally sponsored by Boxee, who did a commercial port. A little bit difficult to set up because there were no board members initially that were in the US. And it cost an extremely amount of money and time to actually set this up.

Also, when we recently changed our name, we had to, of course, go to parts of this process again. And the timing costs were again significant. There's a lot of effort to becoming a nonprofit foundation.

2009, big chapter when XPMC ARM was added. I'm going to speed it up a little bit because we have to manage slides.

2009, OpenGL ES on a Beagle board. 2011, iOS. 2012, Raspberry Pi. We got a new sponsor, Pivos, which really, really boosted the Android development.

And then in 2013, we had Frodo. We went through Atlantis, Babylon, Camelot, Dharma, Eden, Frodo. We got all the platforms, Android still, a little bit on the rough side. And in 2014, we released the last XPMC version, Gotham, which had the full codebase on all the platforms.

Our latest version, Helix, was released in 2014, in December, and actually yesterday we released 14.1. Which this guy released yesterday without telling me.

So talking about things we grew through, what did we fail on? Dual licensing. Because we didn't sign over the rights of the source to the foundation, we would now have to contact every single developer that has ever contributed if we would want to dual license the code.

You can imagine it's a bit difficult because we're spending a long period. We have 50 something team members and hundreds and hundreds of contributors. We haven't responded to the code over the years. We didn't own our brand from the beginning. We didn't focus on trademarking.

So we basically had the same situation as Mozilla Phoenix, Mozilla Firebird, which then became Firefox. The backend server requested many, many times, should have been there years ago, I guess. Last developer conference, we really made a point of this is the next big thing we should put in.

And a lot of developers are currently contributing on this. No dates, but it's gonna come. Definitely gonna come. Communication. I think this is still a problem. Communication between so many different people from different countries is always a problem. We're trying to do it through the forum, through email, IRC, GitHub.

I think the best thing we do is the yearly developer conference, where we meet with all the developers and get our heads into the same direction. And not being user friendly. It's getting there, but there's always improvement possible.

Information not being organized. I think we're actually working very well on that. The last two years. Some quick stats. 83 team members it says here. Well, I thought it was like 50 something. Still increasing.

Sorry? Yeah, that's about 50. Lines of code. You see our code base going up until something like over 10 million and then coming back down to something like 6 million lines of code. Estimated costs is like 100 million if you take the Kokomo model.

I recently saw developers say, yeah, I can optimize something by scraping 10,000 lines of code, but it will make our project $60,000 less worth. Yeah. Languages used. This is a very hard thing to read from there.

It's C and C++ contributes to over 60, 70%. Then it is XML and Python because of the add-ons. And then you go to like shell script make HTML assembly objective C, but that's all less than a percent. 38 languages in total are used throughout the code base.

Top contributor. I think he's still at the top. I need to update this picture. It's Jay Marshall with over 6,800 commits to the code base.

How do we develop? How much time do I have? Five minutes. How do we develop? Code contributions are done through GitHub pull requests. The code is reviewed by several team members and then build on all platforms in our CI, Jenkins.

When it's tested and reviewed okay, we merge it into master. We daily build every platform. Well, we call them nightlies. They're done in the morning actually. Well, local to the server, they're done in the morning.

They're actually dated like 7 a.m. or 8 a.m. We use merge windows. So there's a there's a merge window for feature pull request at the beginning of the month. And then trivial bug fixes you can merge throughout the month. We usually do alpha alpha beta release candidate release.

But we have been discussing doing faster releases, maybe only doing one alpha. I think in the past we also did several betas sometimes, so that's not happening anymore. We want to release more often with less changes and also less breaking of, for instance, skins and stuff in it.

We use milestones in GitHub to track the progress and only allow API breakage during the alpha window. And the rest beta windows only allow stuff to be altered outside of the API and release candidate windows only allow bug fixes.

So once we go into a release candidate, it's basically just checking for bugs. User estimates by version, I'm going to skip that because it's not up to date anymore. User estimates by country, also going to skip that, not up to date anymore. By platform, that's actually quite interesting. 2.3 million people are using Windows.

2.2 million people are using Android. And only 1.2 million people are using Linux. And as you can see, oh, we actually have 599 people using FreeBSD during the period where we... If you wonder how we get these statistics, the Kodi installations have add-ons which update from our servers.

Some of these add-ons are by design in every single version on every single platform. When we update one of those, everybody will get it. We'll just take the statistics from that one. We did that one time to get these numbers.

Android only has one developer. Fastest growing user base of any platform only has one developer. Are you an Android developer? Do you know Android developers? Please come to us because we have a lot of people and only one person.

Raspberry Pi, OpenALec, I'm going to skip some stuff because we don't have time, I think. I'll just do the future thing. What do we have planned for the future? Binary add-ons. Add-ons are currently only in Python. We have some internal add-ons like PVR that are...

Yeah, no, no, I know you don't know PVR. ...that are written in C and compiled by us. We're looking at the possibility to do more add-on types, binary, and also allow external people to submit code that we will compile into a binary add-on.

Obvious pluses of doing binary add-ons will be improved performance for the add-ons and more possibilities for the add-ons. Better integration with the core stuff you can't do from Python. Media importing is also on the future list.

And content integration, so you get better integration of installed content. For instance, you have a Spotify subscription, you could have a binary Spotify add-on which shows your Spotify music list in playlists right in your music. Instead of going into the add-on and then seeing your playlist, you could have them right in your music browser.

More integration. We're still waiting for that one. The ability to play ROMs from retro games directly as it is a video player. Just press play, it starts playing, you can rewind. Actually works, it's very cool, hasn't been finished, once it's finished it immediately goes in.

Kodi server, headless instance, many people are waiting for this. It's almost done, it will probably come this year. Audio DSP processing add-ons, that's another example of binary add-ons adding more possibilities to the system. I'll leave this and I'll go to questions.

Not a single question. How do you deal with the decoding of DTS and Dolby and these kind of things? Because it's quite difficult with a nice system.

We use FFmpeg. Yes, we use FFmpeg. And we prefer hardware. If we can, we do hardware. But we use the FFmpeg library and we know about issues.

We know it's an issue to do Dolby decoding in software. I think the main thing is that we're not selling our software, so Dolby is okay. Sort of. VLC. We have contact with VLC and we know what they did again.

So it's an option, we might have to take it out at one point. But the best performance anyway is to do passthrough to an AVR, which is my recommended solution anyway. Any other questions?

The question was, because we're a non-profit organization, if we have any problems with software patterns, if we're afraid of... Yeah, because we're in the US. Yes, of course.

Well, we have some legal help and if we get into trouble, we'll have to sort it out. But yeah, you can find demons everywhere. Almost 12 years and counting, but we're still here.

The question was, over time, Kodi can accumulate some stale add-ons or probably thumbnails and stuff like that you're talking about.

And do we deal with cleaning this stuff? Are we planning on dealing with cleaning the craft that you accumulate by running Kodi for a long time? We're not planning to do so. There are some external applications that can clean up your thumbnail caches, for instance.

I do think personally that in time it's probably a good idea if we integrate some of that code that's already available in external applications into our own code. But there's no strict plans to do so at the moment. But feel free to submit your pull request.

Any other questions? Yes? The CEC code.

When I bought it, it was actually empty by the way. So now it is rendered.

Because he will tell you.