On Wed, Jul 22, 2020 at 2:38 PM Alex Cohn <alexc...@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 _______________________________________________ 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".