Can I somehow tell GStreamer to look for plugins in a specified directory?
Use the GST_PLUGIN_PATH environment variable to point at the directory you want, or programatically just call:
GstRegistry *registry;
registry = gst_registry_get();
gst_registry_scan_path(registry, directory);
You can no longer do this programmatically in gstreamer 1.0.
In the above answer,
gst_registry_get_default() was replaced with gst_registry_get()
and gst_registry_add_path() was removed.
You can also set GST_PLUGIN_SYSTEM_PATH to the location of the Plugins. Not sure what the difference is between this and GST_PLUGIN_PATH though.
In case you are running GStreamer from command line you may add --gst-plugin-path=PATHS to the command
Example adding current directory as plugins path
gst-inspect-1.0 kvssink --gst-plugin-path=$PWD
There is much more useful commands available just check:
gst-launch-1.0 --help-gst
Related
I am trying to add functionality to FFmpeg library. The issue is that in developer guide there are just general instruction on how to do it. I know that when I want to add something to ffmpeg I need to register the new functionality and rebuild the library so I can then call it somehow like so:
ffmpeg -i input.avi -vf "myfilter" out.avi
I do not want to officialy contribute. I would like to try to create the extra functionality and test it. The question is - is there any scelet file where the basic structure would be ready and you would just get a pointer to a new frame and processed it? Some directions or anything, because the source files are kinda hard to read without understanding its functions it calls inside.
The document in the repo is worth a read: ffmpeg\doc\writing_filters.txt
The steps are:
Add an appropriate line to the: ffmpeg\libavfilter\Makefile
OBJS-$(CONFIG_MCSCALE_CUDA_FILTER) += vf_mcscale_cuda.o
vf_mcscale_cuda.ptx.o scale_eval.o
Add an appropriate line to the: ffmpeg\libacfilter\allfilters.c
extern AVFilter ff_vf_mcscale_cuda;
The change in (2) does not become recognized until ./configure scans the files again to configure the build, so run Configure and when you next run make the filter should be generated. Happy days.
i was faced with a problem to add transform_v1 filter (see details on transform 360 filters at https://www.diycode.cc/projects/facebook/transform360 ) to ffmpeg with the version N-91732-g1124df0. i did exactly according to writing_filters.txt but transform_v1.o is not linked?
i added the object file (vf_transform_v1.o) in Makefile of libavfilter.
OBJS-$(CONFIG_TRANSFORM_V1_FILTER)+= vf_transform_v1.o
i checked that the define CONFIG_TRANSFORM_V1_FILTER=1 is present in config.h .
However, after the compilation transform_v1 is still not recognized.
i resolved this issue in an awkward way, i added explicitly vf_transform_v1.o in OBJ-list without conditioning by the global define CONFIG_TRANSFORM_V1_FILTER:
OBJS+= vf_transform_v1.o
I am trying to build a shared object for Android using ndk-build command, the source compiles fine but then I get this error:
make (e=206): The filename or extension is too long.
If any body can tell me what causes this problem and how to fix it.
Thanks.
You hit the Windows command length limit. You should use some static libraries as a workaround. Typically, people compile branches of their source tree with separate Android.mk files that end with include $(BUILD_STATIC_LIBRARY), and then list these as $(LOCAL_STATIC_LIBRARIES) in the "main" jni/Android.mk that ends with include $(BUILD_SHARED_LIBRARY). Your ndk-build will load this "main" makefile, so it should include (explicitly or using some nesting approach) all the static library makefiles.
But this is only a convenience. You can achieve the same result if you use single jni/Android.mk file as you have now.
You may also find it easier to list the static libraries as $(LOCAL_WHOLE_STATIC_LIBRARIES) - this way you guarantee that the order of listing these libraries will not cause linking problems.
You can add this to Application.mk
APP_SHORT_COMMANDs :=true
This worked for me.
Maybe as a workaround, you can try to subst the directory "D:\MyFiles\Android\Datte\obj\local\armeabi\objs\ngspice\spicelib" for a drive letter, using:
subst X: "D:\MyFiles\Android\Datte\obj\local\armeabi\objs\ngspice\spicelib"
This could save some space and generate a smaller command line. However, it might not solve your problem, depending on the Windows command length limit, as Alex Cohn answered. Besides, you'll have to change your makefile and change, for example,
D:/MyFiles/Android/Datte//obj/local/armeabi/objs/ngspice/spicelib\parser\inp2y.o
for
X:\parser\inp2y.o
I installed OpenSceneGraph 3.0.1using MacPorts.
I've tried osgversion -> OpenSceneGraph Library 3.0.1. I downloaded the OpenSceneGraph-Data.
Everything seems working well than osgviewer cow.osg takes hours without viewing anything !
please I need help ? is there a way to debug ?
Make sure you have defined the OSG_FILE_PATH environment variable and that it points to the data directory (the one with 'cow.osg').
You can then set OSG_NOTIFY_LEVEL to DEBUG_INFO to get extended information printed to the console. If for any reason the file could not be loaded correctly you will see where to start to troubleshoot.
You can also try to run
$ osgviewer --image /path/to/an/image.png
to test if the plugins work correctly.
Plugins are named e.g. osgdb_jpeg.dylib so you can look for these to make sure they have been built properly along with the core libraries and programs.
Try setting the notify level to DEBUG : Tips And Tricks
$ export OSG_NOTIFY_LEVEL=DEBUG
and run it and see if it says what's going on/going wrong.
I am facing this error while trying to debug C code in Visual Studio 2010. When searched in google all i could find something related is as below
http://connect.microsoft.com/VisualStudio/feedback/details/615793/badly-formed-debugger-command-causes-error-parameter-basepath-cannot-have-zero-length.
Any suggestions to overcome this is really appreciated . Thanks
Same problem, I was building a function library to load on demand, but got this message. It is a matter of don't quote the VSDebugger options.
Remove the double quotes from
the full path of the executable
the command arguments
the working directory
embedded spaces can be passed to the command line by single quotes, if really required.
I had the same error message with only the name of the executable in the command (so no full path). It used to work pefectly, but suddenly it didn't. I checked the path variable and somehow there were two consecutive ';' in there. I fixed that and the problem disappeared.
In my case the command line did not have .exe extension at the end (Properties->ConfigurationProperties->Debugging->Command). Adding the extension fixed the problem.
For me "Parameter "basePath" cannot have zero length" was caused when I set my configuration properties->debugging->command to "regsvr32.exe $(TargetPath)" to debug my project registration. I fixed this by setting the command to "regsvr32.exe" and command arguments to "$(TargetPath)"
If you set up a makefile project (I guess it's the case), be sure that the file you put in Configuration Properties -> Debugging -> Command exists.
(and I think it doesn't accept batch files, but I'm not 100% sure)
check your path in: Configuration Properties -> Debugging -> Working Directory.
check that this path is a valid path in your machine.
I've solved this problem with setting value of Properties->Debugging->Command to another, and after it set back to my default.
Also make sure Visual Studio is running "As Administrator". This fix it for me.
I've spent some time reviewing the docs and going through my doxy config file from end to end. I cut doxygen loose on my config file and it produces documentation and indices for structs and cpp classes but I don't see call or caller graphs for the multitude of c functions in my source tree.
Can anybody tell me how to configure doxygen to produces these call and caller trees ? I do have graphviz installed.
You have to set HAVE_DOT, CALL_GRAPH and CALLER_GRAPH to YES.
Also make sure the path to dot is in your PATH variable.
If that still doesn't work, you might have to set EXTRACT_ALL and/or EXTRACT_STATIC, depending on your functions.
For MacOS users:
Install Doxygen and Graphviz as:
brew install doxygen
brew install graphviz
Go to your project folder, and from Terminal set to this path run
doxygen -g
A doxygen file will be generated, named as Doxyfile. Go ahead and open up this file in any editor and find these parameters and replace their values to YES at their locations:
HAVE_DOT = YES
EXTRACT_ALL = YES
EXTRACT_PRIVATE = YES
EXTRACT_STATIC = YES
CALL_GRAPH = YES
CALLER_GRAPH = YES
DISABLE_INDEX = YES
GENERATE_TREEVIEW = YES
RECURSIVE = YES
You can also set name of your project in this Doxyfile. Save the file and then run this command in the terminal:
doxygen Doxyfile
This will generate two more folders named as html and latex. Go to the html folder and open annotated.html to view all details of your project. You will also view png images of the call graphs embedded in the html that are relevant (to some functions/classes for example).
Setting the path to "dot" (/usr/local/bin/) via the "Expert" tab controls in the GUI did the trick!
doxywizard is also useful. It gives you all the options in a GUI. Selecting any option shows quick help about that option.
You might also be interested in COLLABORATION_GRAPH or GRAPHICAL_HIERARCHY.
Quite convenient.
I had the same problem for my C global functions. Enabling CLANG_ASSISTED_PARSING did help display callgraphs for some functions, yet not all of them.