Re: [FFmpeg-devel] libavc/libx264: add support to propagate SSE values through encoder stats
Quoting Carotti, Elias via ffmpeg-devel (2023-10-11 12:54:21)
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 77a9f173b4..85bd870f5d 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -726,7 +726,39 @@ FF_ENABLE_DEPRECATION_WARNINGS
>
> pkt->flags |= AV_PKT_FLAG_KEY*pic_out.b_keyframe;
> if (ret) {
> -ff_side_data_set_encoder_stats(pkt, (pic_out.i_qpplus1 - 1) *
> FF_QP2LAMBDA, NULL, 0, pict_type);
> +const AVPixFmtDescriptor *pix_desc =
> av_pix_fmt_desc_get(csp_to_pixfmt(pic_out.img.i_csp));
There's a problem here - we do not handle all values of i_csp.
E.g. we have no equivalent of X264_CSP_NV12 | X264_CSP_HIGH_DEPTH, which
x264 will use for YUV420P10 input.
The best solution is probably to use AVCodecContext.pix_fmt and assume
that x264 doesn't do any nontrivial (i.e. other than interleaving and
such) pixel format transformations internally.
> +int error_count = 0;
> +int64_t *errors = NULL;
> +int64_t sse[3] = {0};
> +
> +if (ctx->flags & AV_CODEC_FLAG_PSNR) {
> +double scale[3] = { 1,
> +(double)(1 << pix_desc->log2_chroma_h) * (1 <<
> pix_desc->log2_chroma_w),
> +(double)(1 << pix_desc->log2_chroma_h) * (1 <<
> pix_desc->log2_chroma_w),
> +};
> +
> +error_count = pix_desc->nb_components;
> +
> +av_log(ctx, AV_LOG_DEBUG, "PSNR values from libx264: %.3f %.3f
> %.3f.\n",
> + pic_out.prop.f_psnr[0], pic_out.prop.f_psnr[1],
> pic_out.prop.f_psnr[2]);
In my tests libx264 prints these values by itself, so this seems
redundant.
--
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] avfilter/vf_showinfo: also print chroma loc
From: Niklas Haas Curiously absent. --- libavfilter/vf_showinfo.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c index bf8580bc8d..71869446c6 100644 --- a/libavfilter/vf_showinfo.c +++ b/libavfilter/vf_showinfo.c @@ -715,11 +715,11 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *frame) av_log(ctx, AV_LOG_INFO, "n:%4"PRId64" pts:%7s pts_time:%-7s duration:%7"PRId64 " duration_time:%-7s " - "fmt:%s sar:%d/%d s:%dx%d i:%c iskey:%d type:%c ", + "fmt:%s cl:%s sar:%d/%d s:%dx%d i:%c iskey:%d type:%c ", inlink->frame_count_out, av_ts2str(frame->pts), av_ts2timestr(frame->pts, &inlink->time_base), frame->duration, av_ts2timestr(frame->duration, &inlink->time_base), - desc->name, + desc->name, av_chroma_location_name(frame->chroma_location), frame->sample_aspect_ratio.num, frame->sample_aspect_ratio.den, frame->width, frame->height, !(frame->flags & AV_FRAME_FLAG_INTERLACED) ? 'P' : /* Progressive */ -- 2.42.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] avfilter/vf_scale: fix interlaced chroma for other formats
From: Niklas Haas
This logic only covers the case of yuv420p. Extend this logic to cover
*all* vertically subsampled YUV formats, which require the same
interlaced scaling logic.
Fortunately, we can get away with re-using the same code for both JPEG
and MPEG range YUV, because the only difference here is the horizontal
alignment. (To be fixed in a separate commit)
---
libavfilter/vf_scale.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index b0221e8538..23335cef4b 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -518,6 +518,7 @@ static int config_props(AVFilterLink *outlink)
outlink->src->inputs[0];
enum AVPixelFormat outfmt = outlink->format;
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
+const AVPixFmtDescriptor *outdesc = av_pix_fmt_desc_get(outfmt);
ScaleContext *scale = ctx->priv;
uint8_t *flags_val = NULL;
int ret;
@@ -588,14 +589,15 @@ static int config_props(AVFilterLink *outlink)
av_opt_set_int(s, "dst_range",
scale->out_range == AVCOL_RANGE_JPEG, 0);
-/* Override YUV420P default settings to have the correct (MPEG-2)
chroma positions
- * MPEG-2 chroma positions are used by convention
- * XXX: support other 4:2:0 pixel formats */
-if (inlink0->format == AV_PIX_FMT_YUV420P && scale->in_v_chr_pos
== -513) {
+/* Override chroma location default settings to have the correct
+ * chroma positions. MPEG chroma positions are used by convention.
+ * Note that this works for both MPEG-1/JPEG and MPEG-2/4 chroma
+ * locations, since they share a vertical alignment */
+if (desc->log2_chroma_h == 1 && scale->in_v_chr_pos == -513) {
in_v_chr_pos = (i == 0) ? 128 : (i == 1) ? 64 : 192;
}
-if (outlink->format == AV_PIX_FMT_YUV420P && scale->out_v_chr_pos
== -513) {
+if (outdesc->log2_chroma_h == 1 && scale->out_v_chr_pos == -513) {
out_v_chr_pos = (i == 0) ? 128 : (i == 1) ? 64 : 192;
}
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
Changes since v1: - Remove unneeded patch (AVCodecContext.colorspace init) - Merge auto-range conversion into auto-scale filter - Replace vf_zscale by vf_colorspace in fftools - Add some miscellaneous fixes for various FATE tests - Clean up some additional vestigiaul YUVJ remnants ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 01/13] avfilter/vf_scale: don't change range by default
From: Niklas Haas If we don't convert the pixel format, then we shouldn't touch the pixel range by default, either. Ensures full-range YUV input comes out as full-range YUV output, unless we go through a pixel format conversion. In theory, we may also want to extend this logic to YUV->YUV conversions, but a few special cases (YUVJ, Gray, RGB) make this more annoying than it needs to be, so I'll defer it to a future commit. --- libavfilter/vf_scale.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c index b0221e8538..9bbf0f8ed5 100644 --- a/libavfilter/vf_scale.c +++ b/libavfilter/vf_scale.c @@ -863,6 +863,8 @@ scale: in_full = (in_range == AVCOL_RANGE_JPEG); if (scale->out_range != AVCOL_RANGE_UNSPECIFIED) out_full = (scale->out_range == AVCOL_RANGE_JPEG); +else if (in->format == out->format) +out_full = in_full; /* preserve pixel range by default */ sws_setColorspaceDetails(scale->sws, inv_table, in_full, table, out_full, -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 02/13] avcodec: add extended AVCodec color metadata
From: Niklas Haas
This is motivated primarily by a desire for YUVJ removal, which will
require signalling the supported color ranges as part of the codec
capabilities. But since we're here anyway, we might as well add all of
the metadata, which I foresee seeing more use in the future (e.g.
automatic conversion from HDR to SDR when encoding to formats that don't
support AVCOL_TRC_SMPTE2084, ...)
---
doc/APIchanges | 4
libavcodec/codec.h | 7 +++
libavcodec/version.h | 4 ++--
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 9b109e6fa7..f91e855e70 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,10 @@ The last version increases of all libraries were on 2023-02-09
API changes, most recent first:
+2023-10-xx - xx - lavc 60.23.100 - avcodec.h
+ Add AVCodec.csps, AVCodec.color_ranges, AVCodec.chroma_locs,
AVCodec.primaries,
+ AVCodec.trcs.
+
2023-10-06 - xx - lavc 60.30.101 - avcodec.h
AVCodecContext.coded_side_data may now be used during decoding, to be set
by user before calling avcodec_open2() for initialization.
diff --git a/libavcodec/codec.h b/libavcodec/codec.h
index 8034f1a53c..5bc8f21868 100644
--- a/libavcodec/codec.h
+++ b/libavcodec/codec.h
@@ -235,6 +235,13 @@ typedef struct AVCodec {
* Array of supported channel layouts, terminated with a zeroed layout.
*/
const AVChannelLayout *ch_layouts;
+
+/* Extended colorspace support metadata */
+const enum AVColorSpace *csps; ///< array of supported
color spaces, or NULL if unknown, array is terminated by AVCOL_SPC_UNSPECIFIED
+const enum AVColorRange *color_ranges; ///< array of supported
color ranges, or NULL if unknown, array is terminated by 0
+const enum AVChromaLocation *chroma_locs; ///< array of supported
chroma locations, or NULL if unknown, array is terminated by 0
+const enum AVColorPrimaries *primaries; ///< array of supported
color primaries, or NULL if unknown, array is terminated by 0
+const enum AVColorTransferCharacteristic *trcs; ///< array of supported
transfer characteristics, or NULL if known, array is terminated by 0
} AVCodec;
/**
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 6b46100aae..497389d3f3 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,8 +29,8 @@
#include "version_major.h"
-#define LIBAVCODEC_VERSION_MINOR 30
-#define LIBAVCODEC_VERSION_MICRO 102
+#define LIBAVCODEC_VERSION_MINOR 31
+#define LIBAVCODEC_VERSION_MICRO 100
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 03/13] fftools/ffmpeg_filter: auto-convert range if needed
From: Niklas Haas
To convert between color ranges, if needed by the codec properties. We
momentarily duplicate the mjpeg strictness logic to also enfoce full
range. This duplication will be cleaned up in the next commit.
Due to avcodec_open2 being called after ofilter_bind_ost, we need to
look up the eventual encoder options from the options dictionary
directly, following the same design as the "strict" option.
---
fftools/ffmpeg_filter.c | 61 +++--
1 file changed, 52 insertions(+), 9 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index c738fc3397..acdfa72043 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -169,6 +169,7 @@ typedef struct OutputFilterPriv {
int width, height;
int sample_rate;
AVChannelLayout ch_layout;
+enum AVColorRange range;
// time base in which the output is sent to our downstream
// does not need to match the filtersink's timebase
@@ -184,6 +185,7 @@ typedef struct OutputFilterPriv {
const int *formats;
const AVChannelLayout *ch_layouts;
const int *sample_rates;
+const enum AVColorRange *ranges;
AVRational enc_timebase;
// offset for output timestamps, in AV_TIME_BASE_Q
@@ -368,6 +370,9 @@ DEF_CHOOSE_FORMAT(sample_fmts, enum AVSampleFormat, format,
formats,
DEF_CHOOSE_FORMAT(sample_rates, int, sample_rate, sample_rates, 0,
"%d", )
+DEF_CHOOSE_FORMAT(out_range, enum AVColorRange, range, ranges,
+ AVCOL_RANGE_UNSPECIFIED, "%s", av_color_range_name);
+
static void choose_channel_layouts(OutputFilterPriv *ofp, AVBPrint *bprint)
{
if (av_channel_layout_check(&ofp->ch_layout)) {
@@ -662,6 +667,17 @@ static int set_channel_layout(OutputFilterPriv *f,
OutputStream *ost)
return 0;
}
+static int ost_opt_int(OutputStream *ost, const char *name, int defval)
+{
+const AVDictionaryEntry *e = av_dict_get(ost->encoder_opts, name, NULL, 0);
+if (e) {
+const AVOption *o = av_opt_find(ost->enc_ctx, e->key, NULL, 0, 0);
+av_assert0(o);
+av_opt_eval_int(ost->enc_ctx, o, e->value, &defval);
+}
+return defval;
+}
+
int ofilter_bind_ost(OutputFilter *ofilter, OutputStream *ost)
{
const OutputFile *of = output_files[ost->file_index];
@@ -669,6 +685,7 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream
*ost)
FilterGraph *fg = ofilter->graph;
FilterGraphPriv *fgp = fgp_from_fg(fg);
const AVCodec *c = ost->enc_ctx->codec;
+enum AVColorRange color_range;
av_assert0(!ofilter->ost);
@@ -682,6 +699,26 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream
*ost)
case AVMEDIA_TYPE_VIDEO:
ofp->width = ost->enc_ctx->width;
ofp->height = ost->enc_ctx->height;
+color_range = ost_opt_int(ost, "color_range",
ost->enc_ctx->color_range);
+if (color_range != AVCOL_RANGE_UNSPECIFIED) {
+ofp->range = color_range;
+} else {
+ofp->ranges = c->color_ranges;
+
+// MJPEG encoder exports a full list of supported pixel formats,
+// but the full-range ones are experimental-only.
+// Restrict the auto-conversion list unless -strict experimental
+// has been specified.
+if (!strcmp(c->name, "mjpeg")) {
+static const enum AVColorRange mjpeg_ranges[] =
+{ AVCOL_RANGE_JPEG, AVCOL_RANGE_UNSPECIFIED };
+
+int strict_val = ost->enc_ctx->strict_std_compliance;
+strict_val = ost_opt_int(ost, "strict", strict_val);
+if (strict_val > FF_COMPLIANCE_UNOFFICIAL)
+ofp->ranges = mjpeg_ranges;
+}
+}
if (ost->enc_ctx->pix_fmt != AV_PIX_FMT_NONE) {
ofp->format = ost->enc_ctx->pix_fmt;
} else {
@@ -1149,6 +1186,7 @@ static int configure_output_video_filter(FilterGraph *fg,
OutputFilter *ofilter,
OutputFilterPriv *ofp = ofp_from_ofilter(ofilter);
OutputStream *ost = ofilter->ost;
OutputFile*of = output_files[ost->file_index];
+FilterGraphPriv *fgp = fgp_from_fg(fg);
AVFilterContext *last_filter = out->filter_ctx;
AVBPrint bprint;
int pad_idx = out->pad_idx;
@@ -1164,22 +1202,27 @@ static int configure_output_video_filter(FilterGraph
*fg, OutputFilter *ofilter,
if (ret < 0)
return ret;
-if ((ofp->width || ofp->height) && ofilter->ost->autoscale) {
-char args[255];
+av_bprint_init(&bprint, 0, AV_BPRINT_SIZE_UNLIMITED);
+if ((ofp->width || ofp->height) && ofilter->ost->autoscale)
+av_bprintf(&bprint, "w=%d:h=%d:", ofp->width, ofp->height);
+if (!fgp->disable_conversions)
+choose_out_range(ofp, &bprint);
+if (bprint.len) {
AVFilterContext *filter;
const AVDictionaryEntry *e = NULL;
-snprintf(args, sizeof(args), "%d:%d",
- ofp->wi
[FFmpeg-devel] [PATCH v2 04/13] lavfi/vf_colorspace: support prim/trc/csp passthrough
From: Niklas Haas
Setting the output range/primaries/colorspace to unspecified now infers
the value from the input signal. If the input signal also has unknown
prim/trc, and no specific output is requested, enable passthrough mode.
As a technical implementation detail, define a static const sentinel
struct to represent "unknown" values. This is to avoid reconfiguring the
filter on every frame (which is guarded by s->out_primaries etc. being
NULL), as well as make the memcmp NOOP check succeed.
---
libavfilter/vf_colorspace.c | 71 -
1 file changed, 30 insertions(+), 41 deletions(-)
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index 2a30434401..5ab5266ef0 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -442,29 +442,23 @@ static int create_filtergraph(AVFilterContext *ctx,
if (s->user_iprm != AVCOL_PRI_UNSPECIFIED)
s->in_prm = s->user_iprm;
s->in_primaries = av_csp_primaries_desc_from_id(s->in_prm);
-if (!s->in_primaries) {
+s->out_prm = out->color_primaries;
+s->out_primaries = av_csp_primaries_desc_from_id(s->out_prm);
+if (s->out_prm == AVCOL_PRI_UNSPECIFIED || s->fast_mode) {
+static const AVColorPrimariesDesc unknown = {0};
+s->in_primaries = s->out_primaries = &unknown; /* force
passthrough */
+} else if (!s->in_primaries) {
av_log(ctx, AV_LOG_ERROR,
"Unsupported input primaries %d (%s)\n",
s->in_prm, av_color_primaries_name(s->in_prm));
return AVERROR(EINVAL);
-}
-s->out_prm = out->color_primaries;
-s->out_primaries = av_csp_primaries_desc_from_id(s->out_prm);
-if (!s->out_primaries) {
-if (s->out_prm == AVCOL_PRI_UNSPECIFIED) {
-if (s->user_all == CS_UNSPECIFIED) {
-av_log(ctx, AV_LOG_ERROR, "Please specify output
primaries\n");
-} else {
-av_log(ctx, AV_LOG_ERROR,
- "Unsupported output color property %d\n",
s->user_all);
-}
-} else {
-av_log(ctx, AV_LOG_ERROR,
- "Unsupported output primaries %d (%s)\n",
- s->out_prm, av_color_primaries_name(s->out_prm));
-}
+} else if (!s->out_primaries) {
+av_log(ctx, AV_LOG_ERROR,
+ "Unsupported output primaries %d (%s)\n",
+ s->out_prm, av_color_primaries_name(s->out_prm));
return AVERROR(EINVAL);
}
+
s->lrgb2lrgb_passthrough = !memcmp(s->in_primaries, s->out_primaries,
sizeof(*s->in_primaries));
if (!s->lrgb2lrgb_passthrough) {
@@ -505,38 +499,33 @@ static int create_filtergraph(AVFilterContext *ctx,
if (s->user_itrc != AVCOL_TRC_UNSPECIFIED)
s->in_trc = s->user_itrc;
s->in_txchr = get_transfer_characteristics(s->in_trc);
-if (!s->in_txchr) {
-av_log(ctx, AV_LOG_ERROR,
- "Unsupported input transfer characteristics %d (%s)\n",
- s->in_trc, av_color_transfer_name(s->in_trc));
-return AVERROR(EINVAL);
-}
}
if (!s->out_txchr) {
av_freep(&s->lin_lut);
s->out_trc = out->color_trc;
s->out_txchr = get_transfer_characteristics(s->out_trc);
-if (!s->out_txchr) {
-if (s->out_trc == AVCOL_TRC_UNSPECIFIED) {
-if (s->user_all == CS_UNSPECIFIED) {
-av_log(ctx, AV_LOG_ERROR,
- "Please specify output transfer characteristics\n");
-} else {
-av_log(ctx, AV_LOG_ERROR,
- "Unsupported output color property %d\n",
s->user_all);
-}
-} else {
-av_log(ctx, AV_LOG_ERROR,
- "Unsupported output transfer characteristics %d (%s)\n",
- s->out_trc, av_color_transfer_name(s->out_trc));
-}
-return AVERROR(EINVAL);
-}
}
-s->rgb2rgb_passthrough = s->fast_mode || (s->lrgb2lrgb_passthrough &&
- !memcmp(s->in_txchr, s->out_txchr,
sizeof(*s->in_txchr)));
+if ((s->out_trc == AVCOL_TRC_UNSPECIFIED && s->lrgb2lrgb_passthrough) ||
s->fast_mode) {
+static const struct TransferCharacteristics unknown = {0};
+s->in_txchr = s->out_txchr = &unknown; /* force passthrough */
+} else if (!s->in_txchr) {
+av_log(ctx, AV_LOG_ERROR,
+ "Unsupported input transfer characteristics %d (%s)\n",
+ s->in_trc, av_color_transfer_name(s->in_trc));
+return AVERROR(EINVAL);
+} else if (s->out_trc == AVCOL_TRC_UNSPECIFIED) {
+s->out_txchr = s->in_txchr;
+} else if (!s->out
[FFmpeg-devel] [PATCH v2 13/13] avutil/pixdesc: remove old yuvj pixel format check
From: Niklas Haas
These no longer exist.
---
libavutil/pixdesc.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index d640624aaf..75b1ae3cea 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2977,8 +2977,7 @@ enum AVPixelFormat av_pix_fmt_swap_endianness(enum
AVPixelFormat pix_fmt)
#define FF_COLOR_NA -1
#define FF_COLOR_RGB 0 /**< RGB color space */
#define FF_COLOR_GRAY 1 /**< gray color space */
-#define FF_COLOR_YUV 2 /**< YUV color space. 16 <= Y <= 235, 16 <= U, V
<= 240 */
-#define FF_COLOR_YUV_JPEG 3 /**< YUV color space. 0 <= Y <= 255, 0 <= U, V <=
255 */
+#define FF_COLOR_YUV 2 /**< YUV color space */
#define FF_COLOR_XYZ 4
#define pixdesc_has_alpha(pixdesc) \
@@ -2993,9 +2992,6 @@ static int get_color_type(const AVPixFmtDescriptor *desc)
{
return FF_COLOR_GRAY;
if (desc->name) {
-if (av_strstart(desc->name, "yuvj", NULL))
-return FF_COLOR_YUV_JPEG;
-
if (av_strstart(desc->name, "xyz", NULL))
return FF_COLOR_XYZ;
}
@@ -3135,12 +3131,6 @@ static int get_pix_fmt_score(enum AVPixelFormat
dst_pix_fmt,
if (src_color != FF_COLOR_YUV)
loss |= FF_LOSS_COLORSPACE;
break;
-case FF_COLOR_YUV_JPEG:
-if (src_color != FF_COLOR_YUV_JPEG &&
-src_color != FF_COLOR_YUV &&
-src_color != FF_COLOR_GRAY)
-loss |= FF_LOSS_COLORSPACE;
-break;
default:
/* fail safe test */
if (src_color != dst_color)
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 05/13] fftools/ffmpeg_filter: auto-insert colorspace filter
From: Niklas Haas
To convert between color space/transfer/primaries, if needed by the
codec properties. Libswscale can't handle this at the moment, but
fortunately there exists vf_colorspace which we can use unconditionally.
---
fftools/ffmpeg_filter.c | 65 +
1 file changed, 65 insertions(+)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index acdfa72043..41758ac2b5 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -170,6 +170,9 @@ typedef struct OutputFilterPriv {
int sample_rate;
AVChannelLayout ch_layout;
enum AVColorRange range;
+enum AVColorSpace csp;
+enum AVColorPrimaries prim;
+enum AVColorTransferCharacteristic trc;
// time base in which the output is sent to our downstream
// does not need to match the filtersink's timebase
@@ -186,6 +189,9 @@ typedef struct OutputFilterPriv {
const AVChannelLayout *ch_layouts;
const int *sample_rates;
const enum AVColorRange *ranges;
+const enum AVColorSpace *csps;
+const enum AVColorPrimaries *prims;
+const enum AVColorTransferCharacteristic *trcs;
AVRational enc_timebase;
// offset for output timestamps, in AV_TIME_BASE_Q
@@ -373,6 +379,15 @@ DEF_CHOOSE_FORMAT(sample_rates, int, sample_rate,
sample_rates, 0,
DEF_CHOOSE_FORMAT(out_range, enum AVColorRange, range, ranges,
AVCOL_RANGE_UNSPECIFIED, "%s", av_color_range_name);
+DEF_CHOOSE_FORMAT(space, enum AVColorSpace, csp, csps,
+ AVCOL_SPC_UNSPECIFIED, "%s", av_color_space_name);
+
+DEF_CHOOSE_FORMAT(primaries, enum AVColorPrimaries, prim, prims,
+ AVCOL_PRI_UNSPECIFIED, "%s", av_color_primaries_name);
+
+DEF_CHOOSE_FORMAT(trc, enum AVColorTransferCharacteristic, trc, trcs,
+ AVCOL_TRC_UNSPECIFIED, "%s", av_color_transfer_name);
+
static void choose_channel_layouts(OutputFilterPriv *ofp, AVBPrint *bprint)
{
if (av_channel_layout_check(&ofp->ch_layout)) {
@@ -599,6 +614,9 @@ static OutputFilter *ofilter_alloc(FilterGraph *fg)
ofilter = &ofp->ofilter;
ofilter->graph= fg;
ofp->format = -1;
+ofp->csp = AVCOL_SPC_UNSPECIFIED;
+ofp->prim = AVCOL_PRI_UNSPECIFIED;
+ofp->trc = AVCOL_TRC_UNSPECIFIED;
ofilter->last_pts = AV_NOPTS_VALUE;
return ofilter;
@@ -686,6 +704,9 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream
*ost)
FilterGraphPriv *fgp = fgp_from_fg(fg);
const AVCodec *c = ost->enc_ctx->codec;
enum AVColorRange color_range;
+enum AVColorPrimaries color_primaries;
+enum AVColorTransferCharacteristic color_trc;
+enum AVColorSpace color_space;
av_assert0(!ofilter->ost);
@@ -700,6 +721,9 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream
*ost)
ofp->width = ost->enc_ctx->width;
ofp->height = ost->enc_ctx->height;
color_range = ost_opt_int(ost, "color_range",
ost->enc_ctx->color_range);
+color_primaries = ost_opt_int(ost, "color_primaries",
ost->enc_ctx->color_primaries);
+color_trc = ost_opt_int(ost, "color_trc",
ost->enc_ctx->color_trc);
+color_space = ost_opt_int(ost, "colorspace",
ost->enc_ctx->colorspace);
if (color_range != AVCOL_RANGE_UNSPECIFIED) {
ofp->range = color_range;
} else {
@@ -719,6 +743,21 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream
*ost)
ofp->ranges = mjpeg_ranges;
}
}
+if (color_primaries != AVCOL_PRI_UNSPECIFIED) {
+ofp->prim = color_primaries;
+} else {
+ofp->prims = c->primaries;
+}
+if (color_trc != AVCOL_TRC_UNSPECIFIED) {
+ofp->trc = color_trc;
+} else {
+ofp->trcs = c->trcs;
+}
+if (color_space != AVCOL_SPC_UNSPECIFIED) {
+ofp->csp = color_space;
+} else {
+ofp->csps = c->csps;
+}
if (ost->enc_ctx->pix_fmt != AV_PIX_FMT_NONE) {
ofp->format = ost->enc_ctx->pix_fmt;
} else {
@@ -1231,6 +1270,32 @@ static int configure_output_video_filter(FilterGraph
*fg, OutputFilter *ofilter,
pad_idx = 0;
}
+if (!fgp->disable_conversions) {
+av_bprint_init(&bprint, 0, AV_BPRINT_SIZE_UNLIMITED);
+choose_space(ofp, &bprint);
+choose_primaries(ofp, &bprint);
+choose_trc(ofp, &bprint);
+if (!av_bprint_is_complete(&bprint))
+return AVERROR(ENOMEM);
+if (bprint.len) {
+AVFilterContext *filter;
+
+snprintf(name, sizeof(name), "csp_out_%d_%d",
+ ost->file_index, ost->index);
+ret = avfilter_graph_create_filter(&filter,
+
avfilter_get_by_name("colorspace"),
+ name, bprin
[FFmpeg-devel] [PATCH v2 06/13] avcodec/encode: enforce AVCodec capabilities at encode time
From: Niklas Haas
In general, the logic is always the same: if the codec supports only a
single format, enforce it if possible. Otherwise, throw an error when
an incompatible format is thrown.
To preserve backwards compatibility and make this check less pedantic
than it needs to be, always consider 'AVCOL_*_UNKNOWN/UNSPECIFIED' a
valid value. That way, we will only throw an error if the user
explicitly set a color value that we explicitly know is unsupported.
---
libavcodec/encode.c | 102
1 file changed, 102 insertions(+)
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index a436be2657..f22b17f33e 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -611,6 +611,108 @@ static int encode_preinit_video(AVCodecContext *avctx)
avctx->color_range = AVCOL_RANGE_JPEG;
}
+if (c->csps) {
+for (i = 0; c->csps[i] != AVCOL_SPC_UNSPECIFIED; i++)
+if (avctx->colorspace == c->csps[i])
+break;
+if (c->csps[i] == AVCOL_SPC_UNSPECIFIED) {
+av_log(avctx, AV_LOG_ERROR,
+ "Specified colorspace %s is not supported by the %s
encoder.\n",
+ av_color_space_name(avctx->colorspace), c->name);
+av_log(avctx, AV_LOG_ERROR, "Supported colorspaces:\n");
+for (int p = 0; c->csps[p] != AVCOL_SPC_UNSPECIFIED; p++) {
+av_log(avctx, AV_LOG_ERROR, " %s\n",
+ av_color_space_name(c->csps[p]));
+}
+return AVERROR(EINVAL);
+}
+}
+
+if (c->color_ranges) {
+for (i = 0; c->color_ranges[i] != AVCOL_RANGE_UNSPECIFIED; i++) {
+if (avctx->color_range == c->color_ranges[i])
+break;
+}
+if (c->color_ranges[i] == AVCOL_RANGE_UNSPECIFIED) {
+if (i == 1 && !avctx->color_range) {
+avctx->color_range = c->color_ranges[0];
+} else if (avctx->color_range) {
+av_log(avctx, AV_LOG_ERROR,
+ "Specified color range %s is not supported by the %s
encoder.\n",
+ av_color_range_name(avctx->color_range), c->name);
+av_log(avctx, AV_LOG_ERROR, "Supported color ranges:\n");
+for (int p = 0; c->color_ranges[p] != AVCOL_RANGE_UNSPECIFIED;
p++) {
+av_log(avctx, AV_LOG_ERROR, " %s\n",
+ av_color_range_name(c->color_ranges[p]));
+}
+return AVERROR(EINVAL);
+}
+}
+}
+
+if (c->chroma_locs) {
+for (i = 0; c->chroma_locs[i] != AVCHROMA_LOC_UNSPECIFIED; i++)
+if (avctx->chroma_sample_location == c->chroma_locs[i])
+break;
+if (c->chroma_locs[i] == AVCHROMA_LOC_UNSPECIFIED) {
+if (i == 1 && !avctx->chroma_sample_location) {
+avctx->chroma_sample_location = c->chroma_locs[0];
+} else if (avctx->chroma_sample_location) {
+av_log(avctx, AV_LOG_ERROR,
+ "Specified chroma sample location %s is not supported
by the %s encoder.\n",
+ av_chroma_location_name(avctx->chroma_sample_location),
c->name);
+av_log(avctx, AV_LOG_ERROR, "Supported chroma sample
locations:\n");
+for (int p = 0; c->chroma_locs[p] != AVCHROMA_LOC_UNSPECIFIED;
p++) {
+av_log(avctx, AV_LOG_ERROR, " %s\n",
+ av_chroma_location_name(c->chroma_locs[p]));
+}
+return AVERROR(EINVAL);
+}
+}
+}
+
+if (c->primaries) {
+for (i = 0; c->primaries[i] != AVCOL_PRI_UNSPECIFIED; i++)
+if (avctx->color_primaries == c->primaries[i])
+break;
+if (c->primaries[i] == AVCOL_PRI_UNSPECIFIED) {
+if (i == 1 && !avctx->color_primaries) {
+avctx->color_primaries = c->primaries[0];
+} else if (avctx->color_primaries) {
+av_log(avctx, AV_LOG_ERROR,
+ "Specified color primaries %s is not supported by the
%s encoder.\n",
+ av_color_primaries_name(avctx->color_primaries),
c->name);
+av_log(avctx, AV_LOG_ERROR, "Supported color primaries:\n");
+for (int p = 0; c->primaries[p] != AVCOL_PRI_UNSPECIFIED; p++)
{
+av_log(avctx, AV_LOG_ERROR, " %s\n",
+ av_color_primaries_name(c->primaries[p]));
+}
+return AVERROR(EINVAL);
+}
+}
+}
+
+if (c->trcs) {
+for (i = 0; c->trcs[i] != AVCOL_TRC_UNSPECIFIED; i++)
+if (avctx->color_trc == c->trcs[i])
+break;
+if (c->trcs[i] == AVCOL_TRC_UNSPECIFIED) {
+if (i == 1 && !avctx->color_trc) {
+avctx->color_trc = c->trcs[0];
+
[FFmpeg-devel] [PATCH v2 07/13] tests/fate: force MPEG range for rawvideo tests
From: Niklas Haas
The input file is MPEG range, so we should also encode to MPEG range
before comparing against it. This bug was avoided in the past because
JPEG range YUV inputs were tagged as YUVJ, which resulted in an
automatic conversion to PC range by default.
After YUVJ removal, we will need to explicitly specify that we want MPEG
range, since rawvideo does not care (or signal) if the output is JPEG or
MPEG range.
Affects both vsynth and owdenoise.
---
tests/fate/filter-video.mak | 2 +-
tests/fate/vcodec.mak | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 789ec6414c..3aef652244 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -2,7 +2,7 @@
VIDEO_FILTER = $(call ALLYES, $(1:%=%_FILTER) $(2) FILE_PROTOCOL
IMAGE2_DEMUXER PGMYUV_DECODER RAWVIDEO_ENCODER NUT_MUXER MD5_PROTOCOL)
FATE_FILTER_SAMPLES-$(call FILTERDEMDECENCMUX, PERMS OWDENOISE TRIM SCALE,
SMJPEG, MJPEG, RAWVIDEO, RAWVIDEO, PIPE_PROTOCOL) +=
fate-filter-owdenoise-sample
-fate-filter-owdenoise-sample: CMD = ffmpeg -auto_conversion_filters -idct
simple -i $(TARGET_SAMPLES)/smjpeg/scenwin.mjpg -vf
"trim=duration=0.5,perms=random,owdenoise=10:20:20:enable=not(between(t\,0.2\,1.2))"
-an -f rawvideo -
+fate-filter-owdenoise-sample: CMD = ffmpeg -auto_conversion_filters -idct
simple -i $(TARGET_SAMPLES)/smjpeg/scenwin.mjpg -vf
"trim=duration=0.5,perms=random,owdenoise=10:20:20:enable=not(between(t\,0.2\,1.2))"
-an -f rawvideo -color_range mpeg -
fate-filter-owdenoise-sample: REF =
$(SAMPLES)/filter-reference/owdenoise-scenwin.raw
fate-filter-owdenoise-sample: CMP_TARGET = 1
fate-filter-owdenoise-sample: FUZZ = 3539
diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak
index 45ed88da96..f7f474c146 100644
--- a/tests/fate/vcodec.mak
+++ b/tests/fate/vcodec.mak
@@ -6,7 +6,7 @@ fate-vsynth%: CODEC = $(word 3, $(subst -, ,$(@)))
fate-vsynth%: FMT = avi
fate-vsynth%: DEFAULT_SIZE = -s 352x288
fate-vsynth3-%: DEFAULT_SIZE = -s $(FATEW)x$(FATEH)
-fate-vsynth%: CMD = enc_dec "rawvideo $(DEFAULT_SIZE) -pix_fmt yuv420p
$(RAWDECOPTS)" $(SRC) $(FMT) "-c $(CODEC) $(ENCOPTS)" rawvideo "-pix_fmt
yuv420p -vsync passthrough $(DECOPTS)" "" "" ${TWOPASS}
+fate-vsynth%: CMD = enc_dec "rawvideo $(DEFAULT_SIZE) -pix_fmt yuv420p
$(RAWDECOPTS)" $(SRC) $(FMT) "-c $(CODEC) $(ENCOPTS)" rawvideo "-pix_fmt
yuv420p -color_range mpeg -vsync passthrough $(DECOPTS)" "" "" ${TWOPASS}
fate-vsynth%: CMP_UNIT = 1
fate-vsynth%: REF = $(SRC_PATH)/tests/ref/vsynth/$(@:fate-%=%)
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 08/13] tests/fate: allow conversion filters in jpg-icc test
From: Niklas Haas This requires conversion from full to limited range JPEG, as mjpeg only accepts limited range (without extra strictness options). The old solution to this problem was to manually insert -vf scale, but this does not work in the absencee of YUVJ as vf_scale cannot (yet) negotiate the required colorspace range. The simple solution is to enable auto-conversion filters, which allows fftools to insert the correct conversion filter. --- tests/fate/image.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/fate/image.mak b/tests/fate/image.mak index 400199c28a..22c809be36 100644 --- a/tests/fate/image.mak +++ b/tests/fate/image.mak @@ -358,7 +358,7 @@ FATE_JPG += fate-jpg-rgb-5 fate-jpg-rgb-5: CMD = framecrc -idct simple -i $(TARGET_SAMPLES)/jpg/jpg-8930-5.jpg FATE_JPG_TRANSCODE-$(call TRANSCODE, MJPEG, MJPEG IMAGE_JPEG_PIPE, IMAGE_PNG_PIPE_DEMUXER PNG_DECODER SCALE_FILTER) += fate-jpg-icc -fate-jpg-icc: CMD = transcode png_pipe $(TARGET_SAMPLES)/png1/lena-int_rgb24.png mjpeg "-vf scale" "" "-show_frames" +fate-jpg-icc: CMD = transcode png_pipe $(TARGET_SAMPLES)/png1/lena-int_rgb24.png mjpeg "-auto_conversion_filters" "" "-show_frames" FATE_JPG-$(call DEMDEC, IMAGE2, MJPEG) += $(FATE_JPG) FATE_IMAGE_FRAMECRC += $(FATE_JPG-yes) -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 09/13] lavc: set color_ranges for YUVJ-only codecs
From: Niklas Haas
Only affects amv and roqvideo. (mjpeg is handled separately by fftools)
---
libavcodec/mjpegenc.c| 3 +++
libavcodec/roqvideoenc.c | 2 ++
2 files changed, 5 insertions(+)
diff --git a/libavcodec/mjpegenc.c b/libavcodec/mjpegenc.c
index 508772987f..c827a47e59 100644
--- a/libavcodec/mjpegenc.c
+++ b/libavcodec/mjpegenc.c
@@ -685,6 +685,9 @@ const FFCodec ff_amv_encoder = {
.p.pix_fmts = (const enum AVPixelFormat[]) {
AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_NONE
},
+.p.color_ranges = (const enum AVColorRange[]) {
+AVCOL_RANGE_JPEG, AVCOL_RANGE_UNSPECIFIED
+},
.p.priv_class = &amv_class,
.p.capabilities = AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
};
diff --git a/libavcodec/roqvideoenc.c b/libavcodec/roqvideoenc.c
index 0933abf4f9..b584ee1142 100644
--- a/libavcodec/roqvideoenc.c
+++ b/libavcodec/roqvideoenc.c
@@ -1127,6 +1127,8 @@ const FFCodec ff_roq_encoder = {
.close= roq_encode_end,
.p.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUVJ444P,
AV_PIX_FMT_NONE },
+.p.color_ranges = (const enum AVColorRange[]){ AVCOL_RANGE_JPEG,
+
AVCOL_RANGE_UNSPECIFIED },
.p.priv_class = &roq_class,
.caps_internal= FF_CODEC_CAP_INIT_CLEANUP,
};
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 11/13] swscale/utils: simplify JPEG handling function
From: Niklas Haas
YUVJ no longer exists, so this is now just a check for luma-only
formats, and no longer needs to mutate the pixel format.
---
libswscale/utils.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index c179ac05b5..0a4b969fec 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -920,9 +920,9 @@ static void fill_xyztables(struct SwsContext *c)
}
}
-static int handle_jpeg(enum AVPixelFormat *format)
+static int is_luma_only(enum AVPixelFormat format)
{
-switch (*format) {
+switch (format) {
case AV_PIX_FMT_GRAY8:
case AV_PIX_FMT_YA8:
case AV_PIX_FMT_GRAY9LE:
@@ -2018,7 +2018,6 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter
*srcFilter,
SwsFilter *dstFilter)
{
static AVOnce rgb2rgb_once = AV_ONCE_INIT;
-enum AVPixelFormat src_format, dst_format;
int ret;
c->frame_src = av_frame_alloc();
@@ -2029,13 +2028,8 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter
*srcFilter,
if (ff_thread_once(&rgb2rgb_once, ff_sws_rgb2rgb_init) != 0)
return AVERROR_UNKNOWN;
-src_format = c->srcFormat;
-dst_format = c->dstFormat;
-c->srcRange |= handle_jpeg(&c->srcFormat);
-c->dstRange |= handle_jpeg(&c->dstFormat);
-
-if (src_format != c->srcFormat || dst_format != c->dstFormat)
-av_log(c, AV_LOG_WARNING, "deprecated pixel format used, make sure you
did set range correctly\n");
+c->srcRange |= is_luma_only(c->srcFormat);
+c->dstRange |= is_luma_only(c->dstFormat);
if (c->nb_threads != 1) {
ret = context_init_threaded(c, srcFilter, dstFilter);
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 12/13] tests/fate: remove unused YUVJ ref files
From: Niklas Haas --- tests/ref/fate/filter-pixdesc-yuvj411p | 1 - tests/ref/fate/filter-pixdesc-yuvj420p | 1 - tests/ref/fate/filter-pixdesc-yuvj422p | 1 - tests/ref/fate/filter-pixdesc-yuvj440p | 1 - tests/ref/fate/filter-pixdesc-yuvj444p | 1 - tests/ref/pixfmt/yuvj420p | 2 -- tests/ref/pixfmt/yuvj422p | 2 -- tests/ref/pixfmt/yuvj440p | 2 -- tests/ref/pixfmt/yuvj444p | 2 -- 9 files changed, 13 deletions(-) delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj411p delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj420p delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj422p delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj440p delete mode 100644 tests/ref/fate/filter-pixdesc-yuvj444p delete mode 100644 tests/ref/pixfmt/yuvj420p delete mode 100644 tests/ref/pixfmt/yuvj422p delete mode 100644 tests/ref/pixfmt/yuvj440p delete mode 100644 tests/ref/pixfmt/yuvj444p diff --git a/tests/ref/fate/filter-pixdesc-yuvj411p b/tests/ref/fate/filter-pixdesc-yuvj411p deleted file mode 100644 index 5dfc0dc4cd..00 --- a/tests/ref/fate/filter-pixdesc-yuvj411p +++ /dev/null @@ -1 +0,0 @@ -pixdesc-yuvj411pcac93399031ad86e8de0796b60b5bb8a diff --git a/tests/ref/fate/filter-pixdesc-yuvj420p b/tests/ref/fate/filter-pixdesc-yuvj420p deleted file mode 100644 index ad2f968a1f..00 --- a/tests/ref/fate/filter-pixdesc-yuvj420p +++ /dev/null @@ -1 +0,0 @@ -pixdesc-yuvj420p5244374882cf07c3cbcde71940caf8e5 diff --git a/tests/ref/fate/filter-pixdesc-yuvj422p b/tests/ref/fate/filter-pixdesc-yuvj422p deleted file mode 100644 index 5f80d585d6..00 --- a/tests/ref/fate/filter-pixdesc-yuvj422p +++ /dev/null @@ -1 +0,0 @@ -pixdesc-yuvj422p6c9722aa9e0c1b8f9d953efeb93dc318 diff --git a/tests/ref/fate/filter-pixdesc-yuvj440p b/tests/ref/fate/filter-pixdesc-yuvj440p deleted file mode 100644 index c98669285b..00 --- a/tests/ref/fate/filter-pixdesc-yuvj440p +++ /dev/null @@ -1 +0,0 @@ -pixdesc-yuvj440p34e6e86ca3ec4e6ef62d533aa2290e8f diff --git a/tests/ref/fate/filter-pixdesc-yuvj444p b/tests/ref/fate/filter-pixdesc-yuvj444p deleted file mode 100644 index 3e182fa6e2..00 --- a/tests/ref/fate/filter-pixdesc-yuvj444p +++ /dev/null @@ -1 +0,0 @@ -pixdesc-yuvj444pf67694103bb42d74742918adf9ea31c5 diff --git a/tests/ref/pixfmt/yuvj420p b/tests/ref/pixfmt/yuvj420p deleted file mode 100644 index 47a729ed45..00 --- a/tests/ref/pixfmt/yuvj420p +++ /dev/null @@ -1,2 +0,0 @@ -e176bd14185788110e055f945de7f95f *tests/data/pixfmt/yuvj420p.yuv -304128 tests/data/pixfmt/yuvj420p.yuv diff --git a/tests/ref/pixfmt/yuvj422p b/tests/ref/pixfmt/yuvj422p deleted file mode 100644 index 6ab97d59db..00 --- a/tests/ref/pixfmt/yuvj422p +++ /dev/null @@ -1,2 +0,0 @@ -472028e46a81c98d9b2477507def4723 *tests/data/pixfmt/yuvj422p.yuv -304128 tests/data/pixfmt/yuvj422p.yuv diff --git a/tests/ref/pixfmt/yuvj440p b/tests/ref/pixfmt/yuvj440p deleted file mode 100644 index 2beeae52c1..00 --- a/tests/ref/pixfmt/yuvj440p +++ /dev/null @@ -1,2 +0,0 @@ -4d8d402c45d913038d4b725396719111 *tests/data/pixfmt/yuvj440p.yuv -304128 tests/data/pixfmt/yuvj440p.yuv diff --git a/tests/ref/pixfmt/yuvj444p b/tests/ref/pixfmt/yuvj444p deleted file mode 100644 index 63fb813d4b..00 --- a/tests/ref/pixfmt/yuvj444p +++ /dev/null @@ -1,2 +0,0 @@ -c10442da177c9f1d12be3c53be6fa12c *tests/data/pixfmt/yuvj444p.yuv -304128 tests/data/pixfmt/yuvj444p.yuv -- 2.42.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] libavc/libx264: add support to propagate SSE values through encoder stats
On Fri, 2023-10-13 at 16:16 +0200, Anton Khirnov wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you can confirm the sender
> and know the content is safe.
>
>
>
> Quoting Carotti, Elias via ffmpeg-devel (2023-10-11 12:54:21)
> > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> > index 77a9f173b4..85bd870f5d 100644
> > --- a/libavcodec/libx264.c
> > +++ b/libavcodec/libx264.c
> > @@ -726,7 +726,39 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >
> > pkt->flags |= AV_PKT_FLAG_KEY*pic_out.b_keyframe;
> > if (ret) {
> > - ff_side_data_set_encoder_stats(pkt, (pic_out.i_qpplus1 -
> > 1) * FF_QP2LAMBDA, NULL, 0, pict_type);
> > + const AVPixFmtDescriptor *pix_desc =
> > av_pix_fmt_desc_get(csp_to_pixfmt(pic_out.img.i_csp));
>
> There's a problem here - we do not handle all values of i_csp.
> E.g. we have no equivalent of X264_CSP_NV12 | X264_CSP_HIGH_DEPTH,
> which
> x264 will use for YUV420P10 input.
>
> The best solution is probably to use AVCodecContext.pix_fmt and
> assume
> that x264 doesn't do any nontrivial (i.e. other than interleaving and
> such) pixel format transformations internally.
>
I see. Wouldn't not outputting the SSE values when csp_to_pixfmt()
returns AV_PIX_FMT_NONE work better?
That wouldn't be worse than it is today (meaning that right now we
don't get those values for any pix_fmt).
Anyway, I did as you suggested and used AVCodecContext.pix_fmt.
> >
> > + av_log(ctx, AV_LOG_DEBUG, "PSNR values from libx264:
> > %.3f %.3f %.3f.\n",
> > + pic_out.prop.f_psnr[0], pic_out.prop.f_psnr[1],
> > pic_out.prop.f_psnr[2]);
>
> In my tests libx264 prints these values by itself, so this seems
> redundant.
removed.
NICE SRL, viale Monte Grappa 3/5, 20124 Milano, Italia, Registro delle Imprese
di Milano Monza Brianza Lodi REA n. 2096882, Capitale Sociale: 10.329,14 EUR
i.v., Cod. Fisc. e P.IVA 01133050052, Societa con Socio Unico
From b702fcd76cf0626f75a941875f31add50d08894d Mon Sep 17 00:00:00 2001
From: Elias Carotti
Date: Fri, 15 Sep 2023 20:05:43 +0200
Subject: [PATCH] avcodec/libx264: Add the SSE computation for libx264.
Since libx264 only provides a per-frame per-channel PSNR, this is inverted to get back the SSE.
---
libavcodec/libx264.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 77a9f173b4..6ebe210039 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -726,7 +726,36 @@ FF_ENABLE_DEPRECATION_WARNINGS
pkt->flags |= AV_PKT_FLAG_KEY*pic_out.b_keyframe;
if (ret) {
-ff_side_data_set_encoder_stats(pkt, (pic_out.i_qpplus1 - 1) * FF_QP2LAMBDA, NULL, 0, pict_type);
+const AVPixFmtDescriptor *pix_desc = av_pix_fmt_desc_get(ctx->pix_fmt);
+int error_count = 0;
+int64_t *errors = NULL;
+int64_t sse[3] = {0};
+
+if (ctx->flags & AV_CODEC_FLAG_PSNR) {
+double scale[3] = { 1,
+(double)(1 << pix_desc->log2_chroma_h) * (1 << pix_desc->log2_chroma_w),
+(double)(1 << pix_desc->log2_chroma_h) * (1 << pix_desc->log2_chroma_w),
+};
+
+error_count = pix_desc->nb_components;
+
+for (int i = 0; i < pix_desc->nb_components; ++i) {
+double max_value = (double)(1 << pix_desc->comp[i].depth) - 1.0;
+double plane_size = ctx->width * (double)ctx->height / scale[i];
+
+/* psnr = 10 * log10(max_value * max_value / mse) */
+double mse = (max_value * max_value) / pow(10, pic_out.prop.f_psnr[i] / 10.0);
+
+/* SSE = MSE * width * height / scale -> because of possible chroma downsampling */
+sse[i] = (int64_t)floor(mse * plane_size + .5);
+};
+
+errors = sse;
+}
+
+ff_side_data_set_encoder_stats(pkt, (pic_out.i_qpplus1 - 1) * FF_QP2LAMBDA,
+ errors, error_count, pict_type);
+
if (wallclock)
ff_side_data_set_prft(pkt, wallclock);
}
--
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 v2 00/13] YUVJ removal
On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas wrote: > Changes since v1: > > - Remove unneeded patch (AVCodecContext.colorspace init) > - Merge auto-range conversion into auto-scale filter > - Replace vf_zscale by vf_colorspace in fftools > Why is this? I haven't checked what vf_colorspace supports in a hot second, but iirc zscale can handle non linear spaces better and hdr conversion If it's because it's a built in filter, do you think we could first check for zscale presence and fallback to colorspace? - Add some miscellaneous fixes for various FATE tests > - Clean up some additional vestigiaul YUVJ remnants > -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] doc: add spi.txt
On Fri, Oct 13, 2023 at 12:53:34AM +0200, Stefano Sabatini wrote: > On date Wednesday 2023-10-11 20:10:15 +0200, Michael Niedermayer wrote: > > This explains how to request refunds and what can be funded by SPI > > --- > > doc/spi.txt | 50 ++ > > 1 file changed, 50 insertions(+) > > create mode 100644 doc/spi.txt > > > > diff --git a/doc/spi.txt b/doc/spi.txt > > new file mode 100644 > > index 00..7d85de8f09 > > --- /dev/null > > +++ b/doc/spi.txt > > @@ -0,0 +1,50 @@ > > Add a short introduction about SPI here. > > SPI (Software in the Public Interest) is a non-profit corporation > registered in the state of New York founded to act as a fiscal sponsor > for organizations that develop open source software and hardware. For > details check here: > https://www.spi-inc.org/ > > FFmpeg is an SPI associated project and donations can be collected and > handled by SPI on behalf of FFmpeg. For details about the association > check here: > https://www.spi-inc.org/projects/ffmpeg/ > > > > +How to request refunds from SPI: > > + > > +Send a mail to ffmpeg-devel with [REFUND-REQUEST] in the subject > > Expanding on this: > > Send a mail to ffmpeg-devel with the [REFUND-REQUEST] tag and a short > description of the refund topic in the subject. > > In the mail, you also need to provide the amount to be refunded, with > a short description of how the money was spent. > > There is no need and is not recommeded to send receipts when sending > the refund request on the ffmpeg-devel mailing-list, but they are > usually needed later when the request is approved and the refund > request is sent to SPI: > https://www.spi-inc.org/treasurer/reimbursement-form/ > > > + > > + > > +What can be payed by SPI: > > +- > > > +FFmpeg money collected at SPI can be used for any purpose which is OK by > > OK => fine/compliant/in line with > > > +501(c)3 nonprofit rules, and within our mission (Free & OSS software). > > + > > +In practice we frequently payed for Travel and Hardware. > > > +For other things, it is recommanded to disscuss them beforehand > > recommended .. to discuss > > > +on ffmpeg-devel and if the community agrees to fund them, also with > > +SPI through stefano before starting with anything. > > My take on this: > > For other refund expenses or sponsorships, it is recommended to > discuss them beforehand on ffmpeg-devel. If there is a community > agreement on their approval, the current FFmpeg liaison will followup > to get an approval on the SPI side. > > > + > > + > > +Is it possible to fund active development by SPI: > > +(the texts below have been taken from multiple > > + replies FFmpeg has received from SPI, they have been edited > > + so that "I" was replaced by "SPI" in some cases.) > > +- > > +Paying for development *does* require substantial > > > +additional paperwork, but it is not prohibitied. > > prohibited > > > + > > > +Several SPI projects pay contractors for development > > +efforts. SPI needs a contract in place which describes the work to be > > +done. There are also various things SPI needs to check (e.g. are they a > > +US person or not, as with GSoC mentor payments; are they really a > > +contractor and not a employee). > > + > > +SPI can't deal with employment at the moment because that involves a > > +lot of work, like health insurance, tax withholding, etc. Contractors > > +are easier because they have to take care of that themselves; Whether > > +someone is a contractor vs employee depends on various factors (that > > +of course are different in every country) and can be disputed (see > > +e.g. the debate about whether Uber drivers are employees); SPI has a > > +questionnaire about their circumstances.) > > + > > +Unfortunately, there's no one-size-fits all when dealing with contractors. > > +As already mentioned, without knowing the contributor's country > > + > > +SPI does have templates, but they depend on the contractors country. If > > it's > > +US, Australia, France and a couple others SPI could provide them next day, > > +otherwise SPI would need to ask their attorney to draft one, which would > > +take some time > > + > > +Also, SPI has two models, MSA (which transfers ownership) and CSA (which > > +grants a license instead). SPI usually sends the MSA (it's better for most > > +purposes), but for development purposes, some projects prefer that the > > +contractor retain ownership rights. > > This part is a useful resume of the past internal discussions, but at > the same time we never really went down to this road, so I'm not sure > moving this to the repo would be helpful from the operational point of > view. It's probably useful to clarify the current status quo with the > other developers though. > > About the placement of the text, given that this is an internal memo > intended for developers pr
Re: [FFmpeg-devel] [PATCH v2 02/13] avcodec: add extended AVCodec color metadata
On Fri, Oct 13, 2023 at 1:09 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > 2. It is based around the underlying assumption that the set of > permissible states (tupels) is a cartesian product of a set of color > spaces, a set of color ranges etc. This is wrong: E.g. VP9 disallows > limited-range RGB (it is syntactically impossible to set the color range > when using RGB color space). small note on VP9 and other color-constrained codecs, it's still always possible to set these parameters via the container, i.e. through the mp4 color box. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] vulkan_h264: fix long-term ref handling
h->long_ref isn't guaranteed to be contiguously filled. Use the approach
from both vaapi_h264 and vdpau_h264 which goes through the 16 frames in
h->long_ref to find the LTR entries.
Fixes MR2_MW_A.264 from JVT-AVC_V1.
---
libavcodec/vulkan_h264.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vulkan_h264.c b/libavcodec/vulkan_h264.c
index 32ef32d640..1bbef7b0e8 100644
--- a/libavcodec/vulkan_h264.c
+++ b/libavcodec/vulkan_h264.c
@@ -406,10 +406,14 @@ static int vk_h264_start_frame(AVCodecContext
*avctx,
}
/* Fill in long-term refs */
-for (int r = 0, i = h->short_ref_count; i < h->short_ref_count +
h->long_ref_count; i++, r++) {
+for (int r = 0, i = h->short_ref_count; r < H264_MAX_DPB_FRAMES &&
+ i < h->short_ref_count + h->long_ref_count; r++) {
+if (!h->long_ref[r])
+continue;
+
dpb_slot_index = 0;
-for (unsigned slot = 0; slot < H264_MAX_PICTURE_COUNT; slot++) {
-if (h->long_ref[i] == &h->DPB[slot]) {
+for (unsigned slot = 0; slot < 16; slot++) {
+if (h->long_ref[r] == &h->DPB[slot]) {
dpb_slot_index = slot;
break;
}
@@ -422,6 +426,7 @@ static int vk_h264_start_frame(AVCodecContext
*avctx,
dpb_slot_index);
if (err < 0)
return err;
+i++;
}
hp->h264pic = (StdVideoDecodeH264PictureInfo) {
--
2.42.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] SWS cleanup / SPI Funding Suggestion
Hi everyone I propose using 15k$ from SPI for funding sws cleanup work. this is substantially less than what people belive this needs (see IRC logs from yesterday or so) So it really is more a small price for a good deed and not proper payment. This of course is only available to competent developers. (exact rules or how thats determined would still need to be decided unless its a clear case) Also the exact outcome and goal would need to be discussed by the community and whoever does the work. But some goals would probably be to make sws * pleasent to work with * similar speed or faster * proper multithreading * proper full colorspace convertion not ignoring gamma, primaries, ... * clean / understandable modular design (maybe everything can be a "Filter" inside sws that get build into a chain) Proper payment (50k$ maybe) would be too much in relation to what SPI has ATM (150k$) Above all, this is just my oppinion, the actual SPI funding also would need to be approved by the community. This can happen after a specific volunteer comes forth or before, whichever way the community prefers. thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope 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] SWS cleanup / SPI Funding Suggestion
On Fri, Oct 13, 2023 at 3:19 PM Michael Niedermayer wrote: > Hi everyone > > I propose using 15k$ from SPI for funding sws cleanup work. > this is substantially less than what people belive this needs (see IRC > logs from yesterday or so) > So it really is more a small price for a good deed and not proper payment. > This of course is only available to competent developers. (exact rules or > how thats determined > would still need to be decided unless its a clear case) > Also the exact outcome and goal would need to be discussed by the > community and whoever > does the work. > But some goals would probably be to make sws > * pleasent to work with > * similar speed or faster > * proper multithreading > * proper full colorspace convertion not ignoring gamma, primaries, ... > * clean / understandable modular design (maybe everything can be a > "Filter" inside sws > that get build into a chain) > > Proper payment (50k$ maybe) would be too much in relation to what SPI has > ATM (150k$) > > Above all, this is just my oppinion, the actual SPI funding also would > need to > be approved by the community. This can happen after a specific volunteer > comes forth > or before, whichever way the community prefers. > Hi Michael, I don't mean to rain on your parade, but I think there are better image libraries that are more accurate, faster, and can implement proper tonemapping than sws -- zimg, and libplacebo are the prime examples. I believe it would make more sense to integrate one of them in sws as a backend (and fallback) so that the api doesn't change, or, if we absolutely need no external deps, then write an entirely new library, but 15k$ work for "cleanup" on a library noone consciously wants to use seems wasteful IMO. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_showinfo: also print chroma loc
On Fri, Oct 13, 2023 at 10:21 AM Niklas Haas wrote: > From: Niklas Haas > > Curiously absent. > --- > libavfilter/vf_showinfo.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c > index bf8580bc8d..71869446c6 100644 > --- a/libavfilter/vf_showinfo.c > +++ b/libavfilter/vf_showinfo.c > @@ -715,11 +715,11 @@ static int filter_frame(AVFilterLink *inlink, > AVFrame *frame) > av_log(ctx, AV_LOG_INFO, > "n:%4"PRId64" pts:%7s pts_time:%-7s duration:%7"PRId64 > " duration_time:%-7s " > - "fmt:%s sar:%d/%d s:%dx%d i:%c iskey:%d type:%c ", > + "fmt:%s cl:%s sar:%d/%d s:%dx%d i:%c iskey:%d type:%c ", > inlink->frame_count_out, > av_ts2str(frame->pts), av_ts2timestr(frame->pts, > &inlink->time_base), > frame->duration, av_ts2timestr(frame->duration, > &inlink->time_base), > - desc->name, > + desc->name, av_chroma_location_name(frame->chroma_location), > frame->sample_aspect_ratio.num, frame->sample_aspect_ratio.den, > frame->width, frame->height, > !(frame->flags & AV_FRAME_FLAG_INTERLACED) ? 'P' : > /* Progressive */ > -- > ok -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
Oct 13, 2023, 20:33 by vittorio.giov...@gmail.com: > On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas wrote: > >> Changes since v1: >> >> - Remove unneeded patch (AVCodecContext.colorspace init) >> - Merge auto-range conversion into auto-scale filter >> - Replace vf_zscale by vf_colorspace in fftools >> > > Why is this? I haven't checked what vf_colorspace supports in a hot second, > but iirc zscale can handle non linear spaces better and hdr conversion > If it's because it's a built in filter, do you think we could first check > for zscale presence and fallback to colorspace? > vf_colorspace != swscale Relying on external library for basic functionality that we have no control over, which may break its ABI or API at any moment, when we have a built-in one is a no. I wouldn't agree to having it optional in this case either. Users can explicitly request it as a filter and use it, which fits in better with its very explicit programming model too. ___ 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] SWS cleanup / SPI Funding Suggestion
Oct 13, 2023, 22:31 by vittorio.giov...@gmail.com: > On Fri, Oct 13, 2023 at 3:19 PM Michael Niedermayer > wrote: > >> Hi everyone >> >> I propose using 15k$ from SPI for funding sws cleanup work. >> this is substantially less than what people belive this needs (see IRC >> logs from yesterday or so) >> So it really is more a small price for a good deed and not proper payment. >> This of course is only available to competent developers. (exact rules or >> how thats determined >> would still need to be decided unless its a clear case) >> Also the exact outcome and goal would need to be discussed by the >> community and whoever >> does the work. >> But some goals would probably be to make sws >> * pleasent to work with >> * similar speed or faster >> * proper multithreading >> * proper full colorspace convertion not ignoring gamma, primaries, ... >> * clean / understandable modular design (maybe everything can be a >> "Filter" inside sws >> that get build into a chain) >> >> Proper payment (50k$ maybe) would be too much in relation to what SPI has >> ATM (150k$) >> >> Above all, this is just my oppinion, the actual SPI funding also would >> need to >> be approved by the community. This can happen after a specific volunteer >> comes forth >> or before, whichever way the community prefers. >> > > Hi Michael, > I don't mean to rain on your parade, but I think there are better image > libraries that are more accurate, faster, and can implement proper > tonemapping than sws -- zimg, and libplacebo are the prime examples. I > believe it would make more sense to integrate one of them in sws as a > backend (and fallback) so that the api doesn't change, or, if we absolutely > need no external deps, then write an entirely new library, but 15k$ work > for "cleanup" on a library noone consciously wants to use seems wasteful > IMO. > I agree, I'd rather see this money being spent to give libplacebo a software path and having swscale link against it. We can talk about importing the project as a whole separately - I don't think it's necessary, though. zimg would need far too much work, IMO. But I don't mind being wrong here. I wouldn't object to writing a new library or improving swscale either - but I do think this has to be done with a plan we could agree on. As I said yesterday, it is easy to make a mistake. ___ 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] SWS cleanup / SPI Funding Suggestion
On Fri, Oct 13, 2023 at 04:30:56PM -0400, Vittorio Giovara wrote: > On Fri, Oct 13, 2023 at 3:19 PM Michael Niedermayer > wrote: > > > Hi everyone > > > > I propose using 15k$ from SPI for funding sws cleanup work. > > this is substantially less than what people belive this needs (see IRC > > logs from yesterday or so) > > So it really is more a small price for a good deed and not proper payment. > > This of course is only available to competent developers. (exact rules or > > how thats determined > > would still need to be decided unless its a clear case) > > Also the exact outcome and goal would need to be discussed by the > > community and whoever > > does the work. > > But some goals would probably be to make sws > > * pleasent to work with > > * similar speed or faster > > * proper multithreading > > * proper full colorspace convertion not ignoring gamma, primaries, ... > > * clean / understandable modular design (maybe everything can be a > > "Filter" inside sws > > that get build into a chain) > > > > Proper payment (50k$ maybe) would be too much in relation to what SPI has > > ATM (150k$) > > > > Above all, this is just my oppinion, the actual SPI funding also would > > need to > > be approved by the community. This can happen after a specific volunteer > > comes forth > > or before, whichever way the community prefers. > > > > Hi Michael, Hi Vittorio [...] > if we absolutely > need no external deps, Yes, you are correct > then write an entirely new library, The path and the end result are 2 different things The end result that this funding is for is a clean libswscale aka a clean "image convertion lib inside FFmpeg". I think the path should be decided by the developer doing the work, if she wants to extend libplacebo and import that, sure ok too with me Only the contents of the C, H and asm files affects the people using the code And i expeted some reused code, so i call it cleanup. Things called "rewrites" also often failed. So its IMHO a sligtly cursed term, but they are just terms, what the rsult is matters thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 00/13] YUVJ removal
On Fri, Oct 13, 2023 at 5:14 PM Lynne wrote: > Oct 13, 2023, 20:33 by vittorio.giov...@gmail.com: > > > On Fri, Oct 13, 2023 at 10:27 AM Niklas Haas wrote: > > > >> Changes since v1: > >> > >> - Remove unneeded patch (AVCodecContext.colorspace init) > >> - Merge auto-range conversion into auto-scale filter > >> - Replace vf_zscale by vf_colorspace in fftools > >> > > > > Why is this? I haven't checked what vf_colorspace supports in a hot > second, > > but iirc zscale can handle non linear spaces better and hdr conversion > > If it's because it's a built in filter, do you think we could first check > > for zscale presence and fallback to colorspace? > > > > vf_colorspace != swscale > I am aware, thanks, not sure why's related here > Relying on external library for basic functionality that we have > no control over, which may break its ABI or API at any moment, > when we have a built-in one is a no. > I wouldn't agree to having it optional in this case either. Users > can explicitly request it as a filter and use it, which fits in better > with its very explicit programming model too. > except colorspace doesn't implement necessary features and conversions that are present in zscale afair if it's an automation to facilitate the life of a user it shouldn't come at the cost of producing actual good results -- Vittorio ___ 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] SWS cleanup / SPI Funding Suggestion
On Fri, 13 Oct 2023 21:19:34 +0200 Michael Niedermayer wrote: > Hi everyone > > I propose using 15k$ from SPI for funding sws cleanup work. > this is substantially less than what people belive this needs (see IRC logs > from yesterday or so) > So it really is more a small price for a good deed and not proper payment. > This of course is only available to competent developers. (exact rules or how > thats determined > would still need to be decided unless its a clear case) > Also the exact outcome and goal would need to be discussed by the community > and whoever > does the work. > But some goals would probably be to make sws > * pleasent to work with > * similar speed or faster > * proper multithreading > * proper full colorspace convertion not ignoring gamma, primaries, ... > * clean / understandable modular design (maybe everything can be a "Filter" > inside sws > that get build into a chain) > > Proper payment (50k$ maybe) would be too much in relation to what SPI has ATM > (150k$) > > Above all, this is just my oppinion, the actual SPI funding also would need to > be approved by the community. This can happen after a specific volunteer > comes forth > or before, whichever way the community prefers. > > thx My gut instinct is that the correct path forwards is to first create a new API which can internally dispatch to swscale, libplacebo or zimg based on what's compiled/available/preferred (e.g. using GPU filters for hwframes, CPU filters for swframes, zimg (or vf_colorspace's primitives) for colorspace conversions ...). Much of the pain points of my own recent experience with swscale revolves around libswscale's very low level API, complete lack of understanding of most AVFrame metadata, and relatively complex configuration requirements. (vf_scale's comments even acknowledge that libswscale should handle this stuff internally, so users just need to point an AVFrame at both ends and let it do the right thing automatically) The second pain point of extending libswscale itself is that the high-level configuration and low-level "scaling" primitives are deeply entangled, reconfigured in various places, and hard to touch without fear of breaking edge cases. A new API would solve both problems. It would allow us to write new, AVFrame-based, high-level "business logic", which could continue to call into the low-level swscale implementation details and kernels for the time being, and also tap into GPU filters (a la libplacebo) where possible. As time moves on we could replace those underlying primitives by cleaned up rewrites where necessary, until the dependency on libswscale itself is null. Simultaneously, vf_scale can be rewritten on top of this API, which would allow e.g. auto-scale filters to start doing scaling on GPU when conversion between two hwformats is needed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: fix interlaced chroma for other formats
On Fri, Oct 13, 2023 at 04:22:05PM +0200, Niklas Haas wrote: > From: Niklas Haas > > This logic only covers the case of yuv420p. Extend this logic to cover > *all* vertically subsampled YUV formats, which require the same > interlaced scaling logic. > > Fortunately, we can get away with re-using the same code for both JPEG > and MPEG range YUV, because the only difference here is the horizontal > alignment. (To be fixed in a separate commit) > --- > libavfilter/vf_scale.c | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) the patches from H4JO.txt cause several fate tests to worsen in their stddev. like: --- ./tests/ref/vsynth/vsynth1-mjpeg-huffman2023-09-29 01:05:25.534962942 +0200 +++ tests/data/fate/vsynth1-mjpeg-huffman 2023-10-13 20:45:05.228633099 +0200 @@ -1,4 +1,4 @@ 63ea9bd494e16bad8f3a0c8dbb3dc11e *tests/data/fate/vsynth1-mjpeg-huffman.avi 1391380 tests/data/fate/vsynth1-mjpeg-huffman.avi -9a3b8169c251d19044f7087a95458c55 *tests/data/fate/vsynth1-mjpeg-huffman.out.rawvideo -stddev:7.87 PSNR: 30.21 MAXDIFF: 63 bytes: 7603200/ 7603200 +64e440d0421e6b1bf3fbbc539b53e09c *tests/data/fate/vsynth1-mjpeg-huffman.out.rawvideo +stddev:8.37 PSNR: 29.67 MAXDIFF: 69 bytes: 7603200/ 7603200 This patch in this mail here seems fine thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope 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] SWS cleanup / SPI Funding Suggestion
On Fri, 13 Oct 2023 19:42:44 -0300 James Almer wrote: > Anton wrote and pushed an AVFrame based API. It can surely be > improved/extended to use AVFrame metadata. Yes, this is actually a good idea. This API endpoint already has the "correct" signature, so we could definitely re-use it (and SwsContext) instead of introducing a new header file. But to be clear, even with this sws_scale_frame API, you currently still need to configure the SwsContext up-front - and that is the source of problems IMO. I think the entire family of sws_getContext/sws_init_context/sws_setColorspaceDetails are buggy, unmaintainable nightmares. Starting from scratch, this context would not exist at all. All required metadata is available in the AVFrame itself, and it's trivial to invalidate the internal state when something changes. The function itself should be effectively stateless, with the SwsContext serving as a mere cache. So maybe a good path forwards is: 1. Make sws_scale_frame explicitly ignore the configured colorspace details in favor of AVFrame metadata. 2. Allow using sws_scale_frame with an SwsContext that has not been initialized, but merely allocated. 3. Deprecate sws_scale and the old configuration API Then SwsContext would be serving double-duty between being the configuration struct for the legacy API, while also being a cache for the new API, until eventually being just the latter. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: fix interlaced chroma for other formats
On Sat, 14 Oct 2023 00:52:23 +0200 Michael Niedermayer wrote: > On Fri, Oct 13, 2023 at 04:22:05PM +0200, Niklas Haas wrote: > > From: Niklas Haas > > > > This logic only covers the case of yuv420p. Extend this logic to cover > > *all* vertically subsampled YUV formats, which require the same > > interlaced scaling logic. > > > > Fortunately, we can get away with re-using the same code for both JPEG > > and MPEG range YUV, because the only difference here is the horizontal > > alignment. (To be fixed in a separate commit) > > --- > > libavfilter/vf_scale.c | 12 +++- > > 1 file changed, 7 insertions(+), 5 deletions(-) > > the patches from H4JO.txt > cause several fate tests to worsen in their stddev. like: I investigated these regressions and came to the conclusion that the raw input to those tests use mpeg1/jpeg/center-aligned chroma, but the rawvideo demuxer does not tag them as such. So this change in logic (i.e. treating unspecified yuv as mpeg2/mpeg4 chroma loc instead of mpeg1/jpeg chroma loc) regresses those tests by design. A solution would either to continue treating unspecified yuv as mpeg1/jpeg chroma loc (status quo), or change the FATE test to explicitly mark the rawvideo source as center chroma. That said, if the status quo for the past decades is to for vf_scale treat unspecified chroma loc as center-aligned, I am no longer sure if suddenly changing this behavior is a good idea. At the same time, this is also terribly inconsistent across implementations. For example, VLC treats all chroma as center-aligned (ignoring tags), mpv treats untagged *limited range* yuv as mpeg2/left-aligned (and full range as mpeg1/jpeg/center), while libplacebo treats all untagged yuv as mpeg2/left-aligned. There really is no consistent standard here across software, and I haven't even looked at what proprietary players do. ___ 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] SWS cleanup / SPI Funding Suggestion
On Fri, Oct 13, 2023 at 6:55 PM Niklas Haas wrote: > On Fri, 13 Oct 2023 19:42:44 -0300 James Almer wrote: > > Anton wrote and pushed an AVFrame based API. It can surely be > > improved/extended to use AVFrame metadata. > > Yes, this is actually a good idea. This API endpoint already has the > "correct" signature, so we could definitely re-use it (and SwsContext) > instead of introducing a new header file. > > But to be clear, even with this sws_scale_frame API, you currently still > need to configure the SwsContext up-front - and that is the source of > problems IMO. I think the entire family of > sws_getContext/sws_init_context/sws_setColorspaceDetails are buggy, > unmaintainable nightmares. > > Starting from scratch, this context would not exist at all. All required > metadata is available in the AVFrame itself, and it's trivial to > invalidate the internal state when something changes. The function > itself should be effectively stateless, with the SwsContext serving as a > mere cache. > > So maybe a good path forwards is: > > 1. Make sws_scale_frame explicitly ignore the configured colorspace >details in favor of AVFrame metadata. > 2. Allow using sws_scale_frame with an SwsContext that has not been >initialized, but merely allocated. > 3. Deprecate sws_scale and the old configuration API > > Then SwsContext would be serving double-duty between being the > configuration struct for the legacy API, while also being a cache for > the new API, until eventually being just the latter. > TBF this is in part why i was suggesting a new library - I feel like sws is affected by bad brading because of these caching issues and imprecise conversion, and a new clean api in a new library would make a lot of sense in my opinion. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: fix interlaced chroma for other formats
On Sat, Oct 14, 2023 at 01:00:50AM +0200, Niklas Haas wrote: > On Sat, 14 Oct 2023 00:52:23 +0200 Michael Niedermayer > wrote: > > On Fri, Oct 13, 2023 at 04:22:05PM +0200, Niklas Haas wrote: > > > From: Niklas Haas > > > > > > This logic only covers the case of yuv420p. Extend this logic to cover > > > *all* vertically subsampled YUV formats, which require the same > > > interlaced scaling logic. > > > > > > Fortunately, we can get away with re-using the same code for both JPEG > > > and MPEG range YUV, because the only difference here is the horizontal > > > alignment. (To be fixed in a separate commit) > > > --- > > > libavfilter/vf_scale.c | 12 +++- > > > 1 file changed, 7 insertions(+), 5 deletions(-) > > > > the patches from H4JO.txt > > cause several fate tests to worsen in their stddev. like: > > I investigated these regressions and came to the conclusion that the raw > input to those tests use mpeg1/jpeg/center-aligned chroma, but the > rawvideo demuxer does not tag them as such. > > So this change in logic (i.e. treating unspecified yuv as mpeg2/mpeg4 > chroma loc instead of mpeg1/jpeg chroma loc) regresses those tests by > design. > > A solution would either to continue treating unspecified yuv as > mpeg1/jpeg chroma loc (status quo), or change the FATE test to > explicitly mark the rawvideo source as center chroma. do we even have fate tests for all chroma locs ? when you are already working on tuning these. Maybe some quick test could cycle through the cases and test all > > That said, if the status quo for the past decades is to for vf_scale > treat unspecified chroma loc as center-aligned, I am no longer sure if > suddenly changing this behavior is a good idea. At the same time, this > is also terribly inconsistent across implementations. For example, VLC > treats all chroma as center-aligned (ignoring tags), mpv treats untagged > *limited range* yuv as mpeg2/left-aligned (and full range as > mpeg1/jpeg/center), while libplacebo treats all untagged yuv as > mpeg2/left-aligned. There really is no consistent standard here across > software, and I haven't even looked at what proprietary players do. I dont have a good awnser here either. I liked the result you get from taking the samples in the middle of rectangles and tiling the whole continuous image with a plane of rectangles for each luma and chroma plane I felt long ago that was the simplest and most logic way to position chroma in relation to luma. but, some chroma loc autodetection filter that uses correlation or such would be interresting given this mess. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. 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] SWS cleanup / SPI Funding Suggestion
> On Oct 13, 2023, at 4:00 PM, Vittorio Giovara > wrote: > > TBF this is in part why i was suggesting a new library - I feel like sws is > affected by bad brading because of these caching issues and imprecise > conversion, and a new clean api in a new library would make a lot of sense > in my opinion. I think the branding issue would solve itself in short order if the actual implementation of swscale started to be good. My concern with adding a new library is that we'd end up in a situation where we have both swscale and a new library side by side for some extended period of time. By comparison adding cleaner APIs to swscale and then slowly strangling the old APIs (along the lines of Niklas' proposal) would allow for a more gradual transition that has a higher likelihood of success compared to a full rewrite IMO. - Cosmin ___ 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] libavcodec/dxva2.c: fix dxva2 does not support H264 baseline profile
dxva2 fail to init when decode h264 with baseline profile becase
`prof_h264_high` does not contains `AV_PROFILE_H264_BASELINE` and
`dxva_check_codec_compatibility` will return error
---
libavcodec/dxva2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index d7bc587562..e6b83f89cc 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -61,7 +61,8 @@ typedef struct dxva_mode {
static const int prof_mpeg2_main[] = {AV_PROFILE_MPEG2_SIMPLE,
AV_PROFILE_MPEG2_MAIN,
AV_PROFILE_UNKNOWN};
-static const int prof_h264_high[]= {AV_PROFILE_H264_CONSTRAINED_BASELINE,
+static const int prof_h264_high[]= {AV_PROFILE_H264_BASELINE,
+AV_PROFILE_H264_CONSTRAINED_BASELINE,
AV_PROFILE_H264_MAIN,
AV_PROFILE_H264_HIGH,
AV_PROFILE_UNKNOWN};
--
2.42.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: fix interlaced chroma for other formats
> On Oct 13, 2023, at 4:00 PM, Niklas Haas wrote: > > That said, if the status quo for the past decades is to for vf_scale > treat unspecified chroma loc as center-aligned, I am no longer sure if > suddenly changing this behavior is a good idea. I'd say that the current default (jpeg chroma loc for untagged) is more likely to be wrong than right in practice. It is definitely a change but while we're fixing lots of color related issues the next major release this might be a good time to draw a line in the sand and fix the defaults going forward to be the typical case (while perhaps trying to minimize the instances that hit this default path and warning loudly when it does). That said this seems like the kind of change that should be in a 7.0 release rather than a 6.1 release if a 6.1 is going to happen. - Cosmin ___ 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] VMAF is now propagated to the AVFrame coming from the graph
From: ichlubna
Related to my ticket here: https://trac.ffmpeg.org/ticket/10586
VMAF score was not propagated to AVFormat like SSIM or PSNR in the result of
the filter graph. I have fixed this to make the usage consistent and possible
to get VMAF score per-frame in libavfilter.
The only dirty thing here is the added for loop to compute the score twice.
This is done to get the score in real time. Otherwise the score is delayed by
one frame. Computing the score twice should not affect the final averaged
result as each frame is added twice so the average does not change.
---
libavfilter/vf_libvmaf.c | 76 +---
1 file changed, 47 insertions(+), 29 deletions(-)
diff --git a/libavfilter/vf_libvmaf.c b/libavfilter/vf_libvmaf.c
index 2726b061ac..4c84877812 100644
--- a/libavfilter/vf_libvmaf.c
+++ b/libavfilter/vf_libvmaf.c
@@ -139,12 +139,40 @@ static int copy_picture_data(AVFrame *src, VmafPicture
*dst, unsigned bpc)
return 0;
}
+static enum VmafPoolingMethod pool_method_map(const char *pool_method)
+{
+if (pool_method) {
+if (av_stristr(pool_method, "min"))
+return VMAF_POOL_METHOD_MIN;
+if (av_stristr(pool_method, "mean"))
+return VMAF_POOL_METHOD_MEAN;
+if (av_stristr(pool_method, "harmonic_mean"))
+return VMAF_POOL_METHOD_HARMONIC_MEAN;
+}
+
+return VMAF_POOL_METHOD_MEAN;
+}
+
+static void set_meta(AVDictionary **metadata, const char *key, char comp,
float d)
+{
+char value[128];
+snprintf(value, sizeof(value), "%f", d);
+if (comp) {
+char key2[128];
+snprintf(key2, sizeof(key2), "%s%c", key, comp);
+av_dict_set(metadata, key2, value, 0);
+} else {
+av_dict_set(metadata, key, value, 0);
+}
+}
+
static int do_vmaf(FFFrameSync *fs)
{
AVFilterContext *ctx = fs->parent;
LIBVMAFContext *s = ctx->priv;
VmafPicture pic_ref, pic_dist;
AVFrame *ref, *dist;
+double vmaf_score;
int err = 0;
int ret = ff_framesync_dualinput_get(fs, &dist, &ref);
@@ -160,25 +188,29 @@ static int do_vmaf(FFFrameSync *fs)
av_color_range_name(ref->color_range));
}
-err = copy_picture_data(ref, &pic_ref, s->bpc);
-if (err) {
-av_log(s, AV_LOG_ERROR, "problem during vmaf_picture_alloc.\n");
-return AVERROR(ENOMEM);
-}
+for(int i=0; i<2; i++){
+err = copy_picture_data(ref, &pic_ref, s->bpc);
+if (err) {
+av_log(s, AV_LOG_ERROR, "problem during vmaf_picture_alloc.\n");
+return AVERROR(ENOMEM);
+}
-err = copy_picture_data(dist, &pic_dist, s->bpc);
-if (err) {
-av_log(s, AV_LOG_ERROR, "problem during vmaf_picture_alloc.\n");
-vmaf_picture_unref(&pic_ref);
-return AVERROR(ENOMEM);
-}
+err = copy_picture_data(dist, &pic_dist, s->bpc);
+if (err) {
+av_log(s, AV_LOG_ERROR, "problem during vmaf_picture_alloc.\n");
+vmaf_picture_unref(&pic_ref);
+return AVERROR(ENOMEM);
+}
-err = vmaf_read_pictures(s->vmaf, &pic_ref, &pic_dist, s->frame_cnt++);
-if (err) {
-av_log(s, AV_LOG_ERROR, "problem during vmaf_read_pictures.\n");
-return AVERROR(EINVAL);
+err = vmaf_read_pictures(s->vmaf, &pic_ref, &pic_dist, s->frame_cnt++);
+if (err) {
+av_log(s, AV_LOG_ERROR, "problem during vmaf_read_pictures.\n");
+return AVERROR(EINVAL);
+}
}
+vmaf_score_at_index(s->vmaf, s->model[0], &vmaf_score, s->frame_cnt - 2);
+set_meta(&dist->metadata, "lavfi.vmaf", 0, vmaf_score);
return ff_filter_frame(ctx->outputs[0], dist);
}
@@ -637,20 +669,6 @@ static enum VmafOutputFormat log_fmt_map(const char
*log_fmt)
return VMAF_OUTPUT_FORMAT_XML;
}
-static enum VmafPoolingMethod pool_method_map(const char *pool_method)
-{
-if (pool_method) {
-if (av_stristr(pool_method, "min"))
-return VMAF_POOL_METHOD_MIN;
-if (av_stristr(pool_method, "mean"))
-return VMAF_POOL_METHOD_MEAN;
-if (av_stristr(pool_method, "harmonic_mean"))
-return VMAF_POOL_METHOD_HARMONIC_MEAN;
-}
-
-return VMAF_POOL_METHOD_MEAN;
-}
-
static av_cold void uninit(AVFilterContext *ctx)
{
LIBVMAFContext *s = ctx->priv;
--
2.42.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".
