JetPack 4.2.1 nvjpeg leaking

Hi all

I am using unmodified sample 12_camera_v4l2_cuda on TX2 with USB cameras (Have tried multiple different cameras). Command line is “./camera_v4l2_cuda -d /dev/video1 -f MJPEG -s 1280x720 -n 30”

After approx 15 seconds it is crashing with error:
NvRmChannelSubmit: NvError_IoctFailed with errorcode 22… blah blah blah…

By changing command line to -s320x240 it runs for longer, a couple of minutes, but then the same crash.

By commenting the following line out, it will run forever without crashing.
if (ctx->jpegdec->decodeToFd(fd, ctx->cameras[i].g_buff[v4l2_buf.index].start, bytesused, pixfmt, width, height) < 0) …

If I run the same sample on my Jetson Nano then there is no problem and everything runs forever.

So it appears there is a problem in the or the application where the fd buffer is not being freed.

Is there any solution to this problem? I see in a different thread that there was a known problem on nano r32.1 in libnvjpeg and a new version was referenced in that thread. Is there a new version for the TX2 JetPack 4.2.1??


Help please anyone…


For more information, unmodified sample 12_camera_v4l2_cuda runs well on r32.2/Nano but hits memory leak on r32.2/TX2?

Thanks DaneLLL but I’m not quite sure what you’re asking sorry but…

My Nano has r32.1.1 and the sample is running ok. I was just referring to that other post because it sounds similar.

My TX2 has r32.2.0 and the sample crashes.


From your previous comment, it looks like the same r32.2 works on Nano but fails on TX2, implying it might be a hardware issue. It is clear now Nano and TX2 are flashed with different software releases.

We will check and update.

Any update on this one?

Please try attachment. (146 KB)

Yay. This is has certainly fixed the problem.

Thank you!

Attachment in #6 is a temporary solution and shall work fine in non-DeepStream SDK usecases.

If you need to run JPEG decoding in both tegra_multimedia_api and DeepStream SDK 4.0, please use this attachment. It is built with the fix in next r32.3. (146 KB)

the attachment you shared gives an access denied error