Concurrency and Logging

FFmpegKit associates native log and statistics messages with the session that is active in the current native execution thread. The native layer stores the active session ID in thread-local state and uses that ID when forwarding messages to session history and session-specific callbacks.

Threading Requirement

Do not run more than one native FFmpegKit session concurrently on the same execution thread.

If a second session starts on the same thread before the first session has finished producing native messages, the thread-local session context can be overwritten. When that happens, logs or statistics from the earlier session may be attached to the newer session and delivered to the newer session's callback.

Recommended Usage

For normal concurrent execution, use the default asynchronous APIs:

• Android: FFmpegKit.executeAsync(...), FFprobeKit.executeAsync(...), and the async media-information APIs use the library's internal executor
• Apple platforms: the default async APIs use the library's default dispatch queue
• Linux: the default async APIs run each session on its own native thread

If you provide your own scheduler, make sure each concurrently running session has its own worker thread:

• On Android, a custom ExecutorService must have enough worker threads for the maximum number of sessions you allow to run at the same time
• On Apple platforms, a custom dispatch_queue_t must allow concurrent sessions to execute on separate worker threads. A serial queue is fine only when you intentionally want sessions to run one at a time
• Synchronous execute(...) runs on the caller's thread. If you need parallel synchronous executions, start each execution from a different thread

Scope

This applies to native FFmpegKit and FFmpegKitNext APIs that execute FFmpeg, FFprobe, or media-information sessions directly, including Android, iOS, iPadOS, macOS, tvOS, visionOS, and Linux. The same threading constraint also applies to legacy native FFmpegKit versions such as 6.0.

Flutter and React Native users normally do not need to manage this directly, because the plugins route execution through their native scheduling layer. This warning matters for hybrid apps only if you modify the plugin's native code or bypass the plugin and call the native APIs yourself.