[FFmpeg-devel] Add protocol for Android content providers

[Zhao Zhili]

> On Feb 14, 2024, at 06:50, Matthieu Bouron <matthieu.bouron at 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 at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".