Skip to main content
Assume your model artifact now runs on Qualcomm Dragonwing. That is necessary, but it is rarely the whole product. Most Jetson edge AI products are applications wrapped around a model:
On Jetson, that application might be DeepStream, CUDA kernels, TensorRT, OpenCV, and a Docker image pinned to JetPack. On Qualcomm, the equivalent product path is usually built around Qualcomm Intelligent Multimedia SDK, GStreamer, QNN/QAIRT, LiteRT/QNN delegate, camera ISP, Adreno GPU, video encode/decode, and HTP/NPU. The key migration idea:
Port the pipeline, not just the neural net.
In the running case study, this is where the YOLO context binary stops being a standalone model artifact and becomes part of the live camera, metadata, overlay, encode, and health-monitoring application. Before you start:

​
Why a model-only port is not enough

A model can pass every tensor-level validation gate and still fail inside the product. Common causes:
That is why our best practice is to freeze the application contract before optimizing individual pieces. For a vision application, write down:
Then port one stage at a time.

​
The DeepStream-to-IM SDK map

A practical mapping looks like this: This is not a one-to-one replacement for every property. It is a starting map so the team can identify which code disappears, which config moves, and which behavior needs a new validation check. Current IM SDK examples use qticamsrc; older examples may show qtiqmmfsrc. Check gst-inspect-1.0 on your image before copying a pipeline.

​
Start with a file, then move to a camera

The cheapest path is to remove live-camera variability at first. Use the same input video on Jetson and Qualcomm:
Once the file path matches, move to the real camera:
This makes failures cheaper to classify. If the file path matches and the camera path does not, the bug is likely capture format, timestamping, frame rate, exposure, buffer memory, or color conversion. If both fail, look earlier at model export, preprocessing, or postprocessing. Before blaming the model, check the camera path:

​
A minimal Qualcomm camera AI pipeline

A simplified IM SDK-style pipeline for a live camera detector looks like this. It follows the current IM SDK object-detection examples, but exact properties are model- and release-specific; verify them with gst-inspect-1.0 qticamsrc qtiqmmfsrc qtimlqnn qtimlpostprocess on your image. On the IQ-9075 lab image used for this series, qtiqmmfsrc is present and qticamsrc is not, so treat the source element as image-dependent:
For LiteRT models, the inference stage can use the QNN delegate path instead:
The exact pipeline depends on your model, sensor, display, and output requirement. The pattern is the point:

​
Keep preprocessing boring

Most migration bugs hide in preprocessing. For every model, record these fields in a model-side config file:
Then make Jetson and Qualcomm read the same contract. If the old app has CUDA preprocessing, isolate its behavior before replacing it:
A one-line color swap can cost more accuracy than the runtime port.

​
Treat postprocessing as application code

For YOLO-style models, keeping NMS outside the graph is often the simplest migration path. Postprocessing usually includes:
Keep this code explicit and shared when possible. If Jetson has Python postprocessing and Qualcomm has C++/GStreamer postprocessing, build a small golden-output test from saved tensors. The smallest useful test:
That catches layout and threshold drift before you blame the accelerator.

​
Metadata replaces glue code

DeepStream applications often depend on metadata attached to buffers. IM SDK has the same broad idea: inference produces tensors, postprocessing converts tensors into metadata or masks, and downstream elements use that metadata for tracking, overlay, streaming, or another inference stage. A common pattern:
This keeps video buffers and inference metadata aligned without turning the app into a pile of custom glue.

​
Multi-stream is where Qualcomm can shine

Jetson apps often rely on one GPU for inference, CUDA preprocessing, display, and encode. Qualcomm Dragonwing devices have a more heterogeneous pipeline: camera ISP, HTP/NPU, Adreno GPU, video encode/decode, CPU, and DSP resources can each carry different pieces. That does not make performance automatic. It gives you more placement choices. For multi-stream products, measure:
The best pipeline is often the one that avoids unnecessary copies, not the one with the fastest single model invocation. Use symptoms to find the bottleneck:

​
Deployment bundle

A model-only bundle is too small for a real multimedia app. Bundle the contract around the model:
The manifest should record:
That turns “it worked on my EVK” into something another engineer can reproduce.

​
Validation checklist

Before calling the app migrated, make these checks boring:
The first demo can be a one-line gst-launch-1.0 command. The production version should still keep the same pipeline shape, just with better configuration, logging, service management, and update behavior.

​
Takeaway

A successful Jetson-to-Qualcomm migration is not “TensorRT model becomes QNN model.” It is:
Keep the model contract explicit, validate preprocessing and postprocessing separately, start with file input, then move to the camera. The less custom glue you carry over, the easier the product is to debug when it runs all day.