[FFmpeg-devel] working with file descriptors on Android

[Matthieu Bouron]

On Wed, Jul 22, 2020 at 2:38 PM Alex Cohn <alexcohn at netvision.net.il> 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