Re: [FFmpeg-devel] working with file descriptors on Android
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 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 > 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 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 > > > 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 > a > > > > écrit : > > > > > > > > > On Sun, Jul 26, 2020 at 10:21 PM Martin Storsjö > > > 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 i
Re: [FFmpeg-devel] working with file descriptors on Android
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 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 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 > > 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 a > > > écrit : > > > > > > > On Sun, Jul 26, 2020 at 10:21 PM Martin Storsjö > > 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
Re: [FFmpeg-devel] working with file descriptors on Android
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 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 > 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 a > > écrit : > > > > > On Sun, Jul 26, 2020 at 10:21 PM Martin Storsjö > 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".
Re: [FFmpeg-devel] working with file descriptors on Android
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 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 a > écrit : > > > On Sun, Jul 26, 2020 at 10:21 PM Martin Storsjö 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".
Re: [FFmpeg-devel] working with file descriptors on Android
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 a écrit : > On Sun, Jul 26, 2020 at 10:21 PM Martin Storsjö 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".
Re: [FFmpeg-devel] working with file descriptors on Android
On Sun, Jul 26, 2020 at 10:21 PM Martin Storsjö 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".
Re: [FFmpeg-devel] working with file descriptors on Android
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...) On Sun, 26 Jul 2020, Alex Cohn wrote: If this is still out of scope, the alternatives are: - to patch the `file:` protocol, and let it understand that "/proc/self/69" should not be fopen()-ed but rather parsed to extract and use the number as FileContext->fd. - to create an `fd:` protocol (which will be equivalent to `pipe:` but with close() and seek()) - to extend the `pipe_options`, introducing `closeable` and `seekable` (off by default). Out of these, I definitely prefer the fd: protocol one. // Martin ___ 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".
Re: [FFmpeg-devel] working with file descriptors on Android
On Sat, Jul 25, 2020 at 9:37 PM Matthieu Bouron
wrote:
>
> On Wed, Jul 22, 2020 at 2:38 PM Alex Cohn
wrote:
>
> > Usually, we employ the `pipe:` protocol to deal with the numerical
> > file descriptors, and this answers all our needs. On Android, there is
> > a different use case in which numerical file descriptors appear, and
> > this is not covered well with `pipe:` protocol.
> >
> > This happens when a file is opened in scoped storage
> > (https://developer.android.com/training/data-storage#scoped-storage).
> > Currently, there is an exception that still allows `stdio.h` - based
> > access to the media files
> > (
> >
https://developer.android.com/preview/privacy/storage#media-files-raw-paths
> > ),
> > but the document says that it may be slow (we still cannot have true
> > evidence since Android 11 is not released yet), and anyways the clean
> > way to access media files on what is known as 'external storage' is
> > through a document picker Intent
> > (
> >
https://developer.android.com/reference/android/content/Intent#ACTION_OPEN_DOCUMENT
> > and
> >
https://developer.android.com/reference/android/content/Intent#ACTION_CREATE_DOCUMENT
> > ).
> >
> > The Intent produces a `content://` URI from which a DocumentProvider
> > can produce an integer file descriptor. This descriptor can be passed
> > to ffmpeg via pipe: protocol, and almost works, except for a few
> > glitches.
> >
> > 1. This fd must be closed after use. Pipe is not closeable.
> >
> > 2. This fd is seekable, and therefore can be used to work with `.mp4`
> > or some other file formats that don't work through pipe protocol.
> >
> > 3. We can find the actual file name extension for this fd, to
> > facilitate `av_guess_format()` both for input and for output.
> >
> > I have recently prepared two approaches to face this issue. One is an
> > easy patch for the `file:` protocol that recognizes the `/proc/self/`
> > prefix and uses the number as fd. This relies heavily on Java (or
> > Kotlin) processing of the results of document picker. The other way
> > adds a `content://` protocol and does all heavy lifting (calling
> > system Java API through JNI) itself.
> >
>
> Hi,
>
> I already submitted a patch for the second approach in 2015-2016
> (while submitting JNI support + MediaCodec). This approach was
> rejected because the project did not want to have jni support in
> libavutils but instead have it scoped to libavcodec with the decoder.
>
> Original thread:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180593.html
> The patch:
> https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg29451.html
>
> I use this patch in production at work (which contains a hack to import
jni
> support to libavformat):
>
https://github.com/Stupeflix/FFmpeg/commit/6d06b14939cb05e8a377d2ba14ed689b361f0303
>
> I don't know if the project has changed his mind regarding the java/jni
> stuff but I'd also like to upstream this feature (I think content uri
> support
> is a nice and useful feature for the Android platform).
>
> Best regards,
> Matthieu
> ___
> 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".
Thanks for sharing, Matthieu. Such discussions are poorly discoverable. I
have learned a lot from the thred starting with
https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg29498.html.
Recently, I pledged to have JNI_GetCreatedJavaVMs() properly documented and
exposed (https://github.com/android/ndk/issues/1320). It would be great if
you add your insights to that thread.
I agree that adaptation of the content Uri scheme should begin with
defining a policy of how JNI be contained in ffmpeg.
If this is still out of scope, the alternatives are:
- to patch the `file:` protocol, and let it understand that
"/proc/self/69" should not be fopen()-ed but rather parsed to extract and
use the number as FileContext->fd.
- to create an `fd:` protocol (which will be equivalent to `pipe:` but
with close() and seek())
- to extend the `pipe_options`, introducing `closeable` and `seekable`
(off by default).
IMO, easy access to the actual file name is also important, to keep
compatibility with av_guess_format(). Here is how I do it with `file:`
protocol:
public static String getCommandParameter(Context context, Uri uri) {
String displayName = "unknown";
Cursor cursor = context.getContentResolver().query(uri, null,
null, null, null);
try {
if (cursor != null && cursor.moveToFirst()) {
displayName =
cursor.getString(cursor.getColumnIndex(DocumentsContract.Document.COLUMN_DISPLAY_NAME));
}
} catch (Throwable ex) {
Log.e(TAG, "failed to get column", ex);
} finally {
if (cursor != null)
cursor.close();
}
int fd =
Re: [FFmpeg-devel] working with file descriptors on Android
On Wed, Jul 22, 2020 at 2:38 PM Alex Cohn wrote: > Usually, we employ the `pipe:` protocol to deal with the numerical > file descriptors, and this answers all our needs. On Android, there is > a different use case in which numerical file descriptors appear, and > this is not covered well with `pipe:` protocol. > > This happens when a file is opened in scoped storage > (https://developer.android.com/training/data-storage#scoped-storage). > Currently, there is an exception that still allows `stdio.h` - based > access to the media files > ( > https://developer.android.com/preview/privacy/storage#media-files-raw-paths > ), > but the document says that it may be slow (we still cannot have true > evidence since Android 11 is not released yet), and anyways the clean > way to access media files on what is known as 'external storage' is > through a document picker Intent > ( > https://developer.android.com/reference/android/content/Intent#ACTION_OPEN_DOCUMENT > and > https://developer.android.com/reference/android/content/Intent#ACTION_CREATE_DOCUMENT > ). > > The Intent produces a `content://` URI from which a DocumentProvider > can produce an integer file descriptor. This descriptor can be passed > to ffmpeg via pipe: protocol, and almost works, except for a few > glitches. > > 1. This fd must be closed after use. Pipe is not closeable. > > 2. This fd is seekable, and therefore can be used to work with `.mp4` > or some other file formats that don't work through pipe protocol. > > 3. We can find the actual file name extension for this fd, to > facilitate `av_guess_format()` both for input and for output. > > I have recently prepared two approaches to face this issue. One is an > easy patch for the `file:` protocol that recognizes the `/proc/self/` > prefix and uses the number as fd. This relies heavily on Java (or > Kotlin) processing of the results of document picker. The other way > adds a `content://` protocol and does all heavy lifting (calling > system Java API through JNI) itself. > Hi, I already submitted a patch for the second approach in 2015-2016 (while submitting JNI support + MediaCodec). This approach was rejected because the project did not want to have jni support in libavutils but instead have it scoped to libavcodec with the decoder. Original thread: https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180593.html The patch: https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg29451.html I use this patch in production at work (which contains a hack to import jni support to libavformat): https://github.com/Stupeflix/FFmpeg/commit/6d06b14939cb05e8a377d2ba14ed689b361f0303 I don't know if the project has changed his mind regarding the java/jni stuff but I'd also like to upstream this feature (I think content uri support is a nice and useful feature for the Android platform). Best regards, Matthieu ___ 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] working with file descriptors on Android
Usually, we employ the `pipe:` protocol to deal with the numerical file descriptors, and this answers all our needs. On Android, there is a different use case in which numerical file descriptors appear, and this is not covered well with `pipe:` protocol. This happens when a file is opened in scoped storage (https://developer.android.com/training/data-storage#scoped-storage). Currently, there is an exception that still allows `stdio.h` - based access to the media files (https://developer.android.com/preview/privacy/storage#media-files-raw-paths), but the document says that it may be slow (we still cannot have true evidence since Android 11 is not released yet), and anyways the clean way to access media files on what is known as 'external storage' is through a document picker Intent (https://developer.android.com/reference/android/content/Intent#ACTION_OPEN_DOCUMENT and https://developer.android.com/reference/android/content/Intent#ACTION_CREATE_DOCUMENT). The Intent produces a `content://` URI from which a DocumentProvider can produce an integer file descriptor. This descriptor can be passed to ffmpeg via pipe: protocol, and almost works, except for a few glitches. 1. This fd must be closed after use. Pipe is not closeable. 2. This fd is seekable, and therefore can be used to work with `.mp4` or some other file formats that don't work through pipe protocol. 3. We can find the actual file name extension for this fd, to facilitate `av_guess_format()` both for input and for output. I have recently prepared two approaches to face this issue. One is an easy patch for the `file:` protocol that recognizes the `/proc/self/` prefix and uses the number as fd. This relies heavily on Java (or Kotlin) processing of the results of document picker. The other way adds a `content://` protocol and does all heavy lifting (calling system Java API through JNI) itself. I would like to submit my contribution to ffmpeg-devel, but I am in doubt which of the two approaches may better fit the ffmpeg development paradigm, if any. Best Regards, 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".
