[FFmpeg-devel] [PATCH] avformat/hlsenc: hls_init_time should used in living stream mode
When hls_init_time should available when hls_list_size > 0.
Because the list will not refresh new top line segment when hls_list_size is 0
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index a86fc8907f..25107d5f1c 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2938,7 +2938,7 @@ static int hls_init(AVFormatContext *s)
av_log(hls, AV_LOG_DEBUG, "start_number evaluated to %"PRId64"\n",
hls->start_sequence);
}
-hls->recording_time = hls->init_time ? hls->init_time : hls->time;
+hls->recording_time = hls->init_time && hls->max_nb_segments > 0 ?
hls->init_time : hls->time;
if (hls->flags & HLS_SPLIT_BY_TIME && hls->flags &
HLS_INDEPENDENT_SEGMENTS) {
// Independent segments cannot be guaranteed when splitting by time
--
2.29.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: validate vt context in the decoder callback
> On Dec 7, 2022, at 00:30, Alessandro Di Nepi > wrote: > > Got you; giving some context here, and you can find all the details in the > ticket #10079 (http://trac.ffmpeg.org/ticket/10079). > > The issue has been introduced with the commit > d7f4ad88a0df3c1339e142957bf2c40cd056b8ce. > This patch basically changed: > > • In the function `videotoolbox_start(AVCodecContext *avctx)`, > > ``` > -decoder_cb.decompressionOutputRefCon = avctx; > +decoder_cb.decompressionOutputRefCon = > avctx->internal->hwaccel_priv_data; > ``` > > • The context is retrieved in the function, > `videotoolbox_decoder_callback(...)` > > ``` > -AVCodecContext *avctx = opaque; > -VTContext *vtctx = avctx->internal->hwaccel_priv_data; > +VTContext *vtctx = opaque; > ``` > > Having said that, I see that when the `videotoolbox_start` is called, > > • `avctx` is not NULL, > • `avctx->internal->hwaccel_priv_data` is NULL Did you call av_videotoolbox_default_init() or av_videotoolbox_default_init2()? I think that’s why avctx->internal->hwaccel_priv_data is NULL. That code path is broken. Does remove the call of av_videotoolbox_default_init()/av_videotoolbox_default_init2() works for you? > > The first time the `videotoolbox_decoder_callback` is called, > `avctx->internal->hwaccel_priv_data` now has a value, so before d7f4ad88a > `vtctx` has a value. > After the change, since `avctx->internal->hwaccel_priv_data` is captured in > `video toolbox_start`, is NULL and `vtctx` is also NULL. > > Again, this happens just the first time the callback is called; from the > second time, vtctx has a proper value, and everything proceeds as expected. > > I'm willing to change the patch if you think there is a better way, but > something needs to be done because the library simply crashes in the current > state. > From what I see from the original change, reverting is not an option. > > Looking forward to hear feedback on this. > > Best Regards > Alessandro > On 6 Dec 2022, 7:20 +0200, "zhilizhao(赵志立)" , wrote: >> >>> On Dec 5, 2022, at 21:36, Rick Kern wrote: >>> >>> On Sun, Dec 4, 2022 at 12:51 PM Alessandro Di Nepi < >>> alessandro.din...@gmail.com> wrote: >>> On 4 Dec 2022, 17:01 +0200, FFmpeg development discussions and patches < ffmpeg-devel@ffmpeg.org>, wrote: > When this happens, does it continue happening, or is it transient? My main > concern is log spamming. Good question: this is just a transient state, so that it won't continue happening. To give you some context: when the decoding start, the value of `vtctx` is captured "too" early so that the first time the callback is called, it's still NULL. The next time it will have a proper value. >>> If the code isn't setting a variable in time, that issue should be fixed. >>> Otherwise the decoder will drop frames. >> >> Yes, null pointer check doesn’t looks like a resolution to a race >> condition. I’m not sure how the race condition happened in the first >> place. >> > ___ > 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/2] avfilter/vf_tinterlace: support full-range YUV
From: Niklas Haas
This filter, when used in the "pad" mode, currently makes the
distinction between limited and full range solely by testing for YUVJ
pixel formats at link setup time. This is deprecated and should be
improved to perform the detection based on the per-frame metadata.
In order to make this distinction based on color range metadata, which
is only known at the time of filtering frames, for simplicity, we simply
allocate two copies of the "black" frame - one for limited range and the
other for full range metadata. This could be done more dynamically (e.g.
as-needed or simply by blitting the appropriate pixel value directly),
but this change is relatively simple and preserves the structure of the
existing code.
This commit actually fixes a bug in FATE - the new output is correct for
the first time. The previous md5 ref was of a frame that incorrectly
combined full-range pixel data with limited-range black fields. The
corresponding result has been updated.
Signed-off-by: Niklas Haas
---
libavfilter/tinterlace.h | 2 +-
libavfilter/vf_tinterlace.c | 26 ++--
tests/ref/fate/filter-pixfmts-tinterlace_pad | 2 +-
3 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/libavfilter/tinterlace.h b/libavfilter/tinterlace.h
index 4059ebf81a..37b6c10c08 100644
--- a/libavfilter/tinterlace.h
+++ b/libavfilter/tinterlace.h
@@ -70,7 +70,7 @@ typedef struct TInterlaceContext {
int vsub; ///< chroma vertical subsampling
AVFrame *cur;
AVFrame *next;
-uint8_t *black_data[4]; ///< buffer used to fill padded lines
+uint8_t *black_data[2][4]; ///< buffer used to fill padded lines
(limited/full)
int black_linesize[4];
FFDrawContext draw;
FFDrawColor color;
diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c
index 7c54861de4..032629279a 100644
--- a/libavfilter/vf_tinterlace.c
+++ b/libavfilter/vf_tinterlace.c
@@ -201,7 +201,8 @@ static av_cold void uninit(AVFilterContext *ctx)
av_frame_free(&tinterlace->cur );
av_frame_free(&tinterlace->next);
-av_freep(&tinterlace->black_data[0]);
+av_freep(&tinterlace->black_data[0][0]);
+av_freep(&tinterlace->black_data[1][0]);
}
static int config_out_props(AVFilterLink *outlink)
@@ -225,14 +226,22 @@ static int config_out_props(AVFilterLink *outlink)
int ret;
ff_draw_init(&tinterlace->draw, outlink->format, 0);
ff_draw_color(&tinterlace->draw, &tinterlace->color, black);
-if (ff_fmt_is_in(outlink->format, full_scale_yuvj_pix_fmts))
-tinterlace->color.comp[0].u8[0] = 0;
-ret = av_image_alloc(tinterlace->black_data,
tinterlace->black_linesize,
+/* limited range */
+if (!ff_fmt_is_in(outlink->format, full_scale_yuvj_pix_fmts)) {
+ret = av_image_alloc(tinterlace->black_data[0],
tinterlace->black_linesize,
+ outlink->w, outlink->h, outlink->format, 16);
+if (ret < 0)
+return ret;
+ff_fill_rectangle(&tinterlace->draw, &tinterlace->color,
tinterlace->black_data[0],
+ tinterlace->black_linesize, 0, 0, outlink->w,
outlink->h);
+}
+/* full range */
+tinterlace->color.comp[0].u8[0] = 0;
+ret = av_image_alloc(tinterlace->black_data[1],
tinterlace->black_linesize,
outlink->w, outlink->h, outlink->format, 16);
if (ret < 0)
return ret;
-
-ff_fill_rectangle(&tinterlace->draw, &tinterlace->color,
tinterlace->black_data,
+ff_fill_rectangle(&tinterlace->draw, &tinterlace->color,
tinterlace->black_data[1],
tinterlace->black_linesize, 0, 0, outlink->w,
outlink->h);
}
if (tinterlace->flags & (TINTERLACE_FLAG_VLPF | TINTERLACE_FLAG_CVLPF)
@@ -360,7 +369,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*picref)
AVFilterLink *outlink = ctx->outputs[0];
TInterlaceContext *tinterlace = ctx->priv;
AVFrame *cur, *next, *out;
-int field, tff, ret;
+int field, tff, full, ret;
av_frame_free(&tinterlace->cur);
tinterlace->cur = tinterlace->next;
@@ -418,6 +427,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*picref)
out->sample_aspect_ratio = av_mul_q(cur->sample_aspect_ratio,
av_make_q(2, 1));
field = (1 + outlink->frame_count_in) & 1 ? FIELD_UPPER : FIELD_LOWER;
+full = out->color_range == AVCOL_RANGE_JPEG ||
ff_fmt_is_in(out->format, full_scale_yuvj_pix_fmts);
/* copy upper and lower fields */
copy_picture_field(tinterlace, out->data, out->linesize,
(const uint8_t **)cur->data, cur->linesize,
@@ -425,7 +435,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*picref)
FIELD_UPPER_AND_LOWER, 1, field, tinterlace->flags);
/* pad with bl
[FFmpeg-devel] [PATCH 1/2] avfilter/vf_blackdetect: support full-range YUV
From: Niklas Haas This filter currently makes the distinction between limited and full range by testing for the deprecated YUVJ pixel formats at link setup time. This is deprecated and should be improved to perform the detection based on the per-frame metadata. Rewrite it to calculate the black pixel threshold at the time of filtering a frame, when metadata about the frame's color range is known. Doing it this way has the small side benefit of being able to handle streams with variable metadata, and is not a meaningful performance cost. Signed-off-by: Niklas Haas --- libavfilter/vf_blackdetect.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/libavfilter/vf_blackdetect.c b/libavfilter/vf_blackdetect.c index 99ff1ac606..c937248169 100644 --- a/libavfilter/vf_blackdetect.c +++ b/libavfilter/vf_blackdetect.c @@ -102,8 +102,6 @@ static int config_input(AVFilterLink *inlink) BlackDetectContext *s = ctx->priv; const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format); const int depth = desc->comp[0].depth; -const int max = (1 << depth) - 1; -const int factor = (1 << (depth - 8)); s->depth = depth; s->nb_threads = ff_filter_get_nb_threads(ctx); @@ -113,16 +111,10 @@ static int config_input(AVFilterLink *inlink) if (!s->counter) return AVERROR(ENOMEM); -s->pixel_black_th_i = ff_fmt_is_in(inlink->format, yuvj_formats) ? -// luminance_minimum_value + pixel_black_th * luminance_range_size - s->pixel_black_th * max : -16 * factor + s->pixel_black_th * (235 - 16) * factor; - av_log(s, AV_LOG_VERBOSE, - "black_min_duration:%s pixel_black_th:%f pixel_black_th_i:%d picture_black_ratio_th:%f\n", + "black_min_duration:%s pixel_black_th:%f picture_black_ratio_th:%f\n", av_ts2timestr(s->black_min_duration, &s->time_base), - s->pixel_black_th, s->pixel_black_th_i, - s->picture_black_ratio_th); + s->pixel_black_th, s->picture_black_ratio_th); return 0; } @@ -182,6 +174,14 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *picref) AVFilterContext *ctx = inlink->dst; BlackDetectContext *s = ctx->priv; double picture_black_ratio = 0; +const int max = (1 << s->depth) - 1; +const int factor = (1 << (s->depth - 8)); +const int full = picref->color_range == AVCOL_RANGE_JPEG || + ff_fmt_is_in(picref->format, yuvj_formats); + +s->pixel_black_th_i = full ? s->pixel_black_th * max : +// luminance_minimum_value + pixel_black_th * luminance_range_size +16 * factor + s->pixel_black_th * (235 - 16) * factor; ff_filter_execute(ctx, black_counter, picref, NULL, FFMIN(inlink->h, s->nb_threads)); -- 2.38.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] AVX512 NUCs for FATE and development
I intend to buy this RAM: https://www.amazon.co.uk/Crucial-CT2K16G4SFRA32A-PC4-25600-SODIMM-260-Pin/dp/B08C4X9VR5 2x £529 for NUCs 2x £102.48 for RAM 2x £69 for M.2 NVMe SSD £1400 total. Kieran On Thu, 8 Dec 2022 at 21:30, Jean-Baptiste Kempf wrote: > > > On Thu, 8 Dec 2022, at 22:20, Ronald S. Bultje wrote: > > Hi, > > > > On Sun, Dec 4, 2022 at 1:08 PM Kieran Kunhya wrote: > > > >> Hello, > >> > >> As discussed at the developer meeting it would be good to have an > AVX-512 > >> (ICL) FATE machine and also a development machine. > >> What I didn't realise until a few weeks ago is that 11th Generation NUCs > >> have AVX512ICL support. > >> > >> I suggest buying: > >> > >> 2x > >> > >> > https://www.scan.co.uk/products/intel-nuc-bnuc11tnki7-rocket-lake-core-i7-1165g7-dual-ddr4-so-dimm-slots-intel-iris-xe-graphics > >> - £529 each > >> 2x 2x 16GB RAM - 32GB in each (price TBC as I want to buy the right one, > >> RAM can be confusing) > >> 2x M.2 NVMe SSDs - > >> > >> > https://www.amazon.co.uk/WD_BLACK-Internal-Gaming-Technology-speeds/dp/B08KFN1KT1 > >> > >> £1500 total I would estimate. > >> > >> I am happy to host these (as with the M1s) but as these are NUCs anyone > can > >> buy and host them easily. > >> > > > > +1 from me - AVX512-icelake is where a lot of x86 SIMD dev takes place in > > the next few years, and testing this new SIMD code in FATE is critical. > > +1 from me too. > > > -- > 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". > ___ 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] AVX512 NUCs for FATE and development
On Thu, 8 Dec 2022, at 22:20, Ronald S. Bultje wrote: > Hi, > > On Sun, Dec 4, 2022 at 1:08 PM Kieran Kunhya wrote: > >> Hello, >> >> As discussed at the developer meeting it would be good to have an AVX-512 >> (ICL) FATE machine and also a development machine. >> What I didn't realise until a few weeks ago is that 11th Generation NUCs >> have AVX512ICL support. >> >> I suggest buying: >> >> 2x >> >> https://www.scan.co.uk/products/intel-nuc-bnuc11tnki7-rocket-lake-core-i7-1165g7-dual-ddr4-so-dimm-slots-intel-iris-xe-graphics >> - £529 each >> 2x 2x 16GB RAM - 32GB in each (price TBC as I want to buy the right one, >> RAM can be confusing) >> 2x M.2 NVMe SSDs - >> >> https://www.amazon.co.uk/WD_BLACK-Internal-Gaming-Technology-speeds/dp/B08KFN1KT1 >> >> £1500 total I would estimate. >> >> I am happy to host these (as with the M1s) but as these are NUCs anyone can >> buy and host them easily. >> > > +1 from me - AVX512-icelake is where a lot of x86 SIMD dev takes place in > the next few years, and testing this new SIMD code in FATE is critical. +1 from me too. -- 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] AVX512 NUCs for FATE and development
Hi, On Sun, Dec 4, 2022 at 1:08 PM Kieran Kunhya wrote: > Hello, > > As discussed at the developer meeting it would be good to have an AVX-512 > (ICL) FATE machine and also a development machine. > What I didn't realise until a few weeks ago is that 11th Generation NUCs > have AVX512ICL support. > > I suggest buying: > > 2x > > https://www.scan.co.uk/products/intel-nuc-bnuc11tnki7-rocket-lake-core-i7-1165g7-dual-ddr4-so-dimm-slots-intel-iris-xe-graphics > - £529 each > 2x 2x 16GB RAM - 32GB in each (price TBC as I want to buy the right one, > RAM can be confusing) > 2x M.2 NVMe SSDs - > > https://www.amazon.co.uk/WD_BLACK-Internal-Gaming-Technology-speeds/dp/B08KFN1KT1 > > £1500 total I would estimate. > > I am happy to host these (as with the M1s) but as these are NUCs anyone can > buy and host them easily. > +1 from me - AVX512-icelake is where a lot of x86 SIMD dev takes place in the next few years, and testing this new SIMD code in FATE is critical. 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".
[FFmpeg-devel] [PATCH] avfilter: add minvar video filter
Patch attached.
TODO: documentation.
From 85063fe1d9f1fb33670068f7d3bb9038e22f2f75 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Wed, 7 Dec 2022 22:09:59 +0100
Subject: [PATCH] avfilter: add minvar video filter
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_minvar.c | 330 +++
3 files changed, 332 insertions(+)
create mode 100644 libavfilter/vf_minvar.c
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 9a850d5dc5..321bd9a0c8 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -377,6 +377,7 @@ OBJS-$(CONFIG_MESTIMATE_FILTER) += vf_mestimate.o motion_estimation
OBJS-$(CONFIG_METADATA_FILTER) += f_metadata.o
OBJS-$(CONFIG_MIDEQUALIZER_FILTER) += vf_midequalizer.o framesync.o
OBJS-$(CONFIG_MINTERPOLATE_FILTER) += vf_minterpolate.o motion_estimation.o
+OBJS-$(CONFIG_MINVAR_FILTER) += vf_minvar.o
OBJS-$(CONFIG_MIX_FILTER)+= vf_mix.o framesync.o
OBJS-$(CONFIG_MONOCHROME_FILTER) += vf_monochrome.o
OBJS-$(CONFIG_MORPHO_FILTER) += vf_morpho.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 2ece5c15c8..a29dff0bdf 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -355,6 +355,7 @@ extern const AVFilter ff_vf_mestimate;
extern const AVFilter ff_vf_metadata;
extern const AVFilter ff_vf_midequalizer;
extern const AVFilter ff_vf_minterpolate;
+extern const AVFilter ff_vf_minvar;
extern const AVFilter ff_vf_mix;
extern const AVFilter ff_vf_monochrome;
extern const AVFilter ff_vf_morpho;
diff --git a/libavfilter/vf_minvar.c b/libavfilter/vf_minvar.c
new file mode 100644
index 00..55ec98e133
--- /dev/null
+++ b/libavfilter/vf_minvar.c
@@ -0,0 +1,330 @@
+/*
+ * Copyright (c) 2022 Paul B Mahol
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct MinVarContext {
+const AVClass *class;
+
+double variance;
+int sizew;
+int sizeh;
+int planes;
+
+int depth;
+int max;
+int planewidth[4];
+int planeheight[4];
+
+uint64_t *ii[4];
+uint64_t *i2[4];
+ptrdiff_t i_linesize[4];
+size_t i_size[4];
+
+int nb_planes;
+
+void (*compute_sat)(const uint8_t *ssrc,
+int linesize,
+int w, int h,
+int max,
+uint64_t *ii,
+uint64_t *i2,
+int i_linesize);
+int (*filter)(AVFilterContext *ctx, void *arg,
+ int jobnr, int nb_jobs);
+} MinVarContext;
+
+#define OFFSET(x) offsetof(MinVarContext, x)
+#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_RUNTIME_PARAM
+
+static const AVOption minvar_options[] = {
+{ "var", "set global noise variance", OFFSET(variance), AV_OPT_TYPE_DOUBLE,{.dbl=0}, 0, 16, FLAGS },
+{ "rw", "set horizontal patch size", OFFSET(sizew),AV_OPT_TYPE_INT, {.i64=5}, 1, 16, FLAGS },
+{ "rh", "set vertical patch size", OFFSET(sizeh),AV_OPT_TYPE_INT, {.i64=5}, 1, 16, FLAGS },
+{ "planes", "set planes to filter", OFFSET(planes), AV_OPT_TYPE_INT, {.i64=7}, 0, 0xF, FLAGS },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(minvar);
+
+typedef struct ThreadData {
+AVFrame *in, *out;
+} ThreadData;
+
+static av_cold void uninit(AVFilterContext *ctx)
+{
+MinVarContext *s = ctx->priv;
+
+for (int p = 0; p < 4; p++) {
+av_freep(&s->ii[p]);
+av_freep(&s->i2[p]);
+}
+}
+
+#define COMPUTE_SAT(type, depth) \
+static void compute_sat##depth(const uint8_t *ssrc, \
+
[FFmpeg-devel] [PATCH] avcodec/libdav1d: honor the requested skip_frame level
This supports dropping non-intra, non-key, or all frames.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 51 +++
1 file changed, 32 insertions(+), 19 deletions(-)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index 028929404e..2f83a963e9 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -369,6 +369,37 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
return res;
}
+#if FF_DAV1D_VERSION_AT_LEAST(5,1)
+dav1d_get_event_flags(dav1d->c, &event_flags);
+if (c->pix_fmt == AV_PIX_FMT_NONE ||
+event_flags & DAV1D_EVENT_FLAG_NEW_SEQUENCE)
+#endif
+libdav1d_init_params(c, p->seq_hdr);
+if (c->width != p->p.w || c->height != p->p.h) {
+res = ff_set_dimensions(c, p->p.w, p->p.h);
+if (res < 0) {
+dav1d_picture_unref(p);
+return 0;
+}
+}
+
+av_reduce(&c->sample_aspect_ratio.num,
+ &c->sample_aspect_ratio.den,
+ p->p.h * (int64_t)p->frame_hdr->render_width,
+ p->p.w * (int64_t)p->frame_hdr->render_height,
+ INT_MAX);
+ff_set_sar(c, c->sample_aspect_ratio);
+
+if ((c->skip_frame >= AVDISCARD_NONINTRA &&
+(p->frame_hdr->frame_type != DAV1D_FRAME_TYPE_KEY &&
+ p->frame_hdr->frame_type != DAV1D_FRAME_TYPE_INTRA)) ||
+(c->skip_frame >= AVDISCARD_NONKEY &&
+ p->frame_hdr->frame_type != DAV1D_FRAME_TYPE_KEY) ||
+c->skip_frame >= AVDISCARD_ALL) {
+dav1d_picture_unref(p);
+return 0;
+}
+
av_assert0(p->data[0] && p->allocator_data);
// This requires the custom allocator above
@@ -385,30 +416,12 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
frame->linesize[1] = p->stride[1];
frame->linesize[2] = p->stride[1];
-#if FF_DAV1D_VERSION_AT_LEAST(5,1)
-dav1d_get_event_flags(dav1d->c, &event_flags);
-if (c->pix_fmt == AV_PIX_FMT_NONE ||
-event_flags & DAV1D_EVENT_FLAG_NEW_SEQUENCE)
-#endif
-libdav1d_init_params(c, p->seq_hdr);
res = ff_decode_frame_props(c, frame);
if (res < 0)
goto fail;
frame->width = p->p.w;
frame->height = p->p.h;
-if (c->width != p->p.w || c->height != p->p.h) {
-res = ff_set_dimensions(c, p->p.w, p->p.h);
-if (res < 0)
-goto fail;
-}
-
-av_reduce(&frame->sample_aspect_ratio.num,
- &frame->sample_aspect_ratio.den,
- frame->height * (int64_t)p->frame_hdr->render_width,
- frame->width * (int64_t)p->frame_hdr->render_height,
- INT_MAX);
-ff_set_sar(c, frame->sample_aspect_ratio);
if (p->m.user_data.data)
memcpy(&frame->reordered_opaque, p->m.user_data.data,
sizeof(frame->reordered_opaque));
@@ -595,7 +608,7 @@ const FFCodec ff_libdav1d_decoder = {
FF_CODEC_RECEIVE_FRAME_CB(libdav1d_receive_frame),
.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS,
.caps_internal = FF_CODEC_CAP_SETS_PKT_DTS |
- FF_CODEC_CAP_AUTO_THREADS,
+ FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM |
FF_CODEC_CAP_AUTO_THREADS,
.p.priv_class = &libdav1d_class,
.p.wrapper_name = "libdav1d",
};
--
2.38.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/vqcdec: Check width & 15
On Thu, Dec 08, 2022 at 06:32:40PM +1100, Peter Ross wrote: > On Sun, Nov 27, 2022 at 11:34:34PM +0100, Michael Niedermayer wrote: > > Various parts of the code assume that width can be divided by various > > powers of 2 > > without rounding > > > > Fixes: out of array access > > Fixes: > > 53623/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VQC_fuzzer-6209269924233216 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/vqcdec.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/libavcodec/vqcdec.c b/libavcodec/vqcdec.c > > index 18cd99462e..c3bce87974 100644 > > --- a/libavcodec/vqcdec.c > > +++ b/libavcodec/vqcdec.c > > @@ -71,6 +71,9 @@ static av_cold int vqc_decode_init(AVCodecContext * avctx) > > static AVOnce init_static_once = AV_ONCE_INIT; > > VqcContext *s = avctx->priv_data; > > > > +if (avctx->width & 15) > > +return AVERROR_PATCHWELCOME; > > + > > s->vectors = av_malloc((avctx->width * avctx->height * 3) / 2); > > if (!s->vectors) > > return AVERROR(ENOMEM); > > -- > > 2.17.1 > > ok. please apply. will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact 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/file: add fd protocol
On Thu, 2022-12-08 at 16:28 +0100, Andreas Rheinhardt wrote: > Marvin Scholz: > > > > On 8 Dec 2022, at 16:11, Zhao Zhili wrote: > > > > > On Mon, 2022-12-05 at 10:51 +0800, zhilizhao(赵志立) wrote: > > > > > On Nov 19, 2022, at 02:48, Zhao Zhili > > > > > > > > > > wrote: > > > > > > > > > > From: Zhao Zhili > > > > > > > > > > Unlike the pipe protocol, fd protocol has seek support if it > > > > > corresponding to a regular file. > > > > > --- > > > > > Sometimes it's the only way to access files via file > > > > > descriptor, > > > > > e.g., > > > > > requesting a shared file on Android: > > > > > https://developer.android.com/training/secure-file-sharing/request-file > > > > > > > > > > doc/protocols.texi | 24 +++ > > > > > libavformat/Makefile| 1 + > > > > > libavformat/file.c | 51 > > > > > + > > > > > libavformat/protocols.c | 1 + > > > > > libavformat/version.h | 4 ++-- > > > > > 5 files changed, 79 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > Ping for review. > > > > > > > > > > Will apply tomorrow unless there are objections. > > > > > > > Maybe I overlooked something but where does the CONFIG_FD_PROTOCOL > > define comes from? > > > > It is autogenerated by configure due to the entry in lavf/protocols.c > (and this change will trigger a request to rerun configure when > compiling). > (I haven't looked at the patch at all.) > > - Andreas Yes, it was automatically generated by configure and included in config_components. For the patch itself, make pipe protocol is easy, but it doesn't sound right (a seekable pipe). So I chose to add a new one, which is supported by VLC too (URl is little different). A quick test case for this patch is: $ ./ffplay fd:0 < ~/video/cctv.mp4 You can seek back and forth. ___ 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/mediacodecenc: add option to select codec by name
On Mon, 2022-11-28 at 00:55 +0800, Zhao Zhili wrote: > From: Zhao Zhili > > --- > libavcodec/mediacodecenc.c | 8 +++- > libavcodec/version.h | 2 +- > 2 files changed, 8 insertions(+), 2 deletions(-) > > Applied. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mediacodec: fix missing crop info when use NDK MediaCodec
On Thu, 2022-11-24 at 00:49 +0800, Zhao Zhili wrote: > From: Zhao Zhili > > --- > libavcodec/mediacodec_wrapper.c | 38 - > -- > libavcodec/mediacodec_wrapper.h | 24 +++ > libavcodec/mediacodecdec_common.c | 4 > 3 files changed, 63 insertions(+), 3 deletions(-) > > Applied. ___ 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/file: add fd protocol
Marvin Scholz: > > > On 8 Dec 2022, at 16:11, Zhao Zhili wrote: > >> On Mon, 2022-12-05 at 10:51 +0800, zhilizhao(赵志立) wrote: On Nov 19, 2022, at 02:48, Zhao Zhili wrote: From: Zhao Zhili Unlike the pipe protocol, fd protocol has seek support if it corresponding to a regular file. --- Sometimes it's the only way to access files via file descriptor, e.g., requesting a shared file on Android: https://developer.android.com/training/secure-file-sharing/request-file doc/protocols.texi | 24 +++ libavformat/Makefile| 1 + libavformat/file.c | 51 + libavformat/protocols.c | 1 + libavformat/version.h | 4 ++-- 5 files changed, 79 insertions(+), 2 deletions(-) >>> >>> Ping for review. >>> >> >> Will apply tomorrow unless there are objections. >> > > Maybe I overlooked something but where does the CONFIG_FD_PROTOCOL > define comes from? > It is autogenerated by configure due to the entry in lavf/protocols.c (and this change will trigger a request to rerun configure when compiling). (I haven't looked at the patch at all.) - 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] avformat/file: add fd protocol
On 8 Dec 2022, at 16:11, Zhao Zhili wrote: > On Mon, 2022-12-05 at 10:51 +0800, zhilizhao(赵志立) wrote: >>> On Nov 19, 2022, at 02:48, Zhao Zhili >>> wrote: >>> >>> From: Zhao Zhili >>> >>> Unlike the pipe protocol, fd protocol has seek support if it >>> corresponding to a regular file. >>> --- >>> Sometimes it's the only way to access files via file descriptor, >>> e.g., >>> requesting a shared file on Android: >>> https://developer.android.com/training/secure-file-sharing/request-file >>> >>> doc/protocols.texi | 24 +++ >>> libavformat/Makefile| 1 + >>> libavformat/file.c | 51 >>> + >>> libavformat/protocols.c | 1 + >>> libavformat/version.h | 4 ++-- >>> 5 files changed, 79 insertions(+), 2 deletions(-) >>> >>> >> >> Ping for review. >> > > Will apply tomorrow unless there are objections. > Maybe I overlooked something but where does the CONFIG_FD_PROTOCOL define comes from? > ___ > 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/file: add fd protocol
On Mon, 2022-12-05 at 10:51 +0800, zhilizhao(赵志立) wrote: > > On Nov 19, 2022, at 02:48, Zhao Zhili > > wrote: > > > > From: Zhao Zhili > > > > Unlike the pipe protocol, fd protocol has seek support if it > > corresponding to a regular file. > > --- > > Sometimes it's the only way to access files via file descriptor, > > e.g., > > requesting a shared file on Android: > > https://developer.android.com/training/secure-file-sharing/request-file > > > > doc/protocols.texi | 24 +++ > > libavformat/Makefile| 1 + > > libavformat/file.c | 51 > > + > > libavformat/protocols.c | 1 + > > libavformat/version.h | 4 ++-- > > 5 files changed, 79 insertions(+), 2 deletions(-) > > > > > > Ping for review. > Will apply tomorrow unless there are objections. ___ 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 5/5] avcodec/libdav1d: reindent after the previous commit
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index d9542dd6a0..2f151d2d1b 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -328,7 +328,7 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
if (c->reordered_opaque != AV_NOPTS_VALUE) {
pkt->opaque = av_memdup(&c->reordered_opaque,
-
sizeof(c->reordered_opaque));
+sizeof(c->reordered_opaque));
if (!pkt->opaque) {
av_packet_free(&pkt);
dav1d_data_unref(data);
@@ -336,19 +336,19 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
}
}
-res = dav1d_data_wrap_user_data(data, (const uint8_t *)pkt,
-libdav1d_user_data_free, pkt);
-if (res < 0) {
-av_free(pkt->opaque);
-av_packet_free(&pkt);
-dav1d_data_unref(data);
-return res;
-}
+res = dav1d_data_wrap_user_data(data, (const uint8_t *)pkt,
+libdav1d_user_data_free, pkt);
+if (res < 0) {
+av_free(pkt->opaque);
+av_packet_free(&pkt);
+dav1d_data_unref(data);
+return res;
+}
pkt = NULL;
} else {
av_packet_free(&pkt);
if (res >= 0)
-return AVERROR(EAGAIN);
+return AVERROR(EAGAIN);
}
}
--
2.38.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 4/5] avcodec/libdav1d: set frame props from the reordered packet
Attach the AVPacket instead of only a few values to the corresponding Dav1dData
struct and use it to set all output frame props.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 45 +++
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index f98f351e49..d9542dd6a0 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -286,8 +286,10 @@ static void libdav1d_data_free(const uint8_t *data, void
*opaque) {
}
static void libdav1d_user_data_free(const uint8_t *data, void *opaque) {
+AVPacket *pkt = opaque;
av_assert0(data == opaque);
-av_free(opaque);
+av_free(pkt->opaque);
+av_packet_free(&pkt);
}
static int libdav1d_receive_frame(AVCodecContext *c, AVFrame *frame)
@@ -295,13 +297,14 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
Libdav1dContext *dav1d = c->priv_data;
Dav1dData *data = &dav1d->data;
Dav1dPicture pic = { 0 }, *p = &pic;
+AVPacket *pkt;
#if FF_DAV1D_VERSION_AT_LEAST(5,1)
enum Dav1dEventFlags event_flags = 0;
#endif
int res;
if (!data->sz) {
-AVPacket *pkt = av_packet_alloc();
+pkt = av_packet_alloc();
if (!pkt)
return AVERROR(ENOMEM);
@@ -320,29 +323,28 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
return res;
}
-data->m.timestamp = pkt->pts;
-data->m.offset= pkt->pos;
-data->m.duration = pkt->duration;
-
pkt->buf = NULL;
-av_packet_free(&pkt);
+pkt->opaque = NULL;
if (c->reordered_opaque != AV_NOPTS_VALUE) {
-uint8_t *reordered_opaque = av_memdup(&c->reordered_opaque,
+pkt->opaque = av_memdup(&c->reordered_opaque,
sizeof(c->reordered_opaque));
-if (!reordered_opaque) {
+if (!pkt->opaque) {
+av_packet_free(&pkt);
dav1d_data_unref(data);
return AVERROR(ENOMEM);
}
+}
-res = dav1d_data_wrap_user_data(data, reordered_opaque,
-libdav1d_user_data_free,
reordered_opaque);
+res = dav1d_data_wrap_user_data(data, (const uint8_t *)pkt,
+libdav1d_user_data_free, pkt);
if (res < 0) {
-av_free(reordered_opaque);
+av_free(pkt->opaque);
+av_packet_free(&pkt);
dav1d_data_unref(data);
return res;
}
-}
+pkt = NULL;
} else {
av_packet_free(&pkt);
if (res >= 0)
@@ -411,17 +413,18 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
INT_MAX);
ff_set_sar(c, frame->sample_aspect_ratio);
-if (p->m.user_data.data)
-memcpy(&frame->reordered_opaque, p->m.user_data.data,
sizeof(frame->reordered_opaque));
+pkt = (AVPacket *)p->m.user_data.data;
+if (pkt->opaque)
+memcpy(&frame->reordered_opaque, pkt->opaque,
sizeof(frame->reordered_opaque));
else
frame->reordered_opaque = AV_NOPTS_VALUE;
// match timestamps and packet size
-frame->pts = p->m.timestamp;
-frame->pkt_dts = p->m.timestamp;
-frame->pkt_pos = p->m.offset;
-frame->pkt_size = p->m.size;
-frame->duration = p->m.duration;
+res = ff_decode_frame_props_from_pkt(frame, pkt);
+if (res < 0)
+goto fail;
+
+frame->pkt_dts = pkt->pts;
frame->key_frame = p->frame_hdr->frame_type == DAV1D_FRAME_TYPE_KEY;
switch (p->frame_hdr->frame_type) {
@@ -595,7 +598,7 @@ const FFCodec ff_libdav1d_decoder = {
.flush = libdav1d_flush,
FF_CODEC_RECEIVE_FRAME_CB(libdav1d_receive_frame),
.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS,
-.caps_internal = FF_CODEC_CAP_SETS_PKT_DTS |
+.caps_internal = FF_CODEC_CAP_SETS_PKT_DTS |
FF_CODEC_CAP_SETS_FRAME_PROPS |
FF_CODEC_CAP_AUTO_THREADS,
.p.priv_class = &libdav1d_class,
.p.wrapper_name = "libdav1d",
--
2.38.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/5] avcodec/libdav1d: don't use AVCodecInternal.in_pkt
Allocate an AVPacket instead, which will be used in the following commit.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index 028929404e..f98f351e49 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -41,9 +41,6 @@
typedef struct Libdav1dContext {
AVClass *class;
Dav1dContext *c;
-/* This packet coincides with AVCodecInternal.in_pkt
- * and is not owned by us. */
-AVPacket *pkt;
AVBufferPool *pool;
int pool_size;
@@ -219,8 +216,6 @@ static av_cold int libdav1d_init(AVCodecContext *c)
#endif
int res;
-dav1d->pkt = c->internal->in_pkt;
-
av_log(c, AV_LOG_INFO, "libdav1d %s\n", dav1d_version());
dav1d_default_settings(&s);
@@ -306,17 +301,22 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
int res;
if (!data->sz) {
-AVPacket *const pkt = dav1d->pkt;
+AVPacket *pkt = av_packet_alloc();
+
+if (!pkt)
+return AVERROR(ENOMEM);
res = ff_decode_get_packet(c, pkt);
-if (res < 0 && res != AVERROR_EOF)
+if (res < 0 && res != AVERROR_EOF) {
+av_packet_free(&pkt);
return res;
+}
if (pkt->size) {
res = dav1d_data_wrap(data, pkt->data, pkt->size,
libdav1d_data_free, pkt->buf);
if (res < 0) {
-av_packet_unref(pkt);
+av_packet_free(&pkt);
return res;
}
@@ -325,7 +325,7 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
data->m.duration = pkt->duration;
pkt->buf = NULL;
-av_packet_unref(pkt);
+av_packet_free(&pkt);
if (c->reordered_opaque != AV_NOPTS_VALUE) {
uint8_t *reordered_opaque = av_memdup(&c->reordered_opaque,
@@ -343,8 +343,9 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
return res;
}
}
-} else if (res >= 0) {
-av_packet_unref(pkt);
+} else {
+av_packet_free(&pkt);
+if (res >= 0)
return AVERROR(EAGAIN);
}
}
--
2.38.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/5] avcodec/decode: reindent after the previous commit
Signed-off-by: James Almer
---
libavcodec/decode.c | 46 ++---
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 8f7f0fadbe..3e5be501b9 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1280,31 +1280,31 @@ int ff_decode_frame_props_from_pkt(AVFrame *frame,
const AVPacket *pkt)
{ AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
};
-frame->pts = pkt->pts;
-frame->pkt_pos = pkt->pos;
-frame->duration = pkt->duration;
-frame->pkt_size = pkt->size;
-
-for (int i = 0; i < FF_ARRAY_ELEMS(sd); i++) {
-size_t size;
-uint8_t *packet_sd = av_packet_get_side_data(pkt, sd[i].packet,
&size);
-if (packet_sd) {
-AVFrameSideData *frame_sd = av_frame_new_side_data(frame,
- sd[i].frame,
- size);
-if (!frame_sd)
-return AVERROR(ENOMEM);
-
-memcpy(frame_sd->data, packet_sd, size);
-}
+frame->pts = pkt->pts;
+frame->pkt_pos = pkt->pos;
+frame->duration = pkt->duration;
+frame->pkt_size = pkt->size;
+
+for (int i = 0; i < FF_ARRAY_ELEMS(sd); i++) {
+size_t size;
+uint8_t *packet_sd = av_packet_get_side_data(pkt, sd[i].packet, &size);
+if (packet_sd) {
+AVFrameSideData *frame_sd = av_frame_new_side_data(frame,
+ sd[i].frame,
+ size);
+if (!frame_sd)
+return AVERROR(ENOMEM);
+
+memcpy(frame_sd->data, packet_sd, size);
}
-add_metadata_from_side_data(pkt, frame);
+}
+add_metadata_from_side_data(pkt, frame);
-if (pkt->flags & AV_PKT_FLAG_DISCARD) {
-frame->flags |= AV_FRAME_FLAG_DISCARD;
-} else {
-frame->flags = (frame->flags & ~AV_FRAME_FLAG_DISCARD);
-}
+if (pkt->flags & AV_PKT_FLAG_DISCARD) {
+frame->flags |= AV_FRAME_FLAG_DISCARD;
+} else {
+frame->flags = (frame->flags & ~AV_FRAME_FLAG_DISCARD);
+}
return 0;
}
--
2.38.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/5] avcodec/decode: add a function to set frame props from a user provided packet
It will be useful for decoders that don't rely on last_pkt_props to set frame
props.
Signed-off-by: James Almer
---
libavcodec/decode.c | 19 +++
libavcodec/decode.h | 5 +
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index b184c3f55b..8f7f0fadbe 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1261,9 +1261,8 @@ static int add_metadata_from_side_data(const AVPacket
*avpkt, AVFrame *frame)
return av_packet_unpack_dictionary(side_metadata, size, frame_md);
}
-int ff_decode_frame_props(AVCodecContext *avctx, AVFrame *frame)
+int ff_decode_frame_props_from_pkt(AVFrame *frame, const AVPacket *pkt)
{
-const AVPacket *pkt = avctx->internal->last_pkt_props;
static const struct {
enum AVPacketSideDataType packet;
enum AVFrameSideDataType frame;
@@ -1281,11 +1280,10 @@ int ff_decode_frame_props(AVCodecContext *avctx,
AVFrame *frame)
{ AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
};
-if (!(ffcodec(avctx->codec)->caps_internal &
FF_CODEC_CAP_SETS_FRAME_PROPS)) {
frame->pts = pkt->pts;
frame->pkt_pos = pkt->pos;
frame->duration = pkt->duration;
-frame->pkt_size = (int)(intptr_t)pkt->opaque;
+frame->pkt_size = pkt->size;
for (int i = 0; i < FF_ARRAY_ELEMS(sd); i++) {
size_t size;
@@ -1307,6 +1305,19 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame
*frame)
} else {
frame->flags = (frame->flags & ~AV_FRAME_FLAG_DISCARD);
}
+
+return 0;
+}
+
+int ff_decode_frame_props(AVCodecContext *avctx, AVFrame *frame)
+{
+const AVPacket *pkt = avctx->internal->last_pkt_props;
+
+if (!(ffcodec(avctx->codec)->caps_internal &
FF_CODEC_CAP_SETS_FRAME_PROPS)) {
+int ret = ff_decode_frame_props_from_pkt(frame, pkt);
+if (ret < 0)
+return ret;
+frame->pkt_size = (int)(intptr_t)pkt->opaque;
}
frame->reordered_opaque = avctx->reordered_opaque;
diff --git a/libavcodec/decode.h b/libavcodec/decode.h
index 5d95369b5e..906122b4a7 100644
--- a/libavcodec/decode.h
+++ b/libavcodec/decode.h
@@ -69,6 +69,11 @@ int ff_decode_receive_frame(AVCodecContext *avctx, AVFrame
*frame);
*/
int ff_decode_get_packet(AVCodecContext *avctx, AVPacket *pkt);
+/**
+ * Set various frame properties from the provided packet.
+ */
+int ff_decode_frame_props_from_pkt(AVFrame *frame, const AVPacket *pkt);
+
/**
* Set various frame properties from the codec context / packet data.
*/
--
2.38.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".
