When you close IContainer with InputStream. It will be automatically close. You can see Implementation here https://github.com/olivierayache/xuggle-xuggler/blob/ffmpeg-3.x-dev/src/com/xuggle/xuggler/io/InputOutputStreamHandler.java
For the JNI overhead it must be measured but normally by working with native byte buffers it should be limited. Best Olivier Le lun. 27 juil. 2020 à 17:02, Alex Cohn <alexc...@netvision.net.il> a écrit : > 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". _______________________________________________ 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".