Re: [FFmpeg-devel] [PATCH, v3] lavu/hwcontext_qsv: Fix the realign check for hwupload
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Linjie Fu
> Sent: Monday, April 15, 2019 9:24 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [FFmpeg-devel] [PATCH, v3] lavu/hwcontext_qsv: Fix the realign
> check for hwupload
>
> Fix the aligned check in hwupload, input surface should be 16 aligned too.
>
> Fix #7830.
>
> Signed-off-by: Linjie Fu
> ---
> libavutil/hwcontext_qsv.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c index
> b6d8bfe2bf..197dd8002a 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -891,8 +891,7 @@ static int
> qsv_transfer_data_to(AVHWFramesContext *ctx, AVFrame *dst,
> if (ret < 0)
> return ret;
>
> -
> -if (src->height & 16 || src->linesize[0] & 16) {
> +if (src->height & 15 || src->linesize[0] & 15) {
> realigned = 1;
> memset(_frame, 0, sizeof(tmp_frame));
> tmp_frame.format = src->format;
> --
> 2.17.1
LGTM, will apply.
___
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] [DECISION] Project policy on closed source components
On 29-04-2019 05:37 AM, Marton Balint wrote: On Sun, 28 Apr 2019, Marton Balint wrote: Hi All, There has been discussion on the mailing list several times about the inclusion of support for closed source components (codecs, formats, filters, etc) in the main ffmpeg codebase. Also the removal of libNDI happened without general consensus, so a vote is necessary to justify the removal. So here is a call to the voting committee [1] to decide on the following two questions: 1) Should libNDI support be removed from the ffmpeg codebase? 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? I revoke the vote request on the 2nd question (some invalid references and ambiguity was pointed out in it), please only vote on the 1st. Second question will be rephrased and submitted to a vote later, in a different thread. For those new to voting, what's the procedure? Gyan ___ 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] libavfilter: Add more operation supports in FFmpeg dnn native mode.
> -原始邮件- > 发件人: "Pedro Arthur" > 发送时间: 2019-04-29 10:42:42 (星期一) > 收件人: "FFmpeg development discussions and patches" > 抄送: > 主题: Re: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in > FFmpeg dnn native mode. > > Em dom, 28 de abr de 2019 às 23:07, Guo, Yejun escreveu: > > > > > > > > > -Original Message- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of > > > xwm...@pku.edu.cn > > > Sent: Sunday, April 28, 2019 5:27 PM > > > To: ffmpeg development discussions and patches > > > Subject: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports > > > in > > > FFmpeg dnn native mode. > > > > > > This patch is for the support of derain filter project in GSoC. It adds > > > supports for > > > the following operations: > > > > > > > > > > > > > > > (1) Conv padding method: "SAME" and "VALID" > > > > > > (2) Dilation > > > > > > (3) Activation: "NONE" and "LEAKY_RELU" > > > > how about separate this single patch into 3 patches. > > > > > > > > > > > > > > > > > These operations are all needed in derain filter. And if modify the dnn > > > native > > > mode in FFmpeg, the generation process of Super Resolution model should be > > > changed accordingly, e.g. add padding method parameter (= 0) and dilation > > > parameter (= 1). > > > > you can create a PR at https://github.com/HighVoltageRocknRoll/sr > > > > > > > > > > > > > > > > > In addition, I have a question about the Super Resulotion implementation. > > > The > > > model training process of SR uses "VALID" method. According to my > > > understanding of "VALID" mode in tensorflow, the size of output image > > > should > > > be smaller than the current design in SR. Because pixels near the > > > boundary are > > > not processed in "VALID" mode, however, these unprocessed pixels are > > > filled > > > with adjacent pixels in current dnn native mode. I wonder why to do like > > > this > > > here. > > > > I have the same concern that why the native model is not exactly the same > > as tf model, > > the pad layer is missed, and the native model also change the behavior of > > pad parameter of conv layer. > > > > it is only suitable for vf_sr, and not general for other models. > > > I think for training these filters the preferred method is VALID as it > uses only the data available (without filling the borders) and gives > the best possible result. > However for inference usually one expects to output an image with the > same size of the original (imagine the case of chained filters where > each one reduces the image by a few pixels, in the end one may have a > useless output). > Therefore it makes perfect sense to use different padding methods for > training/inference. > > The clamp_to_edge padding was introduced before the TF backend thus it > stayed in the native backend even after the introduction of the TF > backend. > Indeed the clamp_to_edge is simpler than the other padding methods and > also gives a slight better result, If I remember correct the student > which implemented the TF backend did not find an equivalent padding > method in TF, thats why it uses different paddings. > Yes, I think clamp_to_edge is a good method to keep the output with the same size as input. However, I don't think "VALID" is the best method giving best possible result. So, for "VALID" mode, maybe we can use the clamp_to_edge method in the current dnn native mode? And then, we should also add "SAME" option to support other filters. > > > > > > > > > > > > > > > From 4d92ef21a5acf064122c51f442d0e2f5437b3343 Mon Sep 17 00:00:00 > > > 2001 > > > From: Xuewei Meng > > > Date: Sun, 28 Apr 2019 17:21:35 +0800 > > > Subject: [PATCH] Add operation supports in dnn_native > > > > > > Signed-off-by: Xuewei Meng > > > --- > > > libavfilter/dnn_backend_native.c | 36 +--- > > > libavfilter/dnn_backend_native.h | 6 +- > > > 2 files changed, 29 insertions(+), 13 deletions(-) > > > > > > diff --git a/libavfilter/dnn_backend_native.c > > > b/libavfilter/dnn_backend_native.c > > > index 70d857f5f2..0e3ef5d64d 100644 > > > --- a/libavfilter/dnn_backend_native.c > > > +++ b/libavfilter/dnn_backend_native.c > > > @@ -157,13 +157,15 @@ DNNModel *ff_dnn_load_model_native(const char > > > *model_filename) > > > ff_dnn_free_model_native(); > > > return NULL; > > > } > > > +conv_params->dilation = > > > (int32_t)avio_rl32(model_file_context); > > > +conv_params->padding_method = > > > (int32_t)avio_rl32(model_file_context); > > > conv_params->activation = > > > (int32_t)avio_rl32(model_file_context); > > > conv_params->input_num = > > > (int32_t)avio_rl32(model_file_context); > > > conv_params->output_num = > > > (int32_t)avio_rl32(model_file_context); > > > conv_params->kernel_size = > > > (int32_t)avio_rl32(model_file_context); > > >
Re: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in FFmpeg dnn native mode.
Em dom, 28 de abr de 2019 às 23:07, Guo, Yejun escreveu:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > xwm...@pku.edu.cn
> > Sent: Sunday, April 28, 2019 5:27 PM
> > To: ffmpeg development discussions and patches
> > Subject: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in
> > FFmpeg dnn native mode.
> >
> > This patch is for the support of derain filter project in GSoC. It adds
> > supports for
> > the following operations:
> >
> >
> >
> >
> > (1) Conv padding method: "SAME" and "VALID"
> >
> > (2) Dilation
> >
> > (3) Activation: "NONE" and "LEAKY_RELU"
>
> how about separate this single patch into 3 patches.
>
> >
> >
> >
> >
> > These operations are all needed in derain filter. And if modify the dnn
> > native
> > mode in FFmpeg, the generation process of Super Resolution model should be
> > changed accordingly, e.g. add padding method parameter (= 0) and dilation
> > parameter (= 1).
>
> you can create a PR at https://github.com/HighVoltageRocknRoll/sr
>
> >
> >
> >
> >
> > In addition, I have a question about the Super Resulotion implementation.
> > The
> > model training process of SR uses "VALID" method. According to my
> > understanding of "VALID" mode in tensorflow, the size of output image should
> > be smaller than the current design in SR. Because pixels near the boundary
> > are
> > not processed in "VALID" mode, however, these unprocessed pixels are filled
> > with adjacent pixels in current dnn native mode. I wonder why to do like
> > this
> > here.
>
> I have the same concern that why the native model is not exactly the same as
> tf model,
> the pad layer is missed, and the native model also change the behavior of pad
> parameter of conv layer.
>
> it is only suitable for vf_sr, and not general for other models.
>
I think for training these filters the preferred method is VALID as it
uses only the data available (without filling the borders) and gives
the best possible result.
However for inference usually one expects to output an image with the
same size of the original (imagine the case of chained filters where
each one reduces the image by a few pixels, in the end one may have a
useless output).
Therefore it makes perfect sense to use different padding methods for
training/inference.
The clamp_to_edge padding was introduced before the TF backend thus it
stayed in the native backend even after the introduction of the TF
backend.
Indeed the clamp_to_edge is simpler than the other padding methods and
also gives a slight better result, If I remember correct the student
which implemented the TF backend did not find an equivalent padding
method in TF, thats why it uses different paddings.
> >
> >
> >
> >
> > From 4d92ef21a5acf064122c51f442d0e2f5437b3343 Mon Sep 17 00:00:00
> > 2001
> > From: Xuewei Meng
> > Date: Sun, 28 Apr 2019 17:21:35 +0800
> > Subject: [PATCH] Add operation supports in dnn_native
> >
> > Signed-off-by: Xuewei Meng
> > ---
> > libavfilter/dnn_backend_native.c | 36 +---
> > libavfilter/dnn_backend_native.h | 6 +-
> > 2 files changed, 29 insertions(+), 13 deletions(-)
> >
> > diff --git a/libavfilter/dnn_backend_native.c
> > b/libavfilter/dnn_backend_native.c
> > index 70d857f5f2..0e3ef5d64d 100644
> > --- a/libavfilter/dnn_backend_native.c
> > +++ b/libavfilter/dnn_backend_native.c
> > @@ -157,13 +157,15 @@ DNNModel *ff_dnn_load_model_native(const char
> > *model_filename)
> > ff_dnn_free_model_native();
> > return NULL;
> > }
> > +conv_params->dilation =
> > (int32_t)avio_rl32(model_file_context);
> > +conv_params->padding_method =
> > (int32_t)avio_rl32(model_file_context);
> > conv_params->activation =
> > (int32_t)avio_rl32(model_file_context);
> > conv_params->input_num =
> > (int32_t)avio_rl32(model_file_context);
> > conv_params->output_num =
> > (int32_t)avio_rl32(model_file_context);
> > conv_params->kernel_size =
> > (int32_t)avio_rl32(model_file_context);
> > kernel_size = conv_params->input_num *
> > conv_params->output_num *
> >conv_params->kernel_size *
> > conv_params->kernel_size;
> > -dnn_size += 16 + (kernel_size + conv_params->output_num <<
> > 2);
> > +dnn_size += 24 + (kernel_size + conv_params->output_num <<
> > 2);
> > if (dnn_size > file_size || conv_params->input_num <= 0 ||
> > conv_params->output_num <= 0 ||
> > conv_params->kernel_size <= 0){
> > avio_closep(_file_context);
> > @@ -221,23 +223,28 @@ DNNModel *ff_dnn_load_model_native(const char
> > *model_filename)
> >
> > static void convolve(const float *input, float *output, const
> > ConvolutionalParams *conv_params, int width, int height)
> > {
> > -int y, x, n_filter, ch, kernel_y, kernel_x;
> > int radius
Re: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in FFmpeg dnn native mode.
> -原始邮件-
> 发件人: "Guo, Yejun"
> 发送时间: 2019-04-29 10:03:43 (星期一)
> 收件人: "FFmpeg development discussions and patches"
> 抄送:
> 主题: Re: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in
> FFmpeg dnn native mode.
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > xwm...@pku.edu.cn
> > Sent: Sunday, April 28, 2019 5:27 PM
> > To: ffmpeg development discussions and patches
> > Subject: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in
> > FFmpeg dnn native mode.
> >
> > This patch is for the support of derain filter project in GSoC. It adds
> > supports for
> > the following operations:
> >
> >
> >
> >
> > (1) Conv padding method: "SAME" and "VALID"
> >
> > (2) Dilation
> >
> > (3) Activation: "NONE" and "LEAKY_RELU"
>
> how about separate this single patch into 3 patches.
So, first, we can seperate this single patch into 3 patches ('padding',
'dilation', and 'activation'). For 'padding', we can support 3 parameters,
same, valid, and the extra same_clamp_to_edge used in sr. And for "Dilation"
and "padding" patch, the generation process of sr should be changed and we can
create a PR at https://github.com/HighVoltageRocknRoll/sr.
>
> >
> >
> >
> >
> > These operations are all needed in derain filter. And if modify the dnn
> > native
> > mode in FFmpeg, the generation process of Super Resolution model should be
> > changed accordingly, e.g. add padding method parameter (= 0) and dilation
> > parameter (= 1).
>
> you can create a PR at https://github.com/HighVoltageRocknRoll/sr
>
> >
> >
> >
> >
> > In addition, I have a question about the Super Resulotion implementation.
> > The
> > model training process of SR uses "VALID" method. According to my
> > understanding of "VALID" mode in tensorflow, the size of output image should
> > be smaller than the current design in SR. Because pixels near the boundary
> > are
> > not processed in "VALID" mode, however, these unprocessed pixels are filled
> > with adjacent pixels in current dnn native mode. I wonder why to do like
> > this
> > here.
>
> I have the same concern that why the native model is not exactly the same as
> tf model,
> the pad layer is missed, and the native model also change the behavior of pad
> parameter of conv layer.
>
> it is only suitable for vf_sr, and not general for other models.
>
> >
> >
> >
> >
> > From 4d92ef21a5acf064122c51f442d0e2f5437b3343 Mon Sep 17 00:00:00
> > 2001
> > From: Xuewei Meng
> > Date: Sun, 28 Apr 2019 17:21:35 +0800
> > Subject: [PATCH] Add operation supports in dnn_native
> >
> > Signed-off-by: Xuewei Meng
> > ---
> > libavfilter/dnn_backend_native.c | 36 +---
> > libavfilter/dnn_backend_native.h | 6 +-
> > 2 files changed, 29 insertions(+), 13 deletions(-)
> >
> > diff --git a/libavfilter/dnn_backend_native.c
> > b/libavfilter/dnn_backend_native.c
> > index 70d857f5f2..0e3ef5d64d 100644
> > --- a/libavfilter/dnn_backend_native.c
> > +++ b/libavfilter/dnn_backend_native.c
> > @@ -157,13 +157,15 @@ DNNModel *ff_dnn_load_model_native(const char
> > *model_filename)
> > ff_dnn_free_model_native();
> > return NULL;
> > }
> > +conv_params->dilation =
> > (int32_t)avio_rl32(model_file_context);
> > +conv_params->padding_method =
> > (int32_t)avio_rl32(model_file_context);
> > conv_params->activation =
> > (int32_t)avio_rl32(model_file_context);
> > conv_params->input_num =
> > (int32_t)avio_rl32(model_file_context);
> > conv_params->output_num =
> > (int32_t)avio_rl32(model_file_context);
> > conv_params->kernel_size =
> > (int32_t)avio_rl32(model_file_context);
> > kernel_size = conv_params->input_num *
> > conv_params->output_num *
> >conv_params->kernel_size *
> > conv_params->kernel_size;
> > -dnn_size += 16 + (kernel_size + conv_params->output_num <<
> > 2);
> > +dnn_size += 24 + (kernel_size + conv_params->output_num <<
> > 2);
> > if (dnn_size > file_size || conv_params->input_num <= 0 ||
> > conv_params->output_num <= 0 ||
> > conv_params->kernel_size <= 0){
> > avio_closep(_file_context);
> > @@ -221,23 +223,28 @@ DNNModel *ff_dnn_load_model_native(const char
> > *model_filename)
> >
> > static void convolve(const float *input, float *output, const
> > ConvolutionalParams *conv_params, int width, int height)
> > {
> > -int y, x, n_filter, ch, kernel_y, kernel_x;
> > int radius = conv_params->kernel_size >> 1;
> > int src_linesize = width * conv_params->input_num;
> > int filter_linesize = conv_params->kernel_size *
> > conv_params->input_num;
> > int filter_size = conv_params->kernel_size * filter_linesize;
> > +int pad_size = (conv_params->padding_method ==
Re: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in FFmpeg dnn native mode.
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> xwm...@pku.edu.cn
> Sent: Sunday, April 28, 2019 5:27 PM
> To: ffmpeg development discussions and patches
> Subject: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in
> FFmpeg dnn native mode.
>
> This patch is for the support of derain filter project in GSoC. It adds
> supports for
> the following operations:
>
>
>
>
> (1) Conv padding method: "SAME" and "VALID"
>
> (2) Dilation
>
> (3) Activation: "NONE" and "LEAKY_RELU"
how about separate this single patch into 3 patches.
>
>
>
>
> These operations are all needed in derain filter. And if modify the dnn native
> mode in FFmpeg, the generation process of Super Resolution model should be
> changed accordingly, e.g. add padding method parameter (= 0) and dilation
> parameter (= 1).
you can create a PR at https://github.com/HighVoltageRocknRoll/sr
>
>
>
>
> In addition, I have a question about the Super Resulotion implementation. The
> model training process of SR uses "VALID" method. According to my
> understanding of "VALID" mode in tensorflow, the size of output image should
> be smaller than the current design in SR. Because pixels near the boundary are
> not processed in "VALID" mode, however, these unprocessed pixels are filled
> with adjacent pixels in current dnn native mode. I wonder why to do like this
> here.
I have the same concern that why the native model is not exactly the same as tf
model,
the pad layer is missed, and the native model also change the behavior of pad
parameter of conv layer.
it is only suitable for vf_sr, and not general for other models.
>
>
>
>
> From 4d92ef21a5acf064122c51f442d0e2f5437b3343 Mon Sep 17 00:00:00
> 2001
> From: Xuewei Meng
> Date: Sun, 28 Apr 2019 17:21:35 +0800
> Subject: [PATCH] Add operation supports in dnn_native
>
> Signed-off-by: Xuewei Meng
> ---
> libavfilter/dnn_backend_native.c | 36 +---
> libavfilter/dnn_backend_native.h | 6 +-
> 2 files changed, 29 insertions(+), 13 deletions(-)
>
> diff --git a/libavfilter/dnn_backend_native.c
> b/libavfilter/dnn_backend_native.c
> index 70d857f5f2..0e3ef5d64d 100644
> --- a/libavfilter/dnn_backend_native.c
> +++ b/libavfilter/dnn_backend_native.c
> @@ -157,13 +157,15 @@ DNNModel *ff_dnn_load_model_native(const char
> *model_filename)
> ff_dnn_free_model_native();
> return NULL;
> }
> +conv_params->dilation =
> (int32_t)avio_rl32(model_file_context);
> +conv_params->padding_method =
> (int32_t)avio_rl32(model_file_context);
> conv_params->activation =
> (int32_t)avio_rl32(model_file_context);
> conv_params->input_num =
> (int32_t)avio_rl32(model_file_context);
> conv_params->output_num =
> (int32_t)avio_rl32(model_file_context);
> conv_params->kernel_size =
> (int32_t)avio_rl32(model_file_context);
> kernel_size = conv_params->input_num *
> conv_params->output_num *
>conv_params->kernel_size *
> conv_params->kernel_size;
> -dnn_size += 16 + (kernel_size + conv_params->output_num <<
> 2);
> +dnn_size += 24 + (kernel_size + conv_params->output_num <<
> 2);
> if (dnn_size > file_size || conv_params->input_num <= 0 ||
> conv_params->output_num <= 0 ||
> conv_params->kernel_size <= 0){
> avio_closep(_file_context);
> @@ -221,23 +223,28 @@ DNNModel *ff_dnn_load_model_native(const char
> *model_filename)
>
> static void convolve(const float *input, float *output, const
> ConvolutionalParams *conv_params, int width, int height)
> {
> -int y, x, n_filter, ch, kernel_y, kernel_x;
> int radius = conv_params->kernel_size >> 1;
> int src_linesize = width * conv_params->input_num;
> int filter_linesize = conv_params->kernel_size *
> conv_params->input_num;
> int filter_size = conv_params->kernel_size * filter_linesize;
> +int pad_size = (conv_params->padding_method == VALID) ?
> (conv_params->kernel_size - 1) / 2 * conv_params->dilation : 0;
for parameter 'valid', the size of feature map is changed, it should be
reflected at function set_input_output_native,
for example, the size of network->layers[layer].output should be changed, and
we might add the size info into struct Layer.
>
> -for (y = 0; y < height; ++y){
> -for (x = 0; x < width; ++x){
> -for (n_filter = 0; n_filter < conv_params->output_num;
> ++n_filter){
> +for (int y = pad_size; y < height - pad_size; ++y){
> +for (int x = pad_size; x < width - pad_size; ++x){
> +for (int n_filter = 0; n_filter < conv_params->output_num;
> ++n_filter){
> output[n_filter] = conv_params->biases[n_filter];
> -for (ch = 0; ch < conv_params->input_num; ++ch){
> -for
Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add nlmeans_opencl filter
> -Original Message- > From: Song, Ruiling > Sent: Tuesday, April 23, 2019 4:52 PM > To: 'FFmpeg development discussions and patches' de...@ffmpeg.org> > Subject: RE: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add > nlmeans_opencl filter > > > > > -Original Message- > > From: Song, Ruiling > > Sent: Sunday, April 21, 2019 8:18 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: RE: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add > > nlmeans_opencl filter > > > > > > > > > -Original Message- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > Behalf Of > > > Mark Thompson > > > Sent: Saturday, April 20, 2019 11:08 PM > > > To: ffmpeg-devel@ffmpeg.org > > > Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add > > nlmeans_opencl > > > filter > > > > > > On 17/04/2019 03:43, Song, Ruiling wrote: > > > >> -Original Message- > > > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > Behalf > > > Of > > > >> Mark Thompson > > > >> Sent: Wednesday, April 17, 2019 5:28 AM > > > >> To: ffmpeg-devel@ffmpeg.org > > > >> Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] lavfi/opencl: add > > > nlmeans_opencl > > > >> filter > > > >> > > > >> On 12/04/2019 16:09, Ruiling Song wrote: > > > >>> Signed-off-by: Ruiling Song > > > >> > > > >> I can't work out where the problem is, but there is something really > > weirdly > > > >> nondeterministic going on here. > > > >> > > > >> E.g. > > > >> > > > >> $ ./ffmpeg_g -y -init_hw_device opencl:0.0 -i ~/video/test/jellyfish- > 120- > > > mbps- > > > >> 4k-uhd-hevc-10bit.mkv -an -filter_hw_device opencl0 -vf > > > >> > > > format=yuv420p,hwupload,nlmeans_opencl,hwdownload,format=yuv420p - > > > >> frames:v 10 -f framemd5 - > > > >> ... > > > >> 0, 0, 0,1, 12441600, > > > >> 8b8805818076b23ae6f80ec2b5a349d4 > > > >> 0, 1, 1,1, 12441600, > > > >> 7a7fdaa083dc337cfb6af31b643f30a3 > > > >> 0, 2, 2,1, 12441600, > > > >> b10ef2a1e5125cc67e262e086f8040b5 > > > >> 0, 3, 3,1, 12441600, > > > >> c06b53ad90e0357e537df41b63d5b1dc > > > >> 0, 4, 4,1, 12441600, > > > >> 5aa2da07703859a3dee080847dd17d46 > > > >> 0, 5, 5,1, 12441600, > > > >> 733364c6be6af825057e905a6092937d > > > >> 0, 6, 6,1, 12441600, > > > >> 47edae2dec956a582b04babb745d26b0 > > > >> 0, 7, 7,1, 12441600, > > > >> 4e45fe8268df4298d06a17ab8e46c3e9 > > > >> 0, 8, 8,1, 12441600, > > > >> 960d722a3f8787c9191299a114c04174 > > > >> 0, 9, 9,1, 12441600, > > > >> e759c07ee4834a9cf94bfcb4128e7612 > > > >> $ ./ffmpeg_g -y -init_hw_device opencl:0.0 -i ~/video/test/jellyfish- > 120- > > > mbps- > > > >> 4k-uhd-hevc-10bit.mkv -an -filter_hw_device opencl0 -vf > > > >> > > > format=yuv420p,hwupload,nlmeans_opencl,hwdownload,format=yuv420p - > > > >> frames:v 10 -f framemd5 - > > > >> 0, 0, 0,1, 12441600, > > > >> 8b8805818076b23ae6f80ec2b5a349d4 > > > >> [Parsed_nlmeans_opencl_2 @ 0x5557ae580d00] integral image > > overflow > > > >> 2157538 > > > >> 0, 1, 1,1, 12441600, > > > >> bce72e10a9f1118940c5a8392ad78ec3 > > > >> 0, 2, 2,1, 12441600, > > > >> b10ef2a1e5125cc67e262e086f8040b5 > > > >> 0, 3, 3,1, 12441600, > > > >> c06b53ad90e0357e537df41b63d5b1dc > > > >> 0, 4, 4,1, 12441600, > > > >> 5aa2da07703859a3dee080847dd17d46 > > > >> 0, 5, 5,1, 12441600, > > > >> 733364c6be6af825057e905a6092937d > > > >> 0, 6, 6,1, 12441600, > > > >> 47edae2dec956a582b04babb745d26b0 > > > >> 0, 7, 7,1, 12441600, > > > >> 4e45fe8268df4298d06a17ab8e46c3e9 > > > >> 0, 8, 8,1, 12441600, > > > >> 960d722a3f8787c9191299a114c04174 > > > >> 0, 9, 9,1, 12441600, > > > >> e759c07ee4834a9cf94bfcb4128e7612 > > > >> $ ./ffmpeg_g -y -init_hw_device opencl:0.0 -i ~/video/test/jellyfish- > 120- > > > mbps- > > > >> 4k-uhd-hevc-10bit.mkv -an -filter_hw_device opencl0 -vf > > > >> > > > format=yuv420p,hwupload,nlmeans_opencl,hwdownload,format=yuv420p - > > > >> frames:v 10 -f framemd5 - > > > >> 0, 0, 0,1, 12441600, > > > >> 8b8805818076b23ae6f80ec2b5a349d4 > > > >> 0, 1, 1,1, 12441600, > > > >> 7a7fdaa083dc337cfb6af31b643f30a3 > > > >> [Parsed_nlmeans_opencl_2 @ 0x557c51fbfe80] integral image > overflow > > > >> 2098545 > > > >> 0, 2, 2,1, 12441600, > > > >> 68b390535adc5cfa0f8a7942c42a47ca > > > >> 0, 3, 3,1, 12441600, > > > >> c06b53ad90e0357e537df41b63d5b1dc > > > >> 0, 4, 4,1, 12441600, > > >
Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort decoder/encoder/filter/... names in alphabet order
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Alexander Strasser
> Sent: Sunday, April 28, 2019 11:29 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort
> decoder/encoder/filter/... names in alphabet order
>
> On 2019-04-28 07:42 +, Guo, Yejun wrote:
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of
> > > Alexander Strasser
> > > Sent: Sunday, April 28, 2019 9:18 AM
> > > To: FFmpeg development discussions and patches
>
> > > Subject: Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort
> > > decoder/encoder/filter/... names in alphabet order
> > >
> > >
> > > What do you think about using awk instead of shell?
> > >
> > > I have 2 POC patches attached. It's probably not 100% correct yet,
> > > but it kind of demonstrates what it would look like.
> > >
> > > The main advantage of using awk, is that it's more elegant and
> > > shorter. It's probably also less risky, because it's more isolated,
> > > e.g. as it was explained by avih, there is no widely supported way
> > > for locals across shells. We already use awk in configure for
> > > mandatory functions, so it's no new dependency.
> > >
> > > Please comment on the awk approach.
> >
>
> > I did some change to make it correct on ubuntu 16.04, but looks issue on
> windows mingw.
> >
> > print_in_columns() {
> > sort | tr '\n' ' ' | awk -v width="$ncols" '
> > {
> > #add int()
> > num_cols = int(width / 24); num_rows = int((NF + num_cols-1) /
> num_cols);
>
> The added int() calls looks right.
>
>
> > y = x = 1;
> > for (i = 1; i <= NF; i++) {
> > if (y > num_rows) {
> > y = 1; x++;
> > }
> > d[x,y] = $i;
> > y++;
> > }
> >
> > print width
> > print num_cols
> > print num_rows
> > print NF
> >
> > for (y = 1; y <= num_rows; y++) {
> > for (x = 1; x <= num_cols; x++) {
> > # it does not work for the case that the last column is not
> fully filled
> > #line = sprintf(x != num_cols ? "%s%-24s" : "%s%s", line,
> d[x,y]);
> > line = sprintf("%s%-24s", line, d[x,y]);
>
> You mean it doesn't work in the way that there will be trailing spaces
> in the column before the last one which is partially empty, right?
>
> But the output looked right and there were never trailing spaces in the
> last column, right?
suppose num_cols = 3, see below, the spaces after 'c' is trimmed, while the
spaces after 'e' is still there.
abc
de
>
> BTW I changed the algorithm here, because I thought it might be easier
> to unterstand. I will also try the algorithm, you implemented in shell.
>
>
> > }
> > print line;
> > line = "";
> > }
> > }' | sed 's/ *$//'
> > }
> >
> > on ubuntu 16.04, the output is:
> > Enabled bsfs:
> > 135
> > 5
> > 7
> > 33
> > aac_adtstoasc extract_extradata hevc_mp4toannexb
> mpeg4_unpack_bframestruehd_core
> > av1_frame_split filter_unitsimx_dump_header
> noise vp9_metadata
> > av1_metadatah264_metadata mjpeg2jpeg
> nullvp9_raw_reorder
> > chomp h264_mp4toannexb
> mjpega_dump_header prores_metadata vp9_superframe
> > dca_coreh264_redundant_pps mov2textsub
> remove_extradatavp9_superframe_split
> > dump_extradata hapqa_extract
> mp3_header_decompress text2movsub
> > eac3_core hevc_metadata mpeg2_metadata
> trace_headers
> >
> > while on windows, the output is:
> > Enabled bsfs:
> > 72
> > 3
> > 11
> > 33
> > noiseh264_redundant_pps
> > nullextract
> > prores_metadata
> >remove_extradatamp4toannexb
> > text2movsubdump_header
> > trace_headers
> > truehd_corepega_dump_header
> > vp9_metadata
> > vp9_raw_reorderader_decompress
> > vp9_superframea
> >vp9_superframe_splitames
>
> Wild guess: CR LF line endings are emitted somewhere and the CRs stay in
> the input. Your terminal resets the cursor to the start of the line when
> interpreting the midline CRs.
>
> Does it work if you extend the tr in print_in_columns like below?
>
> sort | tr '\r\n' ' ' | awk -v width="$ncols" '
>
yes, it works!
>
> > I did a quick check, but has not found the root cause yet.
> >
> >
> > >
> > > I'm not against the shell way, or a mixed approach, but before going
> > > either way and pushing I would rather have some more testing;
> > > especially on more exotic platforms.
>
> Thanks for testing and looking into it!
>
> Alexander
> ___
> ffmpeg-devel mailing list
>
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
Hi, On Sun, Apr 28, 2019 at 8:14 PM Marton Balint wrote: > On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote: > > On Mon, 29 Apr 2019, at 00:23, Marton Balint wrote: > >> >> On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote: > >> >>> 2) Should patches using closed source libraries which are not > considered > >> >>> "System Libraries" according to the GPL be rejected? > >> >> > >> >> You mean "major components"? > >> >> (at no point does the GPLv2 mention "System Libraries". > >> > > >> > I meant the sytem libraries as in GPL v3. > >> > >> Okay, now I am really confused, I thought the GPLv3 refers to the > system > >> libraries as the drivers interfaces, but that might not be a case, > because > >> that is also the major component? > >> > >> If that is the case, then my intention was obvisouly major component, > but > >> I wonder what the system library means then in GPL v3? > > > > As to that, I have no clue. I feel that the GPLv3 did not help on that > part, and makes it more confusing (and many other parts). > > > > My understanding of major components of the OS, in GPLv2sense, is > kernel+libc+compiler+init/shell+drivers+libraries-installed-with-the-previous. > > Ok, I just revoked the vote request on the 2nd question. Sorry for the > mess. > > It looks like people prefer if GPL is not referenced at all in the > question, so please propose a (preferably short, but still precise) > wording for the vote about this. Should decklink be removed? (Even if the headers are BSD, the end-user functionality depends on closed-source libraries.) Should future patches depending on any closed-source component be approved of by a vote from this committee before being merged? We could even do a vote on the nvidia stuffies, just so we've had that too. Ronald ___ 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] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote: On Mon, 29 Apr 2019, at 00:23, Marton Balint wrote: >> On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote: >>> 2) Should patches using closed source libraries which are not considered >>> "System Libraries" according to the GPL be rejected? >> >> You mean "major components"? >> (at no point does the GPLv2 mention "System Libraries". > > I meant the sytem libraries as in GPL v3. Okay, now I am really confused, I thought the GPLv3 refers to the system libraries as the drivers interfaces, but that might not be a case, because that is also the major component? If that is the case, then my intention was obvisouly major component, but I wonder what the system library means then in GPL v3? As to that, I have no clue. I feel that the GPLv3 did not help on that part, and makes it more confusing (and many other parts). My understanding of major components of the OS, in GPLv2sense, is kernel+libc+compiler+init/shell+drivers+libraries-installed-with-the-previous. Ok, I just revoked the vote request on the 2nd question. Sorry for the mess. It looks like people prefer if GPL is not referenced at all in the question, so please propose a (preferably short, but still precise) wording for the vote about this. Thanks, Marton ___ 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] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, Marton Balint wrote: Hi All, There has been discussion on the mailing list several times about the inclusion of support for closed source components (codecs, formats, filters, etc) in the main ffmpeg codebase. Also the removal of libNDI happened without general consensus, so a vote is necessary to justify the removal. So here is a call to the voting committee [1] to decide on the following two questions: 1) Should libNDI support be removed from the ffmpeg codebase? 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? I revoke the vote request on the 2nd question (some invalid references and ambiguity was pointed out in it), please only vote on the 1st. Second question will be rephrased and submitted to a vote later, in a different thread. Thanks, Marton ___ 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/3] avcodec/cbs_h2645: use the fixed() macro for forbidden_zero_bit
On 4/28/2019 8:00 PM, Mark Thompson wrote:
> On 17/04/2019 03:56, James Almer wrote:
>> This follows the spec definition, and removes a field from the relevant
>> structs.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/cbs_h264.h | 1 -
>> libavcodec/cbs_h264_syntax_template.c | 2 +-
>> libavcodec/cbs_h265.h | 1 -
>> libavcodec/cbs_h265_syntax_template.c | 2 +-
>> 4 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
>> index b5eee7c370..cc46eeb3b0 100644
>> --- a/libavcodec/cbs_h264.h
>> +++ b/libavcodec/cbs_h264.h
>> @@ -38,7 +38,6 @@ enum {
>>
>>
>> typedef struct H264RawNALUnitHeader {
>> -uint8_t forbidden_zero_bit;
>> uint8_t nal_ref_idc;
>> uint8_t nal_unit_type;
>>
>> diff --git a/libavcodec/cbs_h264_syntax_template.c
>> b/libavcodec/cbs_h264_syntax_template.c
>> index cc9bd07590..95fc6d7194 100644
>> --- a/libavcodec/cbs_h264_syntax_template.c
>> +++ b/libavcodec/cbs_h264_syntax_template.c
>> @@ -33,7 +33,7 @@ static int FUNC(nal_unit_header)(CodedBitstreamContext
>> *ctx, RWContext *rw,
>> {
>> int err;
>>
>> -u(1, forbidden_zero_bit, 0, 0);
>> +fixed(1, forbidden_zero_bit, 0);
>> ub(2, nal_ref_idc);
>> ub(5, nal_unit_type);
>>
>> diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
>> index 0c0e4f84b0..c9bc90187b 100644
>> --- a/libavcodec/cbs_h265.h
>> +++ b/libavcodec/cbs_h265.h
>> @@ -35,7 +35,6 @@ enum {
>> };
>>
>> typedef struct H265RawNALUnitHeader {
>> -uint8_t forbidden_zero_bit;
>> uint8_t nal_unit_type;
>> uint8_t nuh_layer_id;
>> uint8_t nuh_temporal_id_plus1;
>> diff --git a/libavcodec/cbs_h265_syntax_template.c
>> b/libavcodec/cbs_h265_syntax_template.c
>> index 87d1332f48..9000bbc307 100644
>> --- a/libavcodec/cbs_h265_syntax_template.c
>> +++ b/libavcodec/cbs_h265_syntax_template.c
>> @@ -33,7 +33,7 @@ static int FUNC(nal_unit_header)(CodedBitstreamContext
>> *ctx, RWContext *rw,
>> {
>> int err;
>>
>> -u(1, forbidden_zero_bit, 0, 0);
>> +fixed(1, forbidden_zero_bit, 0);
>>
>> if (expected_nal_unit_type >= 0)
>> u(6, nal_unit_type, expected_nal_unit_type,
>>
>
> Yep, LGTM.
>
> Thanks,
>
> - Mark
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] [PATCH 3/3] avcodec/cbs_h2645: rename macros to read and write fields with custom range of values
On 4/28/2019 8:19 PM, Mark Thompson wrote:
> On 17/04/2019 03:56, James Almer wrote:
>> These are more in line with the new ones introduced in the previous commit.
>>
>> Signed-off-by: James Almer
>> ---
>> No more i() macro :p
>>
>> Figured I'd leave all the byte and checksum fields using the custom range
>> macro, to have the explicit hex values visible. That's why they were not
>> changed in the first patch.
>>
>> libavcodec/cbs_h2645.c| 8 +-
>> libavcodec/cbs_h264_syntax_template.c | 52 ++---
>> libavcodec/cbs_h265_syntax_template.c | 106 +-
>> 3 files changed, 83 insertions(+), 83 deletions(-)
>>
>> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
>> index 319202fc48..5623fa705e 100644
>> --- a/libavcodec/cbs_h2645.c
>> +++ b/libavcodec/cbs_h2645.c
>> @@ -250,21 +250,21 @@ static int cbs_write_se_golomb(CodedBitstreamContext
>> *ctx, PutBitContext *pbc,
>>
>> #define SUBSCRIPTS(subs, ...) (subs > 0 ? ((int[subs + 1]){ subs,
>> __VA_ARGS__ }) : NULL)
>>
>> -#define u(width, name, range_min, range_max) \
>> +#define uc(width, name, range_min, range_max) \
>> xu(width, name, current->name, range_min, range_max, 0)
>> #define ub(width, name) \
>> xu(width, name, current->name, 0, MAX_UINT_BITS(width), 0)
>> #define flag(name) ub(1, name)
>> #define ue(name, range_min, range_max) \
>> xue(name, current->name, range_min, range_max, 0)
>> -#define i(width, name, range_min, range_max) \
>> +#define ic(width, name, range_min, range_max) \
>> xi(width, name, current->name, range_min, range_max, 0)
>> #define ib(width, name) \
>> xi(width, name, current->name, MIN_INT_BITS(width),
>> MAX_INT_BITS(width), 0)
>> #define se(name, range_min, range_max) \
>> xse(name, current->name, range_min, range_max, 0)
>>
>> -#define us(width, name, range_min, range_max, subs, ...) \
>> +#define ucs(width, name, range_min, range_max, subs, ...) \
>> xu(width, name, current->name, range_min, range_max, subs,
>> __VA_ARGS__)
>> #define ubs(width, name, subs, ...) \
>> xu(width, name, current->name, 0, MAX_UINT_BITS(width), subs,
>> __VA_ARGS__)
>> @@ -272,7 +272,7 @@ static int cbs_write_se_golomb(CodedBitstreamContext
>> *ctx, PutBitContext *pbc,
>> xu(1, name, current->name, 0, 1, subs, __VA_ARGS__)
>> #define ues(name, range_min, range_max, subs, ...) \
>> xue(name, current->name, range_min, range_max, subs, __VA_ARGS__)
>> -#define is(width, name, range_min, range_max, subs, ...) \
>> +#define ics(width, name, range_min, range_max, subs, ...) \
>> xi(width, name, current->name, range_min, range_max, subs,
>> __VA_ARGS__)
>> #define ibs(width, name, subs, ...) \
>> xi(width, name, current->name, MIN_INT_BITS(width),
>> MAX_INT_BITS(width), subs, __VA_ARGS__)
>
> Not sure I'm convinced by this one - the existing flag/u/ue/se set is really
> very nice in matching the standard. If anything, it makes me think of going
> the other way in the AV1 code, though there are fewer limited values there so
> the bare f() case is not so common.
>
> Thanks,
>
> - Mark
I don't mind dropping this patch. You're right that as is it matches the
standard.
___
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/3] avcodec/cbs_h2645: add macros to read and write fields with no custom range of values
On 4/28/2019 7:59 PM, Mark Thompson wrote: > On 17/04/2019 03:56, James Almer wrote: >> Signed-off-by: James Almer >> --- >> Better macro names welcome. I used the same convention as in cbs_av1. >> >> fate-cbs passes, but i'm sure a bunch of these are not tested by it, >> so help double checking i didn't screw up is welcome. >> >> libavcodec/cbs_h2645.c| 10 +- >> libavcodec/cbs_h264_syntax_template.c | 60 ++-- >> libavcodec/cbs_h265_syntax_template.c | 126 +++--- >> 3 files changed, 90 insertions(+), 106 deletions(-) > > The cleanup to things with nontrivial length expressions is nice :) > > LGTM. > > Thanks, > > - Mark Pushed, thanks! ___ 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] avcodec/cbs_h2645: rename macros to read and write fields with custom range of values
On 17/04/2019 03:56, James Almer wrote:
> These are more in line with the new ones introduced in the previous commit.
>
> Signed-off-by: James Almer
> ---
> No more i() macro :p
>
> Figured I'd leave all the byte and checksum fields using the custom range
> macro, to have the explicit hex values visible. That's why they were not
> changed in the first patch.
>
> libavcodec/cbs_h2645.c| 8 +-
> libavcodec/cbs_h264_syntax_template.c | 52 ++---
> libavcodec/cbs_h265_syntax_template.c | 106 +-
> 3 files changed, 83 insertions(+), 83 deletions(-)
>
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index 319202fc48..5623fa705e 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -250,21 +250,21 @@ static int cbs_write_se_golomb(CodedBitstreamContext
> *ctx, PutBitContext *pbc,
>
> #define SUBSCRIPTS(subs, ...) (subs > 0 ? ((int[subs + 1]){ subs,
> __VA_ARGS__ }) : NULL)
>
> -#define u(width, name, range_min, range_max) \
> +#define uc(width, name, range_min, range_max) \
> xu(width, name, current->name, range_min, range_max, 0)
> #define ub(width, name) \
> xu(width, name, current->name, 0, MAX_UINT_BITS(width), 0)
> #define flag(name) ub(1, name)
> #define ue(name, range_min, range_max) \
> xue(name, current->name, range_min, range_max, 0)
> -#define i(width, name, range_min, range_max) \
> +#define ic(width, name, range_min, range_max) \
> xi(width, name, current->name, range_min, range_max, 0)
> #define ib(width, name) \
> xi(width, name, current->name, MIN_INT_BITS(width),
> MAX_INT_BITS(width), 0)
> #define se(name, range_min, range_max) \
> xse(name, current->name, range_min, range_max, 0)
>
> -#define us(width, name, range_min, range_max, subs, ...) \
> +#define ucs(width, name, range_min, range_max, subs, ...) \
> xu(width, name, current->name, range_min, range_max, subs,
> __VA_ARGS__)
> #define ubs(width, name, subs, ...) \
> xu(width, name, current->name, 0, MAX_UINT_BITS(width), subs,
> __VA_ARGS__)
> @@ -272,7 +272,7 @@ static int cbs_write_se_golomb(CodedBitstreamContext
> *ctx, PutBitContext *pbc,
> xu(1, name, current->name, 0, 1, subs, __VA_ARGS__)
> #define ues(name, range_min, range_max, subs, ...) \
> xue(name, current->name, range_min, range_max, subs, __VA_ARGS__)
> -#define is(width, name, range_min, range_max, subs, ...) \
> +#define ics(width, name, range_min, range_max, subs, ...) \
> xi(width, name, current->name, range_min, range_max, subs,
> __VA_ARGS__)
> #define ibs(width, name, subs, ...) \
> xi(width, name, current->name, MIN_INT_BITS(width),
> MAX_INT_BITS(width), subs, __VA_ARGS__)
Not sure I'm convinced by this one - the existing flag/u/ue/se set is really
very nice in matching the standard. If anything, it makes me think of going
the other way in the AV1 code, though there are fewer limited values there so
the bare f() case is not so common.
Thanks,
- Mark
___
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] [DECISION] Project policy on closed source components
On Mon, 29 Apr 2019, Carl Eugen Hoyos wrote: 2019-04-28 22:02 GMT+02:00, Marton Balint : 1) Should libNDI support be removed from the ffmpeg codebase? This sounds to me as if you know of an alternative to not endorsing a company that profits from FFmpeg while at the same time violating the copyright of the FFmpeg developers? What could this alternative be? We could list them on our webpage hall of shame, or whatever. To be frank, I consider this vote to be more important for our project/community to make sure everyone's voice is heard, than the actual outcome. Regards, Marton ___ 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/3] avcodec/cbs_h2645: use the fixed() macro for forbidden_zero_bit
On 17/04/2019 03:56, James Almer wrote:
> This follows the spec definition, and removes a field from the relevant
> structs.
>
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_h264.h | 1 -
> libavcodec/cbs_h264_syntax_template.c | 2 +-
> libavcodec/cbs_h265.h | 1 -
> libavcodec/cbs_h265_syntax_template.c | 2 +-
> 4 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
> index b5eee7c370..cc46eeb3b0 100644
> --- a/libavcodec/cbs_h264.h
> +++ b/libavcodec/cbs_h264.h
> @@ -38,7 +38,6 @@ enum {
>
>
> typedef struct H264RawNALUnitHeader {
> -uint8_t forbidden_zero_bit;
> uint8_t nal_ref_idc;
> uint8_t nal_unit_type;
>
> diff --git a/libavcodec/cbs_h264_syntax_template.c
> b/libavcodec/cbs_h264_syntax_template.c
> index cc9bd07590..95fc6d7194 100644
> --- a/libavcodec/cbs_h264_syntax_template.c
> +++ b/libavcodec/cbs_h264_syntax_template.c
> @@ -33,7 +33,7 @@ static int FUNC(nal_unit_header)(CodedBitstreamContext
> *ctx, RWContext *rw,
> {
> int err;
>
> -u(1, forbidden_zero_bit, 0, 0);
> +fixed(1, forbidden_zero_bit, 0);
> ub(2, nal_ref_idc);
> ub(5, nal_unit_type);
>
> diff --git a/libavcodec/cbs_h265.h b/libavcodec/cbs_h265.h
> index 0c0e4f84b0..c9bc90187b 100644
> --- a/libavcodec/cbs_h265.h
> +++ b/libavcodec/cbs_h265.h
> @@ -35,7 +35,6 @@ enum {
> };
>
> typedef struct H265RawNALUnitHeader {
> -uint8_t forbidden_zero_bit;
> uint8_t nal_unit_type;
> uint8_t nuh_layer_id;
> uint8_t nuh_temporal_id_plus1;
> diff --git a/libavcodec/cbs_h265_syntax_template.c
> b/libavcodec/cbs_h265_syntax_template.c
> index 87d1332f48..9000bbc307 100644
> --- a/libavcodec/cbs_h265_syntax_template.c
> +++ b/libavcodec/cbs_h265_syntax_template.c
> @@ -33,7 +33,7 @@ static int FUNC(nal_unit_header)(CodedBitstreamContext
> *ctx, RWContext *rw,
> {
> int err;
>
> -u(1, forbidden_zero_bit, 0, 0);
> +fixed(1, forbidden_zero_bit, 0);
>
> if (expected_nal_unit_type >= 0)
> u(6, nal_unit_type, expected_nal_unit_type,
>
Yep, LGTM.
Thanks,
- Mark
___
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/3] avcodec/cbs_h2645: add macros to read and write fields with no custom range of values
On 17/04/2019 03:56, James Almer wrote: > Signed-off-by: James Almer > --- > Better macro names welcome. I used the same convention as in cbs_av1. > > fate-cbs passes, but i'm sure a bunch of these are not tested by it, > so help double checking i didn't screw up is welcome. > > libavcodec/cbs_h2645.c| 10 +- > libavcodec/cbs_h264_syntax_template.c | 60 ++-- > libavcodec/cbs_h265_syntax_template.c | 126 +++--- > 3 files changed, 90 insertions(+), 106 deletions(-) The cleanup to things with nontrivial length expressions is nice :) LGTM. Thanks, - Mark ___ 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/cbs_av1: add missing value range constrains to timecode Metadata OBU
On 4/28/2019 7:28 PM, Mark Thompson wrote:
> On 17/04/2019 16:48, James Almer wrote:
>> Also infer the value time_offset_length as 0 when it's not present.
>>
>> Signed-off-by: James Almer
>> ---
>> Fun thing, this metadata OBU is clearly based on the H264/5 timecode SEI, yet
>> time_offset_length is unsigned here :p
>>
>> libavcodec/cbs_av1_syntax_template.c | 14 --
>> 1 file changed, 8 insertions(+), 6 deletions(-)
>>
>> diff --git a/libavcodec/cbs_av1_syntax_template.c
>> b/libavcodec/cbs_av1_syntax_template.c
>> index 59a98b18c9..b04cd51d55 100644
>> --- a/libavcodec/cbs_av1_syntax_template.c
>> +++ b/libavcodec/cbs_av1_syntax_template.c
>> @@ -1753,19 +1753,19 @@ static int
>> FUNC(metadata_timecode)(CodedBitstreamContext *ctx, RWContext *rw,
>> fb(9, n_frames);
>>
>> if (current->full_timestamp_flag) {
>> -fb(6, seconds_value);
>> -fb(6, minutes_value);
>> -fb(5, hours_value);
>> +fc(6, seconds_value, 0, 59);
>
> What, no leap seconds? :P
Not even the Linux Kernel could handle those properly at some point :p
>
>> +fc(6, minutes_value, 0, 59);
>> +fc(5, hours_value, 0, 23);
>> } else {
>> flag(seconds_flag);
>> if (current->seconds_flag) {
>> -fb(6, seconds_value);
>> +fc(6, seconds_value, 0, 59);
>> flag(minutes_flag);
>> if (current->minutes_flag) {
>> -fb(6, minutes_value);
>> +fc(6, minutes_value, 0, 59);
>> flag(hours_flag);
>> if (current->hours_flag)
>> -fb(5, hours_value);
>> +fc(5, hours_value, 0, 23);
>> }
>> }
>> }
>> @@ -1773,6 +1773,8 @@ static int
>> FUNC(metadata_timecode)(CodedBitstreamContext *ctx, RWContext *rw,
>> fb(5, time_offset_length);
>> if (current->time_offset_length > 0)
>> fb(current->time_offset_length, time_offset_value);
>> +else
>> +infer(time_offset_length, 0);
>>
>> return 0;
>> }
>>
>
> LGTM.
Pushed. Look at the h2645 patchset set i sent before this patch as well
whenever you can.
Thanks!
___
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/h263dec: Fixed missing `hw_configs` property
2019-04-29 0:32 GMT+02:00, fumoboy007 : Could you add a sentence to the commit message that explains what this commit fixes? Maybe "h263 decoding with videotoolbox"? 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
2019-04-28 22:02 GMT+02:00, Marton Balint : > 1) Should libNDI support be removed from the ffmpeg codebase? This sounds to me as if you know of an alternative to not endorsing a company that profits from FFmpeg while at the same time violating the copyright of the FFmpeg developers? What could this alternative be? 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".
[FFmpeg-devel] [PATCH] avcodec/h263dec: Fixed missing `hw_configs` property
---
libavcodec/h263dec.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 8385ddfe2e..6f001f6d47 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -743,6 +743,19 @@ const enum AVPixelFormat ff_h263_hwaccel_pixfmt_list_420[]
= {
AV_PIX_FMT_NONE
};
+const AVCodecHWConfigInternal *ff_h263_hw_config_list[] = {
+#if CONFIG_H263_VAAPI_HWACCEL
+HWACCEL_VAAPI(h263),
+#endif
+#if CONFIG_MPEG4_VDPAU_HWACCEL
+HWACCEL_VDPAU(mpeg4),
+#endif
+#if CONFIG_H263_VIDEOTOOLBOX_HWACCEL
+HWACCEL_VIDEOTOOLBOX(h263),
+#endif
+NULL
+};
+
AVCodec ff_h263_decoder = {
.name = "h263",
.long_name = NULL_IF_CONFIG_SMALL("H.263 / H.263-1996, H.263+ /
H.263-1998 / H.263 version 2"),
@@ -758,6 +771,7 @@ AVCodec ff_h263_decoder = {
.flush = ff_mpeg_flush,
.max_lowres = 3,
.pix_fmts = ff_h263_hwaccel_pixfmt_list_420,
+.hw_configs = ff_h263_hw_config_list,
};
AVCodec ff_h263p_decoder = {
@@ -775,16 +789,5 @@ AVCodec ff_h263p_decoder = {
.flush = ff_mpeg_flush,
.max_lowres = 3,
.pix_fmts = ff_h263_hwaccel_pixfmt_list_420,
-.hw_configs = (const AVCodecHWConfigInternal*[]) {
-#if CONFIG_H263_VAAPI_HWACCEL
-HWACCEL_VAAPI(h263),
-#endif
-#if CONFIG_MPEG4_VDPAU_HWACCEL
-HWACCEL_VDPAU(mpeg4),
-#endif
-#if CONFIG_H263_VIDEOTOOLBOX_HWACCEL
-HWACCEL_VIDEOTOOLBOX(h263),
-#endif
-NULL
-},
+.hw_configs = ff_h263_hw_config_list,
};
--
2.17.2 (Apple Git-113)
___
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] [DECISION] Project policy on closed source components
On Mon, 29 Apr 2019, at 00:23, Marton Balint wrote: > >> On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote: > >>> 2) Should patches using closed source libraries which are not considered > >>> "System Libraries" according to the GPL be rejected? > >> > >> You mean "major components"? > >> (at no point does the GPLv2 mention "System Libraries". > > > > I meant the sytem libraries as in GPL v3. > > Okay, now I am really confused, I thought the GPLv3 refers to the system > libraries as the drivers interfaces, but that might not be a case, because > that is also the major component? > > If that is the case, then my intention was obvisouly major component, but > I wonder what the system library means then in GPL v3? As to that, I have no clue. I feel that the GPLv3 did not help on that part, and makes it more confusing (and many other parts). My understanding of major components of the OS, in GPLv2sense, is kernel+libc+compiler+init/shell+drivers+libraries-installed-with-the-previous. -- 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] lavc/qsvenc: disable CO3 for mpeg2
2019-04-28 14:35 GMT+02:00, Zhong Li :
> Currenntly there is no any function of CO3 appled to mpeg2,
> and enabling for mpeg2 it will cause regression with some old
> libmfx libaries (see tiket #7839), so disable CO3 for mpeg2.
>
> Also add runtime version check for CO3.
>
> Signed-off-by: Zhong Li
> ---
> libavcodec/qsvenc.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index a03ab69590..e0886aeedb 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -750,15 +750,18 @@ FF_ENABLE_DEPRECATION_WARNINGS
> }
> #endif
> }
> +
> +if (avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO &&
> QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11)) {
> #if QSV_HAVE_CO3
> -q->extco3.Header.BufferId = MFX_EXTBUFF_CODING_OPTION3;
> -q->extco3.Header.BufferSz = sizeof(q->extco3);
> +q->extco3.Header.BufferId = MFX_EXTBUFF_CODING_OPTION3;
> +q->extco3.Header.BufferSz = sizeof(q->extco3);
> #if QSV_HAVE_GPB
> -if (avctx->codec_id == AV_CODEC_ID_HEVC)
> -q->extco3.GPB = q->gpb ? MFX_CODINGOPTION_ON :
> MFX_CODINGOPTION_OFF;
> +if (avctx->codec_id == AV_CODEC_ID_HEVC)
> +q->extco3.GPB = q->gpb ? MFX_CODINGOPTION_ON :
> MFX_CODINGOPTION_OFF;
> #endif
> -q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer
> *)>extco3;
> +q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer
> *)>extco3;
> #endif
> +}
Please separate the cosmetic from the function change(s) to make
the patch more readable.
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".
Re: [FFmpeg-devel] [PATCH] avcodec/cbs_av1: add missing value range constrains to timecode Metadata OBU
On 17/04/2019 16:48, James Almer wrote:
> Also infer the value time_offset_length as 0 when it's not present.
>
> Signed-off-by: James Almer
> ---
> Fun thing, this metadata OBU is clearly based on the H264/5 timecode SEI, yet
> time_offset_length is unsigned here :p
>
> libavcodec/cbs_av1_syntax_template.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/cbs_av1_syntax_template.c
> b/libavcodec/cbs_av1_syntax_template.c
> index 59a98b18c9..b04cd51d55 100644
> --- a/libavcodec/cbs_av1_syntax_template.c
> +++ b/libavcodec/cbs_av1_syntax_template.c
> @@ -1753,19 +1753,19 @@ static int
> FUNC(metadata_timecode)(CodedBitstreamContext *ctx, RWContext *rw,
> fb(9, n_frames);
>
> if (current->full_timestamp_flag) {
> -fb(6, seconds_value);
> -fb(6, minutes_value);
> -fb(5, hours_value);
> +fc(6, seconds_value, 0, 59);
What, no leap seconds? :P
> +fc(6, minutes_value, 0, 59);
> +fc(5, hours_value, 0, 23);
> } else {
> flag(seconds_flag);
> if (current->seconds_flag) {
> -fb(6, seconds_value);
> +fc(6, seconds_value, 0, 59);
> flag(minutes_flag);
> if (current->minutes_flag) {
> -fb(6, minutes_value);
> +fc(6, minutes_value, 0, 59);
> flag(hours_flag);
> if (current->hours_flag)
> -fb(5, hours_value);
> +fc(5, hours_value, 0, 23);
> }
> }
> }
> @@ -1773,6 +1773,8 @@ static int
> FUNC(metadata_timecode)(CodedBitstreamContext *ctx, RWContext *rw,
> fb(5, time_offset_length);
> if (current->time_offset_length > 0)
> fb(current->time_offset_length, time_offset_value);
> +else
> +infer(time_offset_length, 0);
>
> return 0;
> }
>
LGTM.
Thanks,
- Mark
___
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] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, Marton Balint wrote: On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote: On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote: 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? You mean "major components"? (at no point does the GPLv2 mention "System Libraries". I meant the sytem libraries as in GPL v3. Okay, now I am really confused, I thought the GPLv3 refers to the system libraries as the drivers interfaces, but that might not be a case, because that is also the major component? If that is the case, then my intention was obvisouly major component, but I wonder what the system library means then in GPL v3? Thanks, Marton ___ 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 v3 2/4] cbs_mpeg2: Improve checks for invalid values
Mark Thompson:
> On 23/04/2019 23:55, Andreas Rheinhardt wrote:
>> horizontal/vertical_size_value (containing the twelve least significant
>> bits of the frame size) mustn't be zero according to the specifications;
>> and the value 0 is forbidden for the colour_description elements.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> The actual function calls after macro expansion are the same as in the
>> earlier versions with the exception of the extra_bit_slice calls.
>> libavcodec/cbs_mpeg2.c | 14 --
>> libavcodec/cbs_mpeg2_syntax_template.c | 20 ++--
>> 2 files changed, 18 insertions(+), 16 deletions(-)
>>
>> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
>> index cdde68ea38..fc21745a51 100644
>> --- a/libavcodec/cbs_mpeg2.c
>> +++ b/libavcodec/cbs_mpeg2.c
>> @@ -41,20 +41,22 @@
>> #define SUBSCRIPTS(subs, ...) (subs > 0 ? ((int[subs + 1]){ subs,
>> __VA_ARGS__ }) : NULL)
>>
>> #define ui(width, name) \
>> -xui(width, name, current->name, 0)
>> +xui(width, name, current->name, 0, MAX_UINT_BITS(width), 0)
>> +#define uir(width, name, range_min, range_max) \
>> +xui(width, name, current->name, range_min, range_max, 0)
>> #define uis(width, name, subs, ...) \
>> -xui(width, name, current->name, subs, __VA_ARGS__)
>> +xui(width, name, current->name, 0, MAX_UINT_BITS(width), subs,
>> __VA_ARGS__)
>>
>>
>> #define READ
>> #define READWRITE read
>> #define RWContext GetBitContext
>>
>> -#define xui(width, name, var, subs, ...) do { \
>> +#define xui(width, name, var, range_min, range_max, subs, ...) do { \
>> uint32_t value = 0; \
>> CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
>> SUBSCRIPTS(subs, __VA_ARGS__), \
>> - , 0, (1 << width) - 1)); \
>> + , range_min, range_max)); \
>> var = value; \
>> } while (0)
>>
>> @@ -81,10 +83,10 @@
>> #define READWRITE write
>> #define RWContext PutBitContext
>>
>> -#define xui(width, name, var, subs, ...) do { \
>> +#define xui(width, name, var, range_min, range_max, subs, ...) do { \
>> CHECK(ff_cbs_write_unsigned(ctx, rw, width, #name, \
>> SUBSCRIPTS(subs, __VA_ARGS__), \
>> -var, 0, (1 << width) - 1)); \
>> +var, range_min, range_max)); \
>> } while (0)
>>
>> #define marker_bit() do { \
>> diff --git a/libavcodec/cbs_mpeg2_syntax_template.c
>> b/libavcodec/cbs_mpeg2_syntax_template.c
>> index 10aaea7734..27dcaad316 100644
>> --- a/libavcodec/cbs_mpeg2_syntax_template.c
>> +++ b/libavcodec/cbs_mpeg2_syntax_template.c
>> @@ -26,8 +26,8 @@ static int FUNC(sequence_header)(CodedBitstreamContext
>> *ctx, RWContext *rw,
>>
>> ui(8, sequence_header_code);
>>
>> -ui(12, horizontal_size_value);
>> -ui(12, vertical_size_value);
>> +uir(12, horizontal_size_value, 1, 4095);
>> +uir(12, vertical_size_value, 1, 4095);
>>
>> mpeg2->horizontal_size = current->horizontal_size_value;
>> mpeg2->vertical_size = current->vertical_size_value;
>> @@ -79,7 +79,7 @@ static int FUNC(user_data)(CodedBitstreamContext *ctx,
>> RWContext *rw,
>> #endif
>>
>> for (k = 0; k < current->user_data_length; k++)
>> -xui(8, user_data, current->user_data[k], 0);
>> +xui(8, user_data, current->user_data[k], 0, 255, 0);
>
> This could include the subscript while you're changing it.
>
> uis(8, user_data[k], 1, k);
>
Yes, James remarked the same.
>>
>> return 0;
>> }
>> @@ -125,9 +125,9 @@ static int
>> FUNC(sequence_display_extension)(CodedBitstreamContext *ctx, RWContex
>>
>> ui(1, colour_description);
>> if (current->colour_description) {
>> -ui(8, colour_primaries);
>> -ui(8, transfer_characteristics);
>> -ui(8, matrix_coefficients);
>> +uir(8, colour_primaries, 1, 255);
>> +uir(8, transfer_characteristics, 1, 255);
>> +uir(8, matrix_coefficients, 1, 255);
>
> I'm a bit unsure about this one. While the zero value is indeed banned by
> the standard, it isn't uncommon to find (at least in H.264) streams with
> zeroes in these fields. (The libavcodec encoder for MPEG-2 is happy to write
> such a stream, too.) Start code aliasing is presumably the reason for the
> standard disallowing zeroes, but they probably won't actually be a problem
> unless display_horizontal_size happens to have a specific range of bad values
> (in which case we already fail in a different way).
>
Yeah, that is certainly because of start code emulation. What do you
think about correcting these values while reading? Would be especially
good considering that mpeg2_metadata under certain circumstances
created such files in the first place.
- Andreas
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, Mark Thompson wrote: On 28/04/2019 21:02, Marton Balint wrote: ... closed source libraries which are not considered "System Libraries" according to the GPL ... Please can you define this in a precise way which does not rely upon interpreting the GPL? There are certainly differing opinions about exactly what it means, and we need to know exactly what we are voting on. It is amazingly hard to define this precisely, and I have a feeling that whatever we come up with, somebody will be able to find holes in it. If something is debated to be a "System Library", then we can always do a vote on a case by case basis. (not whether or not it is a system library, but if we accept it into the codebase anyways). Regards, Marton ___ 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 v3 2/4] cbs_mpeg2: Improve checks for invalid values
On 23/04/2019 23:55, Andreas Rheinhardt wrote:
> horizontal/vertical_size_value (containing the twelve least significant
> bits of the frame size) mustn't be zero according to the specifications;
> and the value 0 is forbidden for the colour_description elements.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> The actual function calls after macro expansion are the same as in the
> earlier versions with the exception of the extra_bit_slice calls.
> libavcodec/cbs_mpeg2.c | 14 --
> libavcodec/cbs_mpeg2_syntax_template.c | 20 ++--
> 2 files changed, 18 insertions(+), 16 deletions(-)
>
> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
> index cdde68ea38..fc21745a51 100644
> --- a/libavcodec/cbs_mpeg2.c
> +++ b/libavcodec/cbs_mpeg2.c
> @@ -41,20 +41,22 @@
> #define SUBSCRIPTS(subs, ...) (subs > 0 ? ((int[subs + 1]){ subs,
> __VA_ARGS__ }) : NULL)
>
> #define ui(width, name) \
> -xui(width, name, current->name, 0)
> +xui(width, name, current->name, 0, MAX_UINT_BITS(width), 0)
> +#define uir(width, name, range_min, range_max) \
> +xui(width, name, current->name, range_min, range_max, 0)
> #define uis(width, name, subs, ...) \
> -xui(width, name, current->name, subs, __VA_ARGS__)
> +xui(width, name, current->name, 0, MAX_UINT_BITS(width), subs,
> __VA_ARGS__)
>
>
> #define READ
> #define READWRITE read
> #define RWContext GetBitContext
>
> -#define xui(width, name, var, subs, ...) do { \
> +#define xui(width, name, var, range_min, range_max, subs, ...) do { \
> uint32_t value = 0; \
> CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
> SUBSCRIPTS(subs, __VA_ARGS__), \
> - , 0, (1 << width) - 1)); \
> + , range_min, range_max)); \
> var = value; \
> } while (0)
>
> @@ -81,10 +83,10 @@
> #define READWRITE write
> #define RWContext PutBitContext
>
> -#define xui(width, name, var, subs, ...) do { \
> +#define xui(width, name, var, range_min, range_max, subs, ...) do { \
> CHECK(ff_cbs_write_unsigned(ctx, rw, width, #name, \
> SUBSCRIPTS(subs, __VA_ARGS__), \
> -var, 0, (1 << width) - 1)); \
> +var, range_min, range_max)); \
> } while (0)
>
> #define marker_bit() do { \
> diff --git a/libavcodec/cbs_mpeg2_syntax_template.c
> b/libavcodec/cbs_mpeg2_syntax_template.c
> index 10aaea7734..27dcaad316 100644
> --- a/libavcodec/cbs_mpeg2_syntax_template.c
> +++ b/libavcodec/cbs_mpeg2_syntax_template.c
> @@ -26,8 +26,8 @@ static int FUNC(sequence_header)(CodedBitstreamContext
> *ctx, RWContext *rw,
>
> ui(8, sequence_header_code);
>
> -ui(12, horizontal_size_value);
> -ui(12, vertical_size_value);
> +uir(12, horizontal_size_value, 1, 4095);
> +uir(12, vertical_size_value, 1, 4095);
>
> mpeg2->horizontal_size = current->horizontal_size_value;
> mpeg2->vertical_size = current->vertical_size_value;
> @@ -79,7 +79,7 @@ static int FUNC(user_data)(CodedBitstreamContext *ctx,
> RWContext *rw,
> #endif
>
> for (k = 0; k < current->user_data_length; k++)
> -xui(8, user_data, current->user_data[k], 0);
> +xui(8, user_data, current->user_data[k], 0, 255, 0);
This could include the subscript while you're changing it.
uis(8, user_data[k], 1, k);
>
> return 0;
> }
> @@ -125,9 +125,9 @@ static int
> FUNC(sequence_display_extension)(CodedBitstreamContext *ctx, RWContex
>
> ui(1, colour_description);
> if (current->colour_description) {
> -ui(8, colour_primaries);
> -ui(8, transfer_characteristics);
> -ui(8, matrix_coefficients);
> +uir(8, colour_primaries, 1, 255);
> +uir(8, transfer_characteristics, 1, 255);
> +uir(8, matrix_coefficients, 1, 255);
I'm a bit unsure about this one. While the zero value is indeed banned by the
standard, it isn't uncommon to find (at least in H.264) streams with zeroes in
these fields. (The libavcodec encoder for MPEG-2 is happy to write such a
stream, too.) Start code aliasing is presumably the reason for the standard
disallowing zeroes, but they probably won't actually be a problem unless
display_horizontal_size happens to have a specific range of bad values (in
which case we already fail in a different way).
> }
>
> ui(14, display_horizontal_size);
> @@ -366,16 +366,16 @@ static int FUNC(slice_header)(CodedBitstreamContext
> *ctx, RWContext *rw,
> if (!current->extra_information)
> return AVERROR(ENOMEM);
> for (k = 0; k < current->extra_information_length; k++) {
> -xui(1, extra_bit_slice, bit, 0);
> +xui(1, extra_bit_slice, bit, 1, 1, 0);
>
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
2019-04-28 23:34 GMT+02:00, Marton Balint : > > On Sun, 28 Apr 2019, Carl Eugen Hoyos wrote: > >> 2019-04-28 22:02 GMT+02:00, Marton Balint : >>> 2) Should patches using closed source libraries which are not >>> considered "System Libraries" according to the GPL be rejected? >> >> Do I understand correctly that this question is equivalent to >> requesting the removal of the decklink wrapper? > > I think not, because as far as I understand there is no debate that > DeckLink libraries are System Libraries DeckLink libraries are definitely not a system library. 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, Jean-Baptiste Kempf wrote: On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote: 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? You mean "major components"? (at no point does the GPLv2 mention "System Libraries". I meant the sytem libraries as in GPL v3. Regards, Marton ___ 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] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, Carl Eugen Hoyos wrote: 2019-04-28 22:02 GMT+02:00, Marton Balint : 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? Do I understand correctly that this question is equivalent to requesting the removal of the decklink wrapper? I think not, because as far as I understand there is no debate that DeckLink libraries are System Libraries, because they are installed with the driver. http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241501.html Regards, Marton ___ 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] [DECISION] Project policy on closed source components
2019-04-28 23:29 GMT+02:00, Jean-Baptiste Kempf : > On Sun, 28 Apr 2019, at 22:44, Carl Eugen Hoyos wrote: >> 2019-04-28 22:02 GMT+02:00, Marton Balint : >> > 2) Should patches using closed source libraries which are not >> > considered "System Libraries" according to the GPL be rejected? >> >> Do I understand correctly that this question is equivalent to >> requesting the removal of the decklink wrapper? > > No, it is not. I don't think you can answer this question. But I hope it is obvious to everybody that if a majority votes yes on above question, we will have to remove the decklink wrapper. 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".
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, at 22:02, Marton Balint wrote: > 2) Should patches using closed source libraries which are not considered > "System Libraries" according to the GPL be rejected? You mean "major components"? (at no point does the GPLv2 mention "System Libraries". -- 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] [DECISION] Project policy on closed source components
On 28/04/2019 21:02, Marton Balint wrote: > ... closed source libraries which are not considered "System Libraries" > according to the GPL ... Please can you define this in a precise way which does not rely upon interpreting the GPL? There are certainly differing opinions about exactly what it means, and we need to know exactly what we are voting on. For example, you might consider rejecting a library only if none of the following are true: (1) Full human-readable source code is available for everything which runs on the same processor as FFmpeg does. (2) It implements a standardised API independent of any particular vendor (common to at least three separate vendors?). (3) It interfaces with some common consumer hardware: a whole PC-like system containing it can be widely purchased off-the-shelf for less than 1000 EUR/USD, with all closed-source components provided as part of the operating system. ... or something like that. Thanks, - Mark ___ 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] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, at 22:44, Carl Eugen Hoyos wrote: > 2019-04-28 22:02 GMT+02:00, Marton Balint : > > 2) Should patches using closed source libraries which are not > > considered "System Libraries" according to the GPL be rejected? > > Do I understand correctly that this question is equivalent to > requesting the removal of the decklink wrapper? No, it is not. Decklink is a set of BSD headers that are useful to access the driver, like nVidia. This would be considered "major components". As it is a curious case (BSD headers in a .zip that has a EULA), I would suggest a vote only on this part. -- 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] [DECISION] Project policy on closed source components
> > [1] http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242574.html There are numerous inactive people in the voting committee, some for years. Why are they arbitrarily allowed to vote on this? 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] [DECISION] Project policy on closed source components
On Sun, 28 Apr 2019, James Almer wrote: On 4/28/2019 5:02 PM, Marton Balint wrote: Hi All, There has been discussion on the mailing list several times about the inclusion of support for closed source components (codecs, formats, filters, etc) in the main ffmpeg codebase. Also the removal of libNDI happened without general consensus, so a vote is necessary to justify the removal. So here is a call to the voting committee [1] to decide on the following two questions: 1) Should libNDI support be removed from the ffmpeg codebase? This question needs some context for people to know why the library was removed, and what they are voting for. The trac ticket and relevant discussion threads should be linked to, or summarized. http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/237070.html http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/240878.html http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241233.html https://trac.ffmpeg.org/ticket/7589 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? In addition to the threads above these might also be of some relevance: https://ffmpeg-devel.ffmpeg.narkive.com/Ok5y3HXO/patch-0-3-codec-wrapper-for-librv11-and-rmhd-muxer-demuxer#post1 http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/240913.html http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241067.html Feel free to add more threads with relevant discussion if I missed them. Deadline for voting is 7 days from now. This could use a longer deadline, IMO. Especially if discussion could happen before some people decide to cast a vote. Ok, let's it make 14 days from now the deadline then. Thanks, Marton ___ 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] avfilter/avf_showspectrum: add log scale for frequency plot
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 26
libavfilter/avf_showspectrum.c | 239 -
2 files changed, 200 insertions(+), 65 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 14c33ecf90..7cc3937b40 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6,6 +6,19 @@ logarithmic
Default value is @samp{sqrt}.
+@item fscale
+Specify frequency scale.
+
+It accepts the following values:
+@table @samp
+@item lin
+linear
+@item log
+logarithmic
+@end table
+
+Default value is @samp{lin}.
+
@item saturation
Set saturation modifier for displayed colors. Negative values provide
alternative color scheme. @code{0} is no saturation at all.
@@ -22398,6 +22411,19 @@ logarithmic
@end table
Default value is @samp{log}.
+@item fscale
+Specify frequency scale.
+
+It accepts the following values:
+@table @samp
+@item lin
+linear
+@item log
+logarithmic
+@end table
+
+Default value is @samp{lin}.
+
@item saturation
Set saturation modifier for displayed colors. Negative values provide
alternative color scheme. @code{0} is no saturation at all.
diff --git a/libavfilter/avf_showspectrum.c b/libavfilter/avf_showspectrum.c
index e8d3f1ec8d..b0b4e406ea 100644
--- a/libavfilter/avf_showspectrum.c
+++ b/libavfilter/avf_showspectrum.c
@@ -45,6 +45,7 @@
enum DisplayMode { COMBINED, SEPARATE, NB_MODES };
enum DataMode { D_MAGNITUDE, D_PHASE, NB_DMODES };
+enum FrequencyScale { F_LINEAR, F_LOG, NB_FSCALES };
enum DisplayScale { LINEAR, SQRT, CBRT, LOG, FOURTHRT, FIFTHRT, NB_SCALES };
enum ColorMode{ CHANNEL, INTENSITY, RAINBOW, MORELAND, NEBULAE, FIRE,
FIERY, FRUIT, COOL, MAGMA, GREEN, VIRIDIS, PLASMA, CIVIDIS, TERRAIN, NB_CLMODES
};
enum SlideMode{ REPLACE, SCROLL, FULLFRAME, RSCROLL, NB_SLIDES };
@@ -65,6 +66,7 @@ typedef struct ShowSpectrumContext {
int mode; ///< channel display mode
int color_mode; ///< display color scheme
int scale;
+int fscale;
float saturation; ///< color saturation multiplier
float rotation; ///< color rotation
int start, stop;///< zoom mode
@@ -95,6 +97,7 @@ typedef struct ShowSpectrumContext {
int single_pic;
int legend;
int start_x, start_y;
+int (*plot_channel)(AVFilterContext *ctx, void *arg, int jobnr, int
nb_jobs);
} ShowSpectrumContext;
#define OFFSET(x) offsetof(ShowSpectrumContext, x)
@@ -134,6 +137,9 @@ static const AVOption showspectrum_options[] = {
{ "log", "logarithmic", 0, AV_OPT_TYPE_CONST, {.i64=LOG},0, 0,
FLAGS, "scale" },
{ "4thrt","4th root",0, AV_OPT_TYPE_CONST, {.i64=FOURTHRT}, 0, 0,
FLAGS, "scale" },
{ "5thrt","5th root",0, AV_OPT_TYPE_CONST, {.i64=FIFTHRT}, 0, 0,
FLAGS, "scale" },
+{ "fscale", "set frequency scale", OFFSET(fscale), AV_OPT_TYPE_INT,
{.i64=F_LINEAR}, 0, NB_FSCALES-1, FLAGS, "fscale" },
+{ "lin", "linear", 0, AV_OPT_TYPE_CONST, {.i64=F_LINEAR}, 0, 0,
FLAGS, "fscale" },
+{ "log", "logarithmic", 0, AV_OPT_TYPE_CONST, {.i64=F_LOG},0, 0,
FLAGS, "fscale" },
{ "saturation", "color saturation multiplier", OFFSET(saturation),
AV_OPT_TYPE_FLOAT, {.dbl = 1}, -10, 10, FLAGS },
{ "win_func", "set window function", OFFSET(win_func), AV_OPT_TYPE_INT,
{.i64 = WFUNC_HANNING}, 0, NB_WFUNC-1, FLAGS, "win_func" },
{ "rect", "Rectangular", 0, AV_OPT_TYPE_CONST,
{.i64=WFUNC_RECT}, 0, 0, FLAGS, "win_func" },
@@ -623,6 +629,56 @@ static char *get_time(AVFilterContext *ctx, float seconds,
int x)
return units;
}
+static float log_scale(const float value, const float min, const float max)
+{
+if (value < min)
+return min;
+if (value > max)
+return max;
+
+{
+const float b = logf(max / min) / (max - min);
+const float a = max / expf(max * b);
+
+return expf(value * b) * a;
+}
+}
+
+static float get_log_hz(const int bin, const int num_bins, const float
sample_rate)
+{
+const float max_freq = sample_rate / 2;
+const float hz_per_bin = max_freq / num_bins;
+const float freq = hz_per_bin * bin;
+const float scaled_freq = log_scale(freq + 1, 20, max_freq) - 1;
+
+return num_bins * scaled_freq / max_freq;
+}
+
+static float inv_log_scale(const float value, const float min, const float max)
+{
+if (value < min)
+return min;
+if (value > max)
+return max;
+
+{
+const float b = logf(max / min) / (max - min);
+const float a = max / expf(max * b);
+
+return logf(value / a) / b;
+}
+}
+
+static float bin_pos(const int bin, const int num_bins, const float
sample_rate)
+{
+const float max_freq = sample_rate / 2;
+const float hz_per_bin = max_freq / num_bins;
+const float freq = hz_per_bin * bin;
+const float scaled_freq = inv_log_scale(freq + 1, 20, max_freq) - 1;
+
+return num_bins * scaled_freq
Re: [FFmpeg-devel] [DECISION] Project policy on closed source components
2019-04-28 22:02 GMT+02:00, Marton Balint : > 2) Should patches using closed source libraries which are not > considered "System Libraries" according to the GPL be rejected? Do I understand correctly that this question is equivalent to requesting the removal of the decklink wrapper? 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".
Re: [FFmpeg-devel] [PATCH 4/5] avformat/mxfdec: take into account run-in in find_partition_by_offset
On Sun, 14 Apr 2019, Tomas Härdin wrote:
fre 2019-04-12 klockan 01:09 +0200 skrev Marton Balint:
> Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 236294880e..6f0f87763d 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -433,15 +433,15 @@ static int find_body_sid_by_offset(MXFContext *mxf,
int64_t offset)
Maybe we should rename the function to make it clear offset is
absolute?
{
// we look for partition where the offset is placed
int a, b, m;
-int64_t this_partition;
+int64_t pack_ofs;
a = -1;
b = mxf->partitions_count;
while (b - a > 1) {
-m = (a + b) >> 1;
-this_partition = mxf->partitions[m].this_partition;
-if (this_partition <= offset)
+m = (a + b) >> 1;
+pack_ofs = mxf->partitions[m].pack_ofs;
+if (pack_ofs <= offset)
a = m;
else
b = m;
Looks OK otherwise
Renamed the function, and applied.
Thanks,
Marton
___
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 5/5] avformat/mxfdec: fix and enhance RIP KLV length checks
On Sun, 14 Apr 2019, Tomas Härdin wrote:
fre 2019-04-12 klockan 01:09 +0200 skrev Marton Balint:
KLV length is BER encoded (variable size), but the code assumed the encoding to
always use 4 bytes.
Fixes parsing Random Index Pack in
samples/MXF/issue2160/PW0805A0V01.4C5B5636.EFA330.mxf.
> Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 6f0f87763d..a69f2f1996 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -3126,9 +3126,12 @@ static void mxf_read_random_index_pack(AVFormatContext
*s)
goto end;
avio_seek(s->pb, file_size - length, SEEK_SET);
if (klv_read_packet(, s->pb) < 0 ||
-!IS_KLV_KEY(klv.key, mxf_random_index_pack_key) ||
-klv.length != length - 20)
+!IS_KLV_KEY(klv.key, mxf_random_index_pack_key))
goto end;
+if (klv.next_klv != file_size || klv.length <= 4 || (klv.length - 4) % 12)
{
+av_log(s, AV_LOG_WARNING, "Invalid RIP KLV length\n");
+goto end;
+}
Looks OK.
Thanks, applied.
Aside: Looking at klv_read_packet(), I'm suspicious of its use of
mxf_read_sync(). That feels like something that only belongs in
mxf_read_header(), to deal with run-in. Baptiste added it in
cabe2527ef3. FATE passes without it.
I wonder if it is there to allow some byte based seeking or handle damaged
files more gracefully? I agree it is strange a bit, maybe Baptise can chip
in...
Regards,
Marton
___
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/5] avformat/mxfdec: rework mxf_essence_container_end
On Sun, 14 Apr 2019, Tomas Härdin wrote:
fre 2019-04-12 klockan 01:09 +0200 skrev Marton Balint:
We find the last essence container much faster if we go through the partitions
backwards...
Good catch
> Signed-off-by: Marton Balint
---
libavformat/mxfdec.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index c3892a1037..18c038c3f6 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -1545,10 +1545,7 @@ static int mxf_absolute_bodysid_offset(MXFContext *mxf,
int body_sid, int64_t of
*/
static int64_t mxf_essence_container_end(MXFContext *mxf, int body_sid)
{
-int x;
-int64_t ret = 0;
-
-for (x = 0; x < mxf->partitions_count; x++) {
+for (int x = mxf->partitions_count - 1; x >= 0; x--) {
This is C99, but I think we allow that these days. Maybe someone
objects? Else looks OK
Thanks, applied.
Regards,
Marton
___
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] [DECISION] Project policy on closed source components
On 4/28/2019 5:02 PM, Marton Balint wrote: > Hi All, > > There has been discussion on the mailing list several times about the > inclusion of support for closed source components (codecs, formats, > filters, etc) in the main ffmpeg codebase. > > Also the removal of libNDI happened without general consensus, so a vote > is necessary to justify the removal. > > So here is a call to the voting committee [1] to decide on the following > two questions: > > 1) Should libNDI support be removed from the ffmpeg codebase? This question needs some context for people to know why the library was removed, and what they are voting for. The trac ticket and relevant discussion threads should be linked to, or summarized. > > 2) Should patches using closed source libraries which are not considered > "System Libraries" according to the GPL be rejected? > > Deadline for voting is 7 days from now. This could use a longer deadline, IMO. Especially if discussion could happen before some people decide to cast a vote. > > Thanks, > Marton > > [1] http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242574.html > ___ > 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] [PATCHv2 3/5] avformat/mxfdec: guess wrapping of tracks by other tracks with the same body sid
On Fri, 26 Apr 2019, Tomas Härdin wrote:
ons 2019-04-24 klockan 22:31 +0200 skrev Marton Balint:
On Wed, 24 Apr 2019, Tomas Härdin wrote:
> mån 2019-04-22 klockan 19:15 +0200 skrev Marton Balint:
> > This affects the following samples:
> >
> > samples/ffmpeg-bugs/roundup/issue1775/av_seek_frame_failure.mxf
> > samples/ffmpeg-bugs/trac/ticket1957/16ch.mxf
> > samples/ffmpeg-bugs/trac/ticket5016/r0.mxf
> > samples/ffmpeg-bugs/trac/ticket5016/r1.mxf
> > samples/ffmpeg-bugs/trac/ticket5316/hq.MXF
> > samples/ffmpeg-bugs/trac/ticket5316/hqx.MXF
> >
> > Some AVPacket->pos values are changed because for frame wrapped tracks we point
> > to the KLV offset and not the data.
> >
> > > Signed-off-by: Marton Balint
> >
> > ---
> > libavformat/mxfdec.c | 18 ++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 2c44852062..034025bcaa 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -2553,6 +2553,24 @@ static int mxf_parse_structural_metadata(MXFContext
*mxf)
> > }
> > }
> >
> > +for (int i = 0; i < mxf->fc->nb_streams; i++) {
> > +MXFTrack *track1 = mxf->fc->streams[i]->priv_data;
> > +if (track1 && track1->body_sid) {
> > +for (int j = i + 1; j < mxf->fc->nb_streams; j++) {
> > +MXFTrack *track2 = mxf->fc->streams[j]->priv_data;
> > +if (track2 && track1->body_sid == track2->body_sid &&
track1->wrapping != track2->wrapping) {
> > +if (track1->wrapping == UnknownWrapped)
> > +track1->wrapping = track2->wrapping;
> > +else if (track2->wrapping == UnknownWrapped)
> > +track2->wrapping = track1->wrapping;
> > +else
> > +av_log(mxf->fc, AV_LOG_ERROR, "stream %d and stream %d
have the same BodySID (%d) "
> > + "with different
wrapping\n", i, j, track1->body_sid);
> > +}
> > +}
> > +}
> > +}
>
> Don't we have mxf_get_wrapping_by_body_sid() for this?
>
That is similar, yes, but in order to find and warn about every mismatch
between frame wrapped and clip wrapped as you suggested we cannot use it
here directly (mxf_get_wrapping_by_body_sid finds the first stream with a
known wrapping and a matching body sid).
Also we cannot warn in mxf_get_wrapping_by_body_sid because that is called
for each partition.
Ah, OK then :)
Thanks, applied.
Regards,
Marton
___
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] [DECISION] Project policy on closed source components
Hi All, There has been discussion on the mailing list several times about the inclusion of support for closed source components (codecs, formats, filters, etc) in the main ffmpeg codebase. Also the removal of libNDI happened without general consensus, so a vote is necessary to justify the removal. So here is a call to the voting committee [1] to decide on the following two questions: 1) Should libNDI support be removed from the ffmpeg codebase? 2) Should patches using closed source libraries which are not considered "System Libraries" according to the GPL be rejected? Deadline for voting is 7 days from now. Thanks, Marton [1] http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242574.html ___ 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/scpr3: add missing check for decode_value3() return value
2019-04-26 17:31 GMT+02:00, James Almer : > Fixes ticket #7866. > > Signed-off-by: James Almer > --- > libavcodec/scpr3.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavcodec/scpr3.c b/libavcodec/scpr3.c > index f92ccfa902..5cfad9f4d2 100644 > --- a/libavcodec/scpr3.c > +++ b/libavcodec/scpr3.c > @@ -1038,6 +1038,9 @@ static int decompress_p3(AVCodecContext *avctx, > s->range_model3.freqs[1], > s->range_model3.cnts, > s->range_model3.dectab, ); > +if (ret < 0) > +return ret; > + > min += temp << 8; Why is it a problem to access an uninitialized value? 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".
Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort decoder/encoder/filter/... names in alphabet order
On 2019-04-28 07:42 +, Guo, Yejun wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Alexander Strasser
> > Sent: Sunday, April 28, 2019 9:18 AM
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort
> > decoder/encoder/filter/... names in alphabet order
> >
> >
> > What do you think about using awk instead of shell?
> >
> > I have 2 POC patches attached. It's probably not 100% correct yet,
> > but it kind of demonstrates what it would look like.
> >
> > The main advantage of using awk, is that it's more elegant and
> > shorter. It's probably also less risky, because it's more isolated,
> > e.g. as it was explained by avih, there is no widely supported way
> > for locals across shells. We already use awk in configure for
> > mandatory functions, so it's no new dependency.
> >
> > Please comment on the awk approach.
>
> I did some change to make it correct on ubuntu 16.04, but looks issue on
> windows mingw.
>
> print_in_columns() {
> sort | tr '\n' ' ' | awk -v width="$ncols" '
> {
> #add int()
> num_cols = int(width / 24); num_rows = int((NF + num_cols-1) /
> num_cols);
The added int() calls looks right.
> y = x = 1;
> for (i = 1; i <= NF; i++) {
> if (y > num_rows) {
> y = 1; x++;
> }
> d[x,y] = $i;
> y++;
> }
>
> print width
> print num_cols
> print num_rows
> print NF
>
> for (y = 1; y <= num_rows; y++) {
> for (x = 1; x <= num_cols; x++) {
> # it does not work for the case that the last column is not
> fully filled
> #line = sprintf(x != num_cols ? "%s%-24s" : "%s%s", line,
> d[x,y]);
> line = sprintf("%s%-24s", line, d[x,y]);
You mean it doesn't work in the way that there will be trailing spaces
in the column before the last one which is partially empty, right?
But the output looked right and there were never trailing spaces in the
last column, right?
BTW I changed the algorithm here, because I thought it might be easier
to unterstand. I will also try the algorithm, you implemented in shell.
> }
> print line;
> line = "";
> }
> }' | sed 's/ *$//'
> }
>
> on ubuntu 16.04, the output is:
> Enabled bsfs:
> 135
> 5
> 7
> 33
> aac_adtstoasc extract_extradata hevc_mp4toannexb
> mpeg4_unpack_bframestruehd_core
> av1_frame_split filter_unitsimx_dump_header noise
> vp9_metadata
> av1_metadatah264_metadata mjpeg2jpeg null
> vp9_raw_reorder
> chomp h264_mp4toannexbmjpega_dump_header
> prores_metadata vp9_superframe
> dca_coreh264_redundant_pps mov2textsub
> remove_extradatavp9_superframe_split
> dump_extradata hapqa_extract mp3_header_decompress
> text2movsub
> eac3_core hevc_metadata mpeg2_metadata
> trace_headers
>
> while on windows, the output is:
> Enabled bsfs:
> 72
> 3
> 11
> 33
> noiseh264_redundant_pps
> nullextract
> prores_metadata
>remove_extradatamp4toannexb
> text2movsubdump_header
> trace_headers
> truehd_corepega_dump_header
> vp9_metadata
> vp9_raw_reorderader_decompress
> vp9_superframea
>vp9_superframe_splitames
Wild guess: CR LF line endings are emitted somewhere and the CRs stay in
the input. Your terminal resets the cursor to the start of the line when
interpreting the midline CRs.
Does it work if you extend the tr in print_in_columns like below?
sort | tr '\r\n' ' ' | awk -v width="$ncols" '
> I did a quick check, but has not found the root cause yet.
>
>
> >
> > I'm not against the shell way, or a mixed approach, but before going
> > either way and pushing I would rather have some more testing;
> > especially on more exotic platforms.
Thanks for testing and looking into it!
Alexander
___
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/cinepak: Check slice_size before allocating image
sön 2019-04-28 klockan 11:42 +0200 skrev Michael Niedermayer:
> Fixes: Timeout (16sec -> 125msec)
> Fixes:
> 14283/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5742851457024000
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> ---
> libavcodec/cinepak.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
> index 9b0077402f..d26c505222 100644
> --- a/libavcodec/cinepak.c
> +++ b/libavcodec/cinepak.c
> @@ -353,6 +353,13 @@ static int cinepak_predecode_check (CinepakContext *s)
> if (s->size < 10 + s->sega_film_skip_bytes + num_strips * 12)
> return AVERROR_INVALIDDATA;
>
> +if (num_strips) {
> +uint8_t *data = s->data + 10 + s->sega_film_skip_bytes;
> +int strip_size = AV_RB24 (data + 1);
Should be OK since the check just before this ensures data[0..11] are
valid
/Tomas
___
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] avfilter: add bilateral filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 25
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_gblur.c | 257 ++-
4 files changed, 280 insertions(+), 4 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 14c33ecf90..04ca946d25 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5953,6 +5953,31 @@ The filter accepts the following option:
Set the minimal luminance value. Default is @code{16}.
@end table
+@section bilateral
+Apply bilateral filter, spatial smoothing while preserving edges.
+
+The filter accepts the following options:
+@table @option
+@item sigmaS
+Set sigma of gaussian function to calculate spatial weight.
+Allowed range is 0 to 1024. Default is 3.
+
+@item sigmaR
+Set sigma of gaussian function to calculate range weight.
+Allowed range is 0 to 1024. Default is 0.5
+
+@item steps
+Set number of gaussian steps. Default is 1.
+Alowed range is from 1 to 6.
+
+@item bsteps
+Set number of bilateral steps. Default is 4.
+Alowed range is from 2 to 256.
+
+@item planes
+Set planes to filter. Default is first only.
+@end table
+
@section bitplanenoise
Show and measure bit plane noise.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 59d12ce069..a2e1477313 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -160,6 +160,7 @@ OBJS-$(CONFIG_AVGBLUR_OPENCL_FILTER) +=
vf_avgblur_opencl.o opencl.o \
opencl/avgblur.o boxblur.o
OBJS-$(CONFIG_BBOX_FILTER) += bbox.o vf_bbox.o
OBJS-$(CONFIG_BENCH_FILTER) += f_bench.o
+OBJS-$(CONFIG_BILATERAL_FILTER) += vf_gblur.o
OBJS-$(CONFIG_BITPLANENOISE_FILTER) += vf_bitplanenoise.o
OBJS-$(CONFIG_BLACKDETECT_FILTER)+= vf_blackdetect.o
OBJS-$(CONFIG_BLACKFRAME_FILTER) += vf_blackframe.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ae725cb0e0..931ff9d6c5 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -150,6 +150,7 @@ extern AVFilter ff_vf_avgblur;
extern AVFilter ff_vf_avgblur_opencl;
extern AVFilter ff_vf_bbox;
extern AVFilter ff_vf_bench;
+extern AVFilter ff_vf_bilateral;
extern AVFilter ff_vf_bitplanenoise;
extern AVFilter ff_vf_blackdetect;
extern AVFilter ff_vf_blackframe;
diff --git a/libavfilter/vf_gblur.c b/libavfilter/vf_gblur.c
index f77a3fffc3..778163f53e 100644
--- a/libavfilter/vf_gblur.c
+++ b/libavfilter/vf_gblur.c
@@ -38,6 +38,8 @@ typedef struct GBlurContext {
float sigma;
float sigmaV;
+float sigmaS;
+float sigmaR;
int steps;
int planes;
@@ -45,6 +47,8 @@ typedef struct GBlurContext {
int planewidth[4];
int planeheight[4];
float *buffer;
+float *den;
+float *num;
float boundaryscale;
float boundaryscaleV;
float postscale;
@@ -52,6 +56,11 @@ typedef struct GBlurContext {
float nu;
float nuV;
int nb_planes;
+
+float lut[65536];
+int blut[256];
+float *bbufers[256];
+int bsteps;
} GBlurContext;
#define OFFSET(x) offsetof(GBlurContext, x)
@@ -212,7 +221,8 @@ static int query_formats(AVFilterContext *ctx)
static int config_input(AVFilterLink *inlink)
{
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
-GBlurContext *s = inlink->dst->priv;
+AVFilterContext *ctx = inlink->dst;
+GBlurContext *s = ctx->priv;
s->depth = desc->comp[0].depth;
s->planewidth[1] = s->planewidth[2] = AV_CEIL_RSHIFT(inlink->w,
desc->log2_chroma_w);
@@ -222,9 +232,11 @@ static int config_input(AVFilterLink *inlink)
s->nb_planes = av_pix_fmt_count_planes(inlink->format);
-s->buffer = av_malloc_array(inlink->w, inlink->h * sizeof(*s->buffer));
-if (!s->buffer)
-return AVERROR(ENOMEM);
+if (strcmp(ctx->filter->name, "bilateral")) {
+s->buffer = av_malloc_array(inlink->w, inlink->h * sizeof(*s->buffer));
+if (!s->buffer)
+return AVERROR(ENOMEM);
+}
if (s->sigmaV < 0) {
s->sigmaV = s->sigma;
@@ -332,10 +344,19 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
static av_cold void uninit(AVFilterContext *ctx)
{
GBlurContext *s = ctx->priv;
+int i;
+av_freep(>den);
+av_freep(>num);
av_freep(>buffer);
+
+for (i = 0; i < s->bsteps; i++) {
+av_freep(>bbufers[i]);
+}
}
+#if CONFIG_GBLUR_FILTER
+
static const AVFilterPad gblur_inputs[] = {
{
.name = "default",
@@ -365,3 +386,231 @@ AVFilter ff_vf_gblur = {
.outputs = gblur_outputs,
.flags = AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC |
AVFILTER_FLAG_SLICE_THREADS,
};
+#endif /* CONFIG_GBLUR_FILTER */
+
+#if CONFIG_BILATERAL_FILTER
+
+static const AVOption bilateral_options[] = {
+{ "sigmaS", "set sigma S",OFFSET(sigmaS),
AV_OPT_TYPE_FLOAT, {.dbl=3}, 0.0,
Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort decoder/encoder/filter/... names in alphabet order
On 2019-04-28 03:11 +, avih wrote: > > What do you think about using awk instead of shell? > > No objection here, especially if it's more robust in some ways than this > or other shell code (though personally I'm not fluent in awk). > > My only concern was preventing a considerable performance impact which could > otherwise be avoided relatively easily, and with which I thought I could help. Yes, thank you. Very much appreciated! Alexander ___ 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/mux: skip parameter and pts checks for data muxer
On 28-04-2019 04:15 PM, Nicolas George wrote: Gyan (12019-04-28): Corrupt streams in sufficiently intact containers (MP4, TS) so they can be demuxed but decoder context fields are incomplete/invalid, so ffmpeg won't streamcopy-mux them. Depending on the exact situation, I would use a repair or analysis tool to check them or supply an alternate esds..etc And you want to just dump the packets payload in a file? With the ffmpeg command-line? Then I suggest to implement that as a ffmpeg option: ffmpeg -dump_stream:0 stream0.bin -i damaged.mp4 -f null - I'll try this but I don't think the command as presented will work because a) there's no codec option set, so ffmpeg has to decode frames and that will fail for damaged streams. But this can be quickly remedied by adding -c copy b) ffmpeg will call avformat_write_header for the output, which will likely fail because of the aforementioned codec parameter issues. When that happens, ffmpeg will exit and only the packets demuxed and flushed up to that point will be present in the dumped file. This could possibly be averted by providing a valid dummy input and mapping only that to the output. However, I believe ffmpeg will then exit when that output is marked as finished, but the dumped stream may not be because the main transcode() loop isn't sensitive to it. The pipeline for dumping damaged streams is identical to dumping valid streams except for the part when timestamps are regulated and codec fields validated for the target muxer, which is what my patch disables for a single muxer that doesn't need them. I don't see much (any?) "wasted" processing with my patch, relative to streamcopying a valid stream. Gyan ___ 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] lavc/qsvenc: disable CO3 for mpeg2
Currenntly there is no any function of CO3 appled to mpeg2,
and enabling for mpeg2 it will cause regression with some old
libmfx libaries (see tiket #7839), so disable CO3 for mpeg2.
Also add runtime version check for CO3.
Signed-off-by: Zhong Li
---
libavcodec/qsvenc.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index a03ab69590..e0886aeedb 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -750,15 +750,18 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
#endif
}
+
+if (avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO &&
QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 11)) {
#if QSV_HAVE_CO3
-q->extco3.Header.BufferId = MFX_EXTBUFF_CODING_OPTION3;
-q->extco3.Header.BufferSz = sizeof(q->extco3);
+q->extco3.Header.BufferId = MFX_EXTBUFF_CODING_OPTION3;
+q->extco3.Header.BufferSz = sizeof(q->extco3);
#if QSV_HAVE_GPB
-if (avctx->codec_id == AV_CODEC_ID_HEVC)
-q->extco3.GPB = q->gpb ? MFX_CODINGOPTION_ON :
MFX_CODINGOPTION_OFF;
+if (avctx->codec_id == AV_CODEC_ID_HEVC)
+q->extco3.GPB = q->gpb ? MFX_CODINGOPTION_ON :
MFX_CODINGOPTION_OFF;
#endif
-q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer
*)>extco3;
+q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer
*)>extco3;
#endif
+}
}
if (!check_enc_param(avctx,q)) {
--
2.17.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] libavfilter: Add more operation supports in FFmpeg dnn native mode.
> -原始邮件-
> 发件人: "myp...@gmail.com"
> 发送时间: 2019-04-28 18:28:21 (星期日)
> 收件人: "FFmpeg development discussions and patches"
> 抄送:
> 主题: Re: [FFmpeg-devel] [PATCH] libavfilter: Add more operation supports in
> FFmpeg dnn native mode.
>
> On Sun, Apr 28, 2019 at 5:27 PM wrote:
> >
> > This patch is for the support of derain filter project in GSoC. It adds
> > supports for the following operations:
> >
> >
> >
> >
> > (1) Conv padding method: "SAME" and "VALID"
> >
> > (2) Dilation
> >
> > (3) Activation: "NONE" and "LEAKY_RELU"
> >
> >
> >
> >
> > These operations are all needed in derain filter. And if modify the dnn
> > native mode in FFmpeg, the generation process of Super Resolution model
> > should be changed accordingly, e.g. add padding method parameter (= 0) and
> > dilation parameter (= 1).
> >
> >
> >
> >
> > In addition, I have a question about the Super Resulotion implementation.
> > The model training process of SR uses "VALID" method. According to my
> > understanding of "VALID" mode in tensorflow, the size of output image
> > should be smaller than the current design in SR. Because pixels near the
> > boundary are not processed in "VALID" mode, however, these unprocessed
> > pixels are filled with adjacent pixels in current dnn native mode. I wonder
> > why to do like this here.
> >
> >
> >
> >
> > From 4d92ef21a5acf064122c51f442d0e2f5437b3343 Mon Sep 17 00:00:00 2001
> > From: Xuewei Meng
> > Date: Sun, 28 Apr 2019 17:21:35 +0800
> > Subject: [PATCH] Add operation supports in dnn_native
> >
> > Signed-off-by: Xuewei Meng
> > ---
> > libavfilter/dnn_backend_native.c | 36 +---
> > libavfilter/dnn_backend_native.h | 6 +-
> > 2 files changed, 29 insertions(+), 13 deletions(-)
> >
> > diff --git a/libavfilter/dnn_backend_native.c
> > b/libavfilter/dnn_backend_native.c
> > index 70d857f5f2..0e3ef5d64d 100644
> > --- a/libavfilter/dnn_backend_native.c
> > +++ b/libavfilter/dnn_backend_native.c
> > @@ -157,13 +157,15 @@ DNNModel *ff_dnn_load_model_native(const char
> > *model_filename)
> > ff_dnn_free_model_native();
> > return NULL;
> > }
> > +conv_params->dilation = (int32_t)avio_rl32(model_file_context);
> > +conv_params->padding_method =
> > (int32_t)avio_rl32(model_file_context);
> > conv_params->activation =
> > (int32_t)avio_rl32(model_file_context);
> > conv_params->input_num =
> > (int32_t)avio_rl32(model_file_context);
> > conv_params->output_num =
> > (int32_t)avio_rl32(model_file_context);
> > conv_params->kernel_size =
> > (int32_t)avio_rl32(model_file_context);
> > kernel_size = conv_params->input_num * conv_params->output_num
> > *
> >conv_params->kernel_size *
> > conv_params->kernel_size;
> > -dnn_size += 16 + (kernel_size + conv_params->output_num << 2);
> > +dnn_size += 24 + (kernel_size + conv_params->output_num << 2);
> Add some comments for the number 16 or 24 ?
dnn_size is the bytes of dnn model parameters. Because of the adding of
parameter "conv_params->dilation" and "conv_params->padding_method", dnn_size
shoule be added by 8.
> > if (dnn_size > file_size || conv_params->input_num <= 0 ||
> > conv_params->output_num <= 0 || conv_params->kernel_size
> > <= 0){
> > avio_closep(_file_context);
> > @@ -221,23 +223,28 @@ DNNModel *ff_dnn_load_model_native(const char
> > *model_filename)
> >
> > static void convolve(const float *input, float *output, const
> > ConvolutionalParams *conv_params, int width, int height)
> > {
> > -int y, x, n_filter, ch, kernel_y, kernel_x;
> Why?
Because I think it is better to definite the variables when using them in for
loop.
> > int radius = conv_params->kernel_size >> 1;
> > int src_linesize = width * conv_params->input_num;
> > int filter_linesize = conv_params->kernel_size *
> > conv_params->input_num;
> > int filter_size = conv_params->kernel_size * filter_linesize;
> > +int pad_size = (conv_params->padding_method == VALID) ?
> > (conv_params->kernel_size - 1) / 2 * conv_params->dilation : 0;
> >
> > -for (y = 0; y < height; ++y){
> > -for (x = 0; x < width; ++x){
> > -for (n_filter = 0; n_filter < conv_params->output_num;
> > ++n_filter){
> > +for (int y = pad_size; y < height - pad_size; ++y){
> > +for (int x = pad_size; x < width - pad_size; ++x){
> > +for (int n_filter = 0; n_filter < conv_params->output_num;
> > ++n_filter){
> > output[n_filter] = conv_params->biases[n_filter];
> > -for (ch = 0; ch < conv_params->input_num; ++ch){
> > -for (kernel_y = 0; kernel_y <
> > conv_params->kernel_size; ++kernel_y){
> > -for (kernel_x = 0; kernel_x <
> >
Re: [FFmpeg-devel] [PATCH V1 0/2] Use avctx->framerate first for frame rate setting
On Sun, Apr 28, 2019 at 5:30 PM Gyan wrote: > > > > On 28-04-2019 07:19 AM, myp...@gmail.com wrote: > > On Sat, Apr 27, 2019 at 8:22 PM Gyan wrote: > >> > >> > >> On 27-04-2019 05:25 PM, Carl Eugen Hoyos wrote: > >>> 2019-04-27 13:17 GMT+02:00, Jun Zhao : > perfer avctx->framerate first than use avctx->time_base when > setting the frame rate to encoder. 1/time_base is not the > average frame rate if the frame rate is not constant. > >>> But why would the average framerate be a good choice to set > >>> the encoder timebase? > >>> > >> Also, note that x264/5 RC looks at the framerate. > >> See > >> https://code.videolan.org/videolan/x264/commit/c583687fab832ba7eaf8626048f05ad1f861a855 > >> > >> I can generate a difference with x264 by setting -enc_time_base to > >> different values (with vsync vfr). > >> Maybe check that this change does not lead to a significant change in > >> output. Although I think this would be still an improvement for those > >> cases where r_frame_rate >> avg_frame_rate > >> > >> Gyan > > Yes, framerate and time_base is not close correlation in vfr case, > > e,g, I can setting the framerate = 60fps, but time_base = 1/1000 s, > > then setting pts like: > > > > time_base = 1/1000 s = 1 millisecond > > framerate = 60 fps per second > > PTS 01633506683100 ... > > > > PTS delta 161717161717 ... > > > > we will get 16ms * 20 frames + 17 ms * 40 frames = 1000ms > > I'm aware of the relationship between TB and PTS. My point is x264's RC > adjusts its quantizer based on fps. You're changing that value so the > output bitrate will change for the same input with the same encoder > config if (avg_frame_rate) != (ticks * 1/TB). > > Gyan in fact，this is the purpose of this patch, we used FFmpeg API to setting the time_base/pts/framerate like above to tuning the PTS. ___ 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/mux: skip parameter and pts checks for data muxer
On 4/28/19, Gyan wrote: > > > On 28-04-2019 03:52 PM, Nicolas George wrote: >> Gyan (12019-04-26): >>> From 5ec154870d9c559037598b41736bf5b216a756e0 Mon Sep 17 00:00:00 2001 >>> From: Gyan Doshi >>> Date: Fri, 26 Apr 2019 18:31:33 +0530 >>> Subject: [PATCH] avformat/mux: skip parameter and pts checks for data >>> muxer >>> >>> Allows to dump a malformed stream for external inspection or repair. >> What is your exact use case? I think there are much simpler and much >> more robust solutions. > Corrupt streams in sufficiently intact containers (MP4, TS) so they can > be demuxed but decoder context fields are incomplete/invalid, so ffmpeg > won't streamcopy-mux them. > > Depending on the exact situation, I would use a repair or analysis tool > to check them or supply an alternate esds..etc > If this just dumps demuxed packets use: ffmpeg -i input -c:v copy -f rawvideo outv.raw ffmpeg -i input -c:a copy -f u8 outa.raw ___ 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/mux: skip parameter and pts checks for data muxer
Gyan (12019-04-28): > Corrupt streams in sufficiently intact containers (MP4, TS) so they can be > demuxed but decoder context fields are incomplete/invalid, so ffmpeg won't > streamcopy-mux them. > > Depending on the exact situation, I would use a repair or analysis tool to > check them or supply an alternate esds..etc And you want to just dump the packets payload in a file? With the ffmpeg command-line? Then I suggest to implement that as a ffmpeg option: ffmpeg -dump_stream:0 stream0.bin -i damaged.mp4 -f null - It is not efficient nor robust to have the packets go through all ffmpeg's and libavformat processing only to have an option to disable that processing. Regards, -- Nicolas George 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] avformat/mux: skip parameter and pts checks for data muxer
On 28-04-2019 03:52 PM, Nicolas George wrote: Gyan (12019-04-26): From 5ec154870d9c559037598b41736bf5b216a756e0 Mon Sep 17 00:00:00 2001 From: Gyan Doshi Date: Fri, 26 Apr 2019 18:31:33 +0530 Subject: [PATCH] avformat/mux: skip parameter and pts checks for data muxer Allows to dump a malformed stream for external inspection or repair. What is your exact use case? I think there are much simpler and much more robust solutions. Corrupt streams in sufficiently intact containers (MP4, TS) so they can be demuxed but decoder context fields are incomplete/invalid, so ffmpeg won't streamcopy-mux them. Depending on the exact situation, I would use a repair or analysis tool to check them or supply an alternate esds..etc Gyan ___ 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/pngdec: Check nb_blocks
On 4/28/19, Michael Niedermayer wrote:
> Fixes: Timeout (23sec -> 0.5sec)
> Fixes:
> 14329/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LSCR_fuzzer-5679252923482112
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/pngdec.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index 6a681be29d..1dcde6cbc9 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -1541,6 +1541,8 @@ static int decode_frame_lscr(AVCodecContext *avctx,
> return ret;
>
> nb_blocks = bytestream2_get_le16(gb);
> +if (2 + nb_blocks * 12 > bytestream2_get_bytes_left(gb))
I prefer if this is not reversed.
> +return AVERROR_INVALIDDATA;
>
> if (s->last_picture.f->data[0]) {
> ret = av_frame_copy(frame, s->last_picture.f);
> --
> 2.21.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] avformat/mux: skip parameter and pts checks for data muxer
On 28-04-2019 03:40 PM, Hendrik Leppkes wrote:
On Sun, Apr 28, 2019 at 11:57 AM Michael Niedermayer
wrote:
On Sat, Apr 27, 2019 at 10:01:53AM +0530, Gyan wrote:
On 27-04-2019 01:32 AM, Michael Niedermayer wrote:
On Fri, Apr 26, 2019 at 06:38:37PM +0530, Gyan wrote:
mux.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
d94a699f5dbc31a8ee8b7d1bdb33004d9cd95d46
0001-avformat-mux-skip-parameter-and-pts-checks-for-data-.patch
From 5ec154870d9c559037598b41736bf5b216a756e0 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Fri, 26 Apr 2019 18:31:33 +0530
Subject: [PATCH] avformat/mux: skip parameter and pts checks for data muxer
Allows to dump a malformed stream for external inspection or repair.
---
libavformat/mux.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 83fe1de78f..3699b572f2 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -290,6 +290,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
goto fail;
}
+if (!strcmp(of->name, "data"))
+goto bypass;
+
for (i = 0; i < s->nb_streams; i++) {
st = s->streams[i];
par = st->codecpar;
@@ -409,6 +412,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
av_dict_set(>metadata, e->key, NULL, 0);
}
+bypass:
I think this skips a bit more than what would make sense
(for example priv_data allocation but thats not the only odd thing)
also iam not sure this is the ideal approuch.
I mean "I want to dump inavlid data in a data muxer for debug"
that seems a potentially valid request for other muxers too
like the image muxer producing individual files per frame and
so on
What would be the ideal approach?
I guess the ideal approuch would be to allow the developer who needs
this to override the check when the muxer in use can actually saftely
mux it without the specific check.
There are for example muxers which would not function properly with
backward going dts or something like that
We already have a variety of flags in place, like if a muxer doesn't
care for timestamps at all, flag it AVFMT_NOTIMESTAMPS, and have code
that checks timestamps check for this flag. Checks based on muxer
names seem generally always wrong.
AVFMT_NOTIMESTAMPS is somewhat overloaded. There are formats which don't
_write_ timestamps but still have some code which looks at them e.g.
image2 muxer or the mxf family of muxers. Some lavf code like
compute_muxer_pkt_fields is still run even for formats with the noTS
flag. lavf simply ignores errors for formats with the flag set.
However, if the dumped stream is audio with no sample rate set, then
init_pts will fail and so would compute. Hence the selection of muxer by
name.
Gyan
___
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] libavfilter: Add more operation supports in FFmpeg dnn native mode.
On Sun, Apr 28, 2019 at 5:27 PM wrote:
>
> This patch is for the support of derain filter project in GSoC. It adds
> supports for the following operations:
>
>
>
>
> (1) Conv padding method: "SAME" and "VALID"
>
> (2) Dilation
>
> (3) Activation: "NONE" and "LEAKY_RELU"
>
>
>
>
> These operations are all needed in derain filter. And if modify the dnn
> native mode in FFmpeg, the generation process of Super Resolution model
> should be changed accordingly, e.g. add padding method parameter (= 0) and
> dilation parameter (= 1).
>
>
>
>
> In addition, I have a question about the Super Resulotion implementation. The
> model training process of SR uses "VALID" method. According to my
> understanding of "VALID" mode in tensorflow, the size of output image should
> be smaller than the current design in SR. Because pixels near the boundary
> are not processed in "VALID" mode, however, these unprocessed pixels are
> filled with adjacent pixels in current dnn native mode. I wonder why to do
> like this here.
>
>
>
>
> From 4d92ef21a5acf064122c51f442d0e2f5437b3343 Mon Sep 17 00:00:00 2001
> From: Xuewei Meng
> Date: Sun, 28 Apr 2019 17:21:35 +0800
> Subject: [PATCH] Add operation supports in dnn_native
>
> Signed-off-by: Xuewei Meng
> ---
> libavfilter/dnn_backend_native.c | 36 +---
> libavfilter/dnn_backend_native.h | 6 +-
> 2 files changed, 29 insertions(+), 13 deletions(-)
>
> diff --git a/libavfilter/dnn_backend_native.c
> b/libavfilter/dnn_backend_native.c
> index 70d857f5f2..0e3ef5d64d 100644
> --- a/libavfilter/dnn_backend_native.c
> +++ b/libavfilter/dnn_backend_native.c
> @@ -157,13 +157,15 @@ DNNModel *ff_dnn_load_model_native(const char
> *model_filename)
> ff_dnn_free_model_native();
> return NULL;
> }
> +conv_params->dilation = (int32_t)avio_rl32(model_file_context);
> +conv_params->padding_method =
> (int32_t)avio_rl32(model_file_context);
> conv_params->activation = (int32_t)avio_rl32(model_file_context);
> conv_params->input_num = (int32_t)avio_rl32(model_file_context);
> conv_params->output_num = (int32_t)avio_rl32(model_file_context);
> conv_params->kernel_size =
> (int32_t)avio_rl32(model_file_context);
> kernel_size = conv_params->input_num * conv_params->output_num *
>conv_params->kernel_size *
> conv_params->kernel_size;
> -dnn_size += 16 + (kernel_size + conv_params->output_num << 2);
> +dnn_size += 24 + (kernel_size + conv_params->output_num << 2);
Add some comments for the number 16 or 24 ?
> if (dnn_size > file_size || conv_params->input_num <= 0 ||
> conv_params->output_num <= 0 || conv_params->kernel_size <=
> 0){
> avio_closep(_file_context);
> @@ -221,23 +223,28 @@ DNNModel *ff_dnn_load_model_native(const char
> *model_filename)
>
> static void convolve(const float *input, float *output, const
> ConvolutionalParams *conv_params, int width, int height)
> {
> -int y, x, n_filter, ch, kernel_y, kernel_x;
Why?
> int radius = conv_params->kernel_size >> 1;
> int src_linesize = width * conv_params->input_num;
> int filter_linesize = conv_params->kernel_size * conv_params->input_num;
> int filter_size = conv_params->kernel_size * filter_linesize;
> +int pad_size = (conv_params->padding_method == VALID) ?
> (conv_params->kernel_size - 1) / 2 * conv_params->dilation : 0;
>
> -for (y = 0; y < height; ++y){
> -for (x = 0; x < width; ++x){
> -for (n_filter = 0; n_filter < conv_params->output_num;
> ++n_filter){
> +for (int y = pad_size; y < height - pad_size; ++y){
> +for (int x = pad_size; x < width - pad_size; ++x){
> +for (int n_filter = 0; n_filter < conv_params->output_num;
> ++n_filter){
> output[n_filter] = conv_params->biases[n_filter];
> -for (ch = 0; ch < conv_params->input_num; ++ch){
> -for (kernel_y = 0; kernel_y < conv_params->kernel_size;
> ++kernel_y){
> -for (kernel_x = 0; kernel_x <
> conv_params->kernel_size; ++kernel_x){
> -output[n_filter] += input[CLAMP_TO_EDGE(y +
> kernel_y - radius, height) * src_linesize +
> - CLAMP_TO_EDGE(x +
> kernel_x - radius, width) * conv_params->input_num + ch] *
> -conv_params->kernel[n_filter
> * filter_size + kernel_y * filter_linesize +
> -kernel_x
> * conv_params->input_num + ch];
> +
> +for (int ch = 0; ch < conv_params->input_num; ++ch){
> +for (int kernel_y = 0; kernel_y <
> conv_params->kernel_size; ++kernel_y){
> +for (int kernel_x =
Re: [FFmpeg-devel] [PATCH v2 4/9] vp9_parser: Return stream properties
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Tuesday, April 2, 2019 7:40 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 4/9] vp9_parser: Return stream
> properties
>
> Rewrites the parser entirely, using CBS for header parsing.
> ---
> libavcodec/vp9_parser.c | 112 +---
> 1 file changed, 82 insertions(+), 30 deletions(-)
>
> diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c index
> c957a75667..6bf4f30e80 100644
> --- a/libavcodec/vp9_parser.c
> +++ b/libavcodec/vp9_parser.c
> @@ -1,8 +1,5 @@
> /*
> - * VP9 compatible video decoder
> - *
> - * Copyright (C) 2013 Ronald S. Bultje
> - * Copyright (C) 2013 Clément Bœsch
> + * VP9 parser
> *
> * This file is part of FFmpeg.
> *
> @@ -21,50 +18,105 @@
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> */
>
> -#include "libavutil/intreadwrite.h"
> -#include "libavcodec/get_bits.h"
> +#include "libavutil/avassert.h"
> +#include "cbs.h"
> +#include "cbs_vp9.h"
> #include "parser.h"
>
> -static int parse(AVCodecParserContext *ctx,
> - AVCodecContext *avctx,
> - const uint8_t **out_data, int *out_size,
> - const uint8_t *data, int size)
> +typedef struct VP9ParserContext {
> +CodedBitstreamContext *cbc;
> +VP9RawFrameHeader frame_header;
> +} VP9ParserContext;
> +
> +static const enum AVPixelFormat vp9_pix_fmts[3][2][2] = {
> +{ // 8-bit.
> +{ AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV440P },
> +{ AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV420P },
> +},
> +{ // 10-bit.
> +{ AV_PIX_FMT_YUV444P10, AV_PIX_FMT_YUV440P10 },
> +{ AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV420P10 },
> +},
> +{ // 12-bit.
> +{ AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV440P12 },
> +{ AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV420P12 },
> +},
> +};
> +
> +static int vp9_parser_parse(AVCodecParserContext *ctx,
> +AVCodecContext *avctx,
> +const uint8_t **out_data, int *out_size,
> +const uint8_t *data, int size)
> {
> -GetBitContext gb;
> -int res, profile, keyframe;
> +VP9ParserContext *s = ctx->priv_data;
> +const CodedBitstreamVP9Context *vp9 = s->cbc->priv_data;
> +const VP9RawFrameHeader *fh;
> +int err;
>
> *out_data = data;
> *out_size = size;
>
> -if (!size || (res = init_get_bits8(, data, size)) < 0)
> -return size; // parsers can't return errors
> -get_bits(, 2); // frame marker
> -profile = get_bits1();
> -profile |= get_bits1() << 1;
> -if (profile == 3) profile += get_bits1();
> -if (profile > 3)
> -return size;
> +ctx->key_frame = -1;
> +ctx->pict_type = AV_PICTURE_TYPE_NONE;
> +ctx->picture_structure = AV_PICTURE_STRUCTURE_UNKNOWN;
>
> -avctx->profile = profile;
> +if (!size)
> +return 0;
>
> -if (get_bits1()) {
> -keyframe = 0;
> -} else {
> -keyframe = !get_bits1();
> +s->cbc->log_ctx = avctx;
> +
> +err = ff_cbs_parse_headers(s->cbc, >frame_header, data, size);
> +if (err < 0) {
> +av_log(avctx, AV_LOG_WARNING, "Failed to parse VP9 frame
> headers.\n");
> +goto end;
> }
> +fh = >frame_header;
>
> -if (!keyframe) {
> -ctx->pict_type = AV_PICTURE_TYPE_P;
> -ctx->key_frame = 0;
> -} else {
> +avctx->profile = vp9->profile;
> +avctx->level = FF_LEVEL_UNKNOWN;
> +
> +ctx->width = ctx->coded_width = vp9->frame_width;
> +ctx->height = ctx->coded_height = vp9->frame_height;
> +
> +if (fh->frame_type == VP9_KEY_FRAME) {
> ctx->pict_type = AV_PICTURE_TYPE_I;
> ctx->key_frame = 1;
> +} else {
> +ctx->pict_type = fh->intra_only ? AV_PICTURE_TYPE_I :
> AV_PICTURE_TYPE_P;
> +ctx->key_frame = 0;
> }
>
> +ctx->picture_structure = AV_PICTURE_STRUCTURE_FRAME;
> +
> +av_assert0(vp9->bit_depth == 8 ||
> + vp9->bit_depth == 10 ||
> + vp9->bit_depth == 12);
> +
> +ctx->format = vp9_pix_fmts[(vp9->bit_depth - 8) / 2]
> +
> [vp9->subsampling_x][vp9->subsampling_y];
> +
> +end:
> +s->cbc->log_ctx = NULL;
> +
> return size;
> }
>
> +static av_cold int vp9_parser_init(AVCodecParserContext *ctx) {
> +VP9ParserContext *s = ctx->priv_data;
> +return ff_cbs_init(>cbc, AV_CODEC_ID_VP9, NULL); }
> +
> +static av_cold void vp9_parser_close(AVCodecParserContext *ctx) {
> +VP9ParserContext *s = ctx->priv_data;
> +ff_cbs_close(>cbc);
> +}
> +
> AVCodecParser ff_vp9_parser = {
> .codec_ids = { AV_CODEC_ID_VP9 },
> -.parser_parse = parse,
> +.priv_data_size = sizeof(VP9ParserContext),
> +.parser_init= _parser_init,
> +.parser_close = _parser_close,
> +.parser_parse = _parser_parse,
>
Re: [FFmpeg-devel] [PATCH] avformat/mux: skip parameter and pts checks for data muxer
Gyan (12019-04-26): > From 5ec154870d9c559037598b41736bf5b216a756e0 Mon Sep 17 00:00:00 2001 > From: Gyan Doshi > Date: Fri, 26 Apr 2019 18:31:33 +0530 > Subject: [PATCH] avformat/mux: skip parameter and pts checks for data muxer > > Allows to dump a malformed stream for external inspection or repair. What is your exact use case? I think there are much simpler and much more robust solutions. Regards, -- Nicolas George 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] avformat/mux: skip parameter and pts checks for data muxer
On 28-04-2019 03:26 PM, Michael Niedermayer wrote:
On Sat, Apr 27, 2019 at 10:01:53AM +0530, Gyan wrote:
On 27-04-2019 01:32 AM, Michael Niedermayer wrote:
On Fri, Apr 26, 2019 at 06:38:37PM +0530, Gyan wrote:
mux.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
d94a699f5dbc31a8ee8b7d1bdb33004d9cd95d46
0001-avformat-mux-skip-parameter-and-pts-checks-for-data-.patch
From 5ec154870d9c559037598b41736bf5b216a756e0 Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Fri, 26 Apr 2019 18:31:33 +0530
Subject: [PATCH] avformat/mux: skip parameter and pts checks for data muxer
Allows to dump a malformed stream for external inspection or repair.
---
libavformat/mux.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 83fe1de78f..3699b572f2 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -290,6 +290,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
goto fail;
}
+if (!strcmp(of->name, "data"))
+goto bypass;
+
for (i = 0; i < s->nb_streams; i++) {
st = s->streams[i];
par = st->codecpar;
@@ -409,6 +412,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
av_dict_set(>metadata, e->key, NULL, 0);
}
+bypass:
I think this skips a bit more than what would make sense
(for example priv_data allocation but thats not the only odd thing)
also iam not sure this is the ideal approuch.
I mean "I want to dump inavlid data in a data muxer for debug"
that seems a potentially valid request for other muxers too
like the image muxer producing individual files per frame and
so on
What would be the ideal approach?
I guess the ideal approuch would be to allow the developer who needs
this to override the check when the muxer in use can actually saftely
mux it without the specific check.
There are for example muxers which would not function properly with
backward going dts or something like that
The data muxer doesn't care about timestamps or any other codec
parameter yet lavf will error out if the checks fail since its primary
design is to cater to media-savvy containers. So I skip the checks only
for the 'data' muxer.
Gyan
___
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/mux: skip parameter and pts checks for data muxer
On Sun, Apr 28, 2019 at 11:57 AM Michael Niedermayer
wrote:
>
> On Sat, Apr 27, 2019 at 10:01:53AM +0530, Gyan wrote:
> >
> >
> > On 27-04-2019 01:32 AM, Michael Niedermayer wrote:
> > >On Fri, Apr 26, 2019 at 06:38:37PM +0530, Gyan wrote:
> > >> mux.c |9 -
> > >> 1 file changed, 8 insertions(+), 1 deletion(-)
> > >>d94a699f5dbc31a8ee8b7d1bdb33004d9cd95d46
> > >>0001-avformat-mux-skip-parameter-and-pts-checks-for-data-.patch
> > >> From 5ec154870d9c559037598b41736bf5b216a756e0 Mon Sep 17 00:00:00 2001
> > >>From: Gyan Doshi
> > >>Date: Fri, 26 Apr 2019 18:31:33 +0530
> > >>Subject: [PATCH] avformat/mux: skip parameter and pts checks for data
> > >>muxer
> > >>
> > >>Allows to dump a malformed stream for external inspection or repair.
> > >>---
> > >> libavformat/mux.c | 9 -
> > >> 1 file changed, 8 insertions(+), 1 deletion(-)
> > >>
> > >>diff --git a/libavformat/mux.c b/libavformat/mux.c
> > >>index 83fe1de78f..3699b572f2 100644
> > >>--- a/libavformat/mux.c
> > >>+++ b/libavformat/mux.c
> > >>@@ -290,6 +290,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > >> goto fail;
> > >> }
> > >>+if (!strcmp(of->name, "data"))
> > >>+goto bypass;
> > >>+
> > >> for (i = 0; i < s->nb_streams; i++) {
> > >> st = s->streams[i];
> > >> par = st->codecpar;
> > >>@@ -409,6 +412,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > >> av_dict_set(>metadata, e->key, NULL, 0);
> > >> }
> > >>+bypass:
> > >I think this skips a bit more than what would make sense
> > >(for example priv_data allocation but thats not the only odd thing)
> > >
> > >also iam not sure this is the ideal approuch.
> > >I mean "I want to dump inavlid data in a data muxer for debug"
> > >that seems a potentially valid request for other muxers too
> > >like the image muxer producing individual files per frame and
> > >so on
> > What would be the ideal approach?
>
> I guess the ideal approuch would be to allow the developer who needs
> this to override the check when the muxer in use can actually saftely
> mux it without the specific check.
> There are for example muxers which would not function properly with
> backward going dts or something like that
>
We already have a variety of flags in place, like if a muxer doesn't
care for timestamps at all, flag it AVFMT_NOTIMESTAMPS, and have code
that checks timestamps check for this flag. Checks based on muxer
names seem generally always wrong.
- Hendrik
___
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] avfilter/vf_lut3d: increase MAX_LEVEL
On 4/28/19, Nicolas George wrote: > Paul B Mahol (12019-04-27): >> Considering that some filtergraphs needs 64GB of RAM I consider that >> non-issue. > > Why was this pushed without leaving Clément time to reply? He replied on IRC. ___ 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/mux: skip parameter and pts checks for data muxer
On Sat, Apr 27, 2019 at 10:01:53AM +0530, Gyan wrote:
>
>
> On 27-04-2019 01:32 AM, Michael Niedermayer wrote:
> >On Fri, Apr 26, 2019 at 06:38:37PM +0530, Gyan wrote:
> >> mux.c |9 -
> >> 1 file changed, 8 insertions(+), 1 deletion(-)
> >>d94a699f5dbc31a8ee8b7d1bdb33004d9cd95d46
> >>0001-avformat-mux-skip-parameter-and-pts-checks-for-data-.patch
> >> From 5ec154870d9c559037598b41736bf5b216a756e0 Mon Sep 17 00:00:00 2001
> >>From: Gyan Doshi
> >>Date: Fri, 26 Apr 2019 18:31:33 +0530
> >>Subject: [PATCH] avformat/mux: skip parameter and pts checks for data muxer
> >>
> >>Allows to dump a malformed stream for external inspection or repair.
> >>---
> >> libavformat/mux.c | 9 -
> >> 1 file changed, 8 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/libavformat/mux.c b/libavformat/mux.c
> >>index 83fe1de78f..3699b572f2 100644
> >>--- a/libavformat/mux.c
> >>+++ b/libavformat/mux.c
> >>@@ -290,6 +290,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >> goto fail;
> >> }
> >>+if (!strcmp(of->name, "data"))
> >>+goto bypass;
> >>+
> >> for (i = 0; i < s->nb_streams; i++) {
> >> st = s->streams[i];
> >> par = st->codecpar;
> >>@@ -409,6 +412,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >> av_dict_set(>metadata, e->key, NULL, 0);
> >> }
> >>+bypass:
> >I think this skips a bit more than what would make sense
> >(for example priv_data allocation but thats not the only odd thing)
> >
> >also iam not sure this is the ideal approuch.
> >I mean "I want to dump inavlid data in a data muxer for debug"
> >that seems a potentially valid request for other muxers too
> >like the image muxer producing individual files per frame and
> >so on
> What would be the ideal approach?
I guess the ideal approuch would be to allow the developer who needs
this to override the check when the muxer in use can actually saftely
mux it without the specific check.
There are for example muxers which would not function properly with
backward going dts or something like that
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri
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] [PATCH 3/3, v5] lavc/vaapi_decode: add profile_parser to find the exact va_profile
Add function pointer field in vaapi_profile_map[], set profile_parser
for HEVC_REXT to find the exact va_profile.
Signed-off-by: Linjie Fu
---
SPS range extension fields should be passed to decoder, will use
VAPictureParameterBufferHEVCExtension consist of base and rext.
libavcodec/vaapi_decode.c | 71 ++-
1 file changed, 41 insertions(+), 30 deletions(-)
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 69512e1d45..7c9cfbc0ed 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -24,7 +24,7 @@
#include "decode.h"
#include "internal.h"
#include "vaapi_decode.h"
-
+#include "vaapi_hevc.h"
int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
VAAPIDecodePicture *pic,
@@ -364,39 +364,44 @@ static const struct {
enum AVCodecID codec_id;
int codec_profile;
VAProfile va_profile;
+VAProfile (*profile_parser)(AVCodecContext *avctx);
} vaapi_profile_map[] = {
-#define MAP(c, p, v) { AV_CODEC_ID_ ## c, FF_PROFILE_ ## p, VAProfile ## v }
-MAP(MPEG2VIDEO, MPEG2_SIMPLE,MPEG2Simple ),
-MAP(MPEG2VIDEO, MPEG2_MAIN, MPEG2Main ),
-MAP(H263,UNKNOWN, H263Baseline),
-MAP(MPEG4, MPEG4_SIMPLE,MPEG4Simple ),
+#define MAP(c, p, v, f) { AV_CODEC_ID_ ## c, FF_PROFILE_ ## p, VAProfile ## v,
f}
+MAP(MPEG2VIDEO, MPEG2_SIMPLE,MPEG2Simple , NULL ),
+MAP(MPEG2VIDEO, MPEG2_MAIN, MPEG2Main , NULL ),
+MAP(H263,UNKNOWN, H263Baseline, NULL ),
+MAP(MPEG4, MPEG4_SIMPLE,MPEG4Simple , NULL ),
MAP(MPEG4, MPEG4_ADVANCED_SIMPLE,
- MPEG4AdvancedSimple),
-MAP(MPEG4, MPEG4_MAIN, MPEG4Main ),
+ MPEG4AdvancedSimple, NULL ),
+MAP(MPEG4, MPEG4_MAIN, MPEG4Main , NULL ),
MAP(H264,H264_CONSTRAINED_BASELINE,
- H264ConstrainedBaseline),
-MAP(H264,H264_MAIN, H264Main),
-MAP(H264,H264_HIGH, H264High),
+ H264ConstrainedBaseline, NULL ),
+MAP(H264,H264_MAIN, H264Main, NULL ),
+MAP(H264,H264_HIGH, H264High, NULL ),
#if VA_CHECK_VERSION(0, 37, 0)
-MAP(HEVC,HEVC_MAIN, HEVCMain),
-MAP(HEVC,HEVC_MAIN_10,HEVCMain10 ),
+MAP(HEVC,HEVC_MAIN, HEVCMain, NULL ),
+MAP(HEVC,HEVC_MAIN_10,HEVCMain10 , NULL ),
+#endif
+#if VA_CHECK_VERSION(1, 2, 0)
+MAP(HEVC,HEVC_REXT, None,
+ ff_vaapi_parse_rext_profile),
#endif
MAP(MJPEG, MJPEG_HUFFMAN_BASELINE_DCT,
- JPEGBaseline),
-MAP(WMV3,VC1_SIMPLE, VC1Simple ),
-MAP(WMV3,VC1_MAIN,VC1Main ),
-MAP(WMV3,VC1_COMPLEX, VC1Advanced ),
-MAP(WMV3,VC1_ADVANCED,VC1Advanced ),
-MAP(VC1, VC1_SIMPLE, VC1Simple ),
-MAP(VC1, VC1_MAIN,VC1Main ),
-MAP(VC1, VC1_COMPLEX, VC1Advanced ),
-MAP(VC1, VC1_ADVANCED,VC1Advanced ),
-MAP(VP8, UNKNOWN, VP8Version0_3 ),
+ JPEGBaseline, NULL ),
+MAP(WMV3,VC1_SIMPLE, VC1Simple , NULL ),
+MAP(WMV3,VC1_MAIN,VC1Main , NULL ),
+MAP(WMV3,VC1_COMPLEX, VC1Advanced , NULL ),
+MAP(WMV3,VC1_ADVANCED,VC1Advanced , NULL ),
+MAP(VC1, VC1_SIMPLE, VC1Simple , NULL ),
+MAP(VC1, VC1_MAIN,VC1Main , NULL ),
+MAP(VC1, VC1_COMPLEX, VC1Advanced , NULL ),
+MAP(VC1, VC1_ADVANCED,VC1Advanced , NULL ),
+MAP(VP8, UNKNOWN, VP8Version0_3 , NULL ),
#if VA_CHECK_VERSION(0, 38, 0)
-MAP(VP9, VP9_0, VP9Profile0 ),
+MAP(VP9, VP9_0, VP9Profile0 , NULL ),
#endif
#if VA_CHECK_VERSION(0, 39, 0)
-MAP(VP9, VP9_2, VP9Profile2 ),
+MAP(VP9, VP9_2, VP9Profile2 , NULL ),
#endif
#undef MAP
};
@@ -415,8 +420,8 @@ static int vaapi_decode_make_config(AVCodecContext *avctx,
VAStatus vas;
int err, i, j;
const AVCodecDescriptor *codec_desc;
-VAProfile *profile_list = NULL, matched_va_profile;
-int profile_count, exact_match, matched_ff_profile;
+VAProfile *profile_list = NULL, matched_va_profile, tmp_va_profile;
+int profile_count, exact_match, matched_ff_profile, tmp_codec_profile;
AVHWDeviceContext*device = (AVHWDeviceContext*)device_ref->data;
AVVAAPIDeviceContext *hwctx = device->hwctx;
@@ -454,15 +459,21 @@ static int vaapi_decode_make_config(AVCodecContext *avctx,
if (avctx->profile == vaapi_profile_map[i].codec_profile ||
vaapi_profile_map[i].codec_profile
[FFmpeg-devel] [PATCH 2/3] lavc/vaapi_hevc: add vaapi_parse_rext_profile to find exact va_profile
Add vaapi_parse_rext_profile and use profile constraint flags to
determine the exact va_profile for HEVC_REXT.
Add build object in Makefile for h265_profile_level dependency.
Signed-off-by: Linjie Fu
---
libavcodec/Makefile | 2 +-
libavcodec/vaapi_hevc.c | 69 +
libavcodec/vaapi_hevc.h | 24 ++
3 files changed, 94 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/vaapi_hevc.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index f37135fc07..4f6a7acb92 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -878,7 +878,7 @@ OBJS-$(CONFIG_HEVC_D3D11VA_HWACCEL) += dxva2_hevc.o
OBJS-$(CONFIG_HEVC_DXVA2_HWACCEL) += dxva2_hevc.o
OBJS-$(CONFIG_HEVC_NVDEC_HWACCEL) += nvdec_hevc.o
OBJS-$(CONFIG_HEVC_QSV_HWACCEL) += qsvdec_h2645.o
-OBJS-$(CONFIG_HEVC_VAAPI_HWACCEL) += vaapi_hevc.o
+OBJS-$(CONFIG_HEVC_VAAPI_HWACCEL) += vaapi_hevc.o h265_profile_level.o
OBJS-$(CONFIG_HEVC_VDPAU_HWACCEL) += vdpau_hevc.o
OBJS-$(CONFIG_MJPEG_NVDEC_HWACCEL)+= nvdec_mjpeg.o
OBJS-$(CONFIG_MJPEG_VAAPI_HWACCEL)+= vaapi_mjpeg.o
diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
index c69d63d8ec..dd48747787 100644
--- a/libavcodec/vaapi_hevc.c
+++ b/libavcodec/vaapi_hevc.c
@@ -27,6 +27,8 @@
#include "hevcdec.h"
#include "hwaccel.h"
#include "vaapi_decode.h"
+#include "vaapi_hevc.h"
+#include "h265_profile_level.h"
typedef struct VAAPIDecodePictureHEVC {
VAPictureParameterBufferHEVC pic_param;
@@ -421,6 +423,73 @@ static int vaapi_hevc_decode_slice(AVCodecContext *avctx,
return 0;
}
+static int ptl_convert(const PTLCommon *general_ptl, H265RawProfileTierLevel
*h265_raw_ptl)
+{
+h265_raw_ptl->general_profile_space = general_ptl->profile_space;
+h265_raw_ptl->general_tier_flag = general_ptl->tier_flag;
+h265_raw_ptl->general_profile_idc = general_ptl->profile_idc;
+
+memcpy(h265_raw_ptl->general_profile_compatibility_flag,
+ general_ptl->profile_compatibility_flag, 32
* sizeof(int));
+
+h265_raw_ptl->general_progressive_source_flag =
general_ptl->progressive_source_flag;
+h265_raw_ptl->general_interlaced_source_flag =
general_ptl->interlaced_source_flag;
+h265_raw_ptl->general_non_packed_constraint_flag =
general_ptl->non_packed_constraint_flag;
+h265_raw_ptl->general_frame_only_constraint_flag =
general_ptl->frame_only_constraint_flag;
+h265_raw_ptl->general_max_12bit_constraint_flag=
general_ptl->max_12bit_constraint_flag;
+h265_raw_ptl->general_max_10bit_constraint_flag=
general_ptl->max_10bit_constraint_flag;
+h265_raw_ptl->general_max_8bit_constraint_flag =
general_ptl->max_8bit_constraint_flag;
+h265_raw_ptl->general_max_422chroma_constraint_flag=
general_ptl->max_422chroma_constraint_flag;
+h265_raw_ptl->general_max_420chroma_constraint_flag=
general_ptl->max_420chroma_constraint_flag;
+h265_raw_ptl->general_max_monochrome_constraint_flag =
general_ptl->max_monochrome_constraint_flag;
+h265_raw_ptl->general_intra_constraint_flag=
general_ptl->intra_constraint_flag;
+h265_raw_ptl->general_one_picture_only_constraint_flag =
general_ptl->one_picture_only_constraint_flag;
+h265_raw_ptl->general_lower_bit_rate_constraint_flag =
general_ptl->lower_bit_rate_constraint_flag;
+h265_raw_ptl->general_max_14bit_constraint_flag=
general_ptl->max_14bit_constraint_flag;
+h265_raw_ptl->general_inbld_flag =
general_ptl->inbld_flag;
+h265_raw_ptl->general_level_idc=
general_ptl->level_idc;
+
+return 0;
+}
+
+/*
+ * Find exact va_profile for HEVC Range Extension
+ */
+VAProfile ff_vaapi_parse_rext_profile(AVCodecContext *avctx)
+{
+const HEVCContext *h = avctx->priv_data;
+const HEVCSPS *sps = h->ps.sps;
+const PTL *ptl = &(sps->ptl);
+const PTLCommon *general_ptl = &(ptl->general_ptl);
+const H265ProfileDescriptor *profile = NULL;
+
+H265RawProfileTierLevel *h265_raw_ptl =
av_mallocz(sizeof(H265RawProfileTierLevel));
+/* convert PTLCommon to H265RawProfileTierLevel */
+ptl_convert(general_ptl, h265_raw_ptl);
+
+profile = ff_h265_get_profile(h265_raw_ptl);
+av_freep(_raw_ptl);
+
+if (!profile)
+return VAProfileNone;
+
+#if VA_CHECK_VERSION(1, 2, 0)
+if (!strcmp(profile->name, "Main 4:2:2 10") ||
+!strcmp(profile->name, "Main 4:2:2 10 Intra"))
+return VAProfileHEVCMain422_10;
+else if (!strcmp(profile->name, "Main 4:4:4") ||
+ !strcmp(profile->name, "Main 4:4:4 Intra"))
+return VAProfileHEVCMain444;
+else if (!strcmp(profile->name, "Main 4:4:4 10") ||
+ !strcmp(profile->name, "Main 4:4:4 10 Intra"))
+return VAProfileHEVCMain444_10;
+#else
+av_log(avctx, AV_LOG_WARNING, "HEVC
[FFmpeg-devel] [PATCH 1/2, v2] lavc/vaapi_encode_h264: add support for maxframesize
Add support for max frame size:
- max_frame_size (bytes) to indicate the allowed max frame size, set
with default 4 passes and delata_qp = 1 per pass;
Customized pass_num and delta_qp per pass is also available:
- pass_num to indicate number of passes.
- delta_qp to indicate qp value added to base_qp for each pass.
Currently only AVC encoder can support this settings in multiple pass case.
If the frame size exceeds the limitation, encoder will adjust the QP value
set by bit rate control methods, add delta_qp for each pass to control the
frame size.
new_qp = base_qp + delta_qp[0];
new_qp = base_qp + delta_qp[0] + delta_qp[1] + ...
Set max frame size with default params:
ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
-v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
-c:v h264_vaapi -profile:v main -g 30 -bf 3 -max_frame_size 4 \
-vframes 100 -y ./max_frame_size.h264
Set max frame size with expected params:
ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
-v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
-c:v h264_vaapi -profile:v main -g 30 -bf 3 -max_frame_size 4 \
-pass_num 2 -delta_qp 2 -vframes 100 -y ./max_frame_size.h264
Signed-off-by: Linjie Fu
---
libavcodec/vaapi_encode.c | 56 +-
libavcodec/vaapi_encode.h | 16 +-
libavcodec/vaapi_encode_h264.c | 15 +
3 files changed, 85 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 2dda451882..c807957b23 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -235,7 +235,15 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
if (err < 0)
goto fail;
}
-
+#if VA_CHECK_VERSION(1, 3, 0)
+if (ctx->max_frame_size) {
+err = vaapi_encode_make_param_buffer(avctx, pic,
VAEncMiscParameterBufferType,
+(char*) >mfs_params.misc,
+sizeof(ctx->mfs_params));
+if (err < 0)
+goto fail;
+}
+#endif
if (pic->type == PICTURE_TYPE_IDR) {
if (ctx->va_packed_headers & VA_ENC_PACKED_HEADER_SEQUENCE &&
ctx->codec->write_sequence_header) {
@@ -1630,6 +1638,43 @@ rc_mode_found:
return 0;
}
+static av_cold int vaapi_encode_init_max_frame_size(AVCodecContext *avctx)
+{
+VAAPIEncodeContext *ctx = avctx->priv_data;
+
+uint32_t max_frame_size = ctx->max_frame_size;
+uint8_t num_passes = ctx->pass_num;
+int err = 0;
+int i = 0;
+
+ctx->delta_qp_array = av_mallocz_array(num_passes, sizeof(uint8_t));
+if (!ctx->delta_qp_array) {
+err = AVERROR(ENOMEM);
+return err;
+}
+for (i = 0; i delta_qp_array[i] = ctx->delta_qp;
+}
+
+
+#if VA_CHECK_VERSION(1, 3, 0)
+ctx->mfs_params.misc.type = VAEncMiscParameterTypeMultiPassFrameSize;
+ctx->mfs_params.mfs.type = VAEncMiscParameterTypeMultiPassFrameSize;
+ctx->mfs_params.mfs.max_frame_size = max_frame_size;
+ctx->mfs_params.mfs.num_passes = num_passes;
+ctx->mfs_params.mfs.delta_qp = ctx->delta_qp_array;
+
+av_log(avctx, AV_LOG_VERBOSE, "Max Frame Size: %d bytes, "
+ "num_passes: %d, delta_qp = %d.\n",
+ctx->max_frame_size, num_passes,
ctx->delta_qp);
+#else
+av_log(avctx, AV_LOG_WARNING, "Max Frame Size is "
+"not supported with this VA version.\n");
+#endif
+
+return 0;
+}
+
static av_cold int vaapi_encode_init_gop_structure(AVCodecContext *avctx)
{
VAAPIEncodeContext *ctx = avctx->priv_data;
@@ -2095,6 +2140,12 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
goto fail;
}
+if (ctx->max_frame_size) {
+err = vaapi_encode_init_max_frame_size(avctx);
+if (err < 0)
+goto fail;
+}
+
vas = vaCreateConfig(ctx->hwctx->display,
ctx->va_profile, ctx->va_entrypoint,
ctx->config_attributes, ctx->nb_config_attributes,
@@ -2219,6 +2270,9 @@ av_cold int ff_vaapi_encode_close(AVCodecContext *avctx)
ctx->va_config = VA_INVALID_ID;
}
+if (ctx->delta_qp_array)
+av_freep(>delta_qp_array);
+
av_freep(>codec_sequence_params);
av_freep(>codec_picture_params);
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 44a8db566e..92b1ebd3f0 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -176,6 +176,15 @@ typedef struct VAAPIEncodeContext {
// Desired B frame reference depth.
int desired_b_depth;
+// Max Frame Size
+int max_frame_size;
+// Number Of Passes
+int pass_num;
+// Delta_qp For Each Pass
+int delta_qp;
+// Array
[FFmpeg-devel] [PATCH 1/3] lavc/hevc_ps: parse constraint flags for HEVC REXT
Parse all the constraint flags according to ITU-T Rec. H.265 (02/2018).
It can be passed to hw decoders to determine the exact profile for Range
Extension HEVC.
Signed-off-by: Linjie Fu
---
This is the same patch with previous one, send again to be wrapped in
the patch set.
libavcodec/hevc_ps.c | 44
libavcodec/hevc_ps.h | 13 -
2 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 80df417e4f..53822173b8 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -267,7 +267,7 @@ static int decode_profile_tier_level(GetBitContext *gb,
AVCodecContext *avctx,
{
int i;
-if (get_bits_left(gb) < 2+1+5 + 32 + 4 + 16 + 16 + 12)
+if (get_bits_left(gb) < 2+1+5 + 32 + 4 + 43 + 1)
return -1;
ptl->profile_space = get_bits(gb, 2);
@@ -295,9 +295,45 @@ static int decode_profile_tier_level(GetBitContext *gb,
AVCodecContext *avctx,
ptl->non_packed_constraint_flag = get_bits1(gb);
ptl->frame_only_constraint_flag = get_bits1(gb);
-skip_bits(gb, 16); // XXX_reserved_zero_44bits[0..15]
-skip_bits(gb, 16); // XXX_reserved_zero_44bits[16..31]
-skip_bits(gb, 12); // XXX_reserved_zero_44bits[32..43]
+#define check_profile_idc(idc) \
+ptl->profile_idc == idc || ptl->profile_compatibility_flag[idc]
+
+if (check_profile_idc(4) || check_profile_idc(5) || check_profile_idc(6) ||
+check_profile_idc(7) || check_profile_idc(8) || check_profile_idc(9) ||
+check_profile_idc(10)) {
+
+ptl->max_12bit_constraint_flag= get_bits1(gb);
+ptl->max_10bit_constraint_flag= get_bits1(gb);
+ptl->max_8bit_constraint_flag = get_bits1(gb);
+ptl->max_422chroma_constraint_flag= get_bits1(gb);
+ptl->max_420chroma_constraint_flag= get_bits1(gb);
+ptl->max_monochrome_constraint_flag = get_bits1(gb);
+ptl->intra_constraint_flag= get_bits1(gb);
+ptl->one_picture_only_constraint_flag = get_bits1(gb);
+ptl->lower_bit_rate_constraint_flag = get_bits1(gb);
+
+if (check_profile_idc(5) || check_profile_idc(9) ||
check_profile_idc(10)) {
+ptl->max_14bit_constraint_flag= get_bits1(gb);
+skip_bits_long(gb, 33); // XXX_reserved_zero_33bits[0..32]
+} else {
+skip_bits_long(gb, 34); // XXX_reserved_zero_34bits[0..33]
+}
+} else if (check_profile_idc(2)) {
+skip_bits(gb, 7);
+ptl->one_picture_only_constraint_flag = get_bits1(gb);
+skip_bits_long(gb, 35); // XXX_reserved_zero_35bits[0..34]
+} else {
+skip_bits_long(gb, 43); // XXX_reserved_zero_43bits[0..42]
+}
+
+if ((ptl->profile_idc >=1 && ptl->profile_idc <= 5) || ptl->profile_idc ==
9 ||
+ptl->profile_compatibility_flag[1] ||
ptl->profile_compatibility_flag[2] ||
+ptl->profile_compatibility_flag[3] ||
ptl->profile_compatibility_flag[4] ||
+ptl->profile_compatibility_flag[5] ||
ptl->profile_compatibility_flag[9])
+ptl->inbld_flag = get_bits1(gb);
+else
+skip_bits1(gb);
+#undef check_profile_idc
return 0;
}
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index bbaa9205ef..64f1a1e209 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -177,11 +177,22 @@ typedef struct PTLCommon {
uint8_t tier_flag;
uint8_t profile_idc;
uint8_t profile_compatibility_flag[32];
-uint8_t level_idc;
uint8_t progressive_source_flag;
uint8_t interlaced_source_flag;
uint8_t non_packed_constraint_flag;
uint8_t frame_only_constraint_flag;
+uint8_t max_12bit_constraint_flag;
+uint8_t max_10bit_constraint_flag;
+uint8_t max_8bit_constraint_flag;
+uint8_t max_422chroma_constraint_flag;
+uint8_t max_420chroma_constraint_flag;
+uint8_t max_monochrome_constraint_flag;
+uint8_t intra_constraint_flag;
+uint8_t one_picture_only_constraint_flag;
+uint8_t lower_bit_rate_constraint_flag;
+uint8_t max_14bit_constraint_flag;
+uint8_t inbld_flag;
+uint8_t level_idc;
} PTLCommon;
typedef struct PTL {
--
2.17.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 2/2] doc/encoder: add documentations for max_frame_size
add docs. Signed-off-by: Linjie Fu --- doc/encoders.texi | 11 +++ 1 file changed, 11 insertions(+) diff --git a/doc/encoders.texi b/doc/encoders.texi index ef12c73ed5..e9887e13a6 100644 --- a/doc/encoders.texi +++ b/doc/encoders.texi @@ -2940,6 +2940,17 @@ Use CAVLC. @item aud Include access unit delimiters in the stream (not included by default). +@item max_frame_size +Set the allowed max size in bytes for each frame. If the frame size exceeds the limitation, +encoder will adjust the QP value by delta_qp for each pass to control the frame size. + +@item pass_num +Set number of passes, currently can support up to 4 passes. + +@item delta_qp +Set delta QP for every pass. Every pass can have different QP, currently set equal delta_qp for +each pass. + @item sei Set SEI message types to include. Some combination of the following values: -- 2.17.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/2] avcodec/cinepak: Check slice_size before allocating image
Fixes: Timeout (16sec -> 125msec)
Fixes:
14283/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5742851457024000
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cinepak.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
index 9b0077402f..d26c505222 100644
--- a/libavcodec/cinepak.c
+++ b/libavcodec/cinepak.c
@@ -353,6 +353,13 @@ static int cinepak_predecode_check (CinepakContext *s)
if (s->size < 10 + s->sega_film_skip_bytes + num_strips * 12)
return AVERROR_INVALIDDATA;
+if (num_strips) {
+uint8_t *data = s->data + 10 + s->sega_film_skip_bytes;
+int strip_size = AV_RB24 (data + 1);
+if (strip_size < 12 || strip_size > encoded_buf_size)
+return AVERROR_INVALIDDATA;
+}
+
return 0;
}
--
2.21.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 2/2] avcodec/pngdec: Check nb_blocks
Fixes: Timeout (23sec -> 0.5sec)
Fixes:
14329/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LSCR_fuzzer-5679252923482112
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/pngdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 6a681be29d..1dcde6cbc9 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -1541,6 +1541,8 @@ static int decode_frame_lscr(AVCodecContext *avctx,
return ret;
nb_blocks = bytestream2_get_le16(gb);
+if (2 + nb_blocks * 12 > bytestream2_get_bytes_left(gb))
+return AVERROR_INVALIDDATA;
if (s->last_picture.f->data[0]) {
ret = av_frame_copy(frame, s->last_picture.f);
--
2.21.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] avfilter/vf_lut3d: increase MAX_LEVEL
Paul B Mahol (12019-04-27): > Considering that some filtergraphs needs 64GB of RAM I consider that > non-issue. Why was this pushed without leaving Clément time to reply? -- Nicolas George 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 V1 0/2] Use avctx->framerate first for frame rate setting
On 28-04-2019 07:19 AM, myp...@gmail.com wrote: On Sat, Apr 27, 2019 at 8:22 PM Gyan wrote: On 27-04-2019 05:25 PM, Carl Eugen Hoyos wrote: 2019-04-27 13:17 GMT+02:00, Jun Zhao : perfer avctx->framerate first than use avctx->time_base when setting the frame rate to encoder. 1/time_base is not the average frame rate if the frame rate is not constant. But why would the average framerate be a good choice to set the encoder timebase? Also, note that x264/5 RC looks at the framerate. See https://code.videolan.org/videolan/x264/commit/c583687fab832ba7eaf8626048f05ad1f861a855 I can generate a difference with x264 by setting -enc_time_base to different values (with vsync vfr). Maybe check that this change does not lead to a significant change in output. Although I think this would be still an improvement for those cases where r_frame_rate >> avg_frame_rate Gyan Yes, framerate and time_base is not close correlation in vfr case, e,g, I can setting the framerate = 60fps, but time_base = 1/1000 s, then setting pts like: time_base = 1/1000 s = 1 millisecond framerate = 60 fps per second PTS 01633506683100 ... PTS delta 161717161717 ... we will get 16ms * 20 frames + 17 ms * 40 frames = 1000ms I'm aware of the relationship between TB and PTS. My point is x264's RC adjusts its quantizer based on fps. You're changing that value so the output bitrate will change for the same input with the same encoder config if (avg_frame_rate) != (ticks * 1/TB). Gyan ___ 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] libavfilter: Add more operation supports in FFmpeg dnn native mode.
This patch is for the support of derain filter project in GSoC. It adds
supports for the following operations:
(1) Conv padding method: "SAME" and "VALID"
(2) Dilation
(3) Activation: "NONE" and "LEAKY_RELU"
These operations are all needed in derain filter. And if modify the dnn native
mode in FFmpeg, the generation process of Super Resolution model should be
changed accordingly, e.g. add padding method parameter (= 0) and dilation
parameter (= 1).
In addition, I have a question about the Super Resulotion implementation. The
model training process of SR uses "VALID" method. According to my understanding
of "VALID" mode in tensorflow, the size of output image should be smaller than
the current design in SR. Because pixels near the boundary are not processed in
"VALID" mode, however, these unprocessed pixels are filled with adjacent pixels
in current dnn native mode. I wonder why to do like this here.
From 4d92ef21a5acf064122c51f442d0e2f5437b3343 Mon Sep 17 00:00:00 2001
From: Xuewei Meng
Date: Sun, 28 Apr 2019 17:21:35 +0800
Subject: [PATCH] Add operation supports in dnn_native
Signed-off-by: Xuewei Meng
---
libavfilter/dnn_backend_native.c | 36 +---
libavfilter/dnn_backend_native.h | 6 +-
2 files changed, 29 insertions(+), 13 deletions(-)
diff --git a/libavfilter/dnn_backend_native.c b/libavfilter/dnn_backend_native.c
index 70d857f5f2..0e3ef5d64d 100644
--- a/libavfilter/dnn_backend_native.c
+++ b/libavfilter/dnn_backend_native.c
@@ -157,13 +157,15 @@ DNNModel *ff_dnn_load_model_native(const char
*model_filename)
ff_dnn_free_model_native();
return NULL;
}
+conv_params->dilation = (int32_t)avio_rl32(model_file_context);
+conv_params->padding_method =
(int32_t)avio_rl32(model_file_context);
conv_params->activation = (int32_t)avio_rl32(model_file_context);
conv_params->input_num = (int32_t)avio_rl32(model_file_context);
conv_params->output_num = (int32_t)avio_rl32(model_file_context);
conv_params->kernel_size = (int32_t)avio_rl32(model_file_context);
kernel_size = conv_params->input_num * conv_params->output_num *
conv_params->kernel_size * conv_params->kernel_size;
-dnn_size += 16 + (kernel_size + conv_params->output_num << 2);
+dnn_size += 24 + (kernel_size + conv_params->output_num << 2);
if (dnn_size > file_size || conv_params->input_num <= 0 ||
conv_params->output_num <= 0 || conv_params->kernel_size <= 0){
avio_closep(_file_context);
@@ -221,23 +223,28 @@ DNNModel *ff_dnn_load_model_native(const char
*model_filename)
static void convolve(const float *input, float *output, const
ConvolutionalParams *conv_params, int width, int height)
{
-int y, x, n_filter, ch, kernel_y, kernel_x;
int radius = conv_params->kernel_size >> 1;
int src_linesize = width * conv_params->input_num;
int filter_linesize = conv_params->kernel_size * conv_params->input_num;
int filter_size = conv_params->kernel_size * filter_linesize;
+int pad_size = (conv_params->padding_method == VALID) ?
(conv_params->kernel_size - 1) / 2 * conv_params->dilation : 0;
-for (y = 0; y < height; ++y){
-for (x = 0; x < width; ++x){
-for (n_filter = 0; n_filter < conv_params->output_num; ++n_filter){
+for (int y = pad_size; y < height - pad_size; ++y){
+for (int x = pad_size; x < width - pad_size; ++x){
+for (int n_filter = 0; n_filter < conv_params->output_num;
++n_filter){
output[n_filter] = conv_params->biases[n_filter];
-for (ch = 0; ch < conv_params->input_num; ++ch){
-for (kernel_y = 0; kernel_y < conv_params->kernel_size;
++kernel_y){
-for (kernel_x = 0; kernel_x <
conv_params->kernel_size; ++kernel_x){
-output[n_filter] += input[CLAMP_TO_EDGE(y +
kernel_y - radius, height) * src_linesize +
- CLAMP_TO_EDGE(x +
kernel_x - radius, width) * conv_params->input_num + ch] *
-conv_params->kernel[n_filter *
filter_size + kernel_y * filter_linesize +
-kernel_x *
conv_params->input_num + ch];
+
+for (int ch = 0; ch < conv_params->input_num; ++ch){
+for (int kernel_y = 0; kernel_y <
conv_params->kernel_size; ++kernel_y){
+for (int kernel_x = 0; kernel_x <
conv_params->kernel_size; ++kernel_x){
+int y_pos = y + (kernel_y - radius) *
conv_params->dilation;
+int x_pos = x + (kernel_x - radius) *
conv_params->dilation;
+
+float input_pel = (x_pos < 0 ||
Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort decoder/encoder/filter/... names in alphabet order
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Alexander Strasser
> Sent: Sunday, April 28, 2019 9:18 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort
> decoder/encoder/filter/... names in alphabet order
>
>
> What do you think about using awk instead of shell?
>
> I have 2 POC patches attached. It's probably not 100% correct yet,
> but it kind of demonstrates what it would look like.
>
> The main advantage of using awk, is that it's more elegant and
> shorter. It's probably also less risky, because it's more isolated,
> e.g. as it was explained by avih, there is no widely supported way
> for locals across shells. We already use awk in configure for
> mandatory functions, so it's no new dependency.
>
> Please comment on the awk approach.
I did some change to make it correct on ubuntu 16.04, but looks issue on
windows mingw.
print_in_columns() {
sort | tr '\n' ' ' | awk -v width="$ncols" '
{
#add int()
num_cols = int(width / 24); num_rows = int((NF + num_cols-1) /
num_cols);
y = x = 1;
for (i = 1; i <= NF; i++) {
if (y > num_rows) {
y = 1; x++;
}
d[x,y] = $i;
y++;
}
print width
print num_cols
print num_rows
print NF
for (y = 1; y <= num_rows; y++) {
for (x = 1; x <= num_cols; x++) {
# it does not work for the case that the last column is not
fully filled
#line = sprintf(x != num_cols ? "%s%-24s" : "%s%s", line,
d[x,y]);
line = sprintf("%s%-24s", line, d[x,y]);
}
print line;
line = "";
}
}' | sed 's/ *$//'
}
on ubuntu 16.04, the output is:
Enabled bsfs:
135
5
7
33
aac_adtstoasc extract_extradata hevc_mp4toannexb
mpeg4_unpack_bframestruehd_core
av1_frame_split filter_unitsimx_dump_header noise
vp9_metadata
av1_metadatah264_metadata mjpeg2jpeg null
vp9_raw_reorder
chomp h264_mp4toannexbmjpega_dump_header
prores_metadata vp9_superframe
dca_coreh264_redundant_pps mov2textsub
remove_extradatavp9_superframe_split
dump_extradata hapqa_extract mp3_header_decompress
text2movsub
eac3_core hevc_metadata mpeg2_metadata
trace_headers
while on windows, the output is:
Enabled bsfs:
72
3
11
33
noiseh264_redundant_pps
nullextract
prores_metadata
remove_extradatamp4toannexb
text2movsubdump_header
trace_headers
truehd_corepega_dump_header
vp9_metadata
vp9_raw_reorderader_decompress
vp9_superframea
vp9_superframe_splitames
I did a quick check, but has not found the root cause yet.
>
> I'm not against the shell way, or a mixed approach, but before going
> either way and pushing I would rather have some more testing;
> especially on more exotic platforms.
>
>
> Thank you
> Alexander
___
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".
