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/libnvvideo.so
#1 0x0000ffff5d7efa74 in NvMediaIJPDRenderYUV () at /usr/lib/aarch64-linux-gnu/tegra/libnvmedia.so
#2 0x0000ffff84344780 in jpegTegraDecoderRender () at /usr/lib/aarch64-linux-gnu/tegra/libnvjpeg.so
#3 0x0000ffff8431e948 in jpeg_read_raw_data () at /usr/lib/aarch64-linux-gnu/tegra/libnvjpeg.so
#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.
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.