> On Feb 14, 2024, at 06:50, Matthieu Bouron <matthieu.bou...@gmail.com> wrote: > > Hi, > > On Android, content providers are used for accessing files through shared > mechanisms. One typical case would be an app willing to open a video from > Google Photos, gallery apps, TikTok, Instagram or some other providers. > A content URI looks something like "content://authority/path/id", see: > https://developer.android.com/reference/android/content/ContentUris > https://developer.android.com/guide/topics/providers/content-provider-basics > > It can currently be somehow managed through clumsy means such as using a "fd:" > filename and crafting a special AVOption, which also has the drawback of > requiring the third party to carry around opened file descriptors (with the > multiple opened file limitations implied). Custom AVIOContexts are also an
File descriptor is a general abstraction layer, it target more platforms than Android specific content provider. Android provided getFd() API since API level 12, I guess that’s the default method to deal with content provider in native code. It’s a few lines of code to get native fd in Java, but dozens of code in C with JNI, which is what this patchset done. For multiple opened file limitations issue, they can close the file descriptor after open. It’s unlikely to reach the limit in normal case without leak. I’m OK to provide this android_content_protocol helper if user requests. > option. Both options will have to deal with the JNI though and end users will > have to re-implement the same exact thing. User still need to deal with JNI with the new android_content_protocol, more or less, it’s unavoidable. > > This patchset addresses this by adding a content provider protocol, which has > an API fairly similar to fopen. Android 11 appears to provide something > transparent within fopen(), but FFmpeg doesn't use it in the file protocol, > and > Android < 11 are still widely used. > > The first part move the JNI infrastructure from avcodec to avutil (it remains > internally shared, there is little user implication), OK. JNI infrastructure should belong to avutil at the first place, so hwcontext_mediacodec and so on can use it. Unfortunately for those new avpriv_. > and then the URLProtocol > is added, along with a few cleanups. > > 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 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".