I was trying to install a gstreamer plugin in my Raspberry Pi.
I have downloaded the Gstreamer plugin from a repository, then I build the binaries. After building I did a
sudo make install to install the gstreamer openmax plugin.
But the plugin (gst-openmax) that have hardware decoder elements(omxh264dec etc) are not being listed in gst-inspect.
I think it is because I have not register the plugin ?
How do I register this plugin ?
I have gone through the code and found a function called plugin_init() inside which they have written code to register the plugin. How to invoke this function ?
I tried setting the environmental variables such as GST_PLUGIN_PATH, GST_OMX_CONFIG_DIR, LD_LIBRARY_PATH etc But that too didnt work.
How to Register this open max plugin so that I can use it in different pipelines ?
To get gstreamer to detect your plugin (ie the .dll or .so file) you just need to put it in the plugin directory. You don't need to invoke any function calls such as plugin_init etc. Gstreamer will automatically call it if it detects a plugin in the plugin directory.
Related
I'm developing a free guitar VST plugin that I want to distribute through a .deb package.
In the postinst script, I run the xdg-desktop-menu command to create the launcher for the standalone version (which works fine), but DAWs (like reaper and bitwig) will look for vst plugins inside $HOME/.vst and obviously won't find my plugin there.
At first I thought I needed to create a symlink inside $HOME/.vst but now I know debian packages aren't supposed do anything inside the user's folder. So what should I do instead?
Is there a way or steps to follow to integrate a yocto SDK (standard or extensible) with VSCode? I want to cross-compile, remote connect, and debug a C/C++ application within VSCode for target hardware using a yocto generated Linux image. Is this possible? I know of the bitbake extension but couldn't find one for the SDK. Thank you!
Conservatively, I would say it depends on the level of integration you want to achieve but I use regularly VS Code to edit and build, sometime to debug C applications using a Yocto toolchain, that's really easy for Makefile projects for example.
Assuming you do not ask for Yocto integration into VS Code (I don't know if something exists) but really to use the tools generated by the SDK from Yocto and that you already are familiar with Yocto toolchain usage.
I personally compile on Linux server remotely from a Windows PC. The server contains therefore my projects and the Yocto toolchain.
I use for that the nice Remote SSH extension from Microsoft on VS Code. From there, I can edit easily the files, compile and a terminal is available (that's out of the scope of your question however).
So if working as me or directly in Linux, you can create a Makefile/CMake project for example. The C/C++ VS Code extension is a must have.
Each time you start working, you source the Yocto SDK toolchain and compile directly using make from the terminal window of VSCode. If you want to automatize the build step, you can use the task feature of VS which allows you to launch build script for example.
Regarding the remote connect, the terminal window of VS can also have multiple sub-windows with various connections like SSH to the target. The build script can also use scp to send the generated binary directly to the target but your question is vague regarding what you want to do.
Finally for the debug aspect, GDB is well supported in VS Code and the official doc is a good start as well as the C++ debugging doc.
On the Yocto side, you need to add gdbserver to the image running on the target, it can be done by adding the following to your conf/local.conf:
EXTRA_IMAGE_FEATURES += "tools-debug"
If you want to have debug information for the shared libs on the target, you also need to add:
EXTRA_IMAGE_FEATURES += "dbg-pkgs"
Finally, the SDK must be generated with the same options as the image running on the target and will contain the cross-gdb tool like -gdb to be used on the host side.
So that's possible but requires some setup especially the debug part. As far as I know, there is not a VS Code extension managing all these steps for you automagically.
I followed the instructions in GStreamer Plugin Writer's Guide (1.7.1.1):
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/index.html
in order to build a new gstreamer plugin. Basically I ran make_element and then edited Makefile.am as described. Amazingly make and make install worked and I ended up with:
/usr/local/lib/gstreamer-1.0/libgstframe_grabber.la
/usr/local/lib/gstreamer-1.0/libgstframe_grabber.so
As I understand it, gst-inspect should find this plugin automatically. The guide says that /usr/local/lib/gstreamer-1.0 needs to be added to GST_PLUGIN_PATH in order for plugins in this directory to be found. Another document states that this directory is searched automatically. I tried with and without the environment variable, but no luck.
Now I should say that I have just started to use gstreamer and I am suffering from total information overload. I have read so many documents, yet I don't even know whether I am building a gstreamer1.0 or a gstreamer0.10 plugin (I think the guide is for gstreamer1.0, since the guide's version is 1.7.1.1 but can't be sure).
Can anybody give me a clue here ?
There are many possible reasons that can cause this issue.
First, check if your plugin is blacklisted by command gst-inspect-1.0 -b.
If your plugin show up here, that means it is really blacklisted.
In that case, delete directory ~/.cache/ and then run gst-inpect-1.0 again.
This will force GStreamer to re-scan plugins list. If the reason of blacklist is not solved yet, gst-inpect will probably print out the reason here for you.
Another possible reason (but unlikely happens) is setting GST_REGISTRY_UPDATE as no, which will force GStreamer NOT to rescan the plugin directory, thus not found new plugin
P/s: The guide is for GStreamer 1.0
If you've tried removing your plugin from the blacklist and it still doesn't show up, try this:
export GST_PLUGIN_PATH=/usr/local/lib/gstreamer-1.0
/usr/local/lib/gstreamer-1.0 is the default directory used by make in case of plugins. If you have defined a different directory, use it.
Then run gst-inspect-1.0 and you'll find the newly compiled and installed plugin.
You'll be required to perform the export every time in the shell whether you either create a static pipeline with gst-launch-1.0 or run code of your own. I couldn't find any alternative to make it permanent other than making entry of this in .bashrc file. If you have one, please suggest via comments.
If you run ./configure --help in the gst-plugin directory you will see the following:
By default, make install' will install all the files in
/usr/local/bin', /usr/local/lib' etc. You can specify
an installation prefix other than/usr/local' using --prefix',
for instance--prefix=$HOME'.
If you do after the original installation:sudo updatedb && locate libgst[NAME_OF_YOUR_PLUGIN].so you should see where the library holding your plugin is located (in my case it is under /usr/local/lib/gstreamer-1.0/ as described by the configure help above).
Now on my machine, the GStreamer "official" plugins are installed under: /usr/lib/i386-linux-gnu/gstreamer-1.0/ . This is where the new created plugin library should be stored.
To store the plugin at the right place, run configure with the following parameter:
./configure --libdir=/usr/lib/i386-linux-gnu followed by make && sudo make install
It is important to override with --libdir and NOT --prefix! The usage of --prefix will stick a /lib that we don't want to have under /usr/lib/i386-linux-gnu.The plugin will not be found by gst-inspect-1.0 if /lib is added to the path.
Extra note :
Even if the plugin is at the proper location, you may still see GStreamer blacklisting it when you run gst-inspect-1.0. One of the cause of the blacklisting could be the shared library/ies required by your plugin not installed or not found on your platform. The ldd command can help figuring out the dependencies your plugin may have. Just run ldd [YOUR_GSTREAMER_LIBRARY].so
I have QT 5.2 installed on Ubuntu 12.04. I did not build it, but simply downloaded and unzipped from the QT website. My question is how can we package the required libs along with the executable for deployment? The QT documentation says that we should build QT for static linking, but the "configure" file is missing in the QT directory.
Thanks in advance.
Ok. So I finally managed to deploy my Qt app along with its dependencies after countless hours of googling. This was done on Ubuntu 12.04 with Qt 5.2.
This is how I did it:
Statically build Qt from the source using the following command :
./configure -opensource -confirm-license -prefix ./qtbase -make libs -make tools -release -opengl desktop -static -skip qtwebkit -no-icu -nomake tests -nomake examples
make -j -4
You can download the source from http://download.qt-project.org/official_releases/qt/5.2/5.2.1/single/qt-everywhere-opensource-src-5.2.1.tar.gz
You cannot static build the installer version of Qt.
Open your Qt project and rebuild it. The Qt dependencies will be built into the app executable. Check with ldd to see if it was done correctly.
ldd ./<app_executable>
Now when you try to run this on a system without Qt it might ask for other third party dependencies which you see with ldd. Eg: libxcb-...
You could either install these dependencies with apt-get on the target system or supply the libs with your app. That is: put the required .so files and their soft links into a directory named libs along with your executable.
After the lib dependency problems are fixed the App will give an error about missing Qt fonts. Easiest way to fix this is to supply the Qt fonts folder along with the app.
This link gives a good way of doing this:
http://goblincoding.com/2013/11/07/deploying-qt-5-applications-on-ubuntu-12-04/
The summary of the above page is that you need to supply a small bash script to run your app. the script should be as follows:
#~/bin/bash
export LD_LIBRARY_PATH=./libs
export QT_QPA_FONTDIR=./fonts
./<app_executable>
The target system will now find the libs and the fonts from the directories you supplied and will run without issues. Hope this helped.
NOTE: I haven't tried, but this script method should work even if you are supplying the Qt libs as well without statically building the qt source.
I have a browser plugin written in FireBreath and have a msi package genearted.
I packed the msi in a cab file in order to provide IE users automatic installation.
However, my plugin use DirectX, so I would like to install DirectX along with my plugin.
How do I trigger the DirectX installation? from the msi installer? the inf file?
Thanks in advance!
Have you looked at this? http://blogs.msdn.com/b/astebner/archive/2008/07/31/8797084.aspx
or this? http://blogs.msdn.com/b/astebner/archive/2008/06/05/8576818.aspx
How about this? http://wix.sourceforge.net/manual-wix3/install_directx9.htm
Those are the first three results on google when searching for "wix installer directx" and they seem to fit the bill nicely...