We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

The final release of Kodi v18

00:00

Formal Metadata

Title
The final release of Kodi v18
Subtitle
A two year development story
Title of Series
Number of Parts
561
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Kodi v18 has been in development for over two and finally it is released. During this presentation we go through the most important parts that were added or changed and what this actually means for the future. During past two years developers in and outside of the Kodi Team have been steadily refactoring and working on new features that will be included in Kodi v18. Although we initially thought about doing a RERO release it ended up being quite the opposite. In this presentation we will go through the most important parts that are actually included and why it took so long to come to a final release. Additionally we will briefly cover some parts that we already know will go into v19 at the moment we branched of the current v18 release.
Goodness of fitCodeComputing platformCodecData miningRevision controlComputer animationLecture/Conference
ImplementationArchitectureFocus (optics)CodeInclusion mapStatisticsRevision controlCodeAndroid (robot)Product (business)Computer fileFront and back endsLibrary (computing)Streaming mediaPlug-in (computing)WindowData storage deviceStatisticsBinary codeLine (geometry)Web 2.0MereologyCore dumpoutputPasswordPatch (Unix)VideoconferencingCodierung <Programmierung>Content (media)Digital rights managementPoint (geometry)Video gameComputing platformSoftware repositorySoftwareMultiplication signSoftware bugWebsiteEstimatorComputer animationLecture/Conference
VideoconferencingHill differential equationComplete metric spaceoutputGame controlleroutputWindowRevision controlSoftwareDigital rights managementMereologyAsynchronous Transfer ModeComputer fileData storage deviceGame controllerComputing platformInstallation artString (computer science)VideoconferencingCodecQuantum entanglementSoftware developerStreaming mediaCross-platformCodeDefault (computer science)Sheaf (mathematics)Limit (category theory)Beta functionContent (media)Flow separationConfiguration spaceMappingControl flowCore dumpMenu (computing)Bridging (networking)Game theoryPoint (geometry)EmailAndroid (robot)Key (cryptography)WebsiteEmulatorGraphical user interfaceProof theoryPlug-in (computing)Software maintenanceRippingSega Enterprises Ltd.Lecture/Conference
Video game consoleEmulatorCoccinellidaeMenu (computing)outputGame controllerConfiguration spaceComa BerenicesEmulationHuman migrationAndroid (robot)Internet forumEmulatorGame controllerGame theoryMusical ensembleoutputSega Enterprises Ltd.Video gameProper mapFrame problemMultiplication signVolumenvisualisierungPlanningDirection (geometry)Revision controlShader <Informatik>Human migrationProfil (magazine)HypermediaAndroid (robot)Complete metric spaceMoment (mathematics)ArmLibrary (computing)Power (physics)DatabaseData managementBounded variationWindowInstallation artProjective planeCodeUsabilityVideoconferencingConfiguration spaceInheritance (object-oriented programming)Computing platformRadio-frequency identificationMereologyModule (mathematics)Physical system2 (number)Level (video gaming)Repository (publishing)Student's t-testDifferent (Kate Ryan album)Electronic mailing listLipschitz-StetigkeitBitProof theoryComputer fileTotal S.A.Extension (kinesiology)Point (geometry)CodecLine (geometry)Atomic numberNetwork topologyMenu (computing)JSONLecture/Conference
InformationInternet forumWikiProjective planeComputer animationLecture/Conference
Projective planePlastikkarteStreaming mediaWindowPoint (geometry)Kernel (computing)Cycle (graph theory)Configuration spaceDevice driverInterface (computing)Android (robot)Standard deviationWebsiteCodeSoftware developerInstallation artFront and back endsProcess (computing)BitHypermediaPlug-in (computing)Film editingRevision controlComputing platformBounded variationServer (computing)Slide rulePresentation of a groupVideoconferencingMusical ensembleCASE <Informatik>LogicBinary codeMemory cardCodecLecture/Conference
InformationInternet forumPoint cloudPlug-in (computing)Android (robot)Computer animation
Transcript: English(auto-generated)
Okay, so we start again with our 11 o'clock show. So Martin will talk to us about coding, coding version 18, features and improvements. Martin? Okay. Welcome, everyone, for the people that were already here for VLC.
We're kind of in the same boat as VLC. We have a lot of code that no one understands. So they were trying to clean up and we're basically trying to do the same. The same as getting everything working on all platforms with all the new codecs, 3D, HDR stuff, Wayland.
So we're kind of in parallel what VLC is doing, cleaning up our stuff. So since last week, we finally released version 18.
It's about, I guess, a year late. So it doesn't really matter that much. We started in November 2016, during the time that 17 was about to come out. We continued working on 17 with bug fixes. But others were already starting to clean up our code and we finally released on the 29th.
So our goals were improve what we already have. There were not many features we actually wanted to have. And understanding our code, cleaning it up, because it all originated from the original Xbox.
We used about 800 private APIs on Windows, still from the old SDK that kept working. And we should have cleaned that up at some point. So the goal was to break the code to C++11. Some parts were already going to 14 already.
Remove all the old code, obsolete libraries, because we... What's cracking? Not working well. Sorry.
Okay, let's try. We even kept compiling libraries we didn't even use. We removed like 10 libraries. Like, what do we use it for? And actually no one could answer it.
So we just removed it and then everything kept working. I think last week, or some months ago, we even removed another one. So we thought we were done. At least the best part is we don't have to maintain all that stuff anymore. We use FFmpeg for everything, basically.
We only are three patches behind on their 4.04 release. So we tried to keep that up to date as possible. Because in the past we had like 500 patches on a really old library inside of our code.
And we tried to upstream the patches as best as we can. It's not always possible, but we should at least try to do that. This is the biggest part. Binary add-ons. For the people that already know when to code. They know all the add-ons and the plugins, like the skins and the audio and the video.
Well, we now also moved... Basically, most of that was in core that we couldn't rip out. It's now an add-on as well. So we now have some hive decoders for pictures. So basically you go to our repo and you install that.
So it's not compiled in the core. Our core code is becoming much smaller and we just say plug it in. The same for PVR. Those were kind of add-ons already, but they were always shipped with the core code itself.
So now you can just install one frontend for whatever backend you have. And don't have all the other 20 shipped alongside. Input stream. The nicest part about this, we can actually play back DRM protected content. From within code using whatever platform features it supports.
So like on Android, we can do Netflix full 4K. So basically if you go to somewhere on the web, you can find a Netflix plugin.
You install that, you enter your password and username. So it's fully locked down to Netflix itself. But basically you can load your library there, play back any file there and it works. We're still looking into the Atmos part, but 4 full K works on Android.
On other platforms, Windows is not working yet. Linux uses software, so we are kind of limited to 720p. So Android is fully functional for that. Everything DRM protected by Widevine should work.
So if someone writes a plugin for that, it works. So what we did was 3,000 pull requests, 10,000 comments with 36 people. And about 9,000 changed lines.
And user base, we don't really track that. We have some stuff from Play Store, we have something from Windows. We can look at the amount of downloads, but that doesn't really matter for us. Because we just want a nice product. Play Store says 7.8.
Windows says a couple of hundred thousand. And then the rest is from whatever site. And even on Android, we're not an Amazon store. So maybe 25 or more. Rough estimate.
We always plan changes, but we never promise to incorporate them. And the reason is, well, people change interests, they get a life, they get married, they get kids. And then they vanish. So they start to work on something, and then...
So we're never going to say, next year we will do whatever feature, because we don't know. So we only say when it's done, then when it's actually in the core code. And even then, it might be not enabled by default, because we're still not sure if it actually works. The best part is, this is kind of the same talk as last year.
What we said we would do is actually also done. Because we didn't do anything more. And the best part was the Xbox. That caught everyone by surprise. Because you all know, we started on the original Xbox, locked down, then the 360 came along, nothing worked anymore.
So we thought, Xbox will never happen again. And suddenly the UWP platform came along and was like, it's not going to happen again. It's too complicated. And then someone sent an email, I have it running. What? So that was actually in the start of...
On Windows itself, so not on the Xbox itself. But the platform should be similar. So we started in June 2016 with the Centennial Bridge. We still use it today, because UWP has limitations.
No access to local drives and all that. So we push UWP version to Windows Store, and then the higher version with the bridge version on top of that, because you cannot filter easily. So you have to do some tricks to get the correct version rolling out. And December 2016, the initial work actually started to get it running.
And in 2017 we had the first version actually booting up, which was quite amazing. And then half a year later it was actually kind of done, not fully feature complete, but we actually put it out as a beta. I think we are now at 200,000 installs, so it's not so bad.
Some websites actually called us the best game of the year for Xbox. Because there was actually nothing else out there. What else did we do? Video player.
As said, we started out on the Xbox, and it grew and grew and grew. And it wasn't really designed to take on all the other platforms. So we started to improve that code, and it was all entangled. It's like quantum entanglement. Pull one side with code and the other one breaks.
So they now actually started ripping that out, cleaning it up, pulling it apart. And now video player is kind of a thing of its own. But still, weird stuff happens when you change playlist code and then video player starts breaking. So we still want to improve that. As said, a lot of legacy code, not as efficient as it should be.
Just stacking on code and code and code, not platform agnostic. Linux was hacked into Windows sections and all that. So when you actually, maintaining it was so hard.
And the best part of cleaning up your code is it's maintainable. Like JB said, if you don't understand the code, you cannot maintain it anymore. So you need to understand what is actually happening. So by actually cleaning up your code, ripping parts out, you start to understand what is actually happening.
And that's, I think, the best part we learned about that. Just start pulling strings, see what happens. And if you see something happen, actually put it as a comment in the code. So other people don't have to look again what's happening.
So the DRM part was actually one of the biggest things we wanted to have. So it's using a special API we made, InputStream. So we basically made an add-on that uses that API that actually tells the player, play this. And then the player handles everything else.
And on Android we then tell MediaCodec, play this content. We don't know what it is, so it's still entirely DRM protected. But play this. We don't want to know what it is. It's also more future proof now. With HDR and whatever, 8K, 12K, 20K.
And the future is also, we wanted a headless mode, so the player was fully entangled with the rest of the code. So you couldn't really play something in the background without the GUI doing weird stuff. I could show screenshots, but there's no point.
It's still just a player that plays video. Input handling. And with input handling we actually mean controllers. Not video input, audio input, but actually controller plug-in. We all know the problem is if you have a NES controller or a Sega controller, you plug it in, you have to configure all the keys again.
Not anymore. You just plug it in and it works. There's also a configuration menu, so you can actually change the button mapping. But plug in any controller and it will always work. And this was actually part of RetroPlayer. It's been five years in the making.
So one of our developers is actually a mechanical engineer who got bored and actually started coding on RetroPlayer. And it took him four years, several attempts to get it right. And what basically is, everyone I guess knows RetroPie and whatever other software there is.
But basically this runs in the Kodi GUI. You open any ROM file and it will actually automatically select the ROM, the emulator you want. Combining with input handling, any controller you want.
So you can play NES games with a Sega controller. No problem at all. So his goal was, he loved playing the old games. And back then there was not really anything that was user friendly. You had to do weird stuff to get an emulator running.
So that was his main goal, getting this done. Also the controller part was a real hassle. And some stuff is still future work. But one of the best parts was actually to save, pause and rewind and play again. Because everyone knows that you die or you jump in a pit and you have to play all over again.
You can just rewind while you're left off. So go back a couple of seconds and then start playing again from the moment you want it. So this is a part of how the menu looks. So you can actually just pause the game, maybe you can close it down.
I'm not sure if it's actually saved or not. So it's actually saved while you're left off. So you can actually resume at any point in time. And how the rewind actually works. Because it's actually a video frame. As he uses it, you can actually just rewind like any video and then start playing.
Hit play again and then start controlling the game again. He had that working like three or four years ago. And we had like a tiny kid coming in. That's all he did. Just die and rewind and die rewind. It's kind of a cheater, but why not?
We also had some shaders on top of it. So you can actually have... The emulator is looking like an old CRT monitor again. For people who actually want that. So it tries to upscale as best as it can. And if you want you can make it look like an old CRT monitor again.
To have that old feeling on your 4K TV. This is the controller configuration. So basically all the controllers are also add-ons. So if you say you have this controller. You can install that add-on, that profile basically.
And you can then change it to your liking. If you want A and B switched. No problem. And it will actually save it and plug in any controller. And the rest of what was done. Android was always a hassle. We started working on Android in version 2.4.
I think. Android 2.4. There was no media codec back then. So back then we wrote our own player. Later came along with LIP stage fright. And then it was still a mess. Every manufacturer did their own thing.
Playback was a hassle. And then we started working with Google actually to help improve media codec. Like we need this, we need that audio. Why don't you have this codec? Why do you have all these stupid APIs? Just give it the IEC input. We'll handle all the packaging ourselves.
So we don't have to deal with your timings. We can do the timing internally. Windows now has the 64-bit version. So that was something long overdue. And the problem with that was we used so many third-party libraries. We had to compile them all as 64-bit.
Not a problem in itself. But there was no 64-bit code in those modules. So we actually had to rewrite parts of those modules to be compiled in 64-bit as well. And we tried to remove modules we actually didn't need anymore by replacing them with something that works.
So that was basically 64-bit Windows. It's a bit faster. People screamed like, it's much faster, we want Windows 64-bit, must happen. Well, we actually tested it and it wasn't that much faster.
It's only faster if you do 4K. Back then it wasn't really that obvious yet. Wayland support was added again. Five years ago we had a GSOC student who did the Wayland stuff initially. I think he lost interest or there wasn't really big enough support around to do Wayland properly.
So it kind of decayed and we actually ripped it out again. And then we had another GSOC student, Philip, who redid all that part again. Then for Linux we also have direct render management.
That's especially for the low power platforms. Improves playback a lot. And we now use CMake as our build system. And that means that it's actually much more easy to maintain. Because in the past we have like five build systems for five different platforms.
And now we have one. Add some lines, add a new file, need to compile, done. Works. Took a lot of time, it's still dark magic if you look into it. But we have some gurus that actually know what's happening. And then the most important part was binary add-on repository for almost all platforms.
As I said, we already had binary add-ons to some extent, but we had no way of distributing them. So we actually had to package them into the installer itself. Because there was no real way to make that easily installable afterwards. Because you have Windows, you have Linux, OS X, iOS, Android.
But we wanted to push a new update when we fixed something. And it was still not possible, because we had to take into account all the platforms, all the variations. And it actually took us like two years to figure out how to properly do this. Like if we compile one, it's all one code.
If we compile it, it needs to be distributed to like five, six different versions. Taking into account all the 64-bit, 32-bit, ARM. And now in 18 we actually finally did that. So our installer went from 70, 80 megabytes to 35. Just ripping out all that stuff.
And you install it basically when you want it. We have dashboard, PVR improvements, music library. Is it really improved? Bluer is better. And basically in two years the list is so huge. It's so much to even talk about.
And on release day, sadly our biggest fear was something will break, which we never thought of. And that was for UWP, the migration. Because Windows does different things when you do that. We have a roaming profile and the other one is not.
And that was it. And for version 19 we have Python 3 coming. And we don't really have anything planned. Because we are kind of feature complete. So we're hoping that our GSoC project will bring up some amazing things.
One thing that's also coming up is the database layer. It's a total mess. It's holding us back so much. Because anything you do always goes through our file handler. So anything you do goes through that.
And it's a big bottleneck. So we hope to rip that out as much as we can. And profiles. Like have a kid profile and a parent profile or different names. So those are the biggest features we want to work on. But we don't have to promise anything.
Because someone needs to be interested in actually doing that. And we always hope that the common public will show interest in picking that up. And we will always try to help them. Because it's really amazing to get through. We had our retro player guy looking in it and he got scared.
And for the rest we also had to maintain all the rest of our infrastructure. Which is so much. And your own personal life. And that is I think the biggest problem for everyone. You want to work on something but you still have a life at work.
That was it. We have a few minutes for questions or amazing ideas for your roadmap. We're always looking for GSoC projects. So we have a wiki that lists the GSoC projects.
But we can always have some great ideas. So yeah, you said that you ripped out the decoder add-ons and everything. Will you help the users so that they will autoload or tell them that they're missing an add-on?
It actually automatically does that. Okay, so you don't have to look through it and figure out that oh I need this binary add-on. So like if you install the Netflix add-on it will automatically install the DRM plug-in that automatically pulls down whatever you need. So it's actually plug-and-play.
So all you need to do is enter your username. And then the next one. I saw something about the Nvidia cards and the new version and not supported. What's that about? I'm not really the technical guy about... It was not supposed to be supported with GBM back-end or something like that?
Filip, do you know anything about that?
Okay. So the deal with Nvidia is that the binary drivers do not support the standard EGL interface that all the MISA and other drivers support. They use EGL streams which is a different API and we won't implement that. It's just the same with a lot of for example Wayland compositors. Like you cannot run KDE on Nvidia binary drivers is the same reason.
So our goal basically is to... Not with the GBM back-end, no. With Navo? With Navo you can run, yeah. So our goal is to don't do every edge case. With Android we had a lot of problems with the video playback and we actually ripped out the biggest manufacturers like Amlogic.
We basically said, hey, if you want us to run on your platform, do your job. Write a proper driver. So we then ripped out our Amlogic code and said we support MediaCodec.
This is the official API. If you do not support it, tough luck. And that actually got the ball rolling that I actually started improving. After that we actually got talking with Amlogic to actually improve the Linux kernel. So like the project like LibreELEC didn't have to do all the hassle with all the variations again.
So they actually tried to upstream their drivers as much as possible to the Linux kernel. So we don't have to go through all the edge cases, loopholes, private APIs. It will break at some point and someone needs to maintain it and we basically want to use the API as designed.
Not anything else. So we have a lot of users like... You mentioned on the slides about the release date that you feared some of the SMB problems.
Did they materialize? Yes. Can you tell a bit more about that? At some point during the release cycle I think Windows disabled SMB 1. And for some reason people use Windows 7 as a media server. So we have some configuration in the code.
I think LibreELEC has it better on some platforms or not. And during the last year we had a lot of non-working installs because of the SMB problems. It suddenly starts working. You have SMB 1 on your server and we only want 2 and 3 but you can override it again.
It's always a hassle. On Android SMB 2 doesn't really work because then on the Android platform stuff needs to be done as well. And we basically have not enough developers to actually support most of it.
So we actually now said whatever we've been working on this for two years, cut the date and release it and we'll see what happens. Thank you, Martin. Remember you can rate the presentation on the FOSDEM website. Thank you.
And thank you for 4K playback on Android for WIDEVINET 1 for Linux.