Yes, I would definitely be glad to join forces. That's true that the fd will be closed with the stream, or when the owning ParcelFileDescritpor is closed. But what decides when the stream/ParcelFileDescritpor can be closed? With `file:` protocol, it's very natural that avformat closes the fd when it's done with it. Here, we must manage the timespan of a Java object… Not nice, IMO.
I wonder what overhead Java implementation of AVIOContext introduces, but crossing the JNI border for every `read_packet()` may not be negligible. I believe that the performance price of AVIOContext which simply calls read(), write(), and lseek() on an `fd` is minimal, but even this must be measured carefully to compare with the original `file:` protocol. Sincerely, Alex Cohn On Mon, Jul 27, 2020 at 4:45 PM Olivier Ayache <olivier.aya...@gmail.com> wrote: > > You're welcome. > > Can I suggest you to try IContainer.open with InputStream/OutputStream. If > you use a FileInputStream created from the file descriptor retrieved with > https://developer.android.com/reference/android/content/Intent#ACTION_OPEN_DOCUMENT > Normally fd will be automatically closed by the stream. > > If you're interested we could work together on this because I also need to > implement this type of feature for my projects. > > Best > > Olivier > > Le lun. 27 juil. 2020 à 14:46, Alex Cohn <alexc...@netvision.net.il> a > écrit : > > > Thanks Olivier, > > > > Custom IO looks like a nice way to work around the protocol > > limitations. Unfortunately, it cannot work with avio_open(), so the > > API becomes trickier for end users. > > > > Also, just like with pipes, I cannot reliably close the file > > descriptor when ffmpeg execution is over, can I? > > > > BR, > > Alex Cohn > > > > On Mon, Jul 27, 2020 at 11:01 AM Olivier Ayache > > <olivier.aya...@gmail.com> wrote: > > > > > > A good alternative to work with FFmpeg on Android is Xuggler, it presents > > > FFmpeg's API directly to Java/Kotlin. > > > > > > To deal with fd you can declare and implement your own IO handler by > > > implementing > > > > > https://github.com/olivierayache/xuggle-xuggler/blob/ffmpeg-3.x-dev/src/com/xuggle/xuggler/io/IURLProtocolHandler.java > > > > > > I currently maintain a fork which is fully working on Android (work in > > > progress for iOS with Kotlin multiplatform). > > > > > > https://github.com/olivierayache/xuggle-xuggler > > > > > > Best > > > > > > Olivier Ayache > > > > > > Le dim. 26 juil. 2020 à 23:16, Alex Cohn <alexc...@netvision.net.il> a > > > écrit : > > > > > > > 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". > > > _______________________________________________ > > > 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". > > _______________________________________________ > > 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". > _______________________________________________ > 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". _______________________________________________ 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".
