gst-vimbasrc on Jetpack 4.6

[robbyfrt]

Hi Allied Vision Team,

I was successfully building and testing vimbasrc on a Jetson Nano using Jetpack 4.5.1 and Vimba 6.0. The compute unit for my production use case however is a Xavier NX running on Jetpack 4.6.

I still tried to build the plugin using the docker method but when running the container, I get a very basic error regarding datatypes in the source files:

nvidia@tegra-ubuntu:~$ sudo docker run --rm -it --volume /home/nvidia/gst-vimbasrc:/gst-vimbasrc --volume /opt/Vimba_6_0:/vimba gst-vimbasrc:18.04
[sudo] password for nvidia:
# ============================================================================
cmake -S . -B build -DVIMBA_HOME=$VIMBA_HOME
-- Configuring done
-- Generating done
-- Build files have been written to: /gst-vimbasrc/build
# ============================================================================
cmake --build build
[ 25%] Building C object CMakeFiles/gstvimbasrc.dir/src/gstvimbasrc.c.o
In file included from /usr/include/gstreamer-1.0/gst/gst.h:55:0,
                 from /usr/include/gstreamer-1.0/gst/base/gstpushsrc.h:27,
                 from /gst-vimbasrc/src/gstvimbasrc.h:24,
                 from /gst-vimbasrc/src/gstvimbasrc.c:32:
/gst-vimbasrc/src/gstvimbasrc.c: In function 'set_roi':
/gst-vimbasrc/src/gstvimbasrc.c:1564:36: error: format '%d' expects argument of type 'int', but argument 8 has type 'VmbInt64_t {aka long long int}' [-Werror=format=]
         GST_DEBUG_OBJECT(vimbasrc, "ROI centering along x-axis requested. Calculated offsetx=%d",
                                    ^
/usr/include/gstreamer-1.0/gst/gstinfo.h:640:31: note: in definition of macro 'GST_CAT_LEVEL_LOG'
         (GObject *) (object), __VA_ARGS__);    \
                               ^~~~~~~~~~~
/gst-vimbasrc/src/gstvimbasrc.c:1564:9: note: in expansion of macro 'GST_DEBUG_OBJECT'
         GST_DEBUG_OBJECT(vimbasrc, "ROI centering along x-axis requested. Calculated offsetx=%d",
         ^~~~~~~~~~~~~~~~
/gst-vimbasrc/src/gstvimbasrc.c:1585:36: error: format '%d' expects argument of type 'int', but argument 8 has type 'VmbInt64_t {aka long long int}' [-Werror=format=]
         GST_DEBUG_OBJECT(vimbasrc, "ROI centering along y-axis requested. Calculated offsety=%d",
                                    ^
/usr/include/gstreamer-1.0/gst/gstinfo.h:640:31: note: in definition of macro 'GST_CAT_LEVEL_LOG'
         (GObject *) (object), __VA_ARGS__);    \
                               ^~~~~~~~~~~
/gst-vimbasrc/src/gstvimbasrc.c:1585:9: note: in expansion of macro 'GST_DEBUG_OBJECT'
         GST_DEBUG_OBJECT(vimbasrc, "ROI centering along y-axis requested. Calculated offsety=%d",
         ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
CMakeFiles/gstvimbasrc.dir/build.make:81: recipe for target 'CMakeFiles/gstvimbasrc.dir/src/gstvimbasrc.c.o' failed
make[2]: *** [CMakeFiles/gstvimbasrc.dir/src/gstvimbasrc.c.o] Error 1
CMakeFiles/Makefile2:94: recipe for target 'CMakeFiles/gstvimbasrc.dir/all' failed
make[1]: *** [CMakeFiles/gstvimbasrc.dir/all] Error 2
Makefile:102: recipe for target 'all' failed
make: *** [all] Error 2
# ============================================================================
nvidia@tegra-ubuntu:~$

Since I already built libgstvimbasrc.so on the nano, I naively tried to follow your INSTALLATION.md using a copy from the nano for my Xavier NX without success (no such element or plugin 'vimbasrc'). Referencing the path using GST_PLUGIN_SYSTEM_PATH did not work either.

Any advice? Could you update the repo for Jetpack 4.6 if possible? I am kind of locked in to Jetpack 4.6 due to the manufacturers BSP provided.

[NiklasKroeger-AlliedVision]

Thank you for reporting this error! The errors are fixed on the master branch with commit 1ed82fe. You should be able to compile the plugin again from master.

That being said, I would expect a compiled version from your Jetson Nano to work on your Xavier NX. So maybe it is worth a try to see if we can get the libgstvimbasrc.so file working on your Xavier.

First off, there are also pre-compiled binaries available from our Github releases. Maybe you can try to use the ARM64.zip from our v0.3.2-beta1 pre-release. This zip file includes libgstvimbasrc.so and is intended for use on embedded boards like the Xavier NX.

To figure out why the plugin could not be loaded, checking the .so file with ldd might be helpful. For this, navigate into the directory where you saved the plugin (I assume something like ~/.local/share/gstreamer-1.0/plugins) and run

# expected output should be similar to this. Your paths will vary slightly since this output was generated on an x86_64 machine:

user@hostname:~/.local/share/gstreamer-1.0/plugins$ ldd libgstvimbasrc.so
    linux-vdso.so.1 (0x00007ffeea5e0000)
    libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f7b21b75000)
    libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f7b21921000)
    libgstreamer-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0 (0x00007f7b215e6000)
    libgstbase-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0 (0x00007f7b21371000)
    libVimbaC.so => /usr/local/lib/libVimbaC.so (0x00007f7b21099000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7b20ca8000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f7b20a36000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7b20817000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f7b2060f000)
    libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f7b2040b000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7b2006d000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7b1fe65000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7b1fc61000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7b1f8d8000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7b1f6c0000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f7b2209c000)

One common issue would be the libVimbaC.so dependency you can see in that output. If it can not be found while loading libgstvimbasrc.so, the plugin will not work. In that case the ldd output from above would show the following for libVimbaC.so:

libVimbaC.so => not found

To make libVimbaC.so available, follow the instructions in INSTALLING.md regarding the installation dependencies. I personally usually place a copy of libVimbaC.so from the Vimba packet you have installed in /usr/local/lib and run sudo ldconfig -v to make sure that the file is detected correctly (output of sudo ldconfig -v should include something like this: libVimbaC.so -> libVimbaC.so).

If all dependencies listed by ldd are located correctly, but the file still does not load, it might be possible that the GStreamer plugin registry has the file blacklisted due to earlier errors when loading the plugin. Try resetting the registry cache as described in the first Troubleshooting point in README.md.

[robbyfrt]

Yes. It just works, thank you so much. I used the pre-compiled binaires you provided and uploaded them accordingly to the plugin folder. I think my only previous mistake was not using sudo ldconfig -v to make sure libVimbaC.so is detected. Hence the module not found error when trying to load vimbasrc.

Tat is less than 8hrs in solving my issue. And I can confirm that the plugin works under Jetpack 4.6 (although i have only tried a simple filesink yet). :)

[NiklasKroeger-AlliedVision]

I think my only previous mistake was not using sudo ldconfig -v to make sure libVimbaC.so is detected

Yes I also encountered this in the past. I think the ld cache of the system needs to be updated when new shared objects are added to the path. Running ldconfig takes care of that.

And I can confirm that the plugin works under Jetpack 4.6

Thanks for the info. That is good to know 👍