Where is l4t mmapi sample code?

I’m reading this page multiple times and for the life of me I can’t find where you’re actually supposed to find the sample code after JetPack installs mmapi. It doesn’t seem to be actually specified anywhere and the new installer isn’t saying. Where is the code installed on my system, if it is? I’m searching for the filenames and not finding anything.

I much preferred the old Gtk3 installer. This one prompts me for sudo password when my dev user isn’t in sudo. The behavior of most Gtk apps seems to be to use gksu or similar and I much prefer this as it allows me to substitute with another user that does have sudo. Otherwise I have to log in as another user, log into an incognito session to get my nvidia creds, etc etc…

1 Like

Hi mdegans, you should be able to find it under /usr/src/tegra_multimedia_api on your Nano.

1 Like

Edit Update for those reading the thread since JetPack 4.2.1’s release: i found the sample code under “/usr/src/nvidia/tegra_multimedia_api” on JetPack 4.2.1 instead of “/usr/src/tegra…” on 4.2.0.

Thank you! I also found it at this link here, in the table, “Drivers” row, “Jetson Nano” column.

@dusty: Can you provide an example of how to glue, “to MMAPI”, 00_video_decode with 07_video_convert?

I did a FIFO, and the performance is “OK” but 50% slower than gstreamer

It is discussed in MMAP samples: How to interconnect the samples provided using - Jetson Nano - NVIDIA Developer Forums

It appears the MMAPI sample code download for nano linked off this page has become corrupted. Something is up with Nvidia’s servers and/or CDN.


Hmm I was just able to download and extract the archive (also tested the L4T kernel sources).

There had been an issue going around recently with a bug in bzip2, see: https://bugs.launchpad.net/ubuntu/+source/bzip2/+bug/1834494/comments/6

You could try changing bzip2 version:

# For 18.04:
sudo apt install bzip2=1.0.6-8.1 libbz2-1.0=1.0.6-8.1

# For 16.04:
sudo apt install bzip2=1.0.6-8 libbz2-1.0=1.0.6-8

I really don’t think this is a bzip2 problem because I download a lot of tarballs… like hundreds if not thousands a day if you include the things I use that use it internally, and this only happens with nvidia.

Could it not be your CDN? Can you check against the sha256 of the file you downloaded against the one in my attached screenshot for giggles?

Then, if it matches, I will try certainly try another decompressor (i did anyway). I’m unsure of what 7zip for windows uses internally, but i’m sure there is an alternative.

I just tried an alternative, the version of Python packaged with Visual Studio (3.7.3), and it’s tarfile library.

with tarfile.TarFile(tarball_filename) as tarball:
    tarball.extractall(destination)

and got “tarfile.ReadError: invalid header”

Edit: as an aside, can Nvidia start providing a signed list of shas for it’s downloads, like linux distros do?

OK, just checked - and my sha256sum matches yours.

Can you try extracting it from a Linux machine or on the Nano, and if that doesn’t work, check that bug I linked to and the package versions from my post above.

Thanks. I just tried, and it extracts fine on the nano, or on my primary Linux workstation, but this seems odd that I have to do this only with Nvidia tarballs.

How are you compressing your tarballs? Are you do doing tar cjf some.tar.bz2 somefolder? because that’s what I do and it extracts anywhere.

I just recompressed the mmmapi files on my linux workstation, copied over the file via sftp, and it extracts fine on windows now. z7ip likes it, at least, i haven’t tried Python again.

As a troubleshooting step, could you possibly re-compress and re-upload, the tarball in a similar manner so people can extract it on Windows without having to do it on Linux and scp/whatever over the files?

It might be a bit too late to help me since I already have the files where I want them, but it might prevent somebody else from having this same issue.

OK, good to hear that you were able to get them extracted. I’m not sure exactly how these tbz2’s are compressed, as it is part of some automated build process, but we are looking at tweaking the process in the future to avoid this issue. I have also heard from other Linux user groups this issue pop up with other party’s archives, like on the Gentoo forums and kernel development list.

I believe you, it’s just such a strange, incredible, thing with such a mature package. If you do decide to change the build process, maybe tar.xz can be used instead?