Nvimgcodec produces status code 65535

I have an application that works fine on the Orin Nano devkit. I am now trying to copy the binary to my production system. I installed cuda compat 12-6 and the nvimgcodec libraries from /opt/nvidia to the new system. The binary runs, and some functionality seems to be running fine, but the JPEG encoding of images is not working. I run nvimgcodecFutureGetProcessingStatus(encode_future, &encode_status, &status_size);, and the encode_status equals 65535, which is defined in the library as NVIMGCODEC_STATUS_ENUM_FORCE_INT, so I don’t think this is actually reporting me a specific error. Any ideas how I can debug this? Would there be a more proper way for me to install the nvimgcodec library in this production system without requiring me to build anything there?

Hi nicolau2,

65535 is not a meaningful processing status by itself, it is basically a sentinel / “catch all” value in the enum, so you are right that it is not telling you what is wrong. The useful information is usually

  1. the return value of each nvimgcodec* API call, and

  2. whether the nvImageCodec plugins (nvjpeg_ext, etc) were actually found and loaded on the target system.

Given that you copied only files from /opt/nvidia, my first suspicion is a partial or mismatched installation on the production device.

A few concrete things to check.

  1. Verify all API return codes

Make sure you check the nvimgcodecStatus_t returned from every call you use, especially:

  • nvimgcodecInstanceCreate

  • nvimgcodecEncoderCreate

  • nvimgcodecEncoderEncode

  • nvimgcodecFutureGetProcessingStatus

Every one of those should return NVIMGCODEC_STATUS_SUCCESS, otherwise the encode_future and encode_status are not guaranteed to be valid. The documentation explicitly says that results are only valid when the API returns SUCCESS. NVIDIA Docs

If any call before FutureGetProcessingStatus returns something else (for example NVIMGCODEC_STATUS_MISSED_DEPENDENCIES or NVIMGCODEC_STATUS_EXECUTION_FAILED), that will usually point directly at the root cause.

  1. Turn on the debug

When you create the instance, set:

  • instance_create_info.load_builtin_modules = 1

  • instance_create_info.load_extension_modules = 1

  • instance_create_info.create_debug_messenger = 1

as shown in the C samples. NVIDIA Docs

With the debug enabled, the library will print more detailed error messages to stderr (for example “failed to load nvjpeg_ext”, “missing dependency”, “unsupported codec” etc). That is by far the easiest way to see what is wrong on the production system.

  1. Make sure the plugins and their deps are actually installed

On the devkit, nvImageCodec is typically installed together with its extensions and dependencies and lives under something like:

  • /opt/nvidia/nvimgcodec_cuda12/lib64

  • /opt/nvidia/nvimgcodec_cuda12/extensions

The extensions directory contains nvjpeg_ext, nvjpeg2k_ext, nvbmp_ext, etc, which are what actually provide JPEG encode/decode functionality. GitHub

If on the production device you only copied libnvimgcodec.so or only a subset of that directory, the encoder may be created but finds no backends able to handle JPEG. In that situation the encode will fail and the status you read will not be a clean NVIMGCODEC_PROCESSING_STATUS_SUCCESS.

You have two supported ways to install nvImageCodec on the production system without building anything there.

Option A: use the official wheel (recommended)

On Jetson / Tegra with CUDA 12, the docs recommend:

  • pip install nvidia-nvimgcodec-tegra-cu12[all] GitHub

This pulls in nvImageCodec itself plus nvjpeg, nvjpeg2k, nvtiff, etc, and puts everything where nvImageCodec expects it, including the extensions directory. No manual building is needed.

Option B: copy the full nvImageCodec installation

If you built or installed nvImageCodec into /opt/nvidia on the devkit using the standard instructions, you can:

  • copy the whole /opt/nvidia/nvimgcodec_cuda<major_cuda_ver> directory to the same path on the production system, preserving the lib64 and extensions subdirectories

  • export LD_LIBRARY_PATH=/opt/nvidia/nvimgcodec_cuda12/lib64:$LD_LIBRARY_PATH so the runtime can find libnvimgcodec.so GitHub

Simply copying a couple of .so files from /opt/nvidia without the full tree and without adjusting LD_LIBRARY_PATH usually results in “no backend found” type failures.

  1. Confirm CUDA and driver compatibility

nvImageCodec requires:

  • CUDA Toolkit >= 11.8

  • For Jetson, CUDA Toolkit >= 12.0 on Ubuntu 22.04

Installing only cuda-compat gives you driver shims, but not the full CUDA runtime or libraries like nvjpeg/nvjpeg2k. Make sure the production image has the same CUDA major version as the devkit (or at least one that is supported by the nvimgcodec build you are using).

  1. Check what processing status you actually get

Once you have a proper install:

  • encode_status should be NVIMGCODEC_PROCESSING_STATUS_SUCCESS, as shown in the C API samples. NVIDIA Docs

  • If you still get a nonzero value, print it and also dump the debug output. Often you will see something like “codec unsupported” or “missed dependencies”, which again points back to missing plugins or libraries.

Regards,

Embedded Software Engineer
RidgeRun | https://www.ridgerun.com/

Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com/

Hi frander.diaz.

Thanks for sharing all this information. I still didn’t check everything, but I tried looking at the return values from nvimgcodecInstanceCreate, nvimgcodecImageCreate., nvimgcodecEncoderCreate and nvimgcodecEncoderEncode, all of them return 0 (success). The installation also includes the extensions, not just the shared library. I’ll try to reinstall and ensure the path is correct later.

I tried removing the library I copied, and installed via pip this time. Now I’m getting error code 8 at nvimgcodecImageCreate, and a segfault… `NVIMGCODEC_STATUS_INTERNAL_ERROR`.

What’s a simple way to print any further debug messages?

More updates: I created a simpler example code, cross-compiled, and while it fails in the production board, it does run successfully in the devkit, although then I need to set LD_LIBRARY_PATH.