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
Related
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 would like to compile the following C file on an embedded platform:
https://github.com/openwsn-berkeley/openwsn-fw/blob/develop/firmware/openos/bsp/chips/at86rf231/radio.c
However, as you can see, on lines 20-26 of radio.c it references "radiotimer_capture_cbt":
typedef struct {
radiotimer_capture_cbt startFrame_cb;
radiotimer_capture_cbt endFrame_cb;
radio_state_t state;
} radio_vars_t;
radio_vars_t radio_vars;
So now I need to hunt down where it is defined and make sure I include the right header.
I have cloned the entire GIT repository here: https://github.com/openwsn-berkeley/openwsn-fw, and I'm looking for a way to compile this easily.
Is there a better way to get this compiled other than going through the brutal dependency nightmare?
My ultimate goal is only to get radio.c compiled and anything it needs. I do not see any makefiles in this project so I'm expecting they want us to use an IDE.
The project seems to use scons as a build system. So the simplest way is to dive into the scons files.
There's a small scons file in the directory containing the linked file and two main script in the top directory.
But if you want to play, first remove headers include, try to compile (using -c) to know which one are really needed. Once you get an object file (.o) you can use nm to identify missing symbols (marked with U.) Good luck …
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.
When I work on someone else's code, I tipically need to abuse of grep in order to find data types declarations etc, and this usually makes me confused.
I'd like to have some tool which analyzes the source code and produces some graphviz-like drawing and allows me to follow dependencies.
Also I've found this on the internet, but I think is taylored for the linux kernel only.
Have you tried doxygen?
Doxygen can produce dot files, and you can build the documentation without changing the source code with the right options set in the Doxyfile.
Do you use an editor that can take advantage of tags ? In Emacs, I just type M-. to go to the definition of a symbol, and M-* to go back to where I was once I have read it. This also enables the command tags-search to grep among the files of the software project (very convenient if they are in multiple directories).
I am trying to patch dmenu with the files provided here: http://aur.archlinux.org/packages.php?ID=27334
I do not know how to do it, I've read that I should do patch file-to-patch the-patch, but in the patch provided there is more than one file involved. I've tried patching manually but I failed, it will not compile.
Actually, it's patch < the_patch or cat the_patch | patch.
You may need to use the -p<n> option which is used to strip off segments of the pathnames stored in the patch. For example, if the patch was created from one level above the source tree (like you were diffing one tree against another) and you want to apply the patch from within the source tree, you would need -p.
Another useful option is --dry-run. That will act like it's applying the patch, but won't modify any files. It's a good thing to use to test if you have the -p option correct and to see if the
patch will apply cleanly.
What I normally do is change to the root of the source tree and then run cat <file> | patch -p1 --dry-run. If I get errors about files not being found, I'll switch to -p0. Once either of those works, I remove the --dry-run and do it for real.