How to handle corrupt JPEG frames without segfaulting

Hello, I am developing a solution which involves capturing jpeg frames from a PoE camera and decoding them on an AGX Orin which runs Jetpack 5.1.1. However, there is no a guarantee that all the jpeg frames are well-formed due to networking reliability and when decodeToFd parses a malformed frame it crashes the whole program.

Here it is a snippet of the core dump.

#0  0x0000ffff54ca58ec in NvVideoJPEGDecoderPinYUVSurface () at /usr/lib/aarch64-linux-gnu/tegra/
#1  0x0000ffff5d7efa74 in NvMediaIJPDRenderYUV () at /usr/lib/aarch64-linux-gnu/tegra/
#2  0x0000ffff84344780 in jpegTegraDecoderRender () at /usr/lib/aarch64-linux-gnu/tegra/
#3  0x0000ffff8431e948 in jpeg_read_raw_data () at /usr/lib/aarch64-linux-gnu/tegra/
#4  0x0000aaaada78f3dc in NvJPEGDecoder::decodeToFd(int&, unsigned char*, unsigned long, unsigned int&, unsigned int&, unsigned int&) (this=0xfffef0045610, fd=@0xfffef0029f08: 432, in_buf=0xfffe84005670 "\377\330\377", <incomplete sequence \340>, in_buf_size=5475, pixfmt=@0xfffe967c295c: 43690, width=@0xfffe967c2954: 65534, height=@0xfffe967c2958: 3662497956) at /usr/src/jetson_multimedia_api/samples/common/classes/NvJpegDecoder.cpp:134

Is there a way to handle this problem safely or a workaround and still using hardware decoding? would cause a performance hit for us to rely on a software encoder.

I found a related topic but OP uses 5.1 and left the thread without answer.


Alberto R.

Please upgrade to Jetpack 5.1.3 and run the sample:


If the issue is still present, please share the JPEG file so that we can run 06 sample to replicate the error.

I attempted to save the .jpg file before the crash occurred. If I read from it, nvjpeg is able to decode without any issues, so I haven’t yet figured out a way to reproduce the problem. However, in the main program, I also use nvjpeg on a separate thread to encode frames into jpeg so that could be related somehow ¿?. Also, the issue seems to occur more quickly the more cameras I am simultaneously capturing frames from.

After testing deeply with corrupted images, I have come to the conclusion that it has more to do with the way I call the decoder. It seems that it crashes when createJPEGDecoder and decodeToFd are called on different threads.
To overcome this, I have to create a jpegdec instance with createJPEGDecoder and destroy it for each new frame. But that triggers the virtual memory leak issue until it stops at the 500th frame.
I did not have this issue on Xavier NX with 4.6.3 where I only call createJPEGDecoder at start an use the same ptr until camera capture stops.

Moreover, the manufacturer said that they won’t update until they have a Jetpack 6 upgrade ready.

Is there a better way to overcome this issue?

Xavier series are not supported on Jetpack 6, so it would be great if you can upgrade to latest Jetpack 5 version: 5.1.3.

For using 5.1.1, you may consider use software JPEG decoder.

Sorry, I should have mentioned that I have two Jetson based computers, a Xavier NX with 32.7.4 and the AGX Orin mentioned earlier.

I ended using decodeToBuffer for 35.3.1


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.