On Sun, Jul 26, 2020 at 10:21 PM Martin Storsjö <mar...@martin.st> wrote: > > Hi, > > Without having too much opinion on the JNI stuff (direct access to > content:// urls might be convenient, but on the other hand, it's not > really something you'd end up with if using the command line tool on its > own - if you have one of those you most probably have some java code for > getting it anyway - as far as I remember...)
You are more than right, Martin. None of these approaches can work with a command line tool. Worse, running a command line tool in the context of an Android app is becoming trickier with every new release of the platform, and in this case I cannot blame it on poor engineering. This happens because Google tries to tighten the security on Android just as much as possible. There is a nice cross-platform alternative, though. https://github.com/tanersener/mobile-ffmpeg provides Java and Objective-C APIs to run ffmpeg shared library "as if it were an executable": it can receive the input as a string which mimics the ffmpeg (and ffprobe) command line, and the output to stdout and stderr is captured and passed back to the mobile app. In this scenario, it's easy to get a `content:` URI by conventional Android SAF (structured access framework) API in Java and pass it as string or as a derived file descriptor (converted to string) to the command line parser that will eventually call protocol->url_open(). The latest release (Android Q a.k.a. Android 10, also API 29) made yet another small step in this direction and caused lots of problems for apps that rely upon file access by path. This was the incentive for me to work on the ways to teach avformat to work with the `content:` URIs correctly. BR, Alex Cohn _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
