[FFmpeg-devel] working with file descriptors on Android

[Alex Cohn]

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