[FFmpeg-devel] working with file descriptors on Android

[Olivier Ayache]

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 <alexcohn at 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.ayache at 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 <alexcohn at 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.ayache at 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 <alexcohn at netvision.net.il>
> a
> > > > écrit :
> > > >
> > > > > On Sun, Jul 26, 2020 at 10:21 PM Martin Storsjö <martin at 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 at ffmpeg.org
> > > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > > >
> > > > > To unsubscribe, visit link above, or email
> > > > > ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> > > > _______________________________________________
> > > > ffmpeg-devel mailing list
> > > > ffmpeg-devel at ffmpeg.org
> > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > >
> > > > To unsubscribe, visit link above, or email
> > > > ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> > > _______________________________________________
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel at ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> > _______________________________________________
> > ffmpeg-devel mailing list
> > ffmpeg-devel at ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".