I would like to report misbehavior of ‘nvjpegdec’.
Running the following on my Jetson Nano (developer kit):
gst-launch-1.0 videotestsrc ! videoconvert ! nvjpegenc ! ‘image/jpeg,width=800, height=600’ ! videorate ! ‘image/jpeg, framerate=20/1’ ! nvjpegdec ! autovideosink
fails after ~50 seconds (I timed it a few times, its rather consistent) with error:
NvRmChannelSubmit: NvError_IoctlFailed with error code 22
NvRmPrivFlush: NvRmChannelSubmit failed (err = 196623, SyncPointIdx = 23, SyncPointValue = 0)
For higher resolutions it fails quicker - e.g. with 1920 x 1080 used in the above, it took ~25s.
Having read that the error code deals with HW blocks not accepting requests, I replaced the (encoder and) decoder with software-based, i.e. ‘jpegdec’ instead of ‘nvjpegdec’ and it fixed the problem (or at least it didn’t crush during the time that I had the patience to wait, i.e. some 5 minutes).
So - this works:
gst-launch-1.0 videotestsrc ! videoconvert ! jpegenc ! ‘image/jpeg,width=800, height=600’ ! videorate ! ‘image/jpeg, framerate=20/1’ ! jpegdec ! autovideosink
also, I tried using the hw encoder:
gst-launch-1.0 videotestsrc ! videoconvert ! nvjpegenc ! ‘image/jpeg,width=800, height=600’ ! videorate ! ‘image/jpeg, framerate=20/1’ ! jpegdec ! autovideosink
and it also works (at least for the test’s duration of 5 mins).
Only with ‘nvjpegdec’ it crashes, so all fingers point to nvjpegdec and the behavior, to my mind, might indicate a memory leak.