Re: [FFmpeg-devel] [PATCH v2 4/4] avfilter/avfilter: update documentation of avfilter_graph_create_filter
> On Dec 6, 2019, at 3:06 PM, quinkbl...@foxmail.com wrote: > > From: Zhao Zhili > > --- > libavfilter/avfilter.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h > index 3eaa8a4089..197e12a625 100644 > --- a/libavfilter/avfilter.h > +++ b/libavfilter/avfilter.h > @@ -947,7 +947,7 @@ AVFilterContext *avfilter_graph_get_filter(AVFilterGraph > *graph, const char *nam > /** > * Create and add a filter instance into an existing graph. > * The filter instance is created from the filter filt and inited > - * with the parameters args and opaque. > + * with the parameters args. opaque is ignored currently. It should be 'parameter args’. I will wait for more comments first. > * > * In case of success put in *filt_ctx the pointer to the created > * filter instance, otherwise set *filt_ctx to NULL. > -- > 2.22.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".
[FFmpeg-devel] [PATCH v2 4/4] avfilter/avfilter: update documentation of avfilter_graph_create_filter
From: Zhao Zhili --- libavfilter/avfilter.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h index 3eaa8a4089..197e12a625 100644 --- a/libavfilter/avfilter.h +++ b/libavfilter/avfilter.h @@ -947,7 +947,7 @@ AVFilterContext *avfilter_graph_get_filter(AVFilterGraph *graph, const char *nam /** * Create and add a filter instance into an existing graph. * The filter instance is created from the filter filt and inited - * with the parameters args and opaque. + * with the parameters args. opaque is ignored currently. * * In case of success put in *filt_ctx the pointer to the created * filter instance, otherwise set *filt_ctx to NULL. -- 2.22.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/4] avfilter/buffersink: remove unused macros
From: Zhao Zhili
---
libavfilter/buffersink.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 25b3f4ab6b..30153adbb2 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -61,8 +61,6 @@ typedef struct BufferSinkContext {
} BufferSinkContext;
#define NB_ITEMS(list) (list ## _size / sizeof(*list))
-#define FIFO_INIT_SIZE 8
-#define FIFO_INIT_ELEMENT_SIZE sizeof(void *)
int attribute_align_arg av_buffersink_get_frame(AVFilterContext *ctx, AVFrame
*frame)
{
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 3/4] avfilter/buffersink: deprecate AVBufferSinkParams and AVABufferSinkParams
From: Zhao Zhili
---
libavfilter/buffersink.c | 2 ++
libavfilter/buffersink.h | 4
2 files changed, 6 insertions(+)
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 5f2ed0e4b3..76a46f6678 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -125,6 +125,7 @@ int attribute_align_arg
av_buffersink_get_samples(AVFilterContext *ctx,
return get_frame_internal(ctx, frame, 0, nb_samples);
}
+#if FF_API_NEXT
AVBufferSinkParams *av_buffersink_params_alloc(void)
{
static const int pixel_fmts[] = { AV_PIX_FMT_NONE };
@@ -144,6 +145,7 @@ AVABufferSinkParams *av_abuffersink_params_alloc(void)
return NULL;
return params;
}
+#endif
static av_cold int common_init(AVFilterContext *ctx)
{
diff --git a/libavfilter/buffersink.h b/libavfilter/buffersink.h
index 3c846bb527..2ec821c685 100644
--- a/libavfilter/buffersink.h
+++ b/libavfilter/buffersink.h
@@ -59,6 +59,7 @@ int av_buffersink_get_frame_flags(AVFilterContext *ctx,
AVFrame *frame, int flag
*/
#define AV_BUFFERSINK_FLAG_NO_REQUEST 2
+#if FF_API_NEXT
/**
* Struct to use for initializing a buffersink context.
*/
@@ -71,6 +72,7 @@ typedef struct AVBufferSinkParams {
*
* Must be freed with av_free().
*/
+attribute_deprecated
AVBufferSinkParams *av_buffersink_params_alloc(void);
/**
@@ -89,7 +91,9 @@ typedef struct AVABufferSinkParams {
*
* Must be freed with av_free().
*/
+attribute_deprecated
AVABufferSinkParams *av_abuffersink_params_alloc(void);
+#endif
/**
* Set the frame size for an audio buffer sink.
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/4] avfilter/buffersink: replace init_opaque by init
From: Zhao Zhili
The argument 'opaque' is always NULL since 0acf7e2 (2013).
---
libavfilter/buffersink.c | 35 ++-
1 file changed, 2 insertions(+), 33 deletions(-)
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 30153adbb2..5f2ed0e4b3 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -199,20 +199,6 @@ MAKE_AVFILTERLINK_ACCESSOR(int , sample_rate
)
MAKE_AVFILTERLINK_ACCESSOR(AVBufferRef *, hw_frames_ctx )
-static av_cold int vsink_init(AVFilterContext *ctx, void *opaque)
-{
-BufferSinkContext *buf = ctx->priv;
-AVBufferSinkParams *params = opaque;
-int ret;
-
-if (params) {
-if ((ret = av_opt_set_int_list(buf, "pix_fmts", params->pixel_fmts,
AV_PIX_FMT_NONE, 0)) < 0)
-return ret;
-}
-
-return common_init(ctx);
-}
-
#define CHECK_LIST_SIZE(field) \
if (buf->field ## _size % sizeof(*buf->field)) { \
av_log(ctx, AV_LOG_ERROR, "Invalid size for " #field ": %d, " \
@@ -242,23 +228,6 @@ static int vsink_query_formats(AVFilterContext *ctx)
return 0;
}
-static av_cold int asink_init(AVFilterContext *ctx, void *opaque)
-{
-BufferSinkContext *buf = ctx->priv;
-AVABufferSinkParams *params = opaque;
-int ret;
-
-if (params) {
-if ((ret = av_opt_set_int_list(buf, "sample_fmts",
params->sample_fmts, AV_SAMPLE_FMT_NONE, 0)) < 0 ||
-(ret = av_opt_set_int_list(buf, "sample_rates",
params->sample_rates,-1, 0)) < 0 ||
-(ret = av_opt_set_int_list(buf, "channel_layouts",
params->channel_layouts, -1, 0)) < 0 ||
-(ret = av_opt_set_int_list(buf, "channel_counts",
params->channel_counts, -1, 0)) < 0 ||
-(ret = av_opt_set_int(buf, "all_channel_counts",
params->all_channel_counts, 0)) < 0)
-return ret;
-}
-return common_init(ctx);
-}
-
static int asink_query_formats(AVFilterContext *ctx)
{
BufferSinkContext *buf = ctx->priv;
@@ -345,7 +314,7 @@ AVFilter ff_vsink_buffer = {
.description = NULL_IF_CONFIG_SMALL("Buffer video frames, and make them
available to the end of the filter graph."),
.priv_size = sizeof(BufferSinkContext),
.priv_class= &buffersink_class,
-.init_opaque = vsink_init,
+.init = common_init,
.query_formats = vsink_query_formats,
.activate = activate,
.inputs= avfilter_vsink_buffer_inputs,
@@ -365,7 +334,7 @@ AVFilter ff_asink_abuffer = {
.description = NULL_IF_CONFIG_SMALL("Buffer audio frames, and make them
available to the end of the filter graph."),
.priv_class= &abuffersink_class,
.priv_size = sizeof(BufferSinkContext),
-.init_opaque = asink_init,
+.init = common_init,
.query_formats = asink_query_formats,
.activate = activate,
.inputs= avfilter_asink_abuffer_inputs,
--
2.22.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 3/3] avfilter/buffersink: remove AVBufferSinkParams and AVABufferSinkParams
Please ignore patch 3/3. FFmpeg user may pass AVBufferSinkParams to
avfilter_graph_create_filter with the opaque pointer, which is ignored by
implementation. It should be marked as obsolete.
> On Dec 6, 2019, at 1:14 PM, quinkbl...@foxmail.com wrote:
>
> From: Zhao Zhili
>
> The patch breaks API in theory. Since there is no reason to allocate
> an object which you can do nothing with it, the API break should have
> no effect.
> ---
> libavfilter/buffersink.c | 20
> libavfilter/buffersink.h | 32
> 2 files changed, 52 deletions(-)
>
> diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
> index 5f2ed0e4b3..5d30c55281 100644
> --- a/libavfilter/buffersink.c
> +++ b/libavfilter/buffersink.c
> @@ -125,26 +125,6 @@ int attribute_align_arg
> av_buffersink_get_samples(AVFilterContext *ctx,
> return get_frame_internal(ctx, frame, 0, nb_samples);
> }
>
> -AVBufferSinkParams *av_buffersink_params_alloc(void)
> -{
> -static const int pixel_fmts[] = { AV_PIX_FMT_NONE };
> -AVBufferSinkParams *params = av_malloc(sizeof(AVBufferSinkParams));
> -if (!params)
> -return NULL;
> -
> -params->pixel_fmts = pixel_fmts;
> -return params;
> -}
> -
> -AVABufferSinkParams *av_abuffersink_params_alloc(void)
> -{
> -AVABufferSinkParams *params = av_mallocz(sizeof(AVABufferSinkParams));
> -
> -if (!params)
> -return NULL;
> -return params;
> -}
> -
> static av_cold int common_init(AVFilterContext *ctx)
> {
> BufferSinkContext *buf = ctx->priv;
> diff --git a/libavfilter/buffersink.h b/libavfilter/buffersink.h
> index 3c846bb527..be63bd1af1 100644
> --- a/libavfilter/buffersink.h
> +++ b/libavfilter/buffersink.h
> @@ -59,38 +59,6 @@ int av_buffersink_get_frame_flags(AVFilterContext *ctx,
> AVFrame *frame, int flag
> */
> #define AV_BUFFERSINK_FLAG_NO_REQUEST 2
>
> -/**
> - * Struct to use for initializing a buffersink context.
> - */
> -typedef struct AVBufferSinkParams {
> -const enum AVPixelFormat *pixel_fmts; ///< list of allowed pixel
> formats, terminated by AV_PIX_FMT_NONE
> -} AVBufferSinkParams;
> -
> -/**
> - * Create an AVBufferSinkParams structure.
> - *
> - * Must be freed with av_free().
> - */
> -AVBufferSinkParams *av_buffersink_params_alloc(void);
> -
> -/**
> - * Struct to use for initializing an abuffersink context.
> - */
> -typedef struct AVABufferSinkParams {
> -const enum AVSampleFormat *sample_fmts; ///< list of allowed sample
> formats, terminated by AV_SAMPLE_FMT_NONE
> -const int64_t *channel_layouts; ///< list of allowed channel
> layouts, terminated by -1
> -const int *channel_counts; ///< list of allowed channel
> counts, terminated by -1
> -int all_channel_counts; ///< if not 0, accept any
> channel count or layout
> -int *sample_rates; ///< list of allowed sample
> rates, terminated by -1
> -} AVABufferSinkParams;
> -
> -/**
> - * Create an AVABufferSinkParams structure.
> - *
> - * Must be freed with av_free().
> - */
> -AVABufferSinkParams *av_abuffersink_params_alloc(void);
> -
> /**
> * Set the frame size for an audio buffer sink.
> *
> --
> 2.22.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".
[FFmpeg-devel] [PATCH 2/3] avfilter/buffersink: replace init_opaque by init
From: Zhao Zhili
The argument 'opaque' is always NULL since 0acf7e2 (2013).
---
libavfilter/buffersink.c | 35 ++-
1 file changed, 2 insertions(+), 33 deletions(-)
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 30153adbb2..5f2ed0e4b3 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -199,20 +199,6 @@ MAKE_AVFILTERLINK_ACCESSOR(int , sample_rate
)
MAKE_AVFILTERLINK_ACCESSOR(AVBufferRef *, hw_frames_ctx )
-static av_cold int vsink_init(AVFilterContext *ctx, void *opaque)
-{
-BufferSinkContext *buf = ctx->priv;
-AVBufferSinkParams *params = opaque;
-int ret;
-
-if (params) {
-if ((ret = av_opt_set_int_list(buf, "pix_fmts", params->pixel_fmts,
AV_PIX_FMT_NONE, 0)) < 0)
-return ret;
-}
-
-return common_init(ctx);
-}
-
#define CHECK_LIST_SIZE(field) \
if (buf->field ## _size % sizeof(*buf->field)) { \
av_log(ctx, AV_LOG_ERROR, "Invalid size for " #field ": %d, " \
@@ -242,23 +228,6 @@ static int vsink_query_formats(AVFilterContext *ctx)
return 0;
}
-static av_cold int asink_init(AVFilterContext *ctx, void *opaque)
-{
-BufferSinkContext *buf = ctx->priv;
-AVABufferSinkParams *params = opaque;
-int ret;
-
-if (params) {
-if ((ret = av_opt_set_int_list(buf, "sample_fmts",
params->sample_fmts, AV_SAMPLE_FMT_NONE, 0)) < 0 ||
-(ret = av_opt_set_int_list(buf, "sample_rates",
params->sample_rates,-1, 0)) < 0 ||
-(ret = av_opt_set_int_list(buf, "channel_layouts",
params->channel_layouts, -1, 0)) < 0 ||
-(ret = av_opt_set_int_list(buf, "channel_counts",
params->channel_counts, -1, 0)) < 0 ||
-(ret = av_opt_set_int(buf, "all_channel_counts",
params->all_channel_counts, 0)) < 0)
-return ret;
-}
-return common_init(ctx);
-}
-
static int asink_query_formats(AVFilterContext *ctx)
{
BufferSinkContext *buf = ctx->priv;
@@ -345,7 +314,7 @@ AVFilter ff_vsink_buffer = {
.description = NULL_IF_CONFIG_SMALL("Buffer video frames, and make them
available to the end of the filter graph."),
.priv_size = sizeof(BufferSinkContext),
.priv_class= &buffersink_class,
-.init_opaque = vsink_init,
+.init = common_init,
.query_formats = vsink_query_formats,
.activate = activate,
.inputs= avfilter_vsink_buffer_inputs,
@@ -365,7 +334,7 @@ AVFilter ff_asink_abuffer = {
.description = NULL_IF_CONFIG_SMALL("Buffer audio frames, and make them
available to the end of the filter graph."),
.priv_class= &abuffersink_class,
.priv_size = sizeof(BufferSinkContext),
-.init_opaque = asink_init,
+.init = common_init,
.query_formats = asink_query_formats,
.activate = activate,
.inputs= avfilter_asink_abuffer_inputs,
--
2.22.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 3/3] avfilter/buffersink: remove AVBufferSinkParams and AVABufferSinkParams
From: Zhao Zhili
The patch breaks API in theory. Since there is no reason to allocate
an object which you can do nothing with it, the API break should have
no effect.
---
libavfilter/buffersink.c | 20
libavfilter/buffersink.h | 32
2 files changed, 52 deletions(-)
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 5f2ed0e4b3..5d30c55281 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -125,26 +125,6 @@ int attribute_align_arg
av_buffersink_get_samples(AVFilterContext *ctx,
return get_frame_internal(ctx, frame, 0, nb_samples);
}
-AVBufferSinkParams *av_buffersink_params_alloc(void)
-{
-static const int pixel_fmts[] = { AV_PIX_FMT_NONE };
-AVBufferSinkParams *params = av_malloc(sizeof(AVBufferSinkParams));
-if (!params)
-return NULL;
-
-params->pixel_fmts = pixel_fmts;
-return params;
-}
-
-AVABufferSinkParams *av_abuffersink_params_alloc(void)
-{
-AVABufferSinkParams *params = av_mallocz(sizeof(AVABufferSinkParams));
-
-if (!params)
-return NULL;
-return params;
-}
-
static av_cold int common_init(AVFilterContext *ctx)
{
BufferSinkContext *buf = ctx->priv;
diff --git a/libavfilter/buffersink.h b/libavfilter/buffersink.h
index 3c846bb527..be63bd1af1 100644
--- a/libavfilter/buffersink.h
+++ b/libavfilter/buffersink.h
@@ -59,38 +59,6 @@ int av_buffersink_get_frame_flags(AVFilterContext *ctx,
AVFrame *frame, int flag
*/
#define AV_BUFFERSINK_FLAG_NO_REQUEST 2
-/**
- * Struct to use for initializing a buffersink context.
- */
-typedef struct AVBufferSinkParams {
-const enum AVPixelFormat *pixel_fmts; ///< list of allowed pixel formats,
terminated by AV_PIX_FMT_NONE
-} AVBufferSinkParams;
-
-/**
- * Create an AVBufferSinkParams structure.
- *
- * Must be freed with av_free().
- */
-AVBufferSinkParams *av_buffersink_params_alloc(void);
-
-/**
- * Struct to use for initializing an abuffersink context.
- */
-typedef struct AVABufferSinkParams {
-const enum AVSampleFormat *sample_fmts; ///< list of allowed sample
formats, terminated by AV_SAMPLE_FMT_NONE
-const int64_t *channel_layouts; ///< list of allowed channel
layouts, terminated by -1
-const int *channel_counts; ///< list of allowed channel
counts, terminated by -1
-int all_channel_counts; ///< if not 0, accept any channel
count or layout
-int *sample_rates; ///< list of allowed sample rates,
terminated by -1
-} AVABufferSinkParams;
-
-/**
- * Create an AVABufferSinkParams structure.
- *
- * Must be freed with av_free().
- */
-AVABufferSinkParams *av_abuffersink_params_alloc(void);
-
/**
* Set the frame size for an audio buffer sink.
*
--
2.22.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 1/3] avfilter/buffersink: remove unused macros
From: Zhao Zhili
---
libavfilter/buffersink.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 25b3f4ab6b..30153adbb2 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -61,8 +61,6 @@ typedef struct BufferSinkContext {
} BufferSinkContext;
#define NB_ITEMS(list) (list ## _size / sizeof(*list))
-#define FIFO_INIT_SIZE 8
-#define FIFO_INIT_ELEMENT_SIZE sizeof(void *)
int attribute_align_arg av_buffersink_get_frame(AVFilterContext *ctx, AVFrame
*frame)
{
--
2.22.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] avfilter/crop: avoid premature eval error
On 05-12-2019 11:31 pm, Gyan wrote: On 04-12-2019 04:09 pm, Gyan wrote: Valid width expressions were being rejected. Plan to push in the morning. Pushed as b66a800877d6f97fa94b41533e3d6a6273f7fb9f 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 v2 1/2] lavc/h2645_parse: Don't automatically remove nuh_layer_id > 0 packets
From: Andriy Gelman
HEVC standard supports multi-layer streams (ITU-T H.265 02/2018 Annex
F). Each NAL unit belongs to a particular layer defined by nuh_layer_id
in the header.
Currently, all NAL units that do not belong to a base layer are
automatically removed in ff_h2645_packet_split(). Some data may
therefore be lost when future filters/decoders are designed to support
multi-layer streams.
A better approach is to forward nuh_layer_id > 0 packets and let blocks
down the chain decide how to process them. The condition to remove
packets has been moved to hevcdec and cbs.
Found-by: Andreas Rheinhardt
Signed-off-by: Andriy Gelman
---
libavcodec/cbs_h2645.c | 3 +++
libavcodec/h2645_parse.c | 7 +++
libavcodec/h2645_parse.h | 5 +
libavcodec/hevc_parse.c | 2 ++
libavcodec/hevc_parser.c | 3 +++
libavcodec/hevcdec.c | 2 +-
6 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 88fa0029cd6..ae32078f246 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -565,6 +565,9 @@ static int
cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
AVBufferRef *ref;
size_t size = nal->size;
+if (nal->nuh_layer_id > 0)
+continue;
+
// Remove trailing zeroes.
while (size > 0 && nal->data[size - 1] == 0)
--size;
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 4808f79a67f..0f3343004f9 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -292,23 +292,22 @@ static int get_bit_length(H2645NAL *nal, int
skip_trailing_zeros)
static int hevc_parse_nal_header(H2645NAL *nal, void *logctx)
{
GetBitContext *gb = &nal->gb;
-int nuh_layer_id;
if (get_bits1(gb) != 0)
return AVERROR_INVALIDDATA;
nal->type = get_bits(gb, 6);
-nuh_layer_id = get_bits(gb, 6);
+nal->nuh_layer_id = get_bits(gb, 6);
nal->temporal_id = get_bits(gb, 3) - 1;
if (nal->temporal_id < 0)
return AVERROR_INVALIDDATA;
av_log(logctx, AV_LOG_DEBUG,
"nal_unit_type: %d(%s), nuh_layer_id: %d, temporal_id: %d\n",
- nal->type, hevc_nal_unit_name(nal->type), nuh_layer_id,
nal->temporal_id);
+ nal->type, hevc_nal_unit_name(nal->type), nal->nuh_layer_id,
nal->temporal_id);
-return nuh_layer_id == 0;
+return 1;
}
static int h264_parse_nal_header(H2645NAL *nal, void *logctx)
diff --git a/libavcodec/h2645_parse.h b/libavcodec/h2645_parse.h
index 2acf882d3da..3e47f86c53b 100644
--- a/libavcodec/h2645_parse.h
+++ b/libavcodec/h2645_parse.h
@@ -56,6 +56,11 @@ typedef struct H2645NAL {
*/
int temporal_id;
+/*
+ * HEVC only, identifier of layer to which nal unit belongs
+ */
+int nuh_layer_id;
+
int skipped_bytes;
int skipped_bytes_pos_size;
int *skipped_bytes_pos;
diff --git a/libavcodec/hevc_parse.c b/libavcodec/hevc_parse.c
index dddb293df64..29dfd479f38 100644
--- a/libavcodec/hevc_parse.c
+++ b/libavcodec/hevc_parse.c
@@ -37,6 +37,8 @@ static int hevc_decode_nal_units(const uint8_t *buf, int
buf_size, HEVCParamSets
for (i = 0; i < pkt.nb_nals; i++) {
H2645NAL *nal = &pkt.nals[i];
+if (nal->nuh_layer_id > 0)
+continue;
/* ignore everything except parameter sets and VCL NALUs */
switch (nal->type) {
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index b444b999550..87d5dba4f5e 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -202,6 +202,9 @@ static int parse_nal_units(AVCodecParserContext *s, const
uint8_t *buf,
H2645NAL *nal = &ctx->pkt.nals[i];
GetBitContext *gb = &nal->gb;
+if (nal->nuh_layer_id > 0)
+continue;
+
switch (nal->type) {
case HEVC_NAL_VPS:
ff_hevc_decode_nal_vps(gb, avctx, ps);
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 8f1c162acee..bcd8e67944a 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -3077,7 +3077,7 @@ static int decode_nal_units(HEVCContext *s, const uint8_t
*buf, int length)
if (s->avctx->skip_frame >= AVDISCARD_ALL ||
(s->avctx->skip_frame >= AVDISCARD_NONREF
-&& ff_hevc_nal_is_nonref(nal->type)))
+&& ff_hevc_nal_is_nonref(nal->type)) || nal->nuh_layer_id > 0)
continue;
ret = decode_nal_unit(s, nal);
--
2.24.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/2] lavc/h2645_parse: Reorder H2645NAL to reduce size
From: Andriy Gelman
Size of H2645NAL reduced from 112 to 104 bytes on x86-64.
Signed-off-by: Andriy Gelman
---
libavcodec/h2645_parse.h | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/libavcodec/h2645_parse.h b/libavcodec/h2645_parse.h
index 3e47f86c53b..b88707f207c 100644
--- a/libavcodec/h2645_parse.h
+++ b/libavcodec/h2645_parse.h
@@ -32,8 +32,8 @@
typedef struct H2645NAL {
uint8_t *rbsp_buffer;
-int size;
const uint8_t *data;
+int size;
/**
* Size, in bits, of just the data, excluding the stop bit and any trailing
@@ -41,16 +41,16 @@ typedef struct H2645NAL {
*/
int size_bits;
-int raw_size;
-const uint8_t *raw_data;
-
-GetBitContext gb;
-
/**
* NAL unit type
*/
int type;
+int raw_size;
+const uint8_t *raw_data;
+
+GetBitContext gb;
+
/**
* HEVC only, nuh_temporal_id_plus_1 - 1
*/
@@ -61,13 +61,14 @@ typedef struct H2645NAL {
*/
int nuh_layer_id;
-int skipped_bytes;
-int skipped_bytes_pos_size;
-int *skipped_bytes_pos;
/**
* H.264 only, nal_ref_idc
*/
int ref_idc;
+
+int skipped_bytes;
+int skipped_bytes_pos_size;
+int *skipped_bytes_pos;
} H2645NAL;
typedef struct H2645RBSP {
--
2.24.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 v1] avcodec/cbs_av1: rename enable_intraintra_compound flag
rename enable_intraintra_compound to enable_interintra_compound,
which keep same as AV1 sepc(v1.0.0-errata1).
Signed-off-by: Wangfei
---
libavcodec/cbs_av1.h | 2 +-
libavcodec/cbs_av1_syntax_template.c | 4 ++--
libavformat/av1.c| 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
index 9eaf5c4de6..50a05d2168 100644
--- a/libavcodec/cbs_av1.h
+++ b/libavcodec/cbs_av1.h
@@ -105,7 +105,7 @@ typedef struct AV1RawSequenceHeader {
uint8_t use_128x128_superblock;
uint8_t enable_filter_intra;
uint8_t enable_intra_edge_filter;
-uint8_t enable_intraintra_compound;
+uint8_t enable_interintra_compound;
uint8_t enable_masked_compound;
uint8_t enable_warped_motion;
uint8_t enable_dual_filter;
diff --git a/libavcodec/cbs_av1_syntax_template.c
b/libavcodec/cbs_av1_syntax_template.c
index 6c4816f964..f53955c52e 100644
--- a/libavcodec/cbs_av1_syntax_template.c
+++ b/libavcodec/cbs_av1_syntax_template.c
@@ -268,7 +268,7 @@ static int FUNC(sequence_header_obu)(CodedBitstreamContext
*ctx, RWContext *rw,
flag(enable_intra_edge_filter);
if (current->reduced_still_picture_header) {
-infer(enable_intraintra_compound, 0);
+infer(enable_interintra_compound, 0);
infer(enable_masked_compound, 0);
infer(enable_warped_motion, 0);
infer(enable_dual_filter, 0);
@@ -281,7 +281,7 @@ static int FUNC(sequence_header_obu)(CodedBitstreamContext
*ctx, RWContext *rw,
infer(seq_force_integer_mv,
AV1_SELECT_INTEGER_MV);
} else {
-flag(enable_intraintra_compound);
+flag(enable_interintra_compound);
flag(enable_masked_compound);
flag(enable_warped_motion);
flag(enable_dual_filter);
diff --git a/libavformat/av1.c b/libavformat/av1.c
index 132f4e987b..5ad9222900 100644
--- a/libavformat/av1.c
+++ b/libavformat/av1.c
@@ -257,7 +257,7 @@ static int parse_sequence_header(AV1SequenceParameters
*seq_params, const uint8_
if (!reduced_still_picture_header) {
int enable_order_hint, seq_force_screen_content_tools;
-skip_bits(&gb, 4); // enable_intraintra_compound (1),
enable_masked_compound (1)
+skip_bits(&gb, 4); // enable_interintra_compound (1),
enable_masked_compound (1)
// enable_warped_motion (1), enable_dual_filter (1)
enable_order_hint = get_bits1(&gb);
--
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 v3] avformat/matroskaenc: Use random TrackUID
Michael Niedermayer: > On Tue, Dec 03, 2019 at 04:19:47PM +0100, Andreas Rheinhardt wrote: >> Up until now, the TrackUID of a Matroska track which is supposed to be >> random was not random at all: It always coincided with the TrackNumber >> which is usually the 1-based index of the corresponding stream in the >> array of AVStreams. This has been changed: It is now set via an AVLFG >> if AVFMT_FLAG_BITEXACT is not set. Otherwise it is set like it is set >> now (the only change happens if an explicit track number has been >> chosen via dash_track_number, because the system used in the normal >> situation is now used, too). In particular, no FATE tests need to be >> updated. >> >> This also fixes a bug in case the dash_track_number option was used: >> In this case the TrackUID was set to the track number, but the tags were >> written with a TagTrackUID simply based upon the index, so that the tags >> didn't apply to the track they ought to apply to. > > LGTM > thx > Good to hear. When merging, the fix for ChapterUIDs (https://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253440.html) should get merged first. > >> >> Signed-off-by: Andreas Rheinhardt >> --- >> I have updated the patchset to rely on the AVLFG to provide sufficiently >> many distinct values, as you said. I could add a check and a for if we still >> have a collision after (say) 1000 tries in order to avoid the >> potentially infinite loop. > > You could replace the LFG if you dont trust it. > But i dont understand why you would use it when you dont trust it and then > add a check > I actually trust that it works; it's just that I can't furnish a proof. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] tools: add a fuzzer tool for bitstream filters
On 12/5/2019 6:57 PM, Michael Niedermayer wrote: > On Tue, Dec 03, 2019 at 06:05:41PM -0300, James Almer wrote: >> Signed-off-by: James Almer >> --- >> tools/Makefile| 3 + >> tools/target_bsf_fuzzer.c | 153 ++ >> 2 files changed, 156 insertions(+) >> create mode 100644 tools/target_bsf_fuzzer.c >> >> diff --git a/tools/Makefile b/tools/Makefile >> index 370ee35416..001093105b 100644 >> --- a/tools/Makefile >> +++ b/tools/Makefile >> @@ -5,6 +5,9 @@ TOOLS-$(CONFIG_ZLIB) += cws2fws >> tools/target_dec_%_fuzzer.o: tools/target_dec_fuzzer.c >> $(COMPILE_C) -DFFMPEG_DECODER=$* >> >> +tools/target_bsf_%_fuzzer.o: tools/target_bsf_fuzzer.c >> +$(COMPILE_C) -DFFMPEG_BSF=$* >> + >> tools/target_dem_fuzzer.o: tools/target_dem_fuzzer.c >> $(COMPILE_C) > > This is missing something like: > diff --git a/Makefile b/Makefile > index 532372c9c4..7a0700a80b 100644 > --- a/Makefile > +++ b/Makefile > @@ -50,6 +50,9 @@ $(TOOLS): %$(EXESUF): %.o > target_dec_%_fuzzer$(EXESUF): target_dec_%_fuzzer.o $(FF_DEP_LIBS) > $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS) > $(LIBFUZZER_PATH) > > +target_bsf_%_fuzzer$(EXESUF): target_bsf_%_fuzzer.o $(FF_DEP_LIBS) > + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS) > $(LIBFUZZER_PATH) > + > tools/target_dem_fuzzer$(EXESUF): tools/target_dem_fuzzer.o $(FF_DEP_LIBS) > $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS) > $(LIBFUZZER_PATH) > > LGTM otherwise, only tested locally though > > thx Will add the above and push. 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] avutil/buffer: use appropriate atomic operations
On 12/5/2019 6:02 AM, quinkbl...@foxmail.com wrote:
> From: Zhao Zhili
>
> No functional changes. ref/unref vs add/sub is symmetrical.
> ---
> libavutil/buffer.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/buffer.c b/libavutil/buffer.c
> index 8d1aa5fa84..f0034b026a 100644
> --- a/libavutil/buffer.c
> +++ b/libavutil/buffer.c
> @@ -116,7 +116,7 @@ static void buffer_replace(AVBufferRef **dst, AVBufferRef
> **src)
> } else
> av_freep(dst);
>
> -if (atomic_fetch_add_explicit(&b->refcount, -1, memory_order_acq_rel) ==
> 1) {
> +if (atomic_fetch_sub_explicit(&b->refcount, 1, memory_order_acq_rel) ==
> 1) {
> b->free(b->opaque, b->data);
> av_freep(&b);
> }
> @@ -281,7 +281,7 @@ void av_buffer_pool_uninit(AVBufferPool **ppool)
> pool = *ppool;
> *ppool = NULL;
>
> -if (atomic_fetch_add_explicit(&pool->refcount, -1, memory_order_acq_rel)
> == 1)
> +if (atomic_fetch_sub_explicit(&pool->refcount, 1, memory_order_acq_rel)
> == 1)
> buffer_pool_free(pool);
> }
>
> @@ -298,7 +298,7 @@ static void pool_release_buffer(void *opaque, uint8_t
> *data)
> pool->pool = buf;
> ff_mutex_unlock(&pool->mutex);
>
> -if (atomic_fetch_add_explicit(&pool->refcount, -1, memory_order_acq_rel)
> == 1)
> +if (atomic_fetch_sub_explicit(&pool->refcount, 1, memory_order_acq_rel)
> == 1)
> buffer_pool_free(pool);
> }
Applied, 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 1/2] avcodec/mvha: Check remaining space when reading VLC table probabilities
LGTM
On 12/6/19, Michael Niedermayer wrote:
> Fixes: Infinite loop
> Fixes:
> 19183/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MVHA_fuzzer-5666216765292544
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/mvha.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/mvha.c b/libavcodec/mvha.c
> index 4b03a79283..c270063b1c 100644
> --- a/libavcodec/mvha.c
> +++ b/libavcodec/mvha.c
> @@ -203,6 +203,9 @@ static int decode_frame(AVCodecContext *avctx,
> for (int i = 0; i < s->nb_symbols; symbol++) {
> int prob;
>
> +if (get_bits_left(gb) < 4)
> +return AVERROR_INVALIDDATA;
> +
> if (get_bits1(gb)) {
> prob = get_bits(gb, 12);
> } else {
> --
> 2.23.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avformat/mpeg: Don't copy or leak string in AVBPrint
Michael Niedermayer: > On Wed, Dec 04, 2019 at 01:37:13PM +0100, Andreas Rheinhardt wrote: >> vobsub_read_header() uses an AVBPrint to write a string and up until >> now, it collected the string stored in the AVBPrint via >> av_bprint_finalize(), which might involve an allocation and copy of the >> string. But this is unnecessary, as the lifetime of the returned string >> does not exceed the lifetime of the AVBPrint. So use the string in the >> AVBPrint directly. >> >> This also makes it possible to easily fix a memleak: In certain error >> situations, the string stored in the AVBPrint would not be freed (if it >> was dynamically allocated). This has been fixed, too. >> >> Signed-off-by: Andreas Rheinhardt >> --- >> Supersedes https://ffmpeg.org/pipermail/ffmpeg-devel/2019-October/252074.html >> Resending because of merge conflict. > > will apply > > thx > Thanks. During checking whether my patches work I have also found a use of uninitialized values in vobsub_read_packet() [1]; and earlier I have found a way to eliminate the secondary packet when reading VobSub [2]. Could you look over them, too? - Andreas [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-October/251961.html [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-October/251146.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] [PATCH 2/2] avcodec/mpeg12dec: Fix invalid shift in mpeg2_fast_decode_block_intra()
Fixes: left shift of negative value -695 Fixes: 19232/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG1VIDEO_fuzzer-5702856963522560 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/mpeg12dec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c index 775579f9f0..4643992d28 100644 --- a/libavcodec/mpeg12dec.c +++ b/libavcodec/mpeg12dec.c @@ -586,7 +586,7 @@ static inline int mpeg2_fast_decode_block_intra(MpegEncContext *s, dc = s->last_dc[component]; dc += diff; s->last_dc[component] = dc; -block[0] = dc << (3 - s->intra_dc_precision); +block[0] = dc * (1 << (3 - s->intra_dc_precision)); i = 0; if (s->intra_vlc_format) rl = &ff_rl_mpeg2; -- 2.23.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 1/2] avcodec/mvha: Check remaining space when reading VLC table probabilities
Fixes: Infinite loop
Fixes:
19183/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MVHA_fuzzer-5666216765292544
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mvha.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/mvha.c b/libavcodec/mvha.c
index 4b03a79283..c270063b1c 100644
--- a/libavcodec/mvha.c
+++ b/libavcodec/mvha.c
@@ -203,6 +203,9 @@ static int decode_frame(AVCodecContext *avctx,
for (int i = 0; i < s->nb_symbols; symbol++) {
int prob;
+if (get_bits_left(gb) < 4)
+return AVERROR_INVALIDDATA;
+
if (get_bits1(gb)) {
prob = get_bits(gb, 12);
} else {
--
2.23.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] tools: add a fuzzer tool for bitstream filters
On Tue, Dec 03, 2019 at 06:05:41PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > tools/Makefile| 3 + > tools/target_bsf_fuzzer.c | 153 ++ > 2 files changed, 156 insertions(+) > create mode 100644 tools/target_bsf_fuzzer.c > > diff --git a/tools/Makefile b/tools/Makefile > index 370ee35416..001093105b 100644 > --- a/tools/Makefile > +++ b/tools/Makefile > @@ -5,6 +5,9 @@ TOOLS-$(CONFIG_ZLIB) += cws2fws > tools/target_dec_%_fuzzer.o: tools/target_dec_fuzzer.c > $(COMPILE_C) -DFFMPEG_DECODER=$* > > +tools/target_bsf_%_fuzzer.o: tools/target_bsf_fuzzer.c > + $(COMPILE_C) -DFFMPEG_BSF=$* > + > tools/target_dem_fuzzer.o: tools/target_dem_fuzzer.c > $(COMPILE_C) This is missing something like: diff --git a/Makefile b/Makefile index 532372c9c4..7a0700a80b 100644 --- a/Makefile +++ b/Makefile @@ -50,6 +50,9 @@ $(TOOLS): %$(EXESUF): %.o target_dec_%_fuzzer$(EXESUF): target_dec_%_fuzzer.o $(FF_DEP_LIBS) $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS) $(LIBFUZZER_PATH) +target_bsf_%_fuzzer$(EXESUF): target_bsf_%_fuzzer.o $(FF_DEP_LIBS) + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS) $(LIBFUZZER_PATH) + tools/target_dem_fuzzer$(EXESUF): tools/target_dem_fuzzer.o $(FF_DEP_LIBS) $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS) $(LIBFUZZER_PATH) LGTM otherwise, only tested locally though thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin 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] lavc/h2645_parse: Don't automatically remove nuh_layer_id > 0 packets
On Mon, 02. Dec 00:07, James Almer wrote:
> On 12/1/2019 11:48 PM, Andriy Gelman wrote:
> > From: Andriy Gelman
> >
> > HEVC standard supports multi-layer streams (ITU-T H.265 02/2018 Annex
> > F). Each NAL unit belongs to a particular layer defined by nuh_layer_id
> > in the header.
> >
> > Currently, all NAL units that do not belong to a base layer are
> > automatically removed in ff_h2645_packet_split(). Some data may
> > therefore be lost when future filters/decoders are designed to support
> > multi-layer streams.
> >
> > A better approach is to forward nuh_layer_id > 0 packets and let blocks
> > down the chain decide how to process them. The condition to remove
> > packets has been moved to hevcdec and cbs bsf where such packets are
> > currently not supported.
> > ---
> > libavcodec/cbs_h2645.c | 3 +++
> > libavcodec/h2645_parse.c | 7 +++
> > libavcodec/h2645_parse.h | 5 +
> > libavcodec/hevc_parse.c | 2 ++
> > libavcodec/hevc_parser.c | 2 ++
> > libavcodec/hevcdec.c | 2 +-
> > 6 files changed, 16 insertions(+), 5 deletions(-)
>
> Missing changes to extract_extradata_bsf.
>
> >
> > diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> > index 88fa0029cd6..9f89f1c5a55 100644
> > --- a/libavcodec/cbs_h2645.c
> > +++ b/libavcodec/cbs_h2645.c
> > @@ -562,6 +562,9 @@ static int
> > cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
> >
> > for (i = 0; i < packet->nb_nals; i++) {
> > const H2645NAL *nal = &packet->nals[i];
> > +if (nal->nuh_layer_id > 0)
> > +continue;
>
> CBS itself must not ignore them. Users of CBS should be able to choose
> to ignore them, same way you're doing it for h2645_parse and its users
> below.
James, Andreas,
The parameter sets for multi-layer streams are parsed differently to the
base-layer. See for example SPS p.35 vs p.432 ITU-H265 (02/2018).
CBS only supports parsing nuh_layer_id = 0 at the moment. I have checked with a
multi-layer stream and CBS errors out.
Do you agree then that the above check should stay in the patch?
Thanks,
--
Andriy
___
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] avformat/mpeg: Fix leaks of AVFormatContext and subtitle packets
On Wed, Dec 04, 2019 at 01:37:14PM +0100, Andreas Rheinhardt wrote: > If an error happens in vobsub_read_header() after allocating the > AVFormatContext intended to read the sub-file, both the AVFormatContext > as well as the data in the subtitles queues leaks. This has been fixed. > > Signed-off-by: Andreas Rheinhardt > --- > Supersedes https://ffmpeg.org/pipermail/ffmpeg-devel/2019-October/252075.html > Resending because of merge conflicts. will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avformat/mpeg: Don't copy or leak string in AVBPrint
On Wed, Dec 04, 2019 at 01:37:13PM +0100, Andreas Rheinhardt wrote: > vobsub_read_header() uses an AVBPrint to write a string and up until > now, it collected the string stored in the AVBPrint via > av_bprint_finalize(), which might involve an allocation and copy of the > string. But this is unnecessary, as the lifetime of the returned string > does not exceed the lifetime of the AVBPrint. So use the string in the > AVBPrint directly. > > This also makes it possible to easily fix a memleak: In certain error > situations, the string stored in the AVBPrint would not be freed (if it > was dynamically allocated). This has been fixed, too. > > Signed-off-by: Andreas Rheinhardt > --- > Supersedes https://ffmpeg.org/pipermail/ffmpeg-devel/2019-October/252074.html > Resending because of merge conflict. will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus 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 1/3] avformat/mpeg: Make VobSub demuxer have its own context struct
On Wed, Dec 04, 2019 at 01:37:12PM +0100, Andreas Rheinhardt wrote: > When the VobSub demuxer was added, the fields it required were simply > added to the MpegDemuxContext (if the VobSub demuxer was selected at > all). The mpeg demuxer of course doesn't use these fields even if they > are there; and the VobSub demuxer doesn't use the old ones: It opens an > mpeg subdemuxer of its own and uses this where a mpeg demuxer is > required. Hence the two contexts can be split, saving memory. > > Furthermore several headers can now be moved to the section that is > guarded by #if CONFIG_VOBSUB_DEMUXER (this even includes avassert.h > which was unguarded and has been added in 9cde9f70 despite not being > used in that patch). > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/mpeg.c | 38 ++ > 1 file changed, 18 insertions(+), 20 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange 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 4/5] avcodec/fitsdec: Use lrint()
On Thu, Dec 05, 2019 at 02:51:32PM -0300, James Almer wrote: > On 12/5/2019 2:46 PM, Michael Niedermayer wrote: > > On Mon, Sep 30, 2019 at 10:30:59PM -0300, James Almer wrote: > >> On 9/30/2019 1:30 PM, Michael Niedermayer wrote: > >>> Fixes: -nan is outside the range of representable values of type > >>> 'unsigned short' > >> > >> From lrint documentation: > >> > >> "If x is a NaN or an infinity, or the rounded value is too large to be > >> stored in a long (long long in the case of the ll* functions), then a > >> domain error occurs, and the return value is unspecified." > >> > >> So i don't know if using lrint is a good idea here. > >> > >>> Fixes: > >>> 17769/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FITS_fuzzer-5678314672357376 > >> > >> Is the output of av_int2double/av_int2float or header.data_min NaN in > >> that testcase? Wouldn't it be better to check that instead, and abort? > > > > This patch also fixes the fate failures on 32bit x86 fitsdec-bitpix-64 > > > > I can add per pixel checks but i expect that not to fix fate > > so i suggest to apply this as a fate fix first and then we can decide if we > > need an additional fix for NaN > > > > thx > > Fine by me. will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/crop: avoid premature eval error
On 04-12-2019 04:09 pm, Gyan wrote: Valid width expressions were being rejected. Plan to push in the morning. 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 4/5] avcodec/fitsdec: Use lrint()
On 12/5/2019 2:46 PM, Michael Niedermayer wrote: > On Mon, Sep 30, 2019 at 10:30:59PM -0300, James Almer wrote: >> On 9/30/2019 1:30 PM, Michael Niedermayer wrote: >>> Fixes: -nan is outside the range of representable values of type 'unsigned >>> short' >> >> From lrint documentation: >> >> "If x is a NaN or an infinity, or the rounded value is too large to be >> stored in a long (long long in the case of the ll* functions), then a >> domain error occurs, and the return value is unspecified." >> >> So i don't know if using lrint is a good idea here. >> >>> Fixes: >>> 17769/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FITS_fuzzer-5678314672357376 >> >> Is the output of av_int2double/av_int2float or header.data_min NaN in >> that testcase? Wouldn't it be better to check that instead, and abort? > > This patch also fixes the fate failures on 32bit x86 fitsdec-bitpix-64 > > I can add per pixel checks but i expect that not to fix fate > so i suggest to apply this as a fate fix first and then we can decide if we > need an additional fix for NaN > > thx Fine by me. ___ 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] avcodec/fitsdec: Use lrint()
On Mon, Sep 30, 2019 at 10:30:59PM -0300, James Almer wrote: > On 9/30/2019 1:30 PM, Michael Niedermayer wrote: > > Fixes: -nan is outside the range of representable values of type 'unsigned > > short' > > From lrint documentation: > > "If x is a NaN or an infinity, or the rounded value is too large to be > stored in a long (long long in the case of the ll* functions), then a > domain error occurs, and the return value is unspecified." > > So i don't know if using lrint is a good idea here. > > > Fixes: > > 17769/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FITS_fuzzer-5678314672357376 > > Is the output of av_int2double/av_int2float or header.data_min NaN in > that testcase? Wouldn't it be better to check that instead, and abort? This patch also fixes the fate failures on 32bit x86 fitsdec-bitpix-64 I can add per pixel checks but i expect that not to fix fate so i suggest to apply this as a fate fix first and then we can decide if we need an additional fix for NaN thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates 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 v2 1/3] avfilter/vf_elbg: Fix for the seed type
On Wed, Dec 04, 2019 at 08:31:15PM +0100, Michael Niedermayer wrote: > On Fri, Nov 22, 2019 at 09:50:36AM +0800, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Signed-off-by: Limin Wang > > --- > > libavfilter/vf_elbg.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > will apply Thanks, please help to review the PATCH v2 2/3 and 3/3 also, they're fix the same typo. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I have never wished to cater to the crowd; for what I know they do not > approve, and what they approve I do not know. -- Epicurus > ___ > 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, v3, 1/7] lavu/pixfmt: add new pixel format 0yuv/y210/y410
On 12/5/19, James Darnley wrote:
> On 2019-12-04 15:43, Linjie Fu wrote:
>> Previously, media driver provided planar format(like 420 8 bit),
>> but for HEVC Range Extension (422/444 8/10 bit), the decoded image
>> is produced in packed format because Windows expects it.
>>
>> Add some packed pixel formats for hardware decode support in VAAPI
>> and QSV:
>>
>> 4:2:2 10 bit: Y210
>> 4:4:4 8 bit: 0YUV
>> 4:4:4 10 bit: Y410
>>
>
>> +[AV_PIX_FMT_Y410LE] = {
>> +.name = "y410le",
>> +.nb_components = 4,
>> +.log2_chroma_w = 0,
>> +.log2_chroma_h = 0,
>> +.comp = {
>> +{ 0, 32, 10, 0, 10, 31, 9, 11 },/* Y */
>> +{ 0, 32, 0, 0, 10, 31, 9, 1 },/* U */
>> +{ 0, 32, 20, 0, 10, 31, 9, 21 },/* V */
>> +{ 0, 32, 30, 0, 2, 31, 1, 31 },/* A */
>> +},
>> +.flags = AV_PIX_FMT_FLAG_ALPHA | AV_PIX_FMT_FLAG_BITSTREAM,
>> +},
>
>
>
>> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
>> index d78e863..a163350 100644
>> --- a/libavutil/pixfmt.h
>> +++ b/libavutil/pixfmt.h
>> @@ -348,6 +348,12 @@ enum AVPixelFormat {
>> AV_PIX_FMT_NV24, ///< planar YUV 4:4:4, 24bpp, 1 plane for Y and
>> 1 plane for the UV components, which are interleaved (first byte U and the
>> following byte V)
>> AV_PIX_FMT_NV42, ///< as above, but U and V bytes are swapped
>>
>> +AV_PIX_FMT_Y210BE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
>> big-endian
>> +AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
>> little-endian
>> +AV_PIX_FMT_0YUV, ///< packed YUV 4:4:4, 32bpp, X Y Cb Cr,
>> X=unused/undefined
>> +AV_PIX_FMT_Y410LE,///< packed YUV 4:4:4, 32bpp, Cr Y Cb A,
>> little-endian
>> +AV_PIX_FMT_Y410BE,///< packed YUV 4:4:4, 32bpp, Cr Y Cb A,
>> big-endian
>> +
>> AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS
>> if you want to link with shared libav* because the number of formats might
>> differ between versions
>> };
>>
>
> I will ask again. From
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245929.html
>
>> Why am I suspicious that at least one of those is a re-ordered v210? I
>> seem to recall that we rejected adding v210 to this list. Either they
>> don't belong in this list or they don't belong because libavcodec has a
>> proper decoder (at least for v210).
>>
>> This might be the thread I was remembering but March seems too recent
>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241549.html
>>
>> No real conclusion was reached there.
>>
>> Do bit-packed formats belong in an AVPixelFormat?
>
> Despite what was said last time I do believe this is packed. I have
> taken a little time to actually understand these magic number structs.
>
> y410 is clearly packed like v210. Look at the those offsets: 0, 10, 20,
> 30. Packed into a 32-bit word. Flagged with AV_PIX_FMT_FLAG_BITSTREAM.
>
> How is that any different to v210? Can you address a single sample in
> that 1 plane format without using shifts and bit-wise ands? Isn't that
> the definition of packed? I do not mean interleaved.
>
> Okay, y410 is a little better in that it is 444 so the sample order does
> not change through 6 word cycle. Is that the key difference?
>
>
>
> Do bit-packed formats belong in an AVPixelFormat?
>
> If yes then I do not object to this patch or any others like this.
>
> If no then why is this not rejected?
Please summon Technical Committee, they sure will know the answer ;-)
>
>
>
> Does the AV_PIX_FMT_FLAG_BITSTREAM flag mean they do belong? I admit I
> haven't seen this before so maybe I should shut up and not send this email.
>
>
>
___
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, 1/7] lavu/pixfmt: add new pixel format 0yuv/y210/y410
On 2019-12-04 15:43, Linjie Fu wrote:
> Previously, media driver provided planar format(like 420 8 bit),
> but for HEVC Range Extension (422/444 8/10 bit), the decoded image
> is produced in packed format because Windows expects it.
>
> Add some packed pixel formats for hardware decode support in VAAPI
> and QSV:
>
> 4:2:2 10 bit: Y210
> 4:4:4 8 bit: 0YUV
> 4:4:4 10 bit: Y410
>
> +[AV_PIX_FMT_Y410LE] = {
> +.name = "y410le",
> +.nb_components = 4,
> +.log2_chroma_w = 0,
> +.log2_chroma_h = 0,
> +.comp = {
> +{ 0, 32, 10, 0, 10, 31, 9, 11 },/* Y */
> +{ 0, 32, 0, 0, 10, 31, 9, 1 },/* U */
> +{ 0, 32, 20, 0, 10, 31, 9, 21 },/* V */
> +{ 0, 32, 30, 0, 2, 31, 1, 31 },/* A */
> +},
> +.flags = AV_PIX_FMT_FLAG_ALPHA | AV_PIX_FMT_FLAG_BITSTREAM,
> +},
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index d78e863..a163350 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -348,6 +348,12 @@ enum AVPixelFormat {
> AV_PIX_FMT_NV24, ///< planar YUV 4:4:4, 24bpp, 1 plane for Y and 1
> plane for the UV components, which are interleaved (first byte U and the
> following byte V)
> AV_PIX_FMT_NV42, ///< as above, but U and V bytes are swapped
>
> +AV_PIX_FMT_Y210BE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
> big-endian
> +AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
> little-endian
> +AV_PIX_FMT_0YUV, ///< packed YUV 4:4:4, 32bpp, X Y Cb Cr,
> X=unused/undefined
> +AV_PIX_FMT_Y410LE,///< packed YUV 4:4:4, 32bpp, Cr Y Cb A,
> little-endian
> +AV_PIX_FMT_Y410BE,///< packed YUV 4:4:4, 32bpp, Cr Y Cb A,
> big-endian
> +
> AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if
> you want to link with shared libav* because the number of formats might
> differ between versions
> };
>
I will ask again. From
> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245929.html
> Why am I suspicious that at least one of those is a re-ordered v210? I
> seem to recall that we rejected adding v210 to this list. Either they
> don't belong in this list or they don't belong because libavcodec has a
> proper decoder (at least for v210).
>
> This might be the thread I was remembering but March seems too recent
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241549.html
>
> No real conclusion was reached there.
>
> Do bit-packed formats belong in an AVPixelFormat?
Despite what was said last time I do believe this is packed. I have
taken a little time to actually understand these magic number structs.
y410 is clearly packed like v210. Look at the those offsets: 0, 10, 20,
30. Packed into a 32-bit word. Flagged with AV_PIX_FMT_FLAG_BITSTREAM.
How is that any different to v210? Can you address a single sample in
that 1 plane format without using shifts and bit-wise ands? Isn't that
the definition of packed? I do not mean interleaved.
Okay, y410 is a little better in that it is 444 so the sample order does
not change through 6 word cycle. Is that the key difference?
Do bit-packed formats belong in an AVPixelFormat?
If yes then I do not object to this patch or any others like this.
If no then why is this not rejected?
Does the AV_PIX_FMT_FLAG_BITSTREAM flag mean they do belong? I admit I
haven't seen this before so maybe I should shut up and not send this email.
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_yaepblur: add yaepblur filter
On 12/5/19, Tao Zhang wrote:
> Hello everyone,
> Can I assume this patch is ok if no comments or objections?
Yes, give some time for it to be applied.
I'm busy with other stuff right now. So this patch LGTM (Note to
committer to bump minor of libavfiter upon pushing).
>
> Tao Zhang 于2019年12月3日周二 下午5:26写道：
>>
>> ping:)
>>
>> leozhang 于2019年11月25日周一 下午5:53写道：
>> >
>> > Signed-off-by: leozhang
>> > ---
>> > This filter blur the input while preserving edges, with slice threads
>> > speed up.
>> > My test speed is about 100fps on 1080p video with 16 threads, on my test
>> > machine whose cpu is E5-2660 v4 2.0GHz using 16 threads.
>> > I gauss that i7-9700K 3.6GHz can run faster more.
>> > The test command is
>> > ffmpeg -s 1920x1080 -r 30 -i your_test_file.yuv -filter_threads 16 -vf
>> > yaepblur -f null -
>> >
>> > doc/filters.texi | 22 +++
>> > libavfilter/Makefile | 1 +
>> > libavfilter/allfilters.c | 1 +
>> > libavfilter/vf_yaepblur.c | 349
>> > ++
>> > 4 files changed, 373 insertions(+)
>> > create mode 100644 libavfilter/vf_yaepblur.c
>> >
>> > diff --git a/doc/filters.texi b/doc/filters.texi
>> > index c04421b..61e93d5 100644
>> > --- a/doc/filters.texi
>> > +++ b/doc/filters.texi
>> > @@ -19775,6 +19775,28 @@ Only deinterlace frames marked as interlaced.
>> > The default value is @code{all}.
>> > @end table
>> >
>> > +@section yaepblur
>> > +
>> > +Apply blur filter while preserving edges ("yaepblur" means "yet another
>> > edge preserving blur filter").
>> > +The algorithm is described in
>> > +"J. S. Lee, Digital image enhancement and noise filtering by use of
>> > local statistics, IEEE Trans. Pattern Anal. Mach. Intell. PAMI-2, 1980."
>> > +
>> > +It accepts the following parameters:
>> > +
>> > +@table @option
>> > +@item radius, r
>> > +Set the window radius. Default value is 3.
>> > +
>> > +@item planes, p
>> > +Set which planes to filter. Default is only the first plane.
>> > +
>> > +@item sigma, s
>> > +Set blur strength. Default value is 128.
>> > +@end table
>> > +
>> > +@subsection Commands
>> > +This filter supports same @ref{commands} as options.
>> > +
>> > @section zoompan
>> >
>> > Apply Zoom & Pan effect.
>> > diff --git a/libavfilter/Makefile b/libavfilter/Makefile
>> > index 6838d5c..b490a44 100644
>> > --- a/libavfilter/Makefile
>> > +++ b/libavfilter/Makefile
>> > @@ -442,6 +442,7 @@ OBJS-$(CONFIG_XSTACK_FILTER) +=
>> > vf_stack.o framesync.o
>> > OBJS-$(CONFIG_YADIF_FILTER) += vf_yadif.o
>> > yadif_common.o
>> > OBJS-$(CONFIG_YADIF_CUDA_FILTER) += vf_yadif_cuda.o
>> > vf_yadif_cuda.ptx.o \
>> > yadif_common.o
>> > +OBJS-$(CONFIG_YAEPBLUR_FILTER) += vf_yaepblur.o
>> > OBJS-$(CONFIG_ZMQ_FILTER)+= f_zmq.o
>> > OBJS-$(CONFIG_ZOOMPAN_FILTER)+= vf_zoompan.o
>> > OBJS-$(CONFIG_ZSCALE_FILTER) += vf_zscale.o
>> > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
>> > index 7c1e19e..8f41186 100644
>> > --- a/libavfilter/allfilters.c
>> > +++ b/libavfilter/allfilters.c
>> > @@ -420,6 +420,7 @@ extern AVFilter ff_vf_xmedian;
>> > extern AVFilter ff_vf_xstack;
>> > extern AVFilter ff_vf_yadif;
>> > extern AVFilter ff_vf_yadif_cuda;
>> > +extern AVFilter ff_vf_yaepblur;
>> > extern AVFilter ff_vf_zmq;
>> > extern AVFilter ff_vf_zoompan;
>> > extern AVFilter ff_vf_zscale;
>> > diff --git a/libavfilter/vf_yaepblur.c b/libavfilter/vf_yaepblur.c
>> > new file mode 100644
>> > index 000..ef6fbc9
>> > --- /dev/null
>> > +++ b/libavfilter/vf_yaepblur.c
>> > @@ -0,0 +1,349 @@
>> > +/*
>> > + * Copyright (C) 2019 Leo Zhang
>> > +
>> > + * This file is part of FFmpeg.
>> > + *
>> > + * FFmpeg is free software; you can redistribute it and/or
>> > + * modify it under the terms of the GNU Lesser General Public
>> > + * License as published by the Free Software Foundation; either
>> > + * version 2.1 of the License, or (at your option) any later version.
>> > + *
>> > + * FFmpeg is distributed in the hope that it will be useful,
>> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> > + * Lesser General Public License for more details.
>> > + *
>> > + * You should have received a copy of the GNU Lesser General Public
>> > + * License along with FFmpeg; if not, write to the Free Software
>> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>> > 02110-1301 USA
>> > + */
>> > +
>> > +/**
>> > + * @file
>> > + * yaep(yet another edge preserving) blur filter
>> > + *
>> > + * This implementation is based on an algorithm described in
>> > + * "J. S. Lee, Digital image enhancement and noise filtering by use of
>> > local statistics, IEEE Trans. Pattern
>> > + * Anal. Mach. Intell. PAMI-2, 1980."
>> > + */
>> > +
>> > +#include "libavutil/
Re: [FFmpeg-devel] [PATCH] avfilter/vf_yaepblur: add yaepblur filter
Hello everyone,
Can I assume this patch is ok if no comments or objections?
Tao Zhang 于2019年12月3日周二 下午5:26写道：
>
> ping:)
>
> leozhang 于2019年11月25日周一 下午5:53写道：
> >
> > Signed-off-by: leozhang
> > ---
> > This filter blur the input while preserving edges, with slice threads speed
> > up.
> > My test speed is about 100fps on 1080p video with 16 threads, on my test
> > machine whose cpu is E5-2660 v4 2.0GHz using 16 threads.
> > I gauss that i7-9700K 3.6GHz can run faster more.
> > The test command is
> > ffmpeg -s 1920x1080 -r 30 -i your_test_file.yuv -filter_threads 16 -vf
> > yaepblur -f null -
> >
> > doc/filters.texi | 22 +++
> > libavfilter/Makefile | 1 +
> > libavfilter/allfilters.c | 1 +
> > libavfilter/vf_yaepblur.c | 349
> > ++
> > 4 files changed, 373 insertions(+)
> > create mode 100644 libavfilter/vf_yaepblur.c
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index c04421b..61e93d5 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -19775,6 +19775,28 @@ Only deinterlace frames marked as interlaced.
> > The default value is @code{all}.
> > @end table
> >
> > +@section yaepblur
> > +
> > +Apply blur filter while preserving edges ("yaepblur" means "yet another
> > edge preserving blur filter").
> > +The algorithm is described in
> > +"J. S. Lee, Digital image enhancement and noise filtering by use of local
> > statistics, IEEE Trans. Pattern Anal. Mach. Intell. PAMI-2, 1980."
> > +
> > +It accepts the following parameters:
> > +
> > +@table @option
> > +@item radius, r
> > +Set the window radius. Default value is 3.
> > +
> > +@item planes, p
> > +Set which planes to filter. Default is only the first plane.
> > +
> > +@item sigma, s
> > +Set blur strength. Default value is 128.
> > +@end table
> > +
> > +@subsection Commands
> > +This filter supports same @ref{commands} as options.
> > +
> > @section zoompan
> >
> > Apply Zoom & Pan effect.
> > diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> > index 6838d5c..b490a44 100644
> > --- a/libavfilter/Makefile
> > +++ b/libavfilter/Makefile
> > @@ -442,6 +442,7 @@ OBJS-$(CONFIG_XSTACK_FILTER) +=
> > vf_stack.o framesync.o
> > OBJS-$(CONFIG_YADIF_FILTER) += vf_yadif.o yadif_common.o
> > OBJS-$(CONFIG_YADIF_CUDA_FILTER) += vf_yadif_cuda.o
> > vf_yadif_cuda.ptx.o \
> > yadif_common.o
> > +OBJS-$(CONFIG_YAEPBLUR_FILTER) += vf_yaepblur.o
> > OBJS-$(CONFIG_ZMQ_FILTER)+= f_zmq.o
> > OBJS-$(CONFIG_ZOOMPAN_FILTER)+= vf_zoompan.o
> > OBJS-$(CONFIG_ZSCALE_FILTER) += vf_zscale.o
> > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> > index 7c1e19e..8f41186 100644
> > --- a/libavfilter/allfilters.c
> > +++ b/libavfilter/allfilters.c
> > @@ -420,6 +420,7 @@ extern AVFilter ff_vf_xmedian;
> > extern AVFilter ff_vf_xstack;
> > extern AVFilter ff_vf_yadif;
> > extern AVFilter ff_vf_yadif_cuda;
> > +extern AVFilter ff_vf_yaepblur;
> > extern AVFilter ff_vf_zmq;
> > extern AVFilter ff_vf_zoompan;
> > extern AVFilter ff_vf_zscale;
> > diff --git a/libavfilter/vf_yaepblur.c b/libavfilter/vf_yaepblur.c
> > new file mode 100644
> > index 000..ef6fbc9
> > --- /dev/null
> > +++ b/libavfilter/vf_yaepblur.c
> > @@ -0,0 +1,349 @@
> > +/*
> > + * Copyright (C) 2019 Leo Zhang
> > +
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301 USA
> > + */
> > +
> > +/**
> > + * @file
> > + * yaep(yet another edge preserving) blur filter
> > + *
> > + * This implementation is based on an algorithm described in
> > + * "J. S. Lee, Digital image enhancement and noise filtering by use of
> > local statistics, IEEE Trans. Pattern
> > + * Anal. Mach. Intell. PAMI-2, 1980."
> > + */
> > +
> > +#include "libavutil/opt.h"
> > +#include "libavutil/imgutils.h"
> > +#include "avfilter.h"
> > +#include "internal.h"
> > +
> > +typedef struct YAEPContext {
> > +const AVClass *class;
> > +
> > +int planes;
> > +int radius;
> > +int sigma;
> > +
> > +int nb_planes;
> > +int planewidth[4];
> > +int planeheig
[FFmpeg-devel] [PATCH] avutil/buffer: use appropriate atomic operations
From: Zhao Zhili
No functional changes. ref/unref vs add/sub is symmetrical.
---
libavutil/buffer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavutil/buffer.c b/libavutil/buffer.c
index 8d1aa5fa84..f0034b026a 100644
--- a/libavutil/buffer.c
+++ b/libavutil/buffer.c
@@ -116,7 +116,7 @@ static void buffer_replace(AVBufferRef **dst, AVBufferRef
**src)
} else
av_freep(dst);
-if (atomic_fetch_add_explicit(&b->refcount, -1, memory_order_acq_rel) ==
1) {
+if (atomic_fetch_sub_explicit(&b->refcount, 1, memory_order_acq_rel) == 1)
{
b->free(b->opaque, b->data);
av_freep(&b);
}
@@ -281,7 +281,7 @@ void av_buffer_pool_uninit(AVBufferPool **ppool)
pool = *ppool;
*ppool = NULL;
-if (atomic_fetch_add_explicit(&pool->refcount, -1, memory_order_acq_rel)
== 1)
+if (atomic_fetch_sub_explicit(&pool->refcount, 1, memory_order_acq_rel) ==
1)
buffer_pool_free(pool);
}
@@ -298,7 +298,7 @@ static void pool_release_buffer(void *opaque, uint8_t *data)
pool->pool = buf;
ff_mutex_unlock(&pool->mutex);
-if (atomic_fetch_add_explicit(&pool->refcount, -1, memory_order_acq_rel)
== 1)
+if (atomic_fetch_sub_explicit(&pool->refcount, 1, memory_order_acq_rel) ==
1)
buffer_pool_free(pool);
}
--
2.22.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] avdevice/xcbgrab: Improve non-shm performance
On 2019-12-04 22:32:52 +0100, Marton Balint wrote: > > > On Wed, 4 Dec 2019, Kusanagi Kouichi wrote: > > > On 2019-12-03 21:25:37 +0100, Marton Balint wrote: > > > > > > > > > On Tue, 3 Dec 2019, Kusanagi Kouichi wrote: > > > > > > > On 2019-11-19 22:59:56 +0900, Kusanagi Kouichi wrote: > > > > > Use AVBufferPool. > > > > > > You don't need a buffer pool for the non-shm case, you should wrap the XCB > > > data in a buffer ref instead. I will reply with a patch that shows how it > > > is > > > done, please check if it works correctly, as I am not 100% sure how xcb > > > data > > > structures should be allocated/freed. > > > > > > > Is it safe to omit AV_INPUT_BUFFER_PADDING_SIZE bytes padding? My first > > version is identical to yours. Valgrind reported no error. But I'm not sure. > > Strictly speaking it is against the API, but the performance gains IMHO are > too big to respect the API requirement blindly. Also I see little chance > that it will cause issues, because typically avcodec/rawdec.c will simply > reassign the buffer ref to an AVFrame and keep the data untouched. And > AVFrame data does not have this requirement. If something breaks, we can > always reconsider this or find another solution. > > Regards, > Marton OK, Then can you commit your patch? ___ 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".
