Re: [FFmpeg-devel] [PATCH] avcodec/jni: fix mixed declaration and code

2024-04-21 Thread Matthieu Bouron
On Mon, Apr 15, 2024 at 07:02:36PM +0200, Matthieu Bouron wrote:
> On Thu, Apr 04, 2024 at 10:07:25PM +0200, Matthieu Bouron wrote:
> > ---
> >  libavcodec/jni.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/jni.c b/libavcodec/jni.c
> > index 1193c608c3..fcb4837413 100644
> > --- a/libavcodec/jni.c
> > +++ b/libavcodec/jni.c
> > @@ -84,11 +84,13 @@ void *av_jni_get_java_vm(void *log_ctx)
> >  int av_jni_set_android_app_ctx(void *app_ctx, void *log_ctx)
> >  {
> >  #if CONFIG_JNI
> > +jobjectRefType type;
> > +
> >  JNIEnv *env = ff_jni_get_env(log_ctx);
> >  if (!env)
> >  return AVERROR(EINVAL);
> >  
> > -jobjectRefType type = (*env)->GetObjectRefType(env, app_ctx);
> > +type = (*env)->GetObjectRefType(env, app_ctx);
> >  if (type != JNIGlobalRefType) {
> >  av_log(log_ctx, AV_LOG_ERROR, "Application context must be passed 
> > as a global reference");
> >  return AVERROR(EINVAL);
> > -- 
> > 2.44.0
> > 
> 
> I will apply the patch in a few days if there is no objection.

Patch applied.

-- 
Matthieu B.
___
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] avcodec/jni: fix mixed declaration and code

2024-04-15 Thread Matthieu Bouron
On Thu, Apr 04, 2024 at 10:07:25PM +0200, Matthieu Bouron wrote:
> ---
>  libavcodec/jni.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/jni.c b/libavcodec/jni.c
> index 1193c608c3..fcb4837413 100644
> --- a/libavcodec/jni.c
> +++ b/libavcodec/jni.c
> @@ -84,11 +84,13 @@ void *av_jni_get_java_vm(void *log_ctx)
>  int av_jni_set_android_app_ctx(void *app_ctx, void *log_ctx)
>  {
>  #if CONFIG_JNI
> +jobjectRefType type;
> +
>  JNIEnv *env = ff_jni_get_env(log_ctx);
>  if (!env)
>  return AVERROR(EINVAL);
>  
> -jobjectRefType type = (*env)->GetObjectRefType(env, app_ctx);
> +type = (*env)->GetObjectRefType(env, app_ctx);
>  if (type != JNIGlobalRefType) {
>  av_log(log_ctx, AV_LOG_ERROR, "Application context must be passed as 
> a global reference");
>  return AVERROR(EINVAL);
> -- 
> 2.44.0
> 

I will apply the patch in a few days if there is no objection.


-- 
Matthieu B.
___
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] [RFC] Bump minimum required version of Android to 5.0

2024-04-12 Thread Matthieu Bouron
On Thu, Apr 11, 2024 at 2:17 PM Zhao Zhili  wrote:
>
> We don’t have a minimum required version of Android in FFmpeg.
> libavdevice/android_camera requires Android 7, Java MediaCodec
> requires Android 4.1, and NDK MediaCodec requires Android 5.0.
>
> Without an explicit version, it’s unclear for development and test.
>
> Android 5.0 is released in 2014, is it OK to bump the minimum required
> version to Android 5.0, or any other version you prefer?

I'm OK with bumping the requirements to 5.0, especially if that helps
with maintenance (I dont have nor work with devices < 8.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".


[FFmpeg-devel] [PATCH] avcodec/jni: fix mixed declaration and code

2024-04-04 Thread Matthieu Bouron
---
 libavcodec/jni.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/jni.c b/libavcodec/jni.c
index 1193c608c3..fcb4837413 100644
--- a/libavcodec/jni.c
+++ b/libavcodec/jni.c
@@ -84,11 +84,13 @@ void *av_jni_get_java_vm(void *log_ctx)
 int av_jni_set_android_app_ctx(void *app_ctx, void *log_ctx)
 {
 #if CONFIG_JNI
+jobjectRefType type;
+
 JNIEnv *env = ff_jni_get_env(log_ctx);
 if (!env)
 return AVERROR(EINVAL);
 
-jobjectRefType type = (*env)->GetObjectRefType(env, app_ctx);
+type = (*env)->GetObjectRefType(env, app_ctx);
 if (type != JNIGlobalRefType) {
 av_log(log_ctx, AV_LOG_ERROR, "Application context must be passed as a 
global reference");
 return AVERROR(EINVAL);
-- 
2.44.0

___
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 v2 1/1] avcodec, avformat/ffjni: fix duplicate JNI symbols

2024-04-04 Thread Matthieu Bouron
On Tue, Apr 02, 2024 at 02:55:16PM +0200, Matthieu Bouron wrote:
> On Mon, Apr 01, 2024 at 10:03:54AM +0200, Matthieu Bouron wrote:
> > On Wed, Mar 27, 2024 at 09:06:19AM -0400, Leo Izen wrote:
> > > Use SHLIBOBJS and STLIBOBJS in the Makefiles for avcodec and avformat,
> > > and add a stub ffjni.c to libavformat, which allows the symbols to be
> > > duplicated for shared builds but not static builds.
> > > 
> > > Signed-off-by: Leo Izen 
> > > ---
> > >  libavcodec/Makefile  |  1 +
> > >  libavformat/Makefile |  1 +
> > >  libavformat/ffjni.c  | 23 +++
> > >  libavformat/file.c   |  2 +-
> > >  4 files changed, 26 insertions(+), 1 deletion(-)
> > >  create mode 100644 libavformat/ffjni.c
> > > 
> > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > > index 9ce6d445c1..113adb22d5 100644
> > > --- a/libavcodec/Makefile
> > > +++ b/libavcodec/Makefile
> > > @@ -1068,6 +1068,7 @@ STLIBOBJS-$(CONFIG_ISO_MEDIA)  += 
> > > mpegaudiotabs.o
> > >  STLIBOBJS-$(CONFIG_FLV_MUXER)  += mpeg4audio_sample_rates.o
> > >  STLIBOBJS-$(CONFIG_HLS_DEMUXER)+= ac3_channel_layout_tab.o
> > >  STLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER) += jpegxl_parse.o
> > > +STLIBOBJS-$(CONFIG_JNI)+= ffjni.o
> > >  STLIBOBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER)   += jpegxl_parse.o
> > >  STLIBOBJS-$(CONFIG_MATROSKA_DEMUXER)   += mpeg4audio_sample_rates.o
> > >  STLIBOBJS-$(CONFIG_MOV_DEMUXER)+= ac3_channel_layout_tab.o
> > > diff --git a/libavformat/Makefile b/libavformat/Makefile
> > > index 44aa485029..a89df7e9a3 100644
> > > --- a/libavformat/Makefile
> > > +++ b/libavformat/Makefile
> > > @@ -728,6 +728,7 @@ SHLIBOBJS-$(CONFIG_ISO_MEDIA)+= 
> > > mpegaudiotabs.o
> > >  SHLIBOBJS-$(CONFIG_FLV_MUXER)+= mpeg4audio_sample_rates.o
> > >  SHLIBOBJS-$(CONFIG_HLS_DEMUXER)  += ac3_channel_layout_tab.o
> > >  SHLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER)+= jpegxl_parse.o
> > > +SHLIBOBJS-$(CONFIG_JNI)  += ffjni.o
> > >  SHLIBOBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER)  += jpegxl_parse.o
> > >  SHLIBOBJS-$(CONFIG_MATROSKA_DEMUXER) += mpeg4audio_sample_rates.o
> > >  SHLIBOBJS-$(CONFIG_MOV_DEMUXER)  += ac3_channel_layout_tab.o
> > > diff --git a/libavformat/ffjni.c b/libavformat/ffjni.c
> > > new file mode 100644
> > > index 00..2b1483cf42
> > > --- /dev/null
> > > +++ b/libavformat/ffjni.c
> > > @@ -0,0 +1,23 @@
> > > +/*
> > > + * JNI utility functions - included stub
> > > + *
> > > + * Copyright (c) 2024 Leo Izen 
> > > + *
> > > + * This file is part of FFmpeg.
> > > + *
> > > + * FFmpeg is free software; you can redistribute it and/or
> > > + * modify it under the terms of the GNU Lesser General Public
> > > + * License as published by the Free Software Foundation; either
> > > + * version 2.1 of the License, or (at your option) any later version.
> > > + *
> > > + * FFmpeg is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > > + * Lesser General Public License for more details.
> > > + *
> > > + * You should have received a copy of the GNU Lesser General Public
> > > + * License along with FFmpeg; if not, write to the Free Software
> > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
> > > 02110-1301 USA
> > > + */
> > > +
> > > +#include "libavcodec/ffjni.c"
> > > diff --git a/libavformat/file.c b/libavformat/file.c
> > > index 182995717a..1f853e0e17 100644
> > > --- a/libavformat/file.c
> > > +++ b/libavformat/file.c
> > > @@ -527,8 +527,8 @@ const URLProtocol ff_fd_protocol = {
> > >  
> > >  #if CONFIG_ANDROID_CONTENT_PROTOCOL
> > >  #include 
> > > +#include "libavcodec/ffjni.h"
> > >  #include "libavcodec/jni.h"
> > > -#include "libavcodec/ffjni.c"
> > >  
> > >  typedef struct JFields {
> > >  jclass uri_class;
> > 
> > LGTM, thanks.
> 
> Once the patch is applied. Can you also backport it to the 7.0 branch ?
> 
> Thanks in advance,

Applied and backported.

-- 
Matthieu B.
___
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 v2 1/1] avcodec, avformat/ffjni: fix duplicate JNI symbols

2024-04-02 Thread Matthieu Bouron
On Mon, Apr 01, 2024 at 10:03:54AM +0200, Matthieu Bouron wrote:
> On Wed, Mar 27, 2024 at 09:06:19AM -0400, Leo Izen wrote:
> > Use SHLIBOBJS and STLIBOBJS in the Makefiles for avcodec and avformat,
> > and add a stub ffjni.c to libavformat, which allows the symbols to be
> > duplicated for shared builds but not static builds.
> > 
> > Signed-off-by: Leo Izen 
> > ---
> >  libavcodec/Makefile  |  1 +
> >  libavformat/Makefile |  1 +
> >  libavformat/ffjni.c  | 23 +++
> >  libavformat/file.c   |  2 +-
> >  4 files changed, 26 insertions(+), 1 deletion(-)
> >  create mode 100644 libavformat/ffjni.c
> > 
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 9ce6d445c1..113adb22d5 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -1068,6 +1068,7 @@ STLIBOBJS-$(CONFIG_ISO_MEDIA)  += 
> > mpegaudiotabs.o
> >  STLIBOBJS-$(CONFIG_FLV_MUXER)  += mpeg4audio_sample_rates.o
> >  STLIBOBJS-$(CONFIG_HLS_DEMUXER)+= ac3_channel_layout_tab.o
> >  STLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER) += jpegxl_parse.o
> > +STLIBOBJS-$(CONFIG_JNI)+= ffjni.o
> >  STLIBOBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER)   += jpegxl_parse.o
> >  STLIBOBJS-$(CONFIG_MATROSKA_DEMUXER)   += mpeg4audio_sample_rates.o
> >  STLIBOBJS-$(CONFIG_MOV_DEMUXER)+= ac3_channel_layout_tab.o
> > diff --git a/libavformat/Makefile b/libavformat/Makefile
> > index 44aa485029..a89df7e9a3 100644
> > --- a/libavformat/Makefile
> > +++ b/libavformat/Makefile
> > @@ -728,6 +728,7 @@ SHLIBOBJS-$(CONFIG_ISO_MEDIA)+= 
> > mpegaudiotabs.o
> >  SHLIBOBJS-$(CONFIG_FLV_MUXER)+= mpeg4audio_sample_rates.o
> >  SHLIBOBJS-$(CONFIG_HLS_DEMUXER)  += ac3_channel_layout_tab.o
> >  SHLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER)+= jpegxl_parse.o
> > +SHLIBOBJS-$(CONFIG_JNI)  += ffjni.o
> >  SHLIBOBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER)  += jpegxl_parse.o
> >  SHLIBOBJS-$(CONFIG_MATROSKA_DEMUXER) += mpeg4audio_sample_rates.o
> >  SHLIBOBJS-$(CONFIG_MOV_DEMUXER)  += ac3_channel_layout_tab.o
> > diff --git a/libavformat/ffjni.c b/libavformat/ffjni.c
> > new file mode 100644
> > index 00..2b1483cf42
> > --- /dev/null
> > +++ b/libavformat/ffjni.c
> > @@ -0,0 +1,23 @@
> > +/*
> > + * JNI utility functions - included stub
> > + *
> > + * Copyright (c) 2024 Leo Izen 
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
> > 02110-1301 USA
> > + */
> > +
> > +#include "libavcodec/ffjni.c"
> > diff --git a/libavformat/file.c b/libavformat/file.c
> > index 182995717a..1f853e0e17 100644
> > --- a/libavformat/file.c
> > +++ b/libavformat/file.c
> > @@ -527,8 +527,8 @@ const URLProtocol ff_fd_protocol = {
> >  
> >  #if CONFIG_ANDROID_CONTENT_PROTOCOL
> >  #include 
> > +#include "libavcodec/ffjni.h"
> >  #include "libavcodec/jni.h"
> > -#include "libavcodec/ffjni.c"
> >  
> >  typedef struct JFields {
> >  jclass uri_class;
> 
> LGTM, thanks.

Once the patch is applied. Can you also backport it to the 7.0 branch ?

Thanks in advance,

-- 
Matthieu B.
___
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 v2 1/1] avcodec, avformat/ffjni: fix duplicate JNI symbols

2024-04-01 Thread Matthieu Bouron
On Wed, Mar 27, 2024 at 09:06:19AM -0400, Leo Izen wrote:
> Use SHLIBOBJS and STLIBOBJS in the Makefiles for avcodec and avformat,
> and add a stub ffjni.c to libavformat, which allows the symbols to be
> duplicated for shared builds but not static builds.
> 
> Signed-off-by: Leo Izen 
> ---
>  libavcodec/Makefile  |  1 +
>  libavformat/Makefile |  1 +
>  libavformat/ffjni.c  | 23 +++
>  libavformat/file.c   |  2 +-
>  4 files changed, 26 insertions(+), 1 deletion(-)
>  create mode 100644 libavformat/ffjni.c
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 9ce6d445c1..113adb22d5 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -1068,6 +1068,7 @@ STLIBOBJS-$(CONFIG_ISO_MEDIA)  += 
> mpegaudiotabs.o
>  STLIBOBJS-$(CONFIG_FLV_MUXER)  += mpeg4audio_sample_rates.o
>  STLIBOBJS-$(CONFIG_HLS_DEMUXER)+= ac3_channel_layout_tab.o
>  STLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER) += jpegxl_parse.o
> +STLIBOBJS-$(CONFIG_JNI)+= ffjni.o
>  STLIBOBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER)   += jpegxl_parse.o
>  STLIBOBJS-$(CONFIG_MATROSKA_DEMUXER)   += mpeg4audio_sample_rates.o
>  STLIBOBJS-$(CONFIG_MOV_DEMUXER)+= ac3_channel_layout_tab.o
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 44aa485029..a89df7e9a3 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -728,6 +728,7 @@ SHLIBOBJS-$(CONFIG_ISO_MEDIA)+= 
> mpegaudiotabs.o
>  SHLIBOBJS-$(CONFIG_FLV_MUXER)+= mpeg4audio_sample_rates.o
>  SHLIBOBJS-$(CONFIG_HLS_DEMUXER)  += ac3_channel_layout_tab.o
>  SHLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER)+= jpegxl_parse.o
> +SHLIBOBJS-$(CONFIG_JNI)  += ffjni.o
>  SHLIBOBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER)  += jpegxl_parse.o
>  SHLIBOBJS-$(CONFIG_MATROSKA_DEMUXER) += mpeg4audio_sample_rates.o
>  SHLIBOBJS-$(CONFIG_MOV_DEMUXER)  += ac3_channel_layout_tab.o
> diff --git a/libavformat/ffjni.c b/libavformat/ffjni.c
> new file mode 100644
> index 00..2b1483cf42
> --- /dev/null
> +++ b/libavformat/ffjni.c
> @@ -0,0 +1,23 @@
> +/*
> + * JNI utility functions - included stub
> + *
> + * Copyright (c) 2024 Leo Izen 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "libavcodec/ffjni.c"
> diff --git a/libavformat/file.c b/libavformat/file.c
> index 182995717a..1f853e0e17 100644
> --- a/libavformat/file.c
> +++ b/libavformat/file.c
> @@ -527,8 +527,8 @@ const URLProtocol ff_fd_protocol = {
>  
>  #if CONFIG_ANDROID_CONTENT_PROTOCOL
>  #include 
> +#include "libavcodec/ffjni.h"
>  #include "libavcodec/jni.h"
> -#include "libavcodec/ffjni.c"
>  
>  typedef struct JFields {
>  jclass uri_class;

LGTM, thanks.

-- 
Matthieu B.
___
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] Changelog: add Android content URIs protocol entry

2024-03-26 Thread Matthieu Bouron
On Tue, Mar 26, 2024 at 04:30:53PM +0100, Stefano Sabatini wrote:
> On date Monday 2024-03-25 09:14:15 +0100, Matthieu Bouron wrote:
> > ---
> >  Changelog | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Changelog b/Changelog
> > index 934241a965..e4373ff991 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -37,6 +37,7 @@ version :
> >  - Support PacketTypeMetadata of PacketType in enhanced flv format
> >  - ffplay with hwaccel decoding support (depends on vulkan renderer via 
> > libplacebo)
> >  - dnn filter libtorch backend
> > +- Android content URIs protocol
> 
> Obviously LGTM.

Patch applied. Thanks.

> 
> BTW it would be good to document it in doc/protocols.texi.

Will send a patch in the upcoming days.

-- 
Matthieu B.
___
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] Changelog: add Android content URIs protocol entry

2024-03-25 Thread Matthieu Bouron
---
 Changelog | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Changelog b/Changelog
index 934241a965..e4373ff991 100644
--- a/Changelog
+++ b/Changelog
@@ -37,6 +37,7 @@ version :
 - Support PacketTypeMetadata of PacketType in enhanced flv format
 - ffplay with hwaccel decoding support (depends on vulkan renderer via 
libplacebo)
 - dnn filter libtorch backend
+- Android content URIs protocol
 
 
 version 6.1:
-- 
2.44.0

___
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 1/2] avformat/file: Constify android content protocol

2024-03-25 Thread Matthieu Bouron
On Mon, Mar 25, 2024 at 02:55:32AM +0100, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
> > (The discrepancy between the definition and the declaration
> > in protocols.c is actually UB.)
> > 
> > Signed-off-by: Andreas Rheinhardt 
> > ---
> > This and the next patch have not been tested (apart from "it compiles
> > when the android content protocol is disabled").
> > 
> >  libavformat/file.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/file.c b/libavformat/file.c
> > index dd5819c06f..8f3b35c795 100644
> > --- a/libavformat/file.c
> > +++ b/libavformat/file.c
> > @@ -670,7 +670,7 @@ done:
> >  return ret;
> >  }
> >  
> > -URLProtocol ff_android_content_protocol = {
> > +const URLProtocol ff_android_content_protocol = {
> >  .name= "content",
> >  .url_open= android_content_open,
> >  .url_read= file_read,
> 
> Will apply this patchset tomorrow unless there are objections.

Patchset tested locally and working as intended. LGTM.
Thanks.

-- 
Matthieu B.
___
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] avcodec, avformat/ffjni: fix duplicate JNI symbols

2024-03-24 Thread Matthieu Bouron
On Sun, Mar 24, 2024 at 01:17:41AM -0400, Leo Izen wrote:
> Use SHLIBOBJS and STLIBOBJS in the Makefiles for avcodec and avformat,
> and add a stub ffjni.c to libavformat, which allows the symbols to be
> duplicated for shared builds but not static builds.
> 
> Signed-off-by: Leo Izen 
> ---
>  libavcodec/Makefile  |  1 +
>  libavformat/Makefile |  1 +
>  libavformat/ffjni.c  | 23 +++
>  libavformat/file.c   |  2 +-
>  4 files changed, 26 insertions(+), 1 deletion(-)
>  create mode 100644 libavformat/ffjni.c
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 7ef2e03ca6..2446db51fd 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -1068,6 +1068,7 @@ STLIBOBJS-$(CONFIG_ISO_MEDIA)  += 
> mpegaudiotabs.o
>  STLIBOBJS-$(CONFIG_FLV_MUXER)  += mpeg4audio_sample_rates.o
>  STLIBOBJS-$(CONFIG_HLS_DEMUXER)+= ac3_channel_layout_tab.o
>  STLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER) += jpegxl_parse.o
> +STLIBOBJS-$(CONFIG_JNI)+= ffjni.o
>  STLIBOBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER)   += jpegxl_parse.o
>  STLIBOBJS-$(CONFIG_MATROSKA_DEMUXER)   += mpeg4audio_sample_rates.o
>  STLIBOBJS-$(CONFIG_MOV_DEMUXER)+= ac3_channel_layout_tab.o
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 44aa485029..a89df7e9a3 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -728,6 +728,7 @@ SHLIBOBJS-$(CONFIG_ISO_MEDIA)+= 
> mpegaudiotabs.o
>  SHLIBOBJS-$(CONFIG_FLV_MUXER)+= mpeg4audio_sample_rates.o
>  SHLIBOBJS-$(CONFIG_HLS_DEMUXER)  += ac3_channel_layout_tab.o
>  SHLIBOBJS-$(CONFIG_IMAGE_JPEGXL_PIPE_DEMUXER)+= jpegxl_parse.o
> +SHLIBOBJS-$(CONFIG_JNI)  += ffjni.o
>  SHLIBOBJS-$(CONFIG_JPEGXL_ANIM_DEMUXER)  += jpegxl_parse.o
>  SHLIBOBJS-$(CONFIG_MATROSKA_DEMUXER) += mpeg4audio_sample_rates.o
>  SHLIBOBJS-$(CONFIG_MOV_DEMUXER)  += ac3_channel_layout_tab.o
> diff --git a/libavformat/ffjni.c b/libavformat/ffjni.c
> new file mode 100644
> index 00..2b1483cf42
> --- /dev/null
> +++ b/libavformat/ffjni.c
> @@ -0,0 +1,23 @@
> +/*
> + * JNI utility functions - included stub
> + *
> + * Copyright (c) 2024 Leo Izen 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "libavcodec/ffjni.c"
> diff --git a/libavformat/file.c b/libavformat/file.c
> index dd5819c06f..fa13ae9a6c 100644
> --- a/libavformat/file.c
> +++ b/libavformat/file.c
> @@ -43,7 +43,7 @@
>  #if CONFIG_ANDROID_CONTENT_PROTOCOL
>  #include 
>  #include "libavcodec/jni.h"
> -#include "libavcodec/ffjni.c"
> +#include "libavcodec/ffjni.h"
>  #endif
>  
>  
> -- 
> 2.44.0

LGTM. Sorry for the regression.
___
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] Add protocol for Android content providers (v4)

2024-03-23 Thread Matthieu Bouron
On Tue, Mar 19, 2024 at 06:49:43PM +0100, Matthieu Bouron wrote:
> On Sun, Mar 17, 2024 at 11:28:31PM +0100, Matthieu Bouron wrote:
> > Diff with previous iteration:
> > - rebaed on latest master
> > - applied feedback from Zhao (removed HAVE_SETMODE block, use a typedef 
> > struct,
> >   check that the fd is seekable, moved doc/APIChanges changes to the right
> >   commit)
> > 
> 
> I will push the patchset in a few days if there is no other comment (nor
> any objection).

Patchset applied (with a few rewords on the commit msgs).

-- 
Matthieu B.
___
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] Add protocol for Android content providers (v4)

2024-03-19 Thread Matthieu Bouron
On Sun, Mar 17, 2024 at 11:28:31PM +0100, Matthieu Bouron wrote:
> Diff with previous iteration:
> - rebaed on latest master
> - applied feedback from Zhao (removed HAVE_SETMODE block, use a typedef 
> struct,
>   check that the fd is seekable, moved doc/APIChanges changes to the right
>   commit)
> 

I will push the patchset in a few days if there is no other comment (nor
any objection).

-- 
Matthieu B.

___
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 v4 1/6] avcodec: add av_jni_{get, set}_android_app_ctx helper

2024-03-17 Thread Matthieu Bouron
On Sun, Mar 17, 2024 at 11:38 PM 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.
> > ---
> >  doc/APIchanges   |  3 +++
> >  libavcodec/jni.c | 42 ++
> >  libavcodec/jni.h | 17 +
> >  3 files changed, 62 insertions(+)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index a44c8e4f10..ae1868047e 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -2,6 +2,9 @@ The last version increases of all libraries were on 
> > 2024-03-07
> >
> >  API changes, most recent first:
> >
> > +2024-03-xx - xx - lavc 61.2.100 - jni.h
> > +  Add av_jni_set_android_app_ctx() and av_jni_get_android_app_ctx().
> > +
> >  2024-03-xx - xx - lavu 59.2.100 - channel_layout.h
> >Add AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL.
> >
> > diff --git a/libavcodec/jni.c b/libavcodec/jni.c
> > index ae6490de9d..cfe95bd1ec 100644
> > --- a/libavcodec/jni.c
> > +++ b/libavcodec/jni.c
> > @@ -77,3 +77,45 @@ void *av_jni_get_java_vm(void *log_ctx)
> >  }
> >
> >  #endif
> > +
> > +#if defined(__ANDROID__)
> > +
> > +int av_jni_set_android_app_ctx(void *app_ctx, void *log_ctx)
> > +{
> > +#if CONFIG_JNI
> > +JNIEnv *env = ff_jni_get_env(log_ctx);
> > +if (!env)
> > +return AVERROR(EINVAL);
> > +
> > +jobjectRefType type = (*env)->GetObjectRefType(env, app_ctx);
> > +if (type != JNIGlobalRefType) {
> > +av_log(log_ctx, AV_LOG_ERROR, "Application context must be passed 
> > as a global reference");
> > +return AVERROR(EINVAL);
> > +}
> > +
> > +pthread_mutex_lock();
> > +android_app_ctx = app_ctx;
> > +pthread_mutex_unlock();
> > +
> > +return 0;
> > +#else
> > +return AVERROR(ENOSYS);
> > +#endif
> > +}
> > +
> > +void *av_jni_get_android_app_ctx(void)
> > +{
> > +#if CONFIG_JNI
> > +void *ctx;
> > +
> > +pthread_mutex_lock();
> > +ctx = android_app_ctx;
> > +pthread_mutex_unlock();
> > +
> > +return ctx;
> > +#else
> > +return NULL;
> > +#endif
> > +}
> > +
> > +#endif
> > diff --git a/libavcodec/jni.h b/libavcodec/jni.h
> > index dd99e92611..da8025f830 100644
> > --- a/libavcodec/jni.h
> > +++ b/libavcodec/jni.h
> > @@ -43,4 +43,21 @@ int av_jni_set_java_vm(void *vm, void *log_ctx);
> >   */
> >  void *av_jni_get_java_vm(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
> > + * @return 0 on success, < 0 otherwise
> > + */
> > +int av_jni_set_android_app_ctx(void *app_ctx, void *log_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);
>
> This should mention that these functions are only available on android.

Added the following chunk locally to both functions:

  *
+ * This function is only available on Android.
+ *
___
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 v2 2/6] avformat: add Android content resolver protocol support

2024-03-17 Thread Matthieu Bouron
On Sun, Mar 17, 2024 at 12:33:04PM +0800, Zhao Zhili wrote:
> Sorry for the long delay of review.
> 
> > On Mar 5, 2024, at 03:37, Matthieu Bouron  wrote:
> > 
> > On Tue, Feb 27, 2024 at 03:50:38PM +0100, Matthieu Bouron wrote:
> >> Handles Android content-uri starting with content://.
> >> ---
> > 
> > [...]
> > 
> 
> > Handles Android content-uri starting with content://.
> > ---
> >  configure   |   2 +
> >  doc/APIchanges  |   3 +
> >  libavcodec/jni.c|   1 +
> >  libavformat/Makefile|   1 +
> >  libavformat/file.c  | 157 
> >  libavformat/protocols.c |   1 +
> >  6 files changed, 165 insertions(+)
> > 
> > diff --git a/configure b/configure
> > index bb5e630bad..790a1df7c8 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3655,6 +3655,8 @@ xcbgrab_indev_suggest="libxcb_shm libxcb_shape 
> > libxcb_xfixes"
> >  xv_outdev_deps="xlib_xv xlib_x11 xlib_xext"
> >  
> >  # protocols
> > +android_content_protocol_deps="jni"
> > +android_content_protocol_select="file_protocol"
> >  async_protocol_deps="threads"
> >  bluray_protocol_deps="libbluray"
> >  ffrtmpcrypt_protocol_conflict="librtmp_protocol"
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 10f6667e9e..258e953ca6 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -2,6 +2,9 @@ The last version increases of all libraries were on 
> > 2023-02-09
> >  
> >  API changes, most recent first:
> >  
> > +2024-02-xx - xx - lavc 60.41.100 - jni.h
> > +  Add av_jni_set_android_app_ctx() and av_jni_get_android_app_ctx().
> 
> Should be added together with patch 1/6.

Fixed.

> 
> > +
> >  2024-02-26 - xx - lavf 60.22.101 - avformat.h
> >AV_DISPOSITION_DEPENDENT may now also be used for video streams
> >intended to be merged with other video streams for presentation.
> > diff --git a/libavcodec/jni.c b/libavcodec/jni.c
> > index cfe95bd1ec..1193c608c3 100644
> > --- a/libavcodec/jni.c
> > +++ b/libavcodec/jni.c
> > @@ -35,6 +35,7 @@
> >  #include "ffjni.h"
> >  
> >  static void *java_vm;
> > +static void *android_app_ctx;
> >  static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
> >  
> >  int av_jni_set_java_vm(void *vm, void *log_ctx)
> > diff --git a/libavformat/Makefile b/libavformat/Makefile
> > index 4a380668bd..08fe98a535 100644
> > --- a/libavformat/Makefile
> > +++ b/libavformat/Makefile
> > @@ -657,6 +657,7 @@ OBJS-$(CONFIG_LIBOPENMPT_DEMUXER)+= libopenmpt.o
> >  OBJS-$(CONFIG_VAPOURSYNTH_DEMUXER)   += vapoursynth.o
> >  
> >  # protocols I/O
> > +OBJS-$(CONFIG_ANDROID_CONTENT_PROTOCOL)  += file.o
> >  OBJS-$(CONFIG_ASYNC_PROTOCOL)+= async.o
> >  OBJS-$(CONFIG_APPLEHTTP_PROTOCOL)+= hlsproto.o
> >  OBJS-$(CONFIG_BLURAY_PROTOCOL)   += bluray.o
> > diff --git a/libavformat/file.c b/libavformat/file.c
> > index 64df7ff6fb..1b2b69f090 100644
> > --- a/libavformat/file.c
> > +++ b/libavformat/file.c
> > @@ -40,6 +40,12 @@
> >  #include 
> >  #include "os_support.h"
> >  #include "url.h"
> > +#if CONFIG_ANDROID_CONTENT_PROTOCOL
> > +#include 
> > +#include "libavcodec/jni.h"
> > +#include "libavcodec/ffjni.c"
> > +#endif
> > +
> >  
> >  /* Some systems may not have S_ISFIFO */
> >  #ifndef S_ISFIFO
> > @@ -101,6 +107,21 @@ typedef struct FileContext {
> >  int64_t initial_pos;
> >  } FileContext;
> >  
> > +
> > +#if CONFIG_ANDROID_CONTENT_PROTOCOL
> > +static const AVOption android_content_options[] = {
> > +{ "blocksize", "set I/O operation maximum block size", 
> > offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 1, 
> > INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
> > +{ NULL }
> > +};
> > +
> > +static const AVClass android_content_class = {
> > +.class_name = "android_content",
> > +.item_name  = av_default_item_name,
> > +.option = android_content_options,
> > +.version= LIBAVUTIL_VERSION_INT,
> > +};
> > +#endif
> > +
> >  static const AVOption file_options[] = {
> >  { "truncate", "truncate existing files on write", 
> > offsetof(FileContext, trunc), AV_OPT

[FFmpeg-devel] [PATCH v4 6/6] avcodec/mediacodec_wrapper: remove unnecessary NULL checks before calling Delete{Global, Local}Ref()

2024-03-17 Thread Matthieu Bouron
Delete{Global,Local}Ref already handle NULL.
---
 libavcodec/mediacodec_wrapper.c | 189 
 1 file changed, 47 insertions(+), 142 deletions(-)

diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index 78cd28f53d..306359071e 100644
--- a/libavcodec/mediacodec_wrapper.c
+++ b/libavcodec/mediacodec_wrapper.c
@@ -549,10 +549,8 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
*mime, int profile, int e
 goto done;
 }
 
-if (codec_name) {
-(*env)->DeleteLocalRef(env, codec_name);
-codec_name = NULL;
-}
+(*env)->DeleteLocalRef(env, codec_name);
+codec_name = NULL;
 
 /* Skip software decoders */
 if (
@@ -616,10 +614,8 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
*mime, int profile, int e
 
 found_codec = profile == supported_profile;
 
-if (profile_level) {
-(*env)->DeleteLocalRef(env, profile_level);
-profile_level = NULL;
-}
+(*env)->DeleteLocalRef(env, profile_level);
+profile_level = NULL;
 
 if (found_codec) {
 break;
@@ -627,20 +623,14 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
*mime, int profile, int e
 }
 
 done_with_type:
-if (profile_levels) {
-(*env)->DeleteLocalRef(env, profile_levels);
-profile_levels = NULL;
-}
+(*env)->DeleteLocalRef(env, profile_levels);
+profile_levels = NULL;
 
-if (capabilities) {
-(*env)->DeleteLocalRef(env, capabilities);
-capabilities = NULL;
-}
+(*env)->DeleteLocalRef(env, capabilities);
+capabilities = NULL;
 
-if (type) {
-(*env)->DeleteLocalRef(env, type);
-type = NULL;
-}
+(*env)->DeleteLocalRef(env, type);
+type = NULL;
 
 av_freep(_type);
 
@@ -650,15 +640,11 @@ done_with_type:
 }
 
 done_with_info:
-if (info) {
-(*env)->DeleteLocalRef(env, info);
-info = NULL;
-}
+(*env)->DeleteLocalRef(env, info);
+info = NULL;
 
-if (types) {
-(*env)->DeleteLocalRef(env, types);
-types = NULL;
-}
+(*env)->DeleteLocalRef(env, types);
+types = NULL;
 
 if (found_codec) {
 break;
@@ -668,33 +654,13 @@ done_with_info:
 }
 
 done:
-if (codec_name) {
-(*env)->DeleteLocalRef(env, codec_name);
-}
-
-if (info) {
-(*env)->DeleteLocalRef(env, info);
-}
-
-if (type) {
-(*env)->DeleteLocalRef(env, type);
-}
-
-if (types) {
-(*env)->DeleteLocalRef(env, types);
-}
-
-if (capabilities) {
-(*env)->DeleteLocalRef(env, capabilities);
-}
-
-if (profile_level) {
-(*env)->DeleteLocalRef(env, profile_level);
-}
-
-if (profile_levels) {
-(*env)->DeleteLocalRef(env, profile_levels);
-}
+(*env)->DeleteLocalRef(env, codec_name);
+(*env)->DeleteLocalRef(env, info);
+(*env)->DeleteLocalRef(env, type);
+(*env)->DeleteLocalRef(env, types);
+(*env)->DeleteLocalRef(env, capabilities);
+(*env)->DeleteLocalRef(env, profile_level);
+(*env)->DeleteLocalRef(env, profile_levels);
 
 av_freep(_type);
 
@@ -741,9 +707,7 @@ static FFAMediaFormat *mediaformat_jni_new(void)
 }
 
 fail:
-if (object) {
-(*env)->DeleteLocalRef(env, object);
-}
+(*env)->DeleteLocalRef(env, object);
 
 if (!format->object) {
 ff_jni_reset_jfields(env, >jfields, jni_amediaformat_mapping, 
1, format);
@@ -828,9 +792,7 @@ static char* mediaformat_jni_toString(FFAMediaFormat* ctx)
 
 ret = ff_jni_jstring_to_utf_chars(env, description, format);
 fail:
-if (description) {
-(*env)->DeleteLocalRef(env, description);
-}
+(*env)->DeleteLocalRef(env, description);
 
 return ret;
 }
@@ -867,9 +829,7 @@ static int mediaformat_jni_getInt32(FFAMediaFormat* ctx, 
const char *name, int32
 
 ret = 1;
 fail:
-if (key) {
-(*env)->DeleteLocalRef(env, key);
-}
+(*env)->DeleteLocalRef(env, key);
 
 return ret;
 }
@@ -906,9 +866,7 @@ static int mediaformat_jni_getInt64(FFAMediaFormat* ctx, 
const char *name, int64
 
 ret = 1;
 fail:
-if (key) {
-(*env)->DeleteLocalRef(env, key);
-}
+(*env)->DeleteLocalRef(env, key);
 
 return ret;
 }
@@ -945,9 +903,7 @@ static int mediaformat_jni_getFloat(FFAMediaFormat* ctx, 
const char *name, float
 
 ret = 1;
 fail:
-if (key) {
-(*env)->DeleteLocalRef(env, key);
-}
+(*env)->DeleteLocalRef(env, key);
 
 return ret;
 }
@@ -999,13 +955,8 @@ static int mediaformat_jni_getBuffer(FFAMediaFormat* ctx, 
const char 

[FFmpeg-devel] [PATCH v4 5/6] avcodec/mediacodec_wrapper: use an OFFSET() macro where relevant

2024-03-17 Thread Matthieu Bouron
Reduces a bit the horizontal spacing.
---
 libavcodec/mediacodec_wrapper.c | 138 +---
 1 file changed, 72 insertions(+), 66 deletions(-)

diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index 0880ddd3ef..78cd28f53d 100644
--- a/libavcodec/mediacodec_wrapper.c
+++ b/libavcodec/mediacodec_wrapper.c
@@ -60,31 +60,33 @@ struct JNIAMediaCodecListFields {
 jfieldID level_id;
 };
 
+#define OFFSET(x) offsetof(struct JNIAMediaCodecListFields, x)
 static const struct FFJniField jni_amediacodeclist_mapping[] = {
-{ "android/media/MediaCodecList", NULL, NULL, FF_JNI_CLASS, 
offsetof(struct JNIAMediaCodecListFields, mediacodec_list_class), 1 },
-{ "android/media/MediaCodecList", "", "(I)V", FF_JNI_METHOD, 
offsetof(struct JNIAMediaCodecListFields, init_id), 0 },
-{ "android/media/MediaCodecList", "findDecoderForFormat", 
"(Landroid/media/MediaFormat;)Ljava/lang/String;", FF_JNI_METHOD, 
offsetof(struct JNIAMediaCodecListFields, find_decoder_for_format_id), 0 },
+{ "android/media/MediaCodecList", NULL, NULL, FF_JNI_CLASS, 
OFFSET(mediacodec_list_class), 1 },
+{ "android/media/MediaCodecList", "", "(I)V", FF_JNI_METHOD, 
OFFSET(init_id), 0 },
+{ "android/media/MediaCodecList", "findDecoderForFormat", 
"(Landroid/media/MediaFormat;)Ljava/lang/String;", FF_JNI_METHOD, 
OFFSET(find_decoder_for_format_id), 0 },
 
-{ "android/media/MediaCodecList", "getCodecCount", "()I", 
FF_JNI_STATIC_METHOD, offsetof(struct JNIAMediaCodecListFields, 
get_codec_count_id), 1 },
-{ "android/media/MediaCodecList", "getCodecInfoAt", 
"(I)Landroid/media/MediaCodecInfo;", FF_JNI_STATIC_METHOD, offsetof(struct 
JNIAMediaCodecListFields, get_codec_info_at_id), 1 },
+{ "android/media/MediaCodecList", "getCodecCount", "()I", 
FF_JNI_STATIC_METHOD, OFFSET(get_codec_count_id), 1 },
+{ "android/media/MediaCodecList", "getCodecInfoAt", 
"(I)Landroid/media/MediaCodecInfo;", FF_JNI_STATIC_METHOD, 
OFFSET(get_codec_info_at_id), 1 },
 
-{ "android/media/MediaCodecInfo", NULL, NULL, FF_JNI_CLASS, 
offsetof(struct JNIAMediaCodecListFields, mediacodec_info_class), 1 },
-{ "android/media/MediaCodecInfo", "getName", "()Ljava/lang/String;", 
FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, get_name_id), 1 },
-{ "android/media/MediaCodecInfo", "getCapabilitiesForType", 
"(Ljava/lang/String;)Landroid/media/MediaCodecInfo$CodecCapabilities;", 
FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, 
get_codec_capabilities_id), 1 },
-{ "android/media/MediaCodecInfo", "getSupportedTypes", 
"()[Ljava/lang/String;", FF_JNI_METHOD, offsetof(struct 
JNIAMediaCodecListFields, get_supported_types_id), 1 },
-{ "android/media/MediaCodecInfo", "isEncoder", "()Z", FF_JNI_METHOD, 
offsetof(struct JNIAMediaCodecListFields, is_encoder_id), 1 },
-{ "android/media/MediaCodecInfo", "isSoftwareOnly", "()Z", 
FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, is_software_only_id), 
0 },
+{ "android/media/MediaCodecInfo", NULL, NULL, FF_JNI_CLASS, 
OFFSET(mediacodec_info_class), 1 },
+{ "android/media/MediaCodecInfo", "getName", "()Ljava/lang/String;", 
FF_JNI_METHOD, OFFSET(get_name_id), 1 },
+{ "android/media/MediaCodecInfo", "getCapabilitiesForType", 
"(Ljava/lang/String;)Landroid/media/MediaCodecInfo$CodecCapabilities;", 
FF_JNI_METHOD, OFFSET(get_codec_capabilities_id), 1 },
+{ "android/media/MediaCodecInfo", "getSupportedTypes", 
"()[Ljava/lang/String;", FF_JNI_METHOD, OFFSET(get_supported_types_id), 1 },
+{ "android/media/MediaCodecInfo", "isEncoder", "()Z", FF_JNI_METHOD, 
OFFSET(is_encoder_id), 1 },
+{ "android/media/MediaCodecInfo", "isSoftwareOnly", "()Z", 
FF_JNI_METHOD, OFFSET(is_software_only_id), 0 },
 
-{ "android/media/MediaCodecInfo$CodecCapabilities", NULL, NULL, 
FF_JNI_CLASS, offsetof(struct JNIAMediaCodecListFields, 
codec_capabilities_class), 1 },
-{ "android/media/MediaCodecInfo$CodecCapabilities", "colorFormats", 
"[I", FF_JNI_FIELD, offsetof(struct JNIAMediaCodecListFields, 
color_formats_id), 1 },
-{ "android/media/MediaCodecInfo$CodecCapabilities", "profileLevels", 
"[Landroid/media/MediaCodecInfo$CodecProfileLevel;", FF_JNI_FIELD, 
offsetof(struct JNIAMediaCodecListFields, profile_levels_id), 1 },
+{ "android/media/MediaCodecInfo$CodecCapabilities", NULL, NULL, 
FF_JNI_CLASS, OFFSET(codec_capabilities_class), 1 },
+{ "android/media/MediaCodecInfo$CodecCapabilities", "colorFormats", 
"[I", FF_JNI_FIELD, OFFSET(color_formats_id), 1 },
+{ "android/media/MediaCodecInfo$CodecCapabilities", "profileLevels", 
"[Landroid/media/MediaCodecInfo$CodecProfileLevel;", FF_JNI_FIELD, 
OFFSET(profile_levels_id), 1 },
 
-{ "android/media/MediaCodecInfo$CodecProfileLevel", NULL, NULL, 
FF_JNI_CLASS, offsetof(struct JNIAMediaCodecListFields, 
codec_profile_level_class), 1 },
-{ 

[FFmpeg-devel] [PATCH v4 4/6] avcodec/jni: remove unnecessary NULL checks before calling DeleteLocalRef()

2024-03-17 Thread Matthieu Bouron
Delete{Global,Local}Ref() already handle NULL.
---
 libavcodec/ffjni.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/libavcodec/ffjni.c b/libavcodec/ffjni.c
index e3cf24d3e2..69d9a9faa3 100644
--- a/libavcodec/ffjni.c
+++ b/libavcodec/ffjni.c
@@ -236,17 +236,9 @@ done:
 av_free(name);
 av_free(message);
 
-if (class_class) {
-(*env)->DeleteLocalRef(env, class_class);
-}
-
-if (exception_class) {
-(*env)->DeleteLocalRef(env, exception_class);
-}
-
-if (string) {
-(*env)->DeleteLocalRef(env, string);
-}
+(*env)->DeleteLocalRef(env, class_class);
+(*env)->DeleteLocalRef(env, exception_class);
+(*env)->DeleteLocalRef(env, string);
 
 return ret;
 }
-- 
2.44.0

___
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 v4 3/6] avcodec/jni: use size_t to store structure offsets

2024-03-17 Thread Matthieu Bouron
---
 libavcodec/ffjni.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/ffjni.h b/libavcodec/ffjni.h
index 6027bac0ab..d1e86f8329 100644
--- a/libavcodec/ffjni.h
+++ b/libavcodec/ffjni.h
@@ -24,6 +24,7 @@
 #define AVCODEC_FFJNI_H
 
 #include 
+#include 
 
 /*
  * Attach permanently a JNI environment to the current thread and retrieve it.
@@ -105,7 +106,7 @@ struct FFJniField {
 const char *method;
 const char *signature;
 enum FFJniFieldType type;
-int offset;
+size_t offset;
 int mandatory;
 
 };
-- 
2.44.0

___
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 v4 2/6] avformat: add Android content resolver protocol support

2024-03-17 Thread Matthieu Bouron
Handles Android content-uri starting with content://.
---
 configure   |   2 +
 libavcodec/jni.c|   1 +
 libavformat/Makefile|   1 +
 libavformat/file.c  | 160 
 libavformat/protocols.c |   1 +
 5 files changed, 165 insertions(+)

diff --git a/configure b/configure
index 2b4c4ec9a2..9ef432fddf 100755
--- a/configure
+++ b/configure
@@ -3656,6 +3656,8 @@ xcbgrab_indev_suggest="libxcb_shm libxcb_shape 
libxcb_xfixes"
 xv_outdev_deps="xlib_xv xlib_x11 xlib_xext"
 
 # protocols
+android_content_protocol_deps="jni"
+android_content_protocol_select="file_protocol"
 async_protocol_deps="threads"
 bluray_protocol_deps="libbluray"
 ffrtmpcrypt_protocol_conflict="librtmp_protocol"
diff --git a/libavcodec/jni.c b/libavcodec/jni.c
index cfe95bd1ec..1193c608c3 100644
--- a/libavcodec/jni.c
+++ b/libavcodec/jni.c
@@ -35,6 +35,7 @@
 #include "ffjni.h"
 
 static void *java_vm;
+static void *android_app_ctx;
 static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
 
 int av_jni_set_java_vm(void *vm, void *log_ctx)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 94a949f555..44aa485029 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -658,6 +658,7 @@ OBJS-$(CONFIG_LIBOPENMPT_DEMUXER)+= libopenmpt.o
 OBJS-$(CONFIG_VAPOURSYNTH_DEMUXER)   += vapoursynth.o
 
 # protocols I/O
+OBJS-$(CONFIG_ANDROID_CONTENT_PROTOCOL)  += file.o
 OBJS-$(CONFIG_ASYNC_PROTOCOL)+= async.o
 OBJS-$(CONFIG_APPLEHTTP_PROTOCOL)+= hlsproto.o
 OBJS-$(CONFIG_BLURAY_PROTOCOL)   += bluray.o
diff --git a/libavformat/file.c b/libavformat/file.c
index 64df7ff6fb..dd5819c06f 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -40,6 +40,12 @@
 #include 
 #include "os_support.h"
 #include "url.h"
+#if CONFIG_ANDROID_CONTENT_PROTOCOL
+#include 
+#include "libavcodec/jni.h"
+#include "libavcodec/ffjni.c"
+#endif
+
 
 /* Some systems may not have S_ISFIFO */
 #ifndef S_ISFIFO
@@ -101,6 +107,21 @@ typedef struct FileContext {
 int64_t initial_pos;
 } FileContext;
 
+
+#if CONFIG_ANDROID_CONTENT_PROTOCOL
+static const AVOption android_content_options[] = {
+{ "blocksize", "set I/O operation maximum block size", 
offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 1, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
+{ NULL }
+};
+
+static const AVClass android_content_class = {
+.class_name = "android_content",
+.item_name  = av_default_item_name,
+.option = android_content_options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+#endif
+
 static const AVOption file_options[] = {
 { "truncate", "truncate existing files on write", offsetof(FileContext, 
trunc), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, AV_OPT_FLAG_ENCODING_PARAM },
 { "blocksize", "set I/O operation maximum block size", 
offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 1, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
@@ -524,3 +545,142 @@ const URLProtocol ff_fd_protocol = {
 };
 
 #endif /* CONFIG_FD_PROTOCOL */
+
+#if CONFIG_ANDROID_CONTENT_PROTOCOL
+
+typedef struct JFields {
+jclass uri_class;
+jmethodID parse_id;
+
+jclass context_class;
+jmethodID get_content_resolver_id;
+
+jclass content_resolver_class;
+jmethodID open_file_descriptor_id;
+
+jclass parcel_file_descriptor_class;
+jmethodID detach_fd_id;
+} JFields;
+
+#define OFFSET(x) offsetof(JFields, x)
+static const struct FFJniField jfields_mapping[] = {
+{ "android/net/Uri", NULL, NULL, FF_JNI_CLASS, OFFSET(uri_class), 1 },
+{ "android/net/Uri", "parse", "(Ljava/lang/String;)Landroid/net/Uri;", 
FF_JNI_STATIC_METHOD, OFFSET(parse_id), 1 },
+
+{ "android/content/Context", NULL, NULL, FF_JNI_CLASS, 
OFFSET(context_class), 1 },
+{ "android/content/Context", "getContentResolver", 
"()Landroid/content/ContentResolver;", FF_JNI_METHOD, 
OFFSET(get_content_resolver_id), 1 },
+
+{ "android/content/ContentResolver", NULL, NULL, FF_JNI_CLASS, 
OFFSET(content_resolver_class), 1 },
+{ "android/content/ContentResolver", "openFileDescriptor", 
"(Landroid/net/Uri;Ljava/lang/String;)Landroid/os/ParcelFileDescriptor;", 
FF_JNI_METHOD, OFFSET(open_file_descriptor_id), 1 },
+
+{ "android/os/ParcelFileDescriptor", NULL, NULL, FF_JNI_CLASS, 
OFFSET(parcel_file_descriptor_class), 1 },
+{ "android/os/ParcelFileDescriptor", "detachFd", "()I", FF_JNI_METHOD, 
OFFSET(detach_fd_id), 1 },
+
+{ NULL }
+};
+#undef OFFSET
+
+static int android_content_open(URLContext *h, const char *filename, int flags)
+{
+FileContext *c = h->priv_data;
+int fd, ret;
+struct stat st;
+const char *mode_str = "r";
+
+JNIEnv *env;
+JFields jfields = { 0 };
+jobject application_context = NULL;
+jobject url = NULL;
+jobject mode = NULL;
+jobject uri = NULL;
+jobject content_resolver = NULL;
+jobject parcel_file_descriptor = NULL;
+
+env = ff_jni_get_env(c);
+   

[FFmpeg-devel] [PATCH v4 1/6] avcodec: add av_jni_{get, set}_android_app_ctx helper

2024-03-17 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.
---
 doc/APIchanges   |  3 +++
 libavcodec/jni.c | 42 ++
 libavcodec/jni.h | 17 +
 3 files changed, 62 insertions(+)

diff --git a/doc/APIchanges b/doc/APIchanges
index a44c8e4f10..ae1868047e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07
 
 API changes, most recent first:
 
+2024-03-xx - xx - lavc 61.2.100 - jni.h
+  Add av_jni_set_android_app_ctx() and av_jni_get_android_app_ctx().
+
 2024-03-xx - xx - lavu 59.2.100 - channel_layout.h
   Add AV_CHANNEL_LAYOUT_RETYPE_FLAG_CANONICAL.
 
diff --git a/libavcodec/jni.c b/libavcodec/jni.c
index ae6490de9d..cfe95bd1ec 100644
--- a/libavcodec/jni.c
+++ b/libavcodec/jni.c
@@ -77,3 +77,45 @@ void *av_jni_get_java_vm(void *log_ctx)
 }
 
 #endif
+
+#if defined(__ANDROID__)
+
+int av_jni_set_android_app_ctx(void *app_ctx, void *log_ctx)
+{
+#if CONFIG_JNI
+JNIEnv *env = ff_jni_get_env(log_ctx);
+if (!env)
+return AVERROR(EINVAL);
+
+jobjectRefType type = (*env)->GetObjectRefType(env, app_ctx);
+if (type != JNIGlobalRefType) {
+av_log(log_ctx, AV_LOG_ERROR, "Application context must be passed as a 
global reference");
+return AVERROR(EINVAL);
+}
+
+pthread_mutex_lock();
+android_app_ctx = app_ctx;
+pthread_mutex_unlock();
+
+return 0;
+#else
+return AVERROR(ENOSYS);
+#endif
+}
+
+void *av_jni_get_android_app_ctx(void)
+{
+#if CONFIG_JNI
+void *ctx;
+
+pthread_mutex_lock();
+ctx = android_app_ctx;
+pthread_mutex_unlock();
+
+return ctx;
+#else
+return NULL;
+#endif
+}
+
+#endif
diff --git a/libavcodec/jni.h b/libavcodec/jni.h
index dd99e92611..da8025f830 100644
--- a/libavcodec/jni.h
+++ b/libavcodec/jni.h
@@ -43,4 +43,21 @@ int av_jni_set_java_vm(void *vm, void *log_ctx);
  */
 void *av_jni_get_java_vm(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
+ * @return 0 on success, < 0 otherwise
+ */
+int av_jni_set_android_app_ctx(void *app_ctx, void *log_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 /* AVCODEC_JNI_H */
-- 
2.44.0

___
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] Add protocol for Android content providers (v4)

2024-03-17 Thread Matthieu Bouron
Diff with previous iteration:
- rebaed on latest master
- applied feedback from Zhao (removed HAVE_SETMODE block, use a typedef struct,
  check that the fd is seekable, moved doc/APIChanges changes to the right
  commit)

___
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] Add protocol for Android content providers (v2)

2024-03-14 Thread Matthieu Bouron
On Mon, Mar 04, 2024 at 09:21:43AM +0100, Matthieu Bouron wrote:
> On Tue, Feb 27, 2024 at 03:50:36PM +0100, Matthieu Bouron wrote:
> > Diff from initial patchset:
> > - directly include libavcodec/ffjni.c from libavformat/file.c instead of
> >   migrating ffjni to libavutil (avpriv_*)
> > - check that the passed application context reference is a global one and 
> > error
> >   out if it's not the case
> > 
> 
> Ping.
> 
> Note: I reworded locally the commit msgs using avutil/jni to avcodec/jni.

If there is no objection, I will push the patchset in a few days.
___
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 v2 3/6] avutil/jni: use size_t to store structure offsets

2024-03-04 Thread Matthieu Bouron
On Mon, Mar 04, 2024 at 09:10:49PM +0100, Andreas Rheinhardt wrote:
> Matthieu Bouron:
> > ---
> >  libavcodec/ffjni.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/ffjni.h b/libavcodec/ffjni.h
> > index 6027bac0ab..d5894609ed 100644
> > --- a/libavcodec/ffjni.h
> > +++ b/libavcodec/ffjni.h
> > @@ -24,6 +24,7 @@
> >  #define AVCODEC_FFJNI_H
> >  
> >  #include 
> > +#include 
> >  
> 
> stddef.h is the "cheaper" header for size_t.

New patch attached.

>From 0a5f890dcbedf87da3df5b49ece545a847e423a4 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Tue, 13 Feb 2024 11:03:22 +0100
Subject: [PATCH v3 3/6] avcodec/jni: use size_t to store structure offsets

---
 libavcodec/ffjni.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/ffjni.h b/libavcodec/ffjni.h
index 6027bac0ab..d1e86f8329 100644
--- a/libavcodec/ffjni.h
+++ b/libavcodec/ffjni.h
@@ -24,6 +24,7 @@
 #define AVCODEC_FFJNI_H
 
 #include 
+#include 
 
 /*
  * Attach permanently a JNI environment to the current thread and retrieve it.
@@ -105,7 +106,7 @@ struct FFJniField {
 const char *method;
 const char *signature;
 enum FFJniFieldType type;
-int offset;
+size_t offset;
 int mandatory;
 
 };
-- 
2.44.0

___
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 v2 2/6] avformat: add Android content resolver protocol support

2024-03-04 Thread Matthieu Bouron
On Tue, Feb 27, 2024 at 03:50:38PM +0100, Matthieu Bouron wrote:
> Handles Android content-uri starting with content://.
> ---

[...]

New patch attached (I moved an unrelated chunk to the previous commit).
>From 6ef059b721c1b1635565cc9e7d836be4733c928d Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Mon, 12 Feb 2024 23:14:35 +0100
Subject: [PATCH v3 2/6] avformat: add Android content resolver protocol
 support

Handles Android content-uri starting with content://.
---
 configure   |   2 +
 doc/APIchanges  |   3 +
 libavcodec/jni.c|   1 +
 libavformat/Makefile|   1 +
 libavformat/file.c  | 157 
 libavformat/protocols.c |   1 +
 6 files changed, 165 insertions(+)

diff --git a/configure b/configure
index bb5e630bad..790a1df7c8 100755
--- a/configure
+++ b/configure
@@ -3655,6 +3655,8 @@ xcbgrab_indev_suggest="libxcb_shm libxcb_shape 
libxcb_xfixes"
 xv_outdev_deps="xlib_xv xlib_x11 xlib_xext"
 
 # protocols
+android_content_protocol_deps="jni"
+android_content_protocol_select="file_protocol"
 async_protocol_deps="threads"
 bluray_protocol_deps="libbluray"
 ffrtmpcrypt_protocol_conflict="librtmp_protocol"
diff --git a/doc/APIchanges b/doc/APIchanges
index 10f6667e9e..258e953ca6 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
 
 API changes, most recent first:
 
+2024-02-xx - xx - lavc 60.41.100 - jni.h
+  Add av_jni_set_android_app_ctx() and av_jni_get_android_app_ctx().
+
 2024-02-26 - xx - lavf 60.22.101 - avformat.h
   AV_DISPOSITION_DEPENDENT may now also be used for video streams
   intended to be merged with other video streams for presentation.
diff --git a/libavcodec/jni.c b/libavcodec/jni.c
index cfe95bd1ec..1193c608c3 100644
--- a/libavcodec/jni.c
+++ b/libavcodec/jni.c
@@ -35,6 +35,7 @@
 #include "ffjni.h"
 
 static void *java_vm;
+static void *android_app_ctx;
 static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
 
 int av_jni_set_java_vm(void *vm, void *log_ctx)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 4a380668bd..08fe98a535 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -657,6 +657,7 @@ OBJS-$(CONFIG_LIBOPENMPT_DEMUXER)+= libopenmpt.o
 OBJS-$(CONFIG_VAPOURSYNTH_DEMUXER)   += vapoursynth.o
 
 # protocols I/O
+OBJS-$(CONFIG_ANDROID_CONTENT_PROTOCOL)  += file.o
 OBJS-$(CONFIG_ASYNC_PROTOCOL)+= async.o
 OBJS-$(CONFIG_APPLEHTTP_PROTOCOL)+= hlsproto.o
 OBJS-$(CONFIG_BLURAY_PROTOCOL)   += bluray.o
diff --git a/libavformat/file.c b/libavformat/file.c
index 64df7ff6fb..1b2b69f090 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -40,6 +40,12 @@
 #include 
 #include "os_support.h"
 #include "url.h"
+#if CONFIG_ANDROID_CONTENT_PROTOCOL
+#include 
+#include "libavcodec/jni.h"
+#include "libavcodec/ffjni.c"
+#endif
+
 
 /* Some systems may not have S_ISFIFO */
 #ifndef S_ISFIFO
@@ -101,6 +107,21 @@ typedef struct FileContext {
 int64_t initial_pos;
 } FileContext;
 
+
+#if CONFIG_ANDROID_CONTENT_PROTOCOL
+static const AVOption android_content_options[] = {
+{ "blocksize", "set I/O operation maximum block size", 
offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 1, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
+{ NULL }
+};
+
+static const AVClass android_content_class = {
+.class_name = "android_content",
+.item_name  = av_default_item_name,
+.option = android_content_options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+#endif
+
 static const AVOption file_options[] = {
 { "truncate", "truncate existing files on write", offsetof(FileContext, 
trunc), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, AV_OPT_FLAG_ENCODING_PARAM },
 { "blocksize", "set I/O operation maximum block size", 
offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 1, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
@@ -524,3 +545,139 @@ const URLProtocol ff_fd_protocol = {
 };
 
 #endif /* CONFIG_FD_PROTOCOL */
+
+#if CONFIG_ANDROID_CONTENT_PROTOCOL
+
+struct JFields {
+jclass uri_class;
+jmethodID parse_id;
+
+jclass context_class;
+jmethodID get_content_resolver_id;
+
+jclass content_resolver_class;
+jmethodID open_file_descriptor_id;
+
+jclass parcel_file_descriptor_class;
+jmethodID detach_fd_id;
+};
+
+#define OFFSET(x) offsetof(struct JFields, x)
+static const struct FFJniField jfields_mapping[] = {
+{ "android/net/Uri", NULL, NULL, FF_JNI_CLASS, OFFSET(uri_class), 1 },
+{ "android/net/Uri", "parse", "(Ljava/lang/String;)Landroid/net/Uri;", 
FF_JNI_STATIC_METHOD, OFFSET(parse_id), 1 },
+
+{ "android/content/Context", N

Re: [FFmpeg-devel] [PATCH v2 1/6] avcodec: add av_jni_{get, set}_android_app_ctx helper

2024-03-04 Thread Matthieu Bouron
On Mon, Mar 04, 2024 at 05:35:36PM +0100, Matthieu Bouron wrote:
> On Mon, Mar 4, 2024 at 4:11 PM Matthieu Bouron
>  wrote:
> >
> > On Mon, Mar 4, 2024 at 12:29 PM Andreas Rheinhardt
> >  wrote:

[...]

> > >
> > > I am against adding stub functions on platforms where they are known to
> > > be useless, i.e. everything except android.
> >
> > Ok. Will update the patch introducing a new header "jni_android.h".
> > Unless we want to also scope avcodec/jni.h to Android only ?
> 
> Or maybe you mean adding a ifdef guard to it ?
> 

New patch attached. The functions are now only built for Android.

[...]
>From 1b674e78c6a86090f5c9ed6fef5f47ae83ba98be Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Mon, 12 Feb 2024 23:13:09 +0100
Subject: [PATCH v3 1/6] avcodec: add av_jni_{get,set}_android_app_ctx helper

This will allow users to pass the Android ApplicationContext which is mandatory
to retrieve the ContentResolver responsible to resolve/open Android content-uri.
---
 libavcodec/jni.c | 42 ++
 libavcodec/jni.h | 17 +
 2 files changed, 59 insertions(+)

diff --git a/libavcodec/jni.c b/libavcodec/jni.c
index ae6490de9d..cfe95bd1ec 100644
--- a/libavcodec/jni.c
+++ b/libavcodec/jni.c
@@ -77,3 +77,45 @@ void *av_jni_get_java_vm(void *log_ctx)
 }
 
 #endif
+
+#if defined(__ANDROID__)
+
+int av_jni_set_android_app_ctx(void *app_ctx, void *log_ctx)
+{
+#if CONFIG_JNI
+JNIEnv *env = ff_jni_get_env(log_ctx);
+if (!env)
+return AVERROR(EINVAL);
+
+jobjectRefType type = (*env)->GetObjectRefType(env, app_ctx);
+if (type != JNIGlobalRefType) {
+av_log(log_ctx, AV_LOG_ERROR, "Application context must be passed as a 
global reference");
+return AVERROR(EINVAL);
+}
+
+pthread_mutex_lock();
+android_app_ctx = app_ctx;
+pthread_mutex_unlock();
+
+return 0;
+#else
+return AVERROR(ENOSYS);
+#endif
+}
+
+void *av_jni_get_android_app_ctx(void)
+{
+#if CONFIG_JNI
+void *ctx;
+
+pthread_mutex_lock();
+ctx = android_app_ctx;
+pthread_mutex_unlock();
+
+return ctx;
+#else
+return NULL;
+#endif
+}
+
+#endif
diff --git a/libavcodec/jni.h b/libavcodec/jni.h
index dd99e92611..da8025f830 100644
--- a/libavcodec/jni.h
+++ b/libavcodec/jni.h
@@ -43,4 +43,21 @@ int av_jni_set_java_vm(void *vm, void *log_ctx);
  */
 void *av_jni_get_java_vm(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
+ * @return 0 on success, < 0 otherwise
+ */
+int av_jni_set_android_app_ctx(void *app_ctx, void *log_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 /* AVCODEC_JNI_H */
-- 
2.44.0

___
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 v2 1/6] avcodec: add av_jni_{get, set}_android_app_ctx helper

2024-03-04 Thread Matthieu Bouron
On Mon, Mar 4, 2024 at 4:11 PM Matthieu Bouron
 wrote:
>
> On Mon, Mar 4, 2024 at 12:29 PM 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.
> > > ---
> > >  libavcodec/jni.c | 40 
> > >  libavcodec/jni.h | 17 +
> > >  2 files changed, 57 insertions(+)
> > >
> > > diff --git a/libavcodec/jni.c b/libavcodec/jni.c
> > > index ae6490de9d..7d04d0a268 100644
> > > --- a/libavcodec/jni.c
> > > +++ b/libavcodec/jni.c
> > > @@ -64,6 +64,36 @@ void *av_jni_get_java_vm(void *log_ctx)
> > >  return vm;
> > >  }
> > >
> > > +int av_jni_set_android_app_ctx(void *app_ctx, void *log_ctx)
> > > +{
> > > +JNIEnv *env = avpriv_jni_get_env(c);
> >
> > Patch #1 won't compile on its own due to this; you fix this up in patch #2.
> >
> > > +if (!env)
> > > +return AVERROR(EINVAL);
> > > +
> > > +jobjectRefType type = (*env)->GetObjectRefType(env, app_ctx);
> > > +if (type != JNIGlobalRefType) {
> > > +av_log(log_ctx, AV_LOG_ERROR, "Application context must be 
> > > passed as a global reference");
> > > +return AVERROR(EINVAL);
> > > +}
> > > +
> > > +pthread_mutex_lock();
> > > +android_app_ctx = app_ctx;
> > > +pthread_mutex_unlock();
> > > +
> > > +return 0;
> > > +}
> > > +
> > > +void *av_jni_get_android_app_ctx(void)
> > > +{
> > > +void *ctx;
> > > +
> > > +pthread_mutex_lock();
> > > +ctx = android_app_ctx;
> > > +pthread_mutex_unlock();
> > > +
> > > +return ctx;
> > > +}
> > > +
> > >  #else
> > >
> > >  int av_jni_set_java_vm(void *vm, void *log_ctx)
> > > @@ -76,4 +106,14 @@ void *av_jni_get_java_vm(void *log_ctx)
> > >  return NULL;
> > >  }
> > >
> > > +int av_jni_set_android_app_ctx(void *app_ctx, void *log_ctx)
> > > +{
> > > +return AVERROR(ENOSYS);
> > > +}
> > > +
> > > +void *av_jni_get_android_app_ctx(void)
> > > +{
> > > +return NULL;
> > > +}
> >
> > I am against adding stub functions on platforms where they are known to
> > be useless, i.e. everything except android.
>
> Ok. Will update the patch introducing a new header "jni_android.h".
> Unless we want to also scope avcodec/jni.h to Android only ?

Or maybe you mean adding a ifdef guard to it ?

>
> >
> > > +
> > >  #endif
> > > diff --git a/libavcodec/jni.h b/libavcodec/jni.h
> > > index dd99e92611..da8025f830 100644
> > > --- a/libavcodec/jni.h
> > > +++ b/libavcodec/jni.h
> > > @@ -43,4 +43,21 @@ int av_jni_set_java_vm(void *vm, void *log_ctx);
> > >   */
> > >  void *av_jni_get_java_vm(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
> > > + * @return 0 on success, < 0 otherwise
> > > + */
> > > +int av_jni_set_android_app_ctx(void *app_ctx, void *log_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 /* AVCODEC_JNI_H */
> >
> > ___
> > 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".


Re: [FFmpeg-devel] [PATCH v2 1/6] avcodec: add av_jni_{get, set}_android_app_ctx helper

2024-03-04 Thread Matthieu Bouron
On Mon, Mar 4, 2024 at 12:29 PM 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.
> > ---
> >  libavcodec/jni.c | 40 
> >  libavcodec/jni.h | 17 +
> >  2 files changed, 57 insertions(+)
> >
> > diff --git a/libavcodec/jni.c b/libavcodec/jni.c
> > index ae6490de9d..7d04d0a268 100644
> > --- a/libavcodec/jni.c
> > +++ b/libavcodec/jni.c
> > @@ -64,6 +64,36 @@ void *av_jni_get_java_vm(void *log_ctx)
> >  return vm;
> >  }
> >
> > +int av_jni_set_android_app_ctx(void *app_ctx, void *log_ctx)
> > +{
> > +JNIEnv *env = avpriv_jni_get_env(c);
>
> Patch #1 won't compile on its own due to this; you fix this up in patch #2.
>
> > +if (!env)
> > +return AVERROR(EINVAL);
> > +
> > +jobjectRefType type = (*env)->GetObjectRefType(env, app_ctx);
> > +if (type != JNIGlobalRefType) {
> > +av_log(log_ctx, AV_LOG_ERROR, "Application context must be passed 
> > as a global reference");
> > +return AVERROR(EINVAL);
> > +}
> > +
> > +pthread_mutex_lock();
> > +android_app_ctx = app_ctx;
> > +pthread_mutex_unlock();
> > +
> > +return 0;
> > +}
> > +
> > +void *av_jni_get_android_app_ctx(void)
> > +{
> > +void *ctx;
> > +
> > +pthread_mutex_lock();
> > +ctx = android_app_ctx;
> > +pthread_mutex_unlock();
> > +
> > +return ctx;
> > +}
> > +
> >  #else
> >
> >  int av_jni_set_java_vm(void *vm, void *log_ctx)
> > @@ -76,4 +106,14 @@ void *av_jni_get_java_vm(void *log_ctx)
> >  return NULL;
> >  }
> >
> > +int av_jni_set_android_app_ctx(void *app_ctx, void *log_ctx)
> > +{
> > +return AVERROR(ENOSYS);
> > +}
> > +
> > +void *av_jni_get_android_app_ctx(void)
> > +{
> > +return NULL;
> > +}
>
> I am against adding stub functions on platforms where they are known to
> be useless, i.e. everything except android.

Ok. Will update the patch introducing a new header "jni_android.h".
Unless we want to also scope avcodec/jni.h to Android only ?

>
> > +
> >  #endif
> > diff --git a/libavcodec/jni.h b/libavcodec/jni.h
> > index dd99e92611..da8025f830 100644
> > --- a/libavcodec/jni.h
> > +++ b/libavcodec/jni.h
> > @@ -43,4 +43,21 @@ int av_jni_set_java_vm(void *vm, void *log_ctx);
> >   */
> >  void *av_jni_get_java_vm(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
> > + * @return 0 on success, < 0 otherwise
> > + */
> > +int av_jni_set_android_app_ctx(void *app_ctx, void *log_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 /* AVCODEC_JNI_H */
>
> ___
> 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".


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

2024-03-04 Thread Matthieu Bouron
On Tue, Feb 27, 2024 at 03:50:36PM +0100, Matthieu Bouron wrote:
> Diff from initial patchset:
> - directly include libavcodec/ffjni.c from libavformat/file.c instead of
>   migrating ffjni to libavutil (avpriv_*)
> - check that the passed application context reference is a global one and 
> error
>   out if it's not the case
> 

Ping.

Note: I reworded locally the commit msgs using avutil/jni to avcodec/jni.
___
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] avcodec/mediacodecenc: Add a hint message to use nv12 pix_fmt

2024-03-04 Thread Matthieu Bouron
On Mon, Mar 04, 2024 at 11:37:58AM +0800, Zhao Zhili wrote:
> From: Zhao Zhili 
> 
> ---
>  libavcodec/mediacodecenc.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavcodec/mediacodecenc.c b/libavcodec/mediacodecenc.c
> index 086b545590..984014f1b1 100644
> --- a/libavcodec/mediacodecenc.c
> +++ b/libavcodec/mediacodecenc.c
> @@ -319,6 +319,9 @@ static av_cold int mediacodec_init(AVCodecContext *avctx)
>  ret = ff_AMediaCodec_configure(s->codec, format, s->window, NULL, ret);
>  if (ret) {
>  av_log(avctx, AV_LOG_ERROR, "MediaCodec configure failed, %s\n", 
> av_err2str(ret));
> +if (avctx->pix_fmt == AV_PIX_FMT_YUV420P)
> +av_log(avctx, AV_LOG_ERROR, "Please try -pix_fmt nv12, some 
> devices don't "
> +"support yuv420p as encoder input 
> format.\n");
>  goto bailout;
>  }
>  

LGTM.

___
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 v2 6/6] avcodec/mediacodec_wrapper: remove unnecessary NULL checks before calling Delete{Global, Local}Ref()

2024-02-27 Thread Matthieu Bouron
Delete{Global,Local}Ref already handle NULL.
---
 libavcodec/mediacodec_wrapper.c | 189 
 1 file changed, 47 insertions(+), 142 deletions(-)

diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index 78cd28f53d..306359071e 100644
--- a/libavcodec/mediacodec_wrapper.c
+++ b/libavcodec/mediacodec_wrapper.c
@@ -549,10 +549,8 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
*mime, int profile, int e
 goto done;
 }
 
-if (codec_name) {
-(*env)->DeleteLocalRef(env, codec_name);
-codec_name = NULL;
-}
+(*env)->DeleteLocalRef(env, codec_name);
+codec_name = NULL;
 
 /* Skip software decoders */
 if (
@@ -616,10 +614,8 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
*mime, int profile, int e
 
 found_codec = profile == supported_profile;
 
-if (profile_level) {
-(*env)->DeleteLocalRef(env, profile_level);
-profile_level = NULL;
-}
+(*env)->DeleteLocalRef(env, profile_level);
+profile_level = NULL;
 
 if (found_codec) {
 break;
@@ -627,20 +623,14 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
*mime, int profile, int e
 }
 
 done_with_type:
-if (profile_levels) {
-(*env)->DeleteLocalRef(env, profile_levels);
-profile_levels = NULL;
-}
+(*env)->DeleteLocalRef(env, profile_levels);
+profile_levels = NULL;
 
-if (capabilities) {
-(*env)->DeleteLocalRef(env, capabilities);
-capabilities = NULL;
-}
+(*env)->DeleteLocalRef(env, capabilities);
+capabilities = NULL;
 
-if (type) {
-(*env)->DeleteLocalRef(env, type);
-type = NULL;
-}
+(*env)->DeleteLocalRef(env, type);
+type = NULL;
 
 av_freep(_type);
 
@@ -650,15 +640,11 @@ done_with_type:
 }
 
 done_with_info:
-if (info) {
-(*env)->DeleteLocalRef(env, info);
-info = NULL;
-}
+(*env)->DeleteLocalRef(env, info);
+info = NULL;
 
-if (types) {
-(*env)->DeleteLocalRef(env, types);
-types = NULL;
-}
+(*env)->DeleteLocalRef(env, types);
+types = NULL;
 
 if (found_codec) {
 break;
@@ -668,33 +654,13 @@ done_with_info:
 }
 
 done:
-if (codec_name) {
-(*env)->DeleteLocalRef(env, codec_name);
-}
-
-if (info) {
-(*env)->DeleteLocalRef(env, info);
-}
-
-if (type) {
-(*env)->DeleteLocalRef(env, type);
-}
-
-if (types) {
-(*env)->DeleteLocalRef(env, types);
-}
-
-if (capabilities) {
-(*env)->DeleteLocalRef(env, capabilities);
-}
-
-if (profile_level) {
-(*env)->DeleteLocalRef(env, profile_level);
-}
-
-if (profile_levels) {
-(*env)->DeleteLocalRef(env, profile_levels);
-}
+(*env)->DeleteLocalRef(env, codec_name);
+(*env)->DeleteLocalRef(env, info);
+(*env)->DeleteLocalRef(env, type);
+(*env)->DeleteLocalRef(env, types);
+(*env)->DeleteLocalRef(env, capabilities);
+(*env)->DeleteLocalRef(env, profile_level);
+(*env)->DeleteLocalRef(env, profile_levels);
 
 av_freep(_type);
 
@@ -741,9 +707,7 @@ static FFAMediaFormat *mediaformat_jni_new(void)
 }
 
 fail:
-if (object) {
-(*env)->DeleteLocalRef(env, object);
-}
+(*env)->DeleteLocalRef(env, object);
 
 if (!format->object) {
 ff_jni_reset_jfields(env, >jfields, jni_amediaformat_mapping, 
1, format);
@@ -828,9 +792,7 @@ static char* mediaformat_jni_toString(FFAMediaFormat* ctx)
 
 ret = ff_jni_jstring_to_utf_chars(env, description, format);
 fail:
-if (description) {
-(*env)->DeleteLocalRef(env, description);
-}
+(*env)->DeleteLocalRef(env, description);
 
 return ret;
 }
@@ -867,9 +829,7 @@ static int mediaformat_jni_getInt32(FFAMediaFormat* ctx, 
const char *name, int32
 
 ret = 1;
 fail:
-if (key) {
-(*env)->DeleteLocalRef(env, key);
-}
+(*env)->DeleteLocalRef(env, key);
 
 return ret;
 }
@@ -906,9 +866,7 @@ static int mediaformat_jni_getInt64(FFAMediaFormat* ctx, 
const char *name, int64
 
 ret = 1;
 fail:
-if (key) {
-(*env)->DeleteLocalRef(env, key);
-}
+(*env)->DeleteLocalRef(env, key);
 
 return ret;
 }
@@ -945,9 +903,7 @@ static int mediaformat_jni_getFloat(FFAMediaFormat* ctx, 
const char *name, float
 
 ret = 1;
 fail:
-if (key) {
-(*env)->DeleteLocalRef(env, key);
-}
+(*env)->DeleteLocalRef(env, key);
 
 return ret;
 }
@@ -999,13 +955,8 @@ static int mediaformat_jni_getBuffer(FFAMediaFormat* ctx, 
const char 

[FFmpeg-devel] [PATCH v2 5/6] avcodec/mediacodec_wrapper: use an OFFSET() macro where relevant

2024-02-27 Thread Matthieu Bouron
Reduces a bit the horizontal spacing.
---
 libavcodec/mediacodec_wrapper.c | 138 +---
 1 file changed, 72 insertions(+), 66 deletions(-)

diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index 0880ddd3ef..78cd28f53d 100644
--- a/libavcodec/mediacodec_wrapper.c
+++ b/libavcodec/mediacodec_wrapper.c
@@ -60,31 +60,33 @@ struct JNIAMediaCodecListFields {
 jfieldID level_id;
 };
 
+#define OFFSET(x) offsetof(struct JNIAMediaCodecListFields, x)
 static const struct FFJniField jni_amediacodeclist_mapping[] = {
-{ "android/media/MediaCodecList", NULL, NULL, FF_JNI_CLASS, 
offsetof(struct JNIAMediaCodecListFields, mediacodec_list_class), 1 },
-{ "android/media/MediaCodecList", "", "(I)V", FF_JNI_METHOD, 
offsetof(struct JNIAMediaCodecListFields, init_id), 0 },
-{ "android/media/MediaCodecList", "findDecoderForFormat", 
"(Landroid/media/MediaFormat;)Ljava/lang/String;", FF_JNI_METHOD, 
offsetof(struct JNIAMediaCodecListFields, find_decoder_for_format_id), 0 },
+{ "android/media/MediaCodecList", NULL, NULL, FF_JNI_CLASS, 
OFFSET(mediacodec_list_class), 1 },
+{ "android/media/MediaCodecList", "", "(I)V", FF_JNI_METHOD, 
OFFSET(init_id), 0 },
+{ "android/media/MediaCodecList", "findDecoderForFormat", 
"(Landroid/media/MediaFormat;)Ljava/lang/String;", FF_JNI_METHOD, 
OFFSET(find_decoder_for_format_id), 0 },
 
-{ "android/media/MediaCodecList", "getCodecCount", "()I", 
FF_JNI_STATIC_METHOD, offsetof(struct JNIAMediaCodecListFields, 
get_codec_count_id), 1 },
-{ "android/media/MediaCodecList", "getCodecInfoAt", 
"(I)Landroid/media/MediaCodecInfo;", FF_JNI_STATIC_METHOD, offsetof(struct 
JNIAMediaCodecListFields, get_codec_info_at_id), 1 },
+{ "android/media/MediaCodecList", "getCodecCount", "()I", 
FF_JNI_STATIC_METHOD, OFFSET(get_codec_count_id), 1 },
+{ "android/media/MediaCodecList", "getCodecInfoAt", 
"(I)Landroid/media/MediaCodecInfo;", FF_JNI_STATIC_METHOD, 
OFFSET(get_codec_info_at_id), 1 },
 
-{ "android/media/MediaCodecInfo", NULL, NULL, FF_JNI_CLASS, 
offsetof(struct JNIAMediaCodecListFields, mediacodec_info_class), 1 },
-{ "android/media/MediaCodecInfo", "getName", "()Ljava/lang/String;", 
FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, get_name_id), 1 },
-{ "android/media/MediaCodecInfo", "getCapabilitiesForType", 
"(Ljava/lang/String;)Landroid/media/MediaCodecInfo$CodecCapabilities;", 
FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, 
get_codec_capabilities_id), 1 },
-{ "android/media/MediaCodecInfo", "getSupportedTypes", 
"()[Ljava/lang/String;", FF_JNI_METHOD, offsetof(struct 
JNIAMediaCodecListFields, get_supported_types_id), 1 },
-{ "android/media/MediaCodecInfo", "isEncoder", "()Z", FF_JNI_METHOD, 
offsetof(struct JNIAMediaCodecListFields, is_encoder_id), 1 },
-{ "android/media/MediaCodecInfo", "isSoftwareOnly", "()Z", 
FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, is_software_only_id), 
0 },
+{ "android/media/MediaCodecInfo", NULL, NULL, FF_JNI_CLASS, 
OFFSET(mediacodec_info_class), 1 },
+{ "android/media/MediaCodecInfo", "getName", "()Ljava/lang/String;", 
FF_JNI_METHOD, OFFSET(get_name_id), 1 },
+{ "android/media/MediaCodecInfo", "getCapabilitiesForType", 
"(Ljava/lang/String;)Landroid/media/MediaCodecInfo$CodecCapabilities;", 
FF_JNI_METHOD, OFFSET(get_codec_capabilities_id), 1 },
+{ "android/media/MediaCodecInfo", "getSupportedTypes", 
"()[Ljava/lang/String;", FF_JNI_METHOD, OFFSET(get_supported_types_id), 1 },
+{ "android/media/MediaCodecInfo", "isEncoder", "()Z", FF_JNI_METHOD, 
OFFSET(is_encoder_id), 1 },
+{ "android/media/MediaCodecInfo", "isSoftwareOnly", "()Z", 
FF_JNI_METHOD, OFFSET(is_software_only_id), 0 },
 
-{ "android/media/MediaCodecInfo$CodecCapabilities", NULL, NULL, 
FF_JNI_CLASS, offsetof(struct JNIAMediaCodecListFields, 
codec_capabilities_class), 1 },
-{ "android/media/MediaCodecInfo$CodecCapabilities", "colorFormats", 
"[I", FF_JNI_FIELD, offsetof(struct JNIAMediaCodecListFields, 
color_formats_id), 1 },
-{ "android/media/MediaCodecInfo$CodecCapabilities", "profileLevels", 
"[Landroid/media/MediaCodecInfo$CodecProfileLevel;", FF_JNI_FIELD, 
offsetof(struct JNIAMediaCodecListFields, profile_levels_id), 1 },
+{ "android/media/MediaCodecInfo$CodecCapabilities", NULL, NULL, 
FF_JNI_CLASS, OFFSET(codec_capabilities_class), 1 },
+{ "android/media/MediaCodecInfo$CodecCapabilities", "colorFormats", 
"[I", FF_JNI_FIELD, OFFSET(color_formats_id), 1 },
+{ "android/media/MediaCodecInfo$CodecCapabilities", "profileLevels", 
"[Landroid/media/MediaCodecInfo$CodecProfileLevel;", FF_JNI_FIELD, 
OFFSET(profile_levels_id), 1 },
 
-{ "android/media/MediaCodecInfo$CodecProfileLevel", NULL, NULL, 
FF_JNI_CLASS, offsetof(struct JNIAMediaCodecListFields, 
codec_profile_level_class), 1 },
-{ 

[FFmpeg-devel] [PATCH v2 4/6] avutil/jni: remove unnecessary NULL checks before calling DeleteLocalRef()

2024-02-27 Thread Matthieu Bouron
Delete{Global,Local}Ref() already handle NULL.
---
 libavcodec/ffjni.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/libavcodec/ffjni.c b/libavcodec/ffjni.c
index e3cf24d3e2..69d9a9faa3 100644
--- a/libavcodec/ffjni.c
+++ b/libavcodec/ffjni.c
@@ -236,17 +236,9 @@ done:
 av_free(name);
 av_free(message);
 
-if (class_class) {
-(*env)->DeleteLocalRef(env, class_class);
-}
-
-if (exception_class) {
-(*env)->DeleteLocalRef(env, exception_class);
-}
-
-if (string) {
-(*env)->DeleteLocalRef(env, string);
-}
+(*env)->DeleteLocalRef(env, class_class);
+(*env)->DeleteLocalRef(env, exception_class);
+(*env)->DeleteLocalRef(env, string);
 
 return ret;
 }
-- 
2.44.0

___
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 v2 3/6] avutil/jni: use size_t to store structure offsets

2024-02-27 Thread Matthieu Bouron
---
 libavcodec/ffjni.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/ffjni.h b/libavcodec/ffjni.h
index 6027bac0ab..d5894609ed 100644
--- a/libavcodec/ffjni.h
+++ b/libavcodec/ffjni.h
@@ -24,6 +24,7 @@
 #define AVCODEC_FFJNI_H
 
 #include 
+#include 
 
 /*
  * Attach permanently a JNI environment to the current thread and retrieve it.
@@ -105,7 +106,7 @@ struct FFJniField {
 const char *method;
 const char *signature;
 enum FFJniFieldType type;
-int offset;
+size_t offset;
 int mandatory;
 
 };
-- 
2.44.0

___
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 v2 2/6] avformat: add Android content resolver protocol support

2024-02-27 Thread Matthieu Bouron
Handles Android content-uri starting with content://.
---
 configure   |   2 +
 doc/APIchanges  |   3 +
 libavcodec/jni.c|   3 +-
 libavformat/Makefile|   1 +
 libavformat/file.c  | 157 
 libavformat/protocols.c |   1 +
 6 files changed, 166 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index bb5e630bad..790a1df7c8 100755
--- a/configure
+++ b/configure
@@ -3655,6 +3655,8 @@ xcbgrab_indev_suggest="libxcb_shm libxcb_shape 
libxcb_xfixes"
 xv_outdev_deps="xlib_xv xlib_x11 xlib_xext"
 
 # protocols
+android_content_protocol_deps="jni"
+android_content_protocol_select="file_protocol"
 async_protocol_deps="threads"
 bluray_protocol_deps="libbluray"
 ffrtmpcrypt_protocol_conflict="librtmp_protocol"
diff --git a/doc/APIchanges b/doc/APIchanges
index 10f6667e9e..258e953ca6 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
 
 API changes, most recent first:
 
+2024-02-xx - xx - lavc 60.41.100 - jni.h
+  Add av_jni_set_android_app_ctx() and av_jni_get_android_app_ctx().
+
 2024-02-26 - xx - lavf 60.22.101 - avformat.h
   AV_DISPOSITION_DEPENDENT may now also be used for video streams
   intended to be merged with other video streams for presentation.
diff --git a/libavcodec/jni.c b/libavcodec/jni.c
index 7d04d0a268..5a75d97f19 100644
--- a/libavcodec/jni.c
+++ b/libavcodec/jni.c
@@ -35,6 +35,7 @@
 #include "ffjni.h"
 
 static void *java_vm;
+static void *android_app_ctx;
 static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
 
 int av_jni_set_java_vm(void *vm, void *log_ctx)
@@ -66,7 +67,7 @@ void *av_jni_get_java_vm(void *log_ctx)
 
 int av_jni_set_android_app_ctx(void *app_ctx, void *log_ctx)
 {
-JNIEnv *env = avpriv_jni_get_env(c);
+JNIEnv *env = ff_jni_get_env(log_ctx);
 if (!env)
 return AVERROR(EINVAL);
 
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 4a380668bd..08fe98a535 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -657,6 +657,7 @@ OBJS-$(CONFIG_LIBOPENMPT_DEMUXER)+= libopenmpt.o
 OBJS-$(CONFIG_VAPOURSYNTH_DEMUXER)   += vapoursynth.o
 
 # protocols I/O
+OBJS-$(CONFIG_ANDROID_CONTENT_PROTOCOL)  += file.o
 OBJS-$(CONFIG_ASYNC_PROTOCOL)+= async.o
 OBJS-$(CONFIG_APPLEHTTP_PROTOCOL)+= hlsproto.o
 OBJS-$(CONFIG_BLURAY_PROTOCOL)   += bluray.o
diff --git a/libavformat/file.c b/libavformat/file.c
index 64df7ff6fb..1b2b69f090 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -40,6 +40,12 @@
 #include 
 #include "os_support.h"
 #include "url.h"
+#if CONFIG_ANDROID_CONTENT_PROTOCOL
+#include 
+#include "libavcodec/jni.h"
+#include "libavcodec/ffjni.c"
+#endif
+
 
 /* Some systems may not have S_ISFIFO */
 #ifndef S_ISFIFO
@@ -101,6 +107,21 @@ typedef struct FileContext {
 int64_t initial_pos;
 } FileContext;
 
+
+#if CONFIG_ANDROID_CONTENT_PROTOCOL
+static const AVOption android_content_options[] = {
+{ "blocksize", "set I/O operation maximum block size", 
offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 1, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
+{ NULL }
+};
+
+static const AVClass android_content_class = {
+.class_name = "android_content",
+.item_name  = av_default_item_name,
+.option = android_content_options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+#endif
+
 static const AVOption file_options[] = {
 { "truncate", "truncate existing files on write", offsetof(FileContext, 
trunc), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, AV_OPT_FLAG_ENCODING_PARAM },
 { "blocksize", "set I/O operation maximum block size", 
offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 1, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
@@ -524,3 +545,139 @@ const URLProtocol ff_fd_protocol = {
 };
 
 #endif /* CONFIG_FD_PROTOCOL */
+
+#if CONFIG_ANDROID_CONTENT_PROTOCOL
+
+struct JFields {
+jclass uri_class;
+jmethodID parse_id;
+
+jclass context_class;
+jmethodID get_content_resolver_id;
+
+jclass content_resolver_class;
+jmethodID open_file_descriptor_id;
+
+jclass parcel_file_descriptor_class;
+jmethodID detach_fd_id;
+};
+
+#define OFFSET(x) offsetof(struct JFields, x)
+static const struct FFJniField jfields_mapping[] = {
+{ "android/net/Uri", NULL, NULL, FF_JNI_CLASS, OFFSET(uri_class), 1 },
+{ "android/net/Uri", "parse", "(Ljava/lang/String;)Landroid/net/Uri;", 
FF_JNI_STATIC_METHOD, OFFSET(parse_id), 1 },
+
+{ "android/content/Context", NULL, NULL, FF_JNI_CLASS, 
OFFSET(context_class), 1 },
+{ "android/content/Context", "getContentResolver", 
"()Landroid/content/ContentResolver;", FF_JNI_METHOD, 
OFFSET(get_content_resolver_id), 1 },
+
+{ "android/content/ContentResolver", NULL, NULL, FF_JNI_CLASS, 
OFFSET(content_resolver_class), 1 },
+{ "android/content/ContentResolver", "openFileDescriptor", 

[FFmpeg-devel] [PATCH v2 1/6] avcodec: add av_jni_{get, set}_android_app_ctx helper

2024-02-27 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.
---
 libavcodec/jni.c | 40 
 libavcodec/jni.h | 17 +
 2 files changed, 57 insertions(+)

diff --git a/libavcodec/jni.c b/libavcodec/jni.c
index ae6490de9d..7d04d0a268 100644
--- a/libavcodec/jni.c
+++ b/libavcodec/jni.c
@@ -64,6 +64,36 @@ void *av_jni_get_java_vm(void *log_ctx)
 return vm;
 }
 
+int av_jni_set_android_app_ctx(void *app_ctx, void *log_ctx)
+{
+JNIEnv *env = avpriv_jni_get_env(c);
+if (!env)
+return AVERROR(EINVAL);
+
+jobjectRefType type = (*env)->GetObjectRefType(env, app_ctx);
+if (type != JNIGlobalRefType) {
+av_log(log_ctx, AV_LOG_ERROR, "Application context must be passed as a 
global reference");
+return AVERROR(EINVAL);
+}
+
+pthread_mutex_lock();
+android_app_ctx = app_ctx;
+pthread_mutex_unlock();
+
+return 0;
+}
+
+void *av_jni_get_android_app_ctx(void)
+{
+void *ctx;
+
+pthread_mutex_lock();
+ctx = android_app_ctx;
+pthread_mutex_unlock();
+
+return ctx;
+}
+
 #else
 
 int av_jni_set_java_vm(void *vm, void *log_ctx)
@@ -76,4 +106,14 @@ void *av_jni_get_java_vm(void *log_ctx)
 return NULL;
 }
 
+int av_jni_set_android_app_ctx(void *app_ctx, void *log_ctx)
+{
+return AVERROR(ENOSYS);
+}
+
+void *av_jni_get_android_app_ctx(void)
+{
+return NULL;
+}
+
 #endif
diff --git a/libavcodec/jni.h b/libavcodec/jni.h
index dd99e92611..da8025f830 100644
--- a/libavcodec/jni.h
+++ b/libavcodec/jni.h
@@ -43,4 +43,21 @@ int av_jni_set_java_vm(void *vm, void *log_ctx);
  */
 void *av_jni_get_java_vm(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
+ * @return 0 on success, < 0 otherwise
+ */
+int av_jni_set_android_app_ctx(void *app_ctx, void *log_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 /* AVCODEC_JNI_H */
-- 
2.44.0

___
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] Add protocol for Android content providers (v2)

2024-02-27 Thread Matthieu Bouron
Diff from initial patchset:
- directly include libavcodec/ffjni.c from libavformat/file.c instead of
  migrating ffjni to libavutil (avpriv_*)
- check that the passed application context reference is a global one and error
  out if it's not the case


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


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();
> > +android_app_ctx = app_ctx;
> > +pthread_mutex_unlock();
> > +}
> > +
> > +void *av_jni_get_android_app_ctx(void)
> > +{
> > +void *ctx;
> > +
> > +pthread_mutex_lock();
> > +ctx = android_app_ctx;
> > +pthread_mutex_unlock();
> > +
> > +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] Add protocol for Android content providers

2024-02-27 Thread Matthieu Bouron
On Tue, Feb 27, 2024 at 09:14:04PM +0800, Zhao Zhili wrote:
> 
> 
> > On Feb 27, 2024, at 15:17, Matthieu Bouron  
> > wrote:
> > 
> > On Sat, Feb 24, 2024 at 12:29:24PM +0100, Matthieu Bouron wrote:
> >> On Thu, Feb 15, 2024 at 10:13:03AM +0100, Matthieu Bouron wrote:
> >>> Le jeu. 15 févr. 2024, 9:46 AM, Zhao Zhili  a
> >>> écrit :
> >>> 
> >>>> 
> >>>>> 在 2024年2月15日,下午3:57,Matthieu Bouron  写道:
> >>>>> 
> >>>>> On Thu, Feb 15, 2024 at 12:13:59PM +0800, Zhao Zhili wrote:
> >>>>>> 
> >>>>>> 
> >>>>>>>> On Feb 14, 2024, at 06:50, Matthieu Bouron 
> >>>>>>>> 
> >>>> 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.
> >>>> 
> >>>> The url still need to be passed from Java to C via JNI, it’s not much
> >>>> different compared to pass fd.
> >>>> 
> >>> 
> >>> It's not that much different I agree. But let's say you have a rendering
> >>> engine (in C) where you need to

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

2024-02-26 Thread Matthieu Bouron
On Sat, Feb 24, 2024 at 12:29:24PM +0100, Matthieu Bouron wrote:
> On Thu, Feb 15, 2024 at 10:13:03AM +0100, Matthieu Bouron wrote:
> > Le jeu. 15 févr. 2024, 9:46 AM, Zhao Zhili  a
> > écrit :
> > 
> > >
> > > > 在 2024年2月15日,下午3:57,Matthieu Bouron  写道:
> > > >
> > > > On Thu, Feb 15, 2024 at 12:13:59PM +0800, Zhao Zhili wrote:
> > > >>
> > > >>
> > > >>>> On Feb 14, 2024, at 06:50, Matthieu Bouron 
> > > >>>> 
> > > 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.
> > >
> > > The url still need to be passed from Java to C via JNI, it’s not much
> > > different compared to pass fd.
> > >
> > 
> > It's not that much different I agree. But let's say you have a rendering
> > engine (in C) where you need to pass hundreds of media (from the user) to
> > render a scene, each media is used at different time during the rendering.
> > And Ffmpeg is not a direct dependency and can be called from different
> > libraries/places used by the rendering engine. Calling
> > av_jni_set_android_app_ctx() and you're done, you can pass the content URI
> > to the engine (passing fd at this stage is not an option imho). You still
> > need to convert the uri from java string to c before calling the c code,
> > but it's a direct translation which is typically part of a binding.
> > 
> > 
> > 
> > > >
> > > >>
> > > >&g

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

2024-02-24 Thread Matthieu Bouron
On Thu, Feb 15, 2024 at 10:13:03AM +0100, Matthieu Bouron wrote:
> Le jeu. 15 févr. 2024, 9:46 AM, Zhao Zhili  a
> écrit :
> 
> >
> > > 在 2024年2月15日,下午3:57,Matthieu Bouron  写道:
> > >
> > > On Thu, Feb 15, 2024 at 12:13:59PM +0800, Zhao Zhili wrote:
> > >>
> > >>
> > >>>> On Feb 14, 2024, at 06:50, Matthieu Bouron 
> > 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.
> >
> > The url still need to be passed from Java to C via JNI, it’s not much
> > different compared to pass fd.
> >
> 
> It's not that much different I agree. But let's say you have a rendering
> engine (in C) where you need to pass hundreds of media (from the user) to
> render a scene, each media is used at different time during the rendering.
> And Ffmpeg is not a direct dependency and can be called from different
> libraries/places used by the rendering engine. Calling
> av_jni_set_android_app_ctx() and you're done, you can pass the content URI
> to the engine (passing fd at this stage is not an option imho). You still
> need to convert the uri from java string to c before calling the c code,
> but it's a direct translation which is typically part of a binding.
> 
> 
> 
> > >
> > >>
> > >>>
> > >>> 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),
> > >>
> &g

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

2024-02-15 Thread Matthieu Bouron
Le jeu. 15 févr. 2024, 9:46 AM, Zhao Zhili  a
écrit :

>
> > 在 2024年2月15日,下午3:57,Matthieu Bouron  写道:
> >
> > On Thu, Feb 15, 2024 at 12:13:59PM +0800, Zhao Zhili wrote:
> >>
> >>
> >>>> On Feb 14, 2024, at 06:50, Matthieu Bouron 
> 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.
>
> The url still need to be passed from Java to C via JNI, it’s not much
> different compared to pass fd.
>

It's not that much different I agree. But let's say you have a rendering
engine (in C) where you need to pass hundreds of media (from the user) to
render a scene, each media is used at different time during the rendering.
And Ffmpeg is not a direct dependency and can be called from different
libraries/places used by the rendering engine. Calling
av_jni_set_android_app_ctx() and you're done, you can pass the content URI
to the engine (passing fd at this stage is not an option imho). You still
need to convert the uri from java string to c before calling the c code,
but it's a direct translation which is typically part of a binding.



> >
> >>
> >>>
> >>> 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 ?
>
> I think it’s our target to reduce the number of avpriv API, not increase
> it. Does duplicate the compile unit work in this case so we don’t need to
> export the symbols?
>

Directly including ffjni.c from libavformat/file.c works. We still need to

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

2024-02-14 Thread Matthieu Bouron
On Thu, Feb 15, 2024 at 12:13:59PM +0800, Zhao Zhili wrote:
> 
> 
> > On Feb 14, 2024, at 06:50, Matthieu Bouron  
> > 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-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/7] avcodec: move ffjni to avutil/jniutils

2024-02-14 Thread Matthieu Bouron
On Wed, Feb 14, 2024 at 11:31:21PM +, Mark Thompson wrote:
> On 13/02/2024 22:50, Matthieu Bouron wrote:
> > This will allow to use the jni utils in libavformat. This will be mostly 
> > useful
> > to add Android content-uri support.
> > 
> > This deprecates avcodec/jni.h functions in favor of the ones from 
> > avutil/jni.h.
> > ---
> >   doc/APIchanges |   6 +
> >   libavcodec/Makefile|   3 +-
> >   libavcodec/jni.c   |  48 +
> >   libavcodec/jni.h   |   8 +
> >   libavcodec/mediacodec.c|   6 +-
> >   libavcodec/mediacodec_surface.c|   6 +-
> >   libavcodec/mediacodec_wrapper.c| 200 ++---
> >   libavcodec/mediacodecdec.c |   3 +-
> >   libavutil/Makefile |   4 +
> >   libavutil/jni.c|  78 
> >   libavutil/jni.h|  46 +
> >   libavcodec/ffjni.c => libavutil/jniutils.c |  36 ++--
> >   libavcodec/ffjni.h => libavutil/jniutils.h |  26 ++-
> >   13 files changed, 283 insertions(+), 187 deletions(-)
> >   create mode 100644 libavutil/jni.c
> >   create mode 100644 libavutil/jni.h
> >   rename libavcodec/ffjni.c => libavutil/jniutils.c (88%)
> >   rename libavcodec/ffjni.h => libavutil/jniutils.h (84%)
> 
> Why?
> 
> libavformat already depends on libavcodec.

Since both libavformat  and libavcodec will use it, it seems more
logical to put the code in libavutil. It could also benefits
libavutil/hwcontext_mediacodec.

[...]
___
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 1/7] avcodec: move ffjni to avutil/jniutils

2024-02-14 Thread Matthieu Bouron
On Wed, Feb 14, 2024 at 07:18:04PM +0100, Michael Niedermayer wrote:
> On Tue, Feb 13, 2024 at 11:50:09PM +0100, Matthieu Bouron wrote:
> > This will allow to use the jni utils in libavformat. This will be mostly 
> > useful
> > to add Android content-uri support.
> > 
> > This deprecates avcodec/jni.h functions in favor of the ones from 
> > avutil/jni.h.
> > ---
> >  doc/APIchanges |   6 +
> >  libavcodec/Makefile|   3 +-
> >  libavcodec/jni.c   |  48 +
> >  libavcodec/jni.h   |   8 +
> >  libavcodec/mediacodec.c|   6 +-
> >  libavcodec/mediacodec_surface.c|   6 +-
> >  libavcodec/mediacodec_wrapper.c| 200 ++---
> >  libavcodec/mediacodecdec.c |   3 +-
> >  libavutil/Makefile |   4 +
> >  libavutil/jni.c|  78 
> >  libavutil/jni.h|  46 +
> >  libavcodec/ffjni.c => libavutil/jniutils.c |  36 ++--
> >  libavcodec/ffjni.h => libavutil/jniutils.h |  26 ++-
> >  13 files changed, 283 insertions(+), 187 deletions(-)
> >  create mode 100644 libavutil/jni.c
> >  create mode 100644 libavutil/jni.h
> >  rename libavcodec/ffjni.c => libavutil/jniutils.c (88%)
> >  rename libavcodec/ffjni.h => libavutil/jniutils.h (84%)
> 
> this breaks build
> 
>  make
> CClibavutil/jni.o
> libavutil/jni.c:68:5: error: no previous prototype for ‘av_jni_set_java_vm’ 
> [-Werror=missing-prototypes]
>  int av_jni_set_java_vm(void *vm, void *log_ctx)
>  ^~
> libavutil/jni.c:73:7: error: no previous prototype for ‘av_jni_get_java_vm’ 
> [-Werror=missing-prototypes]
>  void *av_jni_get_java_vm(void *log_ctx)
>^~
> cc1: some warnings being treated as errors
> ffbuild/common.mak:81: recipe for target 'libavutil/jni.o' failed
> make: *** [libavutil/jni.o] Error 1

Thanks, new patch attached.

[...]
>From 5b6a127143d8a3d111f7bef1a3e3bc9aab60a8ea Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Mon, 12 Feb 2024 18:33:41 +0100
Subject: [PATCH 1/7] avcodec: move ffjni to avutil/jniutils

This will allow to use the jni utils in libavformat. This will be mostly useful
to add Android content-uri support.

This deprecates avcodec/jni.h functions in favor of the ones from avutil/jni.h.
---
 doc/APIchanges |   6 +
 libavcodec/Makefile|   3 +-
 libavcodec/jni.c   |  49 +
 libavcodec/jni.h   |   8 +
 libavcodec/mediacodec.c|   6 +-
 libavcodec/mediacodec_surface.c|   6 +-
 libavcodec/mediacodec_wrapper.c| 200 ++---
 libavcodec/mediacodecdec.c |   3 +-
 libavutil/Makefile |   4 +
 libavutil/jni.c|  78 
 libavutil/jni.h|  46 +
 libavcodec/ffjni.c => libavutil/jniutils.c |  36 ++--
 libavcodec/ffjni.h => libavutil/jniutils.h |  26 ++-
 13 files changed, 284 insertions(+), 187 deletions(-)
 create mode 100644 libavutil/jni.c
 create mode 100644 libavutil/jni.h
 rename libavcodec/ffjni.c => libavutil/jniutils.c (88%)
 rename libavcodec/ffjni.h => libavutil/jniutils.h (84%)

diff --git a/doc/APIchanges b/doc/APIchanges
index 221fea30c2..45611ea7ea 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,12 @@ The last version increases of all libraries were on 2023-02-09
 
 API changes, most recent first:
 
+2024-02-xx - xx - lavu 58.39.100 - jni.h
+  Add av_jni_set_jvm() and av_jni_get_jvm().
+
+2024-02-xx - xx - lavc 60.40.100 - jni.h
+  Deprecate av_jni_set_java_vm() and av_jni_get_java_vm().
+
 2024-02-xx - xx - lavu 58.38.100 - channel_layout.h
   Add av_channel_layout_retype().
 
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 470d7cb9b1..f8584d8dfd 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -117,7 +117,7 @@ OBJS-$(CONFIG_IIRFILTER)   += iirfilter.o
 OBJS-$(CONFIG_INFLATE_WRAPPER) += zlib_wrapper.o
 OBJS-$(CONFIG_INTRAX8) += intrax8.o intrax8dsp.o msmpeg4data.o
 OBJS-$(CONFIG_IVIDSP)  += ivi_dsp.o
-OBJS-$(CONFIG_JNI) += ffjni.o jni.o
+OBJS-$(CONFIG_JNI) += jni.o
 OBJS-$(CONFIG_JPEGTABLES)  += jpegtables.o
 OBJS-$(CONFIG_LCMS2)   += fflcms2.o
 OBJS-$(CONFIG_LLAUDDSP)+= lossless_audiodsp.o
@@ -1269,7 +1269,6 @@ SKIPHEADERS-$(CONFIG_AMF)  += amfenc.h
 SKIPHEADERS-$(CONFIG_D3D11VA)  += d3d11va.h dxva2_internal.h
 SKIPHEADERS-$(C

[FFmpeg-devel] [PATCH 7/7] avcodec/mediacodec_wrapper: remove unnecessary NULL checks before calling Delete{Global, Local}Ref()

2024-02-13 Thread Matthieu Bouron
Delete{Global,Local}Ref already handle NULL.
---
 libavcodec/mediacodec_wrapper.c | 189 
 1 file changed, 47 insertions(+), 142 deletions(-)

diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index 536b5b8e81..19d63e2ba0 100644
--- a/libavcodec/mediacodec_wrapper.c
+++ b/libavcodec/mediacodec_wrapper.c
@@ -549,10 +549,8 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
*mime, int profile, int e
 goto done;
 }
 
-if (codec_name) {
-(*env)->DeleteLocalRef(env, codec_name);
-codec_name = NULL;
-}
+(*env)->DeleteLocalRef(env, codec_name);
+codec_name = NULL;
 
 /* Skip software decoders */
 if (
@@ -616,10 +614,8 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
*mime, int profile, int e
 
 found_codec = profile == supported_profile;
 
-if (profile_level) {
-(*env)->DeleteLocalRef(env, profile_level);
-profile_level = NULL;
-}
+(*env)->DeleteLocalRef(env, profile_level);
+profile_level = NULL;
 
 if (found_codec) {
 break;
@@ -627,20 +623,14 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
*mime, int profile, int e
 }
 
 done_with_type:
-if (profile_levels) {
-(*env)->DeleteLocalRef(env, profile_levels);
-profile_levels = NULL;
-}
+(*env)->DeleteLocalRef(env, profile_levels);
+profile_levels = NULL;
 
-if (capabilities) {
-(*env)->DeleteLocalRef(env, capabilities);
-capabilities = NULL;
-}
+(*env)->DeleteLocalRef(env, capabilities);
+capabilities = NULL;
 
-if (type) {
-(*env)->DeleteLocalRef(env, type);
-type = NULL;
-}
+(*env)->DeleteLocalRef(env, type);
+type = NULL;
 
 av_freep(_type);
 
@@ -650,15 +640,11 @@ done_with_type:
 }
 
 done_with_info:
-if (info) {
-(*env)->DeleteLocalRef(env, info);
-info = NULL;
-}
+(*env)->DeleteLocalRef(env, info);
+info = NULL;
 
-if (types) {
-(*env)->DeleteLocalRef(env, types);
-types = NULL;
-}
+(*env)->DeleteLocalRef(env, types);
+types = NULL;
 
 if (found_codec) {
 break;
@@ -668,33 +654,13 @@ done_with_info:
 }
 
 done:
-if (codec_name) {
-(*env)->DeleteLocalRef(env, codec_name);
-}
-
-if (info) {
-(*env)->DeleteLocalRef(env, info);
-}
-
-if (type) {
-(*env)->DeleteLocalRef(env, type);
-}
-
-if (types) {
-(*env)->DeleteLocalRef(env, types);
-}
-
-if (capabilities) {
-(*env)->DeleteLocalRef(env, capabilities);
-}
-
-if (profile_level) {
-(*env)->DeleteLocalRef(env, profile_level);
-}
-
-if (profile_levels) {
-(*env)->DeleteLocalRef(env, profile_levels);
-}
+(*env)->DeleteLocalRef(env, codec_name);
+(*env)->DeleteLocalRef(env, info);
+(*env)->DeleteLocalRef(env, type);
+(*env)->DeleteLocalRef(env, types);
+(*env)->DeleteLocalRef(env, capabilities);
+(*env)->DeleteLocalRef(env, profile_level);
+(*env)->DeleteLocalRef(env, profile_levels);
 
 av_freep(_type);
 
@@ -741,9 +707,7 @@ static FFAMediaFormat *mediaformat_jni_new(void)
 }
 
 fail:
-if (object) {
-(*env)->DeleteLocalRef(env, object);
-}
+(*env)->DeleteLocalRef(env, object);
 
 if (!format->object) {
 avpriv_jni_reset_jfields(env, >jfields, 
jni_amediaformat_mapping, 1, format);
@@ -828,9 +792,7 @@ static char* mediaformat_jni_toString(FFAMediaFormat* ctx)
 
 ret = avpriv_jni_jstring_to_utf_chars(env, description, format);
 fail:
-if (description) {
-(*env)->DeleteLocalRef(env, description);
-}
+(*env)->DeleteLocalRef(env, description);
 
 return ret;
 }
@@ -867,9 +829,7 @@ static int mediaformat_jni_getInt32(FFAMediaFormat* ctx, 
const char *name, int32
 
 ret = 1;
 fail:
-if (key) {
-(*env)->DeleteLocalRef(env, key);
-}
+(*env)->DeleteLocalRef(env, key);
 
 return ret;
 }
@@ -906,9 +866,7 @@ static int mediaformat_jni_getInt64(FFAMediaFormat* ctx, 
const char *name, int64
 
 ret = 1;
 fail:
-if (key) {
-(*env)->DeleteLocalRef(env, key);
-}
+(*env)->DeleteLocalRef(env, key);
 
 return ret;
 }
@@ -945,9 +903,7 @@ static int mediaformat_jni_getFloat(FFAMediaFormat* ctx, 
const char *name, float
 
 ret = 1;
 fail:
-if (key) {
-(*env)->DeleteLocalRef(env, key);
-}
+(*env)->DeleteLocalRef(env, key);
 
 return ret;
 }
@@ -999,13 +955,8 @@ static int mediaformat_jni_getBuffer(FFAMediaFormat* ctx, 

[FFmpeg-devel] [PATCH 5/7] avutil/jni: remove unnecessary NULL checks before calling DeleteLocalRef()

2024-02-13 Thread Matthieu Bouron
Delete{Global,Local}Ref() already handle NULL.
---
 libavutil/jniutils.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/libavutil/jniutils.c b/libavutil/jniutils.c
index 89623af3f8..beedf24c0d 100644
--- a/libavutil/jniutils.c
+++ b/libavutil/jniutils.c
@@ -236,17 +236,9 @@ done:
 av_free(name);
 av_free(message);
 
-if (class_class) {
-(*env)->DeleteLocalRef(env, class_class);
-}
-
-if (exception_class) {
-(*env)->DeleteLocalRef(env, exception_class);
-}
-
-if (string) {
-(*env)->DeleteLocalRef(env, string);
-}
+(*env)->DeleteLocalRef(env, class_class);
+(*env)->DeleteLocalRef(env, exception_class);
+(*env)->DeleteLocalRef(env, string);
 
 return ret;
 }
-- 
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".


[FFmpeg-devel] [PATCH 6/7] avcodec/mediacodec_wrapper: use an OFFSET() macro where relevant

2024-02-13 Thread Matthieu Bouron
Reduces a bit the horizontal spacing.
---
 libavcodec/mediacodec_wrapper.c | 138 +---
 1 file changed, 72 insertions(+), 66 deletions(-)

diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index bc3eb0a80d..536b5b8e81 100644
--- a/libavcodec/mediacodec_wrapper.c
+++ b/libavcodec/mediacodec_wrapper.c
@@ -60,31 +60,33 @@ struct JNIAMediaCodecListFields {
 jfieldID level_id;
 };
 
+#define OFFSET(x) offsetof(struct JNIAMediaCodecListFields, x)
 static const struct FFJniField jni_amediacodeclist_mapping[] = {
-{ "android/media/MediaCodecList", NULL, NULL, FF_JNI_CLASS, 
offsetof(struct JNIAMediaCodecListFields, mediacodec_list_class), 1 },
-{ "android/media/MediaCodecList", "", "(I)V", FF_JNI_METHOD, 
offsetof(struct JNIAMediaCodecListFields, init_id), 0 },
-{ "android/media/MediaCodecList", "findDecoderForFormat", 
"(Landroid/media/MediaFormat;)Ljava/lang/String;", FF_JNI_METHOD, 
offsetof(struct JNIAMediaCodecListFields, find_decoder_for_format_id), 0 },
+{ "android/media/MediaCodecList", NULL, NULL, FF_JNI_CLASS, 
OFFSET(mediacodec_list_class), 1 },
+{ "android/media/MediaCodecList", "", "(I)V", FF_JNI_METHOD, 
OFFSET(init_id), 0 },
+{ "android/media/MediaCodecList", "findDecoderForFormat", 
"(Landroid/media/MediaFormat;)Ljava/lang/String;", FF_JNI_METHOD, 
OFFSET(find_decoder_for_format_id), 0 },
 
-{ "android/media/MediaCodecList", "getCodecCount", "()I", 
FF_JNI_STATIC_METHOD, offsetof(struct JNIAMediaCodecListFields, 
get_codec_count_id), 1 },
-{ "android/media/MediaCodecList", "getCodecInfoAt", 
"(I)Landroid/media/MediaCodecInfo;", FF_JNI_STATIC_METHOD, offsetof(struct 
JNIAMediaCodecListFields, get_codec_info_at_id), 1 },
+{ "android/media/MediaCodecList", "getCodecCount", "()I", 
FF_JNI_STATIC_METHOD, OFFSET(get_codec_count_id), 1 },
+{ "android/media/MediaCodecList", "getCodecInfoAt", 
"(I)Landroid/media/MediaCodecInfo;", FF_JNI_STATIC_METHOD, 
OFFSET(get_codec_info_at_id), 1 },
 
-{ "android/media/MediaCodecInfo", NULL, NULL, FF_JNI_CLASS, 
offsetof(struct JNIAMediaCodecListFields, mediacodec_info_class), 1 },
-{ "android/media/MediaCodecInfo", "getName", "()Ljava/lang/String;", 
FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, get_name_id), 1 },
-{ "android/media/MediaCodecInfo", "getCapabilitiesForType", 
"(Ljava/lang/String;)Landroid/media/MediaCodecInfo$CodecCapabilities;", 
FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, 
get_codec_capabilities_id), 1 },
-{ "android/media/MediaCodecInfo", "getSupportedTypes", 
"()[Ljava/lang/String;", FF_JNI_METHOD, offsetof(struct 
JNIAMediaCodecListFields, get_supported_types_id), 1 },
-{ "android/media/MediaCodecInfo", "isEncoder", "()Z", FF_JNI_METHOD, 
offsetof(struct JNIAMediaCodecListFields, is_encoder_id), 1 },
-{ "android/media/MediaCodecInfo", "isSoftwareOnly", "()Z", 
FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, is_software_only_id), 
0 },
+{ "android/media/MediaCodecInfo", NULL, NULL, FF_JNI_CLASS, 
OFFSET(mediacodec_info_class), 1 },
+{ "android/media/MediaCodecInfo", "getName", "()Ljava/lang/String;", 
FF_JNI_METHOD, OFFSET(get_name_id), 1 },
+{ "android/media/MediaCodecInfo", "getCapabilitiesForType", 
"(Ljava/lang/String;)Landroid/media/MediaCodecInfo$CodecCapabilities;", 
FF_JNI_METHOD, OFFSET(get_codec_capabilities_id), 1 },
+{ "android/media/MediaCodecInfo", "getSupportedTypes", 
"()[Ljava/lang/String;", FF_JNI_METHOD, OFFSET(get_supported_types_id), 1 },
+{ "android/media/MediaCodecInfo", "isEncoder", "()Z", FF_JNI_METHOD, 
OFFSET(is_encoder_id), 1 },
+{ "android/media/MediaCodecInfo", "isSoftwareOnly", "()Z", 
FF_JNI_METHOD, OFFSET(is_software_only_id), 0 },
 
-{ "android/media/MediaCodecInfo$CodecCapabilities", NULL, NULL, 
FF_JNI_CLASS, offsetof(struct JNIAMediaCodecListFields, 
codec_capabilities_class), 1 },
-{ "android/media/MediaCodecInfo$CodecCapabilities", "colorFormats", 
"[I", FF_JNI_FIELD, offsetof(struct JNIAMediaCodecListFields, 
color_formats_id), 1 },
-{ "android/media/MediaCodecInfo$CodecCapabilities", "profileLevels", 
"[Landroid/media/MediaCodecInfo$CodecProfileLevel;", FF_JNI_FIELD, 
offsetof(struct JNIAMediaCodecListFields, profile_levels_id), 1 },
+{ "android/media/MediaCodecInfo$CodecCapabilities", NULL, NULL, 
FF_JNI_CLASS, OFFSET(codec_capabilities_class), 1 },
+{ "android/media/MediaCodecInfo$CodecCapabilities", "colorFormats", 
"[I", FF_JNI_FIELD, OFFSET(color_formats_id), 1 },
+{ "android/media/MediaCodecInfo$CodecCapabilities", "profileLevels", 
"[Landroid/media/MediaCodecInfo$CodecProfileLevel;", FF_JNI_FIELD, 
OFFSET(profile_levels_id), 1 },
 
-{ "android/media/MediaCodecInfo$CodecProfileLevel", NULL, NULL, 
FF_JNI_CLASS, offsetof(struct JNIAMediaCodecListFields, 
codec_profile_level_class), 1 },
-{ 

[FFmpeg-devel] [PATCH 4/7] avutil/jni: use size_t to store structure offsets

2024-02-13 Thread Matthieu Bouron
---
 libavutil/jniutils.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavutil/jniutils.h b/libavutil/jniutils.h
index 2be401c974..01f3acb88d 100644
--- a/libavutil/jniutils.h
+++ b/libavutil/jniutils.h
@@ -24,6 +24,7 @@
 #define AVUTIL_JNIUTILS_H
 
 #include 
+#include 
 
 /*
  * Attach permanently a JNI environment to the current thread and retrieve it.
@@ -102,7 +103,7 @@ struct FFJniField {
 const char *method;
 const char *signature;
 enum FFJniFieldType type;
-int offset;
+size_t offset;
 int mandatory;
 };
 
-- 
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".


[FFmpeg-devel] [PATCH 3/7] avformat: add Android content resolver protocol support

2024-02-13 Thread Matthieu Bouron
Handles Android content-uri starting with content://.
---
 configure   |   2 +
 doc/APIchanges  |   3 +
 libavformat/Makefile|   1 +
 libavformat/file.c  | 157 
 libavformat/protocols.c |   1 +
 5 files changed, 164 insertions(+)

diff --git a/configure b/configure
index f72533b7d2..a3593dc200 100755
--- a/configure
+++ b/configure
@@ -3651,6 +3651,8 @@ xcbgrab_indev_suggest="libxcb_shm libxcb_shape 
libxcb_xfixes"
 xv_outdev_deps="xlib_xv xlib_x11 xlib_xext"
 
 # protocols
+android_content_protocol_deps="jni"
+android_content_protocol_select="file_protocol"
 async_protocol_deps="threads"
 bluray_protocol_deps="libbluray"
 ffrtmpcrypt_protocol_conflict="librtmp_protocol"
diff --git a/doc/APIchanges b/doc/APIchanges
index 45611ea7ea..7f6631b3d3 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
 
 API changes, most recent first:
 
+2024-02-xx - xx - lavu 58.40.100 - jni.h
+  Add av_jni_set_android_app_ctx() and av_jni_get_android_app_ctx().
+
 2024-02-xx - xx - lavu 58.39.100 - jni.h
   Add av_jni_set_jvm() and av_jni_get_jvm().
 
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 05b9b8a115..788d4e4135 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -655,6 +655,7 @@ OBJS-$(CONFIG_LIBOPENMPT_DEMUXER)+= libopenmpt.o
 OBJS-$(CONFIG_VAPOURSYNTH_DEMUXER)   += vapoursynth.o
 
 # protocols I/O
+OBJS-$(CONFIG_ANDROID_CONTENT_PROTOCOL)  += file.o
 OBJS-$(CONFIG_ASYNC_PROTOCOL)+= async.o
 OBJS-$(CONFIG_APPLEHTTP_PROTOCOL)+= hlsproto.o
 OBJS-$(CONFIG_BLURAY_PROTOCOL)   += bluray.o
diff --git a/libavformat/file.c b/libavformat/file.c
index 64df7ff6fb..c7c7a5073f 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -40,6 +40,12 @@
 #include 
 #include "os_support.h"
 #include "url.h"
+#if CONFIG_ANDROID_CONTENT_PROTOCOL
+#include 
+#include "libavutil/jni.h"
+#include "libavutil/jniutils.h"
+#endif
+
 
 /* Some systems may not have S_ISFIFO */
 #ifndef S_ISFIFO
@@ -101,6 +107,21 @@ typedef struct FileContext {
 int64_t initial_pos;
 } FileContext;
 
+
+#if CONFIG_ANDROID_CONTENT_PROTOCOL
+static const AVOption android_content_options[] = {
+{ "blocksize", "set I/O operation maximum block size", 
offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 1, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
+{ NULL }
+};
+
+static const AVClass android_content_class = {
+.class_name = "android_content",
+.item_name  = av_default_item_name,
+.option = android_content_options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+#endif
+
 static const AVOption file_options[] = {
 { "truncate", "truncate existing files on write", offsetof(FileContext, 
trunc), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, AV_OPT_FLAG_ENCODING_PARAM },
 { "blocksize", "set I/O operation maximum block size", 
offsetof(FileContext, blocksize), AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 1, 
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
@@ -524,3 +545,139 @@ const URLProtocol ff_fd_protocol = {
 };
 
 #endif /* CONFIG_FD_PROTOCOL */
+
+#if CONFIG_ANDROID_CONTENT_PROTOCOL
+
+struct JFields {
+jclass uri_class;
+jmethodID parse_id;
+
+jclass context_class;
+jmethodID get_content_resolver_id;
+
+jclass content_resolver_class;
+jmethodID open_file_descriptor_id;
+
+jclass parcel_file_descriptor_class;
+jmethodID detach_fd_id;
+};
+
+#define OFFSET(x) offsetof(struct JFields, x)
+static const struct FFJniField jfields_mapping[] = {
+{ "android/net/Uri", NULL, NULL, FF_JNI_CLASS, OFFSET(uri_class), 1 },
+{ "android/net/Uri", "parse", "(Ljava/lang/String;)Landroid/net/Uri;", 
FF_JNI_STATIC_METHOD, OFFSET(parse_id), 1 },
+
+{ "android/content/Context", NULL, NULL, FF_JNI_CLASS, 
OFFSET(context_class), 1 },
+{ "android/content/Context", "getContentResolver", 
"()Landroid/content/ContentResolver;", FF_JNI_METHOD, 
OFFSET(get_content_resolver_id), 1 },
+
+{ "android/content/ContentResolver", NULL, NULL, FF_JNI_CLASS, 
OFFSET(content_resolver_class), 1 },
+{ "android/content/ContentResolver", "openFileDescriptor", 
"(Landroid/net/Uri;Ljava/lang/String;)Landroid/os/ParcelFileDescriptor;", 
FF_JNI_METHOD, OFFSET(open_file_descriptor_id), 1 },
+
+{ "android/os/ParcelFileDescriptor", NULL, NULL, FF_JNI_CLASS, 
OFFSET(parcel_file_descriptor_class), 1 },
+{ "android/os/ParcelFileDescriptor", "detachFd", "()I", FF_JNI_METHOD, 
OFFSET(detach_fd_id), 1 },
+
+{ NULL }
+};
+#undef OFFSET
+
+static int android_content_open(URLContext *h, const char *filename, int flags)
+{
+FileContext *c = h->priv_data;
+int fd, ret;
+const char *mode_str = "r";
+
+JNIEnv *env;
+struct JFields jfields = { 0 };
+jobject application_context = NULL;
+jobject url = NULL;
+jobject mode = NULL;
+jobject uri = NULL;
+jobject 

[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();
+android_app_ctx = app_ctx;
+pthread_mutex_unlock();
+}
+
+void *av_jni_get_android_app_ctx(void)
+{
+void *ctx;
+
+pthread_mutex_lock();
+ctx = android_app_ctx;
+pthread_mutex_unlock();
+
+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".


[FFmpeg-devel] [PATCH 1/7] avcodec: move ffjni to avutil/jniutils

2024-02-13 Thread Matthieu Bouron
t_stream_id);
-if (ff_jni_exception_check(env, 1, codec) < 0) {
+if (avpriv_jni_exception_check(env, 1, codec) < 0) {
 return AVERROR_EXTERNAL;
 }
 
diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index b8587289a2..128a5bfef1 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -29,6 +29,7 @@
 #include "libavutil/common.h"
 #include "libavutil/opt.h"
 #include "libavutil/intreadwrite.h"
+#include "libavutil/jni.h"
 #include "libavutil/pixfmt.h"
 #include "libavutil/internal.h"
 
@@ -314,7 +315,7 @@ static av_cold int mediacodec_decode_init(AVCodecContext 
*avctx)
 MediaCodecH264DecContext *s = avctx->priv_data;
 
 if (s->use_ndk_codec < 0)
-s->use_ndk_codec = !av_jni_get_java_vm(avctx);
+s->use_ndk_codec = !av_jni_get_jvm(avctx);
 
 format = ff_AMediaFormat_new(s->use_ndk_codec);
 if (!format) {
diff --git a/libavutil/Makefile b/libavutil/Makefile
index e7709b97d0..e28944b1b6 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -56,6 +56,7 @@ HEADERS = adler32.h   
  \
   imgutils.h\
   intfloat.h\
   intreadwrite.h\
+  jni.h \
   lfg.h \
   log.h \
   lzo.h \
@@ -146,6 +147,7 @@ OBJS = adler32.o
\
imgutils.o   \
integer.o\
intmath.o\
+   jni.o\
lfg.o\
    lls.o    \
log.o\
@@ -195,6 +197,7 @@ OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o
 OBJS-$(CONFIG_D3D11VA)  += hwcontext_d3d11va.o
 OBJS-$(CONFIG_D3D12VA)  += hwcontext_d3d12va.o
 OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o
+OBJS-$(CONFIG_JNI)  += jniutils.o
 OBJS-$(CONFIG_LIBDRM)   += hwcontext_drm.o
 OBJS-$(CONFIG_MACOS_KPERF)  += macos_kperf.o
 OBJS-$(CONFIG_MEDIACODEC)   += hwcontext_mediacodec.o
@@ -219,6 +222,7 @@ SKIPHEADERS-$(CONFIG_CUDA) += 
hwcontext_cuda_internal.h \
 SKIPHEADERS-$(CONFIG_D3D11VA)  += hwcontext_d3d11va.h
 SKIPHEADERS-$(CONFIG_D3D12VA)  += hwcontext_d3d12va.h
 SKIPHEADERS-$(CONFIG_DXVA2)+= hwcontext_dxva2.h
+SKIPHEADERS-$(CONFIG_JNI)  += jniutils.h
 SKIPHEADERS-$(CONFIG_QSV)  += hwcontext_qsv.h
 SKIPHEADERS-$(CONFIG_OPENCL)   += hwcontext_opencl.h
 SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
diff --git a/libavutil/jni.c b/libavutil/jni.c
new file mode 100644
index 00..541747cb20
--- /dev/null
+++ b/libavutil/jni.c
@@ -0,0 +1,78 @@
+/*
+ * JNI public API functions
+ *
+ * Copyright (c) 2015-2016 Matthieu Bouron 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config.h"
+
+#include 
+
+#include "libavutil/error.h"
+
+#if CONFIG_JNI
+#include 
+#include 
+
+#include "libavutil/log.h"
+#include "libavutil/jni.h"
+
+static void *java_vm;
+static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
+
+int av_jni_set_jvm(void *vm, void *log_ctx)
+{
+int ret = 0;
+
+pthread_mutex_lock();
+if (java_vm == NULL) {
+java_vm = vm;
+} else if (java_vm != vm) {
+ret = AVERROR(EINVAL);
+av_log(log_ctx, AV_LOG_ERROR, "A Java virtual machine has already been 
set");
+}
+pthread_mutex_unlock();
+
+return 

[FFmpeg-devel] Add protocol for Android content providers

2024-02-13 Thread Matthieu Bouron
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
option. Both options will have to deal with the JNI though and end users will
have to re-implement the same exact thing.

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), 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".


Re: [FFmpeg-devel] [PATCH] avfft: avoid overreads with RDFT API users

2024-02-09 Thread Matthieu Bouron
On Fri, Feb 09, 2024 at 06:27:50PM +0100, Lynne wrote:
> The new API requires an extra array member at the very end,
> which old API users did not do.
> 
> This disables in-place RDFT transforms and instead
> does the transform out of place by copying once, there shouldn't
> be a significant loss of speed as our in-place FFT requires a reorder
> which is likely more expensive in the majority of cases to do.
> 
> Patch attached.
> 

> From 763f2e8941dc3dd4282ad42574bd8d451a256a53 Mon Sep 17 00:00:00 2001
> From: Lynne 
> Date: Fri, 9 Feb 2024 18:17:54 +0100
> Subject: [PATCH] avfft: avoid overreads with RDFT API users
> 
> The new API requires an extra array member at the very end,
> which old API users did not do.
> 
> This disables in-place RDFT transforms and instead
> does the transform out of place by copying once, there shouldn't
> be a significant loss of speed as our in-place FFT requires a reorder
> which is likely more expensive in the majority of cases to do.
> ---
>  libavcodec/avfft.c | 31 +--
>  1 file changed, 25 insertions(+), 6 deletions(-)
> 
> diff --git a/libavcodec/avfft.c b/libavcodec/avfft.c
> index 999b5ed79a..485f216427 100644
> --- a/libavcodec/avfft.c
> +++ b/libavcodec/avfft.c
> @@ -152,7 +152,7 @@ RDFTContext *av_rdft_init(int nbits, enum 
> RDFTransformType trans)
>  return NULL;
>  
>  ret = av_tx_init(>ctx, >fn, AV_TX_FLOAT_RDFT, trans == IDFT_C2R,
> - 1 << nbits, , AV_TX_INPLACE);
> + 1 << nbits, , 0x0);
>  if (ret < 0) {
>  av_free(s);
>  return NULL;
> @@ -162,17 +162,35 @@ RDFTContext *av_rdft_init(int nbits, enum 
> RDFTransformType trans)
>  s->len = 1 << nbits;
>  s->inv = trans == IDFT_C2R;
>  
> +s->tmp = av_malloc((s->len + 2)*sizeof(float));
> +if (!s->tmp) {
> +av_tx_uninit(>ctx);
> +av_free(s);
> +return NULL;
> +}
> +
>  return (RDFTContext *)s;
>  }
>  
>  void av_rdft_calc(RDFTContext *s, FFTSample *data)
>  {
>  AVTXWrapper *w = (AVTXWrapper *)s;
> -if (w->inv)
> -FFSWAP(float, data[1], data[w->len]);
> -w->fn(w->ctx, data, (void *)data, w->stride);
> -if (!w->inv)
> -FFSWAP(float, data[1], data[w->len]);
> +float *src = w->inv ? w->tmp : (float *)data;
> +float *dst = w->inv ? (float *)data : w->tmp;
> +
> +if (w->inv) {
> +memcpy(src, data, w->len*sizeof(float));
> +
> +src[w->len] = src[1];
> +src[1] = 0.0f;
> +}
> +
> +w->fn(w->ctx, dst, (void *)src, w->stride);
> +
> +if (!w->inv) {
> +dst[1] = dst[w->len];
> +memcpy(data, dst, w->len*sizeof(float));
> +}
>  }
>  
>  av_cold void av_rdft_end(RDFTContext *s)
> @@ -180,6 +198,7 @@ av_cold void av_rdft_end(RDFTContext *s)
>  if (s) {
>  AVTXWrapper *w = (AVTXWrapper *)s;
>  av_tx_uninit(>ctx);
> +av_free(>tmp);

av_free(w->tmp);

>  av_free(w);
>  }
>  }
> -- 
> 2.43.0.381.gb435a96ce8
> 

Hi,

I tested the patch with the av_free() adjustment and it fixed the crash /
memory corruption I was encountering on macOS.

Thanks,
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".


Re: [FFmpeg-devel] [PATCH] avcodec/mediacodecenc: set quality in cq mode

2023-12-19 Thread Matthieu Bouron
On Sun, Dec 17, 2023 at 1:51 PM Zhao Zhili  wrote:
>
> From: Zhao Zhili 
>
> From AOSP doc, these values are device and codec specific, but lower
> values generally result in more efficient (smaller-sized) encoding.
>
> For example, global_quality 50 on Pixel 6 results a 1080P 30 FPS
> HEVC with 3744 kb/s, while global_quality 80 results 28178 kb/s.
>
> Fix #10689
>
> Signed-off-by: Zhao Zhili 
> ---
>  libavcodec/mediacodecenc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/mediacodecenc.c b/libavcodec/mediacodecenc.c
> index a1ae5d5ec5..7eae542248 100644
> --- a/libavcodec/mediacodecenc.c
> +++ b/libavcodec/mediacodecenc.c
> @@ -268,8 +268,11 @@ static av_cold int mediacodec_init(AVCodecContext *avctx)
>
>  if (avctx->bit_rate)
>  ff_AMediaFormat_setInt32(format, "bitrate", avctx->bit_rate);
> -if (s->bitrate_mode >= 0)
> +if (s->bitrate_mode >= 0) {
>  ff_AMediaFormat_setInt32(format, "bitrate-mode", s->bitrate_mode);
> +if (s->bitrate_mode == BITRATE_MODE_CQ && avctx->global_quality > 0)
> +ff_AMediaFormat_setInt32(format, "quality", 
> avctx->global_quality);
> +}
>  // frame-rate and i-frame-interval are required to configure codec
>  if (avctx->framerate.num >= avctx->framerate.den && avctx->framerate.den 
> > 0) {
>  s->fps = avctx->framerate.num / avctx->framerate.den;
> --
> 2.34.1
>

Does the `global_quality` value need to be checked/clamped against
`MediaCodecInfo.EncoderCapabilities.getQualityRange()` before use ?
Otherwise, LGTM.
___
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/2] avcodec/jni: make global variables static

2023-09-17 Thread Matthieu Bouron
On Sun, Sep 17, 2023 at 5:38 AM Zhao Zhili  wrote:

> From: Zhao Zhili 
>
> Signed-off-by: Zhao Zhili 
> ---
>  libavcodec/jni.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/jni.c b/libavcodec/jni.c
> index 85dcf2abaf..ae6490de9d 100644
> --- a/libavcodec/jni.c
> +++ b/libavcodec/jni.c
> @@ -34,8 +34,8 @@
>  #include "libavutil/log.h"
>  #include "ffjni.h"
>
> -void *java_vm;
> -pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
> +static void *java_vm;
> +static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
>
>  int av_jni_set_java_vm(void *vm, void *log_ctx)
>  {
> --
> 2.34.1
>
>
LGTM.

Thanks,
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".


Re: [FFmpeg-devel] Consulting Request

2022-11-12 Thread Matthieu Bouron
Hello,

This work has been submitted to the ml recently, see:
http://ffmpeg.org/pipermail/ffmpeg-devel/2022-November/303847.html

Matthieu

On Sat, Nov 12, 2022 at 11:13 AM Olivier Ayache 
wrote:

> Hello and sorry for my late answer but few years ago I have implemented
> this kind of feature.
> Here is a repo containing my work
> https://github.com/olivierayache/xuggle-xuggler.
> In my current company we use it in production for implementing a media
> studio on Android with HW acceleration support.
>
> Olivier Ayache
>
> On Fri, Jun 3, 2022 at 5:02 PM Samuel Raposo Vieira Mira <
> samuel.m...@qt.io>
> wrote:
>
> > Hi all,
> >
> > We are Qt (www.qt.io), a global software company with a strong presence
> > in more than 70 industries and is the leading independent technology
> behind
> > 1+ billion devices and applications.
> >
> > Now we are working on integrating the FFmpeg library into our Multimedia
> > module as one of the possible backends.
> > Android is one of our target platforms, and we now face the issue of
> > lacking Hardware Acceleration for Encoding for Android.
> >
> > We are evaluating the possibility of hiring a consulting service to
> > implement the Mediacodec Hardware encoder in FFmpeg.
> > So we would like to know if any developer would be interested in taking
> on
> > this consulting project.
> >
> > Regards,
> > Samuel Mira
> > Senior Software Developer
> > The Qt Company
> > Tutkijantie 4C
> > FI-90590 Oulu
> > Finland
> > samuel.m...@qt.io
> > www.qt.io
> > [signature_1385223811]
> > [signature_2378664325]
> > [signature_2256736393]
> > [signature_2852832549]
> > [signature_228390225]
> >
> > ___
> > 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".
>
___
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] mediacodecdec_common: enable refcounting of buffers unconditionally

2022-09-28 Thread Matthieu Bouron
On Wed, Sep 28, 2022 at 10:27:49AM +0200, Anton Khirnov wrote:
> Quoting sfan5 (2022-09-18 20:26:48)
> > This allows av_mediacodec_release_buffer to be called safely after
> > the decoder is closed, this was already the case with delay_flush=1.
> > Note that this causes holding onto frames to keep the decoding context
> > alive which is generally considered to be the intended behavior
> > 
> > 
> > (resending as my patch got mangled somehow)
> 
> The patch looks like it makes sense, but I have no experience with this
> code. CCing the maintainer, will push in a few days if nobody objects.

Sorry for the wait, the patch looks good to me.

Thanks,
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".


Re: [FFmpeg-devel] [PATCH] swscale: add NV16 input/output

2022-08-02 Thread Matthieu Bouron
On Thu, Jul 14, 2022 at 8:10 PM Michael Niedermayer 
wrote:

> On Fri, Jul 01, 2022 at 10:08:14AM +0200, Matthieu Bouron wrote:
> > On Sat, Jun 11, 2022 at 5:35 PM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > On Fri, Jun 10, 2022 at 04:11:10PM +0200, Matthieu Bouron wrote:
> > > > On Thu, Jun 2, 2022 at 9:13 PM Michael Niedermayer <
> > > mich...@niedermayer.cc>
> > > > wrote:
> > > >
> > > > > On Wed, Jun 01, 2022 at 10:33:37PM +0200, Matthieu Bouron wrote:
> > > > > > ---
> > > > > >  libswscale/input.c   | 1 +
> > > > > >  libswscale/utils.c   | 1 +
> > > > > >  libswscale/version.h | 2 +-
> > > > > >  tests/ref/fate/filter-pixdesc-nv16   | 1 +
> > > > > >  tests/ref/fate/filter-pixfmts-copy   | 1 +
> > > > > >  tests/ref/fate/filter-pixfmts-crop   | 1 +
> > > > > >  tests/ref/fate/filter-pixfmts-field  | 1 +
> > > > > >  tests/ref/fate/filter-pixfmts-fieldorder | 1 +
> > > > > >  tests/ref/fate/filter-pixfmts-hflip  | 1 +
> > > > > >  tests/ref/fate/filter-pixfmts-il | 1 +
> > > > > >  tests/ref/fate/filter-pixfmts-null   | 1 +
> > > > > >  tests/ref/fate/filter-pixfmts-pad| 1 +
> > > > > >  tests/ref/fate/filter-pixfmts-scale  | 1 +
> > > > > >  tests/ref/fate/filter-pixfmts-vflip  | 1 +
> > > > > >  14 files changed, 14 insertions(+), 1 deletion(-)
> > > > > >  create mode 100644 tests/ref/fate/filter-pixdesc-nv16
> > > > >
> > > > >
> > > > Sorry for the late reply
> > > >
> > > >
> > > > > has this been tested ? (various scaled and non scaled) variants ?
> > > > >
> > > >
> > > > I only tested the non scaled variant using the command line doing
> > > multiple
> > > > round trips to/from nv16.
> > > > Is there a particular test procedure to validate every variants ?
> > >
> > > you can test manually or use something like
> > > libswscale/tests/swscale.c
> > >
> >
> > I manually tested without any issue: il, field, fieldorder, copy, crop,
> > hflip, null, pad, scale and vflip.
>
> if that included up & down scaling while changing format then it should be
> ok
>

It included up and down scaling.

[...]
___
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] swscale: add NV16 input/output

2022-07-12 Thread Matthieu Bouron
Le ven. 1 juil. 2022, 10:08, Matthieu Bouron  a
écrit :

> On Sat, Jun 11, 2022 at 5:35 PM Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Fri, Jun 10, 2022 at 04:11:10PM +0200, Matthieu Bouron wrote:
>> > On Thu, Jun 2, 2022 at 9:13 PM Michael Niedermayer <
>> mich...@niedermayer.cc>
>> > wrote:
>> >
>> > > On Wed, Jun 01, 2022 at 10:33:37PM +0200, Matthieu Bouron wrote:
>> > > > ---
>> > > >  libswscale/input.c   | 1 +
>> > > >  libswscale/utils.c   | 1 +
>> > > >  libswscale/version.h | 2 +-
>> > > >  tests/ref/fate/filter-pixdesc-nv16   | 1 +
>> > > >  tests/ref/fate/filter-pixfmts-copy   | 1 +
>> > > >  tests/ref/fate/filter-pixfmts-crop   | 1 +
>> > > >  tests/ref/fate/filter-pixfmts-field  | 1 +
>> > > >  tests/ref/fate/filter-pixfmts-fieldorder | 1 +
>> > > >  tests/ref/fate/filter-pixfmts-hflip  | 1 +
>> > > >  tests/ref/fate/filter-pixfmts-il | 1 +
>> > > >  tests/ref/fate/filter-pixfmts-null   | 1 +
>> > > >  tests/ref/fate/filter-pixfmts-pad| 1 +
>> > > >  tests/ref/fate/filter-pixfmts-scale  | 1 +
>> > > >  tests/ref/fate/filter-pixfmts-vflip  | 1 +
>> > > >  14 files changed, 14 insertions(+), 1 deletion(-)
>> > > >  create mode 100644 tests/ref/fate/filter-pixdesc-nv16
>> > >
>> > >
>> > Sorry for the late reply
>> >
>> >
>> > > has this been tested ? (various scaled and non scaled) variants ?
>> > >
>> >
>> > I only tested the non scaled variant using the command line doing
>> multiple
>> > round trips to/from nv16.
>> > Is there a particular test procedure to validate every variants ?
>>
>> you can test manually or use something like
>> libswscale/tests/swscale.c
>>
>
> I manually tested without any issue: il, field, fieldorder, copy, crop,
> hflip, null, pad, scale and vflip.
>

Ping.
___
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] swscale: add NV16 input/output

2022-07-01 Thread Matthieu Bouron
On Sat, Jun 11, 2022 at 5:35 PM Michael Niedermayer 
wrote:

> On Fri, Jun 10, 2022 at 04:11:10PM +0200, Matthieu Bouron wrote:
> > On Thu, Jun 2, 2022 at 9:13 PM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > On Wed, Jun 01, 2022 at 10:33:37PM +0200, Matthieu Bouron wrote:
> > > > ---
> > > >  libswscale/input.c   | 1 +
> > > >  libswscale/utils.c   | 1 +
> > > >  libswscale/version.h | 2 +-
> > > >  tests/ref/fate/filter-pixdesc-nv16   | 1 +
> > > >  tests/ref/fate/filter-pixfmts-copy   | 1 +
> > > >  tests/ref/fate/filter-pixfmts-crop   | 1 +
> > > >  tests/ref/fate/filter-pixfmts-field  | 1 +
> > > >  tests/ref/fate/filter-pixfmts-fieldorder | 1 +
> > > >  tests/ref/fate/filter-pixfmts-hflip  | 1 +
> > > >  tests/ref/fate/filter-pixfmts-il | 1 +
> > > >  tests/ref/fate/filter-pixfmts-null   | 1 +
> > > >  tests/ref/fate/filter-pixfmts-pad| 1 +
> > > >  tests/ref/fate/filter-pixfmts-scale  | 1 +
> > > >  tests/ref/fate/filter-pixfmts-vflip  | 1 +
> > > >  14 files changed, 14 insertions(+), 1 deletion(-)
> > > >  create mode 100644 tests/ref/fate/filter-pixdesc-nv16
> > >
> > >
> > Sorry for the late reply
> >
> >
> > > has this been tested ? (various scaled and non scaled) variants ?
> > >
> >
> > I only tested the non scaled variant using the command line doing
> multiple
> > round trips to/from nv16.
> > Is there a particular test procedure to validate every variants ?
>
> you can test manually or use something like
> libswscale/tests/swscale.c
>

I manually tested without any issue: il, field, fieldorder, copy, crop,
hflip, null, pad, scale and vflip.
___
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] swscale: add NV16 input/output

2022-06-10 Thread Matthieu Bouron
On Thu, Jun 2, 2022 at 9:13 PM Michael Niedermayer 
wrote:

> On Wed, Jun 01, 2022 at 10:33:37PM +0200, Matthieu Bouron wrote:
> > ---
> >  libswscale/input.c   | 1 +
> >  libswscale/utils.c   | 1 +
> >  libswscale/version.h | 2 +-
> >  tests/ref/fate/filter-pixdesc-nv16   | 1 +
> >  tests/ref/fate/filter-pixfmts-copy   | 1 +
> >  tests/ref/fate/filter-pixfmts-crop   | 1 +
> >  tests/ref/fate/filter-pixfmts-field  | 1 +
> >  tests/ref/fate/filter-pixfmts-fieldorder | 1 +
> >  tests/ref/fate/filter-pixfmts-hflip  | 1 +
> >  tests/ref/fate/filter-pixfmts-il | 1 +
> >  tests/ref/fate/filter-pixfmts-null   | 1 +
> >  tests/ref/fate/filter-pixfmts-pad| 1 +
> >  tests/ref/fate/filter-pixfmts-scale  | 1 +
> >  tests/ref/fate/filter-pixfmts-vflip  | 1 +
> >  14 files changed, 14 insertions(+), 1 deletion(-)
> >  create mode 100644 tests/ref/fate/filter-pixdesc-nv16
>
>
Sorry for the late reply


> has this been tested ? (various scaled and non scaled) variants ?
>

I only tested the non scaled variant using the command line doing multiple
round trips to/from nv16.
Is there a particular test procedure to validate every variants ?

[...]
___
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] swscale: add NV16 input/output

2022-06-01 Thread Matthieu Bouron
---
 libswscale/input.c   | 1 +
 libswscale/utils.c   | 1 +
 libswscale/version.h | 2 +-
 tests/ref/fate/filter-pixdesc-nv16   | 1 +
 tests/ref/fate/filter-pixfmts-copy   | 1 +
 tests/ref/fate/filter-pixfmts-crop   | 1 +
 tests/ref/fate/filter-pixfmts-field  | 1 +
 tests/ref/fate/filter-pixfmts-fieldorder | 1 +
 tests/ref/fate/filter-pixfmts-hflip  | 1 +
 tests/ref/fate/filter-pixfmts-il | 1 +
 tests/ref/fate/filter-pixfmts-null   | 1 +
 tests/ref/fate/filter-pixfmts-pad| 1 +
 tests/ref/fate/filter-pixfmts-scale  | 1 +
 tests/ref/fate/filter-pixfmts-vflip  | 1 +
 14 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 tests/ref/fate/filter-pixdesc-nv16

diff --git a/libswscale/input.c b/libswscale/input.c
index fe0c27d743..750367b28b 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -1101,6 +1101,7 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
 c->chrToYV12 = uyvyToUV_c;
 break;
 case AV_PIX_FMT_NV12:
+case AV_PIX_FMT_NV16:
 case AV_PIX_FMT_NV24:
 c->chrToYV12 = nv12ToUV_c;
 break;
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 105781c4f4..8298ae8e10 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -257,6 +257,7 @@ static const FormatEntry format_entries[] = {
 [AV_PIX_FMT_P216LE]  = { 1, 1 },
 [AV_PIX_FMT_P416BE]  = { 1, 1 },
 [AV_PIX_FMT_P416LE]  = { 1, 1 },
+[AV_PIX_FMT_NV16]= { 1, 1 },
 };
 
 int ff_shuffle_filter_coefficients(SwsContext *c, int *filterPos,
diff --git a/libswscale/version.h b/libswscale/version.h
index f573bef6fc..0fa41f77d2 100644
--- a/libswscale/version.h
+++ b/libswscale/version.h
@@ -29,7 +29,7 @@
 #include "version_major.h"
 
 #define LIBSWSCALE_VERSION_MINOR   6
-#define LIBSWSCALE_VERSION_MICRO 100
+#define LIBSWSCALE_VERSION_MICRO 101
 
 #define LIBSWSCALE_VERSION_INT  AV_VERSION_INT(LIBSWSCALE_VERSION_MAJOR, \
LIBSWSCALE_VERSION_MINOR, \
diff --git a/tests/ref/fate/filter-pixdesc-nv16 
b/tests/ref/fate/filter-pixdesc-nv16
new file mode 100644
index 00..4c4587c833
--- /dev/null
+++ b/tests/ref/fate/filter-pixdesc-nv16
@@ -0,0 +1 @@
+pixdesc-nv16cbbc5d904b8eebad3705a325c3ec5734
diff --git a/tests/ref/fate/filter-pixfmts-copy 
b/tests/ref/fate/filter-pixfmts-copy
index f06fa1574e..3cd0002e4e 100644
--- a/tests/ref/fate/filter-pixfmts-copy
+++ b/tests/ref/fate/filter-pixfmts-copy
@@ -56,6 +56,7 @@ grayf32le   fb6ea85bfbc8cd21c51fc0e110197294
 monob   8b04f859fee6a0be856be184acd7a0b5
 monow   54d16d2c01abfd72ecdb5e51e283937c
 nv128e24feb2c544dc26a20047a71e4c27aa
+nv1622b1916c0694c4e2979bab8eb71f3d6b
 nv21335d85c9af6110f26ae9e187a82ed2cf
 nv24f30fc8d0ac40af69e119ea919a314572
 nv4229a212f70f8780fe0eb99abcae81894d
diff --git a/tests/ref/fate/filter-pixfmts-crop 
b/tests/ref/fate/filter-pixfmts-crop
index 8b26ab9c53..1a0f0c79ed 100644
--- a/tests/ref/fate/filter-pixfmts-crop
+++ b/tests/ref/fate/filter-pixfmts-crop
@@ -54,6 +54,7 @@ gray9le 4d1932d4968a248584f5e39c25f1dd43
 grayf32be   cf40ec06a8abe54852b7f85a00549eec
 grayf32le   b672526c9da9c8959ab881f242f6890a
 nv1292cda427f794374731ec0321ee00caac
+nv163264b16aaae554c21f052102b491c13b
 nv211bcfc197f4fb95de85ba58182d8d2f69
 nv24514c8f12082f0737e558778cbe7de258
 nv42ece9baae1c5de579dac2c66a89e08ef3
diff --git a/tests/ref/fate/filter-pixfmts-field 
b/tests/ref/fate/filter-pixfmts-field
index c4838d1446..27a74eaef3 100644
--- a/tests/ref/fate/filter-pixfmts-field
+++ b/tests/ref/fate/filter-pixfmts-field
@@ -56,6 +56,7 @@ grayf32le   6b856bdbf2a2bfcd2bc7d50f109daaf0
 monob   2129cc72a484d7e10a44de9117aa9f80
 monow   03d783611d265cae78293f88ea126ea1
 nv1216f7a46708ef25ebd0b72e47920cc11e
+nv1634f36b03f5fccf4eac147b26bbc0a5e5
 nv217294574037cc7f9373ef5695d8ebe809
 nv243b100fb527b64ee2b2d7120da573faf5
 nv421841ce853152d86b27c130f319ea0db2
diff --git a/tests/ref/fate/filter-pixfmts-fieldorder 
b/tests/ref/fate/filter-pixfmts-fieldorder
index 32c06bae4c..ab080d1a37 100644
--- a/tests/ref/fate/filter-pixfmts-fieldorder
+++ b/tests/ref/fate/filter-pixfmts-fieldorder
@@ -53,6 +53,7 @@ gray9be ec877f5bcf0ea275a6f36c12cc9adf11
 gray9le fba944fde7923d5089f4f52d12988b9e
 grayf32be   1aa7960131f880c54fe3c77f13448674
 grayf32le   4029ac9d197f255794c1b9e416520fc7
+nv16085deb984ab986eb5cc961fe265e30c0
 nv244fdbef26042c77f012df114e666efdb2
 nv4259608290fece913e6b7d61edf581a529
 p210be  ca2ce2c25db43dcd14729b2a72a7c604
diff 

Re: [FFmpeg-devel] [PATCH] libavformat/tls_libtls: handle TLS_WANT_{POLLIN, POLLOUT} in read/write functions

2022-05-30 Thread Matthieu Bouron
On Mon, May 23, 2022 at 12:44:33PM +0200, Matthieu Bouron wrote:
> According to the tls documentation: tls_read() and tls_write() can
> return TLS_WANT_POLLIN and TLS_WANT_POLLOUT which indicates that the
> same operation must be repeated immediately.
> 
> This commit prevents the libtls backend from failing when libtls returns
> TLS_WANT_POLLIN or TLS_WANT_POLLOUT with the following error:
> 
> [tls @ 0x7f6e20005a00] (null)
> ---
>  libavformat/tls_libtls.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavformat/tls_libtls.c b/libavformat/tls_libtls.c
> index 911c8094b0..22858d4867 100644
> --- a/libavformat/tls_libtls.c
> +++ b/libavformat/tls_libtls.c
> @@ -158,6 +158,8 @@ static int ff_tls_read(URLContext *h, uint8_t *buf, int 
> size)
>  return ret;
>  else if (ret == 0)
>  return AVERROR_EOF;
> +else if (ret == TLS_WANT_POLLIN || ret == TLS_WANT_POLLOUT)
> +return AVERROR(EAGAIN);
>  av_log(h, AV_LOG_ERROR, "%s\n", tls_error(p->ctx));
>  return AVERROR(EIO);
>  }
> @@ -171,6 +173,8 @@ static int ff_tls_write(URLContext *h, const uint8_t 
> *buf, int size)
>  return ret;
>  else if (ret == 0)
>  return AVERROR_EOF;
> +else if (ret == TLS_WANT_POLLIN || ret == TLS_WANT_POLLOUT)
> +return AVERROR(EAGAIN);
>  av_log(h, AV_LOG_ERROR, "%s\n", tls_error(p->ctx));
>  return AVERROR(EIO);
>  }
> -- 

Ping.
___
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] libavformat/tls_libtls: handle TLS_WANT_{POLLIN, POLLOUT} in read/write functions

2022-05-23 Thread Matthieu Bouron
According to the tls documentation: tls_read() and tls_write() can
return TLS_WANT_POLLIN and TLS_WANT_POLLOUT which indicates that the
same operation must be repeated immediately.

This commit prevents the libtls backend from failing when libtls returns
TLS_WANT_POLLIN or TLS_WANT_POLLOUT with the following error:

[tls @ 0x7f6e20005a00] (null)
---
 libavformat/tls_libtls.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/tls_libtls.c b/libavformat/tls_libtls.c
index 911c8094b0..22858d4867 100644
--- a/libavformat/tls_libtls.c
+++ b/libavformat/tls_libtls.c
@@ -158,6 +158,8 @@ static int ff_tls_read(URLContext *h, uint8_t *buf, int 
size)
 return ret;
 else if (ret == 0)
 return AVERROR_EOF;
+else if (ret == TLS_WANT_POLLIN || ret == TLS_WANT_POLLOUT)
+return AVERROR(EAGAIN);
 av_log(h, AV_LOG_ERROR, "%s\n", tls_error(p->ctx));
 return AVERROR(EIO);
 }
@@ -171,6 +173,8 @@ static int ff_tls_write(URLContext *h, const uint8_t *buf, 
int size)
 return ret;
 else if (ret == 0)
 return AVERROR_EOF;
+else if (ret == TLS_WANT_POLLIN || ret == TLS_WANT_POLLOUT)
+return AVERROR(EAGAIN);
 av_log(h, AV_LOG_ERROR, "%s\n", tls_error(p->ctx));
 return AVERROR(EIO);
 }
-- 
2.36.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".


[FFmpeg-devel] [PATCH] avcodec/mediacodecdec_common: stop the codec before releasing it

2022-03-30 Thread Matthieu Bouron
Fixes the following warnings/errors on codec release:

E/BufferQueueProducer: 
[SurfaceTexture-0-31763-0](id:7c130001,api:3,p:31763,c:31763) detachBuffer: 
slot 0 is not owned by the producer (state = FREE)
E/BufferQueueProducer: 
[SurfaceTexture-0-31763-0](id:7c130001,api:3,p:31763,c:31763) detachBuffer: 
slot 1 is not owned by the producer (state = FREE)
E/BufferQueueProducer: 
[SurfaceTexture-0-31763-0](id:7c130001,api:3,p:31763,c:31763) detachBuffer: 
slot 2 is not owned by the producer (state = FREE)
[...]
---
 libavcodec/mediacodecdec_common.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index cb18aed401..d99881c11f 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -232,6 +232,7 @@ static void ff_mediacodec_dec_unref(MediaCodecDecContext *s)
 
 if (atomic_fetch_sub(>refcount, 1) == 1) {
 if (s->codec) {
+ff_AMediaCodec_stop(s->codec);
 ff_AMediaCodec_delete(s->codec);
 s->codec = NULL;
 }
-- 
2.35.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".


Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: fix DNxHD GC element_type

2021-12-14 Thread Matthieu Bouron
On Tue, Dec 14, 2021 at 04:27:43PM +0100, Nicolas Gaullier wrote:
> The values for the essence element type were updated in the spec
> from 0x05/0x06 (ST2019-4 2008) to 0x0C/0x0D (ST2019-4 2009).
> 
> Fixes ticket #6380.
> 
> Thanks-to: Philip de Nier 
> Thanks-to: Matthieu Bouron 
> 
> Signed-off-by: Nicolas Gaullier 
> ---
>  libavformat/mxfenc.c  | 9 -
>  tests/ref/lavf/mxf_opatom | 2 +-
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 512baa45d3..bae41a774d 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -32,6 +32,7 @@
>   * SMPTE 379M MXF Generic Container
>   * SMPTE 381M Mapping MPEG Streams into the MXF Generic Container
>   * SMPTE 422M Mapping JPEG 2000 Codestreams into the MXF Generic Container
> + * SMPTE ST2019-4 (2009 or later) Mapping VC-3 Coding Units into the MXF 
> Generic Container
>   * SMPTE RP210: SMPTE Metadata Dictionary
>   * SMPTE RP224: Registry of SMPTE Universal Labels
>   */
> @@ -182,7 +183,7 @@ static const MXFContainerEssenceEntry 
> mxf_essence_container_uls[] = {
>mxf_write_cdci_desc },
>  // DNxHD
>  { { 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00
>  },
> -  { 
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00
>  },
> +  { 
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x0C,0x00
>  },
>{ 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x01,0x00,0x00
>  },
>mxf_write_cdci_desc },
>  // JPEG2000
> @@ -2674,6 +2675,12 @@ static int mxf_init(AVFormatContext *s)
>  
>  memcpy(sc->track_essence_element_key, 
> mxf_essence_container_uls[sc->index].element_ul, 15);
>  sc->track_essence_element_key[15] = present[sc->index];
> +if (s->oformat == _mxf_opatom_muxer && st->codecpar->codec_id == 
> AV_CODEC_ID_DNXHD) {
> +// clip-wrapping requires 0x0D per ST2019-4:2009 or 0x06 per 
> previous version ST2019-4:2008
> +// we choose to use 0x06 instead 0x0D to be compatible with AVID 
> systems
> +// and produce mxf files with the most relevant flavour for 
> opatom
> +sc->track_essence_element_key[14] = 0x06;
> +}
>  PRINT_KEY(s, "track essence element key", 
> sc->track_essence_element_key);
>  
>  if (!present[sc->index])
> diff --git a/tests/ref/lavf/mxf_opatom b/tests/ref/lavf/mxf_opatom
> index b818f26c36..e34cf2559e 100644
> --- a/tests/ref/lavf/mxf_opatom
> +++ b/tests/ref/lavf/mxf_opatom
> @@ -1,3 +1,3 @@
> -e558e50a94d88762e07ab8149aced7b9 *tests/data/lavf/lavf.mxf_opatom
> +aab6397829bd90f0c77a3f9fde53bb9c *tests/data/lavf/lavf.mxf_opatom
>  4717625 tests/data/lavf/lavf.mxf_opatom
>  tests/data/lavf/lavf.mxf_opatom CRC=0xf55aa22a
> -- 
> 2.34.0

LGTM, thanks.

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


Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxfenc: fix DNxHD GC container_ul

2021-12-14 Thread Matthieu Bouron
On Tue, Dec 14, 2021 at 04:27:42PM +0100, Nicolas Gaullier wrote:
> Signed-off-by: Nicolas Gaullier 
> ---
>  libavformat/mxfenc.c  | 2 +-
>  tests/ref/lavf/mxf_opatom | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index fcd9afda2a..512baa45d3 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -181,7 +181,7 @@ static const MXFContainerEssenceEntry 
> mxf_essence_container_uls[] = {
>{ 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x00,0x00,0x00
>  },
>mxf_write_cdci_desc },
>  // DNxHD
> -{ { 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00
>  },
> +{ { 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00
>  },
>{ 
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00
>  },
>{ 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x01,0x00,0x00
>  },
>mxf_write_cdci_desc },
> diff --git a/tests/ref/lavf/mxf_opatom b/tests/ref/lavf/mxf_opatom
> index 61e70b..b818f26c36 100644
> --- a/tests/ref/lavf/mxf_opatom
> +++ b/tests/ref/lavf/mxf_opatom
> @@ -1,3 +1,3 @@
> -5d235c127ace64b1f4fe6c79a7ca8be6 *tests/data/lavf/lavf.mxf_opatom
> +e558e50a94d88762e07ab8149aced7b9 *tests/data/lavf/lavf.mxf_opatom
>  4717625 tests/data/lavf/lavf.mxf_opatom
>  tests/data/lavf/lavf.mxf_opatom CRC=0xf55aa22a
> -- 
> 2.34.0

LGTM, thanks

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


Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: fix DNxHD GC ULs

2021-12-14 Thread Matthieu Bouron
On Tue, Dec 14, 2021 at 10:41:27AM +0100, Matthieu Bouron wrote:
> On Tue, Nov 30, 2021 at 10:22:20AM +0100, Nicolas Gaullier wrote:
> > Fix GC container ul.
> > Fix GC element type both for the generic case and for OPAtom.
> > 
> > Thanks to Philip de Nier 
> > for checking the values, especially for OPAtom.
> > ---
> >  libavformat/mxfenc.c  | 8 ++--
> >  tests/ref/lavf/mxf_opatom | 2 +-
> >  2 files changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > index fcd9afda2a..38de3d1ab5 100644
> > --- a/libavformat/mxfenc.c
> > +++ b/libavformat/mxfenc.c
> > @@ -32,6 +32,7 @@
> >   * SMPTE 379M MXF Generic Container
> >   * SMPTE 381M Mapping MPEG Streams into the MXF Generic Container
> >   * SMPTE 422M Mapping JPEG 2000 Codestreams into the MXF Generic Container
> > + * SMPTE ST2019-4 Mapping VC-3 Coding Units into the MXF Generic Container
> >   * SMPTE RP210: SMPTE Metadata Dictionary
> >   * SMPTE RP224: Registry of SMPTE Universal Labels
> >   */
> > @@ -181,8 +182,8 @@ static const MXFContainerEssenceEntry 
> > mxf_essence_container_uls[] = {
> >{ 
> > 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x00,0x00,0x00
> >  },
> >mxf_write_cdci_desc },
> >  // DNxHD
> > -{ { 
> > 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00
> >  },
> > -  { 
> > 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00
> >  },
> > +{ { 
> > 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00
> >  },
> 
> Can the chunk fixing the container UL be put in a separate commit (I just
> checked the spec and it is fine) ?
> 
> > +  { 
> > 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x0C,0x00
> >  },
> 
> It only have access to ST2019-4 (2008) and it mentions two possible value
> for the essence element type:
> - 0x05 frame wrapped picture element
> - 0x06 clip wrapped picture element
> 
> Is 0x0C introduced in a later revision of ST2019 ?

So after an offline discussion with Nicolas and Philip, it turns out, the
values for the essence element type were updated from 0x05/0x06 to
0x0C/0x0D in the 2009 revision of ST2019-4 (and they are still current as
of the latest revision of the spec).

So I'm fine with the change from 0x05 to 0x0C and the AVID hack (using
0x06 instead of 0x0D) as it is what BMX is doing. Can you please add a
comment regarding the AVID hack and why we are not using 0x0D ?

[...]

Thanks,
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".


Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec: set codec profile and level from extradata for H264+HEVC

2021-12-14 Thread Matthieu Bouron
On Mon, Dec 13, 2021 at 09:56:05PM +0100, sfan5 wrote:
> This value is later passed to MediaCodec and checked at decoder init.
> Notably decoding of 10-bit streams before this commit would "work" without
> returning errors but only return garbage output (on most Android devices).

> From 304d1bd55e72212c1e907922547d40da240b Mon Sep 17 00:00:00 2001
> From: sfan5 
> Date: Mon, 13 Dec 2021 21:01:00 +0100
> Subject: [PATCH] lavc/mediacodecdec: set codec profile and level from
>  extradata for H264+HEVC
> 
> This value is later passed to MediaCodec and checked at decoder init.
> Notably decoding of 10-bit streams before this commit would "work" without
> returning errors but only return garbage output (on most Android devices).
> ---
>  libavcodec/mediacodecdec.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index 1cebb3d76d..04d5026e68 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -155,6 +155,9 @@ static int h264_set_extradata(AVCodecContext *avctx, 
> FFAMediaFormat *format)
>  uint8_t *data = NULL;
>  int data_size = 0;
>  
> +avctx->profile = ff_h264_get_profile(sps);
> +avctx->level = sps->level_idc;
> +
>  if ((ret = h2645_ps_to_nalu(sps->data, sps->data_size, , 
> _size)) < 0) {
>  goto done;
>  }
> @@ -236,6 +239,9 @@ static int hevc_set_extradata(AVCodecContext *avctx, 
> FFAMediaFormat *format)
>  uint8_t *data;
>  int data_size;
>  
> +avctx->profile = sps->ptl.general_ptl.profile_idc;
> +avctx->level   = sps->ptl.general_ptl.level_idc;
> +
>  if ((ret = h2645_ps_to_nalu(vps->data, vps->data_size, _data, 
> _data_size)) < 0 ||
>  (ret = h2645_ps_to_nalu(sps->data, sps->data_size, _data, 
> _data_size)) < 0 ||
>  (ret = h2645_ps_to_nalu(pps->data, pps->data_size, _data, 
> _data_size)) < 0) {
> -- 
> 2.34.1
> 

Tested locally without issues. LGTM, thanks.

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


Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: fix DNxHD GC ULs

2021-12-14 Thread Matthieu Bouron
On Tue, Nov 30, 2021 at 10:22:20AM +0100, Nicolas Gaullier wrote:
> Fix GC container ul.
> Fix GC element type both for the generic case and for OPAtom.
> 
> Thanks to Philip de Nier 
> for checking the values, especially for OPAtom.
> ---
>  libavformat/mxfenc.c  | 8 ++--
>  tests/ref/lavf/mxf_opatom | 2 +-
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index fcd9afda2a..38de3d1ab5 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -32,6 +32,7 @@
>   * SMPTE 379M MXF Generic Container
>   * SMPTE 381M Mapping MPEG Streams into the MXF Generic Container
>   * SMPTE 422M Mapping JPEG 2000 Codestreams into the MXF Generic Container
> + * SMPTE ST2019-4 Mapping VC-3 Coding Units into the MXF Generic Container
>   * SMPTE RP210: SMPTE Metadata Dictionary
>   * SMPTE RP224: Registry of SMPTE Universal Labels
>   */
> @@ -181,8 +182,8 @@ static const MXFContainerEssenceEntry 
> mxf_essence_container_uls[] = {
>{ 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x00,0x00,0x00
>  },
>mxf_write_cdci_desc },
>  // DNxHD
> -{ { 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00
>  },
> -  { 
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00
>  },
> +{ { 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00
>  },

Can the chunk fixing the container UL be put in a separate commit (I just
checked the spec and it is fine) ?

> +  { 
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x0C,0x00
>  },

It only have access to ST2019-4 (2008) and it mentions two possible value
for the essence element type:
- 0x05 frame wrapped picture element
- 0x06 clip wrapped picture element

Is 0x0C introduced in a later revision of ST2019 ?

>{ 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x01,0x00,0x00
>  },
>mxf_write_cdci_desc },
>  // JPEG2000
> @@ -2674,6 +2675,9 @@ static int mxf_init(AVFormatContext *s)
>  
>  memcpy(sc->track_essence_element_key, 
> mxf_essence_container_uls[sc->index].element_ul, 15);
>  sc->track_essence_element_key[15] = present[sc->index];
> +if (s->oformat == _mxf_opatom_muxer && st->codecpar->codec_id == 
> AV_CODEC_ID_DNXHD) {
> +sc->track_essence_element_key[14] = 0x06;
> +}
>  PRINT_KEY(s, "track essence element key", 
> sc->track_essence_element_key);
>  
>  if (!present[sc->index])
> diff --git a/tests/ref/lavf/mxf_opatom b/tests/ref/lavf/mxf_opatom
> index 61e70b..e34cf2559e 100644
> --- a/tests/ref/lavf/mxf_opatom
> +++ b/tests/ref/lavf/mxf_opatom
> @@ -1,3 +1,3 @@
> -5d235c127ace64b1f4fe6c79a7ca8be6 *tests/data/lavf/lavf.mxf_opatom
> +aab6397829bd90f0c77a3f9fde53bb9c *tests/data/lavf/lavf.mxf_opatom
>  4717625 tests/data/lavf/lavf.mxf_opatom
>  tests/data/lavf/lavf.mxf_opatom CRC=0xf55aa22a
> -- 
> 2.34.0
> 
> ___
> 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".


Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mediacodec_wrapper: use MediaCodecInfo.isSoftwareOnly() when available

2021-03-10 Thread Matthieu Bouron
On Mon, Mar 08, 2021 at 10:12:38AM +0100, Matthieu Bouron wrote:
> On Wed, Feb 17, 2021 at 04:51:09PM +0100, sfan5 wrote:
> > 
> 
> > From 22ebde779f61fb030633a881ef320264ea446b6b Mon Sep 17 00:00:00 2001
> > From: sfan5 
> > Date: Thu, 11 Feb 2021 20:48:54 +0100
> > Subject: [PATCH 2/2] avcodec/mediacodec_wrapper: use
> >  MediaCodecInfo.isSoftwareOnly() when available
> > 
> > Added in Android 10 it provides a reliable way of filtering out
> > software decoders, unlike existing string-based checks.
> > ---
> >  libavcodec/mediacodec_wrapper.c | 13 +
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/libavcodec/mediacodec_wrapper.c 
> > b/libavcodec/mediacodec_wrapper.c
> > index f1945bcfc0..c829941d6b 100644
> > --- a/libavcodec/mediacodec_wrapper.c
> > +++ b/libavcodec/mediacodec_wrapper.c
> > @@ -45,6 +45,7 @@ struct JNIAMediaCodecListFields {
> >  jmethodID get_codec_capabilities_id;
> >  jmethodID get_supported_types_id;
> >  jmethodID is_encoder_id;
> > +jmethodID is_software_only_id;
> >  
> >  jclass codec_capabilities_class;
> >  jfieldID color_formats_id;
> > @@ -81,6 +82,7 @@ static const struct FFJniField 
> > jni_amediacodeclist_mapping[] = {
> >  { "android/media/MediaCodecInfo", "getCapabilitiesForType", 
> > "(Ljava/lang/String;)Landroid/media/MediaCodecInfo$CodecCapabilities;", 
> > FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, 
> > get_codec_capabilities_id), 1 },
> >  { "android/media/MediaCodecInfo", "getSupportedTypes", 
> > "()[Ljava/lang/String;", FF_JNI_METHOD, offsetof(struct 
> > JNIAMediaCodecListFields, get_supported_types_id), 1 },
> >  { "android/media/MediaCodecInfo", "isEncoder", "()Z", 
> > FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, is_encoder_id), 1 
> > },
> > +{ "android/media/MediaCodecInfo", "isSoftwareOnly", "()Z", 
> > FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, 
> > is_software_only_id), 0 },
> >  
> >  { "android/media/MediaCodecInfo$CodecCapabilities", NULL, NULL, 
> > FF_JNI_CLASS, offsetof(struct JNIAMediaCodecListFields, 
> > codec_capabilities_class), 1 },
> >  { "android/media/MediaCodecInfo$CodecCapabilities", 
> > "colorFormats", "[I", FF_JNI_FIELD, offsetof(struct 
> > JNIAMediaCodecListFields, color_formats_id), 1 },
> > @@ -441,6 +443,17 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
> > *mime, int profile, int e
> >  goto done_with_info;
> >  }
> >  
> > +if (jfields.is_software_only_id) {
> > +int is_software_only = (*env)->CallBooleanMethod(env, info, 
> > jfields.is_software_only_id);
> > +if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> > +goto done;
> > +}
> > +
> > +if (is_software_only) {
> > +goto done_with_info;
> > +}
> > +}
> > +
> >  codec_name = (*env)->CallObjectMethod(env, info, 
> > jfields.get_name_id);
> >  if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> >  goto done;
> > -- 
> > 2.30.1
> > 
> 
> LGTM, I'll push the patch in two days if there is no objection.
> Thanks,

Applied as a7425f712aeed6e18204a68810529895fdbdb1be.
Thanks.

-- 
Matthieu B.
___
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 1/2] avcodec/mediacodec_wrapper: clean up ff_AMediaCodecList_getCodecNameByType a bit

2021-03-10 Thread Matthieu Bouron
On Mon, Mar 08, 2021 at 10:11:58AM +0100, Matthieu Bouron wrote:
> On Wed, Feb 17, 2021 at 04:50:00PM +0100, sfan5 wrote:
> > Hi,
> > 
> > while looking into mediacodec for unrelated reasons I saw some room for
> > improvement.
> > 
> > Therefore, here's a series with two small patches.
> > 
> 
> > From cadd2b2d4a5ffbb4dcc34faf2d3e139e1d4d608b Mon Sep 17 00:00:00 2001
> > From: sfan5 
> > Date: Thu, 11 Feb 2021 19:23:26 +0100
> > Subject: [PATCH 1/2] avcodec/mediacodec_wrapper: clean up
> >  ff_AMediaCodecList_getCodecNameByType a bit
> > 
> > We can skip software decoders before even looking at the mime types.
> > ---
> >  libavcodec/mediacodec_wrapper.c | 113 
> >  1 file changed, 57 insertions(+), 56 deletions(-)
> > 
> > diff --git a/libavcodec/mediacodec_wrapper.c 
> > b/libavcodec/mediacodec_wrapper.c
> > index 79abc8b6aa..f1945bcfc0 100644
> > --- a/libavcodec/mediacodec_wrapper.c
> > +++ b/libavcodec/mediacodec_wrapper.c
> > @@ -441,6 +441,30 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
> > *mime, int profile, int e
> >  goto done_with_info;
> >  }
> >  
> > +codec_name = (*env)->CallObjectMethod(env, info, 
> > jfields.get_name_id);
> > +if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> > +goto done;
> > +}
> > +
> > +name = ff_jni_jstring_to_utf_chars(env, codec_name, log_ctx);
> > +if (!name) {
> > +goto done;
> > +}
> > +
> > +if (codec_name) {
> > +(*env)->DeleteLocalRef(env, codec_name);
> > +codec_name = NULL;
> > +}
> > +
> > +/* Skip software decoders */
> > +if (
> > +strstr(name, "OMX.google") ||
> > +strstr(name, "OMX.ffmpeg") ||
> > +(strstr(name, "OMX.SEC") && strstr(name, ".sw.")) ||
> > +!strcmp(name, "OMX.qcom.video.decoder.hevcswvdec")) {
> > +goto done_with_info;
> > +}
> > +
> >  type_count = (*env)->GetArrayLength(env, types);
> >  for (j = 0; j < type_count; j++) {
> >  int k;
> > @@ -456,74 +480,51 @@ char *ff_AMediaCodecList_getCodecNameByType(const 
> > char *mime, int profile, int e
> >  goto done;
> >  }
> >  
> > -if (!av_strcasecmp(supported_type, mime)) {
> > -codec_name = (*env)->CallObjectMethod(env, info, 
> > jfields.get_name_id);
> > -if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> > -goto done;
> > -}
> > +if (av_strcasecmp(supported_type, mime)) {
> > +goto done_with_type;
> > +}
> >  
> > -name = ff_jni_jstring_to_utf_chars(env, codec_name, 
> > log_ctx);
> > -if (!name) {
> > -goto done;
> > -}
> > +capabilities = (*env)->CallObjectMethod(env, info, 
> > jfields.get_codec_capabilities_id, type);
> > +if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> > +goto done;
> > +}
> >  
> > -if (codec_name) {
> > -(*env)->DeleteLocalRef(env, codec_name);
> > -codec_name = NULL;
> > -}
> > +profile_levels = (*env)->GetObjectField(env, capabilities, 
> > jfields.profile_levels_id);
> > +if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> > +goto done;
> > +}
> >  
> > -/* Skip software decoders */
> > -if (
> > -strstr(name, "OMX.google") ||
> > -strstr(name, "OMX.ffmpeg") ||
> > -(strstr(name, "OMX.SEC") && strstr(name, ".sw.")) ||
> > -!strcmp(name, "OMX.qcom.video.decoder.hevcswvdec")) {
> > -av_freep();
> > -goto done_with_type;
> > +profile_count = (*env)->GetArrayLength(env, profile_levels);
> > +if (!profile_count) {
> > +found_codec = 1;
> > +}
> > +for (k = 0; k 

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mediacodec_wrapper: clean up ff_AMediaCodecList_getCodecNameByType a bit

2021-03-08 Thread Matthieu Bouron
On Wed, Feb 17, 2021 at 04:50:00PM +0100, sfan5 wrote:
> Hi,
> 
> while looking into mediacodec for unrelated reasons I saw some room for
> improvement.
> 
> Therefore, here's a series with two small patches.
> 

> From cadd2b2d4a5ffbb4dcc34faf2d3e139e1d4d608b Mon Sep 17 00:00:00 2001
> From: sfan5 
> Date: Thu, 11 Feb 2021 19:23:26 +0100
> Subject: [PATCH 1/2] avcodec/mediacodec_wrapper: clean up
>  ff_AMediaCodecList_getCodecNameByType a bit
> 
> We can skip software decoders before even looking at the mime types.
> ---
>  libavcodec/mediacodec_wrapper.c | 113 
>  1 file changed, 57 insertions(+), 56 deletions(-)
> 
> diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
> index 79abc8b6aa..f1945bcfc0 100644
> --- a/libavcodec/mediacodec_wrapper.c
> +++ b/libavcodec/mediacodec_wrapper.c
> @@ -441,6 +441,30 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
> *mime, int profile, int e
>  goto done_with_info;
>  }
>  
> +codec_name = (*env)->CallObjectMethod(env, info, 
> jfields.get_name_id);
> +if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> +goto done;
> +}
> +
> +name = ff_jni_jstring_to_utf_chars(env, codec_name, log_ctx);
> +if (!name) {
> +goto done;
> +}
> +
> +if (codec_name) {
> +(*env)->DeleteLocalRef(env, codec_name);
> +codec_name = NULL;
> +}
> +
> +/* Skip software decoders */
> +if (
> +strstr(name, "OMX.google") ||
> +strstr(name, "OMX.ffmpeg") ||
> +(strstr(name, "OMX.SEC") && strstr(name, ".sw.")) ||
> +!strcmp(name, "OMX.qcom.video.decoder.hevcswvdec")) {
> +goto done_with_info;
> +}
> +
>  type_count = (*env)->GetArrayLength(env, types);
>  for (j = 0; j < type_count; j++) {
>  int k;
> @@ -456,74 +480,51 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
> *mime, int profile, int e
>  goto done;
>  }
>  
> -if (!av_strcasecmp(supported_type, mime)) {
> -codec_name = (*env)->CallObjectMethod(env, info, 
> jfields.get_name_id);
> -if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> -goto done;
> -}
> +if (av_strcasecmp(supported_type, mime)) {
> +goto done_with_type;
> +}
>  
> -name = ff_jni_jstring_to_utf_chars(env, codec_name, log_ctx);
> -if (!name) {
> -goto done;
> -}
> +capabilities = (*env)->CallObjectMethod(env, info, 
> jfields.get_codec_capabilities_id, type);
> +if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> +goto done;
> +}
>  
> -if (codec_name) {
> -(*env)->DeleteLocalRef(env, codec_name);
> -codec_name = NULL;
> -}
> +profile_levels = (*env)->GetObjectField(env, capabilities, 
> jfields.profile_levels_id);
> +if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> +goto done;
> +}
>  
> -/* Skip software decoders */
> -if (
> -strstr(name, "OMX.google") ||
> -strstr(name, "OMX.ffmpeg") ||
> -(strstr(name, "OMX.SEC") && strstr(name, ".sw.")) ||
> -!strcmp(name, "OMX.qcom.video.decoder.hevcswvdec")) {
> -av_freep();
> -goto done_with_type;
> +profile_count = (*env)->GetArrayLength(env, profile_levels);
> +if (!profile_count) {
> +found_codec = 1;
> +}
> +for (k = 0; k < profile_count; k++) {
> +int supported_profile = 0;
> +
> +if (profile < 0) {
> +found_codec = 1;
> +break;
>  }
>  
> -capabilities = (*env)->CallObjectMethod(env, info, 
> jfields.get_codec_capabilities_id, type);
> +profile_level = (*env)->GetObjectArrayElement(env, 
> profile_levels, k);
>  if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
>  goto done;
>  }
>  
> -profile_levels = (*env)->GetObjectField(env, capabilities, 
> jfields.profile_levels_id);
> +supported_profile = (*env)->GetIntField(env, profile_level, 
> jfields.profile_id);
>  if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
>  goto done;
>  }
>  
> -profile_count = (*env)->GetArrayLength(env, profile_levels);
> -if (!profile_count) {
> -found_codec = 1;
> +found_codec = profile == supported_profile;

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mediacodec_wrapper: use MediaCodecInfo.isSoftwareOnly() when available

2021-03-08 Thread Matthieu Bouron
On Wed, Feb 17, 2021 at 04:51:09PM +0100, sfan5 wrote:
> 

> From 22ebde779f61fb030633a881ef320264ea446b6b Mon Sep 17 00:00:00 2001
> From: sfan5 
> Date: Thu, 11 Feb 2021 20:48:54 +0100
> Subject: [PATCH 2/2] avcodec/mediacodec_wrapper: use
>  MediaCodecInfo.isSoftwareOnly() when available
> 
> Added in Android 10 it provides a reliable way of filtering out
> software decoders, unlike existing string-based checks.
> ---
>  libavcodec/mediacodec_wrapper.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
> index f1945bcfc0..c829941d6b 100644
> --- a/libavcodec/mediacodec_wrapper.c
> +++ b/libavcodec/mediacodec_wrapper.c
> @@ -45,6 +45,7 @@ struct JNIAMediaCodecListFields {
>  jmethodID get_codec_capabilities_id;
>  jmethodID get_supported_types_id;
>  jmethodID is_encoder_id;
> +jmethodID is_software_only_id;
>  
>  jclass codec_capabilities_class;
>  jfieldID color_formats_id;
> @@ -81,6 +82,7 @@ static const struct FFJniField 
> jni_amediacodeclist_mapping[] = {
>  { "android/media/MediaCodecInfo", "getCapabilitiesForType", 
> "(Ljava/lang/String;)Landroid/media/MediaCodecInfo$CodecCapabilities;", 
> FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, 
> get_codec_capabilities_id), 1 },
>  { "android/media/MediaCodecInfo", "getSupportedTypes", 
> "()[Ljava/lang/String;", FF_JNI_METHOD, offsetof(struct 
> JNIAMediaCodecListFields, get_supported_types_id), 1 },
>  { "android/media/MediaCodecInfo", "isEncoder", "()Z", FF_JNI_METHOD, 
> offsetof(struct JNIAMediaCodecListFields, is_encoder_id), 1 },
> +{ "android/media/MediaCodecInfo", "isSoftwareOnly", "()Z", 
> FF_JNI_METHOD, offsetof(struct JNIAMediaCodecListFields, 
> is_software_only_id), 0 },
>  
>  { "android/media/MediaCodecInfo$CodecCapabilities", NULL, NULL, 
> FF_JNI_CLASS, offsetof(struct JNIAMediaCodecListFields, 
> codec_capabilities_class), 1 },
>  { "android/media/MediaCodecInfo$CodecCapabilities", "colorFormats", 
> "[I", FF_JNI_FIELD, offsetof(struct JNIAMediaCodecListFields, 
> color_formats_id), 1 },
> @@ -441,6 +443,17 @@ char *ff_AMediaCodecList_getCodecNameByType(const char 
> *mime, int profile, int e
>  goto done_with_info;
>  }
>  
> +if (jfields.is_software_only_id) {
> +int is_software_only = (*env)->CallBooleanMethod(env, info, 
> jfields.is_software_only_id);
> +if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
> +goto done;
> +}
> +
> +if (is_software_only) {
> +goto done_with_info;
> +}
> +}
> +
>  codec_name = (*env)->CallObjectMethod(env, info, 
> jfields.get_name_id);
>  if (ff_jni_exception_check(env, 1, log_ctx) < 0) {
>  goto done;
> -- 
> 2.30.1
> 

LGTM, I'll push the patch in two days if there is no objection.
Thanks,

-- 
Matthieu B.
___
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] avcodec/mediacodecdec: Do not abort when H264/HEVC extradata extraction fails

2021-02-12 Thread Matthieu Bouron
On Mon, Jan 25, 2021 at 06:38:36PM +0100, sfan5 wrote:
> Although rare, extradata can be present but empty and extraction will fail.
> However Android also supports passing codec-specific data inline and
> will likely play such a stream anyway. So there's no reason to abort
> initialization before we know for sure.
> ---
>  libavcodec/mediacodecdec.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index ac1725e466..67adefb530 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -167,8 +167,8 @@ static int h264_set_extradata(AVCodecContext *avctx,
> FFAMediaFormat *format)
>  ff_AMediaFormat_setBuffer(format, "csd-1", (void*)data, data_size);
>  av_freep();
>  } else {
> -av_log(avctx, AV_LOG_ERROR, "Could not extract PPS/SPS from
> extradata");
> -ret = AVERROR_INVALIDDATA;
> +av_log(avctx, AV_LOG_WARNING, "Could not extract PPS/SPS from
> extradata\n");
> +ret = 0;
>  }
>   done:
> @@ -254,8 +254,8 @@ static int hevc_set_extradata(AVCodecContext *avctx,
> FFAMediaFormat *format)
>   av_freep();
>  } else {
> -av_log(avctx, AV_LOG_ERROR, "Could not extract VPS/PPS/SPS from
> extradata");
> -ret = AVERROR_INVALIDDATA;
> +av_log(avctx, AV_LOG_WARNING, "Could not extract VPS/PPS/SPS from
> extradata\n");
> +ret = 0;
>  }
>   done:

Hello,

First of all, sorry for the late reply. The original intent with this
restriction was to make sure that MediaCodec could error out early (at the
configuration stage) so an implementation on top of libavcodec can decide
to fall back to a software decoder (without trying to decode anything).

I am fine with removing this restriction (if everyone is OK with that) for
the following reasons:
- there are chances that the h264/hevc software decoders have not been
  enabled (to avoid licensing issues) so the fallback mechanism is not
  available
- as you said extradata are not always available (mpegts) and we want to
  give MediaCodec a chance to decode the stream

So LGTM.

If everyone is OK with that, I'll also submit a patch that removes the
requirements on having the avctx->extradata set (I use such patch at work
to allow playback of certain hls/mpegts streams).

[...]
-- 
Matthieu B.
___
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] avformat/mov: adjust skip_samples according to seek timestamp

2021-01-06 Thread Matthieu Bouron
On Tue, Jan 05, 2021 at 09:56:39PM +0100, Marton Balint wrote:
> 
> On Tue, 5 Jan 2021, Matthieu Bouron wrote:
> 
> > > Could you factorize this to a function? It seems you are doing exactly the
> > > same thing here and below.
> > 
> > New patch attached.
> 
> [...]
> 
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index c6a2d9c388d..e6d0de38c6f 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -8122,6 +8122,15 @@ static int mov_seek_stream(AVFormatContext *s, 
> > AVStream *st, int64_t timestamp,
> >  return sample;
> >  }
> > 
> > +static int64_t mov_get_skip_samples(AVStream *st, int64_t seek_ts)
> > +{
> 
> Maybe cleaner to make "sample" a parameter instead of seek_ts.

Done.

> 
> > +MOVStreamContext *sc = st->priv_data;
> > +int64_t first_ts = st->internal->index_entries[0].timestamp;
> > +
> > +/* compute skip samples according to stream start_pad, seek ts and 
> > first ts */
> > +return FFMAX(sc->start_pad - (seek_ts - first_ts), 0);
> 
> Are you sure you don't need any time base correction here? Difference of
> timestamps is in stream time base, but skip_samples is the number of samples
> is in 1/sample_rate time base...

Done.

> 
> Also you are setting skip_samples for all streams, shouldn't you restrict it
> to audio only, so return 0 for non-audio streams?

I agree, it should only makes sense for audio streams. Updated.

> 
> > +}
> > +
> >  static int mov_read_seek(AVFormatContext *s, int stream_index, int64_t 
> > sample_time, int flags)
> >  {
> >  MOVContext *mc = s->priv_data;
> > @@ -8140,18 +8149,21 @@ static int mov_read_seek(AVFormatContext *s, int 
> > stream_index, int64_t sample_ti
> >  if (mc->seek_individually) {
> >  /* adjust seek timestamp to found sample timestamp */
> >  int64_t seek_timestamp = 
> > st->internal->index_entries[sample].timestamp;
> > +st->internal->skip_samples = mov_get_skip_samples(st, 
> > seek_timestamp);
> > 
> >  for (i = 0; i < s->nb_streams; i++) {
> >  int64_t timestamp;
> > -MOVStreamContext *sc = s->streams[i]->priv_data;
> >  st = s->streams[i];
> > -st->internal->skip_samples = (sample_time <= 0) ? 
> > sc->start_pad : 0;
> > 
> >  if (stream_index == i)
> >  continue;
> > 
> >  timestamp = av_rescale_q(seek_timestamp, 
> > s->streams[stream_index]->time_base, st->time_base);
> > -mov_seek_stream(s, st, timestamp, flags);
> > +sample = mov_seek_stream(s, st, timestamp, flags);
> > +if (sample >= 0) {
> > +seek_timestamp = 
> > st->internal->index_entries[sample].timestamp;
> 
> This is destorying seek_timestamp, which seems unintended.

It was unintended. Fixed.

> 
> > +st->internal->skip_samples = mov_get_skip_samples(st, 
> > seek_timestamp);
> > +}

New patch attached.

[...]

-- 
Matthieu B.
>From 82ed68085304ef98215bc1189d09f85c7c70fc0c Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Fri, 30 Oct 2020 15:38:51 +0100
Subject: [PATCH] avformat/mov: adjust skip_samples according to seek timestamp

Currently skip_samples is set to start_pad if sample_time is lesser or
equal to 0. This can cause issues if the stream starts with packets that
have negative pts. Calling avformat_seek_file() with ts set to 0 on such
streams makes the mov demuxer return the right corresponding packets
(near the 0 timestamp) but set skip_samples to start_pad which is
incorrect as the audio decoder will discard the returned samples
according to skip_samples from the first packet it receives (which has
its timestamp near 0).

For example, considering the following audio stream with start_pad=1344:

 [PKT pts=-1344] [PKT pts=-320] [PKT pts=704] [PKT pts=1728] [...]

Calling avformat_seek_file() with ts=0 makes the next call to
av_read_frame() return the packet with pts=-320 and a skip samples
side data set to 1344 (start_pad). This makes the audio decoder
incorrectly discard (1344 - 320) samples.

This commit makes the move demuxer adjust skip_samples according to the
stream start_pad, seek timestamp and first sample timestamp.

The above example will now result in av_read_frame() still returning the
packet with pts=-320 but with a skip samples side data set to 320
(src_pad - (seek_timestamp - first_timestamp)). This makes the audio
decoder only discard 320 samples (from pts=-320 to pts=0).
---
 libavformat/m

Re: [FFmpeg-devel] [PATCH] avformat/mov: adjust skip_samples according to seek timestamp

2021-01-05 Thread Matthieu Bouron
On Mon, Jan 04, 2021 at 09:04:05PM +0100, Marton Balint wrote:
> 
> 
> On Mon, 2 Nov 2020, Matthieu Bouron wrote:
> 
> > Currently skip_samples is set to start_pad if sample_time is lesser or
> > equal to 0. This can cause issues if the stream starts with packets that
> > have negative pts. Calling avformat_seek_file() with ts set to 0 on such
> > streams makes the mov demuxer return the right corresponding packets
> > (near the 0 timestamp) but set skip_samples to start_pad which is
> > incorrect as the audio decoder will discard the returned samples
> > according to skip_samples from the first packet it receives (which has
> > its timestamp near 0).
> > 
> > For example, considering the following audio stream with start_pad=1344:
> > 
> > [PKT pts=-1344] [PKT pts=-320] [PKT pts=704] [PKT pts=1728] [...]
> > 
> > Calling avformat_seek_file() with ts=0 makes the next call to
> > av_read_frame() return the packet with pts=-320 and a skip samples
> > side data set to 1344 (start_pad). This makes the audio decoder
> > incorrectly discard (1344 - 320) samples.
> > 
> > This commit makes the move demuxer adjust skip_samples according to the
> > stream start_pad, seek timestamp and first sample timestamp.
> > 
> > The above example will now result in av_read_frame() still returning the
> > packet with pts=-320 but with a skip samples side data set to 320
> > (src_pad - (seek_timestamp - first_timestamp)). This makes the audio
> > decoder only discard 320 samples (from pts=-320 to pts=0).
> > ---
> > libavformat/mov.c | 18 --
> > 1 file changed, 16 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index dd0db6bca79..f99cb0df25a 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -8098,20 +8098,34 @@ static int mov_read_seek(AVFormatContext *s, int 
> > stream_index, int64_t sample_ti
> > return sample;
> > 
> > if (mc->seek_individually) {
> > +MOVStreamContext *sc = s->streams[stream_index]->priv_data;
> > +
> > /* adjust seek timestamp to found sample timestamp */
> > +int64_t first_timestamp = st->internal->index_entries[0].timestamp;
> > int64_t seek_timestamp = 
> > st->internal->index_entries[sample].timestamp;
> > 
> > +/* adjust skip samples according to stream start_pad, seek 
> > timestamp and first timestamp */
> > +int64_t skip_samples = FFMAX(sc->start_pad - (seek_timestamp - 
> > first_timestamp), 0);
> > +st->internal->skip_samples = skip_samples;
> > +
> 
> Could you factorize this to a function? It seems you are doing exactly the
> same thing here and below.

New patch attached.

[...]

Thanks,

-- 
Matthieu B.
>From 3c95d4d5e4505edf95b9cf4b5a632be98c069123 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Fri, 30 Oct 2020 15:38:51 +0100
Subject: [PATCH] avformat/mov: adjust skip_samples according to seek timestamp

Currently skip_samples is set to start_pad if sample_time is lesser or
equal to 0. This can cause issues if the stream starts with packets that
have negative pts. Calling avformat_seek_file() with ts set to 0 on such
streams makes the mov demuxer return the right corresponding packets
(near the 0 timestamp) but set skip_samples to start_pad which is
incorrect as the audio decoder will discard the returned samples
according to skip_samples from the first packet it receives (which has
its timestamp near 0).

For example, considering the following audio stream with start_pad=1344:

 [PKT pts=-1344] [PKT pts=-320] [PKT pts=704] [PKT pts=1728] [...]

Calling avformat_seek_file() with ts=0 makes the next call to
av_read_frame() return the packet with pts=-320 and a skip samples
side data set to 1344 (start_pad). This makes the audio decoder
incorrectly discard (1344 - 320) samples.

This commit makes the move demuxer adjust skip_samples according to the
stream start_pad, seek timestamp and first sample timestamp.

The above example will now result in av_read_frame() still returning the
packet with pts=-320 but with a skip samples side data set to 320
(src_pad - (seek_timestamp - first_timestamp)). This makes the audio
decoder only discard 320 samples (from pts=-320 to pts=0).
---
 libavformat/mov.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index c6a2d9c388d..e6d0de38c6f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -8122,6 +8122,15 @@ static int mov_seek_stream(AVFormatContext *s, AVStream 
*st, int64_t timestamp,
 return sample;
 }
 
+static int64_t mov_get_skip_samples(AVStream *st, int64

Re: [FFmpeg-devel] [PATCH] avformat/mov: adjust skip_samples according to seek timestamp

2021-01-04 Thread Matthieu Bouron
On Mon, Nov 23, 2020 at 05:43:06PM +0100, Matthieu Bouron wrote:
> On Tue, Nov 17, 2020 at 02:18:46PM +0100, Matthieu Bouron wrote:
> > On Mon, Nov 09, 2020 at 06:26:46PM +0100, Matthieu Bouron wrote:
> > > On Mon, Nov 02, 2020 at 12:42:19PM +0100, Matthieu Bouron wrote:
> > > > Currently skip_samples is set to start_pad if sample_time is lesser or
> > > > equal to 0. This can cause issues if the stream starts with packets that
> > > > have negative pts. Calling avformat_seek_file() with ts set to 0 on such
> > > > streams makes the mov demuxer return the right corresponding packets
> > > > (near the 0 timestamp) but set skip_samples to start_pad which is
> > > > incorrect as the audio decoder will discard the returned samples
> > > > according to skip_samples from the first packet it receives (which has
> > > > its timestamp near 0).
> > > > 
> > > > For example, considering the following audio stream with start_pad=1344:
> > > > 
> > > >  [PKT pts=-1344] [PKT pts=-320] [PKT pts=704] [PKT pts=1728] [...]
> > > > 
> > > > Calling avformat_seek_file() with ts=0 makes the next call to
> > > > av_read_frame() return the packet with pts=-320 and a skip samples
> > > > side data set to 1344 (start_pad). This makes the audio decoder
> > > > incorrectly discard (1344 - 320) samples.
> > > > 
> > > > This commit makes the move demuxer adjust skip_samples according to the
> > > > stream start_pad, seek timestamp and first sample timestamp.
> > > > 
> > > > The above example will now result in av_read_frame() still returning the
> > > > packet with pts=-320 but with a skip samples side data set to 320
> > > > (src_pad - (seek_timestamp - first_timestamp)). This makes the audio
> > > > decoder only discard 320 samples (from pts=-320 to pts=0).
> > > > ---
> > > >  libavformat/mov.c | 18 --
> > > >  1 file changed, 16 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > > index dd0db6bca79..f99cb0df25a 100644
> > > > --- a/libavformat/mov.c
> > > > +++ b/libavformat/mov.c
> > > > @@ -8098,20 +8098,34 @@ static int mov_read_seek(AVFormatContext *s, 
> > > > int stream_index, int64_t sample_ti
> > > >  return sample;
> > > >  
> > > >  if (mc->seek_individually) {
> > > > +MOVStreamContext *sc = s->streams[stream_index]->priv_data;
> > > > +
> > > >  /* adjust seek timestamp to found sample timestamp */
> > > > +int64_t first_timestamp = 
> > > > st->internal->index_entries[0].timestamp;
> > > >  int64_t seek_timestamp = 
> > > > st->internal->index_entries[sample].timestamp;
> > > >  
> > > > +/* adjust skip samples according to stream start_pad, seek 
> > > > timestamp and first timestamp */
> > > > +int64_t skip_samples = FFMAX(sc->start_pad - (seek_timestamp - 
> > > > first_timestamp), 0);
> > > > +st->internal->skip_samples = skip_samples;
> > > > +
> > > >  for (i = 0; i < s->nb_streams; i++) {
> > > >  int64_t timestamp;
> > > >  MOVStreamContext *sc = s->streams[i]->priv_data;
> > > >  st = s->streams[i];
> > > > -st->internal->skip_samples = (sample_time <= 0) ? 
> > > > sc->start_pad : 0;
> > > >  
> > > >  if (stream_index == i)
> > > >  continue;
> > > >  
> > > >  timestamp = av_rescale_q(seek_timestamp, 
> > > > s->streams[stream_index]->time_base, st->time_base);
> > > > -mov_seek_stream(s, st, timestamp, flags);
> > > > +sample = mov_seek_stream(s, st, timestamp, flags);
> > > > +if (sample >= 0) {
> > > > +first_timestamp = 
> > > > st->internal->index_entries[0].timestamp;
> > > > +seek_timestamp = 
> > > > st->internal->index_entries[sample].timestamp;
> > > > +
> > > > +/* adjust skip samples according to stream start_pad, 
> > > > seek timestamp and first timestamp */
> > > > +skip_samples = FFMAX(sc->start_pad - (seek_timestamp - 
> > > > first_timestamp), 0);
> > > > +st->internal->skip_samples = skip_samples;
> > > > +}
> > > >  }
> > > >  } else {
> > > >  for (i = 0; i < s->nb_streams; i++) {
> > > > -- 
> > > > 2.29.2
> > > > 
> > > 
> > > Ping.
> > > 
> > 
> > Ping.
> > 
> 
> Ping.
> 

Ping.

-- 
Matthieu B.
___
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] avformat/mov: adjust skip_samples according to seek timestamp

2020-11-23 Thread Matthieu Bouron
On Tue, Nov 17, 2020 at 02:18:46PM +0100, Matthieu Bouron wrote:
> On Mon, Nov 09, 2020 at 06:26:46PM +0100, Matthieu Bouron wrote:
> > On Mon, Nov 02, 2020 at 12:42:19PM +0100, Matthieu Bouron wrote:
> > > Currently skip_samples is set to start_pad if sample_time is lesser or
> > > equal to 0. This can cause issues if the stream starts with packets that
> > > have negative pts. Calling avformat_seek_file() with ts set to 0 on such
> > > streams makes the mov demuxer return the right corresponding packets
> > > (near the 0 timestamp) but set skip_samples to start_pad which is
> > > incorrect as the audio decoder will discard the returned samples
> > > according to skip_samples from the first packet it receives (which has
> > > its timestamp near 0).
> > > 
> > > For example, considering the following audio stream with start_pad=1344:
> > > 
> > >  [PKT pts=-1344] [PKT pts=-320] [PKT pts=704] [PKT pts=1728] [...]
> > > 
> > > Calling avformat_seek_file() with ts=0 makes the next call to
> > > av_read_frame() return the packet with pts=-320 and a skip samples
> > > side data set to 1344 (start_pad). This makes the audio decoder
> > > incorrectly discard (1344 - 320) samples.
> > > 
> > > This commit makes the move demuxer adjust skip_samples according to the
> > > stream start_pad, seek timestamp and first sample timestamp.
> > > 
> > > The above example will now result in av_read_frame() still returning the
> > > packet with pts=-320 but with a skip samples side data set to 320
> > > (src_pad - (seek_timestamp - first_timestamp)). This makes the audio
> > > decoder only discard 320 samples (from pts=-320 to pts=0).
> > > ---
> > >  libavformat/mov.c | 18 --
> > >  1 file changed, 16 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > index dd0db6bca79..f99cb0df25a 100644
> > > --- a/libavformat/mov.c
> > > +++ b/libavformat/mov.c
> > > @@ -8098,20 +8098,34 @@ static int mov_read_seek(AVFormatContext *s, int 
> > > stream_index, int64_t sample_ti
> > >  return sample;
> > >  
> > >  if (mc->seek_individually) {
> > > +MOVStreamContext *sc = s->streams[stream_index]->priv_data;
> > > +
> > >  /* adjust seek timestamp to found sample timestamp */
> > > +int64_t first_timestamp = 
> > > st->internal->index_entries[0].timestamp;
> > >  int64_t seek_timestamp = 
> > > st->internal->index_entries[sample].timestamp;
> > >  
> > > +/* adjust skip samples according to stream start_pad, seek 
> > > timestamp and first timestamp */
> > > +int64_t skip_samples = FFMAX(sc->start_pad - (seek_timestamp - 
> > > first_timestamp), 0);
> > > +st->internal->skip_samples = skip_samples;
> > > +
> > >  for (i = 0; i < s->nb_streams; i++) {
> > >  int64_t timestamp;
> > >  MOVStreamContext *sc = s->streams[i]->priv_data;
> > >  st = s->streams[i];
> > > -st->internal->skip_samples = (sample_time <= 0) ? 
> > > sc->start_pad : 0;
> > >  
> > >  if (stream_index == i)
> > >  continue;
> > >  
> > >  timestamp = av_rescale_q(seek_timestamp, 
> > > s->streams[stream_index]->time_base, st->time_base);
> > > -mov_seek_stream(s, st, timestamp, flags);
> > > +sample = mov_seek_stream(s, st, timestamp, flags);
> > > +if (sample >= 0) {
> > > +first_timestamp = 
> > > st->internal->index_entries[0].timestamp;
> > > +seek_timestamp = 
> > > st->internal->index_entries[sample].timestamp;
> > > +
> > > +/* adjust skip samples according to stream start_pad, 
> > > seek timestamp and first timestamp */
> > > +skip_samples = FFMAX(sc->start_pad - (seek_timestamp - 
> > > first_timestamp), 0);
> > > +st->internal->skip_samples = skip_samples;
> > > +}
> > >  }
> > >  } else {
> > >  for (i = 0; i < s->nb_streams; i++) {
> > > -- 
> > > 2.29.2
> > > 
> > 
> > Ping.
> > 
> 
> Ping.
> 

Ping.

-- 
Matthieu B.
___
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] avformat/mov: adjust skip_samples according to seek timestamp

2020-11-17 Thread Matthieu Bouron
On Mon, Nov 09, 2020 at 06:26:46PM +0100, Matthieu Bouron wrote:
> On Mon, Nov 02, 2020 at 12:42:19PM +0100, Matthieu Bouron wrote:
> > Currently skip_samples is set to start_pad if sample_time is lesser or
> > equal to 0. This can cause issues if the stream starts with packets that
> > have negative pts. Calling avformat_seek_file() with ts set to 0 on such
> > streams makes the mov demuxer return the right corresponding packets
> > (near the 0 timestamp) but set skip_samples to start_pad which is
> > incorrect as the audio decoder will discard the returned samples
> > according to skip_samples from the first packet it receives (which has
> > its timestamp near 0).
> > 
> > For example, considering the following audio stream with start_pad=1344:
> > 
> >  [PKT pts=-1344] [PKT pts=-320] [PKT pts=704] [PKT pts=1728] [...]
> > 
> > Calling avformat_seek_file() with ts=0 makes the next call to
> > av_read_frame() return the packet with pts=-320 and a skip samples
> > side data set to 1344 (start_pad). This makes the audio decoder
> > incorrectly discard (1344 - 320) samples.
> > 
> > This commit makes the move demuxer adjust skip_samples according to the
> > stream start_pad, seek timestamp and first sample timestamp.
> > 
> > The above example will now result in av_read_frame() still returning the
> > packet with pts=-320 but with a skip samples side data set to 320
> > (src_pad - (seek_timestamp - first_timestamp)). This makes the audio
> > decoder only discard 320 samples (from pts=-320 to pts=0).
> > ---
> >  libavformat/mov.c | 18 --
> >  1 file changed, 16 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index dd0db6bca79..f99cb0df25a 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -8098,20 +8098,34 @@ static int mov_read_seek(AVFormatContext *s, int 
> > stream_index, int64_t sample_ti
> >  return sample;
> >  
> >  if (mc->seek_individually) {
> > +MOVStreamContext *sc = s->streams[stream_index]->priv_data;
> > +
> >  /* adjust seek timestamp to found sample timestamp */
> > +int64_t first_timestamp = st->internal->index_entries[0].timestamp;
> >  int64_t seek_timestamp = 
> > st->internal->index_entries[sample].timestamp;
> >  
> > +/* adjust skip samples according to stream start_pad, seek 
> > timestamp and first timestamp */
> > +int64_t skip_samples = FFMAX(sc->start_pad - (seek_timestamp - 
> > first_timestamp), 0);
> > +st->internal->skip_samples = skip_samples;
> > +
> >  for (i = 0; i < s->nb_streams; i++) {
> >  int64_t timestamp;
> >  MOVStreamContext *sc = s->streams[i]->priv_data;
> >  st = s->streams[i];
> > -st->internal->skip_samples = (sample_time <= 0) ? 
> > sc->start_pad : 0;
> >  
> >  if (stream_index == i)
> >  continue;
> >  
> >  timestamp = av_rescale_q(seek_timestamp, 
> > s->streams[stream_index]->time_base, st->time_base);
> > -mov_seek_stream(s, st, timestamp, flags);
> > +sample = mov_seek_stream(s, st, timestamp, flags);
> > +if (sample >= 0) {
> > +first_timestamp = st->internal->index_entries[0].timestamp;
> > +seek_timestamp = 
> > st->internal->index_entries[sample].timestamp;
> > +
> > +/* adjust skip samples according to stream start_pad, seek 
> > timestamp and first timestamp */
> > +skip_samples = FFMAX(sc->start_pad - (seek_timestamp - 
> > first_timestamp), 0);
> > +st->internal->skip_samples = skip_samples;
> > +}
> >  }
> >  } else {
> >  for (i = 0; i < s->nb_streams; i++) {
> > -- 
> > 2.29.2
> > 
> 
> Ping.
> 

Ping.

-- 
Matthieu B.
___
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] avformat/mov: adjust skip_samples according to seek timestamp

2020-11-09 Thread Matthieu Bouron
On Mon, Nov 02, 2020 at 12:42:19PM +0100, Matthieu Bouron wrote:
> Currently skip_samples is set to start_pad if sample_time is lesser or
> equal to 0. This can cause issues if the stream starts with packets that
> have negative pts. Calling avformat_seek_file() with ts set to 0 on such
> streams makes the mov demuxer return the right corresponding packets
> (near the 0 timestamp) but set skip_samples to start_pad which is
> incorrect as the audio decoder will discard the returned samples
> according to skip_samples from the first packet it receives (which has
> its timestamp near 0).
> 
> For example, considering the following audio stream with start_pad=1344:
> 
>  [PKT pts=-1344] [PKT pts=-320] [PKT pts=704] [PKT pts=1728] [...]
> 
> Calling avformat_seek_file() with ts=0 makes the next call to
> av_read_frame() return the packet with pts=-320 and a skip samples
> side data set to 1344 (start_pad). This makes the audio decoder
> incorrectly discard (1344 - 320) samples.
> 
> This commit makes the move demuxer adjust skip_samples according to the
> stream start_pad, seek timestamp and first sample timestamp.
> 
> The above example will now result in av_read_frame() still returning the
> packet with pts=-320 but with a skip samples side data set to 320
> (src_pad - (seek_timestamp - first_timestamp)). This makes the audio
> decoder only discard 320 samples (from pts=-320 to pts=0).
> ---
>  libavformat/mov.c | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index dd0db6bca79..f99cb0df25a 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -8098,20 +8098,34 @@ static int mov_read_seek(AVFormatContext *s, int 
> stream_index, int64_t sample_ti
>  return sample;
>  
>  if (mc->seek_individually) {
> +MOVStreamContext *sc = s->streams[stream_index]->priv_data;
> +
>  /* adjust seek timestamp to found sample timestamp */
> +int64_t first_timestamp = st->internal->index_entries[0].timestamp;
>  int64_t seek_timestamp = 
> st->internal->index_entries[sample].timestamp;
>  
> +/* adjust skip samples according to stream start_pad, seek timestamp 
> and first timestamp */
> +int64_t skip_samples = FFMAX(sc->start_pad - (seek_timestamp - 
> first_timestamp), 0);
> +st->internal->skip_samples = skip_samples;
> +
>  for (i = 0; i < s->nb_streams; i++) {
>  int64_t timestamp;
>  MOVStreamContext *sc = s->streams[i]->priv_data;
>  st = s->streams[i];
> -st->internal->skip_samples = (sample_time <= 0) ? sc->start_pad 
> : 0;
>  
>  if (stream_index == i)
>  continue;
>  
>  timestamp = av_rescale_q(seek_timestamp, 
> s->streams[stream_index]->time_base, st->time_base);
> -mov_seek_stream(s, st, timestamp, flags);
> +sample = mov_seek_stream(s, st, timestamp, flags);
> +if (sample >= 0) {
> +first_timestamp = st->internal->index_entries[0].timestamp;
> +seek_timestamp = 
> st->internal->index_entries[sample].timestamp;
> +
> +/* adjust skip samples according to stream start_pad, seek 
> timestamp and first timestamp */
> +skip_samples = FFMAX(sc->start_pad - (seek_timestamp - 
> first_timestamp), 0);
> +st->internal->skip_samples = skip_samples;
> +}
>  }
>  } else {
>  for (i = 0; i < s->nb_streams; i++) {
> -- 
> 2.29.2
> 

Ping.

-- 
Matthieu B.
___
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] avformat/mov: adjust skip_samples according to seek timestamp

2020-11-02 Thread Matthieu Bouron
Currently skip_samples is set to start_pad if sample_time is lesser or
equal to 0. This can cause issues if the stream starts with packets that
have negative pts. Calling avformat_seek_file() with ts set to 0 on such
streams makes the mov demuxer return the right corresponding packets
(near the 0 timestamp) but set skip_samples to start_pad which is
incorrect as the audio decoder will discard the returned samples
according to skip_samples from the first packet it receives (which has
its timestamp near 0).

For example, considering the following audio stream with start_pad=1344:

 [PKT pts=-1344] [PKT pts=-320] [PKT pts=704] [PKT pts=1728] [...]

Calling avformat_seek_file() with ts=0 makes the next call to
av_read_frame() return the packet with pts=-320 and a skip samples
side data set to 1344 (start_pad). This makes the audio decoder
incorrectly discard (1344 - 320) samples.

This commit makes the move demuxer adjust skip_samples according to the
stream start_pad, seek timestamp and first sample timestamp.

The above example will now result in av_read_frame() still returning the
packet with pts=-320 but with a skip samples side data set to 320
(src_pad - (seek_timestamp - first_timestamp)). This makes the audio
decoder only discard 320 samples (from pts=-320 to pts=0).
---
 libavformat/mov.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index dd0db6bca79..f99cb0df25a 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -8098,20 +8098,34 @@ static int mov_read_seek(AVFormatContext *s, int 
stream_index, int64_t sample_ti
 return sample;
 
 if (mc->seek_individually) {
+MOVStreamContext *sc = s->streams[stream_index]->priv_data;
+
 /* adjust seek timestamp to found sample timestamp */
+int64_t first_timestamp = st->internal->index_entries[0].timestamp;
 int64_t seek_timestamp = st->internal->index_entries[sample].timestamp;
 
+/* adjust skip samples according to stream start_pad, seek timestamp 
and first timestamp */
+int64_t skip_samples = FFMAX(sc->start_pad - (seek_timestamp - 
first_timestamp), 0);
+st->internal->skip_samples = skip_samples;
+
 for (i = 0; i < s->nb_streams; i++) {
 int64_t timestamp;
 MOVStreamContext *sc = s->streams[i]->priv_data;
 st = s->streams[i];
-st->internal->skip_samples = (sample_time <= 0) ? sc->start_pad : 
0;
 
 if (stream_index == i)
 continue;
 
 timestamp = av_rescale_q(seek_timestamp, 
s->streams[stream_index]->time_base, st->time_base);
-mov_seek_stream(s, st, timestamp, flags);
+sample = mov_seek_stream(s, st, timestamp, flags);
+if (sample >= 0) {
+first_timestamp = st->internal->index_entries[0].timestamp;
+seek_timestamp = st->internal->index_entries[sample].timestamp;
+
+/* adjust skip samples according to stream start_pad, seek 
timestamp and first timestamp */
+skip_samples = FFMAX(sc->start_pad - (seek_timestamp - 
first_timestamp), 0);
+st->internal->skip_samples = skip_samples;
+}
 }
 } else {
 for (i = 0; i < s->nb_streams; i++) {
-- 
2.29.2

___
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] working with file descriptors on Android

2020-07-25 Thread Matthieu Bouron
On Wed, Jul 22, 2020 at 2:38 PM Alex Cohn  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".

Re: [FFmpeg-devel] [PATCH] add support to Android ndk MediaCodec for encoding/decoding

2020-06-28 Thread Matthieu Bouron
On Sat, Jun 27, 2020 at 09:54:58PM +0300, Martin Storsjö wrote:
> On Sat, 27 Jun 2020, Olivier Ayache wrote:
> 
> > Hi everyone this is the first time I post on this mailing list. I am
> > working since several years on a fork of Xuggler for manipulating ffmpeg
> > API with Java/Kotlin.
> > This work leads me to develop encoder and decoder based on Android NDK
> > MediaCodec.
> > 
> > This work can be found on my Github repository
> > 
> > https://github.com/olivierayache/xuggle-xuggler
> > 
> > 
> > I know that FFmpeg already integrate MediaCodec for decoding via Jni
> > wrappers since version 3.1. I began this work on FFmpeg 2.8.x and I choose
> > the NDK in order to achieve optimum performance.
> 
> If you mean you used the NDK MediaCodec API, I'd suggest you use the same
> JNI wrappers as ffmpeg has already, for consistency. The overhead of a few
> JNI calls per encoded frame is generally negligible. If it, at a later time,
> is decided to drop support for older versions at some point, it should be
> straightforward to convert it to use the NDK MediaCodec API instead.

I agree with this, please use the MediaCodec wrapper for now. The
MediaCodec wrapper mimic the API of the NDK so if we decide to switch to
the NDK, it should be quite easy. Moreover, this work (switch to the NDK)
has already been done by Aman Gupta in one of his branches.

-- 
Matthieu B.
___
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] avcodec/mediacodec_common: use MediaFormat to probe frame color characteristics

2020-05-25 Thread Matthieu Bouron
On Wed, May 20, 2020 at 10:07:03AM +0200, Matthieu Bouron wrote:
> On Sat, May 09, 2020 at 09:45:05AM +0200, Matthieu Bouron wrote:
> > On Tue, Mar 31, 2020 at 10:03:08AM +0200, Matthieu Bouron wrote:
> > > ---
> > >  libavcodec/mediacodecdec_common.c | 100 ++
> > >  1 file changed, 100 insertions(+)
> > > 
> > > diff --git a/libavcodec/mediacodecdec_common.c 
> > > b/libavcodec/mediacodecdec_common.c
> > > index f0752fa6261..404ed282275 100644
> > > --- a/libavcodec/mediacodecdec_common.c
> > > +++ b/libavcodec/mediacodecdec_common.c
> > > @@ -85,6 +85,85 @@
> > >  #define OUTPUT_DEQUEUE_TIMEOUT_US 8000
> > >  #define OUTPUT_DEQUEUE_BLOCK_TIMEOUT_US 100
> > >  
> > > +enum {
> > > +COLOR_RANGE_FULL= 0x1,
> > > +COLOR_RANGE_LIMITED = 0x2,
> > > +};
> > > +
> > > +static enum AVColorRange mcdec_get_color_range(int color_range)
> > > +{
> > > +switch (color_range) {
> > > +case COLOR_RANGE_FULL:
> > > +return AVCOL_RANGE_JPEG;
> > > +case COLOR_RANGE_LIMITED:
> > > +return AVCOL_RANGE_MPEG;
> > > +default:
> > > +return AVCOL_RANGE_UNSPECIFIED;
> > > +}
> > > +}
> > > +
> > > +enum {
> > > +COLOR_STANDARD_BT709  = 0x1,
> > > +COLOR_STANDARD_BT601_PAL  = 0x2,
> > > +COLOR_STANDARD_BT601_NTSC = 0x4,
> > > +COLOR_STANDARD_BT2020 = 0x6,
> > > +};
> > > +
> > > +static enum AVColorSpace mcdec_get_color_space(int color_standard)
> > > +{
> > > +switch (color_standard) {
> > > +case COLOR_STANDARD_BT709:
> > > +return AVCOL_SPC_BT709;
> > > +case COLOR_STANDARD_BT601_PAL:
> > > +return AVCOL_SPC_BT470BG;
> > > +case COLOR_STANDARD_BT601_NTSC:
> > > +return AVCOL_SPC_SMPTE170M;
> > > +case COLOR_STANDARD_BT2020:
> > > +return AVCOL_SPC_BT2020_NCL;
> > > +default:
> > > +return AVCOL_SPC_UNSPECIFIED;
> > > +}
> > > +}
> > > +
> > > +static enum AVColorPrimaries mcdec_get_color_pri(int color_standard)
> > > +{
> > > +switch (color_standard) {
> > > +case COLOR_STANDARD_BT709:
> > > +return AVCOL_PRI_BT709;
> > > +case COLOR_STANDARD_BT601_PAL:
> > > +return AVCOL_PRI_BT470BG;
> > > +case COLOR_STANDARD_BT601_NTSC:
> > > +return AVCOL_PRI_SMPTE170M;
> > > +case COLOR_STANDARD_BT2020:
> > > +return AVCOL_PRI_BT2020;
> > > +default:
> > > +return AVCOL_PRI_UNSPECIFIED;
> > > +}
> > > +}
> > > +
> > > +enum {
> > > +COLOR_TRANSFER_LINEAR= 0x1,
> > > +COLOR_TRANSFER_SDR_VIDEO = 0x3,
> > > +COLOR_TRANSFER_ST2084= 0x6,
> > > +COLOR_TRANSFER_HLG   = 0x7,
> > > +};
> > > +
> > > +static enum AVColorTransferCharacteristic mcdec_get_color_trc(int 
> > > color_transfer)
> > > +{
> > > +switch (color_transfer) {
> > > +case COLOR_TRANSFER_LINEAR:
> > > +return AVCOL_TRC_LINEAR;
> > > +case COLOR_TRANSFER_SDR_VIDEO:
> > > +return AVCOL_TRC_SMPTE170M;
> > > +case COLOR_TRANSFER_ST2084:
> > > +return AVCOL_TRC_SMPTEST2084;
> > > +case COLOR_TRANSFER_HLG:
> > > +return AVCOL_TRC_ARIB_STD_B67;
> > > +default:
> > > +return AVCOL_TRC_UNSPECIFIED;
> > > +}
> > > +}
> > > +
> > >  enum {
> > >  COLOR_FormatYUV420Planar  = 0x13,
> > >  COLOR_FormatYUV420SemiPlanar  = 0x15,
> > > @@ -220,6 +299,10 @@ FF_DISABLE_DEPRECATION_WARNINGS
> > >  FF_ENABLE_DEPRECATION_WARNINGS
> > >  #endif
> > >  frame->pkt_dts = AV_NOPTS_VALUE;
> > > +frame->color_range = avctx->color_range;
> > > +frame->color_primaries = avctx->color_primaries;
> > > +frame->color_trc = avctx->color_trc;
> > > +frame->colorspace = avctx->colorspace;
> > >  
> > >  buffer = av_mallocz(sizeof(AVMediaCodecBuffer));
> > >  if (!buffer) {
> > > @@ -368,6 +451,9 @@ static int mediacodec_dec_parse_format(AVCodecContext 
> > > *avctx, MediaCodec

Re: [FFmpeg-devel] [PATCH] avcodec/mediacodec_common: use MediaFormat to probe frame color characteristics

2020-05-20 Thread Matthieu Bouron
On Sat, May 09, 2020 at 09:45:05AM +0200, Matthieu Bouron wrote:
> On Tue, Mar 31, 2020 at 10:03:08AM +0200, Matthieu Bouron wrote:
> > ---
> >  libavcodec/mediacodecdec_common.c | 100 ++
> >  1 file changed, 100 insertions(+)
> > 
> > diff --git a/libavcodec/mediacodecdec_common.c 
> > b/libavcodec/mediacodecdec_common.c
> > index f0752fa6261..404ed282275 100644
> > --- a/libavcodec/mediacodecdec_common.c
> > +++ b/libavcodec/mediacodecdec_common.c
> > @@ -85,6 +85,85 @@
> >  #define OUTPUT_DEQUEUE_TIMEOUT_US 8000
> >  #define OUTPUT_DEQUEUE_BLOCK_TIMEOUT_US 100
> >  
> > +enum {
> > +COLOR_RANGE_FULL= 0x1,
> > +COLOR_RANGE_LIMITED = 0x2,
> > +};
> > +
> > +static enum AVColorRange mcdec_get_color_range(int color_range)
> > +{
> > +switch (color_range) {
> > +case COLOR_RANGE_FULL:
> > +return AVCOL_RANGE_JPEG;
> > +case COLOR_RANGE_LIMITED:
> > +return AVCOL_RANGE_MPEG;
> > +default:
> > +return AVCOL_RANGE_UNSPECIFIED;
> > +}
> > +}
> > +
> > +enum {
> > +COLOR_STANDARD_BT709  = 0x1,
> > +COLOR_STANDARD_BT601_PAL  = 0x2,
> > +COLOR_STANDARD_BT601_NTSC = 0x4,
> > +COLOR_STANDARD_BT2020 = 0x6,
> > +};
> > +
> > +static enum AVColorSpace mcdec_get_color_space(int color_standard)
> > +{
> > +switch (color_standard) {
> > +case COLOR_STANDARD_BT709:
> > +return AVCOL_SPC_BT709;
> > +case COLOR_STANDARD_BT601_PAL:
> > +return AVCOL_SPC_BT470BG;
> > +case COLOR_STANDARD_BT601_NTSC:
> > +return AVCOL_SPC_SMPTE170M;
> > +case COLOR_STANDARD_BT2020:
> > +return AVCOL_SPC_BT2020_NCL;
> > +default:
> > +return AVCOL_SPC_UNSPECIFIED;
> > +}
> > +}
> > +
> > +static enum AVColorPrimaries mcdec_get_color_pri(int color_standard)
> > +{
> > +switch (color_standard) {
> > +case COLOR_STANDARD_BT709:
> > +return AVCOL_PRI_BT709;
> > +case COLOR_STANDARD_BT601_PAL:
> > +return AVCOL_PRI_BT470BG;
> > +case COLOR_STANDARD_BT601_NTSC:
> > +return AVCOL_PRI_SMPTE170M;
> > +case COLOR_STANDARD_BT2020:
> > +return AVCOL_PRI_BT2020;
> > +default:
> > +return AVCOL_PRI_UNSPECIFIED;
> > +}
> > +}
> > +
> > +enum {
> > +COLOR_TRANSFER_LINEAR= 0x1,
> > +COLOR_TRANSFER_SDR_VIDEO = 0x3,
> > +COLOR_TRANSFER_ST2084= 0x6,
> > +COLOR_TRANSFER_HLG   = 0x7,
> > +};
> > +
> > +static enum AVColorTransferCharacteristic mcdec_get_color_trc(int 
> > color_transfer)
> > +{
> > +switch (color_transfer) {
> > +case COLOR_TRANSFER_LINEAR:
> > +return AVCOL_TRC_LINEAR;
> > +case COLOR_TRANSFER_SDR_VIDEO:
> > +return AVCOL_TRC_SMPTE170M;
> > +case COLOR_TRANSFER_ST2084:
> > +return AVCOL_TRC_SMPTEST2084;
> > +case COLOR_TRANSFER_HLG:
> > +return AVCOL_TRC_ARIB_STD_B67;
> > +default:
> > +return AVCOL_TRC_UNSPECIFIED;
> > +}
> > +}
> > +
> >  enum {
> >  COLOR_FormatYUV420Planar  = 0x13,
> >  COLOR_FormatYUV420SemiPlanar  = 0x15,
> > @@ -220,6 +299,10 @@ FF_DISABLE_DEPRECATION_WARNINGS
> >  FF_ENABLE_DEPRECATION_WARNINGS
> >  #endif
> >  frame->pkt_dts = AV_NOPTS_VALUE;
> > +frame->color_range = avctx->color_range;
> > +frame->color_primaries = avctx->color_primaries;
> > +frame->color_trc = avctx->color_trc;
> > +frame->colorspace = avctx->colorspace;
> >  
> >  buffer = av_mallocz(sizeof(AVMediaCodecBuffer));
> >  if (!buffer) {
> > @@ -368,6 +451,9 @@ static int mediacodec_dec_parse_format(AVCodecContext 
> > *avctx, MediaCodecDecConte
> >  int ret = 0;
> >  int width = 0;
> >  int height = 0;
> > +int color_range = 0;
> > +int color_standard = 0;
> > +int color_transfer = 0;
> >  char *format = NULL;
> >  
> >  if (!s->format) {
> > @@ -426,6 +512,20 @@ static int mediacodec_dec_parse_format(AVCodecContext 
> > *avctx, MediaCodecDecConte
> >  ff_set_sar(avctx, sar);
> >  }
> >  
> > +AMEDIAFORMAT_GET_INT32(color_range, "color-range", 0);
> > +if (color_range)
> 

Re: [FFmpeg-devel] [PATCH] avcodec/mediacodec_common: use MediaFormat to probe frame color characteristics

2020-05-09 Thread Matthieu Bouron
On Tue, Mar 31, 2020 at 10:03:08AM +0200, Matthieu Bouron wrote:
> ---
>  libavcodec/mediacodecdec_common.c | 100 ++
>  1 file changed, 100 insertions(+)
> 
> diff --git a/libavcodec/mediacodecdec_common.c 
> b/libavcodec/mediacodecdec_common.c
> index f0752fa6261..404ed282275 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -85,6 +85,85 @@
>  #define OUTPUT_DEQUEUE_TIMEOUT_US 8000
>  #define OUTPUT_DEQUEUE_BLOCK_TIMEOUT_US 100
>  
> +enum {
> +COLOR_RANGE_FULL= 0x1,
> +COLOR_RANGE_LIMITED = 0x2,
> +};
> +
> +static enum AVColorRange mcdec_get_color_range(int color_range)
> +{
> +switch (color_range) {
> +case COLOR_RANGE_FULL:
> +return AVCOL_RANGE_JPEG;
> +case COLOR_RANGE_LIMITED:
> +return AVCOL_RANGE_MPEG;
> +default:
> +return AVCOL_RANGE_UNSPECIFIED;
> +}
> +}
> +
> +enum {
> +COLOR_STANDARD_BT709  = 0x1,
> +COLOR_STANDARD_BT601_PAL  = 0x2,
> +COLOR_STANDARD_BT601_NTSC = 0x4,
> +COLOR_STANDARD_BT2020 = 0x6,
> +};
> +
> +static enum AVColorSpace mcdec_get_color_space(int color_standard)
> +{
> +switch (color_standard) {
> +case COLOR_STANDARD_BT709:
> +return AVCOL_SPC_BT709;
> +case COLOR_STANDARD_BT601_PAL:
> +return AVCOL_SPC_BT470BG;
> +case COLOR_STANDARD_BT601_NTSC:
> +return AVCOL_SPC_SMPTE170M;
> +case COLOR_STANDARD_BT2020:
> +return AVCOL_SPC_BT2020_NCL;
> +default:
> +return AVCOL_SPC_UNSPECIFIED;
> +}
> +}
> +
> +static enum AVColorPrimaries mcdec_get_color_pri(int color_standard)
> +{
> +switch (color_standard) {
> +case COLOR_STANDARD_BT709:
> +return AVCOL_PRI_BT709;
> +case COLOR_STANDARD_BT601_PAL:
> +return AVCOL_PRI_BT470BG;
> +case COLOR_STANDARD_BT601_NTSC:
> +return AVCOL_PRI_SMPTE170M;
> +case COLOR_STANDARD_BT2020:
> +return AVCOL_PRI_BT2020;
> +default:
> +return AVCOL_PRI_UNSPECIFIED;
> +}
> +}
> +
> +enum {
> +COLOR_TRANSFER_LINEAR= 0x1,
> +COLOR_TRANSFER_SDR_VIDEO = 0x3,
> +COLOR_TRANSFER_ST2084= 0x6,
> +COLOR_TRANSFER_HLG   = 0x7,
> +};
> +
> +static enum AVColorTransferCharacteristic mcdec_get_color_trc(int 
> color_transfer)
> +{
> +switch (color_transfer) {
> +case COLOR_TRANSFER_LINEAR:
> +return AVCOL_TRC_LINEAR;
> +case COLOR_TRANSFER_SDR_VIDEO:
> +return AVCOL_TRC_SMPTE170M;
> +case COLOR_TRANSFER_ST2084:
> +return AVCOL_TRC_SMPTEST2084;
> +case COLOR_TRANSFER_HLG:
> +return AVCOL_TRC_ARIB_STD_B67;
> +default:
> +return AVCOL_TRC_UNSPECIFIED;
> +}
> +}
> +
>  enum {
>  COLOR_FormatYUV420Planar  = 0x13,
>  COLOR_FormatYUV420SemiPlanar  = 0x15,
> @@ -220,6 +299,10 @@ FF_DISABLE_DEPRECATION_WARNINGS
>  FF_ENABLE_DEPRECATION_WARNINGS
>  #endif
>  frame->pkt_dts = AV_NOPTS_VALUE;
> +frame->color_range = avctx->color_range;
> +frame->color_primaries = avctx->color_primaries;
> +frame->color_trc = avctx->color_trc;
> +frame->colorspace = avctx->colorspace;
>  
>  buffer = av_mallocz(sizeof(AVMediaCodecBuffer));
>  if (!buffer) {
> @@ -368,6 +451,9 @@ static int mediacodec_dec_parse_format(AVCodecContext 
> *avctx, MediaCodecDecConte
>  int ret = 0;
>  int width = 0;
>  int height = 0;
> +int color_range = 0;
> +int color_standard = 0;
> +int color_transfer = 0;
>  char *format = NULL;
>  
>  if (!s->format) {
> @@ -426,6 +512,20 @@ static int mediacodec_dec_parse_format(AVCodecContext 
> *avctx, MediaCodecDecConte
>  ff_set_sar(avctx, sar);
>  }
>  
> +AMEDIAFORMAT_GET_INT32(color_range, "color-range", 0);
> +if (color_range)
> +avctx->color_range = mcdec_get_color_range(color_range);
> +
> +AMEDIAFORMAT_GET_INT32(color_standard, "color-standard", 0);
> +if (color_standard) {
> +avctx->colorspace = mcdec_get_color_space(color_standard);
> +avctx->color_primaries = mcdec_get_color_pri(color_standard);
> +}
> +
> +AMEDIAFORMAT_GET_INT32(color_transfer, "color-transfer", 0);
> +if (color_transfer)
> +avctx->color_trc = mcdec_get_color_trc(color_transfer);
> +
>  av_log(avctx, AV_LOG_INFO,
>  "Output crop parameters top=%d bottom=%d left=%d right=%d, "
>  "resulting dimensions width=%d height=%d\n",
> -- 
> 2.26.0
> 

Ping.

-- 
Matthieu B.
___
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] avcodec/mediacodec_wrapper: fix {input, output}_buffers global reference leak

2020-04-15 Thread Matthieu Bouron
On Tue, Apr 14, 2020 at 09:51:08AM +0200, Matthieu Bouron wrote:
> On Thu, Apr 09, 2020 at 05:06:05PM +0200, Matthieu Bouron wrote:
> > Fixes ticket #8607.
> > ---
> >  libavcodec/mediacodec_wrapper.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/libavcodec/mediacodec_wrapper.c 
> > b/libavcodec/mediacodec_wrapper.c
> > index 5213cf640a7..79abc8b6aa9 100644
> > --- a/libavcodec/mediacodec_wrapper.c
> > +++ b/libavcodec/mediacodec_wrapper.c
> > @@ -1303,6 +1303,12 @@ int ff_AMediaCodec_delete(FFAMediaCodec* codec)
> >  ret = AVERROR_EXTERNAL;
> >  }
> >  
> > +(*env)->DeleteGlobalRef(env, codec->input_buffers);
> > +codec->input_buffers = NULL;
> > +
> > +(*env)->DeleteGlobalRef(env, codec->output_buffers);
> > +codec->output_buffers = NULL;
> > +
> >  (*env)->DeleteGlobalRef(env, codec->object);
> >  codec->object = NULL;
> >  
> > -- 
> > 2.26.0
> > 
> 
> The user confirmed the patch fixes the issue. I will apply this patch
> tomorrow if there is no objection.

Applied.

-- 
Matthieu B.
___
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] avcodec/mediacodec_wrapper: fix {input, output}_buffers global reference leak

2020-04-14 Thread Matthieu Bouron
On Thu, Apr 09, 2020 at 05:06:05PM +0200, Matthieu Bouron wrote:
> Fixes ticket #8607.
> ---
>  libavcodec/mediacodec_wrapper.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
> index 5213cf640a7..79abc8b6aa9 100644
> --- a/libavcodec/mediacodec_wrapper.c
> +++ b/libavcodec/mediacodec_wrapper.c
> @@ -1303,6 +1303,12 @@ int ff_AMediaCodec_delete(FFAMediaCodec* codec)
>  ret = AVERROR_EXTERNAL;
>  }
>  
> +(*env)->DeleteGlobalRef(env, codec->input_buffers);
> +codec->input_buffers = NULL;
> +
> +(*env)->DeleteGlobalRef(env, codec->output_buffers);
> +codec->output_buffers = NULL;
> +
>  (*env)->DeleteGlobalRef(env, codec->object);
>  codec->object = NULL;
>  
> -- 
> 2.26.0
> 

The user confirmed the patch fixes the issue. I will apply this patch
tomorrow if there is no objection.

-- 
Matthieu B.
___
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] avcodec/mediacodec_wrapper: fix {input, output}_buffers global reference leak

2020-04-09 Thread Matthieu Bouron
Fixes ticket #8607.
---
 libavcodec/mediacodec_wrapper.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavcodec/mediacodec_wrapper.c b/libavcodec/mediacodec_wrapper.c
index 5213cf640a7..79abc8b6aa9 100644
--- a/libavcodec/mediacodec_wrapper.c
+++ b/libavcodec/mediacodec_wrapper.c
@@ -1303,6 +1303,12 @@ int ff_AMediaCodec_delete(FFAMediaCodec* codec)
 ret = AVERROR_EXTERNAL;
 }
 
+(*env)->DeleteGlobalRef(env, codec->input_buffers);
+codec->input_buffers = NULL;
+
+(*env)->DeleteGlobalRef(env, codec->output_buffers);
+codec->output_buffers = NULL;
+
 (*env)->DeleteGlobalRef(env, codec->object);
 codec->object = NULL;
 
-- 
2.26.0

___
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] avformat/img2dec: return immediately in jpeg_probe() when EOI is found

2020-04-01 Thread Matthieu Bouron
On Wed, Apr 01, 2020 at 09:10:19PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 21:07 Uhr schrieb Matthieu Bouron
> :
> >
> > On Wed, Apr 01, 2020 at 07:59:46PM +0200, Carl Eugen Hoyos wrote:
> > > Am Mi., 1. Apr. 2020 um 19:54 Uhr schrieb Matthieu Bouron
> > > :
> > > >
> > > > On Wed, Apr 01, 2020 at 07:30:55PM +0200, Carl Eugen Hoyos wrote:
> > > > > Am Mi., 1. Apr. 2020 um 19:15 Uhr schrieb Matthieu Bouron
> > > > > :
> > > > > >
> > > > > > On Wed, Apr 01, 2020 at 06:55:42PM +0200, Carl Eugen Hoyos wrote:
> > > > > > > Am Mi., 1. Apr. 2020 um 18:35 Uhr schrieb Matthieu Bouron
> > > > > > > :
> > > > > > > >
> > > > > > > > On Wed, Apr 01, 2020 at 06:29:03PM +0200, Carl Eugen Hoyos 
> > > > > > > > wrote:
> > > > > > > > > Am Mi., 1. Apr. 2020 um 18:01 Uhr schrieb Matthieu Bouron
> > > > > > > > > :
> > > > > > > > > >
> > > > > > > > > > Fixes probing of JPEG files containing MPF metadata 
> > > > > > > > > > appended at the end
> > > > > > > > > > of the file.
> > > > > > > > > >
> > > > > > > > > > The MPF metadata chunk can contains multiple JPEG images 
> > > > > > > > > > (thumbnails)
> > > > > > > > > > which makes the jpeg_probe fails (return 0) because it 
> > > > > > > > > > finds a SOI
> > > > > > > > > > marker after EOI.
> > > > > > > > > > ---
> > > > > > > > > >
> > > > > > > > > > This patch fixes probing of JPEG files containing MPF 
> > > > > > > > > > metadata [1] appended
> > > > > > > > > > at the end of the file.
> > > > > > > > > >
> > > > > > > > > > Such files can be produced by GoPro camera (which produces 
> > > > > > > > > > JPEG files
> > > > > > > > > > with MPF metadata).
> > > > > > > > > >
> > > > > > > > > > You can find a sample here:
> > > > > > > > > > https://0x5c.me/gopro_jpg_mpf_probe_fail
> > > > > > > > >
> > > > > > > > > The sample works fine here with FFmpeg 4.2: Is there a 
> > > > > > > > > regression?
> > > > > > > >
> > > > > > > > This sample does not work on FFmpeg 4.2 and master if you set a 
> > > > > > > > big
> > > > > > > > enought formatprobesize (which matches the file size of the 
> > > > > > > > sample):
> > > > > > >
> > > > > > > Inlined is a patch that fixes detection but I wonder if this 
> > > > > > > shouldn't be
> > > > > > > detected as mjpeg instead
> > > > > > >
> > > > > > > Carl Eugen
> > > > > > >
> > > > > > > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> > > > > > > index 40f3e3d499..4e63b3494e 100644
> > > > > > > --- a/libavformat/img2dec.c
> > > > > > > +++ b/libavformat/img2dec.c
> > > > > > > @@ -737,20 +737,22 @@ static int j2k_probe(const AVProbeData *p)
> > > > > > >  static int jpeg_probe(const AVProbeData *p)
> > > > > > >  {
> > > > > > >  const uint8_t *b = p->buf;
> > > > > > > -int i, state = SOI;
> > > > > > > +int i, state = SOI, MPF = 0;
> > > > > > >
> > > > > > >  if (AV_RB16(b) != 0xFFD8 ||
> > > > > > >  AV_RB32(b) == 0xFFD8FFF7)
> > > > > > >  return 0;
> > > > > > >
> > > > > > >  b += 2;
> > > > > > > -for (i = 0; i < p->buf_size - 3; i++) {
> > > > > > > +for (i = 0; i < p->buf_size - 8; i++) {
> > > > > > >  int c;
> > > > > > >  if (b[i] != 0xFF)
> > > > > > >  continue;
&g

Re: [FFmpeg-devel] [PATCH] avformat/img2dec: return immediately in jpeg_probe() when EOI is found

2020-04-01 Thread Matthieu Bouron
On Wed, Apr 01, 2020 at 07:59:46PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 19:54 Uhr schrieb Matthieu Bouron
> :
> >
> > On Wed, Apr 01, 2020 at 07:30:55PM +0200, Carl Eugen Hoyos wrote:
> > > Am Mi., 1. Apr. 2020 um 19:15 Uhr schrieb Matthieu Bouron
> > > :
> > > >
> > > > On Wed, Apr 01, 2020 at 06:55:42PM +0200, Carl Eugen Hoyos wrote:
> > > > > Am Mi., 1. Apr. 2020 um 18:35 Uhr schrieb Matthieu Bouron
> > > > > :
> > > > > >
> > > > > > On Wed, Apr 01, 2020 at 06:29:03PM +0200, Carl Eugen Hoyos wrote:
> > > > > > > Am Mi., 1. Apr. 2020 um 18:01 Uhr schrieb Matthieu Bouron
> > > > > > > :
> > > > > > > >
> > > > > > > > Fixes probing of JPEG files containing MPF metadata appended at 
> > > > > > > > the end
> > > > > > > > of the file.
> > > > > > > >
> > > > > > > > The MPF metadata chunk can contains multiple JPEG images 
> > > > > > > > (thumbnails)
> > > > > > > > which makes the jpeg_probe fails (return 0) because it finds a 
> > > > > > > > SOI
> > > > > > > > marker after EOI.
> > > > > > > > ---
> > > > > > > >
> > > > > > > > This patch fixes probing of JPEG files containing MPF metadata 
> > > > > > > > [1] appended
> > > > > > > > at the end of the file.
> > > > > > > >
> > > > > > > > Such files can be produced by GoPro camera (which produces JPEG 
> > > > > > > > files
> > > > > > > > with MPF metadata).
> > > > > > > >
> > > > > > > > You can find a sample here:
> > > > > > > > https://0x5c.me/gopro_jpg_mpf_probe_fail
> > > > > > >
> > > > > > > The sample works fine here with FFmpeg 4.2: Is there a regression?
> > > > > >
> > > > > > This sample does not work on FFmpeg 4.2 and master if you set a big
> > > > > > enought formatprobesize (which matches the file size of the sample):
> > > > >
> > > > > Inlined is a patch that fixes detection but I wonder if this 
> > > > > shouldn't be
> > > > > detected as mjpeg instead
> > > > >
> > > > > Carl Eugen
> > > > >
> > > > > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> > > > > index 40f3e3d499..4e63b3494e 100644
> > > > > --- a/libavformat/img2dec.c
> > > > > +++ b/libavformat/img2dec.c
> > > > > @@ -737,20 +737,22 @@ static int j2k_probe(const AVProbeData *p)
> > > > >  static int jpeg_probe(const AVProbeData *p)
> > > > >  {
> > > > >  const uint8_t *b = p->buf;
> > > > > -int i, state = SOI;
> > > > > +int i, state = SOI, MPF = 0;
> > > > >
> > > > >  if (AV_RB16(b) != 0xFFD8 ||
> > > > >  AV_RB32(b) == 0xFFD8FFF7)
> > > > >  return 0;
> > > > >
> > > > >  b += 2;
> > > > > -for (i = 0; i < p->buf_size - 3; i++) {
> > > > > +for (i = 0; i < p->buf_size - 8; i++) {
> > > > >  int c;
> > > > >  if (b[i] != 0xFF)
> > > > >  continue;
> > > > >  c = b[i + 1];
> > > > >  switch (c) {
> > > > >  case SOI:
> > > > > +if (state == EOI && MPF)
> > > > > +return AVPROBE_SCORE_EXTENSION + 1;
> > > >
> > > > Your patch might work
> > >
> > > You could test it.
> > >
> > > > but the code is trying to find JPEG markers in the
> > > > MPF metadata until we reach the first EOI in the MPF JPEG thumbnails,
> > >
> >
> > I meant SOI sorry.
> >
> > > No, and I am quite sure that I tested this sufficiently.
> >
> > My point is, we are trying to parse way more data than necessary (the data
> > we parse might not be jpeg at this point): the code looks for a marker and
> > handles it, if the marker is unknown it repeats this operation for the
> > next byte until it reaches the end of the bu

Re: [FFmpeg-devel] [PATCH] avformat/img2dec: return immediately in jpeg_probe() when EOI is found

2020-04-01 Thread Matthieu Bouron
On Wed, Apr 01, 2020 at 07:30:55PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 19:15 Uhr schrieb Matthieu Bouron
> :
> >
> > On Wed, Apr 01, 2020 at 06:55:42PM +0200, Carl Eugen Hoyos wrote:
> > > Am Mi., 1. Apr. 2020 um 18:35 Uhr schrieb Matthieu Bouron
> > > :
> > > >
> > > > On Wed, Apr 01, 2020 at 06:29:03PM +0200, Carl Eugen Hoyos wrote:
> > > > > Am Mi., 1. Apr. 2020 um 18:01 Uhr schrieb Matthieu Bouron
> > > > > :
> > > > > >
> > > > > > Fixes probing of JPEG files containing MPF metadata appended at the 
> > > > > > end
> > > > > > of the file.
> > > > > >
> > > > > > The MPF metadata chunk can contains multiple JPEG images 
> > > > > > (thumbnails)
> > > > > > which makes the jpeg_probe fails (return 0) because it finds a SOI
> > > > > > marker after EOI.
> > > > > > ---
> > > > > >
> > > > > > This patch fixes probing of JPEG files containing MPF metadata [1] 
> > > > > > appended
> > > > > > at the end of the file.
> > > > > >
> > > > > > Such files can be produced by GoPro camera (which produces JPEG 
> > > > > > files
> > > > > > with MPF metadata).
> > > > > >
> > > > > > You can find a sample here:
> > > > > > https://0x5c.me/gopro_jpg_mpf_probe_fail
> > > > >
> > > > > The sample works fine here with FFmpeg 4.2: Is there a regression?
> > > >
> > > > This sample does not work on FFmpeg 4.2 and master if you set a big
> > > > enought formatprobesize (which matches the file size of the sample):
> > >
> > > Inlined is a patch that fixes detection but I wonder if this shouldn't be
> > > detected as mjpeg instead
> > >
> > > Carl Eugen
> > >
> > > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> > > index 40f3e3d499..4e63b3494e 100644
> > > --- a/libavformat/img2dec.c
> > > +++ b/libavformat/img2dec.c
> > > @@ -737,20 +737,22 @@ static int j2k_probe(const AVProbeData *p)
> > >  static int jpeg_probe(const AVProbeData *p)
> > >  {
> > >  const uint8_t *b = p->buf;
> > > -int i, state = SOI;
> > > +int i, state = SOI, MPF = 0;
> > >
> > >  if (AV_RB16(b) != 0xFFD8 ||
> > >  AV_RB32(b) == 0xFFD8FFF7)
> > >  return 0;
> > >
> > >  b += 2;
> > > -for (i = 0; i < p->buf_size - 3; i++) {
> > > +for (i = 0; i < p->buf_size - 8; i++) {
> > >  int c;
> > >  if (b[i] != 0xFF)
> > >  continue;
> > >  c = b[i + 1];
> > >  switch (c) {
> > >  case SOI:
> > > +if (state == EOI && MPF)
> > > +return AVPROBE_SCORE_EXTENSION + 1;
> >
> > Your patch might work
> 
> You could test it.
> 
> > but the code is trying to find JPEG markers in the
> > MPF metadata until we reach the first EOI in the MPF JPEG thumbnails,
> 

I meant SOI sorry.

> No, and I am quite sure that I tested this sufficiently.

My point is, we are trying to parse way more data than necessary (the data
we parse might not be jpeg at this point): the code looks for a marker and
handles it, if the marker is unknown it repeats this operation for the
next byte until it reaches the end of the buffer or it finds SOI in the
EOI+MPF state (with your patch).

Why cant' we end the processing at EOI ? If there is a particular reason
for that ?

> 
> Shouldn't there be a mpf demuxer that also provides the attachments?

I already have a patch to parse the MPF metadata. The only thing left to
do is to expose the attachments (it currently only exposes those as
file offsets in stream metadata). I will send the patch later on.

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

-- 
Matthieu B.
___
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] avformat/img2dec: return immediately in jpeg_probe() when EOI is found

2020-04-01 Thread Matthieu Bouron
On Wed, Apr 01, 2020 at 06:55:42PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 18:35 Uhr schrieb Matthieu Bouron
> :
> >
> > On Wed, Apr 01, 2020 at 06:29:03PM +0200, Carl Eugen Hoyos wrote:
> > > Am Mi., 1. Apr. 2020 um 18:01 Uhr schrieb Matthieu Bouron
> > > :
> > > >
> > > > Fixes probing of JPEG files containing MPF metadata appended at the end
> > > > of the file.
> > > >
> > > > The MPF metadata chunk can contains multiple JPEG images (thumbnails)
> > > > which makes the jpeg_probe fails (return 0) because it finds a SOI
> > > > marker after EOI.
> > > > ---
> > > >
> > > > This patch fixes probing of JPEG files containing MPF metadata [1] 
> > > > appended
> > > > at the end of the file.
> > > >
> > > > Such files can be produced by GoPro camera (which produces JPEG files
> > > > with MPF metadata).
> > > >
> > > > You can find a sample here:
> > > > https://0x5c.me/gopro_jpg_mpf_probe_fail
> > >
> > > The sample works fine here with FFmpeg 4.2: Is there a regression?
> >
> > This sample does not work on FFmpeg 4.2 and master if you set a big
> > enought formatprobesize (which matches the file size of the sample):
> 
> Inlined is a patch that fixes detection but I wonder if this shouldn't be
> detected as mjpeg instead
> 
> Carl Eugen
> 
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index 40f3e3d499..4e63b3494e 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img2dec.c
> @@ -737,20 +737,22 @@ static int j2k_probe(const AVProbeData *p)
>  static int jpeg_probe(const AVProbeData *p)
>  {
>  const uint8_t *b = p->buf;
> -int i, state = SOI;
> +int i, state = SOI, MPF = 0;
> 
>  if (AV_RB16(b) != 0xFFD8 ||
>  AV_RB32(b) == 0xFFD8FFF7)
>  return 0;
> 
>  b += 2;
> -for (i = 0; i < p->buf_size - 3; i++) {
> +for (i = 0; i < p->buf_size - 8; i++) {
>  int c;
>  if (b[i] != 0xFF)
>  continue;
>  c = b[i + 1];
>  switch (c) {
>  case SOI:
> +if (state == EOI && MPF)
> +return AVPROBE_SCORE_EXTENSION + 1;

Your patch might work but the code is trying to find JPEG markers in the
MPF metadata until we reach the first EOI in the MPF JPEG thumbnails, even
if we already found the SOS and EOI markes of the main JPEG chunk. This
logic does not seem right to me.

Is there a specific reason why we couldn't end the probe when we reach the
EOI marker in the SOS state (ie: what my patch is doing) ?

>  return 0;
>  case SOF0:
>  case SOF1:
> @@ -775,10 +777,12 @@ static int jpeg_probe(const AVProbeData *p)
>  return 0;
>  state = EOI;
>  break;
> +case APP2:
> +if (AV_RB24([i + 4]) == AV_RB24("MPF"))
> +MPF = 1;
>  case DQT:
>  case APP0:
>  case APP1:
> -case APP2:
>  case APP3:
>  case APP4:
>  case APP5:
> ___
> 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".

-- 
Matthieu B.
___
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] avformat/img2dec: return immediately in jpeg_probe() when EOI is found

2020-04-01 Thread Matthieu Bouron
On Wed, Apr 01, 2020 at 06:19:56PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 18:01 Uhr schrieb Matthieu Bouron
> :
> >
> > Fixes probing of JPEG files containing MPF metadata appended at the end
> > of the file.
> >
> > The MPF metadata chunk can contains multiple JPEG images (thumbnails)
> > which makes the jpeg_probe fails (return 0) because it finds a SOI
> > marker after EOI.
> > ---
> >
> > This patch fixes probing of JPEG files containing MPF metadata [1] appended
> > at the end of the file.
> >
> > Such files can be produced by GoPro camera (which produces JPEG files
> > with MPF metadata).
> >
> > You can find a sample here:
> > https://0x5c.me/gopro_jpg_mpf_probe_fail
> >
> > To reproduce the issue using ffmpeg master:
> > wget https://0x5c.me/gopro_jpg_mpf_probe_fail
> > ./ffmpeg -formatprobesize 500 -i gopro_jpg_mpf_probe_fail
> >
> > I removed intentionally the jpeg extension from the filename so the
> > image2 demuxer is not used.
> >
> > Current ffmpeg master won't still be able to decode this file because of a
> > "regression" introduced by ec3d8a0e6945fe015d16cd98a1e7dbb4be815c15 on
> > the mjpeg_parser.
> > The jpeg_pipe demuxer outputs partial chunks of the jpeg file that the
> > mjpeg decoder can't handle (it needs the whole data). Before
> > ec3d8a0e6945fe015d16cd98a1e7dbb4be815c15, the mjpeg_parser was
> > outputting a complete frame.
> >
> > If the parser is correct as is, another way to fix this issue whould be
> > to add AVSTREAM_PARSE_HEADERS to the need_parsing flags from the
> > jpeg_pipe demuxer, ie:
> >
> > --- a/libavformat/img2dec.c
> > +++ b/libavformat/img2dec.c
> > @@ -209,7 +209,7 @@ int ff_img_read_header(AVFormatContext *s1)
> >  s->is_pipe = 0;
> >  else {
> >  s->is_pipe   = 1;
> > -st->need_parsing = AVSTREAM_PARSE_FULL;
> > +st->need_parsing = AVSTREAM_PARSE_FULL | AVSTREAM_PARSE_HEADERS;
> >
> > Settings AVSTREAM_PARSE_HEADERS makes avformat requests complete frames
> > from the parser in libavformat/utils.c
> >
> > What do you think ?
> 
> Why is your sample not detected by the mjpeg demuxer?

I don't know yet, it looks like nb_invalid is incremented in the default
case of mjpeg_probe(). I will investigate why.

This shouldn't change the fact that the jpeg_probe() should be able to
recognize this kind of files.

> 
> I suspect your patch breaks the mjpeg demuxer.

Why would it break the mjpeg demuxer ?

> 
> > [1] https://exiftool.org/TagNames/MPF.html
> >
> > ---
> >  libavformat/img2dec.c | 6 +-
> >  1 file changed, 1 insertion(+), 5 deletions(-)
> >
> > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> > index 93cd51c1932..decd8023e02 100644
> > --- a/libavformat/img2dec.c
> > +++ b/libavformat/img2dec.c
> > @@ -773,9 +773,7 @@ static int jpeg_probe(const AVProbeData *p)
> >  case EOI:
> >  if (state != SOS)
> >  return 0;
> > -state = EOI;
> > -break;
> > -case DHT:
> > +return AVPROBE_SCORE_EXTENSION + 1;
> 
> I don't think this is correct.

Why ? Isn't the data JPEG if we find an EOI marker after having found a
SOS marker ?

> 
> >  case DQT:
> >  case APP0:
> >  case APP1:
> > @@ -803,8 +801,6 @@ static int jpeg_probe(const AVProbeData *p)
> >  }
> >  }
> >
> 
> > -if (state == EOI)
> > -return AVPROBE_SCORE_EXTENSION + 1;
> 
> >  if (state == SOS)
> >  return AVPROBE_SCORE_EXTENSION / 2;
> >  return AVPROBE_SCORE_EXTENSION / 8;
> 
> Carl Eugen
> ___
> 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".

-- 
Matthieu B.
___
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] avformat/img2dec: return immediately in jpeg_probe() when EOI is found

2020-04-01 Thread Matthieu Bouron
On Wed, Apr 01, 2020 at 06:29:03PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 18:01 Uhr schrieb Matthieu Bouron
> :
> >
> > Fixes probing of JPEG files containing MPF metadata appended at the end
> > of the file.
> >
> > The MPF metadata chunk can contains multiple JPEG images (thumbnails)
> > which makes the jpeg_probe fails (return 0) because it finds a SOI
> > marker after EOI.
> > ---
> >
> > This patch fixes probing of JPEG files containing MPF metadata [1] appended
> > at the end of the file.
> >
> > Such files can be produced by GoPro camera (which produces JPEG files
> > with MPF metadata).
> >
> > You can find a sample here:
> > https://0x5c.me/gopro_jpg_mpf_probe_fail
> 
> The sample works fine here with FFmpeg 4.2: Is there a regression?

This sample does not work on FFmpeg 4.2 and master if you set a big
enought formatprobesize (which matches the file size of the sample):

ffmpeg -formatprobesize 500 -i ~/gopro_jpg_mpf_probe_fail gives:

/home/mateo/gopro_jpg_mpf_probe_fail: Invalid data found when processing
input

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

-- 
Matthieu B.
___
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] avformat/img2dec: skip DHT segment in jpeg_probe()

2020-04-01 Thread Matthieu Bouron
On Wed, Apr 01, 2020 at 04:29:16PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 16:24 Uhr schrieb Matthieu Bouron
> :
> >
> > On Wed, Apr 01, 2020 at 04:09:08PM +0200, Carl Eugen Hoyos wrote:
> > > Am Mi., 1. Apr. 2020 um 15:48 Uhr schrieb Matthieu Bouron
> > > :
> > > >
> > > > On Wed, Apr 01, 2020 at 03:38:45PM +0200, Carl Eugen Hoyos wrote:
> > > > > Am Mi., 1. Apr. 2020 um 10:57 Uhr schrieb Matthieu Bouron
> > > > > :
> > > > > >
> > > > > > ---
> > > > > >  libavformat/img2dec.c | 1 +
> > > > > >  1 file changed, 1 insertion(+)
> > > > > >
> > > > > > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> > > > > > index 40f3e3d499e..93cd51c1932 100644
> > > > > > --- a/libavformat/img2dec.c
> > > > > > +++ b/libavformat/img2dec.c
> > > > > > @@ -775,6 +775,7 @@ static int jpeg_probe(const AVProbeData *p)
> > > > > >  return 0;
> > > > > >  state = EOI;
> > > > > >  break;
> > > > > > +case DHT:
> > > > > >  case DQT:
> > > > > >  case APP0:
> > > > > >  case APP1:
> > > > >
> > > > > Please provide a sample file.
> > > >
> > > > This patch does not fix a particular issue. IMHO, we should skip the DHT
> > > > segment just like the other segments (and avoids parsing the data it
> > > > contains) unless there is a particular reason for it ?
> > >
> > > I am (somewhat strongly) against patches that do not fix issues but
> > > Michael will hopefully comment.
> > >
> > > Or are you trying to improve probing speed?
> >
> > I am trying to fix an issues with JPEG files containing MPF metadata
> > appended at the end.
> > Theses files makes the jpeg_probe function fails (returns 0) because the
> > MPF metadata contains JPEG images (so jpeg_probe() finds a SOI marker
> > after EOI). I will send a separate patch for that and provide a
> > sample.
> 
> Are these valid jpeg files?

They are valid JPEGs with MPF metadata
(https://exiftool.org/TagNames/MPF.html).

See
https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/259489.html


> 
> > This patch should improve the probing speed by little though.
> 
> Then please measure the speedup and mention it in the
> commit message.

I tried to measure the speed gain using perf record ffmpeg -i [...]
without success (i can't get a meaningful difference between the different
runs which makes sense as the DHT segment size from the file I test against is
419 bytes).

> 
> Thank you, Carl Eugen
> ___
> 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".

-- 
Matthieu B.
___
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] avformat/img2dec: return immediately in jpeg_probe() when EOI is found

2020-04-01 Thread Matthieu Bouron
Fixes probing of JPEG files containing MPF metadata appended at the end
of the file.

The MPF metadata chunk can contains multiple JPEG images (thumbnails)
which makes the jpeg_probe fails (return 0) because it finds a SOI
marker after EOI.
---

This patch fixes probing of JPEG files containing MPF metadata [1] appended
at the end of the file.

Such files can be produced by GoPro camera (which produces JPEG files
with MPF metadata).

You can find a sample here:
https://0x5c.me/gopro_jpg_mpf_probe_fail

To reproduce the issue using ffmpeg master:
wget https://0x5c.me/gopro_jpg_mpf_probe_fail
./ffmpeg -formatprobesize 500 -i gopro_jpg_mpf_probe_fail

I removed intentionally the jpeg extension from the filename so the
image2 demuxer is not used.

Current ffmpeg master won't still be able to decode this file because of a
"regression" introduced by ec3d8a0e6945fe015d16cd98a1e7dbb4be815c15 on
the mjpeg_parser.
The jpeg_pipe demuxer outputs partial chunks of the jpeg file that the
mjpeg decoder can't handle (it needs the whole data). Before
ec3d8a0e6945fe015d16cd98a1e7dbb4be815c15, the mjpeg_parser was
outputting a complete frame.

If the parser is correct as is, another way to fix this issue whould be
to add AVSTREAM_PARSE_HEADERS to the need_parsing flags from the
jpeg_pipe demuxer, ie:

--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -209,7 +209,7 @@ int ff_img_read_header(AVFormatContext *s1)
 s->is_pipe = 0;
 else {
 s->is_pipe   = 1;
-st->need_parsing = AVSTREAM_PARSE_FULL;
+st->need_parsing = AVSTREAM_PARSE_FULL | AVSTREAM_PARSE_HEADERS;

Settings AVSTREAM_PARSE_HEADERS makes avformat requests complete frames
from the parser in libavformat/utils.c

What do you think ?

[1] https://exiftool.org/TagNames/MPF.html

---
 libavformat/img2dec.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 93cd51c1932..decd8023e02 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -773,9 +773,7 @@ static int jpeg_probe(const AVProbeData *p)
 case EOI:
 if (state != SOS)
 return 0;
-state = EOI;
-break;
-case DHT:
+return AVPROBE_SCORE_EXTENSION + 1;
 case DQT:
 case APP0:
 case APP1:
@@ -803,8 +801,6 @@ static int jpeg_probe(const AVProbeData *p)
 }
 }
 
-if (state == EOI)
-return AVPROBE_SCORE_EXTENSION + 1;
 if (state == SOS)
 return AVPROBE_SCORE_EXTENSION / 2;
 return AVPROBE_SCORE_EXTENSION / 8;
-- 
2.26.0

___
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] avformat/img2dec: skip DHT segment in jpeg_probe()

2020-04-01 Thread Matthieu Bouron
On Wed, Apr 01, 2020 at 04:09:08PM +0200, Carl Eugen Hoyos wrote:
> Am Mi., 1. Apr. 2020 um 15:48 Uhr schrieb Matthieu Bouron
> :
> >
> > On Wed, Apr 01, 2020 at 03:38:45PM +0200, Carl Eugen Hoyos wrote:
> > > Am Mi., 1. Apr. 2020 um 10:57 Uhr schrieb Matthieu Bouron
> > > :
> > > >
> > > > ---
> > > >  libavformat/img2dec.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> > > > index 40f3e3d499e..93cd51c1932 100644
> > > > --- a/libavformat/img2dec.c
> > > > +++ b/libavformat/img2dec.c
> > > > @@ -775,6 +775,7 @@ static int jpeg_probe(const AVProbeData *p)
> > > >  return 0;
> > > >  state = EOI;
> > > >  break;
> > > > +case DHT:
> > > >  case DQT:
> > > >  case APP0:
> > > >  case APP1:
> > >
> > > Please provide a sample file.
> >
> > This patch does not fix a particular issue. IMHO, we should skip the DHT
> > segment just like the other segments (and avoids parsing the data it
> > contains) unless there is a particular reason for it ?
> 
> I am (somewhat strongly) against patches that do not fix issues but
> Michael will hopefully comment.
> 
> Or are you trying to improve probing speed?

I am trying to fix an issues with JPEG files containing MPF metadata
appended at the end.
Theses files makes the jpeg_probe function fails (returns 0) because the
MPF metadata contains JPEG images (so jpeg_probe() finds a SOI marker
after EOI). I will send a separate patch for that and provide a
sample.

This patch should improve the probing speed by little though.

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

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

  1   2   3   4   5   6   7   >