Overview
Containers are lightweight, isolated environments that package everything needed to run an application — code, dependencies, and system libraries — so it behaves consistently across platforms. Advantages of containerization include:- Consistency: Containers provide a consistent environment across multiple platforms and operating systems. Developers can create images that transform into containers when deployed, ensuring uniformity regardless of the underlying infrastructure.
- Automation: Containerization supports automated tasks. Developers can schedule actions without manual intervention, reducing repetitive work.
- Stability: Containers are based on Linux, with the Linux kernel present in every container. This stability extends to systems and devices, including when containers run on macOS or Windows.
- Space efficiency: Unlike traditional virtual machines, which consume significant server space and memory, containers include only application code and dependencies. They can run entirely in the cloud and minimize resource requirements.

IMSDK in Docker
IMSDK in a Docker container means the full Qualcomm multimedia and AI software stack is delivered as containerized environments instead of being manually installed directly on a host or target system. In practice, a build container compiles and assembles all required components, including cross-compiled artifacts for Qualcomm ARM64 targets. The build then produces a deploy container that contains only the runtime pieces needed on the device. Key benefits of this approach:- Reproducible builds: Use the same toolchain, package versions, and scripts across developers and CI. Reduces “works on my machine” failures.
- Build and runtime separation: Use a heavy build image to compile artifacts and a lean deploy image that contains only runtime essentials.
- Efficient cross-compilation: Build on the host and target ARM64 Qualcomm devices reliably, faster than compiling directly on the target.
- Secure runtime posture: Run as a non-root user by default, avoid broad privileged-container dependencies, and use CDI-based explicit hardware passthrough for GPU, camera, and media devices.
- Operational consistency: Use versioned images that are testable, promotable, and rollback-friendly, with a predictable deployment flow using environment and CDI configuration on the target.
Features
- Debian (Trixie) base: Built on Debian Trixie for a streamlined and lightweight foundation.
- No platform dependencies: Entirely self-sufficient — no eSDK or host platform content required to build or deploy.
- Self-contained dependencies: All necessary dependencies are installed directly inside the container, minimizing host-container compatibility issues and simplifying deployment on edge devices.
- GStreamer 1.26: Includes GStreamer 1.26 with the latest
gst-qti-oss-patchesfor optimized performance on Qualcomm platforms. - Broad target support: Validated across QLI 2.x, Ubuntu Server, and Ubuntu Desktop. Supports QCS615, QCS6490, IQ8, and IQ9.
Versions
| Version | Status |
|---|---|
| 2.0.1 | Latest |
Architecture
The following diagram explains the build and deployment flow of the IMSDK Docker image.
- The host machine runs a development container that compiles all IMSDK sources and dependencies into Debian artifacts.
- The generated artifacts are transferred to a Debian-based deploy container with CDI-managed hardware access that runs on the Qualcomm device.
Quick Start Guide
Before getting started, ensure the device is set up by following the Installation guide.
Download configuration files
Before setting up the device, download the CDI and environment files for the target chipset and OS. The CDI JSON file provides platform-specific device mountings; the environment file sets the required variables inside the container. Select your chipset to download the corresponding files:- QCS6490
- QCS8275
- QCS9075
- QCS615
| Target OS | CDI file | Environment file |
|---|---|---|
| QLI 2.x | qcs6490_qli_2x_qimsdk.json | qcs6490_qli_2x_qimsdk.env |
| Ubuntu Server | qcs6490_ubuntu_server_qimsdk.json | qcs6490_ubuntu_server_qimsdk.env |
| Ubuntu Desktop | qcs6490_ubuntu_desktop_qimsdk.json | qcs6490_ubuntu_desktop_qimsdk.env |
Set up and run on the device
Run the container
Gstreamer Python sample applications are not supported in this QIMSDK container.
Build an IMSDK container
All steps in this section are performed on a Ubuntu 22.04 or 24.04 machine which can be x86 or ARM64.
Prerequisites
Ubuntu packages
Ubuntu packages
Install prerequisite packages on the host (one time only).
- ARM64
- x86
File watcher limits
File watcher limits
Increase the maximum user watches and instances on the host to prevent this error during development:Add these lines to Save the file and reboot the host system.
/etc/sysctl.conf:Swap image
Swap image
To build Docker image files, the host system requires at least 64 GB of RAM and a swap image of at least half the available RAM plus a small reserve.For example, with 64 GB of RAM, the recommended swap size is at least 32 GB. With an 8 GB reserve, total RAM + swap + reserved memory is 104 GB.Check whether swap is enabled:If swap is missing or too small, create a new swap file:Edit Update GRUB:Edit Save and close all opened system files, then reboot the host system.After rebooting, verify the swap image matches the expected size:
/etc/default/grub and set:/etc/fstab and add this line at the end of the file:Configure Docker
Configure Docker
Docker must be configured on the host system once before building images.
Remove old versions
Remove old versions
Remove old Docker Desktop versions if present:
Set up the Docker repository
Set up the Docker repository
Install repository dependencies:Create the Docker keyring directory:Add the Docker GPG key:Add the Docker repository:
Install Docker Engine
Install Docker Engine
Add user to the Docker group
Add user to the Docker group
Add the user to the Docker group to run Docker commands without
sudo:Until the host is rebooted, run
newgrp docker in every newly opened terminal.Add a registry mirror (optional)
Add a registry mirror (optional)
Add the registry mirror configuration to Restart Docker:
/etc/docker/daemon.json:Configure proxy (optional)
Configure proxy (optional)
If network downloads require a proxy, add the proxy configuration to the Docker daemon.Add the proxy configuration to Restart Docker:Set proxy environment variables before invoking Docker build commands:This ensures that both the Docker daemon and build processes use the same proxy settings as the host system.
/etc/docker/daemon.json:Until the host is rebooted, run
newgrp docker in every newly opened terminal.Test the Docker setup (optional)
Test the Docker setup (optional)
Run the Docker hello-world container:
Move the Docker directory (optional)
Move the Docker directory (optional)
If the build image script fails with a Verify that no Docker process is running:Check the Docker directory structure:Back up the current Docker directory:Move the Docker directory to the new partition:Create a symlink to the Docker directory in the new partition:Verify that the Docker directory structure is unchanged:Start Docker:List container names:Start a listed container:
No space left on device error, move the Docker directory to /local/mnt.Stop Docker:Configure system memory
Configure system memory
Check that there are no active cgroup CPU and memory utilization restrictions on the host. The Docker service cgroup memory configuration entries should have
max set as the value.Tune VM settings (optional)
Tune VM settings (optional)
If the host system has 64 GB RAM or less, tune system VM page swap and dentry and inode cache reclaim behavior.
vm.swappinessHigher values cause more aggressive application memory page swapping; lower values favor keeping pages in memory longer. The default is usually 60 on recent Ubuntu and Debian versions, which may not fit the Docker build environment on systems with low available RAM. A value of 10 is recommended.vm.vfs_cache_pressureIntermittent high VFS pressure can result from creating many small temporary files during package installation, causing the OS to prematurely swap memory pages associated with cached dentries and inodes. The default is usually 100. Setting it to 400 relaxes cache management by freeing cached pages earlier, reducing the chance of running out of memory during high multi-threaded load.vm.min_free_kbytesIn heavy multi-stage Docker builds with many buildx threads, the host OS can exhaust available RAM quickly. The mandatory VM free memory watermark is controlled by vm.min_free_kbytes. Too low risks deadlocks under load; too high causes premature OOM kills. A value of 262144 KB better balances free memory under excessive load.Edit /etc/sysctl.conf and add:Build steps
Build the container
Build For example:
qimsdk_deploy_arm64, which contains the minimal set of runtime binaries needed to execute GStreamer use cases:If
QIMSDK_ARG_QNP_VERSION is not provided, the QNN and SNPE plugins are disabled in the image.See qimsdk-debian/README.md for more information about the Docker image composition and workflow.
Copy and load the image on the device
Copy the tar file to the device:Load the image on the device:
On a QLI device
$HOME is /root; on a Ubuntu device it is /home/ubuntu.Run the container on the device
With the image copied to the device, follow the Set up and run on the device steps to configure CDI and start the container.
Install additional packages inside the container
Use this procedure to install packages into an already runningqimsdk-debian deploy container. The container must have been started with the --net host option. The following steps use Python as an example.
After setup is complete, Python examples can be run from each new shell executed as the
qimsdk user:
qimsdk user inside the container:
