I follow the steps here to compile FFmpeg.
And there is no problem. Its working well. But i did not understand something.
There are two folders under my home directory.
--ffmpeg_sources
--ffmpeg_build
insede of ffmpeg_sources/libavformat i have number of headers
aiff.h
apetag.h
argo_asf.h
asfcrypt.h
asf.h
ast.h
av1.h
avc.h
avformat.h
avi.h
avio.h
avio_internal.h
avlanguage.h
ogg.h
...
but ffmpeg_build/avformat has 3 header.
avformat.h
avio.h
version.h
btw this is my usr/include/x86_64-linux-gnu/libavformat
avformat.h
avio.h
version.h
Why aren't all headers in these other two files?
For ex: i want to use "ogg_read_packet" but when i try to include <libavformat/oggdec.h> i get cannot open source file "libavformat/oggdec.h"C/C++(1696) error.
Building and using the library aren't the same things.
Have a look at libavformat/oggdec.h and libavformat/oggdec.c. You should have realized, that there is no way to directly use the ogg_read_packet function.
there is no declaration in the header file
the function is declared static in the source file
If you want to encode/decode with a specific codec (here ogg), you have to find an encoder (avcodec_find_encoder or avcodec_find_encoder_by_name) or a decoder (avcodec_find_decoder or avcodec_find_decoder_by_name) and link it to a AVCodecContext via avcodec_open2.
Then for encoding use the 'encode' functions described here and for decoding the 'decode' functions described here.
For more info:
FFmpeg Documentation
FFmpeg Examples
In short, use the public Interface. Only 'God' knows the internals of FFmpeg.
Related
I feel like I'm missing some key idea with this one.
I have a library that I'd like to create a CMakeLists.txt file for. I want to link against it with different applications.
This library expects a conf.h file to be defined. The application has to provide this. The library expects it. What is this relationship called?
My current solution in CMakeLists.txt is to have a variable like:
...
target_include_directories(lib PUBLIC
${CONF_DIR}
)
And then have CONF_DIR be defined by the application. This is uncool, because I can't have multiple applications linking against it.
The only other alternative is to keep a copy of the entire source library inside the application folder, which is also uncool.
I'm looking to maximize reusability. How do I approach this?
Side note: For anyone who's familiar, the library in question is STM32Cube's HAL library, and the pesky file is stm32h7xx_hal_conf.h.
This is a very common approach, when a library requires configuration. FreeRTOS would be another example.
I don't see the issue with modifying the target_include_directories for the library from the App's CMakeLists.txt.
Usually, I create a function to handle the library set-up. The call site would look something like this:
add_stm32_hal_lib(
PATH drivers/STM32H7xx_HAL_Driver
EXTRA_INCLUDES path/to/config
)
# ...
target_link_libraries(app PUBLIC stm32_hal)
The contents of the EXTRA_INCLUDES parameter get shoved into target_include_directories of the static library.
You can't do anything about this, so you'll have to copy the library code.
The header file is used during library compilation stage, so its code ends up being hardwired into the final binary. Because of this, if you want to change some parameters from the header, you need to recompile the library from scratch.
Ideally, the library should be rewritten in such way, that all parameters that are contained in the header can be set up dynamically, during the runtime, using some additional configuration API.
The source codes downloaded from internet has a lot of non standard, uncommon header files
from a different depended modules, say.
#include<calendar.h>
or
#include <vconf.h>
Given any header file, is there a way to find out from which files these headers are fetched from?
look at the documentation of the lib to that the header belongs may the best way.
you also may look into the header and note down some function names and search through the lib which does define the symbol that belongs to that function
edit:
ah i thought you have a bunch of libs and headers and you do not know which you have to link to get functionality that is declared in a specific header
In your case looking at documentation from downloaded source code may be the only way (mostly this information is in the INSTALL or README - file)
No, not in general.
The string inside of #include is just a filename, and those can easily be reused by different projects, especially generic names like "calendar.h".
You could try googling the header names, or try to compile and google the function names that are used in the downloaded code, but defined in the missing header file. You could try asking the author of the code, or looking for more information from where you downloaded the code.
I am looking for some input on how to programmatically convert mp4 files to fragmented f4f files with accompanying manifests.
I currently have an implementation for creating segmented MPEG2-TS files with accompanying manifest for Apples HLS, and want to create a similar piece of software for Adobes HDS.
My code is based on Libav (alternatively, ffmpeg), so I was hoping they had native support for muxing f4f files, but I have not been able to find any resources for it.
What I am specifically looking for:
How (if) the format is used in libav?
If there is any special requirements (such as the h264_mp4toannexb filter required for converting MP4 to MPEG2 TS)?
Any sample code (even if it's not using libav/ffmpeg)
An easy-to-read manifest specification.
I'm afraid you have to read mp4/f4f specification, and implementation it your self.
MP4 file format: ISO/IEC 14496-14
f4f file format: It is included in the f4v specification.(http://www.adobe.com/cn/devnet/f4v.html)
The code of mod_h264_streaming (http://h264.code-shop.com/trac) may be helpful.
We have a legacy library implementation and associated exposed header files. Recently we found that, some of the functions in the exposed header file, don't have corresponding definitions in the library implementation.
We want to check if there could be some more such functions. Is there any easier way of doing this rather than sifting through each and every API present in header and then checking if there is a definition for it?
You can generate C source from the header (Perl is a way to go!) that calls all the functions and try to compile it. Linker will complain about missing functions.
Try to create the ABI dump file by the abi-compliance-checker tool:
abi-compliance-checker -lib NAME -dump DESC.xml
DESC.xml file is the following:
<version>
1.0
</version>
<headers>
/path(s)/to/headers
</headers>
<libs>
/path(s)/to/libraries
</libs>
The resulting ABI dump file will contain the information you need about symbols declared in header files (SymbolInfo) and symbols exported by shared libraries (Symbols).
You can also generate ABI dump in the xml format by adding --xml option.
If this is C, you can do something like:
printf("", /* insert all functions here */);
That should pass them all as function pointers to printf. The ones that do not exist should show up as linker errors.
(In C++, you would have to list overloads explicitly, which makes it a bit more difficult.)
I'd be inclined to use ctags to generate a list of identifiers from the header file then use ar, emfar or elfdump in Unix or lib.exe or dumpbin.exe in Windows (see discussion here) to dump a list of identifiers from the library and then sort and diff the two lists.
How can I locate a C library header file from a Makefile.PL?
There is ExtUtils::Liblist to find libraries, but I can't see the equivalent for header files.
Devel::CheckLib is what most authors seem to be use for that. It checks both for the existance of libraries as well as header files, as those libraries are probably useless without them.
Why not write a small lib to do this (and let it live in inc/lib/FindHeaders.pm or some such under the top level of your package dir). Just use Config (see incpath) along with File::Find and glob and you should be able to have a small library which can walk your default include path and map a hash of header files on your system, returning it to a call from Makefile.PL. It would be trivial to extend this to include non-standard include paths as well with a constructor argument to your lib. Easy peasy.