GetMetaDataAsync not thread-safe?
I have observed that occasionally Engine.GetMetaDataAsync() is returning null. I can replicate this in a test, running this method a number of times in parallel for different mp4 files.
I was previously sharing the same Engine instance but am observing the same behaviour when creating an instance per invocation.
Is this method not thread-safe? Or is the actual issue that the underlying FFMpeg executable itself isn't thread-safe? I'm using the latest official Windows build; configuration below:
ffmpeg version 4.1.3 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 8.3.1 (GCC) 20190414
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth
I am using FFmpeg.NET version 3.3.1.
i know this issue has been here for a long time, but i still need some time to verify.
I've had a look at the code handling the ffmpeg process and couldn't find anything that has a concurrency problem / race condition in there. The ffmpeg tool is spawned as separate process and should be independent of each other (and each Engine). he reading / closing of the output data of the ffmpeg process seems fine to me too looking at the source code of the dotnet core framework. I will further investigate as I'm planning to read metadata in a parallel fashion too.