Re: [FFmpeg-devel] [PATCH v2] avcodec/mediacodecdec: call MediaCodec.stop on close
On Fri, Aug 9, 2024 at 11:08 AM sfan5 wrote: > > revised commit message as suggested Patch 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] [RFC] 7.1 Release
On Sat, Aug 17, 2024 at 5:38 AM Marth64 wrote: > > I would like to get DVD seeking in and some recent bugfixes (initial > patchset was sent, working on revision). I'm chasing one last > lingering issue with chapter-based extraction. > Hopefully, I can make a breakthrough or get help to fix it soon. > Beyond that I plan to leave DVD alone for a long time. > > On Wed, Aug 14, 2024 at 9:52 AM Lynne via ffmpeg-devel > wrote: > > > > On 14/08/2024 14:41, Michael Niedermayer wrote: > > > Hi all > > > > > > Are there any upcoming LTS releases that want to/could include FFmpeg 7.1 > > > ? > > > If so please reply here and list the date before which we would have to > > > finish the 7.1 release so it can be included with no problems > > > > > > Otherwise, are there any preferrances of the general/approximate release > > > date? > > > > > > thx > > > > > > > > > ___ > > > 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". > > > > I'd like to have Vulkan encoding support merged before 7.1 is branched. > > Working on the patches ATM, merging them one by one. > > > > The first week of September seems like a nice target for a release, > > which would mean we'd need to branch at the end of this month. Hi, I would like the mediacodec audio support merged before 7.1 is branched. I will have time to work on it start of next week and submit a v2 of the original 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".
Re: [FFmpeg-devel] [PATCH 36/39] lavc: add private container FIFO API
Quoting Anton Khirnov (2024-08-16 10:44:42) > ping Will push the rest of this set in a couple days unless there are further comments. -- Anton Khirnov ___ 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/8] lavfi: move ff_parse_pixel_format() to vf_format, its only caller
The only thing this function does beyond calling av_get_pix_fmt() is
falling back onto parsing the argument as a number. No other filters
should need to do this.
---
libavfilter/formats.c | 15 ---
libavfilter/internal.h | 11 ---
libavfilter/vf_format.c | 17 -
3 files changed, 16 insertions(+), 27 deletions(-)
diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index 15099ac545..18f7b89104 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -939,21 +939,6 @@ int ff_default_query_formats(AVFilterContext *ctx)
/* internal functions for parsing audio format arguments */
-int ff_parse_pixel_format(enum AVPixelFormat *ret, const char *arg, void
*log_ctx)
-{
-char *tail;
-int pix_fmt = av_get_pix_fmt(arg);
-if (pix_fmt == AV_PIX_FMT_NONE) {
-pix_fmt = strtol(arg, &tail, 0);
-if (*tail || !av_pix_fmt_desc_get(pix_fmt)) {
-av_log(log_ctx, AV_LOG_ERROR, "Invalid pixel format '%s'\n", arg);
-return AVERROR(EINVAL);
-}
-}
-*ret = pix_fmt;
-return 0;
-}
-
int ff_parse_sample_rate(int *ret, const char *arg, void *log_ctx)
{
char *tail;
diff --git a/libavfilter/internal.h b/libavfilter/internal.h
index 4938612593..343bc0b330 100644
--- a/libavfilter/internal.h
+++ b/libavfilter/internal.h
@@ -35,17 +35,6 @@ int ff_fmt_is_regular_yuv(enum AVPixelFormat fmt);
/* Functions to parse audio format arguments */
-/**
- * Parse a pixel format.
- *
- * @param ret pixel format pointer to where the value should be written
- * @param arg string to parse
- * @param log_ctx log context
- * @return >= 0 in case of success, a negative AVERROR code on error
- */
-av_warn_unused_result
-int ff_parse_pixel_format(enum AVPixelFormat *ret, const char *arg, void
*log_ctx);
-
/**
* Parse a sample rate.
*
diff --git a/libavfilter/vf_format.c b/libavfilter/vf_format.c
index 2b88b10f65..83deff7190 100644
--- a/libavfilter/vf_format.c
+++ b/libavfilter/vf_format.c
@@ -86,6 +86,21 @@ static av_cold int invert_formats(AVFilterFormats **fmts,
return 0;
}
+static int parse_pixel_format(enum AVPixelFormat *ret, const char *arg, void
*log_ctx)
+{
+char *tail;
+int pix_fmt = av_get_pix_fmt(arg);
+if (pix_fmt == AV_PIX_FMT_NONE) {
+pix_fmt = strtol(arg, &tail, 0);
+if (*tail || !av_pix_fmt_desc_get(pix_fmt)) {
+av_log(log_ctx, AV_LOG_ERROR, "Invalid pixel format '%s'\n", arg);
+return AVERROR(EINVAL);
+}
+}
+*ret = pix_fmt;
+return 0;
+}
+
static av_cold int init(AVFilterContext *ctx)
{
FormatContext *s = ctx->priv;
@@ -96,7 +111,7 @@ static av_cold int init(AVFilterContext *ctx)
sep = strchr(cur, '|');
if (sep && *sep)
*sep++ = 0;
-if ((ret = ff_parse_pixel_format(&pix_fmt, cur, ctx)) < 0 ||
+if ((ret = parse_pixel_format(&pix_fmt, cur, ctx)) < 0 ||
(ret = ff_add_format(&s->formats, pix_fmt)) < 0)
return ret;
}
--
2.43.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 4/8] lavfi/inernal: move ff_fmt_is_regular_yuv() declaration to video.h
---
libavfilter/avfiltergraph.c | 1 +
libavfilter/buffersrc.c | 1 +
libavfilter/internal.h | 6 --
libavfilter/video.h | 6 ++
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
index 0da2f8462b..6317f8d457 100644
--- a/libavfilter/avfiltergraph.c
+++ b/libavfilter/avfiltergraph.c
@@ -40,6 +40,7 @@
#include "formats.h"
#include "framequeue.h"
#include "internal.h"
+#include "video.h"
#define OFFSET(x) offsetof(AVFilterGraph, x)
#define F AV_OPT_FLAG_FILTERING_PARAM
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index 2743493d5d..1cf23fe37b 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -39,6 +39,7 @@
#include "filters.h"
#include "formats.h"
#include "internal.h"
+#include "video.h"
typedef struct BufferSourceContext {
const AVClass*class;
diff --git a/libavfilter/internal.h b/libavfilter/internal.h
index eb312ab485..6a0b9ed7e1 100644
--- a/libavfilter/internal.h
+++ b/libavfilter/internal.h
@@ -27,12 +27,6 @@
#include "libavutil/internal.h"
#include "avfilter.h"
-/**
- * Returns true if a pixel format is "regular YUV", which includes all pixel
- * formats that are affected by YUV colorspace negotiation.
- */
-int ff_fmt_is_regular_yuv(enum AVPixelFormat fmt);
-
/**
* Negotiate the media format, dimensions, etc of all inputs to a filter.
*
diff --git a/libavfilter/video.h b/libavfilter/video.h
index 8c5f6c84e7..77f27fdf7c 100644
--- a/libavfilter/video.h
+++ b/libavfilter/video.h
@@ -45,4 +45,10 @@ AVFrame *ff_null_get_video_buffer(AVFilterLink *link, int w,
int h);
*/
AVFrame *ff_get_video_buffer(AVFilterLink *link, int w, int h);
+/**
+ * Returns true if a pixel format is "regular YUV", which includes all pixel
+ * formats that are affected by YUV colorspace negotiation.
+ */
+int ff_fmt_is_regular_yuv(enum AVPixelFormat fmt);
+
#endif /* AVFILTER_VIDEO_H */
--
2.43.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 5/8] lavfi/f_streamselect: remove a no-op ff_filter_config_links() call
It does not do anything when the links are already configured. --- libavfilter/f_streamselect.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/f_streamselect.c b/libavfilter/f_streamselect.c index 07d55a7506..ecdcc7f269 100644 --- a/libavfilter/f_streamselect.c +++ b/libavfilter/f_streamselect.c @@ -249,7 +249,7 @@ static int process_command(AVFilterContext *ctx, const char *cmd, const char *ar if (ret < 0) return ret; -return ff_filter_config_links(ctx); +return 0; } return AVERROR(ENOSYS); } -- 2.43.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/8] lavfi: move ff_parse_{sample_rate, channel_layout}() to audio.[ch]
That is a more appropriate place for those functions.
---
libavfilter/audio.c | 36 +++
libavfilter/audio.h | 25
libavfilter/formats.c | 38 -
libavfilter/internal.h | 27 --
libavfilter/tests/formats.c | 1 +
5 files changed, 62 insertions(+), 65 deletions(-)
diff --git a/libavfilter/audio.c b/libavfilter/audio.c
index 1768b31184..11b3d0c9c3 100644
--- a/libavfilter/audio.c
+++ b/libavfilter/audio.c
@@ -23,6 +23,7 @@
#include "libavutil/channel_layout.h"
#include "libavutil/common.h"
#include "libavutil/cpu.h"
+#include "libavutil/eval.h"
#include "audio.h"
#include "avfilter.h"
@@ -107,3 +108,38 @@ AVFrame *ff_get_audio_buffer(AVFilterLink *link, int
nb_samples)
return ret;
}
+
+int ff_parse_sample_rate(int *ret, const char *arg, void *log_ctx)
+{
+char *tail;
+double srate = av_strtod(arg, &tail);
+if (*tail || srate < 1 || (int)srate != srate || srate > INT_MAX) {
+av_log(log_ctx, AV_LOG_ERROR, "Invalid sample rate '%s'\n", arg);
+return AVERROR(EINVAL);
+}
+*ret = srate;
+return 0;
+}
+
+int ff_parse_channel_layout(AVChannelLayout *ret, int *nret, const char *arg,
+void *log_ctx)
+{
+AVChannelLayout chlayout = { 0 };
+int res;
+
+res = av_channel_layout_from_string(&chlayout, arg);
+if (res < 0) {
+av_log(log_ctx, AV_LOG_ERROR, "Invalid channel layout '%s'\n", arg);
+return AVERROR(EINVAL);
+}
+
+if (chlayout.order == AV_CHANNEL_ORDER_UNSPEC && !nret) {
+av_log(log_ctx, AV_LOG_ERROR, "Unknown channel layout '%s' is not
supported.\n", arg);
+return AVERROR(EINVAL);
+}
+*ret = chlayout;
+if (nret)
+*nret = chlayout.nb_channels;
+
+return 0;
+}
diff --git a/libavfilter/audio.h b/libavfilter/audio.h
index aab80baa50..881df0cf87 100644
--- a/libavfilter/audio.h
+++ b/libavfilter/audio.h
@@ -47,4 +47,29 @@ AVFrame *ff_null_get_audio_buffer(AVFilterLink *link, int
nb_samples);
*/
AVFrame *ff_get_audio_buffer(AVFilterLink *link, int nb_samples);
+/**
+ * Parse a sample rate.
+ *
+ * @param ret unsigned integer pointer to where the value should be written
+ * @param arg string to parse
+ * @param log_ctx log context
+ * @return >= 0 in case of success, a negative AVERROR code on error
+ */
+av_warn_unused_result
+int ff_parse_sample_rate(int *ret, const char *arg, void *log_ctx);
+
+/**
+ * Parse a channel layout or a corresponding integer representation.
+ *
+ * @param ret 64bit integer pointer to where the value should be written.
+ * @param nret integer pointer to the number of channels;
+ * if not NULL, then unknown channel layouts are accepted
+ * @param arg string to parse
+ * @param log_ctx log context
+ * @return >= 0 in case of success, a negative AVERROR code on error
+ */
+av_warn_unused_result
+int ff_parse_channel_layout(AVChannelLayout *ret, int *nret, const char *arg,
+void *log_ctx);
+
#endif /* AVFILTER_AUDIO_H */
diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index 18f7b89104..cd7c68f592 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -22,7 +22,6 @@
#include "libavutil/avassert.h"
#include "libavutil/channel_layout.h"
#include "libavutil/common.h"
-#include "libavutil/eval.h"
#include "libavutil/mem.h"
#include "libavutil/pixdesc.h"
#include "avfilter.h"
@@ -937,43 +936,6 @@ int ff_default_query_formats(AVFilterContext *ctx)
return 0;
}
-/* internal functions for parsing audio format arguments */
-
-int ff_parse_sample_rate(int *ret, const char *arg, void *log_ctx)
-{
-char *tail;
-double srate = av_strtod(arg, &tail);
-if (*tail || srate < 1 || (int)srate != srate || srate > INT_MAX) {
-av_log(log_ctx, AV_LOG_ERROR, "Invalid sample rate '%s'\n", arg);
-return AVERROR(EINVAL);
-}
-*ret = srate;
-return 0;
-}
-
-int ff_parse_channel_layout(AVChannelLayout *ret, int *nret, const char *arg,
-void *log_ctx)
-{
-AVChannelLayout chlayout = { 0 };
-int res;
-
-res = av_channel_layout_from_string(&chlayout, arg);
-if (res < 0) {
-av_log(log_ctx, AV_LOG_ERROR, "Invalid channel layout '%s'\n", arg);
-return AVERROR(EINVAL);
-}
-
-if (chlayout.order == AV_CHANNEL_ORDER_UNSPEC && !nret) {
-av_log(log_ctx, AV_LOG_ERROR, "Unknown channel layout '%s' is not
supported.\n", arg);
-return AVERROR(EINVAL);
-}
-*ret = chlayout;
-if (nret)
-*nret = chlayout.nb_channels;
-
-return 0;
-}
-
static int check_list(void *log, const char *name, const AVFilterFormats *fmts)
{
unsigned i, j;
diff --git a/libavfilter/internal.h b/libavfilter/internal.h
index 343bc0b330..eb312ab485 100644
--- a/libavfilter/internal.h
+++ b/libavfilter/internal.h
@@ -33,33 +33,6 @@
*/
int
[FFmpeg-devel] [PATCH 1/8] lavfi/internal: move functions used by filters to filters.h
internal.h currently mixes interfaces intended to be used by filters with those that should be limited to generic filter- or graph-level code. --- libavfilter/af_acontrast.c | 1 + libavfilter/af_acopy.c | 1 + libavfilter/af_acrusher.c | 1 + libavfilter/af_adecorrelate.c | 1 + libavfilter/af_adenorm.c| 1 + libavfilter/af_aderivative.c| 1 + libavfilter/af_adynamicequalizer.c | 1 + libavfilter/af_adynamicsmooth.c | 1 + libavfilter/af_aemphasis.c | 1 + libavfilter/af_aexciter.c | 1 + libavfilter/af_aformat.c| 1 + libavfilter/af_afreqshift.c | 1 + libavfilter/af_alimiter.c | 1 + libavfilter/af_anequalizer.c| 1 + libavfilter/af_anull.c | 1 + libavfilter/af_aphaser.c| 1 + libavfilter/af_apulsator.c | 1 + libavfilter/af_asetrate.c | 1 + libavfilter/af_asoftclip.c | 1 + libavfilter/af_asr.c| 1 + libavfilter/af_astats.c | 1 + libavfilter/af_asubboost.c | 1 + libavfilter/af_asupercut.c | 1 + libavfilter/af_atempo.c | 1 + libavfilter/af_atilt.c | 1 + libavfilter/af_bs2b.c | 1 + libavfilter/af_channelmap.c | 1 + libavfilter/af_chorus.c | 1 + libavfilter/af_compand.c| 1 + libavfilter/af_compensationdelay.c | 1 + libavfilter/af_crystalizer.c| 1 + libavfilter/af_dcshift.c| 1 + libavfilter/af_deesser.c| 1 + libavfilter/af_drmeter.c| 1 + libavfilter/af_earwax.c | 1 + libavfilter/af_extrastereo.c| 1 + libavfilter/af_flanger.c| 1 + libavfilter/af_haas.c | 1 + libavfilter/af_hdcd.c | 1 + libavfilter/af_ladspa.c | 1 + libavfilter/af_mcompand.c | 1 + libavfilter/af_pan.c| 1 + libavfilter/af_silencedetect.c | 1 + libavfilter/af_stereotools.c| 1 + libavfilter/af_stereowiden.c| 1 + libavfilter/af_tremolo.c| 1 + libavfilter/af_vibrato.c| 1 + libavfilter/af_volumedetect.c | 1 + libavfilter/asink_anullsink.c | 1 + libavfilter/audio.c | 1 + libavfilter/audio.h | 2 +- libavfilter/avfiltergraph.c | 1 + libavfilter/dnn/dnn_interface.c | 2 + libavfilter/f_bench.c | 1 + libavfilter/f_realtime.c| 1 + libavfilter/f_reverse.c | 1 + libavfilter/f_sidedata.c| 1 + libavfilter/f_zmq.c | 1 + libavfilter/filters.h | 292 libavfilter/formats.c | 1 + libavfilter/graphdump.c | 1 + libavfilter/graphparser.c | 1 + libavfilter/internal.h | 292 libavfilter/vf_addroi.c | 1 + libavfilter/vf_amplify.c| 1 + libavfilter/vf_aspect.c | 1 + libavfilter/vf_atadenoise.c | 1 + libavfilter/vf_avgblur.c| 1 + libavfilter/vf_avgblur_opencl.c | 1 + libavfilter/vf_avgblur_vulkan.c | 2 + libavfilter/vf_backgroundkey.c | 1 + libavfilter/vf_bilateral.c | 1 + libavfilter/vf_bitplanenoise.c | 1 + libavfilter/vf_blackframe.c | 1 + libavfilter/vf_boxblur.c| 1 + libavfilter/vf_bwdif.c | 1 + libavfilter/vf_cas.c| 1 + libavfilter/vf_chromaber_vulkan.c | 2 + libavfilter/vf_chromakey.c | 1 + libavfilter/vf_chromanr.c | 1 + libavfilter/vf_chromashift.c| 1 + libavfilter/vf_ciescope.c | 1 + libavfilter/vf_codecview.c | 1 + libavfilter/vf_colorbalance.c | 1 + libavfilter/vf_colorchannelmixer.c | 1 + libavfilter/vf_colorconstancy.c | 1 + libavfilter/vf_colorcontrast.c | 1 + libavfilter/vf_colorcorrect.c | 1 + libavfilter/vf_colorize.c | 1 + libavfilter/vf_colorkey.c | 1 + libavfilter/vf_colorkey_opencl.c| 1 + libavfilter/vf_colorlevels.c| 1 + libavfilter/vf_colormatrix.c| 1 + libavfilter/vf_colorspace.c | 1 + libavfilter/vf_colortemperature.c | 1 + libavfilter/vf_convolution.c| 1 + libavfilter/vf_convolution_opencl.c | 1 + libavfilter/vf_copy.c | 1 + libavfilter/vf_cropdetect.c | 1 + libavfilter/vf_curves.c | 1 + libavfilter/vf_dblur.c | 1 + libavfilter/vf_dctdnoiz.c | 2 + libavfilter/vf_deband.c | 1 + libavfilter/vf_deblock.c| 1 + libavfilter/vf_deflicker.c | 1 + libavfilter/vf_derain.c | 1 + libavfilter/vf_deshake.c
[FFmpeg-devel] [PATCH 8/8] lavfi: make FFFilterContext private to generic code
Nothing in it needs to be visible to filters.
---
libavfilter/avfilter.c | 6 ++
libavfilter/avfilter_internal.h | 18 ++
libavfilter/filters.h | 25 ++---
3 files changed, 26 insertions(+), 23 deletions(-)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index c89a7ab508..8a2a9e0593 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -1647,3 +1647,9 @@ int ff_outlink_frame_wanted(AVFilterLink *link)
FilterLinkInternal * const li = ff_link_internal(link);
return li->frame_wanted_out;
}
+
+int ff_filter_execute(AVFilterContext *ctx, avfilter_action_func *func,
+ void *arg, int *ret, int nb_jobs)
+{
+return fffilterctx(ctx)->execute(ctx, func, arg, ret, nb_jobs);
+}
diff --git a/libavfilter/avfilter_internal.h b/libavfilter/avfilter_internal.h
index 8386183745..ec3933b1d1 100644
--- a/libavfilter/avfilter_internal.h
+++ b/libavfilter/avfilter_internal.h
@@ -92,6 +92,24 @@ static inline FilterLinkInternal
*ff_link_internal(AVFilterLink *link)
return (FilterLinkInternal*)link;
}
+typedef struct FFFilterContext {
+/**
+ * The public AVFilterContext. See avfilter.h for it.
+ */
+AVFilterContext p;
+
+avfilter_execute_func *execute;
+
+// 1 when avfilter_init_*() was successfully called on this filter
+// 0 otherwise
+int initialized;
+} FFFilterContext;
+
+static inline FFFilterContext *fffilterctx(AVFilterContext *ctx)
+{
+return (FFFilterContext*)ctx;
+}
+
typedef struct AVFilterCommand {
double time;///< time expressed in seconds
char *command; ///< command
diff --git a/libavfilter/filters.h b/libavfilter/filters.h
index 636753b26a..0053ad4303 100644
--- a/libavfilter/filters.h
+++ b/libavfilter/filters.h
@@ -199,24 +199,6 @@ static inline FilterLink* ff_filter_link(AVFilterLink
*link)
return (FilterLink*)link;
}
-typedef struct FFFilterContext {
-/**
- * The public AVFilterContext. See avfilter.h for it.
- */
-AVFilterContext p;
-
-avfilter_execute_func *execute;
-
-// 1 when avfilter_init_*() was successfully called on this filter
-// 0 otherwise
-int initialized;
-} FFFilterContext;
-
-static inline FFFilterContext *fffilterctx(AVFilterContext *ctx)
-{
-return (FFFilterContext*)ctx;
-}
-
/**
* The filter is aware of hardware frames, and any hardware frame context
* should not be automatically propagated through it.
@@ -614,10 +596,7 @@ int ff_append_outpad_free_name(AVFilterContext *f,
AVFilterPad *p);
*/
int ff_fmt_is_in(int fmt, const int *fmts);
-static av_always_inline int ff_filter_execute(AVFilterContext *ctx,
avfilter_action_func *func,
- void *arg, int *ret, int nb_jobs)
-{
-return fffilterctx(ctx)->execute(ctx, func, arg, ret, nb_jobs);
-}
+int ff_filter_execute(AVFilterContext *ctx, avfilter_action_func *func,
+ void *arg, int *ret, int nb_jobs);
#endif /* AVFILTER_FILTERS_H */
--
2.43.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 7/8] lavfi/filters: move functions only used by generic code to avfilter_internal.h
---
libavfilter/avfilter_internal.h | 15 +++
libavfilter/filters.h | 15 ---
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/libavfilter/avfilter_internal.h b/libavfilter/avfilter_internal.h
index 3b8d6fe60e..8386183745 100644
--- a/libavfilter/avfilter_internal.h
+++ b/libavfilter/avfilter_internal.h
@@ -184,4 +184,19 @@ void ff_tlog_link(void *ctx, AVFilterLink *link, int end);
*/
int ff_filter_graph_run_once(AVFilterGraph *graph);
+/**
+ * Process the commands queued in the link up to the time of the frame.
+ * Commands will trigger the process_command() callback.
+ * @return >= 0 or AVERROR code.
+ */
+int ff_inlink_process_commands(AVFilterLink *link, const AVFrame *frame);
+
+/**
+ * Evaluate the timeline expression of the link for the time and properties
+ * of the frame.
+ * @return >0 if enabled, 0 if disabled
+ * @note It does not update link->dst->is_disabled.
+ */
+int ff_inlink_evaluate_timeline_at_frame(AVFilterLink *link, const AVFrame
*frame);
+
#endif /* AVFILTER_AVFILTER_INTERNAL_H */
diff --git a/libavfilter/filters.h b/libavfilter/filters.h
index 4e763a94c0..636753b26a 100644
--- a/libavfilter/filters.h
+++ b/libavfilter/filters.h
@@ -303,21 +303,6 @@ enum FilterFormatsState {
*/
void ff_filter_set_ready(AVFilterContext *filter, unsigned priority);
-/**
- * Process the commands queued in the link up to the time of the frame.
- * Commands will trigger the process_command() callback.
- * @return >= 0 or AVERROR code.
- */
-int ff_inlink_process_commands(AVFilterLink *link, const AVFrame *frame);
-
-/**
- * Evaluate the timeline expression of the link for the time and properties
- * of the frame.
- * @return >0 if enabled, 0 if disabled
- * @note It does not update link->dst->is_disabled.
- */
-int ff_inlink_evaluate_timeline_at_frame(AVFilterLink *link, const AVFrame
*frame);
-
/**
* Get the number of frames available on the link.
* @return the number of frames available in the link fifo.
--
2.43.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] Check codec_whitelist before reinitializing AVCtx.priv_data.
Quoting Dale Curtis (2024-07-31 23:10:24) > On Wed, Jul 31, 2024 at 4:32 AM Anton Khirnov wrote: > > > Quoting Dale Curtis (2024-07-31 01:14:13) > > > I realized there are a couple more allocations that can be skipped here > > > when a codec is not on the allow list. Here's the updated patch. > > > > > > - dale > > > > > > On Mon, Jul 29, 2024 at 10:19 AM Dale Curtis > > > wrote: > > > > > > > This ensures that if a codec isn't on codec_whitelist, its VUI > > > > information can still be populated during find_stream_info() > > > > via parsers. > > > > > > > > Signed-off-by: Dale Curtis > > > > --- > > > > libavcodec/avcodec.c | 12 ++-- > > > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > > > > > > > > > > > From f87042d77d13c4c45f4b800146dc16347c1007d4 Mon Sep 17 00:00:00 2001 > > > From: Dale Curtis > > > Date: Tue, 30 Jul 2024 23:12:21 + > > > Subject: [PATCH] Check codec_whitelist before reinitializing > > AVCtx.priv_data. > > > > > > This ensures that if a codec isn't on codec_whitelist, its VUI > > > information can still be populated during find_stream_info() > > > via parsers. > > > > Can you elaborate on this? > > > > The current code reinitializes the private data structures then checks the > whitelist. If the private data section had already been filled out, it ends > up being overwritten causing find_stream_info to drop side channel data. I don't follow, why would any code outside of libavcodec care about anything in private data? -- Anton Khirnov ___ 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] MV-HEVC support for decoding of Apple's stereo video
Quoting Danny Hong (2024-08-16 21:49:05) > Quoting Anton Khirnov (2024-08-16 09:32:28) > > The way this will work is that different views will be output by decoder > > as separate frames with side data indicating their view ID. > > Thanks for the info again! Wouldn't it be easier for the user/consumer of > the decoded frames to simply have the side data indicate "left" or "right" > view? If only view ID is indicated, then the VPS and the 3D reference > displays information SEI have to be parsed again (by the user/consumer) to > get the mapping between view ID and left/right eye, no? View ID is the only information that is guaranteed to be present, as it's encoded in the VPS, which is why I'm treating it as fundamental. The decoder could also process and export SEI information when available, you just cannot rely on it in general. -- Anton Khirnov ___ 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] Don't reallocate a AVCodecContext when closing a non-open codec.
Quoting Dale Curtis (2024-08-02 18:54:04) > This results in an unnecessary ~800k allocation with H.264. A > nearby callsite uses avcodec_is_open() to avoid this, so do the > same when exiting avformat_find_stream_info(). > > Signed-off-by: Dale Curtis > --- > libavformat/demux.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) LGTM, pushed -- Anton Khirnov ___ 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] use proper macro to avoid issue with prior avutil/timestamp.c
> > FP_INFINITE is a return value from fpclassify(), not a double. > > Does maybe using av_int2double(UINT64_C(0xFFF) << 52) help your slow > startup? > Sadly, no. double log = (fpclassify(val) == FP_ZERO ? av_int2double(UINT64_C(0xFFF) << 52) : floor(log10(fabs(val; gives the same long-startup time. ___ 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] MV-HEVC support for decoding of Apple's stereo video
On 8/16/2024 4:49 PM, Danny Hong wrote: Quoting Anton Khirnov (2024-08-16 09:32:28) The way this will work is that different views will be output by decoder as separate frames with side data indicating their view ID. Thanks for the info again! Wouldn't it be easier for the user/consumer of the decoded frames to simply have the side data indicate "left" or "right" view? If only view ID is indicated, then the VPS and the 3D reference displays information SEI have to be parsed again (by the user/consumer) to get the mapping between view ID and left/right eye, no? When present, 3D reference displays information SEI will be used to export a Stereo3D frame side data entry signaling the eye the frame belongs to based on the view ID, yes. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/aarch64/me_cmp: add dotprod implementations of sse16 and vsse_intra16
On Fri, Aug 16, 2024 at 1:16 PM Martin Storsjö wrote: > On Thu, 15 Aug 2024, Ramiro Polla wrote: > > checkasm --bench for Raspberry Pi 5 Model B Rev 1.0: > > sse_0_c: 241.5 > > sse_0_neon: 37.2 > > sse_0_dotprod: 22.2 > > vsse_4_c: 148.7 > > vsse_4_neon: 31.0 > > vsse_4_dotprod: 15.7 > > --- > > libavcodec/aarch64/me_cmp_init_aarch64.c | 14 +++ > > libavcodec/aarch64/me_cmp_neon.S | 114 +++ > > 2 files changed, 128 insertions(+) > > LGTM, thanks! Thanks. Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] use proper macro to avoid issue with prior avutil/timestamp.c
Le 17 août 2024 06:09:16 GMT+03:00, Mike Lieman a écrit :
>From b2ddfdd9ed695a1f47ed6251369abca08864e3ab Mon Sep 17 00:00:00 2001
>From: Mike Lieman
>Date: Fri, 16 Aug 2024 23:05:51 -0400
>Subject: [PATCH] use proper macro to avoid issue with prior
>avutil/timestamp.c
> patch causing long startup times with some files under mplayer
> (https://trac.mplayerhq.hu/ticket/2425)
>
>---
> libavutil/timestamp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/libavutil/timestamp.c b/libavutil/timestamp.c
>index 6c231a517d..eab2531538 100644
>--- a/libavutil/timestamp.c
>+++ b/libavutil/timestamp.c
>@@ -24,7 +24,7 @@ char *av_ts_make_time_string2(char *buf, int64_t ts,
>AVRational tb)
> snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
> } else {
> double val = av_q2d(tb) * ts;
>-double log = (fpclassify(val) == FP_ZERO ? -INFINITY :
>floor(log10(fabs(val;
>+double log = (fpclassify(val) == FP_ZERO ? FP_INFINITE :
You're papering over whatever the real issue is here. As noted by James and the
Trac issue already, FP_INFINITE is *not* a floating point value and using it
this way makes no sense.
>floor(log10(fabs(val;
> int precision = (isfinite(log) && log < 0) ? -log + 5 : 6;
> int last = snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.*f", precision,
>val);
> last = FFMIN(last, AV_TS_MAX_STRING_SIZE - 1) - 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] use proper macro to avoid issue with prior avutil/timestamp.c
I now understand that and am trying to work through the logic to see why
we are getting this strange behaviour.When I have some free time, I
think I'm going to have to step through this with gdb since without the
context of what's actually in buf, ts, and tb I can't understand what's
going on in the for loops, but it seems something's going on in the for
loops, since it's not happening when I'm using the incorrect constant.
On Sat, Aug 17, 2024 at 10:07 AM Rémi Denis-Courmont
wrote:
>
>
> Le 17 août 2024 06:09:16 GMT+03:00, Mike Lieman a
> écrit :
> >From b2ddfdd9ed695a1f47ed6251369abca08864e3ab Mon Sep 17 00:00:00 2001
> >From: Mike Lieman
> >Date: Fri, 16 Aug 2024 23:05:51 -0400
> >Subject: [PATCH] use proper macro to avoid issue with prior
> >avutil/timestamp.c
> > patch causing long startup times with some files under mplayer
> > (https://trac.mplayerhq.hu/ticket/2425)
> >
> >---
> > libavutil/timestamp.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/libavutil/timestamp.c b/libavutil/timestamp.c
> >index 6c231a517d..eab2531538 100644
> >--- a/libavutil/timestamp.c
> >+++ b/libavutil/timestamp.c
> >@@ -24,7 +24,7 @@ char *av_ts_make_time_string2(char *buf, int64_t ts,
> >AVRational tb)
> > snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
> > } else {
> > double val = av_q2d(tb) * ts;
> >-double log = (fpclassify(val) == FP_ZERO ? -INFINITY :
> >floor(log10(fabs(val;
> >+double log = (fpclassify(val) == FP_ZERO ? FP_INFINITE :
>
> You're papering over whatever the real issue is here. As noted by James
> and the Trac issue already, FP_INFINITE is *not* a floating point value and
> using it this way makes no sense.
>
> >floor(log10(fabs(val;
> > int precision = (isfinite(log) && log < 0) ? -log + 5 : 6;
> > int last = snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.*f",
> precision,
> >val);
> > last = FFMIN(last, AV_TS_MAX_STRING_SIZE - 1) - 1;
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/vvc_mc: R-V V avg w_avg
How can I test the weight and biweight of H.264? I haven't seen the related test code.. tests/checkasm/checkasm --bench --test=h264dsp Rémi Denis-Courmont 于2024年8月15日周四 16:10写道： > > > Le 3 août 2024 13:30:34 GMT+03:00, u...@foxmail.com a écrit : > >From: sunyuechi > > > > C908 X60 > >avg_8_2x2_c:1.21.0 > >avg_8_2x2_rvv_i32 :0.70.7 > >avg_8_2x4_c:2.02.2 > >avg_8_2x4_rvv_i32 :1.21.2 > >avg_8_2x8_c:3.74.0 > >avg_8_2x8_rvv_i32 :1.71.5 > >avg_8_2x16_c :7.27.7 > >avg_8_2x16_rvv_i32 :3.02.7 > >avg_8_2x32_c : 14.2 15.2 > >avg_8_2x32_rvv_i32 :5.55.0 > >avg_8_2x64_c : 51.0 43.7 > >avg_8_2x64_rvv_i32 : 39.2 29.7 > >avg_8_2x128_c : 100.5 79.2 > >avg_8_2x128_rvv_i32: 79.7 68.2 > >avg_8_4x2_c:1.72.0 > >avg_8_4x2_rvv_i32 :1.00.7 > >avg_8_4x4_c:3.53.7 > >avg_8_4x4_rvv_i32 :1.21.2 > >avg_8_4x8_c:6.77.0 > >avg_8_4x8_rvv_i32 :1.71.5 > >avg_8_4x16_c : 13.5 14.0 > >avg_8_4x16_rvv_i32 :3.02.7 > >avg_8_4x32_c : 26.2 27.7 > >avg_8_4x32_rvv_i32 :5.54.7 > >avg_8_4x64_c : 73.0 73.7 > >avg_8_4x64_rvv_i32 : 39.0 32.5 > >avg_8_4x128_c : 143.0 137.2 > >avg_8_4x128_rvv_i32: 72.7 68.0 > >avg_8_8x2_c:3.53.5 > >avg_8_8x2_rvv_i32 :1.00.7 > >avg_8_8x4_c:6.26.5 > >avg_8_8x4_rvv_i32 :1.51.0 > >avg_8_8x8_c: 12.7 13.2 > >avg_8_8x8_rvv_i32 :2.01.5 > >avg_8_8x16_c : 25.0 26.5 > >avg_8_8x16_rvv_i32 :3.22.7 > >avg_8_8x32_c : 50.0 52.7 > >avg_8_8x32_rvv_i32 :6.25.0 > >avg_8_8x64_c : 118.7 122.5 > >avg_8_8x64_rvv_i32 : 40.2 31.5 > >avg_8_8x128_c : 236.7 220.2 > >avg_8_8x128_rvv_i32: 85.2 67.7 > >avg_8_16x2_c :6.26.7 > >avg_8_16x2_rvv_i32 :1.20.7 > >avg_8_16x4_c : 12.5 13.0 > >avg_8_16x4_rvv_i32 :1.71.0 > >avg_8_16x8_c : 24.5 26.0 > >avg_8_16x8_rvv_i32 :3.01.7 > >avg_8_16x16_c : 49.0 51.5 > >avg_8_16x16_rvv_i32:5.53.0 > >avg_8_16x32_c : 97.5 102.5 > >avg_8_16x32_rvv_i32: 10.55.5 > >avg_8_16x64_c : 213.7 222.0 > >avg_8_16x64_rvv_i32: 48.5 34.2 > >avg_8_16x128_c : 434.7 420.0 > >avg_8_16x128_rvv_i32 : 97.7 74.0 > >avg_8_32x2_c : 12.2 12.7 > >avg_8_32x2_rvv_i32 :1.51.0 > >avg_8_32x4_c : 24.5 25.5 > >avg_8_32x4_rvv_i32 :3.01.7 > >avg_8_32x8_c : 48.5 50.7 > >avg_8_32x8_rvv_i32 :5.22.7 > >avg_8_32x16_c : 96.7 101.2 > >avg_8_32x16_rvv_i32: 10.25.0 > >avg_8_32x32_c : 192.7 202.2 > >avg_8_32x32_rvv_i32: 19.79.5 > >avg_8_32x64_c
Re: [FFmpeg-devel] [PATCH] use proper macro to avoid issue with prior avutil/timestamp.c
On Sat, Aug 17, 2024 at 3:27 PM Mike Lieman wrote: > > > > > FP_INFINITE is a return value from fpclassify(), not a double. > > > > Does maybe using av_int2double(UINT64_C(0xFFF) << 52) help your slow > > startup? > > > > Sadly, no. > > double log = (fpclassify(val) == FP_ZERO ? av_int2double(UINT64_C(0xFFF) << > 52) : floor(log10(fabs(val; > For the logic in this particular function - even if not accurate, any non-negative value will result in the same outcome as using -INFINITY. So using even the value 0 would work. My simple guess would be that the infinity check fails for some reason (maybe -ffast-math?), thus treating the infinite as a finite value, and using an extreme amount of precision that almost breaks printf? We could avoid the infinity entirely here without any downsides, really. Or you could check if your build uses ffast-math, not sure we support that. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] use proper macro to avoid issue with prior avutil/timestamp.c
> > On Sat, Aug 17, 2024 at 11:29 AM Hendrik Leppkes > wrote: > Or you could check if your build uses ffast-math, not sure we support that > Hot Dog! We have a weiner! Removing -ffast-math from my mplayer build appears to have resolved the issue. Thank you for your time and guidance. ___ 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] Less CPU use in hwaccel MJPEG decoding
attached
>From 9e312c20d10839cb2c731acd23bc1b00177cd7dd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Llu=C3=ADs=20Batlle=20i=20Rossell?=
Date: Sat, 17 Aug 2024 18:03:37 +0200
Subject: [PATCH] Less CPU use in hwaccel MJPEG decoding
It skips the unnecessary unescaping the entropy-encoded data in case of
using a hardware accelerator.
---
libavcodec/mjpegdec.c | 19 ++-
libavcodec/mjpegdec.h | 1 +
libavcodec/mxpegdec.c | 2 +-
3 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 8676155ecf..759a01b981 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2235,12 +2235,21 @@ found:
}
int ff_mjpeg_find_marker(MJpegDecodeContext *s,
- const uint8_t **buf_ptr, const uint8_t *buf_end,
- const uint8_t **unescaped_buf_ptr,
- int *unescaped_buf_size)
+const struct AVHWAccel
*hwaccel,
+const uint8_t **buf_ptr, const
uint8_t *buf_end,
+const uint8_t
**unescaped_buf_ptr,
+int *unescaped_buf_size)
{
int start_code;
-start_code = find_marker(buf_ptr, buf_end);
+ start_code = find_marker(buf_ptr, buf_end);
+
+ if (start_code == SOS && hwaccel)
+ {
+ /* hardware accelerators don't need unescaping */
+ *unescaped_buf_ptr = *buf_ptr;
+ *unescaped_buf_size = buf_end - *buf_ptr;
+ return start_code;
+ }
av_fast_padded_malloc(&s->buffer, &s->buffer_size, buf_end - *buf_ptr);
if (!s->buffer)
@@ -2399,7 +2408,7 @@ redo_for_pal8:
buf_end = buf + buf_size;
while (buf_ptr < buf_end) {
/* find start next marker */
-start_code = ff_mjpeg_find_marker(s, &buf_ptr, buf_end,
+start_code = ff_mjpeg_find_marker(s, avctx->hwaccel, &buf_ptr, buf_end,
&unescaped_buf_ptr,
&unescaped_buf_size);
/* EOF */
diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
index 13c524d597..bc21eab647 100644
--- a/libavcodec/mjpegdec.h
+++ b/libavcodec/mjpegdec.h
@@ -184,6 +184,7 @@ int ff_mjpeg_decode_sos(MJpegDecodeContext *s,
const uint8_t *mb_bitmask,int mb_bitmask_size,
const AVFrame *reference);
int ff_mjpeg_find_marker(MJpegDecodeContext *s,
+const struct AVHWAccel
*hwaccel,
const uint8_t **buf_ptr, const uint8_t *buf_end,
const uint8_t **unescaped_buf_ptr, int
*unescaped_buf_size);
diff --git a/libavcodec/mxpegdec.c b/libavcodec/mxpegdec.c
index 73df2ff9ff..d18d1541ed 100644
--- a/libavcodec/mxpegdec.c
+++ b/libavcodec/mxpegdec.c
@@ -202,7 +202,7 @@ static int mxpeg_decode_frame(AVCodecContext *avctx,
AVFrame *rframe,
s->got_mxm_bitmask = 0;
s->got_sof_data = !!s->got_sof_data;
while (buf_ptr < buf_end) {
-start_code = ff_mjpeg_find_marker(jpg, &buf_ptr, buf_end,
+start_code = ff_mjpeg_find_marker(jpg, NULL, &buf_ptr, buf_end,
&unescaped_buf_ptr,
&unescaped_buf_size);
if (start_code < 0)
goto the_end;
--
2.44.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] Less CPU use in hwaccel MJPEG decoding (v2)
v2 attached.
I had crippled the indentation.
On Sat, Aug 17, 2024 at 06:05:24PM +0200, Lluís Batlle i Rossell wrote:
> attached
>From ea2d702daa88bf3b1bde1f03c26c69bb8ab9e2b8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Llu=C3=ADs=20Batlle=20i=20Rossell?=
Date: Sat, 17 Aug 2024 18:03:37 +0200
Subject: [PATCH] Less CPU use in hwaccel MJPEG decoding
It skips the unnecessary unescaping of the entropy-encoded data in case
of using a hardware accelerator.
This is 50% less of CPU use in my benchmark.
---
libavcodec/mjpegdec.c | 11 ++-
libavcodec/mjpegdec.h | 1 +
libavcodec/mxpegdec.c | 2 +-
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 8676155ecf..43583c1ccf 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2235,6 +2235,7 @@ found:
}
int ff_mjpeg_find_marker(MJpegDecodeContext *s,
+ const struct AVHWAccel *hwaccel,
const uint8_t **buf_ptr, const uint8_t *buf_end,
const uint8_t **unescaped_buf_ptr,
int *unescaped_buf_size)
@@ -2242,6 +2243,14 @@ int ff_mjpeg_find_marker(MJpegDecodeContext *s,
int start_code;
start_code = find_marker(buf_ptr, buf_end);
+if (start_code == SOS && hwaccel)
+{
+/* hardware accelerators don't need unescaping */
+*unescaped_buf_ptr = *buf_ptr;
+*unescaped_buf_size = buf_end - *buf_ptr;
+return start_code;
+}
+
av_fast_padded_malloc(&s->buffer, &s->buffer_size, buf_end - *buf_ptr);
if (!s->buffer)
return AVERROR(ENOMEM);
@@ -2399,7 +2408,7 @@ redo_for_pal8:
buf_end = buf + buf_size;
while (buf_ptr < buf_end) {
/* find start next marker */
-start_code = ff_mjpeg_find_marker(s, &buf_ptr, buf_end,
+start_code = ff_mjpeg_find_marker(s, avctx->hwaccel, &buf_ptr, buf_end,
&unescaped_buf_ptr,
&unescaped_buf_size);
/* EOF */
diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
index 13c524d597..bc21eab647 100644
--- a/libavcodec/mjpegdec.h
+++ b/libavcodec/mjpegdec.h
@@ -184,6 +184,7 @@ int ff_mjpeg_decode_sos(MJpegDecodeContext *s,
const uint8_t *mb_bitmask,int mb_bitmask_size,
const AVFrame *reference);
int ff_mjpeg_find_marker(MJpegDecodeContext *s,
+const struct AVHWAccel
*hwaccel,
const uint8_t **buf_ptr, const uint8_t *buf_end,
const uint8_t **unescaped_buf_ptr, int
*unescaped_buf_size);
diff --git a/libavcodec/mxpegdec.c b/libavcodec/mxpegdec.c
index 73df2ff9ff..d18d1541ed 100644
--- a/libavcodec/mxpegdec.c
+++ b/libavcodec/mxpegdec.c
@@ -202,7 +202,7 @@ static int mxpeg_decode_frame(AVCodecContext *avctx,
AVFrame *rframe,
s->got_mxm_bitmask = 0;
s->got_sof_data = !!s->got_sof_data;
while (buf_ptr < buf_end) {
-start_code = ff_mjpeg_find_marker(jpg, &buf_ptr, buf_end,
+start_code = ff_mjpeg_find_marker(jpg, NULL, &buf_ptr, buf_end,
&unescaped_buf_ptr,
&unescaped_buf_size);
if (start_code < 0)
goto the_end;
--
2.44.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] MAINTAINERS: Add more fields based on the linux kernel MAINTAINERs
Hi On Fri, Aug 16, 2024 at 10:41:54AM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-08-15 22:49:03) > > On Thu, Aug 15, 2024 at 07:38:50PM +0200, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2024-08-15 09:33:07) > > > > Text was stolen from the linux kernel > > > > This is thus identical to the kernel just a different more compact > > > > format. > > > > I am very happy also to switch the file entirely to the format of the > > > > linux kernel maintainer list > > > > if people prefer > > > > > > > > This allows tracking the status of each sub system, if it needs new > > > > blood or not > > > > > > > > It allows people to specify a separate webpage / document describing > > > > the subsystem > > > > It allows people to ask for bug reports to be mailed to them instead of > > > > just > > > > sent to trac. > > > > It allows listing things like gitlab or github or anything else where to > > > > submit patches. This could be used both for testing new patch > > > > submission systems > > > > as well as permanently honoring the preferance of the developers > > > > maintaining a > > > > subsystem. > > > > It allows listing a separate tree where development happens, and > > > > against which > > > > thus patches should be done. > > > > > > > > Overall this gives us/the people many more options on how to maintain > > > > their stuff > > > > > > I agree with Rémi that we are way too small to need Linux-style > > > subsystem delegation. > > > > Lets see, lets pick last month, july, in > > july 2024 we had 1456 messages on ffmpeg-devel > > july 2023 we had 1493, > > july 2022 we had 1221, > > july 2021 we had 953, > > july 2020 we had 1668 > > july 2019 we had 1316 > > july 2018 we had 974 > > july 2016 we had 1139 > > july 2014 we had 1183 > > july 2012 we had 1901 > > july 2010 we had 2391 > > > > Does this look to you like we are growing or that there is some limitation ? > > (also i could quote both Paul and Kostya about saying that the project > > dying) > > WTF is that supposed to mean and how is it relevant to this thread? You claimed "we are way too small to need Linux-style subsystem delegation." What i showed is that we are stagnant and not growing, and that projects with Linux-style subsystem delegation do not have this issue at this size. Paul and Kostyas point of view is a step further, that we are declining (for whatever reason) Its a fact of life, if things dont grow they tend to decline. To be perfectly balanced at the same size over long time there must be something that pushes it to that size. one can side by side compare projects that grow and are stagnant. I claim that for us its the closed-ness of our development model thats the cause. The need that every codec, every format, every filter must be in one repository and that every change to it must pass through one gate. I claimed this many times over many years, this is not new. I suggested many time that a plugin architecture and or a linux like development model would solve this > > > > > > I do not see who this is for and what actual > > > problems it is supposed to address. > > > > Many problems or many aspects of the same problem(s) > > > > Its fundamental human nature that people want to be free and work on their > > things without others interfering too much. They want to create > > things they feel proud of. > > > > Just think of it this way maybe, If you take 100 skilled artists and let > > each work on their own you will get 100 art pieces many will be impressive. > > OTOH if you put these 100 artists in the same group you will get one art > > piece > > and many artists who want to leave. > > Do you see maybe the relation to FFmpeg and people leaving ? > > > > You could also make this example with cooks. 100 cooks make 100 wonderfull > > dishes > > when they can work independantly. But if they are in the same kitchen and > > argue > > and demand changes from each other, the result will not be wonderfull nor > > will > > the cooks be satisfied with their own work, eventually some will leave > > > > You dont see this because you where not hit by this yourself in a way > > that bothers you. > > This is not an answer, this is a parable capped off with an ad hominem. why do you read this as if it was a personal attack? You yourself just said "I do not see who this is for and what actual problems it is supposed to address." And now if i speculate why as in "you dont see this because ..." is a personal attack ? If you do see the problem we dont need to discuss it. OTOH if you do not see key developers leaving or dont see their pain or dont see that they are happier when they can develop their code outside. Then we should discuss this, maybe iam wrong, maybe you will see the relation, maybe something entirely different will happen. This was not meant as an attack, it was meant as a discussion to resolve teh difference in our points of view. > > > Just as a unrelated, sid
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add more fields based on the linux kernel MAINTAINERs
On Fri, Aug 16, 2024 at 10:41:54AM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-08-15 22:49:03) > > On Thu, Aug 15, 2024 at 07:38:50PM +0200, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2024-08-15 09:33:07) [...] > > This is just a small step in improving things and really it sadens me > > that this is taken as something controversal. > > In other words, "I am sad that people disagree with me, therefore people > should not disagree with me". > This is a textbook attempt at emotional manipulation, AKA "appeal to > emotion". Thats a straw man fallacy. You word my position in a way that is not my position and then attack that Iam sad that FFmpeg started with a development model that would hit a scalability issue. And that i failed to change that later. Iam sad about my failure here Iam sad that the development model is kind of locked down, that maintaince outside isnt possible. And that any attempt to change that is blocked Iam not sad anyone disagrees with me Also theres nothing being split up. We have already people maintaining code outside. For example Paul in librempeg If one suggests to redo his work and "kill him off", instead of acknowledging that he maintains some parts of the codebase outside. Thats not a good solution IMHO, even though we likely will succeed if we try that. Here we do have again the scalability thing. look inward, redo others work, deny their existance or acknowledge their work and find a way to combine the work and move forward and grow This change to MAINTAINERs is just a small first step. The next step may be that we or I would talk with paul and see what exactly his oppinion and preferrance is. I cannot for example suggest to paul that he could maintain his code outside of ffmpeg and be paid for that IF here people already oppose to the idea of even allowing that at a syntax level in MAINTAINERs also of course payment requires STF & SPI & future community consensus. We are many steps away from this still. Iam in some sense here probing what the team would be ok with and what not and it makes me sad if outside maintaince is not an option. The fewer options we have the less likely it is that we can find an agreement with Paul. Of course others might want to use this too. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add more fields based on the linux kernel MAINTAINERs
Le 17 août 2024 19:32:00 GMT+03:00, Michael Niedermayer a écrit : >Hi > >On Fri, Aug 16, 2024 at 10:41:54AM +0200, Anton Khirnov wrote: >> Quoting Michael Niedermayer (2024-08-15 22:49:03) >> > On Thu, Aug 15, 2024 at 07:38:50PM +0200, Anton Khirnov wrote: >> > > Quoting Michael Niedermayer (2024-08-15 09:33:07) >> > > > Text was stolen from the linux kernel >> > > > This is thus identical to the kernel just a different more compact >> > > > format. >> > > > I am very happy also to switch the file entirely to the format of the >> > > > linux kernel maintainer list >> > > > if people prefer >> > > > >> > > > This allows tracking the status of each sub system, if it needs new >> > > > blood or not >> > > > >> > > > It allows people to specify a separate webpage / document describing >> > > > the subsystem >> > > > It allows people to ask for bug reports to be mailed to them instead >> > > > of just >> > > > sent to trac. >> > > > It allows listing things like gitlab or github or anything else where >> > > > to >> > > > submit patches. This could be used both for testing new patch >> > > > submission systems >> > > > as well as permanently honoring the preferance of the developers >> > > > maintaining a >> > > > subsystem. >> > > > It allows listing a separate tree where development happens, and >> > > > against which >> > > > thus patches should be done. >> > > > >> > > > Overall this gives us/the people many more options on how to maintain >> > > > their stuff >> > > >> > > I agree with Rémi that we are way too small to need Linux-style >> > > subsystem delegation. >> > >> > Lets see, lets pick last month, july, in >> > july 2024 we had 1456 messages on ffmpeg-devel >> > july 2023 we had 1493, >> > july 2022 we had 1221, >> > july 2021 we had 953, >> > july 2020 we had 1668 >> > july 2019 we had 1316 >> > july 2018 we had 974 >> > july 2016 we had 1139 >> > july 2014 we had 1183 >> > july 2012 we had 1901 >> > july 2010 we had 2391 >> > >> > Does this look to you like we are growing or that there is some limitation >> > ? >> > (also i could quote both Paul and Kostya about saying that the project >> > dying) >> >> WTF is that supposed to mean and how is it relevant to this thread? > >You claimed "we are way too small to need Linux-style subsystem delegation." >What i showed is that we are stagnant and not growing, and that projects with >Linux-style subsystem delegation do not have this issue at this size. You're confusing correlation and causation. FFmpeg is not stagnant *because* it does not have subsystems and non-fast-forward merges. The vast majority of OSS projects do not have subsystems (in the Linux sense) regardless of whether they are stagnant, dwindling or expanding. Linux-like development is but a mean to scale up. It is completely senseless to adopt that methodology in a project that does *not* have a major problem with scaling. It just brings more problems and solves almost none. In other words, you're (figuratively) putting the cart before the horse here. >Paul and Kostyas point of view is a step further, that we are declining (for >whatever reason) Subsystem delegation will not make things any better. The reasons why Paul forked are not addressed in any meaningful way by breaking FFmpeg down into Git subsystems. I'm oversimplifying but we have 3 factions now: - The FFboring faction wants to stick strictly to the current scope, do maintainance and immediately adjacent new features, for the benefit of existing downstreams and the `ffmpeg` CLI. - The Make FFmpeg Great Again faction wants to merge whatever experiments any committer works at, without the shackles of stability, FATE, the review process, etc, going back to how FFmpeg originally was (or how they idealise it), - the Neither-Nor faction who's trying to find an impossible middle ground and ends up mostly (but not fully) aligning with FFboring by default. Unfortunately I don't think this is tenable in the long run because the first two factions are really pushing in contradictory directions, that are not really amenable to compromised. The fact that Paul forked seems to confirm this. But regardless, Linux-style subsystems are *not* going to help here at all. >I claimed this many times over many years, this is not new. I suggested >many time that a plugin architecture and or a linux like development >model would solve this A plugin architecture is completely orthogonal to development methodology (and I am not personally against it). And in fact, I am not against Linux-style development per se, but FFmpeg does not currently have the scale to justify the additional *overhead* thereof. >why do you read my email in such a negative way ?! Because of how you worded it. I'm with Anton on this one. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpe
Re: [FFmpeg-devel] [PATCH] [h264] Use small padding with the checked bitstream reader.
On Wed, Aug 14, 2024 at 04:32:36PM -0700, Dale Curtis wrote: > MAX_MBPAIR_SIZE was added in 23f5cff92cdcfa55a735c458fcb5f95c0e0f3b1f > to prevent CABAC/CAVLC overread issues. It adds 256kb of padding to > RBSP allocations. AFAICT it seems unnecessary with the checked > bitstream reader. Dropping this padding is a substantial memory > improvement for constrained devices. > > 782865bf3094e36cbb4bd9cfacda252307e6589d removed the small padding > when AV_CODEC_FLAG2_FAST was set, but I don't have access to that > fuzzer test case to check this patch. Does anyone have this for testing? 20978/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5746381832847360 sent privately thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxf: start to add mxf_inspect_mode and skip RIP if needed sponsored by nxtedition
On Wed, 14 Aug 2024, Marc-Antoine Arnaud wrote:
---
libavformat/mxfdec.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
Why would you want to tune this?
Thanks,
Marton
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index a5863445ab5..df958819300 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -321,6 +321,7 @@ typedef struct MXFContext {
int nb_index_tables;
MXFIndexTable *index_tables;
int eia608_extract;
+int mxf_inspect_mode;
} MXFContext;
/* NOTE: klv_offset is not set (-1) for local keys */
@@ -3713,7 +3714,9 @@ static int mxf_read_header(AVFormatContext *s)
return AVERROR_INVALIDDATA;
mxf->run_in = run_in;
-mxf_read_random_index_pack(s);
+if (mxf->mxf_inspect_mode == 0) {
+mxf_read_random_index_pack(s);
+}
while (!avio_feof(s->pb)) {
const MXFMetadataReadTableEntry *metadata;
@@ -4261,6 +4264,15 @@ static const AVOption options[] = {
{ "eia608_extract", "extract eia 608 captions from s436m track",
offsetof(MXFContext, eia608_extract), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1,
AV_OPT_FLAG_DECODING_PARAM },
+{ "mxf_inspect_mode", "the way to inspect MXF file",
+ offsetof(MXFContext, mxf_inspect_mode), AV_OPT_TYPE_INT, {.i64 = 0}, 0,
1,
+ AV_OPT_FLAG_DECODING_PARAM, .unit = "mxf_inspect_mode" },
+{ "rip", "Parse RIP, then every body partition",
+ 0, AV_OPT_TYPE_CONST, {.i64 = 0}, INT_MIN, INT_MAX,
+ AV_OPT_FLAG_DECODING_PARAM, .unit = "mxf_inspect_mode" },
+{ "header", "Parse Header, first partition and next partitions if needed",
+ 0, AV_OPT_TYPE_CONST, {.i64 = 1}, INT_MIN, INT_MAX,
+ AV_OPT_FLAG_DECODING_PARAM, .unit = "mxf_inspect_mode" },
{ NULL },
};
--
2.39.3 (Apple Git-146)
___
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] [h264] Use small padding with the checked bitstream reader.
On 8/17/2024 3:04 PM, Michael Niedermayer wrote: On Wed, Aug 14, 2024 at 04:32:36PM -0700, Dale Curtis wrote: MAX_MBPAIR_SIZE was added in 23f5cff92cdcfa55a735c458fcb5f95c0e0f3b1f to prevent CABAC/CAVLC overread issues. It adds 256kb of padding to RBSP allocations. AFAICT it seems unnecessary with the checked bitstream reader. Dropping this padding is a substantial memory improvement for constrained devices. 782865bf3094e36cbb4bd9cfacda252307e6589d removed the small padding when AV_CODEC_FLAG2_FAST was set, but I don't have access to that fuzzer test case to check this patch. Does anyone have this for testing? 20978/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5746381832847360 sent privately thx Could the padding be changed to AV_INPUT_BUFFER_PADDING_SIZE instead of 0 when small_padding is requested? ___ 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] [TC invoked] [PATCH 2/4] lavc/mpegvideo: use H263DSP dequant function
On Sat, 6 Jul 2024, Rémi Denis-Courmont wrote: Le lauantaina 6. heinäkuuta 2024, 19.20.33 EEST Andreas Rheinhardt a écrit : Rémi Denis-Courmont: > Le lauantaina 6. heinäkuuta 2024, 18.23.00 EEST Andreas Rheinhardt a écrit : >> >> This adds an indirection. I have asked you to actually benchmark this >> code (and not only the DSP function you add), but you never did. > > I already pointed out previously that this is the way this project does > DSP > code. Certainly it would be nice to hard-code the path when there is only > one possible. This is often the case on Armv8 notably, and of course on > platforms without optimisations. > > But that's a general problem way beyond the scope of this patchset. We > always add indirect function calls in this sort of situation, and I don't > see why I would have duty to benchmark it, so I am going to ignore this. You have a duty to benchmark it because you add it where it wasn't before. I don't recall other people benchmarking the indirect branch they've added previously for other DSP code. Recent examples include VVC and FLAC. Rightfully so, because there is not really an alternative anyway. Even GNU IFUNCs and Glibc alternative libraries internally use an indirect branch (hidden in PLT/GOT), and FFmpeg can't self-patch at load-time like the Linux kernel does, nor can it generate dynamic PLT entries with direct branches. Also if an indirect call is unacceptable, then how come the calling code is itself an indirect call and for abstraction rather than performance. Your request is completely arbitrary here. Yes, there is already an indirect call close up, and so? I'm not trying to clean MpegEncContext here, only trying to add one function to checkasm, RVV and (with James' work) post-MMX x86. Hi, As discussions on these patchsets didn't seem to progress but seemed to get stuck, Rémi requested (admittedly, many many weeks ago) the TC to resolve the disputes here. Therefore - the TC has now started reading up on the earlier arguments made on the mailing list, and will now be discussing what the suggested way forward will be. Regards, The FFmpeg Technical Committee ___ 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/9] avcodec/avcodec: Warn about data returned from get_buffer*()
On Sat, Aug 17, 2024 at 01:32:56AM +0200, epira...@gmail.com wrote: > > > On 17 Aug 2024, at 1:11, Michael Niedermayer wrote: > > > Signed-off-by: Michael Niedermayer > > --- > > doc/APIchanges | 4 > > libavcodec/avcodec.h | 4 > > 2 files changed, 8 insertions(+) > > > > diff --git a/doc/APIchanges b/doc/APIchanges > > index 173f317ea1b..53d164959c0 100644 > > --- a/doc/APIchanges > > +++ b/doc/APIchanges > > @@ -2,6 +2,10 @@ The last version increases of all libraries were on > > 2024-03-07 > > > > API changes, most recent first: > > > > +2024-08-xx - x - lavc 61.11.100- avcodec.h > > + Not really a change but get_buffer*() should not return > > + sensitive data > > IMO this is really hard to understand unless you look at exactly this > commit diff which most people reading the change log will not. > > Maybe instead: > > Clarify the documentation for get_buffer*() functions, making it > clear that the memory returned by them should not contain sensitive > information. This is not a change in the API and how it already worked > before. ok will apply something very similar to your suggestion thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/4] avcodec/vvcdec: misc, rename BDOF_BLOCK_SIZE to BDOF_MIN_BLOCK_SIZE
---
libavcodec/vvc/dsp.c| 4 ++--
libavcodec/vvc/inter_template.c | 10 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavcodec/vvc/dsp.c b/libavcodec/vvc/dsp.c
index 648d54ebb2..7463d8c9de 100644
--- a/libavcodec/vvc/dsp.c
+++ b/libavcodec/vvc/dsp.c
@@ -80,8 +80,8 @@ typedef struct IntraEdgeParams {
#define BDOF_BORDER_EXT 1
#define BDOF_PADDED_SIZE(16 + BDOF_BORDER_EXT * 2)
-#define BDOF_BLOCK_SIZE 4
-#define BDOF_GRADIENT_SIZE (BDOF_BLOCK_SIZE + BDOF_BORDER_EXT * 2)
+#define BDOF_MIN_BLOCK_SIZE 4
+#define BDOF_GRADIENT_SIZE (BDOF_MIN_BLOCK_SIZE + BDOF_BORDER_EXT * 2)
#define BIT_DEPTH 8
#include "dsp_template.c"
diff --git a/libavcodec/vvc/inter_template.c b/libavcodec/vvc/inter_template.c
index afcee2e360..0f1712e337 100644
--- a/libavcodec/vvc/inter_template.c
+++ b/libavcodec/vvc/inter_template.c
@@ -433,8 +433,8 @@ static void FUNC(apply_bdof_min_block)(pixel* dst, const
ptrdiff_t dst_stride, c
const int16_t* gh[] = { gradient_h[0] + 1 + BDOF_PADDED_SIZE,
gradient_h[1] + 1 + BDOF_PADDED_SIZE };
const int16_t* gv[] = { gradient_v[0] + 1 + BDOF_PADDED_SIZE,
gradient_v[1] + 1 + BDOF_PADDED_SIZE };
-for (int y = 0; y < BDOF_BLOCK_SIZE; y++) {
-for (int x = 0; x < BDOF_BLOCK_SIZE; x++) {
+for (int y = 0; y < BDOF_MIN_BLOCK_SIZE; y++) {
+for (int x = 0; x < BDOF_MIN_BLOCK_SIZE; x++) {
const int idx = y * BDOF_PADDED_SIZE + x;
const int bdof_offset = vx * (gh[0][idx] - gh[1][idx]) + vy *
(gv[0][idx] - gv[1][idx]);
dst[x] = av_clip_pixel((src0[x] + offset4 + src1[x] + bdof_offset)
>> shift4);
@@ -461,8 +461,8 @@ static void FUNC(apply_bdof)(uint8_t *_dst, const ptrdiff_t
_dst_stride, int16_t
_src1, MAX_PB_SIZE, block_w, block_h, 1);
pad_int16(_src1, MAX_PB_SIZE, block_w, block_h);
-for (int y = 0; y < block_h; y += BDOF_BLOCK_SIZE) {
-for (int x = 0; x < block_w; x += BDOF_BLOCK_SIZE) {
+for (int y = 0; y < block_h; y += BDOF_MIN_BLOCK_SIZE) {
+for (int x = 0; x < block_w; x += BDOF_MIN_BLOCK_SIZE) {
const int16_t* src0 = _src0 + y * MAX_PB_SIZE + x;
const int16_t* src1 = _src1 + y * MAX_PB_SIZE + x;
pixel *d= dst + x;
@@ -472,7 +472,7 @@ static void FUNC(apply_bdof)(uint8_t *_dst, const ptrdiff_t
_dst_stride, int16_t
FUNC(derive_bdof_vx_vy)(src0, src1, gh, gv, BDOF_PADDED_SIZE, &vx,
&vy);
FUNC(apply_bdof_min_block)(d, dst_stride, src0, src1, gh, gv, vx,
vy);
}
-dst += BDOF_BLOCK_SIZE * dst_stride;
+dst += BDOF_MIN_BLOCK_SIZE * dst_stride;
}
}
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/4] avcodec/vvcdec: bdof, do not pad sources and gradients to simplify the code
---
libavcodec/vvc/dsp.c| 25 +
libavcodec/vvc/dsp.h| 4 +-
libavcodec/vvc/inter_template.c | 65 ++---
3 files changed, 31 insertions(+), 63 deletions(-)
diff --git a/libavcodec/vvc/dsp.c b/libavcodec/vvc/dsp.c
index 7463d8c9de..433353c32c 100644
--- a/libavcodec/vvc/dsp.c
+++ b/libavcodec/vvc/dsp.c
@@ -26,26 +26,6 @@
#define VVC_SIGN(v) (v < 0 ? -1 : !!v)
-static void av_always_inline pad_int16(int16_t *_dst, const ptrdiff_t
dst_stride, const int width, const int height)
-{
-const int padded_width = width + 2;
-int16_t *dst;
-for (int y = 0; y < height; y++) {
-dst = _dst + y * dst_stride;
-for (int x = 0; x < width; x++) {
-dst[-1] = dst[0];
-dst[width] = dst[width - 1];
-}
-}
-
-_dst--;
-//top
-memcpy(_dst - dst_stride, _dst, padded_width * sizeof(int16_t));
-//bottom
-_dst += dst_stride * height;
-memcpy(_dst, _dst - dst_stride, padded_width * sizeof(int16_t));
-}
-
static int vvc_sad(const int16_t *src0, const int16_t *src1, int dx, int dy,
const int block_w, const int block_h)
{
@@ -77,11 +57,10 @@ typedef struct IntraEdgeParams {
#define PROF_BORDER_EXT 1
#define PROF_BLOCK_SIZE (AFFINE_MIN_BLOCK_SIZE + PROF_BORDER_EXT * 2)
-#define BDOF_BORDER_EXT 1
-#define BDOF_PADDED_SIZE(16 + BDOF_BORDER_EXT * 2)
+#define BDOF_BORDER_EXT 1
+#define BDOF_BLOCK_SIZE 16
#define BDOF_MIN_BLOCK_SIZE 4
-#define BDOF_GRADIENT_SIZE (BDOF_MIN_BLOCK_SIZE + BDOF_BORDER_EXT * 2)
#define BIT_DEPTH 8
#include "dsp_template.c"
diff --git a/libavcodec/vvc/dsp.h b/libavcodec/vvc/dsp.h
index 38ff492a23..635ebcafed 100644
--- a/libavcodec/vvc/dsp.h
+++ b/libavcodec/vvc/dsp.h
@@ -88,8 +88,6 @@ typedef struct VVCInterDSPContext {
void (*bdof_fetch_samples)(int16_t *dst, const uint8_t *src, ptrdiff_t
src_stride, int x_frac, int y_frac,
int width, int height);
-void (*prof_grad_filter)(int16_t *gradient_h, int16_t *gradient_v, const
ptrdiff_t gradient_stride,
-const int16_t *src, const ptrdiff_t src_stride, int width, int height,
const int pad);
void (*apply_prof)(int16_t *dst, const int16_t *src, const int16_t
*diff_mv_x, const int16_t *diff_mv_y);
void (*apply_prof_uni)(uint8_t *dst, ptrdiff_t dst_stride, const int16_t
*src,
@@ -97,7 +95,7 @@ typedef struct VVCInterDSPContext {
void (*apply_prof_uni_w)(uint8_t *dst, const ptrdiff_t dst_stride, const
int16_t *src,
const int16_t *diff_mv_x, const int16_t *diff_mv_y, int denom, int wx,
int ox);
-void (*apply_bdof)(uint8_t *dst, ptrdiff_t dst_stride, int16_t *src0,
int16_t *src1, int block_w, int block_h);
+void (*apply_bdof)(uint8_t *dst, ptrdiff_t dst_stride, const int16_t
*src0, const int16_t *src1, int block_w, int block_h);
int (*sad)(const int16_t *src0, const int16_t *src1, int dx, int dy, int
block_w, int block_h);
void (*dmvr[2][2])(int16_t *dst, const uint8_t *src, ptrdiff_t src_stride,
int height,
diff --git a/libavcodec/vvc/inter_template.c b/libavcodec/vvc/inter_template.c
index 0f1712e337..c073a73e76 100644
--- a/libavcodec/vvc/inter_template.c
+++ b/libavcodec/vvc/inter_template.c
@@ -292,13 +292,11 @@ static void FUNC(fetch_samples)(int16_t *_dst, const
uint8_t *_src, const ptrdif
FUNC(bdof_fetch_samples)(_dst, _src, _src_stride, x_frac, y_frac,
AFFINE_MIN_BLOCK_SIZE, AFFINE_MIN_BLOCK_SIZE);
}
-static void FUNC(prof_grad_filter)(int16_t *_gradient_h, int16_t *_gradient_v,
const ptrdiff_t gradient_stride,
-const int16_t *_src, const ptrdiff_t src_stride, const int width, const
int height, const int pad)
+static void FUNC(prof_grad_filter)(int16_t *gradient_h, int16_t *gradient_v,
const ptrdiff_t gradient_stride,
+const int16_t *_src, const ptrdiff_t src_stride, const int width, const
int height)
{
const int shift = 6;
const int16_t *src = _src;
-int16_t *gradient_h = _gradient_h + pad * (1 + gradient_stride);
-int16_t *gradient_v = _gradient_v + pad * (1 + gradient_stride);
for (int y = 0; y < height; y++) {
const int16_t *p = src;
@@ -311,10 +309,6 @@ static void FUNC(prof_grad_filter)(int16_t *_gradient_h,
int16_t *_gradient_v, c
gradient_v += gradient_stride;
src += src_stride;
}
-if (pad) {
-pad_int16(_gradient_h + 1 + gradient_stride, gradient_stride, width,
height);
-pad_int16(_gradient_v + 1 + gradient_stride, gradient_stride, width,
height);
-}
}
static void FUNC(apply_prof)(int16_t *dst, const int16_t *src, const int16_t
*diff_mv_x, const int16_t *diff_mv_y)
@@ -323,7 +317,7 @@ static void FUNC(apply_prof)(int16_t *dst, const int16_t
*src, const int16_t *di
int16_t gradient_h[AFFINE_MIN_BLOCK_SIZE * AFFINE_MIN_BLOCK_SIZE];
int16_t gradient_v[AFFINE_MIN_BLOCK_SIZE * AFFINE_MIN_BLOCK_SIZE];
-FUNC(prof_grad_filter)(
[FFmpeg-devel] [PATCH 3/4] x86/vvcdec: inter, add optical flow avx2 code
BDoF used about 10%–25% of the CPU for some clips. Here are the FPS for one run; please ignore the negative values, as they may be due to round-to-round variation clips | before | after | delta ||---|-- RitualDance_1920x1080_60_10_420_37_RA.266 | 310.0 | 363.0 | 14.60% NovosobornayaSquare_1920x1080.bin | 322.3 | 339.7 | 5.12% Tango2_3840x2160_60_10_420_27_LD.266| 71.0 | 68.7 | -3.35% RitualDance_1920x1080_60_10_420_32_LD.266 | 250.0 | 245.3 | -1.92% Chimera_8bit_1080P_1000_frames.vvc | 359.3 | 422.7 | 15.00% BQTerrace_1920x1080_60_10_420_22_RA.vvc | 142.3 | 147.7 | 3.66% --- libavcodec/x86/vvc/Makefile | 1 + libavcodec/x86/vvc/vvc_of.asm| 380 +++ libavcodec/x86/vvc/vvcdsp_init.c | 21 ++ 3 files changed, 402 insertions(+) create mode 100644 libavcodec/x86/vvc/vvc_of.asm diff --git a/libavcodec/x86/vvc/Makefile b/libavcodec/x86/vvc/Makefile index 04f16bc10c..aa59aa59cf 100644 --- a/libavcodec/x86/vvc/Makefile +++ b/libavcodec/x86/vvc/Makefile @@ -6,5 +6,6 @@ OBJS-$(CONFIG_VVC_DECODER) += x86/vvc/vvcdsp_init.o \ X86ASM-OBJS-$(CONFIG_VVC_DECODER) += x86/vvc/vvc_alf.o \ x86/vvc/vvc_dmvr.o \ x86/vvc/vvc_mc.o \ + x86/vvc/vvc_of.o \ x86/vvc/vvc_sad.o \ x86/h26x/h2656_inter.o diff --git a/libavcodec/x86/vvc/vvc_of.asm b/libavcodec/x86/vvc/vvc_of.asm new file mode 100644 index 00..b70073fa82 --- /dev/null +++ b/libavcodec/x86/vvc/vvc_of.asm @@ -0,0 +1,380 @@ +; /* +; * Provide AVX2 luma optical flow functions for VVC decoding +; * Copyright (c) 2024 Nuo Mi +; * +; * This file is part of FFmpeg. +; * +; * FFmpeg is free software; you can redistribute it and/or +; * modify it under the terms of the GNU Lesser General Public +; * License as published by the Free Software Foundation; either +; * version 2.1 of the License, or (at your option) any later version. +; * +; * FFmpeg is distributed in the hope that it will be useful, +; * but WITHOUT ANY WARRANTY; without even the implied warranty of +; * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +; * Lesser General Public License for more details. +; * +; * You should have received a copy of the GNU Lesser General Public +; * License along with FFmpeg; if not, write to the Free Software +; * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA +; */ +%include "libavutil/x86/x86util.asm" + +%define MAX_PB_SIZE 128 +%define SRC_STRIDE (MAX_PB_SIZE * 2) +%define SRC_PS 2 ; source pixel size, sizeof(int16_t) +%define BDOF_STACK_SIZE 10 ; (4 + 1) * 2, 4 lines + the first line, *2 for h and v +%define bdof_stack_offset(line) ((line) * 2 % BDOF_STACK_SIZE * mmsize) +%define SHIFT 6 +%define SHIFT2 4 + +SECTION_RODATA 32 +pd_15 times 8 dd 15 +pd_m15 times 8 dd -15 +cextern pb_0 + +pb_shuffle_w8 times 2 db 0, 1, 0xff, 0xff, 8, 9, 0xff, 0xff, 6, 7, 0xff, 0xff, 14, 15, 0xff, 0xff +pb_shuffle_w16 times 2 db 0, 1, 0xff, 0xff, 6, 7, 0xff, 0xff, 8, 9, 0xff, 0xff, 14, 15, 0xff, 0xff +pd_perm_w16dd 0, 2, 1, 4, 3, 6, 5, 7 +%if ARCH_X86_64 + +%if HAVE_AVX2_EXTERNAL + +SECTION .text + +INIT_YMM avx2 + +; dst = (src0 >> shift) - (src1 >> shift) +%macro DIFF 5 ; dst, src0, src1, shift, tmp +psraw %1, %2, %4 +psraw %5, %3, %4 +psubw %1, %5 +%endmacro + +%macro LOAD_GRAD_H 4 ; dst, src, off, tmp +movu%1, [%2 + %3 + 2 * SRC_PS] +movu%4, [%2 + %3] + +DIFF%1, %1, %4, SHIFT, %4 +%endmacro + +%macro SUM_GRAD 2 ;(dst/grad0, grad1) +paddw %1, %2 +psraw %1, 1; shift3 +%endmacro + +%macro APPLY_BDOF_MIN_BLOCK_LINE 5 ; dst, vx, vy, tmp, line_num +%define off bdof_stack_offset(%5) +pmullw%1, %2, [rsp + off + 0 * mmsize] ; vx * (gradient_h[0] - gradient_h[1]) +pmullw%4, %3, [rsp + off + 1 * mmsize] ; vy * (gradient_v[0] - gradient_v[1]) +paddw %1, [src0q + (%5 + 1) * SRC_STRIDE + SRC_PS] +paddw %4, [src1q + (%5 + 1) * SRC_STRIDE + SRC_PS] +paddsw%1, %4 ; src0[x] + src1[x] + bdof_offset +pmulhrsw %1, m11 +CLIPW %1, m9, m10 +%endmacro + +%macro SAVE_8BPC 2 ; dst, src +packuswb m%2, m%2 +vpermq m%2, m%2, q0020 +
[FFmpeg-devel] [PATCH 4/4] checkasm: add vvc_bdof test
apply_bdof_8_8x16_c: 5718.7
apply_bdof_8_8x16_avx2: 1029.9
apply_bdof_8_16x8_c: 5669.4
apply_bdof_8_16x8_avx2: 592.2
apply_bdof_8_16x16_c: 11313.4
apply_bdof_8_16x16_avx2: 1211.9
apply_bdof_10_8x16_c: 6295.7
apply_bdof_10_8x16_avx2: 1019.9
apply_bdof_10_16x8_c: 5548.2
apply_bdof_10_16x8_avx2: 580.9
apply_bdof_10_16x16_c: 11199.2
apply_bdof_10_16x16_avx2: 1154.2
apply_bdof_12_8x16_c: 5594.2
apply_bdof_12_8x16_avx2: 1018.2
apply_bdof_12_16x8_c: 5548.4
apply_bdof_12_16x8_avx2: 582.9
apply_bdof_12_16x16_c: 11016.7
apply_bdof_12_16x16_avx2: 1158.2
---
tests/checkasm/vvc_mc.c | 50 +
1 file changed, 50 insertions(+)
diff --git a/tests/checkasm/vvc_mc.c b/tests/checkasm/vvc_mc.c
index 62fa6aa7d0..754cf19065 100644
--- a/tests/checkasm/vvc_mc.c
+++ b/tests/checkasm/vvc_mc.c
@@ -64,6 +64,14 @@ static const int sizes[] = { 2, 4, 8, 16, 32, 64, 128 };
randomize_buffers(buf0, buf1, size, mask); \
} while (0)
+#define randomize_prof_src(buf0, buf1, size)\
+do {\
+const int shift = 14 - bit_depth; \
+const int mask16 = 0x3fff >> shift << shift; \
+uint32_t mask = (mask16 << 16) | mask16;\
+randomize_buffers(buf0, buf1, size, mask); \
+} while (0)
+
static void check_put_vvc_luma(void)
{
LOCAL_ALIGNED_32(int16_t, dst0, [DST_BUF_SIZE / 2]);
@@ -382,6 +390,47 @@ static void check_dmvr(void)
report("dmvr");
}
+#define BDOF_BLOCK_SIZE 16
+#define BDOF_SRC_SIZE (MAX_PB_SIZE* (BDOF_BLOCK_SIZE + 2))
+#define BDOF_SRC_OFFSET (MAX_PB_SIZE + 1)
+#define BDOF_DST_SIZE (BDOF_BLOCK_SIZE * BDOF_BLOCK_SIZE * 2)
+static void check_bdof(void)
+{
+LOCAL_ALIGNED_32(uint8_t, dst0, [BDOF_DST_SIZE]);
+LOCAL_ALIGNED_32(uint8_t, dst1, [BDOF_DST_SIZE]);
+LOCAL_ALIGNED_32(uint16_t, src00, [BDOF_SRC_SIZE]);
+LOCAL_ALIGNED_32(uint16_t, src01, [BDOF_SRC_SIZE]);
+LOCAL_ALIGNED_32(uint16_t, src10, [BDOF_SRC_SIZE]);
+LOCAL_ALIGNED_32(uint16_t, src11, [BDOF_SRC_SIZE]);
+
+VVCDSPContext c;
+declare_func(void, uint8_t *dst, ptrdiff_t dst_stride, const int16_t
*src0, const int16_t *src1, int block_w, int block_h);
+
+for (int bit_depth = 8; bit_depth <= 12; bit_depth += 2) {
+const int dst_stride = BDOF_BLOCK_SIZE * SIZEOF_PIXEL;
+
+ff_vvc_dsp_init(&c, bit_depth);
+randomize_prof_src(src00, src10, BDOF_SRC_SIZE);
+randomize_prof_src(src01, src11, BDOF_SRC_SIZE);
+for (int h = 8; h <= 16; h *= 2) {
+for (int w = 8; w <= 16; w *= 2) {
+if (w * h < 128)
+continue;
+if (check_func(c.inter.apply_bdof, "apply_bdof_%d_%dx%d",
bit_depth, w, h)) {
+memset(dst0, 0, BDOF_DST_SIZE);
+memset(dst1, 0, BDOF_DST_SIZE);
+call_ref(dst0, dst_stride, src00 + BDOF_SRC_OFFSET, src01
+ BDOF_SRC_OFFSET, w, h);
+call_new(dst1, dst_stride, src10 + BDOF_SRC_OFFSET, src11
+ BDOF_SRC_OFFSET, w, h);
+if (memcmp(dst0, dst1, BDOF_DST_SIZE))
+fail();
+bench_new(dst0, dst_stride, src00 + BDOF_SRC_OFFSET, src01
+ BDOF_SRC_OFFSET, w, h);
+}
+}
+}
+}
+report("apply_bdof");
+}
+
static void check_vvc_sad(void)
{
const int bit_depth = 10;
@@ -422,6 +471,7 @@ static void check_vvc_sad(void)
void checkasm_check_vvc_mc(void)
{
check_dmvr();
+check_bdof();
check_vvc_sad();
check_put_vvc_luma();
check_put_vvc_luma_uni();
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] x86/vvcdec: inter, add optical flow avx2 code
On 8/17/2024 10:48 PM, Nuo Mi wrote: +pxorm6, m6 +phaddw m%2, m6 +phaddw m%2, m6 Horizonal adds are slow. Can't you do this with normal adds, shifts and blend? +vpermq m%2, m%2, q0020 +pshufd m%2, m%2, q1120 +pmovsxwd m%2, xmm%2 ; 4 sgxgy + +pmulld m%2, m11 ; 4 vx * sgxgy Similarly, pmulld is super slow (Ten cycles in some architectures), and that's on top of a pmovsx. Since you have m6 zeroed already, wouldn't pmaddwd work here? The pd_15 and pd_m15 constants would need to be changed to words, as would the values to be clipped. +psrad m%2, 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] hw_base_encode: refactor picture allocation/freeing
This commit cleans up and refactors the mess of private state upon
private state that used to be.
Now, FFHWBaseEncodePicture is fully initialized upon call-time,
and, most importantly, this lets APIs which require initialization
data for frames (VkImageViews) to initialize this for both the
input image, and the reconstruction (DPB) image.
---
libavcodec/d3d12va_encode.c | 24 +---
libavcodec/hw_base_encode.c | 33 ++---
libavcodec/hw_base_encode.h | 21 ++-
libavcodec/vaapi_encode.c | 66 ++---
libavcodec/vaapi_encode.h | 4 +-
libavcodec/vaapi_encode_av1.c | 20 +-
libavcodec/vaapi_encode_h264.c | 42 ++---
libavcodec/vaapi_encode_h265.c | 20 +-
libavcodec/vaapi_encode_mjpeg.c | 7 ++--
libavcodec/vaapi_encode_mpeg2.c | 7 ++--
libavcodec/vaapi_encode_vp8.c | 4 +-
libavcodec/vaapi_encode_vp9.c | 14 +++
12 files changed, 128 insertions(+), 134 deletions(-)
diff --git a/libavcodec/d3d12va_encode.c b/libavcodec/d3d12va_encode.c
index 9ee9da41e3..681044c5c8 100644
--- a/libavcodec/d3d12va_encode.c
+++ b/libavcodec/d3d12va_encode.c
@@ -186,7 +186,7 @@ static int
d3d12va_encode_create_metadata_buffers(AVCodecContext *avctx,
}
static int d3d12va_encode_issue(AVCodecContext *avctx,
-const FFHWBaseEncodePicture *base_pic)
+FFHWBaseEncodePicture *base_pic)
{
FFHWBaseEncodeContext *base_ctx = avctx->priv_data;
D3D12VAEncodeContext *ctx = avctx->priv_data;
@@ -560,27 +560,20 @@ static int d3d12va_encode_free_rc_params(AVCodecContext
*avctx)
return 0;
}
-static FFHWBaseEncodePicture *d3d12va_encode_alloc(AVCodecContext *avctx,
- const AVFrame *frame)
+static int d3d12va_encode_init(AVCodecContext *avctx, FFHWBaseEncodePicture
*base)
{
D3D12VAEncodeContext *ctx = avctx->priv_data;
-D3D12VAEncodePicture *pic;
-
-pic = av_mallocz(sizeof(*pic));
-if (!pic)
-return NULL;
+D3D12VAEncodePicture *pic = base->priv;
if (ctx->codec->picture_priv_data_size > 0) {
-pic->base.priv_data = av_mallocz(ctx->codec->picture_priv_data_size);
-if (!pic->base.priv_data) {
-av_freep(&pic);
-return NULL;
-}
+pic->base.codec_priv = av_mallocz(ctx->codec->picture_priv_data_size);
+if (!pic->base.codec_priv)
+return AVERROR(ENOMEM);
}
pic->input_surface = (AVD3D12VAFrame *)frame->data[0];
-return &pic->base;
+return 0;
}
static int d3d12va_encode_free(AVCodecContext *avctx,
@@ -680,7 +673,7 @@ end:
}
static int d3d12va_encode_output(AVCodecContext *avctx,
- const FFHWBaseEncodePicture *base_pic,
AVPacket *pkt)
+ FFHWBaseEncodePicture *base_pic, AVPacket
*pkt)
{
FFHWBaseEncodeContext *base_ctx = avctx->priv_data;
D3D12VAEncodePicture *pic = (D3D12VAEncodePicture *)base_pic;
@@ -1389,6 +1382,7 @@ static int
d3d12va_encode_create_recon_frames(AVCodecContext *avctx)
}
static const FFHWEncodePictureOperation d3d12va_type = {
+.priv_size = sizeof(D3D12VAEncodePicture),
.alloc = &d3d12va_encode_alloc,
.issue = &d3d12va_encode_issue,
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index c1346e866c..60d862f1b6 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -27,6 +27,19 @@
#include "avcodec.h"
#include "hw_base_encode.h"
+static int base_encode_pic_free(FFHWBaseEncodePicture *pic)
+{
+av_frame_free(&pic->input_image);
+av_frame_free(&pic->recon_image);
+
+av_buffer_unref(&pic->opaque_ref);
+av_freep(&pic->codec_priv);
+av_freep(&pic->priv);
+av_free(pic);
+
+return 0;
+}
+
static void hw_base_encode_add_ref(FFHWBaseEncodePicture *pic,
FFHWBaseEncodePicture *target,
int is_ref, int in_dpb, int prev)
@@ -370,6 +383,7 @@ static int hw_base_encode_clear_old(AVCodecContext *avctx,
FFHWBaseEncodeContext
else
ctx->pic_start = next;
ctx->op->free(avctx, pic);
+base_encode_pic_free(pic);
} else {
prev = pic;
}
@@ -416,7 +430,7 @@ static int hw_base_encode_send_frame(AVCodecContext *avctx,
FFHWBaseEncodeContex
if (err < 0)
return err;
-pic = ctx->op->alloc(avctx, frame);
+pic = av_mallocz(sizeof(*pic));
if (!pic)
return AVERROR(ENOMEM);
@@ -467,6 +481,9 @@ static int hw_base_encode_send_frame(AVCodecContext *avctx,
FFHWBaseEncodeContex
ctx->pic_end = pic;
}
+err = ctx->op->init(avctx, pic);
+if (err < 0)
+goto fail;
} else {
ctx->end_of_stream = 1;
@@ -480,6 +497,7 @@ stati
