Re: [FFmpeg-devel] [PATCH 2/7] avutil: add av_jni_{get, set}_android_app_ctx helper

2024-02-27 Thread Matthieu Bouron 
On Tue, Feb 27, 2024 at 02:42:01PM +0100, Andreas Rheinhardt wrote:
> Matthieu Bouron:
> > This will allow users to pass the Android ApplicationContext which is 
> > mandatory
> > to retrieve the ContentResolver responsible to resolve/open Android 
> > content-uri.
> > ---
> >  libavutil/jni.c | 28 
> >  libavutil/jni.h | 17 +
> >  2 files changed, 45 insertions(+)
> > 
> > diff --git a/libavutil/jni.c b/libavutil/jni.c
> > index 541747cb20..d6f96717b0 100644
> > --- a/libavutil/jni.c
> > +++ b/libavutil/jni.c
> > @@ -34,6 +34,7 @@
> >  #include "libavutil/jni.h"
> >  
> >  static void *java_vm;
> > +static void *android_app_ctx;
> >  static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
> >  
> >  int av_jni_set_jvm(void *vm, void *log_ctx)
> > @@ -63,6 +64,24 @@ void *av_jni_get_jvm(void *log_ctx)
> >  return vm;
> >  }
> >  
> > +void av_jni_set_android_app_ctx(void *app_ctx)
> > +{
> > +pthread_mutex_lock(&lock);
> > +android_app_ctx = app_ctx;
> > +pthread_mutex_unlock(&lock);
> > +}
> > +
> > +void *av_jni_get_android_app_ctx(void)
> > +{
> > +void *ctx;
> > +
> > +pthread_mutex_lock(&lock);
> > +ctx = android_app_ctx;
> > +pthread_mutex_unlock(&lock);
> > +
> > +return ctx;
> > +}
> > +
> >  #else
> >  
> >  int av_jni_set_java_vm(void *vm, void *log_ctx)
> > @@ -75,4 +94,13 @@ void *av_jni_get_java_vm(void *log_ctx)
> >  return NULL;
> >  }
> >  
> > +void av_jni_set_android_app_ctx(void *app_ctx)
> > +{
> > +}
> > +
> > +void *av_jni_get_android_app_ctx(void)
> > +{
> > +return NULL;
> > +}
> > +
> >  #endif
> > diff --git a/libavutil/jni.h b/libavutil/jni.h
> > index 700960dbb8..630f4074a1 100644
> > --- a/libavutil/jni.h
> > +++ b/libavutil/jni.h
> > @@ -43,4 +43,21 @@ int av_jni_set_jvm(void *vm, void *log_ctx);
> >   */
> >  void *av_jni_get_jvm(void *log_ctx);
> >  
> > +/*
> > + * Set the Android application context which will be used to retrieve the 
> > Android
> > + * content resolver to resolve content uris.
> > + *
> > + * @param app_ctx global JNI reference to the Android application context
> > + */
> > +void av_jni_set_android_app_ctx(void *app_ctx);
> > +
> > +/*
> > + * Get the Android application context that has been set with
> > + * av_jni_set_android_app_ctx.
> > + *
> > + * @return a pointer the the Android application context
> > + */
> > +void *av_jni_get_android_app_ctx(void);
> > +
> > +
> >  #endif /* AVUTIL_JNI_H */
> 
> This adds global state in order to pass the application context to your
> protocol (in lieu of an option to pass pointers to a protocol). Can
> there be scenarios in which multiple application contexts are useful in
> the same process?

This is intended. In general, there is only one application context that
lives for the entire application lifetime. I don't think there is any
useful scenario where multiple application contexts are useful (and I
haven't encountered any), even while unit testing (where you can easily
craft multiple application contexts).

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

Re: [FFmpeg-devel] [PATCH 2/7] avutil: add av_jni_{get, set}_android_app_ctx helper

2024-02-27 Thread Andreas Rheinhardt 
Matthieu Bouron:
> This will allow users to pass the Android ApplicationContext which is 
> mandatory
> to retrieve the ContentResolver responsible to resolve/open Android 
> content-uri.
> ---
>  libavutil/jni.c | 28 
>  libavutil/jni.h | 17 +
>  2 files changed, 45 insertions(+)
> 
> diff --git a/libavutil/jni.c b/libavutil/jni.c
> index 541747cb20..d6f96717b0 100644
> --- a/libavutil/jni.c
> +++ b/libavutil/jni.c
> @@ -34,6 +34,7 @@
>  #include "libavutil/jni.h"
>  
>  static void *java_vm;
> +static void *android_app_ctx;
>  static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
>  
>  int av_jni_set_jvm(void *vm, void *log_ctx)
> @@ -63,6 +64,24 @@ void *av_jni_get_jvm(void *log_ctx)
>  return vm;
>  }
>  
> +void av_jni_set_android_app_ctx(void *app_ctx)
> +{
> +pthread_mutex_lock(&lock);
> +android_app_ctx = app_ctx;
> +pthread_mutex_unlock(&lock);
> +}
> +
> +void *av_jni_get_android_app_ctx(void)
> +{
> +void *ctx;
> +
> +pthread_mutex_lock(&lock);
> +ctx = android_app_ctx;
> +pthread_mutex_unlock(&lock);
> +
> +return ctx;
> +}
> +
>  #else
>  
>  int av_jni_set_java_vm(void *vm, void *log_ctx)
> @@ -75,4 +94,13 @@ void *av_jni_get_java_vm(void *log_ctx)
>  return NULL;
>  }
>  
> +void av_jni_set_android_app_ctx(void *app_ctx)
> +{
> +}
> +
> +void *av_jni_get_android_app_ctx(void)
> +{
> +return NULL;
> +}
> +
>  #endif
> diff --git a/libavutil/jni.h b/libavutil/jni.h
> index 700960dbb8..630f4074a1 100644
> --- a/libavutil/jni.h
> +++ b/libavutil/jni.h
> @@ -43,4 +43,21 @@ int av_jni_set_jvm(void *vm, void *log_ctx);
>   */
>  void *av_jni_get_jvm(void *log_ctx);
>  
> +/*
> + * Set the Android application context which will be used to retrieve the 
> Android
> + * content resolver to resolve content uris.
> + *
> + * @param app_ctx global JNI reference to the Android application context
> + */
> +void av_jni_set_android_app_ctx(void *app_ctx);
> +
> +/*
> + * Get the Android application context that has been set with
> + * av_jni_set_android_app_ctx.
> + *
> + * @return a pointer the the Android application context
> + */
> +void *av_jni_get_android_app_ctx(void);
> +
> +
>  #endif /* AVUTIL_JNI_H */

This adds global state in order to pass the application context to your
protocol (in lieu of an option to pass pointers to a protocol). Can
there be scenarios in which multiple application contexts are useful in
the same process?

- Andreas

___
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] [PATCH 2/7] avutil: add av_jni_{get, set}_android_app_ctx helper

2024-02-13 Thread Matthieu Bouron 
This will allow users to pass the Android ApplicationContext which is mandatory
to retrieve the ContentResolver responsible to resolve/open Android content-uri.
---
 libavutil/jni.c | 28 
 libavutil/jni.h | 17 +
 2 files changed, 45 insertions(+)

diff --git a/libavutil/jni.c b/libavutil/jni.c
index 541747cb20..d6f96717b0 100644
--- a/libavutil/jni.c
+++ b/libavutil/jni.c
@@ -34,6 +34,7 @@
 #include "libavutil/jni.h"
 
 static void *java_vm;
+static void *android_app_ctx;
 static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
 
 int av_jni_set_jvm(void *vm, void *log_ctx)
@@ -63,6 +64,24 @@ void *av_jni_get_jvm(void *log_ctx)
 return vm;
 }
 
+void av_jni_set_android_app_ctx(void *app_ctx)
+{
+pthread_mutex_lock(&lock);
+android_app_ctx = app_ctx;
+pthread_mutex_unlock(&lock);
+}
+
+void *av_jni_get_android_app_ctx(void)
+{
+void *ctx;
+
+pthread_mutex_lock(&lock);
+ctx = android_app_ctx;
+pthread_mutex_unlock(&lock);
+
+return ctx;
+}
+
 #else
 
 int av_jni_set_java_vm(void *vm, void *log_ctx)
@@ -75,4 +94,13 @@ void *av_jni_get_java_vm(void *log_ctx)
 return NULL;
 }
 
+void av_jni_set_android_app_ctx(void *app_ctx)
+{
+}
+
+void *av_jni_get_android_app_ctx(void)
+{
+return NULL;
+}
+
 #endif
diff --git a/libavutil/jni.h b/libavutil/jni.h
index 700960dbb8..630f4074a1 100644
--- a/libavutil/jni.h
+++ b/libavutil/jni.h
@@ -43,4 +43,21 @@ int av_jni_set_jvm(void *vm, void *log_ctx);
  */
 void *av_jni_get_jvm(void *log_ctx);
 
+/*
+ * Set the Android application context which will be used to retrieve the 
Android
+ * content resolver to resolve content uris.
+ *
+ * @param app_ctx global JNI reference to the Android application context
+ */
+void av_jni_set_android_app_ctx(void *app_ctx);
+
+/*
+ * Get the Android application context that has been set with
+ * av_jni_set_android_app_ctx.
+ *
+ * @return a pointer the the Android application context
+ */
+void *av_jni_get_android_app_ctx(void);
+
+
 #endif /* AVUTIL_JNI_H */
-- 
2.43.1

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