InputStream Adaptive is the demuxer that lets Kodi play segmented bitrate streams

It is a demuxer, not a player, and that distinction drives everything

The scope is stated in one sentence in the documentation, and it is worth reading carefully because it defines what the project is for. This is a Kodi input stream add-on which acts as a demuxer for segmented, multi-bitrate internet streams, and the most common streaming protocols such as MPEG-DASH, HLS and Microsoft Smooth Streaming are supported. A demuxer sits between a manifest and the decoder. The server publishes a manifest describing a set of variant streams at different bitrates and a set of media segments; the demuxer reads that manifest, chooses or lets the client choose a bitrate, requests the segments, and hands a continuous elementary stream to the player. Kodi provides the player, the UI and the library, and this add-on provides the part that turns a manifest into something decodable. That is why the project has no playback interface of its own and why almost everything a user sees comes from elsewhere.

Enabling it means setting ListItem properties, not installing a player

The integration step is where most add-on developers will spend their first hour, and the documentation is explicit about it. To enable InputStream playback via your video add-on, you must first configure the ListItem properties appropriately, which is Kodi's own mechanism for attaching a stream handler to a media item before it is played. The documentation also offers a shortcut for test purposes: you can create STRM files with URLs and playback parameters to instruct Kodi to use this InputStream add-on, which is a fast way to confirm that a manifest parses before you wire it into your own add-on. The detailed instructions for integration, building and testing live in the project wiki rather than in the readme, and the documentation asks you to refer to those wiki pages. The project page is a summary and a pointer, and the wiki is the manual.

DRM works, but the CDM module has to come from the platform

The DRM story is where the platform boundaries show up, and the documentation is careful about it. The add-on also has support for DRM protected streams, such as Google Widevine, Microsoft PlayReady and others, however some are only available on specific operating systems. For Google Widevine DRM on non-Android systems, the installation of the Widevine CDM module library is required, and that module is not included with this add-on. That is a significant constraint rather than a footnote. A developer on a desktop Kodi build cannot assume the DRM path will work without sourcing a CDM module separately, and the availability of a given DRM system depends on what the host operating system provides. The add-on supports the mechanism and the integration; the licence-decryption module comes from outside it, which is the only arrangement that makes sense for a component that must work across operating systems.

Threads and segment memory are the operational constraint

The notes section gives the one performance figure in the documentation and it is worth understanding rather than quoting. This addon uses threads to download segments, and the memory consumption is the sum of a single segment from each stream currently playing. Referring to known streams, the documentation puts it at less than 10MB for 720p videos. The design implication is that memory scales with the number of concurrent streams rather than with the bitrate of one, since each playing stream holds roughly one segment in flight at a time. That is the trade the threaded design buys: several variant streams can be fetched in parallel, which matters for adaptive switching because a stream that cannot fetch the next segment quickly cannot switch up in time to avoid a stall. The number of threads is not documented here, so the practical limit on how many variants you fetch concurrently is a question the wiki has to answer rather than the readme.

The WIP status wiki exists because the feature set is still moving

The project is candid about its own state, which is unusual and useful. There are many features that may currently be partially functional or not implemented, and the documentation suggests you open a specific WIP status wiki page to better understand the current status of add-on development. A separate note frames the project as work in progress, and the linked page is titled Add-on WIP status. This matters for an adopter more than a feature list does. An input stream add-on that silently mishandles a manifest type will not fail loudly, it will produce a stream that stalls or picks the wrong bitrate, and the person watching does not know the add-on is at fault. The existence of a status page is a signal that you should check it for the specific manifest types you depend on rather than assuming parity with the protocol.

The build is CMake with vendored dependencies and a Jenkins pipeline

The repository layout shows this is a native C++ add-on with a conventional CMake build. At the root there is a `CMakeLists.txt` and a set of Find modules for the dependencies: `FindBento4.cmake`, `FindGtest.cmake`, `FindLibAndroidJNI.cmake`, `FindNlohmannJSON.cmake` and `Findpugixml.cmake`, plus a `Helpers.cmake` for shared build logic. The source lives in `src/`, the add-on itself in `inputstream.adaptive/`, vendored libraries in `lib/` and `depends/`, and there is a `plugin.video.isasamples/` directory that holds sample video add-ons for testing. The continuous integration is spread across several systems, with an Azure Pipelines build badge, a GitHub Actions build and run tests workflow, a Jenkinsfile and a badge pointing at the Kodi Jenkins server, and an appveyor configuration. Bilingual release naming is visible in the tag list, with 22.3.23-Piers and 22.3.22-Piers on the Piers branch alongside 21.5.25-Omega, and the default branch of the repository is Piers.

What InputStream Adaptive is not, and what to use instead

Two boundaries are worth stating. The first is that this is an add-on and not an application. If you want an end-user media player with a library, a remote control and a recommendation engine, this is the wrong project, because it never draws a frame. The second is that it is one of several ways to get adaptive streaming into Kodi, and the alternative approaches differ in where the complexity lives. A pure Python add-on using the `requests` library and a manifest parser can handle simple HLS without any native code, which is easier to build, easier to review and trivially portable, at the cost of handling no DRM and being slower under segment churn. A media framework like libVLC or mpv embedded as a player sidesteps the manifest problem entirely by taking over playback, which removes the Kodi integration entirely and with it any chance of the video appearing inside your add-on's own UI. The difference in approach is where the demuxing responsibility lives: InputStream Adaptive keeps it in a native C++ component under Kodi's input stream interface, so your add-on keeps control of the interface while taking on the burden of a native dependency chain, Bento4 among them.

Editorial conclusion

InputStream Adaptive is worth adopting if you maintain a Kodi video add-on whose sources are segmented adaptive streams, because it gives you a demuxer for MPEG-DASH, HLS and Microsoft Smooth Streaming plus a path to DRM that a plain Kodi build does not offer, and because the add-on ships a plugin.video.isasamples directory so you can test against real manifests. It is a poor fit if you are building an end-user application rather than a Kodi add-on, since the value is entirely in how it plugs into Kodi's input stream interface, and a poor fit if you need a stable feature set, because the project itself points at a WIP status wiki and says that many features may currently be partially functional or not implemented. Before you depend on it, read the Add-on WIP status wiki page for the specific manifest types you need, and check whether your target platform can actually provide the CDM module, since the Widevine CDM library is not included with the add-on. The last push to the repository was on 2026-10-15, with release 22.3.23-Piers published on 2026-10-10.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. xbmc/inputstream.adaptive on GitHub