Usdx: ffmpeg 3.0 or newer not supported on windows

[basisbit]

Actual behaviour

The game crashes at startup showing a message stating it can't find the procedure "av_frame_free" and the the game closes.

Expected behaviour

The game should start and work just fine, playing audio and video files and so on.

Steps to reproduce

To prepare for the next release, I tried to update USDX to any somewhat recent ffmpeg library bundles. They are available here: https://ffmpeg.zeranoe.com/builds/win32/shared/

1. In the USDX/game folder, delete the old files avcodec-*.dll, avdevice-*.dll, avfilter-*.dll, avformat-*.dll, avutil-*.dll, postproc-*.dll, swresample-*.dll and swscale-*.dll
2. Unpack the zip/ffmpegVersion/bin/*.dll files into the USDX/game folder
3. Update the ffmpeg folder name, and various dll names and library versions in config-win.inc (you can get the library versions by checking the dll file property details in Windows Explorer)
4. Compile the game
5. run the compiled USDX/game/ultrastardx.exe

Details

• USDX version: today's master
• Operating System + version: current Windows 10
  I tried to fix this issue for a couple of hours and also tried to mess with the compiler DEFs in config-win.inc for FF_API_OLD_DECODE_AUDIO and HaveLibsamplerate without success.
  The only code in USDX which calls av_frame_free is in destructor TFFmpegDecodeStream.Destroy(); which the compiler does not stop at when adding a breakpoint there.

[s09bQ5]

FFmpeg 2.0 moved some functions like av_frame_free from libavcodec to libavutil. Our FFmpeg units still tell FPC that they are in libavcodec. On Windows the imports in a binary have to tell exactly which symbol is imported from which DLL. The linker on Windows does not search the DLLs. On Linux/macOS the linker looks into all libraries but doesn't record in the binary which shared library actually provided the symbol.

(The linker for C applications on Windows also doesn't look at the DLLs. For linking C applications on Windows there are usually static libraries with the same name as the DLLs that contain the pieces that have to be put into the imports section of the binary. So the linker doesn't even know about shared libraries.)

[basisbit]

thanks for the hint! Fixed with b584279