memory leak

[123lifei]

could you find memory leak Slowly when you use decode named h264_nvv4l2dec?

[LinusCDE]

I have not used that decoder extensively, so I didn't notice that. The decoder is the official submitted by nvidia employees to the ffmpeg mailinglist afaik (link should be in readme).

That would probably be an issue on their side then. For decode, I would recommend the nvmpi variant anyways, since it seemed a bit more performant (but the nvidia one supports some other pixel formats).

So this is probably not in my scope to fix, as I just repackaged other en-/decoders here. If there is an updated patch that fixes it, let me know.

[xsacha]

The official nvidia one has received update to 4.2.2.1 (23 May 2021) by the way. There's a Ubuntu 20 build too, 4.2.7 (21 July 2022).
I believe you are using the 2020 version here.

$ echo "deb https://repo.download.nvidia.com/jetson/ffmpeg main main" | sudo tee -a /etc/apt/sources.list
$ echo "deb-src https://repo.download.nvidia.com/jetson/ffmpeg main main" | sudo tee -a /etc/apt/sources.list
$ sudo apt update
$ sudo apt install ffmpeg

[LinusCDE]

I have not yet managed to migrate to a firmware with Ubuntu 20.04. The version used here should work fine as long as libs are not too out of date. In that case compiling it yourself would solve it.

The ffmpeg version itself isn't intended to mirror the one available from apt. If it's too out of date, I can probably update it sometime in the future. Right now I just cannot provide a build on the newest version and compatible with the newest jetpack release (if there is a mismatch) due to time constrains I'll have for a few months at least.

Maybe I'll find the time, to at least update to the mentioned (or whatever the current release) is. I heavily doubt that for now though. (PRs are also always welcome. The way I did it should be described in the readme.)

Or did you want to imply that theirs now also includes their hw acceleration? That would be awesome.

[xsacha]

Just a note, I think I get the leak you mention on the newer version (4.2.2.1) for Ubuntu 18. However, I have not tested the Ubuntu 20 version.
It's a very slow leak right? It appears invisible to the process, although top shows it associated with the process. I found the number increasing is in:

$ cat /proc/meminfo
...
NvMapMemFree: 0 kB
NvMapMemUsed: 1559860 kB
...

When I switch back to jetson-ffmpeg, the number appears stable. I remember this bug occurring in an earlier version of jetson-ffmpeg.

Edit: I discovered a fix here https://gitlab.com/switchroot/switch-l4t-multimedia/FFmpeg/-/commit/deac819ac20d2ccd1664c95e4d91c20a35d67cc5
It's a different one though.

[LinusCDE]

I'm finally now getting to fully re-install my jetson with the newest OS/SDK. So will try to incoperate the fix there ig the following days / week (if I find time and motivation for it).

This means that I can't test the old version based on Ubuntu 18.04 anymore. I'll probably make the old instructions collapsible / reachable over a separate branch and mention this patch, so people can try to include it themselves.

[LinusCDE]

The leak should be fixed with commit 6b4170f.

I'm currently on making a new release based on ffmpeg 6.0. I so far managed to get most patches migrated to 6.0 as the api seems to have changed quite a bit. However I still have an issue where using the h264_nvmpi encoder spams the message Error while dequeing buffer from output plane (I have not tested h265 yet).

The error seems the be thrown here but I still need to figure out why that happens.