You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
I have observed that occasionally
Engine.GetMetaDataAsync()
is returningnull
. 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:
I am using FFmpeg.NET version 3.3.1.
The text was updated successfully, but these errors were encountered: