gstreamer bad plugins with opencv 3.3

bhargavK · October 28, 2017, 12:25am

Hello,

I have been working on some video playing/streaming pipelines for Computer Vision work on Nvidia Jetson TX2. It had Ubuntu 16.04 with latest Jetpack.

I have already installed opencv 3.3 and to test some of the pipelines, with .MP4 video files, I need h264parse plugin which is a part of gst-bad-plugins. However, when I try to install it using apt-get, it shows that following packages will be installed:

freepats gstreamer1.0-plugins-bad-faad gstreamer1.0-plugins-bad-videoparsers
libbs2b0 libde265-0 libflite1 libfluidsynth1 libgstreamer-plugins-bad1.0-0
libmimic0 libmjpegutils-2.1-0 libmms0 libmpeg2encpp-2.1-0 libmplex2-2.1-0
libofa0 libopenal-data libopenal1 libopencv-calib3d2.4v5
libopencv-contrib2.4v5 libopencv-core2.4v5 libopencv-features2d2.4v5
libopencv-flann2.4v5 libopencv-highgui2.4v5 libopencv-imgproc2.4v5
libopencv-legacy2.4v5 libopencv-ml2.4v5 libopencv-objdetect2.4v5
libopencv-video2.4v5 libsoundtouch1 libspandsp2 libsrtp0 libvo-aacenc0
libvo-amrwbenc0 libwildmidi-config libwildmidi1 libzbar0

Here it tries to install an older version of opencv and this really messes up with my current opencv (v3.3) install.

Does anyone have any idea on how should I overcome this problem. I would not want the option to just ignore all the dependencies. But somehow, if it detects the installed opencv version, that would be awesome.

Any help is appreciated.

Thanks!

(I have also made a stackoverflow post but I want to maximize the probability of people suggesting something. Stackoverflow link: https://stackoverflow.com/questions/46985053/installation-of-gstreamer-bad-plugins-and-opencv3-3-on-ubuntu-16-04-arm64)

jkjung13 · October 30, 2017, 4:53am

I have built and installed opencv-3.3.0 at /usr/local on my Jetson TX2. When I did ‘apt-get install gstreamer1.0-plugins-bad’, those libopencv 2.4v5 stuffs did get installed onto my Jetson TX2 as well.

But as far as I can see, it’s OK to have both these versions of OpenCV installed on my Jetson TX2. I have been programming PyCaffe together with OpenCV, and I don’t notice any problem at all.

You can refer to my latest blog post here: [url]https://jkjung-avt.github.io/tx2-camera-caffe/[/url]

jkjung13 · October 30, 2017, 5:00am

Duplicated post removed…

bhargavK · October 30, 2017, 7:34pm

I think I read through your blog-post. I believe you installed gstreamer plugins before installing OpenCV-3.3.0.

In my case, I had already installed OpenCV-3.3.0 and then when I install the gstreamer-bad plugins, the current version would be overwritten. So, I installed the bad plugins and then again built OpenCV-3.3.0.

Seems like it is working so far.

Thanks.

GWAVE · July 10, 2018, 11:27pm

I’ve been following jkjung13’s blog posts on working the Jetson TX2 and some of the examples with OpenCV and Caffe. Before installing OpenCV (How to Install OpenCV (3.4.0) on Jetson TX2), he suggests that we remove the native install of OpenCV libraries with

$ sudo apt-get purge libopencv*

In a later blog post on recording with the camera (Tegra Camera Recorder), jkjung13 says that we need to install the following dependency for running his script

$ sudo apt-get install gstreamer1.0-plugins-bad

As you (bhargavK) pointed out, this install, via apt-get, depends on some OpenCV libraries (libopencv*), which seem to come from an older version of OpenCV. Comparing the listed dependent OpenCV libraries for “gstreamer1.0-plugins-bad” with those already in my “/usr/local/lib” directory (after already having installed OpenCV3.4.0), I see that I have all but one OpenCV library (libopencv-contrib). Looking over at the github page (GitHub - opencv/opencv_contrib: Repository for OpenCV's extra modules), it sounds like this “library” would just be an extension to the install instruction from jkjung13’s blog post on installing OpenCV3.4.0 on the Jetson TX2 (see link above).

All that being said, I wish to try jkjung13’s record example but I’m hesitant to break my install of OpenCV3.4.0. If you (bhargavK) performed

$ sudo apt-get install gstreamer1.0-plugins-bad

did you then remove the older OpenCV libraries via

$ sudo apt-get purge libopencv*

before reinstalling OpenCV3.x? Or did you skip the removal step and simply reinstall OpenCV3.x? If you skipped the removal step, did your reinstall result in the softlinks (found in /usr/local/lib) pointing to the latest OpenCV libraries or did the softlinks still point to the older OpenCV libraries resulting from the install of “gstreamer1.0-plugins-bad”? Here I’m assuming that installing the dependent OpenCV libraries, via apt-get, places the libraries in “/usr/local/lib”, but maybe apt-get dumps them somewhere else?

I’m interested in installing “gstreamer1.0-plugins-bad”, via apt-get, so that I can try jkjung13’s record example, but I don’t want to mess up my OpenCV3.4 install. I know yourself and jkjung13 claim “everything works without trouble so far” but it seems it’s just a matter of where the softlink’s point? I don’t know, but I was hoping to get a little more clarity on the proper install of “gstreamer1.0-plugins-bad” without breaking my install of OpenCV3.4.

jkjung13 · July 11, 2018, 1:47am

On JTX2, the compiler (gcc) and linker (ld) would search for header and library files in /usr/local before the standard /usr locations. And since I have installed OpenCV-3.x in /usr/local, I think it’s OK. The OpenCV-3.x headers/libraries should take precedence over the /usr/lib/aarch64-linux-gnu/libopencv_xxx.so.2.4 stuffs installed by apt.

Reference:

GCC search path: https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
Dynamic library search path: https://unix.stackexchange.com/questions/367600/what-is-the-order-that-linuxs-dynamic-linker-searches-paths-in

GCC header search order on JTX2: (/usr/local/include is on top)

nvidia@tegra-ubuntu:~$ cpp -v /dev/null -o /dev/null
......
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/aarch64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/aarch64-linux-gnu/5/include-fixed
 /usr/include/aarch64-linux-gnu
 /usr/include

Dynamic linkder search path:

nvidia@tegra-ubuntu:~$ man ld.so
......
       If  a  shared  object  dependency  does not contain a slash, then it is
       searched for in the following order:

       o  (ELF only) Using the directories specified in the  DT_RPATH  dynamic
          section  attribute of the binary if present and DT_RUNPATH attribute
          does not exist.  Use of DT_RPATH is deprecated.

       o  Using the environment  variable  LD_LIBRARY_PATH  (unless  the  exe‐
          cutable is being run in secure-execution mode; see below).  in which
          case it is ignored.

       o  (ELF only) Using the directories specified in the DT_RUNPATH dynamic
          section attribute of the binary if present.

       o  From the cache file /etc/ld.so.cache, which contains a compiled list
          of candidate  shared  objects  previously  found  in  the  augmented
          library  path.  If, however, the binary was linked with the -z node‐
          flib linker option, shared objects in the default paths are skipped.
          Shared  objects  installed  in  hardware capability directories (see
          below) are preferred to other shared objects.

       o  In the default path /lib, and then /usr/lib.  (On some 64-bit archi‐
          tectures,  the  default  paths for 64-bit shared objects are /lib64,
          and then /usr/lib64.)  If the binary was linked with the -z nodeflib
          linker option, this step is skipped.

And I checked /etc/ld.so.cache and verified /usr/local/lib/libopencv_xxx.3.4 are ahead of libopencv_xxx.2.4 files.

GWAVE · July 11, 2018, 3:11am

Thanks jkjung13 for the clarity! I follow your reasoning and it makes sense to me.