permission is denied using Android Q ffmpeg": error=13, Permission denied
From Android Q onwards, you cannot execute binaries in your app's private data directory.
From the issuetracker: https://issuetracker.google.com/issues/128554619
The change to block exec() on application data files for targetAPI >= Q is working-as-intended. Please see https://android-review.googlesource.com/c/platform/system/sepolicy/+/804149 for background on this change. Calling exec() on writable application files is a W^X (https://en.wikipedia.org/wiki/W%5EX) violation and represents an unsafe application practice. Executable code should always be loaded from the application APK.
While exec() no longer works on files within the application home directory, it continues to be supported for files within the read-only /data/app directory. In particular, it should be possible to package the binaries into your application's native libs directory and enable android:extractNativeLibs=true, and then call exec() on the /data/app artifacts. A similar approach is done with the wrap.sh functionality, documented at https://developer.android.com/ndk/guides/wrap-script#packaging_wrapsh .
Additionally, please be aware that executables executed via exec() are not managed according to the Android process lifecycle, and generally speaking, exec() is discouraged from Android applications. While not Android documentation, Using "exec()" with NDK covers this in some detail. Relying on exec() may be problematic in future Android versions.
Change only on Build.gradle filetargetSdkVersion 29 to 28andRe-Install your app on your device - It is resolved your permission issue for temporary because of the targetSdkVersion 29 is required platform for released build on play store so I suggest to you use this library, It is support the target Sdk 30
https://github.com/SimformSolutionsPvtLtd/SSffmpegVideoOperation
The earlier answer correctly explains the problem you are hitting. This is also an open issue raised last September, discussed on the forum of the library you are using (from what I can see in the stack trace).
The solution to compile for SDK 29 would be to stop putting binaries in the /data/ directory, and ensure they are in the native libs directory. That can't be achieved after the APK is installed and unpacked on non-rooted devices, and so should be done correctly when preparing the Android project (e.g. through gradle settings), and to make sure that upon installation the contents get properly unpacked: android:extractNativeLibs=true.
In your case, this code moves binaries that are packaged as 'assets' into the users data directory:
That's a security concern running any executables in a location that is read/writeable. That source code I linked to above would need to be removed, instead, the native binaries packaged in /libs. The change is more secure as the /libs location inside your apps install directory is executable but not writable.
In summary, the 3rd party lib needs to address it, or you could do it and contribute a pull request. Or fork your own and recompile it for yourself.
There's still a problem, if your app actually downloads content after it is installed, and expects to execute any downloads. That's now impossible as far as I can tell in Android 10.
The future-proof solution is to stop using external binaries, and to compile the dependencies as NDK projects. They will need jni wrappers around native code (a bit of work). There is a related project I know of you could look into.