Re: [FFmpeg-devel] FFmpeg release 6.1

[Jean-Baptiste Kempf]

Hello,

On Thu, 21 Sep 2023, at 00:47, Kieran Kunhya wrote:
>>
>> also iam not sure "experimental" is the right flag for code that has
>> possible security issues. People might turn experimental on not realizing
>> the security aspect.
>>
>
> We should make this clear in the docs then.

+1

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
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 3/3] libavfilter/dnn: Initialze DNNData variables

[Chen, Wenbin]

> > On Sep 20, 2023, at 10:26, wenbin.chen-at-intel@ffmpeg.org wrote:
> >
> > From: Wenbin Chen 
> >
> > Signed-off-by: Wenbin Chen 
> > ---
> > libavfilter/dnn/dnn_backend_tf.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/dnn/dnn_backend_tf.c
> b/libavfilter/dnn/dnn_backend_tf.c
> > index b521de7fbe..e1e8cef0d2 100644
> > --- a/libavfilter/dnn/dnn_backend_tf.c
> > +++ b/libavfilter/dnn/dnn_backend_tf.c
> > @@ -629,6 +629,7 @@ static int fill_model_input_tf(TFModel *tf_model,
> TFRequestItem *request) {
> > TFContext *ctx = _model->ctx;
> > int ret = 0;
> >
> > +memset(, 0, sizeof(input));
> 
> Can be simplified with DNNData input = { 0 };

Thanks for your advice. I update it in patch v2. 

> 
> > lltask = ff_queue_pop_front(tf_model->lltask_queue);
> > av_assert0(lltask);
> > task = lltask->task;
> > @@ -724,7 +725,7 @@ static void infer_completion_callback(void *args) {
> > TFModel *tf_model = task->model;
> > TFContext *ctx = _model->ctx;
> >
> > -outputs = av_malloc_array(task->nb_output, sizeof(*outputs));
> > +outputs = av_calloc(task->nb_output, sizeof(*outputs));
> > if (!outputs) {
> > av_log(ctx, AV_LOG_ERROR, "Failed to allocate memory for
> *outputs\n");
> > goto err;
> > --
> > 2.34.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 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] [PATCH v2 3/3] libavfilter/dnn: Initialze DNNData variables

[wenbin . chen-at-intel . com]

From: Wenbin Chen 

Signed-off-by: Wenbin Chen 
---
 libavfilter/dnn/dnn_backend_tf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/dnn/dnn_backend_tf.c b/libavfilter/dnn/dnn_backend_tf.c
index b521de7fbe..25046b58d9 100644
--- a/libavfilter/dnn/dnn_backend_tf.c
+++ b/libavfilter/dnn/dnn_backend_tf.c
@@ -622,7 +622,7 @@ err:
 }
 
 static int fill_model_input_tf(TFModel *tf_model, TFRequestItem *request) {
-DNNData input;
+DNNData input = { 0 };
 LastLevelTaskItem *lltask;
 TaskItem *task;
 TFInferRequest *infer_request = NULL;
@@ -724,7 +724,7 @@ static void infer_completion_callback(void *args) {
 TFModel *tf_model = task->model;
 TFContext *ctx = _model->ctx;
 
-outputs = av_malloc_array(task->nb_output, sizeof(*outputs));
+outputs = av_calloc(task->nb_output, sizeof(*outputs));
 if (!outputs) {
 av_log(ctx, AV_LOG_ERROR, "Failed to allocate memory for *outputs\n");
 goto err;
-- 
2.34.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 v2 2/3] libavfilter/dnn: Add scale and mean preprocess to openvino backend

[wenbin . chen-at-intel . com]

From: Wenbin Chen 

Dnn models has different data preprocess requirements. Scale and mean
parameters are added to preprocess input data.

Signed-off-by: Wenbin Chen 
---
 libavfilter/dnn/dnn_backend_openvino.c | 43 --
 libavfilter/dnn/dnn_io_proc.c  | 82 +-
 libavfilter/dnn_interface.h|  2 +
 3 files changed, 108 insertions(+), 19 deletions(-)

diff --git a/libavfilter/dnn/dnn_backend_openvino.c 
b/libavfilter/dnn/dnn_backend_openvino.c
index 3ba5f5331a..4224600f94 100644
--- a/libavfilter/dnn/dnn_backend_openvino.c
+++ b/libavfilter/dnn/dnn_backend_openvino.c
@@ -46,6 +46,8 @@ typedef struct OVOptions{
 int batch_size;
 int input_resizable;
 DNNLayout layout;
+float scale;
+float mean;
 } OVOptions;
 
 typedef struct OVContext {
@@ -105,6 +107,8 @@ static const AVOption dnn_openvino_options[] = {
 { "none",  "none", 0, AV_OPT_TYPE_CONST, { .i64 = DL_NONE }, 0, 0, 
FLAGS, "layout"},
 { "nchw",  "nchw", 0, AV_OPT_TYPE_CONST, { .i64 = DL_NCHW }, 0, 0, 
FLAGS, "layout"},
 { "nhwc",  "nhwc", 0, AV_OPT_TYPE_CONST, { .i64 = DL_NHWC }, 0, 0, 
FLAGS, "layout"},
+{ "scale", "Add scale preprocess operation. Divide each element of input 
by specified value.", OFFSET(options.scale), AV_OPT_TYPE_FLOAT, { .dbl = 0 }, 
INT_MIN, INT_MAX, FLAGS},
+{ "mean",  "Add mean preprocess operation. Subtract specified value from 
each element of input.", OFFSET(options.mean),  AV_OPT_TYPE_FLOAT, { .dbl = 0 
}, INT_MIN, INT_MAX, FLAGS},
 { NULL }
 };
 
@@ -209,6 +213,7 @@ static int fill_model_input_ov(OVModel *ov_model, 
OVRequestItem *request)
 ie_blob_t *input_blob = NULL;
 #endif
 
+memset(, 0, sizeof(input));
 lltask = ff_queue_peek_front(ov_model->lltask_queue);
 av_assert0(lltask);
 task = lltask->task;
@@ -274,6 +279,9 @@ static int fill_model_input_ov(OVModel *ov_model, 
OVRequestItem *request)
 // all models in openvino open model zoo use BGR as input,
 // change to be an option when necessary.
 input.order = DCO_BGR;
+// We use preprocess_steps to scale input data, so disable scale and mean 
here.
+input.scale = 1;
+input.mean = 0;
 
 for (int i = 0; i < ctx->options.batch_size; ++i) {
 lltask = ff_queue_pop_front(ov_model->lltask_queue);
@@ -343,6 +351,7 @@ static void infer_completion_callback(void *args)
 ov_shape_t output_shape = {0};
 ov_element_type_e precision;
 
+memset(, 0, sizeof(output));
 status = 
ov_infer_request_get_output_tensor_by_index(request->infer_request, 0, 
_tensor);
 if (status != OK) {
 av_log(ctx, AV_LOG_ERROR,
@@ -409,6 +418,8 @@ static void infer_completion_callback(void *args)
 #endif
 output.dt   = precision_to_datatype(precision);
 output.layout   = ctx->options.layout;
+output.scale= ctx->options.scale;
+output.mean = ctx->options.mean;
 
 av_assert0(request->lltask_count >= 1);
 for (int i = 0; i < request->lltask_count; ++i) {
@@ -542,7 +553,9 @@ static int init_model_ov(OVModel *ov_model, const char 
*input_name, const char *
 ie_config_t config = {NULL, NULL, NULL};
 char *all_dev_names = NULL;
 #endif
-
+// We scale pixel by default when do frame processing.
+if (fabsf(ctx->options.scale) < 1e-6f)
+ctx->options.scale = ov_model->model->func_type == DFT_PROCESS_FRAME ? 
255 : 1;
 // batch size
 if (ctx->options.batch_size <= 0) {
 ctx->options.batch_size = 1;
@@ -609,15 +622,37 @@ static int init_model_ov(OVModel *ov_model, const char 
*input_name, const char *
 goto err;
 }
 
+status = 
ov_preprocess_input_tensor_info_set_element_type(input_tensor_info, U8);
 if (ov_model->model->func_type != DFT_PROCESS_FRAME)
-//set precision only for detect and classify
-status = 
ov_preprocess_input_tensor_info_set_element_type(input_tensor_info, U8);
-status |= ov_preprocess_output_set_element_type(output_tensor_info, F32);
+status |= ov_preprocess_output_set_element_type(output_tensor_info, 
F32);
+else if (fabsf(ctx->options.scale - 1) > 1e-6f || fabsf(ctx->options.mean) 
> 1e-6f)
+status |= ov_preprocess_output_set_element_type(output_tensor_info, 
F32);
+else
+status |= ov_preprocess_output_set_element_type(output_tensor_info, 
U8);
 if (status != OK) {
 av_log(ctx, AV_LOG_ERROR, "Failed to set input/output element type\n");
 ret = ov2_map_error(status, NULL);
 goto err;
 }
+// set preprocess steps.
+if (fabsf(ctx->options.scale - 1) > 1e-6f || fabsf(ctx->options.mean) > 
1e-6f) {
+ov_preprocess_preprocess_steps_t* input_process_steps = NULL;
+status = 
ov_preprocess_input_info_get_preprocess_steps(ov_model->input_info, 
_process_steps);
+if (status != OK) {
+av_log(ctx, AV_LOG_ERROR, "Failed to get preprocess steps\n");
+ret = ov2_map_error(status, NULL);
+

[FFmpeg-devel] [PATCH v2 1/3] libavfilter/dnn: add layout option to openvino backend

[wenbin . chen-at-intel . com]

From: Wenbin Chen 

Dnn models have different input layout (NCHW or NHWC), so a
"layout" option is added
Use openvino's API to do layout conversion for input data. Use swscale
to do layout conversion for output data as openvino doesn't have
similiar C API for output.

Signed-off-by: Wenbin Chen 
---
 libavfilter/dnn/dnn_backend_openvino.c |  47 +++-
 libavfilter/dnn/dnn_io_proc.c  | 151 ++---
 libavfilter/dnn_interface.h|   7 ++
 3 files changed, 185 insertions(+), 20 deletions(-)

diff --git a/libavfilter/dnn/dnn_backend_openvino.c 
b/libavfilter/dnn/dnn_backend_openvino.c
index 4922833b07..3ba5f5331a 100644
--- a/libavfilter/dnn/dnn_backend_openvino.c
+++ b/libavfilter/dnn/dnn_backend_openvino.c
@@ -45,6 +45,7 @@ typedef struct OVOptions{
 uint8_t async;
 int batch_size;
 int input_resizable;
+DNNLayout layout;
 } OVOptions;
 
 typedef struct OVContext {
@@ -100,6 +101,10 @@ static const AVOption dnn_openvino_options[] = {
 DNN_BACKEND_COMMON_OPTIONS
 { "batch_size",  "batch size per request", OFFSET(options.batch_size),  
AV_OPT_TYPE_INT,{ .i64 = 1 }, 1, 1000, FLAGS},
 { "input_resizable", "can input be resizable or not", 
OFFSET(options.input_resizable), AV_OPT_TYPE_BOOL,   { .i64 = 0 }, 0, 1, 
FLAGS },
+{ "layout", "input layout of model", OFFSET(options.layout), 
AV_OPT_TYPE_INT, { .i64 = DL_NONE}, DL_NONE, DL_NHWC, FLAGS, "layout" },
+{ "none",  "none", 0, AV_OPT_TYPE_CONST, { .i64 = DL_NONE }, 0, 0, 
FLAGS, "layout"},
+{ "nchw",  "nchw", 0, AV_OPT_TYPE_CONST, { .i64 = DL_NCHW }, 0, 0, 
FLAGS, "layout"},
+{ "nhwc",  "nhwc", 0, AV_OPT_TYPE_CONST, { .i64 = DL_NHWC }, 0, 0, 
FLAGS, "layout"},
 { NULL }
 };
 
@@ -231,9 +236,9 @@ static int fill_model_input_ov(OVModel *ov_model, 
OVRequestItem *request)
 avpriv_report_missing_feature(ctx, "Do not support dynamic model.");
 return AVERROR(ENOSYS);
 }
-input.height = dims[2];
-input.width = dims[3];
-input.channels = dims[1];
+input.height = dims[1];
+input.width = dims[2];
+input.channels = dims[3];
 input.dt = precision_to_datatype(precision);
 input.data = av_malloc(input.height * input.width * input.channels * 
get_datatype_size(input.dt));
 if (!input.data)
@@ -403,6 +408,7 @@ static void infer_completion_callback(void *args)
 av_assert0(request->lltask_count <= dims.dims[0]);
 #endif
 output.dt   = precision_to_datatype(precision);
+output.layout   = ctx->options.layout;
 
 av_assert0(request->lltask_count >= 1);
 for (int i = 0; i < request->lltask_count; ++i) {
@@ -521,11 +527,14 @@ static int init_model_ov(OVModel *ov_model, const char 
*input_name, const char *
 OVContext *ctx = _model->ctx;
 #if HAVE_OPENVINO2
 ov_status_e status;
-ov_preprocess_input_tensor_info_t* input_tensor_info;
-ov_preprocess_output_tensor_info_t* output_tensor_info;
+ov_preprocess_input_tensor_info_t* input_tensor_info = NULL;
+ov_preprocess_output_tensor_info_t* output_tensor_info = NULL;
+ov_preprocess_input_model_info_t* input_model_info = NULL;
 ov_model_t *tmp_ov_model;
 ov_layout_t* NHWC_layout = NULL;
+ov_layout_t* NCHW_layout = NULL;
 const char* NHWC_desc = "NHWC";
+const char* NCHW_desc = "NCHW";
 const char* device = ctx->options.device_type;
 #else
 IEStatusCode status;
@@ -570,6 +579,7 @@ static int init_model_ov(OVModel *ov_model, const char 
*input_name, const char *
 
 //set input layout
 status = ov_layout_create(NHWC_desc, _layout);
+status |= ov_layout_create(NCHW_desc, _layout);
 if (status != OK) {
 av_log(ctx, AV_LOG_ERROR, "Failed to create layout for input.\n");
 ret = ov2_map_error(status, NULL);
@@ -583,6 +593,22 @@ static int init_model_ov(OVModel *ov_model, const char 
*input_name, const char *
 goto err;
 }
 
+status = ov_preprocess_input_info_get_model_info(ov_model->input_info, 
_model_info);
+if (status != OK) {
+av_log(ctx, AV_LOG_ERROR, "Failed to get input model info\n");
+ret = ov2_map_error(status, NULL);
+goto err;
+}
+if (ctx->options.layout == DL_NCHW)
+status = ov_preprocess_input_model_info_set_layout(input_model_info, 
NCHW_layout);
+else if (ctx->options.layout == DL_NHWC)
+status = ov_preprocess_input_model_info_set_layout(input_model_info, 
NHWC_layout);
+if (status != OK) {
+av_log(ctx, AV_LOG_ERROR, "Failed to get set input model layout\n");
+ret = ov2_map_error(status, NULL);
+goto err;
+}
+
 if (ov_model->model->func_type != DFT_PROCESS_FRAME)
 //set precision only for detect and classify
 status = 
ov_preprocess_input_tensor_info_set_element_type(input_tensor_info, U8);
@@ -618,6 +644,9 @@ static int init_model_ov(OVModel *ov_model, const char 
*input_name, const char *
 ret = ov2_map_error(status, NULL);
   

Re: [FFmpeg-devel] [PATCH 17/42] avcodec/refstruct: Add RefStruct pool API

[Andreas Rheinhardt]

Michael Niedermayer:
> On Tue, Sep 19, 2023 at 09:57:09PM +0200, Andreas Rheinhardt wrote:
>> Very similar to the AVBufferPool API, but with some differences:
>> 1. Reusing an already existing entry does not incur an allocation
>> at all any more (the AVBufferPool API needs to allocate an AVBufferRef).
>> 2. The tasks done while holding the lock are smaller; e.g.
>> allocating new entries is now performed without holding the lock.
>> The same goes for freeing.
>> 3. The entries are freed as soon as possible (the AVBufferPool API
>> frees them in two batches: The first in av_buffer_pool_uninit() and
>> the second immediately before the pool is freed when the last
>> outstanding entry is returned to the pool).
>> 4. The API is designed for objects and not naked buffers and
>> therefore has a reset callback. This is called whenever an object
>> is returned to the pool.
>> 5. Just like with the RefStruct API, custom allocators are not
>> supported.
>>
>> (If desired, the FFRefStructPool struct itself could be made
>> reference counted via the RefStruct API; an FFRefStructPool
>> would then be freed via ff_refstruct_unref().)
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavcodec/refstruct.c | 194 -
>>  libavcodec/refstruct.h | 128 +++
>>  2 files changed, 321 insertions(+), 1 deletion(-)
> 
> seems to break building on ppc (--disable-pthreads)
> 
> CClibavcodec/refstruct.o
> src/libavcodec/refstruct.c: In function ‘pool_free’:
> src/libavcodec/refstruct.c:187:5: error: implicit declaration of function 
> ‘pthread_mutex_destroy’; did you mean ‘ff_mutex_destroy’? 
> [-Werror=implicit-function-declaration]
>  pthread_mutex_destroy(>mutex);
>  ^
>  ff_mutex_destroy
> src/libavcodec/refstruct.c: In function ‘pool_return_entry’:
> src/libavcodec/refstruct.c:205:5: error: implicit declaration of function 
> ‘pthread_mutex_lock’; did you mean ‘ff_mutex_lock’? 
> [-Werror=implicit-function-declaration]
>  pthread_mutex_lock(>mutex);
>  ^~
>  ff_mutex_lock
> src/libavcodec/refstruct.c:211:5: error: implicit declaration of function 
> ‘pthread_mutex_unlock’; did you mean ‘ff_mutex_unlock’? 
> [-Werror=implicit-function-declaration]
>  pthread_mutex_unlock(>mutex);
>  ^~~~
>  ff_mutex_unlock
> src/libavcodec/refstruct.c: In function ‘ff_refstruct_pool_alloc_ext_c’:
> src/libavcodec/refstruct.c:339:11: error: implicit declaration of function 
> ‘pthread_mutex_init’; did you mean ‘ff_mutex_init’? 
> [-Werror=implicit-function-declaration]
>  err = pthread_mutex_init(>mutex, NULL);
>^~
>ff_mutex_init
> cc1: some warnings being treated as errors
> /home/michael/ffmpeg-git/ffmpeg/ffbuild/common.mak:81: recipe for target 
> 'libavcodec/refstruct.o' failed
> make: *** [libavcodec/refstruct.o] Error 1
> make: Target 'all' not remade because of errors.

Sorry for not having tested --disable-pthreads. Will switch to our
ff_mutex-wrappers.

- Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 35/42] avcodec/threadprogress: Add new API for frame-threaded progress

[Andreas Rheinhardt]

Michael Niedermayer:
> On Tue, Sep 19, 2023 at 09:57:27PM +0200, Andreas Rheinhardt wrote:
>> The API is very similar by the ProgressFrame API, with the exception
>> that it no longer has an included AVFrame. Instead one can wait
>> on anything via a ThreadProgress. One just has to ensure that
>> the lifetime of the object containing the ThreadProgress is long
>> enough (the corresponding problem for ProgressFrames is solved
>> by allocating the progress and giving each thread a reference
>> to it). This will typically be solved by putting a ThreadProgress
>> in a refcounted structure that is shared between threads.
>> It will be put to the test in the following commits.
>>
>> An alternative to the check for whether the owner exists
>> (meaning "do we use frame-threading?") would be to initialize
>> the progress to INT_MAX in case frame threading is not in use.
>> This would probably be preferable on arches where atomic reads
>> are cheap (like x86), but are there ones where it is not?
>>
>> One could also (guarded by e.g. an ASSERT_LEVEL check) actually
>> track the progress for non-framethreading, too, in order to
>> track errors even in single-threaded mode.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavcodec/pthread_frame.c  | 50 +
>>  libavcodec/threadprogress.h | 37 +++
>>  2 files changed, 87 insertions(+)
>>  create mode 100644 libavcodec/threadprogress.h
> 
> Seems to break build here with shared libs / clang
> 
> CClibavcodec/pthread_frame.o
> src/libavcodec/pthread_frame.c:1108:9: error: address argument to atomic 
> operation must be a pointer to non-const _Atomic type ('const atomic_int *' 
> (aka 'const _Atomic(int) *') invalid)
> atomic_load_explicit(>progress, memory_order_acquire) >= n)
> ^~~
> /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:135:30: note: expanded 
> from macro 'atomic_load_explicit'
> #define atomic_load_explicit __c11_atomic_load
>  ^
> src/libavcodec/pthread_frame.c:1116:12: error: address argument to atomic 
> operation must be a pointer to non-const _Atomic type ('const atomic_int *' 
> (aka 'const _Atomic(int) *') invalid)
> while (atomic_load_explicit(>progress, memory_order_relaxed) < n)
>^~~
> /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:135:30: note: expanded 
> from macro 'atomic_load_explicit'
> #define atomic_load_explicit __c11_atomic_load
>  ^
> 2 errors generated.
> src/ffbuild/common.mak:81: recipe for target 'libavcodec/pthread_frame.o' 
> failed
> make: *** [libavcodec/pthread_frame.o] Error 1
> make: Target 'all' not remade because of errors.
> 

The original version of C11 did not allow to use atomic_load() on
const-qualified atomic objects (presumably because on systems that don't
have native support for atomic operations this might involve locking a
mutex or so and this would involve writes); this has since been changed
(see defect report N1807), yet your (presumably) ancient toolchain does
not reflect that.

I'll cast const away here and add a comment.

- Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter: add libvmaf_cuda

[Timo Rothenpieler]

On 20.09.2023 22:06, Kyle Swanson wrote:

Hi,

On Mon, Sep 18, 2023 at 2:39 PM Kyle Swanson  wrote:


Hi,

On Mon, Sep 18, 2023 at 12:41 PM Timo Rothenpieler
 wrote:

On 18.09.2023 21:21, Marvin Scholz wrote:

I am far from an expert with the configure script but won't that cause 
--enable-libvmaf to fail when
libvmaf is built without cuda support? Which seems undesirable to me…


Yeah, hence my suggested change of


enabled libvmaf_cuda  && require_pkg_config libvmaf_cuda "libvmaf >= 2.0.0" 
libvmaf_cuda.h vmaf_cuda_state_init


This only works if I add `libvmaf_cuda` to EXTERNAL_LIBRARY_LIST,
otherwise running `./configure --enable-libvmaf-cuda` will fail with
`Unknown option "--enable-libvmaf-cuda".` I'm not sure that's the
right thing to do given there is no such thing as `libvmaf_cuda`. If
you are aware of a different way of handling this, let me know. Most
of the other libraries we link with optional configurations (see
libopus, libvpx, ...) seem to have the pattern I used in this previous
patch [0], which does avoid the problem pointed out by Marvin.

Thanks,
Kyle

[0] http://ffmpeg.org/pipermail/ffmpeg-devel/2023-September/314409.html


Timo, any NAKs regarding this earlier patch? If you're at VDD this
week, maybe we can chat about it if you'd like.


The only remaining issue is the configure situation really.
No other obvious issues from my side.

It definitely needs to be sorted out properly.
Either configure needs to treat libvmaf_cuda like it is an entirely 
independent library (it's being added to --help output after all, which 
indicates to me that this is the intended approach).


Or it needs to be a sub-feature of libvmaf, where if libvmaf is enabled, 
support for CUDA is checked for, and then the vmaf_cuda filter needs to 
depend on that check.


All current patches had some kind of mix between the two.
___
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] Hi! We've been fuzzing `ffmpeg` with [sydr-fuzz](https://github.com/ispras/oss-sydr-fuzz) security predicates and we found numeric truncation error in `svs.c:57`.

[Andreas Rheinhardt]

mezhue...@ispras.ru:
> From: headshog 
> 
> In function `svs_read_header` on line 57 field `st->codecpar->sample_rate` 
> has type `int`, the type of return value in `av_rescale_rnd` function is 
> `uint64_t`, so the numeric truncation may occur here. Then value of 
> `st->codecpar->sample_rate` is passed to `avpriv_set_pts_info` function 
> parameter `unsgined int pts_den`. In this function `pts_den` is used only in 
> passing its value to parameter `int64_t den` in function `av_reduce`. So we 
> suggest to change the type of field `sample_rate` to `int64_t` and to change 
> the type of `pts_den` to `uint64_t` in `avpriv_set_pts_info` function. The 
> other way to solve this is to add a checker for `sample_rate` valid value.
> 
> - OS: ubuntu 20.04
> - commit: f225f8d7464569c7b917015c26ad30a37a5fbbe2
> 
> ```
> libavformat/svs.c:57:36: runtime error: implicit conversion from type 
> 'int64_t' (aka 'long') of value 6321554672 (64-bit, signed) to type 'int' 
> changed the value to 2026587376 (32-bit, signed)
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> libavformat/svs.c:57:36

Truncation via implicit conversions is not undefined behavior (but it
may be a bug).

- Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] FFmpeg release 6.1

[Kieran Kunhya]

>
> also iam not sure "experimental" is the right flag for code that has
> possible security issues. People might turn experimental on not realizing
> the security aspect.
>

We should make this clear in the docs then.

Kieran
___
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 PATCH 1/2] libavdevice/pipewiregrab: add pipewire based grab

[Leo Izen]

On 9/20/23 14:40, Abhishek Ojha wrote:

This is an proof of concept for pipewire grab to enable screen capture
on wayland. Add a new Linux capture based on [1] PipeWire and the
[2] Desktop portal.
This new capture starts by asking the Desktop portal for a screencapture
session.There are quite a few D-Bus calls involved in this, but the key
points are:

1. A connection to org.freedesktop.portal.ScreenCast is estabilished,
and the available cursor modes are updated. Currently only embedded
and hidden currsor mode enabled.

2. Call CreateSession via dbus call. This is the first step of the
communication. Response callback return the status of created
session.

3. Call SelectSources . This is when a system dialog pops up asking
the user to either select a monitor (desktop capture).Only monitor
capture is enabled in current implementation.

4. Call Start . This signals the compositor that it can setup a PipeWire
stream, and start sending buffers.

Above flow is implemented as per the [2] xdg-desktop-portal. Once flow
is completed, pipewire fd is received and using this pipewire stream is
created and receive buffer from the created stream.

For cursor implementation, embedded cursor mode is enabled that means
cursor metadata is not handled in current implementation and has no
control over the cursor bitmap.

gdbus/pipewire logic, this is based on obs-xdg, gstpipewire and
pipewire examples, and initial pipewire grab logic, this is based on
libavdevice/xcbgrab and libavdevice/v4l2

This implementation shows the skeleton implementation and enables basic
functionality. I'd like to hear opinions and suggestions to improve and
properly use this.

[1] https://pipewire.org/
[2] https://github.com/flatpak/xdg-desktop-portal/

Below are the arguments for pipewiregrab.
ffplay -f pipewiregrab -draw_mouse 1 -i :0.0

Signed-off-by: Abhishek Ojha 
---
  configure  |9 +
  libavdevice/Makefile   |1 +
  libavdevice/alldevices.c   |1 +
  libavdevice/pipewiregrab.c | 1836 
  4 files changed, 1847 insertions(+)
  create mode 100644 libavdevice/pipewiregrab.c

diff --git a/configure b/configure
index e40dcce09e..325b10484f 100755
--- a/configure
+++ b/configure
@@ -299,6 +299,7 @@ External library support:
--enable-libxcb-shm  enable X11 grabbing shm communication [autodetect]
--enable-libxcb-xfixes   enable X11 grabbing mouse rendering [autodetect]
--enable-libxcb-shapeenable X11 grabbing shape rendering [autodetect]
+  --enable-libpipewire enable screen grabbing using pipewire [autodetect]
--enable-libxvid enable Xvid encoding via xvidcore,
 native MPEG-4/Xvid encoder exists [no]
--enable-libxml2 enable XML parsing using the C library libxml2, 
needed
@@ -1788,6 +1789,8 @@ EXTERNAL_AUTODETECT_LIBRARY_LIST="
  libxcb_shm
  libxcb_shape
  libxcb_xfixes
+libpipewire
+libgio_unix
  lzma
  mediafoundation
  metal
@@ -3621,6 +3624,7 @@ v4l2_outdev_suggest="libv4l2"
  vfwcap_indev_deps="vfw32 vfwcap_defines"
  xcbgrab_indev_deps="libxcb"
  xcbgrab_indev_suggest="libxcb_shm libxcb_shape libxcb_xfixes"
+pipewiregrab_indev_deps="libpipewire libgio_unix pthreads"
  xv_outdev_deps="xlib_xv xlib_x11 xlib_xext"
  
  # protocols

@@ -7041,6 +7045,11 @@ if enabled libxcb; then
  enabled libxcb_xfixes && check_pkg_config libxcb_xfixes xcb-xfixes 
xcb/xfixes.h xcb_xfixes_get_cursor_image
  fi
  
+enabled libpipewire && check_pkg_config libpipewire "libpipewire-0.3 >= 0.3.40" pipewire/pipewire.h pw_init

+if enabled libpipewire; then
+enabled libgio_unix && check_pkg_config libgio_unix gio-unix-2.0 gio/gio.h 
g_main_loop_new
+fi
+
  check_func_headers "windows.h" CreateDIBSection "$gdigrab_indev_extralibs"
  
  # d3d11va requires linking directly to dxgi and d3d11 if not building for

diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index c30449201d..f02960782d 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -49,6 +49,7 @@ OBJS-$(CONFIG_V4L2_INDEV)+= v4l2.o 
v4l2-common.o timefilter.o
  OBJS-$(CONFIG_V4L2_OUTDEV)   += v4l2enc.o v4l2-common.o
  OBJS-$(CONFIG_VFWCAP_INDEV)  += vfwcap.o
  OBJS-$(CONFIG_XCBGRAB_INDEV) += xcbgrab.o
+OBJS-$(CONFIG_PIPEWIREGRAB_INDEV)+= pipewiregrab.o
  OBJS-$(CONFIG_XV_OUTDEV) += xv.o
  
  # external libraries

diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
index 8a90fcb5d7..1fa8563df4 100644
--- a/libavdevice/alldevices.c
+++ b/libavdevice/alldevices.c
@@ -53,6 +53,7 @@ extern const AVInputFormat  ff_v4l2_demuxer;
  extern const FFOutputFormat ff_v4l2_muxer;
  extern const AVInputFormat  ff_vfwcap_demuxer;
  extern const AVInputFormat  ff_xcbgrab_demuxer;
+extern const AVInputFormat  ff_pipewiregrab_demuxer;
  extern const FFOutputFormat ff_xv_muxer;
  
  /* external libraries */

diff --git 

Re: [FFmpeg-devel] [PATCH] avfilter: add libvmaf_cuda

[Kyle Swanson]

Hi,

On Mon, Sep 18, 2023 at 2:39 PM Kyle Swanson  wrote:
>
> Hi,
>
> On Mon, Sep 18, 2023 at 12:41 PM Timo Rothenpieler
>  wrote:
> > On 18.09.2023 21:21, Marvin Scholz wrote:
> > > I am far from an expert with the configure script but won't that cause 
> > > --enable-libvmaf to fail when
> > > libvmaf is built without cuda support? Which seems undesirable to me…
> >
> > Yeah, hence my suggested change of
> >
> > > enabled libvmaf_cuda  && require_pkg_config libvmaf_cuda "libvmaf >= 
> > > 2.0.0" libvmaf_cuda.h vmaf_cuda_state_init
>
> This only works if I add `libvmaf_cuda` to EXTERNAL_LIBRARY_LIST,
> otherwise running `./configure --enable-libvmaf-cuda` will fail with
> `Unknown option "--enable-libvmaf-cuda".` I'm not sure that's the
> right thing to do given there is no such thing as `libvmaf_cuda`. If
> you are aware of a different way of handling this, let me know. Most
> of the other libraries we link with optional configurations (see
> libopus, libvpx, ...) seem to have the pattern I used in this previous
> patch [0], which does avoid the problem pointed out by Marvin.
>
> Thanks,
> Kyle
>
> [0] http://ffmpeg.org/pipermail/ffmpeg-devel/2023-September/314409.html

Timo, any NAKs regarding this earlier patch? If you're at VDD this
week, maybe we can chat about it if you'd like.

Thanks,
Kyle
___
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 17/42] avcodec/refstruct: Add RefStruct pool API

[Michael Niedermayer]

On Tue, Sep 19, 2023 at 09:57:09PM +0200, Andreas Rheinhardt wrote:
> Very similar to the AVBufferPool API, but with some differences:
> 1. Reusing an already existing entry does not incur an allocation
> at all any more (the AVBufferPool API needs to allocate an AVBufferRef).
> 2. The tasks done while holding the lock are smaller; e.g.
> allocating new entries is now performed without holding the lock.
> The same goes for freeing.
> 3. The entries are freed as soon as possible (the AVBufferPool API
> frees them in two batches: The first in av_buffer_pool_uninit() and
> the second immediately before the pool is freed when the last
> outstanding entry is returned to the pool).
> 4. The API is designed for objects and not naked buffers and
> therefore has a reset callback. This is called whenever an object
> is returned to the pool.
> 5. Just like with the RefStruct API, custom allocators are not
> supported.
> 
> (If desired, the FFRefStructPool struct itself could be made
> reference counted via the RefStruct API; an FFRefStructPool
> would then be freed via ff_refstruct_unref().)
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/refstruct.c | 194 -
>  libavcodec/refstruct.h | 128 +++
>  2 files changed, 321 insertions(+), 1 deletion(-)

seems to break building on ppc (--disable-pthreads)

CC  libavcodec/refstruct.o
src/libavcodec/refstruct.c: In function ‘pool_free’:
src/libavcodec/refstruct.c:187:5: error: implicit declaration of function 
‘pthread_mutex_destroy’; did you mean ‘ff_mutex_destroy’? 
[-Werror=implicit-function-declaration]
 pthread_mutex_destroy(>mutex);
 ^
 ff_mutex_destroy
src/libavcodec/refstruct.c: In function ‘pool_return_entry’:
src/libavcodec/refstruct.c:205:5: error: implicit declaration of function 
‘pthread_mutex_lock’; did you mean ‘ff_mutex_lock’? 
[-Werror=implicit-function-declaration]
 pthread_mutex_lock(>mutex);
 ^~
 ff_mutex_lock
src/libavcodec/refstruct.c:211:5: error: implicit declaration of function 
‘pthread_mutex_unlock’; did you mean ‘ff_mutex_unlock’? 
[-Werror=implicit-function-declaration]
 pthread_mutex_unlock(>mutex);
 ^~~~
 ff_mutex_unlock
src/libavcodec/refstruct.c: In function ‘ff_refstruct_pool_alloc_ext_c’:
src/libavcodec/refstruct.c:339:11: error: implicit declaration of function 
‘pthread_mutex_init’; did you mean ‘ff_mutex_init’? 
[-Werror=implicit-function-declaration]
 err = pthread_mutex_init(>mutex, NULL);
   ^~
   ff_mutex_init
cc1: some warnings being treated as errors
/home/michael/ffmpeg-git/ffmpeg/ffbuild/common.mak:81: recipe for target 
'libavcodec/refstruct.o' failed
make: *** [libavcodec/refstruct.o] Error 1
make: Target 'all' not remade because of errors.


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


signature.asc
Description: PGP signature
___
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 35/42] avcodec/threadprogress: Add new API for frame-threaded progress

[Michael Niedermayer]

On Tue, Sep 19, 2023 at 09:57:27PM +0200, Andreas Rheinhardt wrote:
> The API is very similar by the ProgressFrame API, with the exception
> that it no longer has an included AVFrame. Instead one can wait
> on anything via a ThreadProgress. One just has to ensure that
> the lifetime of the object containing the ThreadProgress is long
> enough (the corresponding problem for ProgressFrames is solved
> by allocating the progress and giving each thread a reference
> to it). This will typically be solved by putting a ThreadProgress
> in a refcounted structure that is shared between threads.
> It will be put to the test in the following commits.
> 
> An alternative to the check for whether the owner exists
> (meaning "do we use frame-threading?") would be to initialize
> the progress to INT_MAX in case frame threading is not in use.
> This would probably be preferable on arches where atomic reads
> are cheap (like x86), but are there ones where it is not?
> 
> One could also (guarded by e.g. an ASSERT_LEVEL check) actually
> track the progress for non-framethreading, too, in order to
> track errors even in single-threaded mode.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/pthread_frame.c  | 50 +
>  libavcodec/threadprogress.h | 37 +++
>  2 files changed, 87 insertions(+)
>  create mode 100644 libavcodec/threadprogress.h

Seems to break build here with shared libs / clang

CC  libavcodec/pthread_frame.o
src/libavcodec/pthread_frame.c:1108:9: error: address argument to atomic 
operation must be a pointer to non-const _Atomic type ('const atomic_int *' 
(aka 'const _Atomic(int) *') invalid)
atomic_load_explicit(>progress, memory_order_acquire) >= n)
^~~
/usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:135:30: note: expanded 
from macro 'atomic_load_explicit'
#define atomic_load_explicit __c11_atomic_load
 ^
src/libavcodec/pthread_frame.c:1116:12: error: address argument to atomic 
operation must be a pointer to non-const _Atomic type ('const atomic_int *' 
(aka 'const _Atomic(int) *') invalid)
while (atomic_load_explicit(>progress, memory_order_relaxed) < n)
   ^~~
/usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:135:30: note: expanded 
from macro 'atomic_load_explicit'
#define atomic_load_explicit __c11_atomic_load
 ^
2 errors generated.
src/ffbuild/common.mak:81: recipe for target 'libavcodec/pthread_frame.o' failed
make: *** [libavcodec/pthread_frame.o] Error 1
make: Target 'all' not remade because of errors.


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


signature.asc
Description: PGP signature
___
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] [RFC PATCH 1/2] libavdevice/pipewiregrab: add pipewire based grab

[Abhishek Ojha]

This is an proof of concept for pipewire grab to enable screen capture
on wayland. Add a new Linux capture based on [1] PipeWire and the
[2] Desktop portal.
This new capture starts by asking the Desktop portal for a screencapture
session.There are quite a few D-Bus calls involved in this, but the key
points are:

1. A connection to org.freedesktop.portal.ScreenCast is estabilished,
   and the available cursor modes are updated. Currently only embedded
   and hidden currsor mode enabled.

2. Call CreateSession via dbus call. This is the first step of the
   communication. Response callback return the status of created
   session.

3. Call SelectSources . This is when a system dialog pops up asking
   the user to either select a monitor (desktop capture).Only monitor
   capture is enabled in current implementation.

4. Call Start . This signals the compositor that it can setup a PipeWire
   stream, and start sending buffers.

Above flow is implemented as per the [2] xdg-desktop-portal. Once flow
is completed, pipewire fd is received and using this pipewire stream is
created and receive buffer from the created stream.

For cursor implementation, embedded cursor mode is enabled that means
cursor metadata is not handled in current implementation and has no
control over the cursor bitmap.

gdbus/pipewire logic, this is based on obs-xdg, gstpipewire and
pipewire examples, and initial pipewire grab logic, this is based on
libavdevice/xcbgrab and libavdevice/v4l2

This implementation shows the skeleton implementation and enables basic
functionality. I'd like to hear opinions and suggestions to improve and
properly use this.

[1] https://pipewire.org/
[2] https://github.com/flatpak/xdg-desktop-portal/

Below are the arguments for pipewiregrab.
ffplay -f pipewiregrab -draw_mouse 1 -i :0.0

Signed-off-by: Abhishek Ojha 
---
 configure  |9 +
 libavdevice/Makefile   |1 +
 libavdevice/alldevices.c   |1 +
 libavdevice/pipewiregrab.c | 1836 
 4 files changed, 1847 insertions(+)
 create mode 100644 libavdevice/pipewiregrab.c

diff --git a/configure b/configure
index e40dcce09e..325b10484f 100755
--- a/configure
+++ b/configure
@@ -299,6 +299,7 @@ External library support:
   --enable-libxcb-shm  enable X11 grabbing shm communication [autodetect]
   --enable-libxcb-xfixes   enable X11 grabbing mouse rendering [autodetect]
   --enable-libxcb-shapeenable X11 grabbing shape rendering [autodetect]
+  --enable-libpipewire enable screen grabbing using pipewire [autodetect]
   --enable-libxvid enable Xvid encoding via xvidcore,
native MPEG-4/Xvid encoder exists [no]
   --enable-libxml2 enable XML parsing using the C library libxml2, 
needed
@@ -1788,6 +1789,8 @@ EXTERNAL_AUTODETECT_LIBRARY_LIST="
 libxcb_shm
 libxcb_shape
 libxcb_xfixes
+libpipewire
+libgio_unix
 lzma
 mediafoundation
 metal
@@ -3621,6 +3624,7 @@ v4l2_outdev_suggest="libv4l2"
 vfwcap_indev_deps="vfw32 vfwcap_defines"
 xcbgrab_indev_deps="libxcb"
 xcbgrab_indev_suggest="libxcb_shm libxcb_shape libxcb_xfixes"
+pipewiregrab_indev_deps="libpipewire libgio_unix pthreads"
 xv_outdev_deps="xlib_xv xlib_x11 xlib_xext"
 
 # protocols
@@ -7041,6 +7045,11 @@ if enabled libxcb; then
 enabled libxcb_xfixes && check_pkg_config libxcb_xfixes xcb-xfixes 
xcb/xfixes.h xcb_xfixes_get_cursor_image
 fi
 
+enabled libpipewire && check_pkg_config libpipewire "libpipewire-0.3 >= 
0.3.40" pipewire/pipewire.h pw_init
+if enabled libpipewire; then
+enabled libgio_unix && check_pkg_config libgio_unix gio-unix-2.0 gio/gio.h 
g_main_loop_new
+fi
+
 check_func_headers "windows.h" CreateDIBSection "$gdigrab_indev_extralibs"
 
 # d3d11va requires linking directly to dxgi and d3d11 if not building for
diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index c30449201d..f02960782d 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -49,6 +49,7 @@ OBJS-$(CONFIG_V4L2_INDEV)+= v4l2.o 
v4l2-common.o timefilter.o
 OBJS-$(CONFIG_V4L2_OUTDEV)   += v4l2enc.o v4l2-common.o
 OBJS-$(CONFIG_VFWCAP_INDEV)  += vfwcap.o
 OBJS-$(CONFIG_XCBGRAB_INDEV) += xcbgrab.o
+OBJS-$(CONFIG_PIPEWIREGRAB_INDEV)+= pipewiregrab.o
 OBJS-$(CONFIG_XV_OUTDEV) += xv.o
 
 # external libraries
diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
index 8a90fcb5d7..1fa8563df4 100644
--- a/libavdevice/alldevices.c
+++ b/libavdevice/alldevices.c
@@ -53,6 +53,7 @@ extern const AVInputFormat  ff_v4l2_demuxer;
 extern const FFOutputFormat ff_v4l2_muxer;
 extern const AVInputFormat  ff_vfwcap_demuxer;
 extern const AVInputFormat  ff_xcbgrab_demuxer;
+extern const AVInputFormat  ff_pipewiregrab_demuxer;
 extern const FFOutputFormat ff_xv_muxer;
 
 /* external libraries */
diff --git a/libavdevice/pipewiregrab.c b/libavdevice/pipewiregrab.c
new file mode 100644
index 

[FFmpeg-devel] [RFC PATCH 2/2] configure: disable locale use in spa plugin

[Abhishek Ojha]

This commit requires to resolve the compilation error of pipewiregrab
because Pipewire's spa plugin is requesting locale_t extension to
compile.
Which was added in POSIX 2008 but ffmpeg is using POSIX 2001 due to
which spa plugin complains. __LOCALE_C_ONLY flag is set to disable
the locale usage in spa plugin. Adding it in configure file fix both
the library test and source compilation issue.
Not sure if this is the right approach to fix the issue.
Feedback/Suggestions will be highly appreciated.

Signed-off-by: Abhishek Ojha 
---
 configure | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configure b/configure
index 325b10484f..e14a8e5bcb 100755
--- a/configure
+++ b/configure
@@ -7045,6 +7045,8 @@ if enabled libxcb; then
 enabled libxcb_xfixes && check_pkg_config libxcb_xfixes xcb-xfixes 
xcb/xfixes.h xcb_xfixes_get_cursor_image
 fi
 
+# _POSIX_C_SOURCE=200112 doesn't support locale
+add_cppflags -D__LOCALE_C_ONLY
 enabled libpipewire && check_pkg_config libpipewire "libpipewire-0.3 >= 
0.3.40" pipewire/pipewire.h pw_init
 if enabled libpipewire; then
 enabled libgio_unix && check_pkg_config libgio_unix gio-unix-2.0 gio/gio.h 
g_main_loop_new
-- 
2.34.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] FFmpeg release 6.1

[Michael Niedermayer]

On Wed, Sep 20, 2023 at 06:43:18PM +0100, Kieran Kunhya wrote:
> >
> > I dont suggest merging more EVC code before the release. I meant the
> > EVC code already in git, is reading alot of things with no checks.
> > It maybe doesnt matter in most cases, as its not used in most cases without
> > more EVC code but still
> > Also ATM other things are blocking so EVC still could make it in principle.
> > Just that the release should not be delayed because of addition of more
> > EVC code
> > But someone needs to check the existing EVC code in git without checks is
> > safe
> >
> 
> Or just mark EVC as experimental?

thats an option but even now, before we even have a experimental decoder in
git we already had a out of array write issue caused by evc code
so we still need to be carefull as not everything is under these checks

also iam not sure "experimental" is the right flag for code that has
possible security issues. People might turn experimental on not realizing
the security aspect.

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


signature.asc
Description: PGP signature
___
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] FFmpeg release 6.1

[Michael Niedermayer]

On Wed, Sep 20, 2023 at 02:47:19PM +0200, Niklas Haas wrote:
> On Tue, 19 Sep 2023 21:16:08 +0200 Michael Niedermayer 
>  wrote:
> > what about merging libplacebo into FFmpeg for example ?
> > As far as iam concerned you can have absolute final power about anything
> > in that libplacebo inside FFmpeg.
> 
> To respond quickly to this point,
> 
> I'm not sure what merging libplacebo would improve to the status quo. As

Code in libavfilter could more deeply depend on / integrate with libplacebo


> far as I can tell, it would only make my life harder, at least if you
> expect me to start caring about patches sent to the mailing list (as
> opposed to using PR/MRs as I do currently).

Well, _I_ dont mind how you manage libplacebo.


> 
> I'm not sure what the goal would be, either, except dragging more code
> into FFmpeg. Code that can easily live outside it, because the degree of
> interoperation between the two is minimal. All relevant distros already
> package both libplacebo and FFmpeg, so the "ease of distribution" ship
> has sailed.

Well the goal is to have some sort of lib that unifies swscale, libplacebo
and similar into code that provides high performance, high quality, CPU and
GPU based convertion. And this really needs to be "close" to libavfilter if
libavfilter would use it.


> 
> It would also make libplacebo releases now tied to FFmpeg releases,
> which is an obvious downgrade for my own reverse dependents and a
> significant downgrade to my current release process.

We must avoid downgrades


> The FFmpeg ABI
> policy also seems wholly incompatible with the libplacebo ABI policy.

i am not sure what the libplacebo ABI policy is

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


signature.asc
Description: PGP signature
___
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] FFmpeg release 6.1

[Kieran Kunhya]

>
> I dont suggest merging more EVC code before the release. I meant the
> EVC code already in git, is reading alot of things with no checks.
> It maybe doesnt matter in most cases, as its not used in most cases without
> more EVC code but still
> Also ATM other things are blocking so EVC still could make it in principle.
> Just that the release should not be delayed because of addition of more
> EVC code
> But someone needs to check the existing EVC code in git without checks is
> safe
>

Or just mark EVC as experimental?

Kieran
___
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] FFmpeg release 6.1

[Michael Niedermayer]

On Tue, Sep 19, 2023 at 11:58:41PM +0200, Lynne wrote:
> Sep 19, 2023, 21:16 by mich...@niedermayer.cc:
> 
> > On Tue, Sep 19, 2023 at 07:18:03PM +0200, Niklas Haas wrote:
> >
> >> On Tue, 11 Apr 2023 00:14:28 +0200 Michael Niedermayer 
> >>  wrote:
> >> > Hi all
> >> > 
> >> > There was the request to make a 6.1 before end of April
> >> > Is that still so ?
> >> > 
> >> > Assuming it is, its time to make that branch and release soon
> >>
> >> Hi,
> >>
> >> It is now september. What happened to this release? FFmpeg 6.1 is
> >> currently the only thing blocking the adoption of vulkan video.
> >>
> >
> > there are several security issues that need to be fixed
> > ossfuzz found more, it also put some random unlreated issues again
> > into the same ticket. (which are basically invissible sub-tickets)
> > the evc code also needs a security review, Maybe Dawid is working on this
> > iam not sure. And iam sure theres more
> > We also have a security issue in fate, i belive nicolas is looking into
> > that, that doesnt hold up the release but all these things compete for time
> > and some people you may have noticed tried to just randomly block patches
> > going back and forth on these and discussing with tech/community committtees
> > also took time.
> > And last but not least if people want me to design a standalone SDR library
> > while thats not holding up 6.1 it takes time from the pot from 6.1 work.
> > I did say this, i was attacked but yes time is unforgiving it doesnt care
> >
> > Also I did fall behind with security fixes in the summer a bit, the weather 
> > was
> > nice, some members of the community where not nice. So i tried to spend some
> > time with the nice weather
> >
> > If you want 6.1 to happen quick. be nice to me or help with anything that i
> > have to work on 6.1 or other so theres more time in the pot
> > what about merging libplacebo into FFmpeg for example ?
> > As far as iam concerned you can have absolute final power about anything
> > in that libplacebo inside FFmpeg.
> > Or help with the whole SDR thing. If i dont have to think about it and
> > can concentrate on the release and security then yes it will happen faster
> >
> > I also have some paid work under NDA which i signed a contract for, i need
> > to work on that too. Yes code will be submitted to FFmpeg when/if its done
> > And theres life, i have other shit to do too. For example my taxes and i 
> > also
> > want to spend some time working on AI/neural nets. I guess that will not be
> > FFmpeg related as id like my work on AI not to be in a similar position to
> > where avradio is now.
> >
> > So yeah, i think theres no problem with 6.1 its just not happening as quick
> > as I and others wanted
> >
> > thx
> >
> > [...]
> > -- 
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > If you think the mosad wants you dead since a long time then you are either
> > wrong or dead since a long time.
> >
> 
> I'm not sure it's a good idea to wait to merge the EVC decoder.
> Perhaps we should move that to the next release.

I dont suggest merging more EVC code before the release. I meant the
EVC code already in git, is reading alot of things with no checks.
It maybe doesnt matter in most cases, as its not used in most cases without
more EVC code but still
Also ATM other things are blocking so EVC still could make it in principle.
Just that the release should not be delayed because of addition of more EVC code
But someone needs to check the existing EVC code in git without checks is safe


> 
> I'd like to get my AAC padding/duration fixes in, and drop lavc's
> old FFT code entirely.

fine

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


signature.asc
Description: PGP signature
___
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] TRAC Spam

[Michael Niedermayer]

On Wed, Sep 20, 2023 at 05:28:29PM +0200, Paul B Mahol wrote:
> On Wed, Sep 20, 2023 at 4:33 PM Michael Niedermayer 
> wrote:
> 
> > On Wed, Sep 20, 2023 at 02:30:20PM +0200, Paul B Mahol wrote:
> > > On Wed, Sep 20, 2023 at 1:46 PM Michael Koch <
> > astroelectro...@t-online.de>
> > > wrote:
> > >
> > > > Ticket / Comment
> > > > 1920 / 12
> > > >
> > > Remove that nick once and for all.
> >
> > No user with the nick "that" has been found
> >
> 
> Bad joke, I obviously meant nick that wrote such comments.
> As apparently this is not first comment by that nick.

I cant delete unspecified nicks. And i cant check what nick wrote
a comment thats no longer there.

Best is to simply spell the nick out to be deleted next time.

But i expect her to come back once shes deleted, this is not her first
nick, i have already deleted her a few days ago, so iam not sure deleting it 
helps.
ATM i suspect she will give up and go away when her spam doesnt stick
or the bayesian filter / akismet will catch on to this style of spam
if not we can take a closer look and find another solution to block this

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


signature.asc
Description: PGP signature
___
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] avfilter/vf_smartblur: pass old context to sws_getCachedContext

[Zhao Zhili]

On Fri, 2023-09-15 at 23:16 +0800, Zhao Zhili wrote:
> From: Zhao Zhili 
> 
> Otherwise it make no sense to use sws_getCachedContext.
> ---
>  libavfilter/vf_smartblur.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavfilter/vf_smartblur.c b/libavfilter/vf_smartblur.c
> index 85d8d502e1..ae0ec05b2d 100644
> --- a/libavfilter/vf_smartblur.c
> +++ b/libavfilter/vf_smartblur.c
> @@ -136,7 +136,7 @@ static int alloc_sws_context(FilterParam *f, int
> width, int height, unsigned int
>  vec->coeff[vec->length / 2] += 1.0 - f->strength;
>  sws_filter.lumH = sws_filter.lumV = vec;
>  sws_filter.chrH = sws_filter.chrV = NULL;
> -    f->filter_context = sws_getCachedContext(NULL,
> +    f->filter_context = sws_getCachedContext(f->filter_context,
>   width, height,
> AV_PIX_FMT_GRAY8,
>   width, height,
> AV_PIX_FMT_GRAY8,
>   flags, _filter,
> NULL, NULL);

Pushed.
___
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] TRAC Spam

[Paul B Mahol]

On Wed, Sep 20, 2023 at 4:33 PM Michael Niedermayer 
wrote:

> On Wed, Sep 20, 2023 at 02:30:20PM +0200, Paul B Mahol wrote:
> > On Wed, Sep 20, 2023 at 1:46 PM Michael Koch <
> astroelectro...@t-online.de>
> > wrote:
> >
> > > Ticket / Comment
> > > 1920 / 12
> > >
> > Remove that nick once and for all.
>
> No user with the nick "that" has been found
>

Bad joke, I obviously meant nick that wrote such comments.
As apparently this is not first comment by that nick.


>
> sorry
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Republics decline into democracies and democracies degenerate into
> despotisms. -- Aristotle
> ___
> 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] [RFC/PATCH] ffmpeg CLI multithreading

[Michael Niedermayer]

Hi

On Tue, Sep 19, 2023 at 09:10:27PM +0200, Anton Khirnov wrote:
[...]
> You can fetch the code from the 'ffmpeg_threading' branch in
> git://git.khirnov.net/libav. I will also present a short talk about this
> work at VDD. Comments, questions, suggestions, etc. are very much
> welcome, both here and there.

please record the talk and make it available for people who arent physically
or virtually there at the time

Thx!

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


signature.asc
Description: PGP signature
___
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] TRAC Spam

[Michael Niedermayer]

On Wed, Sep 20, 2023 at 02:30:20PM +0200, Paul B Mahol wrote:
> On Wed, Sep 20, 2023 at 1:46 PM Michael Koch 
> wrote:
> 
> > Ticket / Comment
> > 1920 / 12
> >
> Remove that nick once and for all.

No user with the nick "that" has been found

sorry

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


signature.asc
Description: PGP signature
___
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] TRAC Spam

[Michael Niedermayer]

On Wed, Sep 20, 2023 at 01:46:45PM +0200, Michael Koch wrote:
> Ticket / Comment
> 1920 / 12

The ticket comment 12 on ticket #1920 has been deleted.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
than the original author, trying to rewrite it will not make it better.


signature.asc
Description: PGP signature
___
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] FFmpeg release 6.1

[Niklas Haas]

On Tue, 19 Sep 2023 21:16:08 +0200 Michael Niedermayer  
wrote:
> what about merging libplacebo into FFmpeg for example ?
> As far as iam concerned you can have absolute final power about anything
> in that libplacebo inside FFmpeg.

To respond quickly to this point,

I'm not sure what merging libplacebo would improve to the status quo. As
far as I can tell, it would only make my life harder, at least if you
expect me to start caring about patches sent to the mailing list (as
opposed to using PR/MRs as I do currently).

I'm not sure what the goal would be, either, except dragging more code
into FFmpeg. Code that can easily live outside it, because the degree of
interoperation between the two is minimal. All relevant distros already
package both libplacebo and FFmpeg, so the "ease of distribution" ship
has sailed.

It would also make libplacebo releases now tied to FFmpeg releases,
which is an obvious downgrade for my own reverse dependents and a
significant downgrade to my current release process. The FFmpeg ABI
policy also seems wholly incompatible with the libplacebo ABI policy.

___
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] Hi! We've been fuzzing `ffmpeg` with [sydr-fuzz](https://github.com/ispras/oss-sydr-fuzz) security predicates and we found numeric truncation error in `svs.c:57`.

[mezhuevtp]

On 2023-09-20 15:29, Paul B Mahol wrote:

Unacceptable code changes as that Breaks ABI/API.
___
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".


Maybe then a checker for valid sample_rate value should be added to 
svs_read_header function?

___
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] TRAC Spam

[Paul B Mahol]

On Wed, Sep 20, 2023 at 1:46 PM Michael Koch 
wrote:

> Ticket / Comment
> 1920 / 12
>
Remove that nick once and for all.

>
>
>
>
> ___
> 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] Hi! We've been fuzzing `ffmpeg` with [sydr-fuzz](https://github.com/ispras/oss-sydr-fuzz) security predicates and we found numeric truncation error in `svs.c:57`.

[Paul B Mahol]

Unacceptable code changes as that Breaks ABI/API.
___
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] Hi! We've been fuzzing `ffmpeg` with [sydr-fuzz](https://github.com/ispras/oss-sydr-fuzz) security predicates and we found numeric truncation error in `svs.c:57`.

[mezhuevtp]

From: headshog 

In function `svs_read_header` on line 57 field `st->codecpar->sample_rate` has 
type `int`, the type of return value in `av_rescale_rnd` function is 
`uint64_t`, so the numeric truncation may occur here. Then value of 
`st->codecpar->sample_rate` is passed to `avpriv_set_pts_info` function 
parameter `unsgined int pts_den`. In this function `pts_den` is used only in 
passing its value to parameter `int64_t den` in function `av_reduce`. So we 
suggest to change the type of field `sample_rate` to `int64_t` and to change 
the type of `pts_den` to `uint64_t` in `avpriv_set_pts_info` function. The 
other way to solve this is to add a checker for `sample_rate` valid value.

- OS: ubuntu 20.04
- commit: f225f8d7464569c7b917015c26ad30a37a5fbbe2

```
libavformat/svs.c:57:36: runtime error: implicit conversion from type 'int64_t' 
(aka 'long') of value 6321554672 (64-bit, signed) to type 'int' changed the 
value to 2026587376 (32-bit, signed)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior libavformat/svs.c:57:36
```
---
 libavcodec/codec_par.h | 2 +-
 libavformat/internal.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/codec_par.h b/libavcodec/codec_par.h
index add90fdb1e..2bbb7ba4e7 100644
--- a/libavcodec/codec_par.h
+++ b/libavcodec/codec_par.h
@@ -175,7 +175,7 @@ typedef struct AVCodecParameters {
 /**
  * Audio only. The number of audio samples per second.
  */
-int  sample_rate;
+int64_t  sample_rate;
 /**
  * Audio only. The number of bytes per coded audio frame, required by some
  * formats.
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 901a8b51c6..6e1fce41aa 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -584,7 +584,7 @@ const struct AVCodec *ff_find_decoder(AVFormatContext *s, 
const AVStream *st,
  * @param pts_den time base denominator
  */
 void avpriv_set_pts_info(AVStream *st, int pts_wrap_bits,
- unsigned int pts_num, unsigned int pts_den);
+ unsigned int pts_num, uint64_t pts_den);
 
 /**
  * Set the timebase for each stream from the corresponding codec timebase and
-- 
2.25.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] TRAC Spam

[Michael Koch]

Ticket / Comment
1920 / 12




___
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 3/3] libavfilter/dnn: Initialze DNNData variables

[zhilizhao(赵志立)]

> On Sep 20, 2023, at 10:26, wenbin.chen-at-intel@ffmpeg.org wrote:
> 
> From: Wenbin Chen 
> 
> Signed-off-by: Wenbin Chen 
> ---
> libavfilter/dnn/dnn_backend_tf.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavfilter/dnn/dnn_backend_tf.c 
> b/libavfilter/dnn/dnn_backend_tf.c
> index b521de7fbe..e1e8cef0d2 100644
> --- a/libavfilter/dnn/dnn_backend_tf.c
> +++ b/libavfilter/dnn/dnn_backend_tf.c
> @@ -629,6 +629,7 @@ static int fill_model_input_tf(TFModel *tf_model, 
> TFRequestItem *request) {
> TFContext *ctx = _model->ctx;
> int ret = 0;
> 
> +memset(, 0, sizeof(input));

Can be simplified with DNNData input = { 0 };

> lltask = ff_queue_pop_front(tf_model->lltask_queue);
> av_assert0(lltask);
> task = lltask->task;
> @@ -724,7 +725,7 @@ static void infer_completion_callback(void *args) {
> TFModel *tf_model = task->model;
> TFContext *ctx = _model->ctx;
> 
> -outputs = av_malloc_array(task->nb_output, sizeof(*outputs));
> +outputs = av_calloc(task->nb_output, sizeof(*outputs));
> if (!outputs) {
> av_log(ctx, AV_LOG_ERROR, "Failed to allocate memory for *outputs\n");
> goto err;
> -- 
> 2.34.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 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".