Hi,
I recently switched from Jetpack 4.2.3 to Jetpack 4.6.3. I now run out of memory for my application whereas with the older Jetpack it was fine. After investigation, I found that the increased memory usage comes from calling NvJPEGEncoder::createJPEGEncoder(). With JP 4.2.3 there is no noticeable memory usage increase, but with JP 4.6.3 it adds about 250 MB for every call to NvJPEGEncoder::createJPEGEncoder().
Is this a known degredation?
Hi,
We don’t see the issue reported on Jetpack 4.6.3 or 4.6.4. Please check if you can reproduce it by running the sample:
/usr/src/jetson_multimedia_api/samples/05_jpeg_encode/
If you can run the sample to reproduce it, please share us the command and we can try.
Ah, you’re right, the increase in memory doesn’t happen with the call to NvJPEGEncoder::createJPEGEncoder but the first call to encodeFromFd(). On Jetpack 4.6.3, it adds 263 MB (to be exact). Running the sample code 05_jpeg_encode you can see the same effect.
Subsequent calls to encodeFromFd also keep increasing the memory usage to ~600 MB, but I think that’s probably a lazy malloc thing, because a call to sync; echo 3 > /proc/sys/vm/drop_caches frees that extra memory usage to make it the same ~270MB again.
Btw, I couldn’t get the same sample code to work properly on Jetpack 4.2.3; it takes about 20 seconds (I had to increase the callback timeout) and then always produces a fully green JPEG. It did not cause the same memory increase, but seeing as the jpeg encoder doesn’t work normally, that may not mean anything. In my own code I do have the jpeg encoder working on Jetpack 4.2.3 and I don’t see the memory increase there.
Any news? Did you manage to reproduce the extra memory usage after the first call to encodeFromFd with Jetpack 4.6?
Hi,
This doesn’t look to be an issue if available memory is back after cleaning the cache. Do you hit OOM killer while running the 05 sample in long run test?
I understand the extra memory in cache is not a problem. My problem is the 263 MB that is not cleared on Jetpack 4.6. On Jetpack 4.2 calling encodeFromFd does not cause this increase in memory usage.
Hi,
Do you mean after deleting the NvJPEGEncoder object, there is 263MB leak? We would expect the memory goes back to available memory if you delete the not-in-use object.
Sorry, I’m being unclear. There’s no memory leak. It’s just that using the JPEG encoder takes 263 MB on Jetpack 4.6 where it doesn’t on Jetpack 4.2, i.e. as far as I can see it barely uses any memory at all on Jetpack 4.2. Releasing the NvJPEGEncoder object releases all memory as it should, so that isn’t the issue.
Hi,
Please consider create/delete the object in runtime. This is more like an enhancement and there’s no next Jetpack 4 release. It would be feasible to find out a solution on current release.
Thanks for the answer (and the quick replies in general, much appreciated!) Sadly, that is not an option for us, as we use the JPEG encoder continously; we encode multiple JPEGs per second.
So do I understand you correctly that the added memory usage from using the jpeg encoder in Jetpack 4.6 vs on 4.2 is not something you are planning to address in any Jetpack 4.x release, i.e. a Jetpack release that I can run on the Jetson Nano? It would of course be helpful if you did improve it, but it’s also helpful to know where I stand.
Hi,
The latest release for TX2 is Jetpack 4.6.4. For now it’s expected to be the last version.
If there’s critical security hole being reported, we will check and consider a next release then.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.