Re: [FFmpeg-devel] Add protocol for Android content providers

[Matthieu Bouron <matthieu.bouron@gmail.com>]

On Thu, Feb 15, 2024 at 12:13:59PM +0800, Zhao Zhili wrote:
> 
> 
> > On Feb 14, 2024, at 06:50, Matthieu Bouron <matthieu.bouron@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.

I've been doing this kind of work for 3/4 users (including myself) at this
point and have to do it another time, this is what motivated me to propose
this patchset.

> 
> > 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.

The advantage I see of using this protocol is that the user only need to
call av_jni_set_jvm() + av_jni_set_android_app_ctx() at the start of the
application and FFmpeg will handle the content-uri transparently. This is
especially helpful if the Android application rely on multiple libraries
that in turn rely on FFmpeg to read medias.

> 
> > 
> > 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_.

What do you mean by "Unfortunately" ? Would you like to make the JNI API
public ?

[...]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".