I've no idea what a "header file that created the header file in the first place" is. When a library developer publishes a library, they will typically release the binary library and a header file that defines the functions implemented by the library. They won't necessarily have used the header file to compile the library.
You don't even need to use the header file the developer released. All the compiler needs to know is the function prototype, and the linker needs to be able to find the symbol. So you could just stick "void LoadFile(char *fileName);" in at the top of test.c and it'll work fine. However it's usually more hassle to do that, and doesn't really provide many benefits, which is why we just take the easy way and #include "libffmpeg.h".
You certainly don't have to recompile a library in order to be able to use it. Linux nerds frequently want to, which is why "how to recompile the library" is usually on something like page 1 of the documentation instead of hidden in an appendix. But nobody would be able to release closed-source libraries if recompiling was necessary.
Dynamic linking doesn't make the software do anything you didn't specify. At runtime the program will attempt to load the shared library from PATH, LD_LIBRARY_PATH and/or SHLIB_PATH, depending on OS and how much of this I've got right, and the only complaint you'll get is if the library itself doesn't exist. It doesn't matter if any of those PATHs point to nonexistent locations.