[FFmpeg-devel] [PATCH] avfilter/vf_overlay: Fix the calculation of average alpha with alpha composition and threads > 1
The calculation of average alpha utilizes the value of next
line(alpha[x+linesize]):
alpha[0]alpha[1]
alpha[0+linesize] alpha[1+linesize]
However, alpha[x+linesize] could be either an alpha_composited value or
an original value if it locates at next slice, which may lead to an
incorrect output and run2run changed MD5.
Hence, only utilizes the alpha within one slice on the boundary to fix
the calculation of average alpha.
CMD:
$ffmpeg -i
https://samples.ffmpeg.org/FLV/flash_with_alpha/laraShadow_dl.flv \
-filter_complex "nullsrc=1920x1080[arena];[arena][0:v]overlay" \
-vframes 10 -an -f md5 -
Before:
Incorrect output and changed MD5 at each run.
After this patch:
Consistent output and MD5.
Signed-off-by: Linjie Fu
---
[RFC]This is a partial fix. A fully-fixed method may be don't overwrite
dst_alpha
or preserve the original alpha value in composite_alpha().
Then we can use the original alpha value for calculation in blend_plane().
libavfilter/vf_overlay.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index f560d54dae..9488ccd0d7 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -515,13 +515,13 @@ static av_always_inline void
blend_plane_##depth##_##nbits##bits(AVFilterContext
if (main_has_alpha && alpha != 0 && alpha != max) {
\
/* average alpha for color components, improve quality */
\
uint8_t alpha_d;
\
-if (hsub && vsub && j+1 < src_hp && k+1 < src_wp) {
\
+if (hsub && vsub && j+1 < src_hp && k+1 < src_wp && j+1 <
slice_end) { \
alpha_d = (da[0] + da[dst->linesize[3]] +
\
da[1] + da[dst->linesize[3]+1]) >> 2;
\
} else if (hsub || vsub) {
\
alpha_h = hsub && k+1 < src_wp ?
\
(da[0] + da[1]) >> 1 : da[0];
\
-alpha_v = vsub && j+1 < src_hp ?
\
+alpha_v = vsub && j+1 < src_hp && j+1 < slice_end ?
\
(da[0] + da[dst->linesize[3]]) >> 1 : da[0];
\
alpha_d = (alpha_v + alpha_h) >> 1;
\
} else
\
--
2.31.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] libavfilter/vf_pad: Try round up w/h for odd resolution to avoid failure
Try round_up output w/h for the clips with odd resolution to avoid failure if no
padding is required(e.g. iw/ih+0+0).
$ffmpeg -i input.mp4 -vf "scale=1241x1234,pad=iw+0+0:ih+3+3:0:3" -f null -
Before:
Round down to 1240x1234 and failed since s->w < inlink->w (e.g. 1240 < 1241)
[Parsed_pad_1 @ 0x7f849090f840] Padded dimensions cannot be smaller than input
dimensions.
[Parsed_pad_1 @ 0x7f849090f840] Failed to configure input pad on Parsed_pad_1
Error reinitializing filters!
Failed to inject frame into filter network: Invalid argument
Error while processing the decoded data for stream #0:0
Conversion failed!
After:
Try to Round up for odd resolution (1241x1234 -> 1242x1240)
Stream #0:0(und): Video: wrapped_avframe, yuv420p(tv, progressive), 1242x1240
Signed-off-by: Linjie Fu
---
libavfilter/vf_pad.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_pad.c b/libavfilter/vf_pad.c
index e52f7284d4..c9a0a75630 100644
--- a/libavfilter/vf_pad.c
+++ b/libavfilter/vf_pad.c
@@ -107,6 +107,7 @@ static int config_input(AVFilterLink *inlink)
AVFilterContext *ctx = inlink->dst;
PadContext *s = ctx->priv;
AVRational adjusted_aspect = s->aspect;
+int round_w, round_h;
int ret;
double var_values[VARS_NB], res;
char *expr;
@@ -178,9 +179,13 @@ static int config_input(AVFilterLink *inlink)
if (s->y < 0 || s->y + inlink->h > s->h)
s->y = var_values[VAR_Y] = (s->h - inlink->h) / 2;
-s->w= ff_draw_round_to_sub(>draw, 0, -1, s->w);
-s->h= ff_draw_round_to_sub(>draw, 1, -1, s->h);
-/* sanity check params */
+round_w = ff_draw_round_to_sub(>draw, 0, -1, s->w);
+round_h = ff_draw_round_to_sub(>draw, 1, -1, s->h);
+
+s->w = round_w < inlink->w ? ff_draw_round_to_sub(>draw, 0, 1, s->w) :
round_w;
+s->h = round_h < inlink->h ? ff_draw_round_to_sub(>draw, 0, 1, s->h) :
round_h;
+
+ /* sanity check params */
if (s->w < inlink->w || s->h < inlink->h) {
av_log(ctx, AV_LOG_ERROR, "Padded dimensions cannot be smaller than
input dimensions.\n");
return AVERROR(EINVAL);
--
2.31.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avdevice/libopenh264dec: Increase array sizes, fix stack-buffer overread
On Mon, Dec 6, 2021 at 7:37 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> av_image_copy() expects an array of four pointers and linesizes
> according to its declaration; it currently only pointers that are
> actually in use (depending upon the pixel format), but this might
> change at any time. It has already happened for the linesizes in
> d7bc52bf456deba0f32d9fe5c288ec441f1ebef5 and so increasing their
> array fixes a stack-buffer overread.
>
> This fixes a -Wstringop-overflow= and -Wstringop-overread warning
> from GCC 11.2.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/libopenh264dec.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/libopenh264dec.c b/libavcodec/libopenh264dec.c
> index ea70a8e143..7f5e85402a 100644
> --- a/libavcodec/libopenh264dec.c
> +++ b/libavcodec/libopenh264dec.c
> @@ -91,8 +91,8 @@ static int svc_decode_frame(AVCodecContext *avctx, void
> *data,
> {
> SVCContext *s = avctx->priv_data;
> SBufferInfo info = { 0 };
> -uint8_t* ptrs[3];
> -int ret, linesize[3];
> +uint8_t *ptrs[4] = { NULL };
> +int ret, linesize[4];
> AVFrame *avframe = data;
> DECODING_STATE state;
> #if OPENH264_VER_AT_LEAST(1, 7)
> @@ -140,6 +140,7 @@ static int svc_decode_frame(AVCodecContext *avctx,
> void *data,
>
> linesize[0] = info.UsrData.sSystemBuffer.iStride[0];
> linesize[1] = linesize[2] = info.UsrData.sSystemBuffer.iStride[1];
> +linesize[3] = 0;
> av_image_copy(avframe->data, avframe->linesize, (const uint8_t **)
> ptrs, linesize, avctx->pix_fmt, avctx->width, avctx->height);
>
> avframe->pts = info.uiOutYuvTimeStamp;
> --
> 2.32.0
>
lgtm. (guess the title is referring to "avcodec/libopenh264dec: xxx" ?)
___
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] libavcodec/hevc_mp4toannexb_bsf: update the extradata in codec par if change detected
Andreas:
On Sun, Dec 5, 2021 at 7:34 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Linjie Fu:
> > From: Linjie Fu
> >
> > Container may support multiple sample descriptions in a single
> > bitstream, like multiple stsd in mov, which introduces different
> > sequence header(e.g.profile/bit_depth) in the middle of the bitstream.
> >
> > Update the extradata field in context parameter once packet with
> > different extradata is got.
> >
> > Signed-off-by: Linjie Fu
> > ---
> > libavcodec/hevc_mp4toannexb_bsf.c | 23 +++
> > 1 file changed, 23 insertions(+)
> >
> > diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
> b/libavcodec/hevc_mp4toannexb_bsf.c
> > index 790dfb0394..36a83d0c95 100644
> > --- a/libavcodec/hevc_mp4toannexb_bsf.c
> > +++ b/libavcodec/hevc_mp4toannexb_bsf.c
> > @@ -125,6 +125,9 @@ static int hevc_mp4toannexb_filter(AVBSFContext
> *ctx, AVPacket *out)
> > int got_irap = 0;
> > int i, ret = 0;
> >
> > +uint8_t *extradata;
> > +size_t extradata_size = 0;
> > +
> > ret = ff_bsf_get_packet(ctx, );
> > if (ret < 0)
> > return ret;
> > @@ -135,6 +138,26 @@ static int hevc_mp4toannexb_filter(AVBSFContext
> *ctx, AVPacket *out)
> > return 0;
> > }
> >
> > +extradata = av_packet_get_side_data(in, AV_PKT_DATA_NEW_EXTRADATA,
> _size);
> > +if (extradata && extradata_size &&
> > +(ctx->par_in->extradata_size != extradata_size ||
> > + memcmp(ctx->par_in->extradata, extradata, extradata_size))) {
> > +av_log(ctx, AV_LOG_VERBOSE, "Update extradata, size = %zu\n",
> extradata_size);
>
> We use SIZE_SPECIFIER instead of zu due to MSVC compatibility. I don't
> know if we actually support MSVC versions that old any more, but it is
> still used.
>
> +/* Update extradata */
> > +av_freep(>par_in->extradata);
> > +ctx->par_in->extradata_size = extradata_size;
> > +ctx->par_in->extradata = av_mallocz(extradata_size +
> AV_INPUT_BUFFER_PADDING_SIZE);
> > +if (!ctx->par_in->extradata)
> > +return AVERROR(ENOMEM);
> > +memcpy(ctx->par_in->extradata, extradata, extradata_size);
> > +/* Reinit */
> > +ret = hevc_extradata_to_annexb(ctx);
> > +if (ret < 0)
> > +return ret;
> > +s->length_size = ret;
> > +s->extradata_parsed = 1;
> > +}
> > +
> > bytestream2_init(, in->data, in->size);
> >
> > while (bytestream2_get_bytes_left()) {
> >
>
> 1. This is an API violation: par_in is set by the user before
> initializing the BSF, par_out is set by the BSF in init. After init,
> both are immutable.
> 2. Instead you should make hevc_extradata_to_annexb() accept a buffer
> with length field (or maybe even factor everything that
> hevc_mp4toannexb_init() does out of it and make that function accept a
> buffer and a length field; and another field to return the reformatted
> extradata and its size).
> 3. Notice that you need to actually modify the packet's
> AV_PKT_DATA_NEW_EXTRADATA side-data to make it Annex B. Otherwise the
> output will be incorrect.
> 4. And in case this BSF actually inserts the extradata in-band, it would
> need to retain an internal copy of this new extradata.
> (Andriy Gelman once sent a good patch that never got applied that added
> the correct extradata in-band even when there are in-band updates to the
> extradata. I suggest you look at this patch if you want to tackle this
> problem.)
>
Will check Andriy‘s patch first, seems that it may handle this case
properly, thanks for the review comments and pointing this out.
- Linjie
___
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/hevc_mp4toannexb_bsf: update the extradata in codec par if change detected
From: Linjie Fu
Container may support multiple sample descriptions in a single
bitstream, like multiple stsd in mov, which introduces different
sequence header(e.g.profile/bit_depth) in the middle of the bitstream.
Update the extradata field in context parameter once packet with
different extradata is got.
Signed-off-by: Linjie Fu
---
libavcodec/hevc_mp4toannexb_bsf.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/libavcodec/hevc_mp4toannexb_bsf.c
b/libavcodec/hevc_mp4toannexb_bsf.c
index 790dfb0394..36a83d0c95 100644
--- a/libavcodec/hevc_mp4toannexb_bsf.c
+++ b/libavcodec/hevc_mp4toannexb_bsf.c
@@ -125,6 +125,9 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
int got_irap = 0;
int i, ret = 0;
+uint8_t *extradata;
+size_t extradata_size = 0;
+
ret = ff_bsf_get_packet(ctx, );
if (ret < 0)
return ret;
@@ -135,6 +138,26 @@ static int hevc_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
return 0;
}
+extradata = av_packet_get_side_data(in, AV_PKT_DATA_NEW_EXTRADATA,
_size);
+if (extradata && extradata_size &&
+(ctx->par_in->extradata_size != extradata_size ||
+ memcmp(ctx->par_in->extradata, extradata, extradata_size))) {
+av_log(ctx, AV_LOG_VERBOSE, "Update extradata, size = %zu\n",
extradata_size);
+/* Update extradata */
+av_freep(>par_in->extradata);
+ctx->par_in->extradata_size = extradata_size;
+ctx->par_in->extradata = av_mallocz(extradata_size +
AV_INPUT_BUFFER_PADDING_SIZE);
+if (!ctx->par_in->extradata)
+return AVERROR(ENOMEM);
+memcpy(ctx->par_in->extradata, extradata, extradata_size);
+/* Reinit */
+ret = hevc_extradata_to_annexb(ctx);
+if (ret < 0)
+return ret;
+s->length_size = ret;
+s->extradata_parsed = 1;
+}
+
bytestream2_init(, in->data, in->size);
while (bytestream2_get_bytes_left()) {
--
2.31.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 1/3] Revert "fftools/ffmpeg_filter: fix the flags parsing for scaler"
On Sat, Aug 28, 2021 at 4:45 AM Michael Niedermayer wrote: > On Sat, Aug 07, 2021 at 09:33:27PM +0200, Michael Niedermayer wrote: > > On Sat, Aug 07, 2021 at 06:15:05PM +0800, Linjie Fu wrote: > > > From: Linjie Fu > > > > > > This reverts commit b3a0548a981db52911dd34d9de254c4fee0a8f79. > > > > LGTM > > please apply this unless you intend to fix it in another way > Rebased and applied, 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".
[FFmpeg-devel] [PATCH v2 2/2] libavfilter/graphparser: Add scale_sws_opts parse support in avfilter_graph_parse2
From: Linjie Fu
To pass the swscale options for the inserted scalers.
ffmpeg -i input.mp4 -filter_complex \
"scale_sws_opts=alphablend=checkerboard;format=nv12" \
-t 0.5 output.mp4
Update docs.
Signed-off-by: Linjie Fu
---
doc/filters.texi | 7 ---
libavfilter/graphparser.c | 22 ++
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index bdeb3fedfd..67108f91ff 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -204,9 +204,9 @@ pads must be connected. A filtergraph is considered valid
if all the
filter input and output pads of all the filterchains are connected.
Libavfilter will automatically insert @ref{scale} filters where format
-conversion is required. It is possible to specify swscale flags
-for those automatically inserted scalers by prepending
-@code{sws_flags=@var{flags};}
+conversion is required. It is possible to specify swscale flags or
+scale_sws_opts for those automatically inserted scalers by prepending
+@code{sws_flags=@var{flags};} or @code{scale_sws_opts=@var{scale_sws_opts};}
to the filtergraph description.
Here is a BNF description of the filtergraph syntax:
@@ -219,6 +219,7 @@ Here is a BNF description of the filtergraph syntax:
@var{FILTER} ::= [@var{LINKLABELS}] @var{FILTER_NAME} ["="
@var{FILTER_ARGUMENTS}] [@var{LINKLABELS}]
@var{FILTERCHAIN} ::= @var{FILTER} [,@var{FILTERCHAIN}]
@var{FILTERGRAPH} ::= [sws_flags=@var{flags};] @var{FILTERCHAIN}
[;@var{FILTERGRAPH}]
+@var{FILTERGRAPH} ::= [scale_sws_opts=@var{opts};] @var{FILTERCHAIN}
[;@var{FILTERGRAPH}]
@end example
@anchor{filtergraph escaping}
diff --git a/libavfilter/graphparser.c b/libavfilter/graphparser.c
index 1385c3ae71..96ae8940af 100644
--- a/libavfilter/graphparser.c
+++ b/libavfilter/graphparser.c
@@ -415,6 +415,25 @@ static int parse_sws_flags(const char **buf, AVFilterGraph
*graph)
return 0;
}
+static int parse_scale_sws_opts(const char **buf, AVFilterGraph *graph)
+{
+char *p = strchr(*buf, ';');
+
+if (!av_strstart(*buf, "scale_sws_opts=", buf))
+return 0;
+
+if (!p) {
+av_log(graph, AV_LOG_ERROR, "scale_sws_opts not terminated with
';'.\n");
+return AVERROR(EINVAL);
+}
+
+av_freep(>scale_sws_opts);
+graph->scale_sws_opts = av_strndup(*buf, p - *buf);
+
+*buf = p + 1;
+return 0;
+}
+
int avfilter_graph_parse2(AVFilterGraph *graph, const char *filters,
AVFilterInOut **inputs,
AVFilterInOut **outputs)
@@ -429,6 +448,9 @@ int avfilter_graph_parse2(AVFilterGraph *graph, const char
*filters,
if ((ret = parse_sws_flags(, graph)) < 0)
goto fail;
+if ((ret = parse_scale_sws_opts(, graph)) < 0)
+goto fail;
+
do {
AVFilterContext *filter;
filters += strspn(filters, WHITESPACES);
--
2.31.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 v2 1/2] lavfi/vf_scale: dump the exact swscale_options to passed to libswscale
From: Linjie Fu
Printed verbose log doesn't match the sws_flags specified in the cmdline
for simple filter graph.
ffmpeg .. -sws_flags bicubic ..
[auto_scaler_0] w:iw h:ih flags:'' interl:0
[auto_scaler_0] w:310 h:449 fmt:yuva420p sar:0/1 -> w:310 h:449 fmt:yuv420p
sar:0/1 flags:0x0
Filter complex doesn't have this issue as mentioned in 12e7e1d03, the
auto-inserted scaler accepts sws_flags in filtergraph complex which
overrides the 'flags' option for vf_scale and dump it as a verbose log:
ffmpeg .. -filter_complex "sws_flags=bicubic;format=nv12" ..
[auto_scaler_0] w:iw h:ih flags:'bicubic' interl:0
[auto_scaler_0] w:310 h:449 fmt:yuva420p sar:0/1 -> w:310 h:449 fmt:nv12
sar:0/1 flags:0x2
To catch the difference, dump the exact sws_flags which is passed to
libswscale.
[auto_scaler_0] swscale_options:'sws_flags=bicubic'
Signed-off-by: Linjie Fu
---
libavfilter/vf_scale.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index aa855b894a..dc8051a236 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -552,10 +552,16 @@ static int config_props(AVFilterLink *outlink)
scale->out_range == AVCOL_RANGE_JPEG, 0);
if (scale->opts) {
+char args[512] = { 0 };
AVDictionaryEntry *e = NULL;
while ((e = av_dict_get(scale->opts, "", e,
AV_DICT_IGNORE_SUFFIX))) {
if ((ret = av_opt_set(*s, e->key, e->value, 0)) < 0)
return ret;
+av_strlcatf(args, sizeof(args), "%s=%s:", e->key,
e->value);
+}
+if (args[0] != '\0') {
+args[strlen(args)-1] = 0;
+av_log(ctx, AV_LOG_VERBOSE, "swscale_options:'%s'\n",
args);
}
}
/* Override YUV420P default settings to have the correct (MPEG-2)
chroma positions
--
2.31.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] lavfi/vf_scale: dump the exact swscale_options to passed to libswscale
On Sat, Aug 7, 2021 at 9:12 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Linjie Fu:
> > From: Linjie Fu
> >
> > Printed verbose log doesn't match the sws_flags specified in the cmdline
> > for simple filter graph.
> >
> > ffmpeg .. -sws_flags bicubic ..
> > [auto_scaler_0] w:iw h:ih flags:'' interl:0
> > [auto_scaler_0] w:310 h:449 fmt:yuva420p sar:0/1 -> w:310 h:449
> fmt:yuv420p sar:0/1 flags:0x0
> >
> > Filter complex doesn't have this issue as mentioned in 12e7e1d03, the
> > auto-inserted scaler accepts sws_flags in filtergraph complex which
> > overrides the 'flags' option for vf_scale and dump it as a verbose log:
> >
> > ffmpeg .. -filter_complex "sws_flags=bicubic;format=nv12" ..
> > [auto_scaler_0] w:iw h:ih flags:'bicubic' interl:0
> > [auto_scaler_0] w:310 h:449 fmt:yuva420p sar:0/1 -> w:310 h:449
> fmt:nv12 sar:0/1 flags:0x2
> >
> > To catch the difference, dump the exact sws_flags which is passed to
> > libswscale.
> >
> > [auto_scaler_0] swscale_options:'sws_flags=bicubic'
> >
> > Signed-off-by: Linjie Fu
> > ---
> > libavfilter/vf_scale.c | 6 ++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> > index aa855b894a..f994217bdc 100644
> > --- a/libavfilter/vf_scale.c
> > +++ b/libavfilter/vf_scale.c
> > @@ -552,11 +552,17 @@ static int config_props(AVFilterLink *outlink)
> > scale->out_range == AVCOL_RANGE_JPEG, 0);
> >
> > if (scale->opts) {
> > +char args[512];
> > +args[0] = 0;
>
> This will lead to a declaration-after-statement warning.
>
> > AVDictionaryEntry *e = NULL;
> > while ((e = av_dict_get(scale->opts, "", e,
> AV_DICT_IGNORE_SUFFIX))) {
> > if ((ret = av_opt_set(*s, e->key, e->value, 0)) < 0)
> > return ret;
> > +av_strlcatf(args, sizeof(args), "%s=%s:", e->key,
> e->value);
> > }
> > +if (strlen(args))
>
> I doubt strlen(args) == 0 can happen; anyway, checking for whether a
> string is empty can be done easier: "if (args[0] != '\0')".
>
> > +args[strlen(args)-1] = 0;
> > +av_log(ctx, AV_LOG_VERBOSE, "swscale_options:'%s'\n",
> (char *)av_x_if_null(args, ""));
>
> The av_x_if_null() makes no sense at all, as args is never NULL: It is a
> stack array.
Modified as suggested, thx.
- linjie
___
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] libavfilter/graphparser: Add scale_sws_opts parse support in avfilter_graph_parse2
Andreas:
On Sat, Aug 7, 2021 at 9:52 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Linjie Fu:
> > From: Linjie Fu
> >
> > To pass the swscale options for the inserted scalers.
> >
> > ffmpeg -i input.mp4 -filter_complex \
> > "scale_sws_opts=alphablend=checkerboard;format=nv12" \
> > -t 0.5 output.mp4
> >
> > Update docs.
> >
> > Signed-off-by: Linjie Fu
> > ---
> > doc/filters.texi | 7 ---
> > libavfilter/graphparser.c | 27 +++
> > 2 files changed, 31 insertions(+), 3 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 790d165433..dbbb3a6940 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -204,9 +204,9 @@ pads must be connected. A filtergraph is considered
> valid if all the
> > filter input and output pads of all the filterchains are connected.
> >
> > Libavfilter will automatically insert @ref{scale} filters where format
> > -conversion is required. It is possible to specify swscale flags
> > -for those automatically inserted scalers by prepending
> > -@code{sws_flags=@var{flags};}
> > +conversion is required. It is possible to specify swscale flags or
> > +scale_sws_opts for those automatically inserted scalers by prepending
> > +@code{sws_flags=@var{flags};} or
> @code{scale_sws_opts=@var{scale_sws_opts};}
> > to the filtergraph description.
> >
> > Here is a BNF description of the filtergraph syntax:
> > @@ -219,6 +219,7 @@ Here is a BNF description of the filtergraph syntax:
> > @var{FILTER} ::= [@var{LINKLABELS}] @var{FILTER_NAME} ["="
> @var{FILTER_ARGUMENTS}] [@var{LINKLABELS}]
> > @var{FILTERCHAIN} ::= @var{FILTER} [,@var{FILTERCHAIN}]
> > @var{FILTERGRAPH} ::= [sws_flags=@var{flags};] @var{FILTERCHAIN}
> [;@var{FILTERGRAPH}]
> > +@var{FILTERGRAPH} ::= [scale_sws_opts=@var{opts};]
> @var{FILTERCHAIN} [;@var{FILTERGRAPH}]
> > @end example
> >
> > @anchor{filtergraph escaping}
> > diff --git a/libavfilter/graphparser.c b/libavfilter/graphparser.c
> > index 1385c3ae71..8c63d6454e 100644
> > --- a/libavfilter/graphparser.c
> > +++ b/libavfilter/graphparser.c
> > @@ -415,6 +415,30 @@ static int parse_sws_flags(const char **buf,
> AVFilterGraph *graph)
> > return 0;
> > }
> >
> > +static int parse_scale_sws_opts(const char **buf, AVFilterGraph *graph)
> > +{
> > +char *p = strchr(*buf, ';');
> > +
> > +if (strncmp(*buf, "scale_sws_opts=", 15)) {
>
> av_strstart()
>
> > +return 0;
> > +}
> > +
> > +if (!p) {
> > +av_log(graph, AV_LOG_ERROR, "scale_sws_opts not terminated with
> ';'.\n");
> > +return AVERROR(EINVAL);
> > +}
> > +
> > +*buf += 15;
> > +
> > +av_freep(>scale_sws_opts);
> > +if (!(graph->scale_sws_opts = av_mallocz(p - *buf + 1)))
> > +return AVERROR(ENOMEM);
> > +av_strlcpy(graph->scale_sws_opts, *buf, p - *buf + 1);
>
> av_strndup()
>
Yes, thanks for pointing this out.
This patch uses the similar code from current implementation[1], hence I
guess it could be simplified too.
- linjie
[1]
https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/graphparser.c#L395
___
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] [FFmpeg-cvslog] fftools/ffmpeg_filter: fix the flags parsing for scaler
On Sat, Aug 7, 2021 at 2:33 AM Michael Niedermayer wrote: > On Thu, Aug 05, 2021 at 02:30:32PM +0000, Linjie Fu wrote: > > ffmpeg | branch: master | Linjie Fu | Sun > Aug 1 18:58:19 2021 +0800| [b3a0548a981db52911dd34d9de254c4fee0a8f79] | > committer: Linjie Fu > > > > fftools/ffmpeg_filter: fix the flags parsing for scaler > > > > Scaler relys on "-sws_flags" option to pass the flags to swscale > > and scale filter. Currently passing "sws_flags=xxx" as a filter > > option to scaler leads to an incorrect option parsing. > > > > Check and change the string to "flags=xxx" and dumped flags information. > > (Refer to parse_sws_flags()) > > > > CMD: > > $ffmpeg -v verbose -i input.mp4 -sws_flags lanczos+bitexact+accurate_rnd > \ > > -vf format=yuv420p,scale=800x600 -an -vframes 10 -f md5 - > > > > Before: > > [auto_scaler_0 @ 0x7f96c3808680] w:iw h:ih flags:'' interl:0 > > [auto_scaler_0 @ 0x7f96c3808680] w:1920 h:1080 fmt:yuvj420p sar:0/1 -> > w:1920 h:1080 fmt:yuv420p sar:0/1 flags:0x0 > > [Parsed_scale_1 @ 0x7f96c3806e40] w:1920 h:1080 fmt:yuv420p sar:0/1 -> > w:800 h:600 fmt:yuv420p sar:0/1 flags:0x0 > > MD5=ff1d6091690c6fcd36d458d2a9f648ce > > > > After: > > [auto_scaler_0 @ 0x7fe94563b4c0] w:iw h:ih > flags:'lanczos+bitexact+accurate_rnd' interl:0 > > [auto_scaler_0 @ 0x7fe94563b4c0] w:1920 h:1080 fmt:yuvj420p sar:0/1 -> > w:1920 h:1080 fmt:yuv420p sar:0/1 flags:0xc0200 > > [Parsed_scale_1 @ 0x7fe945639d00] w:1920 h:1080 fmt:yuv420p sar:0/1 -> > w:800 h:600 fmt:yuv420p sar:0/1 flags:0xc0200 > > MD5=ff1d6091690c6fcd36d458d2a9f648ce > > > > Signed-off-by: Linjie Fu > > > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=b3a0548a981db52911dd34d9de254c4fee0a8f79 > > --- > > This breaks > -i laraShadow_dl.flv -alphablend checkerboard -qscale 2 -t 0.5 file.avi > Thanks. Double checked, this commit should be reverted since options are parsed and passed to libswscale correctly. Previous issue I was trying to fix is more like a log print issue rather than an option parsing issue. New patch sent to the maillist. Sorry for the revert. After this commit the output is just black > > sample seems here: > https://samples.ffmpeg.org/FLV/flash_with_alpha/ Does filter_complex support the same usage or there are other methods to pass swscale_option? # ffmpeg -i laraShadow_dl.flv -filter_complex "sws_flags=bilinear;format=yuv420p" -alphablend checkerboard -y patched.avi The output is black, "-alphablend checkerboard" seems not passed to the auto-inserted scale filter. - linjie ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] libavfilter/graphparser: Add scale_sws_opts parse support in avfilter_graph_parse2
From: Linjie Fu
To pass the swscale options for the inserted scalers.
ffmpeg -i input.mp4 -filter_complex \
"scale_sws_opts=alphablend=checkerboard;format=nv12" \
-t 0.5 output.mp4
Update docs.
Signed-off-by: Linjie Fu
---
doc/filters.texi | 7 ---
libavfilter/graphparser.c | 27 +++
2 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 790d165433..dbbb3a6940 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -204,9 +204,9 @@ pads must be connected. A filtergraph is considered valid
if all the
filter input and output pads of all the filterchains are connected.
Libavfilter will automatically insert @ref{scale} filters where format
-conversion is required. It is possible to specify swscale flags
-for those automatically inserted scalers by prepending
-@code{sws_flags=@var{flags};}
+conversion is required. It is possible to specify swscale flags or
+scale_sws_opts for those automatically inserted scalers by prepending
+@code{sws_flags=@var{flags};} or @code{scale_sws_opts=@var{scale_sws_opts};}
to the filtergraph description.
Here is a BNF description of the filtergraph syntax:
@@ -219,6 +219,7 @@ Here is a BNF description of the filtergraph syntax:
@var{FILTER} ::= [@var{LINKLABELS}] @var{FILTER_NAME} ["="
@var{FILTER_ARGUMENTS}] [@var{LINKLABELS}]
@var{FILTERCHAIN} ::= @var{FILTER} [,@var{FILTERCHAIN}]
@var{FILTERGRAPH} ::= [sws_flags=@var{flags};] @var{FILTERCHAIN}
[;@var{FILTERGRAPH}]
+@var{FILTERGRAPH} ::= [scale_sws_opts=@var{opts};] @var{FILTERCHAIN}
[;@var{FILTERGRAPH}]
@end example
@anchor{filtergraph escaping}
diff --git a/libavfilter/graphparser.c b/libavfilter/graphparser.c
index 1385c3ae71..8c63d6454e 100644
--- a/libavfilter/graphparser.c
+++ b/libavfilter/graphparser.c
@@ -415,6 +415,30 @@ static int parse_sws_flags(const char **buf, AVFilterGraph
*graph)
return 0;
}
+static int parse_scale_sws_opts(const char **buf, AVFilterGraph *graph)
+{
+char *p = strchr(*buf, ';');
+
+if (strncmp(*buf, "scale_sws_opts=", 15)) {
+return 0;
+}
+
+if (!p) {
+av_log(graph, AV_LOG_ERROR, "scale_sws_opts not terminated with
';'.\n");
+return AVERROR(EINVAL);
+}
+
+*buf += 15;
+
+av_freep(>scale_sws_opts);
+if (!(graph->scale_sws_opts = av_mallocz(p - *buf + 1)))
+return AVERROR(ENOMEM);
+av_strlcpy(graph->scale_sws_opts, *buf, p - *buf + 1);
+
+*buf = p + 1;
+return 0;
+}
+
int avfilter_graph_parse2(AVFilterGraph *graph, const char *filters,
AVFilterInOut **inputs,
AVFilterInOut **outputs)
@@ -429,6 +453,9 @@ int avfilter_graph_parse2(AVFilterGraph *graph, const char
*filters,
if ((ret = parse_sws_flags(, graph)) < 0)
goto fail;
+if ((ret = parse_scale_sws_opts(, graph)) < 0)
+goto fail;
+
do {
AVFilterContext *filter;
filters += strspn(filters, WHITESPACES);
--
2.31.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/3] lavfi/vf_scale: dump the exact swscale_options to passed to libswscale
From: Linjie Fu
Printed verbose log doesn't match the sws_flags specified in the cmdline
for simple filter graph.
ffmpeg .. -sws_flags bicubic ..
[auto_scaler_0] w:iw h:ih flags:'' interl:0
[auto_scaler_0] w:310 h:449 fmt:yuva420p sar:0/1 -> w:310 h:449 fmt:yuv420p
sar:0/1 flags:0x0
Filter complex doesn't have this issue as mentioned in 12e7e1d03, the
auto-inserted scaler accepts sws_flags in filtergraph complex which
overrides the 'flags' option for vf_scale and dump it as a verbose log:
ffmpeg .. -filter_complex "sws_flags=bicubic;format=nv12" ..
[auto_scaler_0] w:iw h:ih flags:'bicubic' interl:0
[auto_scaler_0] w:310 h:449 fmt:yuva420p sar:0/1 -> w:310 h:449 fmt:nv12
sar:0/1 flags:0x2
To catch the difference, dump the exact sws_flags which is passed to
libswscale.
[auto_scaler_0] swscale_options:'sws_flags=bicubic'
Signed-off-by: Linjie Fu
---
libavfilter/vf_scale.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index aa855b894a..f994217bdc 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -552,11 +552,17 @@ static int config_props(AVFilterLink *outlink)
scale->out_range == AVCOL_RANGE_JPEG, 0);
if (scale->opts) {
+char args[512];
+args[0] = 0;
AVDictionaryEntry *e = NULL;
while ((e = av_dict_get(scale->opts, "", e,
AV_DICT_IGNORE_SUFFIX))) {
if ((ret = av_opt_set(*s, e->key, e->value, 0)) < 0)
return ret;
+av_strlcatf(args, sizeof(args), "%s=%s:", e->key,
e->value);
}
+if (strlen(args))
+args[strlen(args)-1] = 0;
+av_log(ctx, AV_LOG_VERBOSE, "swscale_options:'%s'\n", (char
*)av_x_if_null(args, ""));
}
/* Override YUV420P default settings to have the correct (MPEG-2)
chroma positions
* MPEG-2 chroma positions are used by convention
--
2.31.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] Revert "fftools/ffmpeg_filter: fix the flags parsing for scaler"
From: Linjie Fu
This reverts commit b3a0548a981db52911dd34d9de254c4fee0a8f79.
This breaks the usage of swscale options, scale_sws_opts should be passed
to auto-inserted scale-filters.
The auto-inserted scaler accepts sws_flags in filtergraph complex which
overrides the 'flags' option for vf_scale and dump it in verbose, however
simple filtergraph doesn't override. Hence we got different verbose logs
printed in vf_scale when we specify -sws_flags in cmdline. It's a matter
of log print rather than option parsing.
Signed-off-by: Linjie Fu
---
fftools/ffmpeg_filter.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 49076f13ee..a90858655d 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -977,11 +977,7 @@ int configure_filtergraph(FilterGraph *fg)
}
if (strlen(args))
args[strlen(args)-1] = 0;
-
-if (!strncmp(args, "sws_flags=", 10)) {
-// keep the 'flags=' part
-fg->graph->scale_sws_opts = av_strdup(args+4);
-}
+fg->graph->scale_sws_opts = av_strdup(args);
args[0] = 0;
while ((e = av_dict_get(ost->swr_opts, "", e,
--
2.31.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] fftools: Don't set default swscale flags in ffmpeg/ffprobe/ffplay
On Thu, Aug 5, 2021 at 11:22 PM Nicolas George wrote: > Linjie Fu (12021-08-05): > > Where is supposed to be the right placement? > > In the commit that makes the results change. > > Just do this: checkout the first commit, build, run FATE. Does it pass? > Double confirmed locally, Yes, and the first commit has passed the patchwork too: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210804170311.86426-1-fulin...@zju.edu.cn/ - linjie ___ 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] fftools: Don't set default swscale flags in ffmpeg/ffprobe/ffplay
On Thu, Aug 5, 2021 at 10:54 PM Nicolas George wrote: > Linjie Fu (12021-08-05): > > This initials from your review comments to remove setting defaults in > > ffmpeg (etc) and use the default flags in swscale, > > and I didn't see objections at least till now. Did I misunderstand? > > I approved the general principle and the lavfi parts. I do not maintain > the fftools part and did not approve it. > > Since nobody approved it, you should not have pushed. > > At a glance, it was wrong about the placement of the FATE change. Where is supposed to be the right placement? Be ready to revert if there is any objection, and in the future be more > careful. > Will keep in mind, thanks. - linjie ___ 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] [FFmpeg-cvslog] fftools: Don't set default swscale flags in ffmpeg/ffprobe/ffplay
On Thu, Aug 5, 2021 at 10:32 PM Nicolas George wrote: > Linjie Fu (12021-08-05): > > ffmpeg | branch: master | Linjie Fu | Thu > Aug 5 00:37:29 2021 +0800| [5b0e6b0d82dfcc5c6b999e2678b52b0cff38ae0a] | > committer: Linjie Fu > > > > fftools: Don't set default swscale flags in ffmpeg/ffprobe/ffplay > > > > Signed-off-by: Linjie Fu > > > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=5b0e6b0d82dfcc5c6b999e2678b52b0cff38ae0a > > --- > > > > fftools/cmdutils.c | 8 > > fftools/ffplay.c | 2 -- > > fftools/ffprobe.c | 1 - > > 3 files changed, 11 deletions(-) > > Why did you push? Did somebody approve the fftools patches? This initials from your review comments to remove setting defaults in ffmpeg (etc) and use the default flags in swscale, and I didn't see objections at least till now. Did I misunderstand? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/2] lavfi/vf_scale: use default swscale flags for simple and complex filter graph
On Thu, Aug 5, 2021 at 2:22 AM Nicolas George wrote:
> Linjie Fu (12021-08-05):
> > > > -if (scale->flags_str) {
> > > > +if (*scale->flags_str) {
> > > It could still be NULL, IIRC.
> > sws_flags doesn't have a candidate for "" (NULL) [1].
> > Hence NULL input for flags leads to a parsing issue:
>
> It is not what I am talking about.
>
> The application can set scale->flags to NULL. If it does,
> *scale->flags_str crashes.
>
Got your point, change it locally into:
-if (scale->flags_str) {
+ if (scale->flags_str && *scale->flags_str) {
Thanks for the review. Plan to apply soon if no more comments.
- linjie
___
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 v4 3/3] fftools/ffmpeg_filter: fix the flags parsing for scaler
From: Linjie Fu
Scaler relys on "-sws_flags" option to pass the flags to swscale
and scale filter. Currently passing "sws_flags=xxx" as a filter
option to scaler leads to an incorrect option parsing.
Check and change the string to "flags=xxx" and dumped flags information.
(Refer to parse_sws_flags())
CMD:
$ffmpeg -v verbose -i input.mp4 -sws_flags lanczos+bitexact+accurate_rnd \
-vf format=yuv420p,scale=800x600 -an -vframes 10 -f md5 -
Before:
[auto_scaler_0 @ 0x7f96c3808680] w:iw h:ih flags:'' interl:0
[auto_scaler_0 @ 0x7f96c3808680] w:1920 h:1080 fmt:yuvj420p sar:0/1 -> w:1920
h:1080 fmt:yuv420p sar:0/1 flags:0x0
[Parsed_scale_1 @ 0x7f96c3806e40] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0x0
MD5=ff1d6091690c6fcd36d458d2a9f648ce
After:
[auto_scaler_0 @ 0x7fe94563b4c0] w:iw h:ih
flags:'lanczos+bitexact+accurate_rnd' interl:0
[auto_scaler_0 @ 0x7fe94563b4c0] w:1920 h:1080 fmt:yuvj420p sar:0/1 -> w:1920
h:1080 fmt:yuv420p sar:0/1 flags:0xc0200
[Parsed_scale_1 @ 0x7fe945639d00] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0xc0200
MD5=ff1d6091690c6fcd36d458d2a9f648ce
Signed-off-by: Linjie Fu
---
fftools/ffmpeg_filter.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 958d74f008..94838adc56 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -977,7 +977,11 @@ int configure_filtergraph(FilterGraph *fg)
}
if (strlen(args))
args[strlen(args)-1] = 0;
-fg->graph->scale_sws_opts = av_strdup(args);
+
+if (!strncmp(args, "sws_flags=", 10)) {
+// keep the 'flags=' part
+fg->graph->scale_sws_opts = av_strdup(args+4);
+}
args[0] = 0;
while ((e = av_dict_get(ost->swr_opts, "", e,
--
2.31.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 v4 1/3] lavfi/vf_scale: use default swscale flags for scaler
Currently the default swscale flags for simple filter graph is bicubic,
however for complex filter graph it uses bilinear as decleared in scale
filter.
$ffmpeg -v verbose -i input.mp4 -vf format=yuv420p,scale=800x600 -an -f null -
[Parsed_scale_1 @ 0x7f86d2c160c0] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0x4
$ffmpeg -v verbose -i input.mp4 -filter_complex format=yuv420p,scale=800x600
-an -f null -
[Parsed_scale_1 @ 0x7f8779e046c0] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0x2
Use default swscale flags (bicubic currently) for scale filter.
- Remove flags="bilinear" from vf_scale
- Update the FATE refs
Signed-off-by: Linjie Fu
---
libavfilter/vf_scale.c | 4 ++--
tests/ref/fate/filter-scale2ref_keep_aspect | 10 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index f07e01bf90..683c4caa37 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -313,7 +313,7 @@ static av_cold int init_dict(AVFilterContext *ctx,
AVDictionary **opts)
scale->flags = 0;
-if (scale->flags_str) {
+if (*scale->flags_str) {
const AVClass *class = sws_get_class();
const AVOption*o = av_opt_find(, "sws_flags", NULL, 0,
AV_OPT_SEARCH_FAKE_OBJ);
@@ -900,7 +900,7 @@ static const AVOption scale_options[] = {
{ "width", "Output video width", OFFSET(w_expr),
AV_OPT_TYPE_STRING,.flags = TFLAGS },
{ "h", "Output video height", OFFSET(h_expr),
AV_OPT_TYPE_STRING,.flags = TFLAGS },
{ "height","Output video height", OFFSET(h_expr),
AV_OPT_TYPE_STRING,.flags = TFLAGS },
-{ "flags", "Flags to pass to libswscale", OFFSET(flags_str),
AV_OPT_TYPE_STRING, { .str = "bilinear" }, .flags = FLAGS },
+{ "flags", "Flags to pass to libswscale", OFFSET(flags_str),
AV_OPT_TYPE_STRING, { .str = "" }, .flags = FLAGS },
{ "interl", "set interlacing", OFFSET(interlaced), AV_OPT_TYPE_BOOL, {.i64
= 0 }, -1, 1, FLAGS },
{ "size", "set video size", OFFSET(size_str),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, FLAGS },
{ "s", "set video size", OFFSET(size_str),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, FLAGS },
diff --git a/tests/ref/fate/filter-scale2ref_keep_aspect
b/tests/ref/fate/filter-scale2ref_keep_aspect
index 8dd0dbb13b..53c6fc14ec 100644
--- a/tests/ref/fate/filter-scale2ref_keep_aspect
+++ b/tests/ref/fate/filter-scale2ref_keep_aspect
@@ -7,8 +7,8 @@
#dimensions 0: 160x120
#sar 0: 1/1
#stream#, dts,pts, duration, size, hash
-0, 0, 0,1,57600, 9a19c23dc3a557786840d0098606d5f1
-0, 1, 1,1,57600, e6fbdabaf1bb0d28afc648ed4d27e9f0
-0, 2, 2,1,57600, 52924ed0a751214c50fb2e7a626c8cc5
-0, 3, 3,1,57600, 67d5fd6ee71793f1cf8794d1c27afdce
-0, 4, 4,1,57600, 85f7775f7b01afd369fc8919dc759d30
+0, 0, 0,1,57600, 65fe9892ad710cc5763b04b390327d40
+0, 1, 1,1,57600, 5e8d4524bc8889afa8769e851e998bc0
+0, 2, 2,1,57600, 8f5e0e58d1f4c2104b82ef7a16850f1e
+0, 3, 3,1,57600, cfe4142845e1445d33748493faa63cda
+0, 4, 4,1,57600, bb491f3b01788773fb6129aef0f0abd2
--
2.31.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 v4 2/3] fftools: Don't set default swscale flags in ffmpeg/ffprobe/ffplay
From: Linjie Fu
Signed-off-by: Linjie Fu
---
fftools/cmdutils.c | 8
fftools/ffplay.c | 2 --
fftools/ffprobe.c | 1 -
3 files changed, 11 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 0b1ef03a25..912e881174 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -81,11 +81,6 @@ enum show_muxdemuxers {
SHOW_MUXERS,
};
-void init_opts(void)
-{
-av_dict_set(_dict, "flags", "bicubic", 0);
-}
-
void uninit_opts(void)
{
av_dict_free(_opts);
@@ -670,7 +665,6 @@ static void finish_group(OptionParseContext *octx, int
group_idx,
resample_opts = NULL;
sws_dict= NULL;
swr_opts= NULL;
-init_opts();
memset(>cur_group, 0, sizeof(octx->cur_group));
}
@@ -708,8 +702,6 @@ static void init_parse_context(OptionParseContext *octx,
octx->global_opts.group_def = _group;
octx->global_opts.arg = "";
-
-init_opts();
}
void uninit_parse_context(OptionParseContext *octx)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 6b19574eae..46758b9f55 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -3695,8 +3695,6 @@ int main(int argc, char **argv)
#endif
avformat_network_init();
-init_opts();
-
signal(SIGINT , sigterm_handler); /* Interrupt (ANSI).*/
signal(SIGTERM, sigterm_handler); /* Termination (ANSI). */
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index f411ba35b5..95263e1e6f 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -3721,7 +3721,6 @@ int main(int argc, char **argv)
options = real_options;
parse_loglevel(argc, argv, options);
avformat_network_init();
-init_opts();
#if CONFIG_AVDEVICE
avdevice_register_all();
#endif
--
2.31.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/2] lavfi/vf_scale: use default swscale flags for simple and complex filter graph
On Wed, Aug 4, 2021 at 7:03 PM Nicolas George wrote:
> Linjie Fu (12021-08-04):
> > From: Linjie Fu
> >
> > Currently the default swscale flags for simple filter graph is bicubic,
> > however for complex filter graph it uses bilinear as decleared in scale
> > filter.
> >
> > $ffmpeg -v verbose -i input.mp4 -vf format=yuv420p,scale=800x600 -an -f
> null -
> > [Parsed_scale_1 @ 0x7f86d2c160c0] w:1920 h:1080 fmt:yuv420p sar:0/1 ->
> w:800 h:600 fmt:yuv420p sar:0/1 flags:0x4
> >
> > $ffmpeg -v verbose -i input.mp4 -filter_complex
> format=yuv420p,scale=800x600 -an -f null -
> > [Parsed_scale_1 @ 0x7f8779e046c0] w:1920 h:1080 fmt:yuv420p sar:0/1 ->
> w:800 h:600 fmt:yuv420p sar:0/1 flags:0x2
> >
> > Use default swscale flags (bicubic currently) for scale filter.
> > - Remove flags="bilinear" from vf_scale
> > - Remove setting defaults in ffmpeg/ffprobe/ffplay
> > - Update the FATE refs
> >
> > Signed-off-by: Linjie Fu
> > ---
> > fftools/cmdutils.c | 8
> > fftools/ffplay.c| 2 --
> > fftools/ffprobe.c | 1 -
> > libavfilter/vf_scale.c | 4 ++--
> > tests/ref/fate/filter-scale2ref_keep_aspect | 10 +-
> > 5 files changed, 7 insertions(+), 18 deletions(-)
>
> Why are patches for fftools squashed with this patch? They should be
> separate, as they were.
>
You're right, splitted locally.
> >
> > diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> > index 0b1ef03a25..912e881174 100644
> > --- a/fftools/cmdutils.c
> > +++ b/fftools/cmdutils.c
> > @@ -81,11 +81,6 @@ enum show_muxdemuxers {
> > SHOW_MUXERS,
> > };
> >
> > -void init_opts(void)
> > -{
> > -av_dict_set(_dict, "flags", "bicubic", 0);
> > -}
> > -
> > void uninit_opts(void)
> > {
> > av_dict_free(_opts);
> > @@ -670,7 +665,6 @@ static void finish_group(OptionParseContext *octx,
> int group_idx,
> > resample_opts = NULL;
> > sws_dict= NULL;
> > swr_opts= NULL;
> > -init_opts();
> >
> > memset(>cur_group, 0, sizeof(octx->cur_group));
> > }
> > @@ -708,8 +702,6 @@ static void init_parse_context(OptionParseContext
> *octx,
> >
> > octx->global_opts.group_def = _group;
> > octx->global_opts.arg = "";
> > -
> > -init_opts();
> > }
> >
> > void uninit_parse_context(OptionParseContext *octx)
> > diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> > index 6b19574eae..46758b9f55 100644
> > --- a/fftools/ffplay.c
> > +++ b/fftools/ffplay.c
> > @@ -3695,8 +3695,6 @@ int main(int argc, char **argv)
> > #endif
> > avformat_network_init();
> >
> > -init_opts();
> > -
> > signal(SIGINT , sigterm_handler); /* Interrupt (ANSI).*/
> > signal(SIGTERM, sigterm_handler); /* Termination (ANSI). */
> >
> > diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> > index f411ba35b5..95263e1e6f 100644
> > --- a/fftools/ffprobe.c
> > +++ b/fftools/ffprobe.c
> > @@ -3721,7 +3721,6 @@ int main(int argc, char **argv)
> > options = real_options;
> > parse_loglevel(argc, argv, options);
> > avformat_network_init();
> > -init_opts();
> > #if CONFIG_AVDEVICE
> > avdevice_register_all();
> > #endif
> > diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> > index f07e01bf90..683c4caa37 100644
> > --- a/libavfilter/vf_scale.c
> > +++ b/libavfilter/vf_scale.c
> > @@ -313,7 +313,7 @@ static av_cold int init_dict(AVFilterContext *ctx,
> AVDictionary **opts)
> >
> > scale->flags = 0;
> >
>
> > -if (scale->flags_str) {
> > +if (*scale->flags_str) {
>
> It could still be NULL, IIRC.
>
sws_flags doesn't have a candidate for "" (NULL) [1].
Hence NULL input for flags leads to a parsing issue:
$ffmpeg -v verbose -i input.mp4 -vf format=yuv420p,scale=800x600 -an
-vframes 10 -f md5 -
[Parsed_scale_1 @ 0x7fc03f44e6c0] w:800 h:600 flags:'' interl:0
[swscaler @ 0x7ffee24cb830] [Eval @ 0x7ffee24cb130] Undefined constant or
missing '(' in ''
[swscaler @ 0x7ffee24cb830] Unable to parse option value ""
[AVFilterGraph @ 0x7fc03f44e5c0] Error initializing filter 'scale' with
args '800x600'
Error reinitializing filters!
Failed to inject frame into filter network: Invalid argument
>
> > const AVClass *class = sws_get_class();
> >
Re: [FFmpeg-devel] [PATCH v1] avfilter/vf_vpp_qsv: add scale mode option
Hi Andreas,On Wed, Aug 4, 2021 at 8:30 AM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Linjie Fu: > > On Wed, Mar 24, 2021 at 2:15 PM Wang, Fei W > wrote: > > > >> On Mon, 2021-03-22 at 20:12 +0800, Linjie Fu wrote: > >>> On Wed, Feb 24, 2021 at 9:44 AM Fei Wang > >>> wrote: > >>>> > >>>> The option allow user to set diffenent scaling mode from > >>>> auto/low-power/high-quality. > >>>> > >>>> More details: > >>>> > >> > >> > https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#mfxExtVPPScaling > >>>> > >>>> Signed-off-by: Fei Wang > >>>> --- > >>>> libavfilter/vf_vpp_qsv.c | 25 +++-- > >>>> 1 file changed, 23 insertions(+), 2 deletions(-) > >>>> > >>>> diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c > >>>> index 5d57707455..effc459d3b 100644 > >>>> --- a/libavfilter/vf_vpp_qsv.c > >>>> +++ b/libavfilter/vf_vpp_qsv.c > >>>> @@ -43,8 +43,9 @@ > >>>> > >>>> /* number of video enhancement filters */ > >>>> #define ENH_FILTERS_COUNT (7) > > You forgot to increment this number; see > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283004.html Thanks for the reminder, patch lgtm. ___ 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 4/4] fftools/cmdutils: pass sws_flags to scale filter in simple filter graph
On Tue, Aug 3, 2021 at 1:07 AM Nicolas George wrote:
> Linjie Fu (12021-08-03):
> > From: Linjie Fu
> >
> > Pass sws_flags to scale filter through scale_sws_opts and correct the
> > dumped flags information.
> >
> > CMD:
> > $ffmpeg -v verbose -i input.mp4 -sws_flags lanczos+bitexact+accurate_rnd
> \
> > -vf format=yuv420p,scale=800x600 -an -vframes 10 -f md5 -
> >
> > Before:
> > [auto_scaler_0 @ 0x7f899a418780] w:iw h:ih flags:'bilinear' interl:0
> > [auto_scaler_0 @ 0x7f899a418780] w:1920 h:1080 fmt:yuvj420p sar:0/1 ->
> w:1920 h:1080 fmt:yuv420p sar:0/1 flags:0x2
> > [Parsed_scale_1 @ 0x7f899a417100] w:1920 h:1080 fmt:yuv420p sar:0/1 ->
> w:800 h:600 fmt:yuv420p sar:0/1 flags:0x2
> > MD5=ff1d6091690c6fcd36d458d2a9f648ce
> >
> > After:
> > [auto_scaler_0 @ 0x7fc7a3a06080] w:iw h:ih
> flags:'lanczos+bitexact+accurate_rnd' interl:0
> > [auto_scaler_0 @ 0x7fc7a3a06080] w:1920 h:1080 fmt:yuvj420p sar:0/1 ->
> w:1920 h:1080 fmt:yuv420p sar:0/1 flags:0xc0200
> > [Parsed_scale_1 @ 0x7fc7a3a04780] w:1920 h:1080 fmt:yuv420p sar:0/1 ->
> w:800 h:600 fmt:yuv420p sar:0/1 flags:0xc0200
> > MD5=ff1d6091690c6fcd36d458d2a9f648ce
> >
> > Signed-off-by: Linjie Fu
> > ---
> > fftools/ffmpeg_filter.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> > index 958d74f008..94838adc56 100644
> > --- a/fftools/ffmpeg_filter.c
> > +++ b/fftools/ffmpeg_filter.c
> > @@ -977,7 +977,11 @@ int configure_filtergraph(FilterGraph *fg)
> > }
> > if (strlen(args))
> > args[strlen(args)-1] = 0;
>
> > -fg->graph->scale_sws_opts = av_strdup(args);
> > +
> > +if (!strncmp(args, "sws_flags=", 10)) {
> > +// keep the 'flags=' part
> > +fg->graph->scale_sws_opts = av_strdup(args+4);
> > +}
>
> What? This code does not seem to match the commit message. More
> explanation needed.
>
> >
> > args[0] = 0;
> > while ((e = av_dict_get(ost->swr_opts, "", e,
>
> Regards,
>
Fixed the commit message and updated the patch set, thx.
- linjie
___
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 3/4] libswscale/utils: simplify the default scaler logic
On Tue, Aug 3, 2021 at 1:02 AM Nicolas George wrote: > Linjie Fu (12021-08-03): > > From: Linjie Fu > > > > Signed-off-by: Linjie Fu > > --- > > libswscale/utils.c | 7 +-- > > 1 file changed, 1 insertion(+), 6 deletions(-) > > Nack. The original logic needs to be evaluated to see if the others > scalers are better. > Okay, I'll leave it as is for now until we get enough evaluations. - linjie ___ 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 v3 2/2] fftools/ffmpeg_filter: fix the flags parsing for scaler
From: Linjie Fu
Scaler relys on "-sws_flags" option to pass the flags to swscale
and scale filter. Currently passing "sws_flags=xxx" as a filter
option to scaler leads to an incorrect option parsing.
Check and change the string to "flags=xxx" and dumped flags information.
(Refer to parse_sws_flags())
CMD:
$ffmpeg -v verbose -i input.mp4 -sws_flags lanczos+bitexact+accurate_rnd \
-vf format=yuv420p,scale=800x600 -an -vframes 10 -f md5 -
Before:
[auto_scaler_0 @ 0x7f96c3808680] w:iw h:ih flags:'' interl:0
[auto_scaler_0 @ 0x7f96c3808680] w:1920 h:1080 fmt:yuvj420p sar:0/1 -> w:1920
h:1080 fmt:yuv420p sar:0/1 flags:0x0
[Parsed_scale_1 @ 0x7f96c3806e40] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0x0
MD5=ff1d6091690c6fcd36d458d2a9f648ce
After:
[auto_scaler_0 @ 0x7fe94563b4c0] w:iw h:ih
flags:'lanczos+bitexact+accurate_rnd' interl:0
[auto_scaler_0 @ 0x7fe94563b4c0] w:1920 h:1080 fmt:yuvj420p sar:0/1 -> w:1920
h:1080 fmt:yuv420p sar:0/1 flags:0xc0200
[Parsed_scale_1 @ 0x7fe945639d00] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0xc0200
MD5=ff1d6091690c6fcd36d458d2a9f648ce
Signed-off-by: Linjie Fu
---
fftools/ffmpeg_filter.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 958d74f008..94838adc56 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -977,7 +977,11 @@ int configure_filtergraph(FilterGraph *fg)
}
if (strlen(args))
args[strlen(args)-1] = 0;
-fg->graph->scale_sws_opts = av_strdup(args);
+
+if (!strncmp(args, "sws_flags=", 10)) {
+// keep the 'flags=' part
+fg->graph->scale_sws_opts = av_strdup(args+4);
+}
args[0] = 0;
while ((e = av_dict_get(ost->swr_opts, "", e,
--
2.31.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 v3 1/2] lavfi/vf_scale: use default swscale flags for simple and complex filter graph
From: Linjie Fu
Currently the default swscale flags for simple filter graph is bicubic,
however for complex filter graph it uses bilinear as decleared in scale
filter.
$ffmpeg -v verbose -i input.mp4 -vf format=yuv420p,scale=800x600 -an -f null -
[Parsed_scale_1 @ 0x7f86d2c160c0] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0x4
$ffmpeg -v verbose -i input.mp4 -filter_complex format=yuv420p,scale=800x600
-an -f null -
[Parsed_scale_1 @ 0x7f8779e046c0] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0x2
Use default swscale flags (bicubic currently) for scale filter.
- Remove flags="bilinear" from vf_scale
- Remove setting defaults in ffmpeg/ffprobe/ffplay
- Update the FATE refs
Signed-off-by: Linjie Fu
---
fftools/cmdutils.c | 8
fftools/ffplay.c| 2 --
fftools/ffprobe.c | 1 -
libavfilter/vf_scale.c | 4 ++--
tests/ref/fate/filter-scale2ref_keep_aspect | 10 +-
5 files changed, 7 insertions(+), 18 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 0b1ef03a25..912e881174 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -81,11 +81,6 @@ enum show_muxdemuxers {
SHOW_MUXERS,
};
-void init_opts(void)
-{
-av_dict_set(_dict, "flags", "bicubic", 0);
-}
-
void uninit_opts(void)
{
av_dict_free(_opts);
@@ -670,7 +665,6 @@ static void finish_group(OptionParseContext *octx, int
group_idx,
resample_opts = NULL;
sws_dict= NULL;
swr_opts= NULL;
-init_opts();
memset(>cur_group, 0, sizeof(octx->cur_group));
}
@@ -708,8 +702,6 @@ static void init_parse_context(OptionParseContext *octx,
octx->global_opts.group_def = _group;
octx->global_opts.arg = "";
-
-init_opts();
}
void uninit_parse_context(OptionParseContext *octx)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 6b19574eae..46758b9f55 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -3695,8 +3695,6 @@ int main(int argc, char **argv)
#endif
avformat_network_init();
-init_opts();
-
signal(SIGINT , sigterm_handler); /* Interrupt (ANSI).*/
signal(SIGTERM, sigterm_handler); /* Termination (ANSI). */
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index f411ba35b5..95263e1e6f 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -3721,7 +3721,6 @@ int main(int argc, char **argv)
options = real_options;
parse_loglevel(argc, argv, options);
avformat_network_init();
-init_opts();
#if CONFIG_AVDEVICE
avdevice_register_all();
#endif
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index f07e01bf90..683c4caa37 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -313,7 +313,7 @@ static av_cold int init_dict(AVFilterContext *ctx,
AVDictionary **opts)
scale->flags = 0;
-if (scale->flags_str) {
+if (*scale->flags_str) {
const AVClass *class = sws_get_class();
const AVOption*o = av_opt_find(, "sws_flags", NULL, 0,
AV_OPT_SEARCH_FAKE_OBJ);
@@ -900,7 +900,7 @@ static const AVOption scale_options[] = {
{ "width", "Output video width", OFFSET(w_expr),
AV_OPT_TYPE_STRING,.flags = TFLAGS },
{ "h", "Output video height", OFFSET(h_expr),
AV_OPT_TYPE_STRING,.flags = TFLAGS },
{ "height","Output video height", OFFSET(h_expr),
AV_OPT_TYPE_STRING,.flags = TFLAGS },
-{ "flags", "Flags to pass to libswscale", OFFSET(flags_str),
AV_OPT_TYPE_STRING, { .str = "bilinear" }, .flags = FLAGS },
+{ "flags", "Flags to pass to libswscale", OFFSET(flags_str),
AV_OPT_TYPE_STRING, { .str = "" }, .flags = FLAGS },
{ "interl", "set interlacing", OFFSET(interlaced), AV_OPT_TYPE_BOOL, {.i64
= 0 }, -1, 1, FLAGS },
{ "size", "set video size", OFFSET(size_str),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, FLAGS },
{ "s", "set video size", OFFSET(size_str),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, FLAGS },
diff --git a/tests/ref/fate/filter-scale2ref_keep_aspect
b/tests/ref/fate/filter-scale2ref_keep_aspect
index 8dd0dbb13b..53c6fc14ec 100644
--- a/tests/ref/fate/filter-scale2ref_keep_aspect
+++ b/tests/ref/fate/filter-scale2ref_keep_aspect
@@ -7,8 +7,8 @@
#dimensions 0: 160x120
#sar 0: 1/1
#stream#, dts,pts, duration, size, hash
-0, 0, 0,1,57600, 9a19c23dc3a557786840d0098606d5f1
-0, 1, 1,1,57600, e6fbdabaf1bb0d28afc648ed4d27e9f0
-0, 2, 2,
Re: [FFmpeg-devel] [PATCH v1] avfilter/vf_vpp_qsv: add scale mode option
On Wed, Mar 24, 2021 at 2:15 PM Wang, Fei W wrote:
> On Mon, 2021-03-22 at 20:12 +0800, Linjie Fu wrote:
> > On Wed, Feb 24, 2021 at 9:44 AM Fei Wang
> > wrote:
> > >
> > > The option allow user to set diffenent scaling mode from
> > > auto/low-power/high-quality.
> > >
> > > More details:
> > >
>
> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#mfxExtVPPScaling
> > >
> > > Signed-off-by: Fei Wang
> > > ---
> > > libavfilter/vf_vpp_qsv.c | 25 +++--
> > > 1 file changed, 23 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> > > index 5d57707455..effc459d3b 100644
> > > --- a/libavfilter/vf_vpp_qsv.c
> > > +++ b/libavfilter/vf_vpp_qsv.c
> > > @@ -43,8 +43,9 @@
> > >
> > > /* number of video enhancement filters */
> > > #define ENH_FILTERS_COUNT (7)
> > > -#define QSV_HAVE_ROTATION QSV_VERSION_ATLEAST(1, 17)
> > > -#define QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
> > > +#define QSV_HAVE_ROTATION QSV_VERSION_ATLEAST(1, 17)
> > > +#define QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
> > > +#define QSV_HAVE_SCALING_CONFIG QSV_VERSION_ATLEAST(1, 19)
> > >
> > > typedef struct VPPContext{
> > > const AVClass *class;
> > > @@ -59,6 +60,9 @@ typedef struct VPPContext{
> > > mfxExtVPPProcAmp procamp_conf;
> > > mfxExtVPPRotation rotation_conf;
> > > mfxExtVPPMirroring mirroring_conf;
> > > +#ifdef QSV_HAVE_SCALING_CONFIG
> > > +mfxExtVPPScaling scale_conf;
> > > +#endif
> > >
> > > int out_width;
> > > int out_height;
> > > @@ -83,6 +87,8 @@ typedef struct VPPContext{
> > > int rotate; /* rotate angle : [0, 90, 180,
> > > 270] */
> > > int hflip; /* flip mode : 0 = off, 1 =
> > > HORIZONTAL flip */
> > >
> > > +int scale_mode; /* scale mode : 0 = auto, 1 = low
> > > power, 2 = high quality */
> > > +
> > > /* param for the procamp */
> > > intprocamp;/* enable procamp */
> > > float hue;
> > > @@ -128,6 +134,7 @@ static const AVOption options[] = {
> > > { "h", "Output video height", OFFSET(oh),
> > > AV_OPT_TYPE_STRING, { .str="w*ch/cw" }, 0, 255, .flags = FLAGS },
> > > { "height", "Output video height", OFFSET(oh),
> > > AV_OPT_TYPE_STRING, { .str="w*ch/cw" }, 0, 255, .flags = FLAGS },
> > > { "format", "Output pixel format", OFFSET(output_format_str),
> > > AV_OPT_TYPE_STRING, { .str = "same" }, .flags = FLAGS },
> > > +{ "scale_mode", "scale mode: 0=auto, 1=low power, 2=high
> > > quality", OFFSET(scale_mode), AV_OPT_TYPE_INT, { .i64 =
> > > MFX_SCALING_MODE_DEFAULT }, MFX_SCALING_MODE_DEFAULT,
> > > MFX_SCALING_MODE_QUALITY, .flags = FLAGS, "scale mode" },
> > >
> > > { NULL }
> > > };
> > > @@ -454,6 +461,20 @@ static int config_output(AVFilterLink
> > > *outlink)
> > > #endif
> > > }
> > >
> > > +if (inlink->w != outlink->w || inlink->h != outlink->h) {
> > > +#ifdef QSV_HAVE_SCALING_CONFIG
> > > +memset(>scale_conf, 0, sizeof(mfxExtVPPScaling));
> > > +vpp->scale_conf.Header.BufferId=
> > > MFX_EXTBUFF_VPP_SCALING;
> > > +vpp->scale_conf.Header.BufferSz=
> > > sizeof(mfxExtVPPScaling);
> > > +vpp->scale_conf.ScalingMode= vpp->scale_mode;
> > > +
> > > +param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)
> > > >scale_conf;
> > > +#else
> > > +av_log(ctx, AV_LOG_WARNING, "The QSV VPP Scale option is "
> > > +"not supported with this MSDK version.\n");
> > > +#endif
> > > +}
> > > +
> > > if (vpp->use_frc || vpp->use_crop || vpp->deinterlace || vpp-
> > > >denoise ||
> > > vpp->detail || vpp->procamp || vpp->rotate || vpp->hflip
> > > ||
> > > inlink->w != outlink->w || inlink->h != outlink->h ||
> > > in_format != vpp->out_format)
> > > --
> > > 2.17.1
> > >
> >
> > Looks reasonable, and it seems the default behaviour is QUALITY mode
> > on all platforms except for APL:
>
> That's right. If scale_mode is set to auto, MSDK will choose different
> mode(high-quality/low-power) on different platform.
>
Applied, thx.
- linjie
___
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] fftools/cmdutils: make the default swscale flags identical for simple and complex filter graph
On Tue, Aug 3, 2021 at 12:48 AM Michael Niedermayer wrote: > On Sun, Aug 01, 2021 at 04:08:17PM +0200, Nicolas George wrote: > > Linjie Fu (12021-08-01): > > > Checked swscale, it uses bicubic by default. > > > Scale filter sets the flags to bilinear if sws_scale_opt is not > initialized > > > by sws_dict. > > > > > > We should use the same default flags for both simple and complex filter > > > graphs, either from swscale, or from scale filter. > > > If prefer to keep it identical with swscale, we may modify the flags > in the > > > scale filter. > > > > Thanks. I also think that unless there is a good reason, we should rely > > on a single default, from the lowest level. So: > > > > - remove flags="bilinear" from vf_scale; > > > > - remove setting defaults in ffmpeg. > > > > Unless somebody can find a good reason for different defaults. > Michael, it is your commit, 8155bbc944c314fc202d31b0e4a3c77b8efc8dde, > > that introduced it. Any comments? > > > > Also, the current code in libswscale looks nonsensical: > > > > if (dstW < srcW && dstH < srcH) > > flags |= SWS_BICUBIC; > > else if (dstW > srcW && dstH > srcH) > > flags |= SWS_BICUBIC; > > else > > flags |= SWS_BICUBIC; > > > > It was originally 6b3ff6f91a535d6383f41ca7bdf760165dcb6015 with some > > logic, but it was cancelled by the merge commit > > 5710f55e490d0c3cf7348b3ca91c8c0fe4274be2. > > > "The default is left at bicubic until someone has compared the scalers > > properly speed and quality wise." > > > > But eight years later nobody did. > > In case someone tests this, it should test > 1. human subjective quality in addition to some objective quality > 2. scaling + compression > 3. various material, noisy and less crisp material may favor >different scalers than super flawless crisp images Just update the patch set as suggested and keep the default to "bicubic" for now, until we get a better choice, thx. - linjie ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/4] FATE: Update test refs for scale used in filter complex
Hi Andreas, On Tue, Aug 3, 2021 at 12:50 AM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Linjie Fu: > > From: Linjie Fu > > > > Since we prefer to use bicubic flags for scale filter to keep pace with > > swscale. > > > > Signed-off-by: Linjie Fu > > --- > > tests/ref/fate/filter-scale2ref_keep_aspect | 10 +- > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/tests/ref/fate/filter-scale2ref_keep_aspect > b/tests/ref/fate/filter-scale2ref_keep_aspect > > index 8dd0dbb13b..53c6fc14ec 100644 > > --- a/tests/ref/fate/filter-scale2ref_keep_aspect > > +++ b/tests/ref/fate/filter-scale2ref_keep_aspect > > @@ -7,8 +7,8 @@ > > #dimensions 0: 160x120 > > #sar 0: 1/1 > > #stream#, dts,pts, duration, size, hash > > -0, 0, 0,1,57600, > 9a19c23dc3a557786840d0098606d5f1 > > -0, 1, 1,1,57600, > e6fbdabaf1bb0d28afc648ed4d27e9f0 > > -0, 2, 2,1,57600, > 52924ed0a751214c50fb2e7a626c8cc5 > > -0, 3, 3,1,57600, > 67d5fd6ee71793f1cf8794d1c27afdce > > -0, 4, 4,1,57600, > 85f7775f7b01afd369fc8919dc759d30 > > +0, 0, 0,1,57600, > 65fe9892ad710cc5763b04b390327d40 > > +0, 1, 1,1,57600, > 5e8d4524bc8889afa8769e851e998bc0 > > +0, 2, 2,1,57600, > 8f5e0e58d1f4c2104b82ef7a16850f1e > > +0, 3, 3,1,57600, > cfe4142845e1445d33748493faa63cda > > +0, 4, 4,1,57600, > bb491f3b01788773fb6129aef0f0abd2 > > > Changes to FATE should be in the same patch that warrants this; in your > case: In the patch that switches the scale filter. Otherwise you break > FATE in this commit and fix it in a later commit. Thanks for the hints, merged locally. - linjie ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 4/4] fftools/cmdutils: pass sws_flags to scale filter in simple filter graph
From: Linjie Fu
Pass sws_flags to scale filter through scale_sws_opts and correct the
dumped flags information.
CMD:
$ffmpeg -v verbose -i input.mp4 -sws_flags lanczos+bitexact+accurate_rnd \
-vf format=yuv420p,scale=800x600 -an -vframes 10 -f md5 -
Before:
[auto_scaler_0 @ 0x7f899a418780] w:iw h:ih flags:'bilinear' interl:0
[auto_scaler_0 @ 0x7f899a418780] w:1920 h:1080 fmt:yuvj420p sar:0/1 -> w:1920
h:1080 fmt:yuv420p sar:0/1 flags:0x2
[Parsed_scale_1 @ 0x7f899a417100] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0x2
MD5=ff1d6091690c6fcd36d458d2a9f648ce
After:
[auto_scaler_0 @ 0x7fc7a3a06080] w:iw h:ih
flags:'lanczos+bitexact+accurate_rnd' interl:0
[auto_scaler_0 @ 0x7fc7a3a06080] w:1920 h:1080 fmt:yuvj420p sar:0/1 -> w:1920
h:1080 fmt:yuv420p sar:0/1 flags:0xc0200
[Parsed_scale_1 @ 0x7fc7a3a04780] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0xc0200
MD5=ff1d6091690c6fcd36d458d2a9f648ce
Signed-off-by: Linjie Fu
---
fftools/ffmpeg_filter.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 958d74f008..94838adc56 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -977,7 +977,11 @@ int configure_filtergraph(FilterGraph *fg)
}
if (strlen(args))
args[strlen(args)-1] = 0;
-fg->graph->scale_sws_opts = av_strdup(args);
+
+if (!strncmp(args, "sws_flags=", 10)) {
+// keep the 'flags=' part
+fg->graph->scale_sws_opts = av_strdup(args+4);
+}
args[0] = 0;
while ((e = av_dict_get(ost->swr_opts, "", e,
--
2.31.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 v2 3/4] libswscale/utils: simplify the default scaler logic
From: Linjie Fu
Signed-off-by: Linjie Fu
---
libswscale/utils.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 176fc6fd63..dea3b76eb3 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1250,12 +1250,7 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter
*srcFilter,
/* provide a default scaler if not set by caller */
if (!i) {
-if (dstW < srcW && dstH < srcH)
-flags |= SWS_BICUBIC;
-else if (dstW > srcW && dstH > srcH)
-flags |= SWS_BICUBIC;
-else
-flags |= SWS_BICUBIC;
+flags |= SWS_BICUBIC;
c->flags = flags;
} else if (i & (i - 1)) {
av_log(c, AV_LOG_ERROR,
--
2.31.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 v2 2/4] lavfi/vf_scale: use single default swscale flags for simple and complex filter graph
From: Linjie Fu
Currently the default swscale flags for simple filter graph is bicubic,
however for complex filter graph it uses bilinear as decleared in scale
filter.
$ffmpeg -v verbose -i input.mp4 -vf format=yuv420p,scale=800x600 -an -f null -
[Parsed_scale_1 @ 0x7f86d2c160c0] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0x4
$ffmpeg -v verbose -i input.mp4 -filter_complex format=yuv420p,scale=800x600
-an -f null -
[Parsed_scale_1 @ 0x7f8779e046c0] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0x2
Set the default flags for scale filter to "bicubic" to match the behaviour in
swscale.
And remove setting defaults in ffmpeg/ffprobe/ffplay.
Signed-off-by: Linjie Fu
---
fftools/cmdutils.c | 8
fftools/ffplay.c | 2 --
fftools/ffprobe.c | 1 -
libavfilter/vf_scale.c | 2 +-
4 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 0b1ef03a25..912e881174 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -81,11 +81,6 @@ enum show_muxdemuxers {
SHOW_MUXERS,
};
-void init_opts(void)
-{
-av_dict_set(_dict, "flags", "bicubic", 0);
-}
-
void uninit_opts(void)
{
av_dict_free(_opts);
@@ -670,7 +665,6 @@ static void finish_group(OptionParseContext *octx, int
group_idx,
resample_opts = NULL;
sws_dict= NULL;
swr_opts= NULL;
-init_opts();
memset(>cur_group, 0, sizeof(octx->cur_group));
}
@@ -708,8 +702,6 @@ static void init_parse_context(OptionParseContext *octx,
octx->global_opts.group_def = _group;
octx->global_opts.arg = "";
-
-init_opts();
}
void uninit_parse_context(OptionParseContext *octx)
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 6b19574eae..46758b9f55 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -3695,8 +3695,6 @@ int main(int argc, char **argv)
#endif
avformat_network_init();
-init_opts();
-
signal(SIGINT , sigterm_handler); /* Interrupt (ANSI).*/
signal(SIGTERM, sigterm_handler); /* Termination (ANSI). */
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index f411ba35b5..95263e1e6f 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -3721,7 +3721,6 @@ int main(int argc, char **argv)
options = real_options;
parse_loglevel(argc, argv, options);
avformat_network_init();
-init_opts();
#if CONFIG_AVDEVICE
avdevice_register_all();
#endif
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index f07e01bf90..3029ab4b68 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -900,7 +900,7 @@ static const AVOption scale_options[] = {
{ "width", "Output video width", OFFSET(w_expr),
AV_OPT_TYPE_STRING,.flags = TFLAGS },
{ "h", "Output video height", OFFSET(h_expr),
AV_OPT_TYPE_STRING,.flags = TFLAGS },
{ "height","Output video height", OFFSET(h_expr),
AV_OPT_TYPE_STRING,.flags = TFLAGS },
-{ "flags", "Flags to pass to libswscale", OFFSET(flags_str),
AV_OPT_TYPE_STRING, { .str = "bilinear" }, .flags = FLAGS },
+{ "flags", "Flags to pass to libswscale", OFFSET(flags_str),
AV_OPT_TYPE_STRING, { .str = "bicubic" }, .flags = FLAGS },
{ "interl", "set interlacing", OFFSET(interlaced), AV_OPT_TYPE_BOOL, {.i64
= 0 }, -1, 1, FLAGS },
{ "size", "set video size", OFFSET(size_str),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, FLAGS },
{ "s", "set video size", OFFSET(size_str),
AV_OPT_TYPE_STRING, {.str = NULL}, 0, FLAGS },
--
2.31.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 v2 1/4] FATE: Update test refs for scale used in filter complex
From: Linjie Fu Since we prefer to use bicubic flags for scale filter to keep pace with swscale. Signed-off-by: Linjie Fu --- tests/ref/fate/filter-scale2ref_keep_aspect | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tests/ref/fate/filter-scale2ref_keep_aspect b/tests/ref/fate/filter-scale2ref_keep_aspect index 8dd0dbb13b..53c6fc14ec 100644 --- a/tests/ref/fate/filter-scale2ref_keep_aspect +++ b/tests/ref/fate/filter-scale2ref_keep_aspect @@ -7,8 +7,8 @@ #dimensions 0: 160x120 #sar 0: 1/1 #stream#, dts,pts, duration, size, hash -0, 0, 0,1,57600, 9a19c23dc3a557786840d0098606d5f1 -0, 1, 1,1,57600, e6fbdabaf1bb0d28afc648ed4d27e9f0 -0, 2, 2,1,57600, 52924ed0a751214c50fb2e7a626c8cc5 -0, 3, 3,1,57600, 67d5fd6ee71793f1cf8794d1c27afdce -0, 4, 4,1,57600, 85f7775f7b01afd369fc8919dc759d30 +0, 0, 0,1,57600, 65fe9892ad710cc5763b04b390327d40 +0, 1, 1,1,57600, 5e8d4524bc8889afa8769e851e998bc0 +0, 2, 2,1,57600, 8f5e0e58d1f4c2104b82ef7a16850f1e +0, 3, 3,1,57600, cfe4142845e1445d33748493faa63cda +0, 4, 4,1,57600, bb491f3b01788773fb6129aef0f0abd2 -- 2.31.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 1/2] fftools/cmdutils: make the default swscale flags identical for simple and complex filter graph
On Sun, Aug 1, 2021 at 10:13 PM Gyan Doshi wrote: > > > On 2021-08-01 19:19, Linjie Fu wrote: > > On Sun, Aug 1, 2021 at 9:25 PM Nicolas George wrote: > > > >> Linjie Fu (12021-08-01): > >>> From: Linjie Fu > >>> > >>> Currently the default swscale flags for simple filter graph is bicubic, > >>> however for complex filter graph it uses bilinear as decleared in scale > >>> filter. > >> Why does ffmpeg set a default different from swscale? > >> > > Checked swscale, it uses bicubic by default. > > Scale filter sets the flags to bilinear if sws_scale_opt is not > initialized > > by sws_dict. > > > > We should use the same default flags for both simple and complex filter > > graphs, either from swscale, or from scale filter. > > If prefer to keep it identical with swscale, we may modify the flags in > the > > scale filter. > > Keeping bicubic the default is best. > > You'll need to update the refs for all the failed FATE tests. Got the point, bicubic seems more reasonable if taking FATE tests into account. Let's wait for more comments, and maybe do some code clean too for libswscale as Nicolas has pointed out. - linjie ___ 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] fftools/cmdutils: make the default swscale flags identical for simple and complex filter graph
On Sun, Aug 1, 2021 at 9:25 PM Nicolas George wrote: > Linjie Fu (12021-08-01): > > From: Linjie Fu > > > > Currently the default swscale flags for simple filter graph is bicubic, > > however for complex filter graph it uses bilinear as decleared in scale > > filter. > > Why does ffmpeg set a default different from swscale? > Checked swscale, it uses bicubic by default. Scale filter sets the flags to bilinear if sws_scale_opt is not initialized by sws_dict. We should use the same default flags for both simple and complex filter graphs, either from swscale, or from scale filter. If prefer to keep it identical with swscale, we may modify the flags in the scale filter. - linjie ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] fftools/cmdutils: pass sws_flags to scale filter in simple filter graph
From: Linjie Fu
Pass sws_flags to scale filter through scale_sws_opts and correct the
dumped flags information.
CMD:
$ffmpeg -v verbose -i input.mp4 -sws_flags lanczos+bitexact+accurate_rnd \
-vf format=yuv420p,scale=800x600 -an -vframes 10 -f md5 -
Before:
[auto_scaler_0 @ 0x7f899a418780] w:iw h:ih flags:'bilinear' interl:0
[auto_scaler_0 @ 0x7f899a418780] w:1920 h:1080 fmt:yuvj420p sar:0/1 -> w:1920
h:1080 fmt:yuv420p sar:0/1 flags:0x2
[Parsed_scale_1 @ 0x7f899a417100] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0x2
MD5=ff1d6091690c6fcd36d458d2a9f648ce
After:
[auto_scaler_0 @ 0x7fc7a3a06080] w:iw h:ih
flags:'lanczos+bitexact+accurate_rnd' interl:0
[auto_scaler_0 @ 0x7fc7a3a06080] w:1920 h:1080 fmt:yuvj420p sar:0/1 -> w:1920
h:1080 fmt:yuv420p sar:0/1 flags:0xc0200
[Parsed_scale_1 @ 0x7fc7a3a04780] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0xc0200
MD5=ff1d6091690c6fcd36d458d2a9f648ce
Signed-off-by: Linjie Fu
---
fftools/cmdutils.c | 1 -
fftools/ffmpeg_filter.c | 6 +-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 56b8ada5b1..f4d9f5eafb 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -670,7 +670,6 @@ static void finish_group(OptionParseContext *octx, int
group_idx,
resample_opts = NULL;
sws_dict= NULL;
swr_opts= NULL;
-init_opts();
memset(>cur_group, 0, sizeof(octx->cur_group));
}
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 958d74f008..94838adc56 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -977,7 +977,11 @@ int configure_filtergraph(FilterGraph *fg)
}
if (strlen(args))
args[strlen(args)-1] = 0;
-fg->graph->scale_sws_opts = av_strdup(args);
+
+if (!strncmp(args, "sws_flags=", 10)) {
+// keep the 'flags=' part
+fg->graph->scale_sws_opts = av_strdup(args+4);
+}
args[0] = 0;
while ((e = av_dict_get(ost->swr_opts, "", e,
--
2.31.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] fftools/cmdutils: make the default swscale flags identical for simple and complex filter graph
From: Linjie Fu
Currently the default swscale flags for simple filter graph is bicubic,
however for complex filter graph it uses bilinear as decleared in scale
filter.
$ffmpeg -v verbose -i input.mp4 -vf format=yuv420p,scale=800x600 -an -f null -
[Parsed_scale_1 @ 0x7f86d2c160c0] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0x4
$ffmpeg -v verbose -i input.mp4 -filter_complex format=yuv420p,scale=800x600
-an -f null -
[Parsed_scale_1 @ 0x7f8779e046c0] w:1920 h:1080 fmt:yuv420p sar:0/1 -> w:800
h:600 fmt:yuv420p sar:0/1 flags:0x2
Set the default swscale flags for simple filter graph to bilinear to match
the description in scale filter.
Signed-off-by: Linjie Fu
---
fftools/cmdutils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 0b1ef03a25..56b8ada5b1 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -83,7 +83,7 @@ enum show_muxdemuxers {
void init_opts(void)
{
-av_dict_set(_dict, "flags", "bicubic", 0);
+av_dict_set(_dict, "flags", "bilinear", 0);
}
void uninit_opts(void)
--
2.31.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] fftools/ffmpeg: accelerate seeking while reading input at native frame rate
On Mon, Jul 19, 2021 at 3:32 PM Gyan Doshi wrote:
>
>
> On 2021-07-19 12:48, Gyan Doshi wrote:
> >
> >
> > On 2021-07-18 22:23, Linjie Fu wrote:
> >> On Sun, Jul 18, 2021 at 8:57 PM Gyan Doshi wrote:
> >>>
> >>>
> >>> On 2021-07-18 15:37, Linjie Fu wrote:
> >>>> On Sun, Jul 18, 2021 at 5:26 PM Gyan Doshi wrote:
> >>>>>
> >>>>> On 2021-07-18 13:35, Linjie Fu wrote:
> >>>>>> On Sun, Jul 18, 2021 at 1:21 PM Gyan Doshi
> wrote:
> >>>>>>> On 2021-07-18 10:42, Linjie Fu wrote:
> >>>>>>>> Hi Gyan,
> >>>>>>>> On Sun, Jul 18, 2021 at 12:24 PM Gyan Doshi
> >> wrote:
> >>>>>>>>> On 2021-07-18 09:32, Linjie Fu wrote:
> >>>>>>>>>> On Wed, Jul 7, 2021 at 9:42 AM Linjie Fu <
> >> linjie.justin...@gmail.com> wrote:
> >>>>>>>>>>> On Sun, Jul 4, 2021 at 10:50 PM Linjie Fu >
> >> wrote:
> >>>>>>>>>>>> From: Linjie Fu
> >>>>>>>>>>>>
> >>>>>>>>>>>> Skip the logic of frame rate emulation until the input reaches
> >> the
> >>>>>>>>>>>> specified start time.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Test CMD:
> >>>>>>>>>>>> $ffmpeg -re -ss 30 -i input.mp4 -pix_fmt yuv420p -f
> >>>>>>>>>>>> sdl2
> >> -
> >>>>>>>>>>>> Before the patch:
> >>>>>>>>>>>> first time to got frame, it takes 257305 us
> >>>>>>>>>>>> After this patch:
> >>>>>>>>>>>> first time to got frame, it takes 48879 us
> >>>>>>>>>>>>
> >>>>>>>>>>>> Signed-off-by: Linjie Fu
> >>>>>>>>>>>> ---
> >>>>>>>>>>>> [v2]: fixed the mixed declaration and code warning
> >>>>>>>>>>>> Calculate the time to get the first frame:
> >>>>>>>>>>>>
> >>
> https://github.com/fulinjie/ffmpeg/commit/2aa4762e1e65709997b1ab9dd596332244db80ed
> >>
> >>>>>>>>>>>> fftools/ffmpeg.c | 8 ++--
> >>>>>>>>>>>> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>>>>>>>>>>>
> >>>>>>>>>>>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> >>>>>>>>>>>> index e97d879cb3..c8849e4250 100644
> >>>>>>>>>>>> --- a/fftools/ffmpeg.c
> >>>>>>>>>>>> +++ b/fftools/ffmpeg.c
> >>>>>>>>>>>> @@ -4221,10 +4221,14 @@ static int get_input_packet(InputFile
> >> *f, AVPacket **pkt)
> >>>>>>>>>>>> {
> >>>>>>>>>>>> if (f->rate_emu) {
> >>>>>>>>>>>> int i;
> >>>>>>>>>>>> +int64_t pts;
> >>>>>>>>>>>> +int64_t now;
> >>>>>>>>>>>> for (i = 0; i < f->nb_streams; i++) {
> >>>>>>>>>>>> InputStream *ist =
> >>>>>>>>>>>> input_streams[f->ist_index
> >> + i];
> >>>>>>>>>>>> -int64_t pts = av_rescale(ist->dts, 100,
> >> AV_TIME_BASE);
> >>>>>>>>>>>> -int64_t now = av_gettime_relative() - ist->start;
> >>>>>>>>>>>> +if (!ist->got_output)
> >>>>>>>>>>>> +continue;
> >>>>>>>>>>>> +pts = av_rescale(ist->dts, 100,
> >>>>>>>>>>>> AV_TIME_BASE);
> >>>>>>>>>>>> +now = av_gettime_relative() - ist->start;
> >>>>>>>>>>>> if (pts > now)
> >>>>>>>>>>>>
Re: [FFmpeg-devel] [PATCH v2] fftools/ffmpeg: accelerate seeking while reading input at native frame rate
On Sun, Jul 18, 2021 at 8:57 PM Gyan Doshi wrote:
>
>
>
> On 2021-07-18 15:37, Linjie Fu wrote:
> > On Sun, Jul 18, 2021 at 5:26 PM Gyan Doshi wrote:
> >>
> >>
> >> On 2021-07-18 13:35, Linjie Fu wrote:
> >>> On Sun, Jul 18, 2021 at 1:21 PM Gyan Doshi wrote:
> >>>>
> >>>> On 2021-07-18 10:42, Linjie Fu wrote:
> >>>>> Hi Gyan,
> >>>>> On Sun, Jul 18, 2021 at 12:24 PM Gyan Doshi
wrote:
> >>>>>> On 2021-07-18 09:32, Linjie Fu wrote:
> >>>>>>> On Wed, Jul 7, 2021 at 9:42 AM Linjie Fu <
linjie.justin...@gmail.com> wrote:
> >>>>>>>> On Sun, Jul 4, 2021 at 10:50 PM Linjie Fu
wrote:
> >>>>>>>>> From: Linjie Fu
> >>>>>>>>>
> >>>>>>>>> Skip the logic of frame rate emulation until the input reaches
the
> >>>>>>>>> specified start time.
> >>>>>>>>>
> >>>>>>>>> Test CMD:
> >>>>>>>>>$ffmpeg -re -ss 30 -i input.mp4 -pix_fmt yuv420p -f sdl2
-
> >>>>>>>>>
> >>>>>>>>> Before the patch:
> >>>>>>>>> first time to got frame, it takes 257305 us
> >>>>>>>>> After this patch:
> >>>>>>>>> first time to got frame, it takes 48879 us
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Linjie Fu
> >>>>>>>>> ---
> >>>>>>>>> [v2]: fixed the mixed declaration and code warning
> >>>>>>>>> Calculate the time to get the first frame:
> >>>>>>>>>
https://github.com/fulinjie/ffmpeg/commit/2aa4762e1e65709997b1ab9dd596332244db80ed
> >>>>>>>>> fftools/ffmpeg.c | 8 ++--
> >>>>>>>>> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>>>>>>>>
> >>>>>>>>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> >>>>>>>>> index e97d879cb3..c8849e4250 100644
> >>>>>>>>> --- a/fftools/ffmpeg.c
> >>>>>>>>> +++ b/fftools/ffmpeg.c
> >>>>>>>>> @@ -4221,10 +4221,14 @@ static int get_input_packet(InputFile
*f, AVPacket **pkt)
> >>>>>>>>> {
> >>>>>>>>> if (f->rate_emu) {
> >>>>>>>>> int i;
> >>>>>>>>> +int64_t pts;
> >>>>>>>>> +int64_t now;
> >>>>>>>>> for (i = 0; i < f->nb_streams; i++) {
> >>>>>>>>> InputStream *ist = input_streams[f->ist_index
+ i];
> >>>>>>>>> -int64_t pts = av_rescale(ist->dts, 100,
AV_TIME_BASE);
> >>>>>>>>> -int64_t now = av_gettime_relative() - ist->start;
> >>>>>>>>> +if (!ist->got_output)
> >>>>>>>>> +continue;
> >>>>>>>>> +pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
> >>>>>>>>> +now = av_gettime_relative() - ist->start;
> >>>>>>>>> if (pts > now)
> >>>>>>>>> return AVERROR(EAGAIN);
> >>>>>>>>> }
> >>>>>>>>> --
> >>>>>>>>> 2.31.1
> >>>>>>>> ping, thx.
> >>>>>>>>
> >>>>>>> Another ping, thx.
> >>>>>> I pushed changes to this code yesterday. I don't think it's
required
> >>>>>> anymore, but do test.
> >>>>>>
> >>>>> Thanks for the review, tested after applying the readrate patch, I'm
> >>>>> afraid that it's not identical as hope,
> >>>>> since ist->nb_packets would increase no matter input stream got
output or not:
> >>>>>
> >>>>> (lldb) p ist->nb_packets
> >>>>> (uint64_t) $4 = 1
> >>>>>
> >>>>> (lldb) p ist->got_output
> >>>>> (int) $5 = 0
> >>>>>
> >
Re: [FFmpeg-devel] [PATCH v2] fftools/ffmpeg: accelerate seeking while reading input at native frame rate
On Sun, Jul 18, 2021 at 5:26 PM Gyan Doshi wrote:
>
>
>
> On 2021-07-18 13:35, Linjie Fu wrote:
> > On Sun, Jul 18, 2021 at 1:21 PM Gyan Doshi wrote:
> >>
> >>
> >> On 2021-07-18 10:42, Linjie Fu wrote:
> >>> Hi Gyan,
> >>> On Sun, Jul 18, 2021 at 12:24 PM Gyan Doshi wrote:
> >>>>
> >>>> On 2021-07-18 09:32, Linjie Fu wrote:
> >>>>> On Wed, Jul 7, 2021 at 9:42 AM Linjie Fu
> >>>>> wrote:
> >>>>>> On Sun, Jul 4, 2021 at 10:50 PM Linjie Fu wrote:
> >>>>>>> From: Linjie Fu
> >>>>>>>
> >>>>>>> Skip the logic of frame rate emulation until the input reaches the
> >>>>>>> specified start time.
> >>>>>>>
> >>>>>>> Test CMD:
> >>>>>>> $ffmpeg -re -ss 30 -i input.mp4 -pix_fmt yuv420p -f sdl2 -
> >>>>>>>
> >>>>>>> Before the patch:
> >>>>>>> first time to got frame, it takes 257305 us
> >>>>>>> After this patch:
> >>>>>>> first time to got frame, it takes 48879 us
> >>>>>>>
> >>>>>>> Signed-off-by: Linjie Fu
> >>>>>>> ---
> >>>>>>> [v2]: fixed the mixed declaration and code warning
> >>>>>>> Calculate the time to get the first frame:
> >>>>>>> https://github.com/fulinjie/ffmpeg/commit/2aa4762e1e65709997b1ab9dd596332244db80ed
> >>>>>>> fftools/ffmpeg.c | 8 ++--
> >>>>>>> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> >>>>>>> index e97d879cb3..c8849e4250 100644
> >>>>>>> --- a/fftools/ffmpeg.c
> >>>>>>> +++ b/fftools/ffmpeg.c
> >>>>>>> @@ -4221,10 +4221,14 @@ static int get_input_packet(InputFile *f,
> >>>>>>> AVPacket **pkt)
> >>>>>>> {
> >>>>>>> if (f->rate_emu) {
> >>>>>>> int i;
> >>>>>>> +int64_t pts;
> >>>>>>> +int64_t now;
> >>>>>>> for (i = 0; i < f->nb_streams; i++) {
> >>>>>>> InputStream *ist = input_streams[f->ist_index + i];
> >>>>>>> -int64_t pts = av_rescale(ist->dts, 100,
> >>>>>>> AV_TIME_BASE);
> >>>>>>> -int64_t now = av_gettime_relative() - ist->start;
> >>>>>>> +if (!ist->got_output)
> >>>>>>> +continue;
> >>>>>>> +pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
> >>>>>>> +now = av_gettime_relative() - ist->start;
> >>>>>>> if (pts > now)
> >>>>>>> return AVERROR(EAGAIN);
> >>>>>>> }
> >>>>>>> --
> >>>>>>> 2.31.1
> >>>>>> ping, thx.
> >>>>>>
> >>>>> Another ping, thx.
> >>>> I pushed changes to this code yesterday. I don't think it's required
> >>>> anymore, but do test.
> >>>>
> >>> Thanks for the review, tested after applying the readrate patch, I'm
> >>> afraid that it's not identical as hope,
> >>> since ist->nb_packets would increase no matter input stream got output or
> >>> not:
> >>>
> >>> (lldb) p ist->nb_packets
> >>> (uint64_t) $4 = 1
> >>>
> >>> (lldb) p ist->got_output
> >>> (int) $5 = 0
> >>>
> >>> Hence we still need to add the check for ist->got_output, or replace
> >>> the ist->nb_packets.
> >> No, test the speed, not the parity of got_output. got_output is only
> >> incremented when the stream is decoded.
> > The time interval consumed to get the first frame is tested as well,
> > it's not speeded up:
> > First time to get the frame, it takes 257395 us.
> > After adding the check for got_output in decoding scenery, this would
> > reduce to 48792 us.
> >
> > Hence it doesn't reduce the latency under decode scenery.
> >
> >> Won't work with streamcopy.
> > Got your point.
> >
> >> nb_packets is the correct check since it's incremented after the initial
> >> packet is demuxed.
> > IIRC, the initial packet is demuxed right after the first time we call
> > get_input_packet()-> av_read_frame(), and nb_packets would increase.
> > Hence, the check for ist->nb_packets would reduce the latency for
> > demuxing the first packet,
> > and won't help much if we use start_time like "-ss 30". Under the
> > decoding scenery, we still
> > need to wait until the pkt->pts specified time then demux the packet.
> >
> > If no objections, consider to change the check to:
> >
> > if (!ist->nb_packets || (!ist->got_output && ist->decoding_needed))
> > continue;
> >
> > to reduce the waiting time for:
> > 1. demuxing the first packet (if any)
> > 2. demuxing the packet before we got the first decoded output.
>
> Which sample file are you using, and how do I reproduce the timings?
>
It could be reproduced with a random input file (if long enough), and
the time calculating method I used previously (needs to rebase a
little bit for now):
https://github.com/fulinjie/ffmpeg/commit/2aa4762e1e65709997b1ab9dd596332244db80ed
CMD:
$ffmpeg -re -ss 30 -i input.mp4 -pix_fmt yuv420p -f sdl2 -
or
$ffmpeg -re -ss 30 -i input.mp4 -f null -
- linjie
___
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] fftools/ffmpeg: accelerate seeking while reading input at native frame rate
On Sun, Jul 18, 2021 at 1:21 PM Gyan Doshi wrote:
>
>
>
> On 2021-07-18 10:42, Linjie Fu wrote:
> > Hi Gyan,
> > On Sun, Jul 18, 2021 at 12:24 PM Gyan Doshi wrote:
> >>
> >>
> >> On 2021-07-18 09:32, Linjie Fu wrote:
> >>> On Wed, Jul 7, 2021 at 9:42 AM Linjie Fu
> >>> wrote:
> >>>> On Sun, Jul 4, 2021 at 10:50 PM Linjie Fu wrote:
> >>>>> From: Linjie Fu
> >>>>>
> >>>>> Skip the logic of frame rate emulation until the input reaches the
> >>>>> specified start time.
> >>>>>
> >>>>> Test CMD:
> >>>>> $ffmpeg -re -ss 30 -i input.mp4 -pix_fmt yuv420p -f sdl2 -
> >>>>>
> >>>>> Before the patch:
> >>>>> first time to got frame, it takes 257305 us
> >>>>> After this patch:
> >>>>> first time to got frame, it takes 48879 us
> >>>>>
> >>>>> Signed-off-by: Linjie Fu
> >>>>> ---
> >>>>> [v2]: fixed the mixed declaration and code warning
> >>>>> Calculate the time to get the first frame:
> >>>>> https://github.com/fulinjie/ffmpeg/commit/2aa4762e1e65709997b1ab9dd596332244db80ed
> >>>>>fftools/ffmpeg.c | 8 ++--
> >>>>>1 file changed, 6 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> >>>>> index e97d879cb3..c8849e4250 100644
> >>>>> --- a/fftools/ffmpeg.c
> >>>>> +++ b/fftools/ffmpeg.c
> >>>>> @@ -4221,10 +4221,14 @@ static int get_input_packet(InputFile *f,
> >>>>> AVPacket **pkt)
> >>>>>{
> >>>>>if (f->rate_emu) {
> >>>>>int i;
> >>>>> +int64_t pts;
> >>>>> +int64_t now;
> >>>>>for (i = 0; i < f->nb_streams; i++) {
> >>>>>InputStream *ist = input_streams[f->ist_index + i];
> >>>>> -int64_t pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
> >>>>> -int64_t now = av_gettime_relative() - ist->start;
> >>>>> +if (!ist->got_output)
> >>>>> +continue;
> >>>>> +pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
> >>>>> +now = av_gettime_relative() - ist->start;
> >>>>>if (pts > now)
> >>>>>return AVERROR(EAGAIN);
> >>>>>}
> >>>>> --
> >>>>> 2.31.1
> >>>> ping, thx.
> >>>>
> >>> Another ping, thx.
> >> I pushed changes to this code yesterday. I don't think it's required
> >> anymore, but do test.
> >>
> > Thanks for the review, tested after applying the readrate patch, I'm
> > afraid that it's not identical as hope,
> > since ist->nb_packets would increase no matter input stream got output or
> > not:
> >
> > (lldb) p ist->nb_packets
> > (uint64_t) $4 = 1
> >
> > (lldb) p ist->got_output
> > (int) $5 = 0
> >
> > Hence we still need to add the check for ist->got_output, or replace
> > the ist->nb_packets.
>
> No, test the speed, not the parity of got_output. got_output is only
> incremented when the stream is decoded.
The time interval consumed to get the first frame is tested as well,
it's not speeded up:
First time to get the frame, it takes 257395 us.
After adding the check for got_output in decoding scenery, this would
reduce to 48792 us.
Hence it doesn't reduce the latency under decode scenery.
> Won't work with streamcopy.
Got your point.
> nb_packets is the correct check since it's incremented after the initial
> packet is demuxed.
IIRC, the initial packet is demuxed right after the first time we call
get_input_packet()-> av_read_frame(), and nb_packets would increase.
Hence, the check for ist->nb_packets would reduce the latency for
demuxing the first packet,
and won't help much if we use start_time like "-ss 30". Under the
decoding scenery, we still
need to wait until the pkt->pts specified time then demux the packet.
If no objections, consider to change the check to:
if (!ist->nb_packets || (!ist->got_output && ist->decoding_needed)) continue;
to reduce the waiting time for:
1. demuxing the first packet (if any)
2. demuxing the packet before we got the first decoded output.
> > Also there is a new warning caught by the check in patchwork, probably
> > "mixed declaration and code warning".
> > Will send patches to rebase and fix.
>
> There is already patch for the mixed warning.
Saw it, thx.
- linjie
___
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] fftools/ffmpeg: accelerate seeking while reading input at native frame rate
Hi Gyan,
On Sun, Jul 18, 2021 at 12:24 PM Gyan Doshi wrote:
>
>
>
> On 2021-07-18 09:32, Linjie Fu wrote:
> > On Wed, Jul 7, 2021 at 9:42 AM Linjie Fu wrote:
> >> On Sun, Jul 4, 2021 at 10:50 PM Linjie Fu wrote:
> >>> From: Linjie Fu
> >>>
> >>> Skip the logic of frame rate emulation until the input reaches the
> >>> specified start time.
> >>>
> >>> Test CMD:
> >>> $ffmpeg -re -ss 30 -i input.mp4 -pix_fmt yuv420p -f sdl2 -
> >>>
> >>> Before the patch:
> >>> first time to got frame, it takes 257305 us
> >>> After this patch:
> >>> first time to got frame, it takes 48879 us
> >>>
> >>> Signed-off-by: Linjie Fu
> >>> ---
> >>> [v2]: fixed the mixed declaration and code warning
> >>> Calculate the time to get the first frame:
> >>> https://github.com/fulinjie/ffmpeg/commit/2aa4762e1e65709997b1ab9dd596332244db80ed
> >>> fftools/ffmpeg.c | 8 ++--
> >>> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> >>> index e97d879cb3..c8849e4250 100644
> >>> --- a/fftools/ffmpeg.c
> >>> +++ b/fftools/ffmpeg.c
> >>> @@ -4221,10 +4221,14 @@ static int get_input_packet(InputFile *f,
> >>> AVPacket **pkt)
> >>> {
> >>> if (f->rate_emu) {
> >>> int i;
> >>> +int64_t pts;
> >>> +int64_t now;
> >>> for (i = 0; i < f->nb_streams; i++) {
> >>> InputStream *ist = input_streams[f->ist_index + i];
> >>> -int64_t pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
> >>> -int64_t now = av_gettime_relative() - ist->start;
> >>> +if (!ist->got_output)
> >>> +continue;
> >>> +pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
> >>> +now = av_gettime_relative() - ist->start;
> >>> if (pts > now)
> >>> return AVERROR(EAGAIN);
> >>> }
> >>> --
> >>> 2.31.1
> >> ping, thx.
> >>
> > Another ping, thx.
>
> I pushed changes to this code yesterday. I don't think it's required
> anymore, but do test.
>
Thanks for the review, tested after applying the readrate patch, I'm
afraid that it's not identical as hope,
since ist->nb_packets would increase no matter input stream got output or not:
(lldb) p ist->nb_packets
(uint64_t) $4 = 1
(lldb) p ist->got_output
(int) $5 = 0
Hence we still need to add the check for ist->got_output, or replace
the ist->nb_packets.
Also there is a new warning caught by the check in patchwork, probably
"mixed declaration and code warning".
Will send patches to rebase and fix.
- linjie
___
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: add QSV variants of the stack filters
Hi Haihao,
On Wed, Jun 9, 2021 at 3:36 PM Haihao Xiang wrote:
>
> Include hstack_qsv, vstack_qsv and xstack_qsv, some code is copy and
> pasted from other filters
>
> Example:
> $> ffmpeg -hwaccel qsv -c:v hevc_qsv -i input.h265 -filter_complex
> "[0:v][0:v]hstack_qsv" -f null -
> ---
> configure | 6 +
> libavfilter/Makefile | 3 +
> libavfilter/allfilters.c | 3 +
> libavfilter/vf_stack_qsv.c | 499 +
> 4 files changed, 511 insertions(+)
> create mode 100644 libavfilter/vf_stack_qsv.c
>
> diff --git a/configure b/configure
> index 6bfd98b384..89adb3a374 100755
> --- a/configure
> +++ b/configure
> @@ -3705,6 +3705,12 @@ vpp_qsv_filter_select="qsvvpp"
> xfade_opencl_filter_deps="opencl"
> yadif_cuda_filter_deps="ffnvcodec"
> yadif_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
> +hstack_qsv_filter_deps="libmfx"
> +hstack_qsv_filter_select="qsvvpp"
> +vstack_qsv_filter_deps="libmfx"
> +vstack_qsv_filter_select="qsvvpp"
> +xstack_qsv_filter_deps="libmfx"
> +xstack_qsv_filter_select="qsvvpp"
>
> # examples
> avio_list_dir_deps="avformat avutil"
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index bc81033e3f..16cf2c8712 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -493,6 +493,9 @@ OBJS-$(CONFIG_YAEPBLUR_FILTER) +=
> vf_yaepblur.o
> OBJS-$(CONFIG_ZMQ_FILTER)+= f_zmq.o
> OBJS-$(CONFIG_ZOOMPAN_FILTER)+= vf_zoompan.o
> OBJS-$(CONFIG_ZSCALE_FILTER) += vf_zscale.o
> +OBJS-$(CONFIG_HSTACK_QSV_FILTER) += vf_stack_qsv.o framesync.o
> +OBJS-$(CONFIG_VSTACK_QSV_FILTER) += vf_stack_qsv.o framesync.o
> +OBJS-$(CONFIG_XSTACK_QSV_FILTER) += vf_stack_qsv.o framesync.o
>
> OBJS-$(CONFIG_ALLRGB_FILTER) += vsrc_testsrc.o
> OBJS-$(CONFIG_ALLYUV_FILTER) += vsrc_testsrc.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index c6afef835f..278ccb99a9 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -471,6 +471,9 @@ extern const AVFilter ff_vf_yaepblur;
> extern const AVFilter ff_vf_zmq;
> extern const AVFilter ff_vf_zoompan;
> extern const AVFilter ff_vf_zscale;
> +extern const AVFilter ff_vf_hstack_qsv;
> +extern const AVFilter ff_vf_vstack_qsv;
> +extern const AVFilter ff_vf_xstack_qsv;
>
> extern const AVFilter ff_vsrc_allrgb;
> extern const AVFilter ff_vsrc_allyuv;
> diff --git a/libavfilter/vf_stack_qsv.c b/libavfilter/vf_stack_qsv.c
> new file mode 100644
> index 00..87f611eece
> --- /dev/null
> +++ b/libavfilter/vf_stack_qsv.c
> @@ -0,0 +1,499 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +/**
> + * @file
> + * Hardware accelerated hstack, vstack and xstack filters based on Intel
> Quick Sync Video VPP
> + */
> +
> +#include "libavutil/opt.h"
> +#include "libavutil/common.h"
> +#include "libavutil/pixdesc.h"
> +#include "libavutil/eval.h"
> +#include "libavutil/hwcontext.h"
> +#include "libavutil/avstring.h"
> +#include "libavutil/avassert.h"
> +#include "libavutil/imgutils.h"
> +#include "libavutil/mathematics.h"
> +#include "libavutil/parseutils.h"
> +
> +#include "internal.h"
> +#include "avfilter.h"
"avfilter.h" has been included in lots of *.h like "internal.h" and
"qsvvpp.h", hence seems to be redundant here.
> +#include "filters.h"
> +#include "formats.h"
> +#include "video.h"
> +
> +#include "framesync.h"
> +#include "qsvvpp.h"
> +
> +#define OFFSET(x) offsetof(QSVStackContext, x)
> +#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
> +
> +enum {
> +QSV_STACK_H = 0,
> +QSV_STACK_V = 1,
> +QSV_STACK_X = 2
> +};
> +
> +typedef struct QSVStackContext {
> +const AVClass *class;
> +QSVVPPContext *qsv;
> +QSVVPPParam qsv_param;
> +mfxExtVPPComposite comp_conf;
> +int mode;
> +FFFrameSync fs;
> +
> +/* Options */
> +int nb_inputs;
> +int shortest;
> +double scale;
> +char *layout;
> +uint8_t fillcolor[4];
> +char *fillcolor_str;
> +int fillcolor_enable;
> +} QSVStackContext;
> +
> +static void rgb2yuv(float r, float g, float b, int *y, int *u, int *v, int
>
Re: [FFmpeg-devel] [PATCH v2] fftools/ffmpeg: accelerate seeking while reading input at native frame rate
On Wed, Jul 7, 2021 at 9:42 AM Linjie Fu wrote:
>
> On Sun, Jul 4, 2021 at 10:50 PM Linjie Fu wrote:
> >
> > From: Linjie Fu
> >
> > Skip the logic of frame rate emulation until the input reaches the
> > specified start time.
> >
> > Test CMD:
> >$ffmpeg -re -ss 30 -i input.mp4 -pix_fmt yuv420p -f sdl2 -
> >
> > Before the patch:
> > first time to got frame, it takes 257305 us
> > After this patch:
> > first time to got frame, it takes 48879 us
> >
> > Signed-off-by: Linjie Fu
> > ---
> > [v2]: fixed the mixed declaration and code warning
> > Calculate the time to get the first frame:
> > https://github.com/fulinjie/ffmpeg/commit/2aa4762e1e65709997b1ab9dd596332244db80ed
> > fftools/ffmpeg.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index e97d879cb3..c8849e4250 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -4221,10 +4221,14 @@ static int get_input_packet(InputFile *f, AVPacket
> > **pkt)
> > {
> > if (f->rate_emu) {
> > int i;
> > +int64_t pts;
> > +int64_t now;
> > for (i = 0; i < f->nb_streams; i++) {
> > InputStream *ist = input_streams[f->ist_index + i];
> > -int64_t pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
> > -int64_t now = av_gettime_relative() - ist->start;
> > +if (!ist->got_output)
> > +continue;
> > +pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
> > +now = av_gettime_relative() - ist->start;
> > if (pts > now)
> > return AVERROR(EAGAIN);
> > }
> > --
> > 2.31.1
> ping, thx.
>
Another ping, 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".
Re: [FFmpeg-devel] [PATCH v2] fftools/ffmpeg: accelerate seeking while reading input at native frame rate
On Sun, Jul 4, 2021 at 10:50 PM Linjie Fu wrote:
>
> From: Linjie Fu
>
> Skip the logic of frame rate emulation until the input reaches the
> specified start time.
>
> Test CMD:
>$ffmpeg -re -ss 30 -i input.mp4 -pix_fmt yuv420p -f sdl2 -
>
> Before the patch:
> first time to got frame, it takes 257305 us
> After this patch:
> first time to got frame, it takes 48879 us
>
> Signed-off-by: Linjie Fu
> ---
> [v2]: fixed the mixed declaration and code warning
> Calculate the time to get the first frame:
> https://github.com/fulinjie/ffmpeg/commit/2aa4762e1e65709997b1ab9dd596332244db80ed
> fftools/ffmpeg.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index e97d879cb3..c8849e4250 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -4221,10 +4221,14 @@ static int get_input_packet(InputFile *f, AVPacket
> **pkt)
> {
> if (f->rate_emu) {
> int i;
> +int64_t pts;
> +int64_t now;
> for (i = 0; i < f->nb_streams; i++) {
> InputStream *ist = input_streams[f->ist_index + i];
> -int64_t pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
> -int64_t now = av_gettime_relative() - ist->start;
> +if (!ist->got_output)
> +continue;
> +pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
> +now = av_gettime_relative() - ist->start;
> if (pts > now)
> return AVERROR(EAGAIN);
> }
> --
> 2.31.1
ping, thx.
- linjie
___
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] fftools/ffmpeg: accelerate seeking while reading input at native frame rate
From: Linjie Fu
Skip the logic of frame rate emulation until the input reaches the
specified start time.
Test CMD:
$ffmpeg -re -ss 30 -i input.mp4 -pix_fmt yuv420p -f sdl2 -
Before the patch:
first time to got frame, it takes 257305 us
After this patch:
first time to got frame, it takes 48879 us
Signed-off-by: Linjie Fu
---
[v2]: fixed the mixed declaration and code warning
Calculate the time to get the first frame:
https://github.com/fulinjie/ffmpeg/commit/2aa4762e1e65709997b1ab9dd596332244db80ed
fftools/ffmpeg.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e97d879cb3..c8849e4250 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4221,10 +4221,14 @@ static int get_input_packet(InputFile *f, AVPacket
**pkt)
{
if (f->rate_emu) {
int i;
+int64_t pts;
+int64_t now;
for (i = 0; i < f->nb_streams; i++) {
InputStream *ist = input_streams[f->ist_index + i];
-int64_t pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
-int64_t now = av_gettime_relative() - ist->start;
+if (!ist->got_output)
+continue;
+pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
+now = av_gettime_relative() - ist->start;
if (pts > now)
return AVERROR(EAGAIN);
}
--
2.31.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] fftools/ffmpeg: accelerate seeking while reading input at native frame rate
From: Linjie Fu
Skip the logic of frame rate emulation until the input reaches the
specified start time.
Test CMD:
$ffmpeg -re -ss 30 -i input.mp4 -pix_fmt yuv420p -f sdl2 -
Before the patch:
first time to got frame, it takes 257305 us
After this patch:
first time to got frame, it takes 48879 us
Signed-off-by: Linjie Fu
---
fftools/ffmpeg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e97d879cb3..851f23ffdb 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4223,6 +4223,8 @@ static int get_input_packet(InputFile *f, AVPacket **pkt)
int i;
for (i = 0; i < f->nb_streams; i++) {
InputStream *ist = input_streams[f->ist_index + i];
+if (!ist->got_output)
+continue;
int64_t pts = av_rescale(ist->dts, 100, AV_TIME_BASE);
int64_t now = av_gettime_relative() - ist->start;
if (pts > now)
--
2.31.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 13/22] lavfi/scale_qsv: add more input / output pixel formats
On Mon, May 17, 2021 at 11:30 AM Haihao Xiang wrote:
>
> NV12 and P010 are added
>
> $ ffmpeg -init_hw_device qsv -c:v h264_qsv -i input.h264 -vf
> "scale_qsv=format=p010" -f null -
> ---
> libavfilter/vf_vpp_qsv.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> index bceee8c4df..29ba220665 100644
> --- a/libavfilter/vf_vpp_qsv.c
> +++ b/libavfilter/vf_vpp_qsv.c
> @@ -665,7 +665,10 @@ DEFINE_QSV_FILTER(vpp, vpp, "VPP");
> static int qsvscale_query_formats(AVFilterContext *ctx)
> {
> static const enum AVPixelFormat pixel_formats[] = {
> -AV_PIX_FMT_QSV, AV_PIX_FMT_NONE,
> +AV_PIX_FMT_NV12,
> +AV_PIX_FMT_P010,
> +AV_PIX_FMT_QSV,
> +AV_PIX_FMT_NONE,
> };
> AVFilterFormats *pix_fmts = ff_make_format_list(pixel_formats);
>
LGTM, also verified it works as expected, thx.
- Linjie
___
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 14/22] lavfi/vpp_qsv: double the framerate for deinterlacing
Hi Haihao,
On Mon, May 17, 2021 at 11:30 AM Haihao Xiang wrote:
>
> ---
> libavfilter/vf_vpp_qsv.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> index 29ba220665..ec35f85b04 100644
> --- a/libavfilter/vf_vpp_qsv.c
> +++ b/libavfilter/vf_vpp_qsv.c
> @@ -255,10 +255,14 @@ static int config_input(AVFilterLink *inlink)
> int ret;
> int64_t ow, oh;
>
> -if (vpp->framerate.den == 0 || vpp->framerate.num == 0)
> +/* Ignore user's setting for framerate when deinterlacing is used */
> +if (vpp->deinterlace)
> +vpp->framerate = av_mul_q(inlink->frame_rate,
> + (AVRational){ 2, 1 });
> +else if (vpp->framerate.den == 0 || vpp->framerate.num == 0)
> vpp->framerate = inlink->frame_rate;
No objection, just considering would it be better to prompt a warning
for users instead of just ignoring the user 's setting?
- linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] lavc/qsv: apply AVCodecContext AVOption -threads to QSV
Hi Haihao, On Thu, Apr 8, 2021 at 3:10 PM Haihao Xiang wrote: > > By default the SDK creates a thread for each CPU when creating a mfx > session for decoding / encoding, which results in CPU overhead on a > multi CPU system. Actually creating 2 threads is a better choice for > most cases in practice. > > This patch allows user to specify the number of threads created for a > mfx session via option -threads. If the number is not specified, 2 > threads will be created by default. > > Note the SDK requires at least 2 threads to avoid dead locks[1] > > [1]https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_lib/scheduler/linux/src/mfx_scheduler_core_ischeduler.cpp#L90-L93 > --- Optional choice for users to specify the thread number looks reasonable to me, and decreasing the CPU overhead makes sense for HW encoding pipeline. Also curious about what's the tradeoff of decreasing the thread number to 2. Would the performance or something else drop? - linjie ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] lavfi/qsvvpp: support async depth
Hi Fei W, On Wed, Mar 31, 2021 at 10:14 AM Wang, Fei W wrote: > > On Wed, 2021-03-31 at 10:07 +0800, Fei Wang wrote: > > Async depth will allow qsv filter cache few frames, and avoid force > > switch and end filter task frame by frame. This change will improve > > performance for some multi-task case, for example 1:N transcode( > > decode + vpp + encode) with all QSV plugins. > > > > Performance data test on my Coffee Lake Desktop(i7-8700K) by using > > the following 1:8 transcode test case improvement: > > 1. Fps improved from 55 to 130. > > 2. Render/Video usage improved from ~61%/~38% to ~100%/~70%.(Data get > > from intel_gpu_top) > > > > test CMD: > > ffmpeg -v verbose -init_hw_device qsv=hw:/dev/dri/renderD128 > > -filter_hw_device \ > > hw -hwaccel qsv -hwaccel_output_format qsv -c:v h264_qsv -i > > 1920x1080.264 \ > > -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 > > -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \ > > -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 > > -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \ > > -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 > > -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \ > > -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 > > -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \ > > -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 > > -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \ > > -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 > > -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \ > > -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 > > -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - > > > > Signed-off-by: Fei Wang > > --- > > Change: > > 1. Add test data in commit message. > > 2. Rmove some duplicate code. Appreciate the detailed data. Verified locally the performance improves in 1:N downscale cases as your description. Also do some experiments for 1:N upscale (1080p->3840x2160) , 1:1 and N:1 cases, the bottleneck seems to be somewhere else hence the performance remains identical for vpp async depth. But this could be another story. Patch functionally LGTM, thx. - linjie ___ 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] 4.4 Release Name
On Sat, Apr 3, 2021 at 16:53 Michael Niedermayer wrote: > On Sat, Apr 03, 2021 at 02:19:58PM +0800, Linjie Fu wrote: > > On Sat, Apr 3, 2021 at 09:10 Zane van Iperen > wrote: > > > > > > > > > > > On 2/4/21 8:34 pm, RADSL wrote: > > > > > > > > On 4/2/2021 2:59 AM, Michael Niedermayer wrote: > > > >> Hi all > > > >> > > > >> We still need to choose the name for 4.4 > > > >> previous unused suggestions where: > > > >> Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois, > > > Viterbi, Darwin > > > >> > > > >> Feel free to reply with name suggestions > > > >> If theres a tie then i will randomly pick amongth the tied, i assume > > > all previous > > > >> suggestions where suggested exactly once already. > > > >> > > > >> I plan to make the release today or tomorrow unless major bugfixes > are > > > >> still pending. I probably wont have time sunday / monday for making > the > > > >> release > > > >> > > > >> Thanks > > > >> > > > >> > > > > version 4.4 Plandemic > > > > > > Absolutely +1 Plandemic > > > > > > Plandemic sounds cool. > > it does until you google what it refers too > > Do the people voting for that want FFmpeg to be associated with the > movie(s) ? > Misunderstood the word and its usage. Sorry for the misunderstanding, no offense from my side. ___ 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] 4.4 Release Name
On Sat, Apr 3, 2021 at 09:10 Zane van Iperen wrote: > > > On 2/4/21 8:34 pm, RADSL wrote: > > > > On 4/2/2021 2:59 AM, Michael Niedermayer wrote: > >> Hi all > >> > >> We still need to choose the name for 4.4 > >> previous unused suggestions where: > >> Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois, > Viterbi, Darwin > >> > >> Feel free to reply with name suggestions > >> If theres a tie then i will randomly pick amongth the tied, i assume > all previous > >> suggestions where suggested exactly once already. > >> > >> I plan to make the release today or tomorrow unless major bugfixes are > >> still pending. I probably wont have time sunday / monday for making the > >> release > >> > >> Thanks > >> > >> > > version 4.4 Plandemic > > Absolutely +1 Plandemic Plandemic sounds cool. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avfilter/vf_vpp_qsv: add scale mode option
On Wed, Feb 24, 2021 at 9:44 AM Fei Wang wrote:
>
> The option allow user to set diffenent scaling mode from
> auto/low-power/high-quality.
>
> More details:
> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#mfxExtVPPScaling
>
> Signed-off-by: Fei Wang
> ---
> libavfilter/vf_vpp_qsv.c | 25 +++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> index 5d57707455..effc459d3b 100644
> --- a/libavfilter/vf_vpp_qsv.c
> +++ b/libavfilter/vf_vpp_qsv.c
> @@ -43,8 +43,9 @@
>
> /* number of video enhancement filters */
> #define ENH_FILTERS_COUNT (7)
> -#define QSV_HAVE_ROTATION QSV_VERSION_ATLEAST(1, 17)
> -#define QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
> +#define QSV_HAVE_ROTATION QSV_VERSION_ATLEAST(1, 17)
> +#define QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
> +#define QSV_HAVE_SCALING_CONFIG QSV_VERSION_ATLEAST(1, 19)
>
> typedef struct VPPContext{
> const AVClass *class;
> @@ -59,6 +60,9 @@ typedef struct VPPContext{
> mfxExtVPPProcAmp procamp_conf;
> mfxExtVPPRotation rotation_conf;
> mfxExtVPPMirroring mirroring_conf;
> +#ifdef QSV_HAVE_SCALING_CONFIG
> +mfxExtVPPScaling scale_conf;
> +#endif
>
> int out_width;
> int out_height;
> @@ -83,6 +87,8 @@ typedef struct VPPContext{
> int rotate; /* rotate angle : [0, 90, 180, 270] */
> int hflip; /* flip mode : 0 = off, 1 = HORIZONTAL flip
> */
>
> +int scale_mode; /* scale mode : 0 = auto, 1 = low power, 2 =
> high quality */
> +
> /* param for the procamp */
> intprocamp;/* enable procamp */
> float hue;
> @@ -128,6 +134,7 @@ static const AVOption options[] = {
> { "h", "Output video height", OFFSET(oh), AV_OPT_TYPE_STRING, {
> .str="w*ch/cw" }, 0, 255, .flags = FLAGS },
> { "height", "Output video height", OFFSET(oh), AV_OPT_TYPE_STRING, {
> .str="w*ch/cw" }, 0, 255, .flags = FLAGS },
> { "format", "Output pixel format", OFFSET(output_format_str),
> AV_OPT_TYPE_STRING, { .str = "same" }, .flags = FLAGS },
> +{ "scale_mode", "scale mode: 0=auto, 1=low power, 2=high quality",
> OFFSET(scale_mode), AV_OPT_TYPE_INT, { .i64 = MFX_SCALING_MODE_DEFAULT },
> MFX_SCALING_MODE_DEFAULT, MFX_SCALING_MODE_QUALITY, .flags = FLAGS, "scale
> mode" },
>
> { NULL }
> };
> @@ -454,6 +461,20 @@ static int config_output(AVFilterLink *outlink)
> #endif
> }
>
> +if (inlink->w != outlink->w || inlink->h != outlink->h) {
> +#ifdef QSV_HAVE_SCALING_CONFIG
> +memset(>scale_conf, 0, sizeof(mfxExtVPPScaling));
> +vpp->scale_conf.Header.BufferId= MFX_EXTBUFF_VPP_SCALING;
> +vpp->scale_conf.Header.BufferSz= sizeof(mfxExtVPPScaling);
> +vpp->scale_conf.ScalingMode= vpp->scale_mode;
> +
> +param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)>scale_conf;
> +#else
> +av_log(ctx, AV_LOG_WARNING, "The QSV VPP Scale option is "
> +"not supported with this MSDK version.\n");
> +#endif
> +}
> +
> if (vpp->use_frc || vpp->use_crop || vpp->deinterlace || vpp->denoise ||
> vpp->detail || vpp->procamp || vpp->rotate || vpp->hflip ||
> inlink->w != outlink->w || inlink->h != outlink->h || in_format !=
> vpp->out_format)
> --
> 2.17.1
>
Looks reasonable, and it seems the default behaviour is QUALITY mode
on all platforms except for APL:
https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/shared/src/mfx_vpp_vaapi.cpp#L1258
- linjie
___
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] lavfi/qsvvpp: support async depth
Hi Fei,
On Mon, Mar 15, 2021 at 1:13 PM Fei Wang wrote:
>
> Async depth will allow qsv filter cache few frames, and avoid force
> switch and end filter task frame by frame. This change will improve
> performance for some multi-task case, for example 1:N transcode(
> decode + vpp + encode) with all QSV plugins.
Async depth support for qsv vpp is valuable for the performance of
whole qsv pipeline, since both decoding/encoding have already
supported the async_depth.
Hence, would you please help to elaborate more about the details about
the performance improvement for the whole pipeline?
(For examples, before/after this patch, cmdline, platform and the fps ...)
> Signed-off-by: Fei Wang
> ---
> Change: combine used and queued into queued in QSVFrame.
>
> libavfilter/qsvvpp.c | 153 ++-
> libavfilter/qsvvpp.h | 41 -
> libavfilter/vf_deinterlace_qsv.c | 14 +--
> libavfilter/vf_vpp_qsv.c | 75 ---
> 4 files changed, 193 insertions(+), 90 deletions(-)
>
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> index f216b3f248..e7c7a12cfa 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -27,6 +27,7 @@
> #include "libavutil/hwcontext_qsv.h"
> #include "libavutil/time.h"
> #include "libavutil/pixdesc.h"
> +#include "libavutil/fifo.h"
This seems to be redundant, since you're adding fifo.h in qsvvpp.h as well.
> #include "internal.h"
> #include "qsvvpp.h"
> @@ -37,37 +38,6 @@
> #define IS_OPAQUE_MEMORY(mode) (mode & MFX_MEMTYPE_OPAQUE_FRAME)
> #define IS_SYSTEM_MEMORY(mode) (mode & MFX_MEMTYPE_SYSTEM_MEMORY)
>
> -typedef struct QSVFrame {
> -AVFrame *frame;
> -mfxFrameSurface1 *surface;
> -mfxFrameSurface1 surface_internal; /* for system memory */
> -struct QSVFrame *next;
> -} QSVFrame;
> -
> -/* abstract struct for all QSV filters */
> -struct QSVVPPContext {
> -mfxSession session;
> -int (*filter_frame) (AVFilterLink *outlink, AVFrame *frame);/* callback
> */
> -enum AVPixelFormat out_sw_format; /* Real output format */
> -mfxVideoParam vpp_param;
> -mfxFrameInfo *frame_infos; /* frame info for each input */
> -
> -/* members related to the input/output surface */
> -int in_mem_mode;
> -int out_mem_mode;
> -QSVFrame *in_frame_list;
> -QSVFrame *out_frame_list;
> -int nb_surface_ptrs_in;
> -int nb_surface_ptrs_out;
> -mfxFrameSurface1 **surface_ptrs_in;
> -mfxFrameSurface1 **surface_ptrs_out;
> -
> -/* MFXVPP extern parameters */
> -mfxExtOpaqueSurfaceAlloc opaque_alloc;
> -mfxExtBuffer **ext_buffers;
> -int nb_ext_buffers;
> -};
> -
> static const mfxHandleType handle_types[] = {
> MFX_HANDLE_VA_DISPLAY,
> MFX_HANDLE_D3D9_DEVICE_MANAGER,
> @@ -336,9 +306,11 @@ static int fill_frameinfo_by_link(mfxFrameInfo
> *frameinfo, AVFilterLink *link)
> static void clear_unused_frames(QSVFrame *list)
> {
> while (list) {
> -if (list->surface && !list->surface->Data.Locked) {
> -list->surface = NULL;
> +/* list->queued==1 means the frame is not cached in VPP
> + * process any more, it can be released to pool. */
> +if ((list->queued == 1) && !list->surface.Data.Locked) {
> av_frame_free(>frame);
> +list->queued = 0;
> }
> list = list->next;
> }
> @@ -361,8 +333,10 @@ static QSVFrame *get_free_frame(QSVFrame **list)
> QSVFrame *out = *list;
>
> for (; out; out = out->next) {
> -if (!out->surface)
> +if (!out->queued) {
> +out->queued = 1;
> break;
> +}
> }
>
> if (!out) {
> @@ -371,8 +345,9 @@ static QSVFrame *get_free_frame(QSVFrame **list)
> av_log(NULL, AV_LOG_ERROR, "Can't alloc new output frame.\n");
> return NULL;
> }
> -out->next = *list;
> -*list = out;
> +out->queued = 1;
> +out->next = *list;
> +*list = out;
> }
>
> return out;
> @@ -402,7 +377,7 @@ static QSVFrame *submit_frame(QSVVPPContext *s,
> AVFilterLink *inlink, AVFrame *p
> return NULL;
> }
> qsv_frame->frame = av_frame_clone(picref);
> -qsv_frame->surface = (mfxFrameSurface1 *)qsv_frame->frame->data[3];
> +qsv_frame->surface = *(mfxFrameSurface1 *)qsv_frame->frame->data[3];
The type of surface in struct QSVFrame would be changed fron
*mfxFrameSurface1 to mfxFrameSurface1, and surface_internal would be
removed.
IMO separating the related changes for the structures into a single
commit would make it more explicit, since it's not closely related
with the implemetation of async fifo.
- linjie
___
ffmpeg-devel mailing list
Re: [FFmpeg-devel] [PATCH] mailmap: add entry for myself
On Mon, Mar 8, 2021 at 11:58 PM Thilo Borgmann wrote: > > Hi, > > Am 08.03.21 um 16:12 schrieb Linjie Fu: > > Signed-off-by: Linjie Fu > > --- > > .mailmap | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/.mailmap b/.mailmap > > index 3bd1a85c3c..ba072f38c8 100644 > > --- a/.mailmap > > +++ b/.mailmap > > @@ -10,7 +10,8 @@ > > > > > > > > - > > + > > + > > > > > > > > LGTM, you are listed as one of the libopenh264enc maintainers, please push. > Applied, thx. - linjie ___ 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] mailmap: add entry for myself
Signed-off-by: Linjie Fu --- .mailmap | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.mailmap b/.mailmap index 3bd1a85c3c..ba072f38c8 100644 --- a/.mailmap +++ b/.mailmap @@ -10,7 +10,8 @@ - + + -- 2.25.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] lavc/hevc_parser: remove repeated profile/level settings
Since avctx->profile/level would be set in export_stream_params()
in set_sps(), identical codes here seem to be redundant.
Signed-off-by: Linjie Fu
---
libavcodec/hevc_parser.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 463d352055..0eb7fb074c 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -95,8 +95,6 @@ static int hevc_parse_slice_header(AVCodecParserContext *s,
H2645NAL *nal,
s->width= ps->sps->width - ow->left_offset - ow->right_offset;
s->height = ps->sps->height - ow->top_offset - ow->bottom_offset;
s->format = ps->sps->pix_fmt;
-avctx->profile = ps->sps->ptl.general_ptl.profile_idc;
-avctx->level= ps->sps->ptl.general_ptl.level_idc;
if (ps->vps->vps_timing_info_present_flag) {
num = ps->vps->vps_num_units_in_tick;
--
2.25.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] lavf/utils: reset event_flags if extradata is not extracted correctly
On Mon, Jan 25, 2021 at 9:08 PM Anton Khirnov wrote: > > Quoting Linjie Fu (2021-01-25 04:49:21) > > On Mon, Jan 25, 2021 at 12:49 AM Anton Khirnov wrote: > > > > > > Quoting Linjie Fu (2021-01-24 16:05:56) > > > > Regression since 87f0c8280. > > > > > > > > If the extradata of a stream could not be extracted correctly, > > > > codec_info_nb_frames would remain zero, while st->event_flag would still > > > > be marked as AVSTREAM_EVENT_FLAG_NEW_PACKETS. > > > > > > > > The two expressions could be different in this case, hence reset > > > > event_flags and calculate the correct score. > > > > > > > > Fix #9029. > > > > > > The ticket mentions ffplay, but ffplay does not access event_flags. > > > > > > > You are right, this helps ffmpeg cmdline to copy and dump: > > $ ffmpeg -i sample_cut.flv -c copy -y dump.mp4 > > > > Before 87f0c8280 and after this patch: > > > > audio streams could be dumped and playable, while video streams still not. > > > > 87f0c8280..master: > > Error reporting and quits. > > > > [mp4 @ 0x7fb276809a00] dimensions not set > > Could not write header for output file #0 (incorrect codec parameters > > ?): Invalid argument > > Error initializing output stream 0:1 -- > > > > I'd change the commit message to "#9029 related" for this, since the > > ffplay issue remains the same. > > I am still not convinced this is really a regression. You can still > process the file by explicitly mapping only the audio stream. Okay, I'm fine with this if it won't trigger failures for to different paths. > This file is damaged and the video stream is not readable. IMO it is > better to report an error and let the user decide what to do with it > than silently skip the video stream while pretending everything is fine. VLC is able to decode/play this correctly, hence maybe need to investigate more into this. - linjie ___ 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] lavf/utils: reset event_flags if extradata is not extracted correctly
On Mon, Jan 25, 2021 at 12:49 AM Anton Khirnov wrote: > > Quoting Linjie Fu (2021-01-24 16:05:56) > > Regression since 87f0c8280. > > > > If the extradata of a stream could not be extracted correctly, > > codec_info_nb_frames would remain zero, while st->event_flag would still > > be marked as AVSTREAM_EVENT_FLAG_NEW_PACKETS. > > > > The two expressions could be different in this case, hence reset > > event_flags and calculate the correct score. > > > > Fix #9029. > > The ticket mentions ffplay, but ffplay does not access event_flags. > You are right, this helps ffmpeg cmdline to copy and dump: $ ffmpeg -i sample_cut.flv -c copy -y dump.mp4 Before 87f0c8280 and after this patch: audio streams could be dumped and playable, while video streams still not. 87f0c8280..master: Error reporting and quits. [mp4 @ 0x7fb276809a00] dimensions not set Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument Error initializing output stream 0:1 -- I'd change the commit message to "#9029 related" for this, since the ffplay issue remains the same. - linjie ___ 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] fftools/ffmpeg_opt: restore to use codec_info_nb_frames to calculate score
On Sun, Jan 24, 2021 at 9:38 PM James Almer wrote: > > On 1/24/2021 10:00 AM, Linjie Fu wrote: > > From: Linjie Fu > > > > Regression since 87f0c8280. > > > > If the extradata of a stream could not be extracted correctly, > > codec_info_nb_frames would remain zero, while st->event_flag would still > > be marked as AVSTREAM_EVENT_FLAG_NEW_PACKETS since it's a new packet > > indeed. > > > > The two expressions could be different in this case, hence restore to > > calculate the correct score. > > > > Fix #9029. > > codec_info_nb_frames is not public, which is why its usage was removed, > so this patch is not ok. Okay, thx. > A proper fix would perhaps be to reset event_flags after this, as its > API says it should. Can you try that and see if it works? > Yes it works, and I've tried this before I sent this patch out. However, what makes me hesitant is the definition of AVSTREAM_EVENT_FLAG_NEW_PACKETS , which says this flag indicates "new packets for this stream were read from the file". IIRC the behaviour in this case matches the definition well, hence I didn't reset event_flags to zero at first. Will send it out for discussion as well, thx. - linjie ___ 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] lavf/utils: reset event_flags if extradata is not extracted correctly
Regression since 87f0c8280.
If the extradata of a stream could not be extracted correctly,
codec_info_nb_frames would remain zero, while st->event_flag would still
be marked as AVSTREAM_EVENT_FLAG_NEW_PACKETS.
The two expressions could be different in this case, hence reset
event_flags and calculate the correct score.
Fix #9029.
Signed-off-by: Linjie Fu
---
libavformat/utils.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 6f100294a1..de397a209e 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3895,8 +3895,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
}
if (!st->internal->avctx->extradata) {
ret = extract_extradata(st, pkt);
-if (ret < 0)
+if (ret < 0) {
+st->event_flags = 0;
goto unref_then_goto_end;
+}
}
/* If still no information, we try to open the codec and to
--
2.25.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] fftools/ffmpeg_opt: restore to use codec_info_nb_frames to calculate score
From: Linjie Fu
Regression since 87f0c8280.
If the extradata of a stream could not be extracted correctly,
codec_info_nb_frames would remain zero, while st->event_flag would still
be marked as AVSTREAM_EVENT_FLAG_NEW_PACKETS since it's a new packet
indeed.
The two expressions could be different in this case, hence restore to
calculate the correct score.
Fix #9029.
Signed-off-by: Linjie Fu
---
fftools/ffmpeg_opt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index bf2eb26246..ba813ea7bc 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -2228,8 +2228,7 @@ static int open_output_file(OptionsContext *o, const char
*filename)
for (i = 0; i < nb_input_streams; i++) {
int score;
ist = input_streams[i];
-score = ist->st->codecpar->width * ist->st->codecpar->height
- + 1 * !!(ist->st->event_flags &
AVSTREAM_EVENT_FLAG_NEW_PACKETS)
+score = ist->st->codecpar->width * ist->st->codecpar->height +
1*!!ist->st->codec_info_nb_frames
+ 500*!!(ist->st->disposition &
AV_DISPOSITION_DEFAULT);
if (ist->user_set_discard == AVDISCARD_ALL)
continue;
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 0/8] HEVC native support for Screen content coding
On Mon, Dec 7, 2020 at 8:56 PM Linjie Fu wrote: > > Add parsing support and reference management for HEVC SCC, as part of > the fully decoding support for hardware(vaapi). > > v3: > - addressed the hang issue in multi-threads > - prompted more logs to prompt scc is not fully supported > - PPS overread is kind of weird, would reply separately in previous >mail threads. > > Previous comments: > https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg110151.html > > Linjie Fu (8): > lavc/avcodec: Add FF_PROFILE_HEVC_SCC for screen content coding > lavc/hevc_ps: Add sps parse support for HEVC SCC extension syntax > lavc/hevc_ps: Add pps parse support for HEVC SCC extension > lavc/hevc_ps: Add slice parse support for HEVC SCC extension > lavc/hevcdec: Fix the parsing for use_integer_mv_flag > lavc/hevcdec: Set max_num_merge_cand to uint8_t > lavc/hevc: Update reference list for SCC > lavc/hevcdec: Prompt detailed logs for invalid PPS id > > libavcodec/avcodec.h | 1 + > libavcodec/hevc.h| 3 + > libavcodec/hevc_parser.c | 2 +- > libavcodec/hevc_ps.c | 116 +-- > libavcodec/hevc_ps.h | 32 +++ > libavcodec/hevc_refs.c | 27 - > libavcodec/hevcdec.c | 22 +++- > libavcodec/hevcdec.h | 7 ++- > libavcodec/profiles.c| 1 + > 9 files changed, 201 insertions(+), 10 deletions(-) > > -- Ping for the patch set [1], thx. [1] https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=2878 - linjie ___ 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 6/6] avcodec/qsvdec: refact, remove duplicate code for plugin loading
Guangxin:
On Tue, Jan 5, 2021 at 10:44 AM Xu Guangxin wrote:
>
> ---
> libavcodec/qsvdec.c | 29 +++--
> 1 file changed, 11 insertions(+), 18 deletions(-)
>
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index 3ca16dafae..d10f90a0db 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -682,21 +682,12 @@ static av_cold int qsv_decode_init(AVCodecContext
> *avctx)
> {
> QSVDecContext *s = avctx->priv_data;
> int ret;
> +const char *uid = NULL;
>
> if (avctx->codec_id == AV_CODEC_ID_VP8) {
> -static const char *uid_vp8dec_hw =
> "f622394d8d87452f878c51f2fc9b4131";
> -
> -av_freep(>qsv.load_plugins);
> -s->qsv.load_plugins = av_strdup(uid_vp8dec_hw);
> -if (!s->qsv.load_plugins)
> -return AVERROR(ENOMEM);
> +uid = "f622394d8d87452f878c51f2fc9b4131";
> } else if (avctx->codec_id == AV_CODEC_ID_VP9) {
> -static const char *uid_vp9dec_hw =
> "a922394d8d87452f878c51f2fc9b4131";
> -
> -av_freep(>qsv.load_plugins);
> -s->qsv.load_plugins = av_strdup(uid_vp9dec_hw);
> -if (!s->qsv.load_plugins)
> -return AVERROR(ENOMEM);
> +uid = "a922394d8d87452f878c51f2fc9b4131";
> }
> else if (avctx->codec_id == AV_CODEC_ID_HEVC && s->load_plugin !=
> LOAD_PLUGIN_NONE) {
> static const char * const uid_hevcdec_sw =
> "15dd936825ad475ea34e35f3f54217a6";
> @@ -707,16 +698,18 @@ static av_cold int qsv_decode_init(AVCodecContext
> *avctx)
> "load_plugins is not empty, but load_plugin is not set to
> 'none'."
> "The load_plugin value will be ignored.\n");
> } else {
> -av_freep(>qsv.load_plugins);
> -
> if (s->load_plugin == LOAD_PLUGIN_HEVC_SW)
> -s->qsv.load_plugins = av_strdup(uid_hevcdec_sw);
> +uid = uid_hevcdec_sw;
> else
> -s->qsv.load_plugins = av_strdup(uid_hevcdec_hw);
> -if (!s->qsv.load_plugins)
> -return AVERROR(ENOMEM);
> +uid = uid_hevcdec_hw;
> }
> }
> +if (uid) {
> +av_freep(>qsv.load_plugins);
> +s->qsv.load_plugins = av_strdup(uid);
> +if (!s->qsv.load_plugins)
> +return AVERROR(ENOMEM);
> +}
>
> s->qsv.orig_pix_fmt = AV_PIX_FMT_NV12;
> s->packet_fifo = av_fifo_alloc(sizeof(AVPacket));
> --
Merging the AVCodec descriptions for all qsv decoders makes the code
cleaner, since
the majority of them are identical. And all checks passed in [1].
One concern is it may be less convenient or more tricky to modify in
the future, if a
specific decoder changes and differs from the rest.
Anyway, lgtm at least for now, and prefer to apply if no more
comments/objections/concerns.
[1] https://github.com/intel-media-ci/ffmpeg/pull/326
- linjie
___
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 v4 1/2] lavf/qsv: Add functions to print mfx iopattern, warning and error
Haihao:
On Tue, Jan 5, 2021 at 3:03 PM Haihao Xiang wrote:
>
> It is a copy of the relevant part in lavc/qsv but use different function
> names to avoid multiple definition when linking lavc and lavf statically.
>
> Signed-off-by: Haihao Xiang
> ---
> v4: rename the new functions to avoid multiple definition
>
> libavfilter/qsvvpp.c | 104 +++
> libavfilter/qsvvpp.h | 9
> 2 files changed, 113 insertions(+)
>
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> index 8d5ff2eb65..b31082db03 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -76,6 +76,110 @@ static const mfxHandleType handle_types[] = {
>
> static const AVRational default_tb = { 1, 9 };
>
> +static const struct {
> +int mfx_iopattern;
> +const char *desc;
> +} qsv_iopatterns[] = {
> +{MFX_IOPATTERN_IN_VIDEO_MEMORY, "input is video memory surface"
>},
> +{MFX_IOPATTERN_IN_SYSTEM_MEMORY,"input is system memory surface"
>},
> +{MFX_IOPATTERN_IN_OPAQUE_MEMORY,"input is opaque memory surface"
>},
> +{MFX_IOPATTERN_OUT_VIDEO_MEMORY,"output is video memory surface"
>},
> +{MFX_IOPATTERN_OUT_SYSTEM_MEMORY, "output is system memory surface"
>},
> +{MFX_IOPATTERN_OUT_OPAQUE_MEMORY, "output is opaque memory surface"
>},
> +};
> +
> +int ff_qsvvpp_print_iopattern(void *log_ctx, int mfx_iopattern,
> + const char *extra_string)
> +{
> +const char *desc = NULL;
> +
> +for (int i = 0; i < FF_ARRAY_ELEMS(qsv_iopatterns); i++) {
> +if (qsv_iopatterns[i].mfx_iopattern == mfx_iopattern) {
> +desc = qsv_iopatterns[i].desc;
> +}
> +}
> +if (!desc)
> +desc = "unknown iopattern";
> +
> +av_log(log_ctx, AV_LOG_VERBOSE, "%s: %s\n", extra_string, desc);
> +return 0;
> +}
> +
> +static const struct {
> +mfxStatus mfxerr;
> +int averr;
> +const char *desc;
> +} qsv_errors[] = {
> +{ MFX_ERR_NONE, 0, "success"
>},
> +{ MFX_ERR_UNKNOWN, AVERROR_UNKNOWN, "unknown error"
>},
> +{ MFX_ERR_NULL_PTR, AVERROR(EINVAL), "NULL pointer"
>},
> +{ MFX_ERR_UNSUPPORTED, AVERROR(ENOSYS), "unsupported"
>},
> +{ MFX_ERR_MEMORY_ALLOC, AVERROR(ENOMEM), "failed to allocate
> memory"},
> +{ MFX_ERR_NOT_ENOUGH_BUFFER,AVERROR(ENOMEM), "insufficient
> input/output buffer" },
> +{ MFX_ERR_INVALID_HANDLE, AVERROR(EINVAL), "invalid handle"
>},
> +{ MFX_ERR_LOCK_MEMORY, AVERROR(EIO),"failed to lock the
> memory block" },
> +{ MFX_ERR_NOT_INITIALIZED, AVERROR_BUG, "not initialized"
>},
> +{ MFX_ERR_NOT_FOUND,AVERROR(ENOSYS), "specified object
> was not found" },
> +/* the following 3 errors should always be handled explicitly, so those
> "mappings"
> + * are for completeness only */
> +{ MFX_ERR_MORE_DATA,AVERROR_UNKNOWN, "expect more data
> at input"},
> +{ MFX_ERR_MORE_SURFACE, AVERROR_UNKNOWN, "expect more
> surface at output"},
> +{ MFX_ERR_MORE_BITSTREAM, AVERROR_UNKNOWN, "expect more
> bitstream at output" },
> +{ MFX_ERR_ABORTED, AVERROR_UNKNOWN, "operation aborted"
>},
> +{ MFX_ERR_DEVICE_LOST, AVERROR(EIO),"device lost"
>},
> +{ MFX_ERR_INCOMPATIBLE_VIDEO_PARAM, AVERROR(EINVAL), "incompatible video
> parameters"},
> +{ MFX_ERR_INVALID_VIDEO_PARAM, AVERROR(EINVAL), "invalid video
> parameters" },
> +{ MFX_ERR_UNDEFINED_BEHAVIOR, AVERROR_BUG, "undefined
> behavior" },
> +{ MFX_ERR_DEVICE_FAILED,AVERROR(EIO),"device failed"
>},
> +{ MFX_ERR_INCOMPATIBLE_AUDIO_PARAM, AVERROR(EINVAL), "incompatible audio
> parameters"},
> +{ MFX_ERR_INVALID_AUDIO_PARAM, AVERROR(EINVAL), "invalid audio
> parameters" },
> +
> +{ MFX_WRN_IN_EXECUTION, 0, "operation in
> execution" },
> +{ MFX_WRN_DEVICE_BUSY, 0, "device busy"
>},
> +{ MFX_WRN_VIDEO_PARAM_CHANGED, 0, "video parameters
> changed" },
> +{ MFX_WRN_PARTIAL_ACCELERATION, 0, "partial
> acceleration" },
> +{ MFX_WRN_INCOMPATIBLE_VIDEO_PARAM, 0, "incompatible video
> parameters"},
> +{ MFX_WRN_VALUE_NOT_CHANGED,0, "value is
> saturated"
Re: [FFmpeg-devel] [PATCH] avcodec/libkvazaar: Set default ratecontrol algorithm for libkvazaar
On Fri, Jan 1, 2021 at 9:55 PM Linjie Fu wrote:
>
> On Thu, Dec 10, 2020 at 3:28 PM Linjie Fu wrote:
> >
> > On Thu, Dec 10, 2020 at 2:09 PM Joose Sainio wrote:
> > >
> > > The standalone version of Kvazaar sets a default ratecontrol algorithm
> > > when
> > > bitrate is set. Mirror this behaviour.
> > >
> > > Signed-off-by: Joose Sainio
> > > ---
> > > libavcodec/libkvazaar.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> > > index 9032547678..68ce7ad58c 100644
> > > --- a/libavcodec/libkvazaar.c
> > > +++ b/libavcodec/libkvazaar.c
> > > @@ -95,6 +95,9 @@ static av_cold int libkvazaar_init(AVCodecContext
> > > *avctx)
> > > cfg->target_bitrate = avctx->bit_rate;
> > > cfg->vui.sar_width = avctx->sample_aspect_ratio.num;
> > > cfg->vui.sar_height = avctx->sample_aspect_ratio.den;
> > > +if(avctx->bit_rate){
> > > +cfg->rc_algorithm = KVZ_LAMBDA;
> > > +}
> > >
> > > if (ctx->kvz_params) {
> > > AVDictionary *dict = NULL;
> > >
> > >
> > Looks reasonable, fixed the encoding failure if explicitly setting
> > bitrate through "-b:v 3M".
> > And the result matches the behaviour of -kvazaar-params "bitrate=300".
> >
> Prefer to apply if no objection.
>
Fixed the coding style, rebased and applied, thx.
- linjie
___
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] fate/hevc-conformance: add clip for persistent_rice_adaptation_enabled_flag
On Fri, Jan 1, 2021 at 9:39 PM Linjie Fu wrote: > > On Mon, Dec 14, 2020 at 5:49 PM Guangxin Xu wrote: > > > > Hi Lingjie > > thanks for the review. > > The stream has the feature but not used. > > > > the decoded yuv's md5 is 3c94b5ebc0aed0abae4e619b9dcca9cc > > it's matched with the WPP_HIGH_TP_444_8BIT_RExt_Apple_2.md5 > > > > Double checked, md5 is matched, and the related the descriptions in > 9.3.1 and 9.3.2.4: > For each Rice parameter initialization state k, each entry of the > table tableStatCoeffSync is initialized to the corresponding value of > StatCoeff[ k ]. > > Would like to push this patch firstly if no objections. > The fate patch could be applied later if someone helps to upload the sample. Applied the functional patch, thx. - linjie ___ 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/5] avcodec/qsvdec_other: refact, use DEFINE_QSV_DECODER to remove duplicate code
Guangxin:
On Thu, Nov 26, 2020 at 6:21 PM Xu Guangxin wrote:
>
> ---
> libavcodec/qsvdec_other.c | 188 --
> 1 file changed, 36 insertions(+), 152 deletions(-)
>
> diff --git a/libavcodec/qsvdec_other.c b/libavcodec/qsvdec_other.c
> index 2775e07955..266ac9f2e5 100644
> --- a/libavcodec/qsvdec_other.c
> +++ b/libavcodec/qsvdec_other.c
> @@ -189,170 +189,54 @@ static const AVOption options[] = {
> { NULL },
> };
>
> -#if CONFIG_MPEG2_QSV_DECODER
> -static const AVClass mpeg2_qsv_class = {
> -.class_name = "mpeg2_qsv",
> -.item_name = av_default_item_name,
> -.option = options,
> -.version= LIBAVUTIL_VERSION_INT,
> -};
> +#define DEFINE_QSV_DECODER(x, X, bsf_name) \
> +static const AVClass x##_qsv_class = { \
> +.class_name = #x "_qsv", \
> +.item_name = av_default_item_name, \
> +.option = options, \
> +.version= LIBAVUTIL_VERSION_INT, \
> +}; \
> +AVCodec ff_##x##_qsv_decoder = { \
> +.name = #x "_qsv", \
> +.long_name = NULL_IF_CONFIG_SMALL(#X " video (Intel Quick Sync
> Video acceleration)"), \
> +.priv_data_size = sizeof(QSVOtherContext), \
> +.type = AVMEDIA_TYPE_VIDEO, \
> +.id = AV_CODEC_ID_##X, \
> +.init = qsv_decode_init, \
> +.decode = qsv_decode_frame, \
> +.flush = qsv_decode_flush, \
> +.close = qsv_decode_close, \
> +.bsfs = bsf_name, \
> +.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_DR1 |
> AV_CODEC_CAP_AVOID_PROBING | AV_CODEC_CAP_HYBRID, \
> +.priv_class = ##_qsv_class, \
> +.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_NV12, \
> +AV_PIX_FMT_P010, \
> +AV_PIX_FMT_QSV, \
> +AV_PIX_FMT_NONE }, \
> +.hw_configs = ff_qsv_hw_configs, \
> +.wrapper_name = "qsv", \
> +}; \
>
> -AVCodec ff_mpeg2_qsv_decoder = {
> -.name = "mpeg2_qsv",
> -.long_name = NULL_IF_CONFIG_SMALL("MPEG-2 video (Intel Quick Sync
> Video acceleration)"),
> -.priv_data_size = sizeof(QSVOtherContext),
> -.type = AVMEDIA_TYPE_VIDEO,
> -.id = AV_CODEC_ID_MPEG2VIDEO,
> -.init = qsv_decode_init,
> -.decode = qsv_decode_frame,
> -.flush = qsv_decode_flush,
> -.close = qsv_decode_close,
> -.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_DR1 |
> AV_CODEC_CAP_AVOID_PROBING | AV_CODEC_CAP_HYBRID,
> -.priv_class = _qsv_class,
> -.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_NV12,
> -AV_PIX_FMT_QSV,
> -AV_PIX_FMT_NONE },
> -.hw_configs = ff_qsv_hw_configs,
> -.wrapper_name = "qsv",
> -};
> +#if CONFIG_MPEG2_QSV_DECODER
> +DEFINE_QSV_DECODER(mpeg2, MPEG2VIDEO, NULL)
> #endif
>
> #if CONFIG_VC1_QSV_DECODER
> -static const AVClass vc1_qsv_class = {
> -.class_name = "vc1_qsv",
> -.item_name = av_default_item_name,
> -.option = options,
> -.version= LIBAVUTIL_VERSION_INT,
> -};
> -
> -AVCodec ff_vc1_qsv_decoder = {
> -.name = "vc1_qsv",
> -.long_name = NULL_IF_CONFIG_SMALL("VC-1 video (Intel Quick Sync
> Video acceleration)"),
> -.priv_data_size = sizeof(QSVOtherContext),
> -.type = AVMEDIA_TYPE_VIDEO,
> -.id = AV_CODEC_ID_VC1,
> -.init = qsv_decode_init,
> -.decode = qsv_decode_frame,
> -.flush = qsv_decode_flush,
> -.close = qsv_decode_close,
> -.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_DR1 |
> AV_CODEC_CAP_AVOID_PROBING | AV_CODEC_CAP_HYBRID,
> -.priv_class = _qsv_class,
> -.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_NV12,
> -AV_PIX_FMT_QSV,
> -AV_PIX_FMT_NONE },
> -.hw_configs = ff_qsv_hw_configs,
> -.wrapper_name = "qsv",
> -};
> -#endif
> -
> -#if CONFIG_VP8_QSV_DECODER
> -static const AVClass vp8_qsv_class = {
> -.class_name = "vp8_qsv",
> -.item_name = av_default_item_name,
> -.option = options,
> -.version= LIBAVUTIL_VERSION_INT,
> -};
> -
> -AVCodec ff_vp8_qsv_decoder = {
> -.name = "vp8_qsv",
> -.long_name = NULL_IF_CONFIG_SMALL("VP8 video (Intel Quick Sync
> Video acceleration)"),
> -.priv_data_size = sizeof(QSVOtherContext),
> -.type = AVMEDIA_TYPE_VIDEO,
> -.id = AV_CODEC_ID_VP8,
> -.init = qsv_decode_init,
> -.decode = qsv_decode_frame,
> -.flush = qsv_decode_flush,
> -.close = qsv_decode_close,
> -.capabilities =
Re: [FFmpeg-devel] [PATCH v2] fate/hevc-conformance: add clip for persistent_rice_adaptation_enabled_flag
On Mon, Dec 14, 2020 at 5:49 PM Guangxin Xu wrote: > > Hi Lingjie > thanks for the review. > The stream has the feature but not used. > > the decoded yuv's md5 is 3c94b5ebc0aed0abae4e619b9dcca9cc > it's matched with the WPP_HIGH_TP_444_8BIT_RExt_Apple_2.md5 > Double checked, md5 is matched, and the related the descriptions in 9.3.1 and 9.3.2.4: For each Rice parameter initialization state k, each entry of the table tableStatCoeffSync is initialized to the corresponding value of StatCoeff[ k ]. Would like to push this patch firstly if no objections. The fate patch could be applied later if someone helps to upload the sample. - linjie ___ 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/libkvazaar: Set default ratecontrol algorithm for libkvazaar
On Thu, Dec 10, 2020 at 3:28 PM Linjie Fu wrote:
>
> On Thu, Dec 10, 2020 at 2:09 PM Joose Sainio wrote:
> >
> > The standalone version of Kvazaar sets a default ratecontrol algorithm when
> > bitrate is set. Mirror this behaviour.
> >
> > Signed-off-by: Joose Sainio
> > ---
> > libavcodec/libkvazaar.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> > index 9032547678..68ce7ad58c 100644
> > --- a/libavcodec/libkvazaar.c
> > +++ b/libavcodec/libkvazaar.c
> > @@ -95,6 +95,9 @@ static av_cold int libkvazaar_init(AVCodecContext *avctx)
> > cfg->target_bitrate = avctx->bit_rate;
> > cfg->vui.sar_width = avctx->sample_aspect_ratio.num;
> > cfg->vui.sar_height = avctx->sample_aspect_ratio.den;
> > +if(avctx->bit_rate){
> > +cfg->rc_algorithm = KVZ_LAMBDA;
> > +}
> >
> > if (ctx->kvz_params) {
> > AVDictionary *dict = NULL;
> >
> >
> Looks reasonable, fixed the encoding failure if explicitly setting
> bitrate through "-b:v 3M".
> And the result matches the behaviour of -kvazaar-params "bitrate=300".
>
Prefer to apply if no objection.
- linjie
___
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] About support a new arch
On Fri, Dec 11, 2020 at 6:31 PM Steven Liu wrote: > > > > > 2020年12月11日 下午5:52，Linjie Fu 写道： > > > > Hi, > > > > On Fri, Dec 11, 2020 at 3:58 PM Steven Liu wrote: > >> > >> > >> > >>> 2020年12月11日 下午3:55，俞林杰 写道： > >>> > >>> a new arch called csky > >> > >> How should we test your code for this arch? > >> > > > > Previous discussion in mail thread[1] about adding new hardware > > implementation, > > which you may want to refer to. > > > > [1] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-May/263382.html > I cannot understand, maybe need more information about how to test Linjie > Yu’s code. > What Toolchans to compile the code? > Run on what operating system? > I get only one information from his mail: > 1. He have a new ARCH (x86? ARM? MIPS?) > 2. He want ffmpeg run on the new ARCH. > Agree, and previous reply is a reference for Linjie Yu to elaborate more. (Apologize for being confusing) ___ 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] About support a new arch
Hi, On Fri, Dec 11, 2020 at 3:58 PM Steven Liu wrote: > > > > > 2020年12月11日 下午3:55，俞林杰 写道： > > > > a new arch called csky > > How should we test your code for this arch? > Previous discussion in mail thread[1] about adding new hardware implementation, which you may want to refer to. [1] https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-May/263382.html - linjie ___ 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] fate/hevc-conformance: add clip for persistent_rice_adaptation_enabled_flag
Hi Guangxin, On Sun, Nov 15, 2020 at 11:07 AM Xu Guangxin wrote: > > you can download it from: > https://www.itu.int/wftp3/av-arch/jctvc-site/bitstream_exchange/draft_conformance/RExt/WPP_HIGH_TP_444_8BIT_RExt_Apple_2.zip > > Signed-off-by: Xu Guangxin > --- > tests/fate/hevc.mak | 1 + > .../hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2| 8 > 2 files changed, 9 insertions(+) > create mode 100644 > tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2 > > diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak > index 9a32a7d74c..97edb49781 100644 > --- a/tests/fate/hevc.mak > +++ b/tests/fate/hevc.mak > @@ -141,6 +141,7 @@ HEVC_SAMPLES = \ > WPP_D_ericsson_MAIN_2 \ > WPP_E_ericsson_MAIN_2 \ > WPP_F_ericsson_MAIN_2 \ > +WPP_HIGH_TP_444_8BIT_RExt_Apple_2 \ > > HEVC_SAMPLES_10BIT =\ > DBLK_A_MAIN10_VIXS_3\ > diff --git > a/tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2 > b/tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2 > new file mode 100644 > index 00..fcb1d2894a > --- /dev/null > +++ b/tests/ref/fate/hevc-conformance-WPP_HIGH_TP_444_8BIT_RExt_Apple_2 > @@ -0,0 +1,8 @@ > +#tb 0: 1/25 > +#media_type 0: video > +#codec_id 0: rawvideo > +#dimensions 0: 1024x768 > +#sar 0: 0/1 > +0, 0, 0,1, 1179648, 0x78e55a69 > +0, 1, 1,1, 1179648, 0x5babb3cb > +0, 2, 2,1, 1179648, 0x65935648 > -- > 2.17.1 > For this sample, native hevc decoder doesn't support "High Throughput 4:4:4" (profile_idc = 5) yet: $ ffmpeg -i fate-suite/hevc-conformance/WPP_HIGH_TP_444_8BIT_RExt_Apple_2.bit [hevc @ 0x7fcf04818800] Unknown HEVC profile: 5 [hevc @ 0x7fcf04818800] high_precision_offsets_enabled_flag not yet implemented [hevc @ 0x7fcf04818800] Unknown HEVC profile: 5 [hevc @ 0x7fcf04818800] high_precision_offsets_enabled_flag not yet implemented [hevc @ 0x7fcf04818800] Unknown HEVC profile: 5 [hevc @ 0x7fcf04818800] high_precision_offsets_enabled_flag not yet implemented Hence the md5 result seems to be different from the reference in WPP_HIGH_TP_444_8BIT_RExt_Apple_2.md5 - linjie ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/2] lavf/qsv: Add functions to print mfx iopattern, warning and error
On Thu, Dec 10, 2020 at 1:50 PM Haihao Xiang wrote: > > It is a copy of the relevant part in lavc/qsv. > > Signed-off-by: Haihao Xiang > --- > To avoid duplicated tables in the same library after applying patch ' > lavc/qsv: make some functions inline', use a local copy of the relevant > code in this patch > > libavfilter/qsvvpp.c | 104 +++ > libavfilter/qsvvpp.h | 9 > 2 files changed, 113 insertions(+) Looks reasonable to me. - linjie ___ 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] qsvdec: factor common options out
On Thu, Nov 26, 2020 at 1:30 PM Haihao Xiang wrote:
>
> ---
> libavcodec/qsvdec.h | 13 +
> libavcodec/qsvdec_h2645.c | 12 ++--
> libavcodec/qsvdec_other.c | 6 +-
> 3 files changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/libavcodec/qsvdec.h b/libavcodec/qsvdec.h
> index f3b7344cba..10e8cf7f91 100644
> --- a/libavcodec/qsvdec.h
> +++ b/libavcodec/qsvdec.h
> @@ -36,6 +36,19 @@
> #include "hwconfig.h"
> #include "qsv_internal.h"
>
> +#define QSVDEC_COMMON_OPTIONS \
> +{ "async_depth", \
> + "Internal parallelization depth, the higher the value the higher the
> latency.", \
> + OFFSET(qsv.async_depth), AV_OPT_TYPE_INT, \
> + { .i64 = ASYNC_DEPTH_DEFAULT }, 1, INT_MAX, VD }, \
> +{ "gpu_copy", \
> + "A GPU-accelerated copy between video and system memory", \
> + OFFSET(qsv.gpu_copy), AV_OPT_TYPE_INT, \
> + { .i64 = MFX_GPUCOPY_DEFAULT }, MFX_GPUCOPY_DEFAULT, MFX_GPUCOPY_OFF,
> VD, "gpu_copy" }, \
> +{ "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_GPUCOPY_DEFAULT }, 0, 0, VD, "gpu_copy" }, \
> +{ "on", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_GPUCOPY_ON },
> 0, 0, VD, "gpu_copy" }, \
> +{ "off", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_GPUCOPY_OFF },
> 0, 0, VD, "gpu_copy" }
> +
> typedef struct QSVContext {
> // the session used for decoding
> mfxSession session;
> diff --git a/libavcodec/qsvdec_h2645.c b/libavcodec/qsvdec_h2645.c
> index 02c41883b6..f767033ecf 100644
> --- a/libavcodec/qsvdec_h2645.c
> +++ b/libavcodec/qsvdec_h2645.c
> @@ -184,7 +184,7 @@ static void qsv_decode_flush(AVCodecContext *avctx)
>
> #if CONFIG_HEVC_QSV_DECODER
> static const AVOption hevc_options[] = {
> -{ "async_depth", "Internal parallelization depth, the higher the value
> the higher the latency.", OFFSET(qsv.async_depth), AV_OPT_TYPE_INT, { .i64 =
> ASYNC_DEPTH_DEFAULT }, 1, INT_MAX, VD },
> +QSVDEC_COMMON_OPTIONS,
>
> { "load_plugin", "A user plugin to load in an internal session",
> OFFSET(load_plugin), AV_OPT_TYPE_INT, { .i64 = LOAD_PLUGIN_HEVC_HW },
> LOAD_PLUGIN_NONE, LOAD_PLUGIN_HEVC_HW, VD, "load_plugin" },
> { "none", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = LOAD_PLUGIN_NONE },
> 0, 0, VD, "load_plugin" },
> @@ -194,10 +194,6 @@ static const AVOption hevc_options[] = {
> { "load_plugins", "A :-separate list of hexadecimal plugin UIDs to load
> in an internal session",
> OFFSET(qsv.load_plugins), AV_OPT_TYPE_STRING, { .str = "" }, 0, 0,
> VD },
>
> -{ "gpu_copy", "A GPU-accelerated copy between video and system memory",
> OFFSET(qsv.gpu_copy), AV_OPT_TYPE_INT, { .i64 = MFX_GPUCOPY_DEFAULT },
> MFX_GPUCOPY_DEFAULT, MFX_GPUCOPY_OFF, VD, "gpu_copy"},
> -{ "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_GPUCOPY_DEFAULT }, 0, 0, VD, "gpu_copy"},
> -{ "on", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_GPUCOPY_ON },
> 0, 0, VD, "gpu_copy"},
> -{ "off", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_GPUCOPY_OFF },
> 0, 0, VD, "gpu_copy"},
> { NULL },
> };
>
> @@ -232,12 +228,8 @@ AVCodec ff_hevc_qsv_decoder = {
>
> #if CONFIG_H264_QSV_DECODER
> static const AVOption options[] = {
> -{ "async_depth", "Internal parallelization depth, the higher the value
> the higher the latency.", OFFSET(qsv.async_depth), AV_OPT_TYPE_INT, { .i64 =
> ASYNC_DEPTH_DEFAULT }, 1, INT_MAX, VD },
> +QSVDEC_COMMON_OPTIONS,
>
> -{ "gpu_copy", "A GPU-accelerated copy between video and system memory",
> OFFSET(qsv.gpu_copy), AV_OPT_TYPE_INT, { .i64 = MFX_GPUCOPY_DEFAULT },
> MFX_GPUCOPY_DEFAULT, MFX_GPUCOPY_OFF, VD, "gpu_copy"},
> -{ "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_GPUCOPY_DEFAULT }, 0, 0, VD, "gpu_copy"},
> -{ "on", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_GPUCOPY_ON },
> 0, 0, VD, "gpu_copy"},
> -{ "off", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_GPUCOPY_OFF },
> 0, 0, VD, "gpu_copy"},
> { NULL },
> };
>
> diff --git a/libavcodec/qsvdec_other.c b/libavcodec/qsvdec_other.c
> index 2775e07955..65cefff2ab 100644
> --- a/libavcodec/qsvdec_other.c
> +++ b/libavcodec/qsvdec_other.c
> @@ -180,12 +180,8 @@ static void qsv_decode_flush(AVCodecContext *avctx)
> #define OFFSET(x) offsetof(QSVOtherContext, x)
> #define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
> static const AVOption options[] = {
> -{ "async_depth", "Internal parallelization depth, the higher the value
> the higher the latency.", OFFSET(qsv.async_depth), AV_OPT_TYPE_INT, { .i64 =
> ASYNC_DEPTH_DEFAULT }, 1, INT_MAX, VD },
> +QSVDEC_COMMON_OPTIONS,
>
> -{ "gpu_copy", "A GPU-accelerated copy between video and system memory",
> OFFSET(qsv.gpu_copy), AV_OPT_TYPE_INT, { .i64 = MFX_GPUCOPY_DEFAULT },
> MFX_GPUCOPY_DEFAULT, MFX_GPUCOPY_OFF, VD, "gpu_copy"},
> -{ "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_GPUCOPY_DEFAULT
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc: add low latency P-pyramid support for qsv
On Thu, Dec 10, 2020 at 2:07 PM wrote:
>
> From: Wenbinc-Bin
>
> Add low latency P-pyramid support for qsv, and it relates to a new
> command line parameter "-p_strategy". To enable this flag, user also
> need to set "-bf" to -1 or 0.
IMO correcting the related options and prompting a warning would be
more user-friendly.
> Signed-off-by Wenbin Chen
> ---
> libavcodec/qsvenc.c | 22 ++
> libavcodec/qsvenc.h | 2 ++
> 2 files changed, 24 insertions(+)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 2bd2a56227..c3b41374e4 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -268,6 +268,13 @@ static void dump_video_param(AVCodecContext *avctx,
> QSVEncContext *q,
> case MFX_B_REF_PYRAMID: av_log(avctx, AV_LOG_VERBOSE, "pyramid");
> break;
> default:av_log(avctx, AV_LOG_VERBOSE, "auto");
> break;
> }
> +av_log(avctx, AV_LOG_VERBOSE, "; PRefType: ");
> +switch(co3->PRefType){
> +case MFX_P_REF_DEFAULT: av_log(avctx, AV_LOG_VERBOSE, "default");
> break;
> +case MFX_P_REF_SIMPLE: av_log(avctx, AV_LOG_VERBOSE, "simple");
> break;
> +case MFX_P_REF_PYRAMID: av_log(avctx, AV_LOG_VERBOSE, "pyramid");
> break;
> +default:break;
> +}
> av_log(avctx, AV_LOG_VERBOSE, "\n");
> #endif
>
> @@ -777,6 +784,21 @@ FF_ENABLE_DEPRECATION_WARNINGS
> #if QSV_HAVE_CO3
> q->extco3.Header.BufferId = MFX_EXTBUFF_CODING_OPTION3;
> q->extco3.Header.BufferSz = sizeof(q->extco3);
> +switch(q->p_strategy){
> +case 0:
> +q->extco3.PRefType = MFX_P_REF_DEFAULT;
> +break;
> +case 1:
> +q->extco3.PRefType = MFX_P_REF_SIMPLE;
> +break;
> +case 2:
> +q->extco3.PRefType = MFX_P_REF_PYRAMID;
> +break;
> +default:
> +q->extco3.PRefType = MFX_P_REF_DEFAULT;
> +av_log(avctx, AV_LOG_VERBOSE, "invalid p_strategy, set to
> default\n");
> +break;
> +}
It'll be great if one could help to provide some links/background
information like [1] in commit messages or docs,
to elaborate more about "default" and "simple", and make a new option
easier to be understood:
[1]
https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#preftype
- linjie
___
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/libkvazaar: Set default ratecontrol algorithm for libkvazaar
On Thu, Dec 10, 2020 at 2:09 PM Joose Sainio wrote:
>
> The standalone version of Kvazaar sets a default ratecontrol algorithm when
> bitrate is set. Mirror this behaviour.
>
> Signed-off-by: Joose Sainio
> ---
> libavcodec/libkvazaar.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/libkvazaar.c b/libavcodec/libkvazaar.c
> index 9032547678..68ce7ad58c 100644
> --- a/libavcodec/libkvazaar.c
> +++ b/libavcodec/libkvazaar.c
> @@ -95,6 +95,9 @@ static av_cold int libkvazaar_init(AVCodecContext *avctx)
> cfg->target_bitrate = avctx->bit_rate;
> cfg->vui.sar_width = avctx->sample_aspect_ratio.num;
> cfg->vui.sar_height = avctx->sample_aspect_ratio.den;
> +if(avctx->bit_rate){
> +cfg->rc_algorithm = KVZ_LAMBDA;
> +}
>
> if (ctx->kvz_params) {
> AVDictionary *dict = NULL;
>
>
Looks reasonable, fixed the encoding failure if explicitly setting
bitrate through "-b:v 3M".
And the result matches the behaviour of -kvazaar-params "bitrate=300".
- linjie
___
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 v3 5/8] lavc/hevcdec: Fix the parsing for use_integer_mv_flag
From: Linjie Fu
According to 7.3.6.1, use_integer_mv_flag should be parsed if
motion_vector_resolution_control_idc equals to 2.
Otherwise wrong parameters in the subsequent parsing procedures
would be got.
Signed-off-by: Linjie Fu
---
libavcodec/hevcdec.c | 8
libavcodec/hevcdec.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 7074a0760a..6a029b270e 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -808,6 +808,14 @@ static int hls_slice_header(HEVCContext *s)
sh->max_num_merge_cand);
return AVERROR_INVALIDDATA;
}
+
+// Syntax in 7.3.6.1
+if (s->ps.sps->motion_vector_resolution_control_idc == 2)
+sh->use_integer_mv_flag = get_bits1(gb);
+else
+// Inferred to be equal to
motion_vector_resolution_control_idc if not present
+sh->use_integer_mv_flag =
s->ps.sps->motion_vector_resolution_control_idc;
+
}
sh->slice_qp_delta = get_se_golomb(gb);
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index 6e22e044dd..1164af2862 100644
--- a/libavcodec/hevcdec.h
+++ b/libavcodec/hevcdec.h
@@ -302,6 +302,7 @@ typedef struct SliceHeader {
int tc_offset; ///< tc_offset_div2 * 2
unsigned int max_num_merge_cand; ///< 5 - 5_minus_max_num_merge_cand
+uint8_t use_integer_mv_flag;
unsigned *entry_point_offset;
int * offset;
--
2.25.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 0/7] HEVC native support for Screen content coding
On Tue, Sep 29, 2020 at 10:03 PM Mark Thompson wrote: > On 10/09/2020 07:42, Haihao Xiang wrote: > > Resend Linjie's patchset with the updates. > > > > As a part of the support for VA-API HEVC SCC decoding (gen12, Tiger > > Lake+). > > > > The full support could be accessed in: > > https://github.com/intel-media-ci/ffmpeg/pull/231 > > > > The VAAPI part would be provided later once the implementations of > > native parsing and reference management are all decent. > > > > Linjie Fu (7): > >lavc/avcodec: Add FF_PROFILE_HEVC_SCC for screen content coding > >lavc/hevc_ps: Add sps parse support for HEVC SCC extension syntax > >lavc/hevc_ps: Add pps parse support for HEVC SCC extension > >lavc/hevc_ps: Add slice parse support for HEVC SCC extension > >lavc/hevcdec: Fix the parsing for use_integer_mv_flag > >lavc/hevcdec: Set max_num_merge_cand to uint8_t > >lavc/hevc: Update reference list for SCC > > > > libavcodec/avcodec.h | 1 + > > libavcodec/hevc.h | 3 ++ > > libavcodec/hevc_ps.c | 118 +++-- > > libavcodec/hevc_ps.h | 32 +++ > > libavcodec/hevc_refs.c | 27 +- > > libavcodec/hevcdec.c | 17 +- > > libavcodec/hevcdec.h | 7 ++- > > libavcodec/profiles.c | 1 + > > 8 files changed, 197 insertions(+), 9 deletions(-) > > This looks generally pretty good, but the lack of a software > implementation is kindof unfortunate - is there any plan to do anything > about that? > > If not, I think you need to make sure that all of the newly-added flags > give a suitable error message to say that it isn't supported. (Especially > in cases like use_integer_mv_flag where it can return incorrect output > while saying that everything is fine.) > > > It seems to always hang with all threads waiting for each other when given > a non-software-decodable SCC stream with threads enabled (it hangs forever > entirely repeatably before the SIGINT): > > $ ./ffmpeg_g -threads 2 -i PPI_A_InterDigital_2.bit -f null - > ... > Stream #0:0: Video: hevc (Scc), yuv444p(tv), 1280x720, 25 fps, 25 > tbr, 1200k tbn, 25 tbc > [hevc @ 0x57b3a680] high_precision_offsets_enabled_flag not yet > implemented > [hevc @ 0x57b3a680] Overread PPS by 8 bits > [New Thread 0x7344f700 (LWP 1954956)] > [New Thread 0x72c4e700 (LWP 1954957)] > Stream mapping: > >Stream #0:0 -> #0:0 (hevc (native) -> wrapped_avframe (native)) > Press [q] to stop, [?] for help > [hevc @ 0x57b3a680] high_precision_offsets_enabled_flag not yet > implemented > [hevc @ 0x57b3a680] Overread PPS by 8 bits > [hevc @ 0x57b3a680] PPS id out of range: 0 > [hevc @ 0x57b3a680] Error parsing NAL unit #3. > Error while decoding stream #0:0: Invalid data found when processing input > > Thread 1 "ffmpeg_g" received signal SIGINT, Interrupt. > futex_wait_cancelable (private=0, expected=0, futex_word=0x57b4cd90) > at ../sysdeps/nptl/futex-internal.h:183 > 183 ../sysdeps/nptl/futex-internal.h: No such file or directory. > (gdb) i thr >Id Target Id Frame > * 1Thread 0x734561c0 (LWP 1954952) "ffmpeg_g" > futex_wait_cancelable (private=0, expected=0, futex_word=0x57b4cd90) at > ../sysdeps/nptl/futex-internal.h:183 >2Thread 0x7344f700 (LWP 1954956) "ffmpeg_g" > futex_wait_cancelable (private=0, expected=0, futex_word=0x57b4cb80) at > ../sysdeps/nptl/futex-internal.h:183 >3Thread 0x72c4e700 (LWP 1954957) "ffmpeg_g" > futex_wait_cancelable (private=0, expected=0, futex_word=0x57b4cd64) at > ../sysdeps/nptl/futex-internal.h:183 > (gdb) thr ap al bt > > Thread 3 (Thread 0x72c4e700 (LWP 1954957)): > #0 futex_wait_cancelable (private=0, expected=0, > futex_word=0x57b4cd64) at ../sysdeps/nptl/futex-internal.h:183 > #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, > mutex=0x57b4cdc0, cond=0x57b4cd38) at pthread_cond_wait.c:508 > #2 __pthread_cond_wait (cond=0x57b4cd38, mutex=0x57b4cdc0) at > pthread_cond_wait.c:638 > #3 0x560eaed8 in strict_pthread_cond_wait (cond=0x57b4cd38, > mutex=0x57b4cdc0) at src/libavutil/thread.h:112 > #4 0x560ec49c in ff_thread_await_progress (f=0x57b6b0a8, > n=41, field=0) at src/libavcodec/pthread_frame.c:601 > #5 0x55e8e73b in hevc_await_progress (s=0x57b6a140, > ref=0x57b6b0a0, mv=0x72c4da00, y0=0, height=32) at > src/libavcodec/hevcdec.c:1796 > #6 0x55e8eeb3 in hls_prediction_unit (s=0x57b6a140, x0=32, > y0=0,
[FFmpeg-devel] [PATCH v3 4/8] lavc/hevc_ps: Add slice parse support for HEVC SCC extension
From: Linjie Fu
Signed-off-by: Linjie Fu
---
libavcodec/hevcdec.c | 6 ++
libavcodec/hevcdec.h | 4
2 files changed, 10 insertions(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 699c13bbcc..7074a0760a 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -825,6 +825,12 @@ static int hls_slice_header(HEVCContext *s)
sh->slice_cr_qp_offset = 0;
}
+if (s->ps.pps->pps_slice_act_qp_offsets_present_flag) {
+sh->slice_act_y_qp_offset = get_se_golomb(gb);
+sh->slice_act_cb_qp_offset = get_se_golomb(gb);
+sh->slice_act_cr_qp_offset = get_se_golomb(gb);
+}
+
if (s->ps.pps->chroma_qp_offset_list_enabled_flag)
sh->cu_chroma_qp_offset_enabled_flag = get_bits1(gb);
else
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index 39c5c7f89f..6e22e044dd 100644
--- a/libavcodec/hevcdec.h
+++ b/libavcodec/hevcdec.h
@@ -292,6 +292,10 @@ typedef struct SliceHeader {
int slice_cb_qp_offset;
int slice_cr_qp_offset;
+int slice_act_y_qp_offset;
+int slice_act_cb_qp_offset;
+int slice_act_cr_qp_offset;
+
uint8_t cu_chroma_qp_offset_enabled_flag;
int beta_offset;///< beta_offset_div2 * 2
--
2.25.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 v3 0/8] HEVC native support for Screen content coding
Add parsing support and reference management for HEVC SCC, as part of the fully decoding support for hardware(vaapi). v3: - addressed the hang issue in multi-threads - prompted more logs to prompt scc is not fully supported - PPS overread is kind of weird, would reply separately in previous mail threads. Previous comments: https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg110151.html Linjie Fu (8): lavc/avcodec: Add FF_PROFILE_HEVC_SCC for screen content coding lavc/hevc_ps: Add sps parse support for HEVC SCC extension syntax lavc/hevc_ps: Add pps parse support for HEVC SCC extension lavc/hevc_ps: Add slice parse support for HEVC SCC extension lavc/hevcdec: Fix the parsing for use_integer_mv_flag lavc/hevcdec: Set max_num_merge_cand to uint8_t lavc/hevc: Update reference list for SCC lavc/hevcdec: Prompt detailed logs for invalid PPS id libavcodec/avcodec.h | 1 + libavcodec/hevc.h| 3 + libavcodec/hevc_parser.c | 2 +- libavcodec/hevc_ps.c | 116 +-- libavcodec/hevc_ps.h | 32 +++ libavcodec/hevc_refs.c | 27 - libavcodec/hevcdec.c | 22 +++- libavcodec/hevcdec.h | 7 ++- libavcodec/profiles.c| 1 + 9 files changed, 201 insertions(+), 10 deletions(-) -- 2.25.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 v3 8/8] lavc/hevcdec: Prompt detailed logs for invalid PPS id
There are 3 functions reporting the same log, which is not straight
forward enough for users:
- hevc_parse_slice_header()
- ff_hevc_decode_nal_pps()
- hls_slice_header()
Provide detailed logs to distinguish from "out of range PPS id" and
"empty pps_list[pps_id]".
Before:
PPS id out of range: 0
After:
PPS id out of range or empty pps_list[0]: 0
Since 0 is within the range of pps_id, it's more clear that there is
an invalid pps_list.
Signed-off-by: Linjie Fu
---
libavcodec/hevc_parser.c | 2 +-
libavcodec/hevcdec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 463d352055..0c6b50c0b9 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -75,7 +75,7 @@ static int hevc_parse_slice_header(AVCodecParserContext *s,
H2645NAL *nal,
pps_id = get_ue_golomb(gb);
if (pps_id >= HEVC_MAX_PPS_COUNT || !ps->pps_list[pps_id]) {
-av_log(avctx, AV_LOG_ERROR, "PPS id out of range: %d\n", pps_id);
+av_log(avctx, AV_LOG_ERROR, "PPS id out of range or empty
pps_list[%d]: %d\n", pps_id, pps_id);
return AVERROR_INVALIDDATA;
}
ps->pps = (HEVCPPS*)ps->pps_list[pps_id]->data;
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index e1d469658c..02c489e1f9 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -554,7 +554,7 @@ static int hls_slice_header(HEVCContext *s)
sh->pps_id = get_ue_golomb_long(gb);
if (sh->pps_id >= HEVC_MAX_PPS_COUNT || !s->ps.pps_list[sh->pps_id]) {
-av_log(s->avctx, AV_LOG_ERROR, "PPS id out of range: %d\n",
sh->pps_id);
+av_log(s->avctx, AV_LOG_ERROR, "PPS id out of range or empty
pps_list[%d]: %d\n", sh->pps_id, sh->pps_id);
return AVERROR_INVALIDDATA;
}
if (!sh->first_slice_in_pic_flag &&
--
2.25.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 v3 1/8] lavc/avcodec: Add FF_PROFILE_HEVC_SCC for screen content coding
From: Linjie Fu
Signed-off-by: Linjie Fu
---
libavcodec/avcodec.h | 1 +
libavcodec/hevc_ps.c | 2 ++
libavcodec/profiles.c | 1 +
3 files changed, 4 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 20af3ef00d..2e853bfdef 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1948,6 +1948,7 @@ typedef struct AVCodecContext {
#define FF_PROFILE_HEVC_MAIN_10 2
#define FF_PROFILE_HEVC_MAIN_STILL_PICTURE 3
#define FF_PROFILE_HEVC_REXT4
+#define FF_PROFILE_HEVC_SCC 9
#define FF_PROFILE_AV1_MAIN 0
#define FF_PROFILE_AV1_HIGH 1
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index ea6fd536c6..584e2ba0d6 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -281,6 +281,8 @@ static int decode_profile_tier_level(GetBitContext *gb,
AVCodecContext *avctx,
av_log(avctx, AV_LOG_DEBUG, "Main Still Picture profile bitstream\n");
else if (ptl->profile_idc == FF_PROFILE_HEVC_REXT)
av_log(avctx, AV_LOG_DEBUG, "Range Extension profile bitstream\n");
+else if (ptl->profile_idc == FF_PROFILE_HEVC_SCC)
+av_log(avctx, AV_LOG_DEBUG, "Screen Content Coding Extension profile
bitstream\n");
else
av_log(avctx, AV_LOG_WARNING, "Unknown HEVC profile: %d\n",
ptl->profile_idc);
diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
index e59a3a5c12..e815b90c6a 100644
--- a/libavcodec/profiles.c
+++ b/libavcodec/profiles.c
@@ -79,6 +79,7 @@ const AVProfile ff_hevc_profiles[] = {
{ FF_PROFILE_HEVC_MAIN_10, "Main 10" },
{ FF_PROFILE_HEVC_MAIN_STILL_PICTURE, "Main Still Picture" },
{ FF_PROFILE_HEVC_REXT, "Rext"},
+{ FF_PROFILE_HEVC_SCC, "Scc" },
{ FF_PROFILE_UNKNOWN },
};
--
2.25.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 v3 7/8] lavc/hevc: Update reference list for SCC
Screen Content Coding allows non-intra slice in an IDR frame, and would
mark the current decoded picture as "used for long-term reference", no
matter TwoVersionsOfCurrDecPicFlag(8.1.3), hence some previous restricts
are not suitable any more.
Constructe RefPicListTemp and RefPicList according to 8-8/9/10.
Add a check for native decoder to quit while self-referencing is detected,
since it's not supported yet.
Signed-off-by: Linjie Fu
---
libavcodec/hevc_refs.c | 27 +--
libavcodec/hevcdec.c | 6 +-
2 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 4f6d985ae6..ba32e232bb 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -301,7 +301,7 @@ int ff_hevc_slice_rpl(HEVCContext *s)
return ret;
if (!(s->rps[ST_CURR_BEF].nb_refs + s->rps[ST_CURR_AFT].nb_refs +
- s->rps[LT_CURR].nb_refs)) {
+ s->rps[LT_CURR].nb_refs) &&
!s->ps.pps->pps_curr_pic_ref_enabled_flag) {
av_log(s->avctx, AV_LOG_ERROR, "Zero refs in the frame RPS.\n");
return AVERROR_INVALIDDATA;
}
@@ -328,6 +328,12 @@ int ff_hevc_slice_rpl(HEVCContext *s)
rpl_tmp.nb_refs++;
}
}
+// Construct RefPicList0, RefPicList1 (8-8, 8-10)
+if (s->ps.pps->pps_curr_pic_ref_enabled_flag) {
+rpl_tmp.ref[rpl_tmp.nb_refs]= s->ref;
+rpl_tmp.isLongTerm[rpl_tmp.nb_refs] = 1;
+rpl_tmp.nb_refs++;
+}
}
/* reorder the references if necessary */
@@ -350,6 +356,12 @@ int ff_hevc_slice_rpl(HEVCContext *s)
rpl->nb_refs = FFMIN(rpl->nb_refs, sh->nb_refs[list_idx]);
}
+// 8-9
+if (s->ps.pps->pps_curr_pic_ref_enabled_flag && sh->slice_type ==
HEVC_SLICE_P &&
+!sh->rpl_modification_flag[list_idx] && rpl_tmp.nb_refs >
sh->nb_refs[L0]) {
+rpl->ref[sh->nb_refs[L0]] = s->ref;
+}
+
if (sh->collocated_list == list_idx &&
sh->collocated_ref_idx < rpl->nb_refs)
s->ref->collocated_ref = rpl->ref[sh->collocated_ref_idx];
@@ -423,7 +435,8 @@ static int add_candidate_ref(HEVCContext *s, RefPicList
*list,
{
HEVCFrame *ref = find_ref_idx(s, poc, use_msb);
-if (ref == s->ref || list->nb_refs >= HEVC_MAX_REFS)
+if ((ref == s->ref && !s->ps.pps->pps_curr_pic_ref_enabled_flag) ||
+list->nb_refs >= HEVC_MAX_REFS)
return AVERROR_INVALIDDATA;
if (!ref) {
@@ -492,6 +505,12 @@ int ff_hevc_frame_rps(HEVCContext *s)
goto fail;
}
+if (s->ps.pps->pps_curr_pic_ref_enabled_flag) {
+ret = add_candidate_ref(s, [LT_FOLL], s->poc,
HEVC_FRAME_FLAG_LONG_REF, 1);
+if (ret < 0)
+goto fail;
+}
+
fail:
/* release any frames that are now unused */
for (i = 0; i < FF_ARRAY_ELEMS(s->DPB); i++)
@@ -518,5 +537,9 @@ int ff_hevc_frame_nb_refs(const HEVCContext *s)
for (i = 0; i < long_rps->nb_refs; i++)
ret += !!long_rps->used[i];
}
+
+if (s->ps.pps->pps_curr_pic_ref_enabled_flag)
+ret++;
+
return ret;
}
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 6a029b270e..e1d469658c 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -637,7 +637,8 @@ static int hls_slice_header(HEVCContext *s)
sh->slice_type);
return AVERROR_INVALIDDATA;
}
-if (IS_IRAP(s) && sh->slice_type != HEVC_SLICE_I) {
+if (IS_IRAP(s) && sh->slice_type != HEVC_SLICE_I &&
+s->ps.sps->ptl.general_ptl.profile_idc != FF_PROFILE_HEVC_SCC) {
av_log(s->avctx, AV_LOG_ERROR, "Inter slices in an IRAP frame.\n");
return AVERROR_INVALIDDATA;
}
@@ -752,6 +753,9 @@ static int hls_slice_header(HEVCContext *s)
if (!nb_refs) {
av_log(s->avctx, AV_LOG_ERROR, "Zero refs for a frame with P
or B slices.\n");
return AVERROR_INVALIDDATA;
+} else if (s->ps.pps->pps_curr_pic_ref_enabled_flag) {
+av_log(s->avctx, AV_LOG_ERROR, "Self refs for a frame is not
supprted yet.\n");
+return AVERROR_INVALIDDATA;
}
if (s->ps.pps->lists_modification_present_flag && nb_refs > 1) {
--
2.25.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 v3 6/8] lavc/hevcdec: Set max_num_merge_cand to uint8_t
From: Linjie Fu
uint8_t is big enough and keep consistent with the definition in
cbs_h265.h.
Signed-off-by: Linjie Fu
---
libavcodec/hevcdec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index 1164af2862..464eb7cd3c 100644
--- a/libavcodec/hevcdec.h
+++ b/libavcodec/hevcdec.h
@@ -301,7 +301,7 @@ typedef struct SliceHeader {
int beta_offset;///< beta_offset_div2 * 2
int tc_offset; ///< tc_offset_div2 * 2
-unsigned int max_num_merge_cand; ///< 5 - 5_minus_max_num_merge_cand
+uint8_t max_num_merge_cand; ///< 5 - 5_minus_max_num_merge_cand
uint8_t use_integer_mv_flag;
unsigned *entry_point_offset;
--
2.25.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 v3 3/8] lavc/hevc_ps: Add pps parse support for HEVC SCC extension
From: Linjie Fu
Signed-off-by: Linjie Fu
Signed-off-by: Haihao Xiang
---
libavcodec/hevc_ps.c | 70 +++-
libavcodec/hevc_ps.h | 17 +++
2 files changed, 86 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index d65efc1aef..704b666756 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -1400,6 +1400,48 @@ static int pps_range_extensions(GetBitContext *gb,
AVCodecContext *avctx,
return(0);
}
+static int pps_scc_extension(GetBitContext *gb, AVCodecContext *avctx,
+ HEVCPPS *pps, HEVCSPS *sps)
+{
+int num_comps;
+int i, ret;
+
+pps->pps_curr_pic_ref_enabled_flag = get_bits1(gb);
+if (pps->residual_adaptive_colour_transform_enabled_flag = get_bits1(gb)) {
+pps->pps_slice_act_qp_offsets_present_flag = get_bits1(gb);
+pps->pps_act_y_qp_offset = get_se_golomb_long(gb) - 5;
+pps->pps_act_cb_qp_offset = get_se_golomb_long(gb) - 5;
+pps->pps_act_cr_qp_offset = get_se_golomb_long(gb) - 3;
+
+#define CHECK_QP_OFFSET(name) (pps->pps_act_ ## name ## _qp_offset < -12 || \
+ pps->pps_act_ ## name ## _qp_offset > 12)
+ret = CHECK_QP_OFFSET(y) || CHECK_QP_OFFSET(cb) || CHECK_QP_OFFSET(cr);
+#undef CHECK_QP_OFFSET
+if (ret) {
+av_log(avctx, AV_LOG_ERROR,
+ "PpsActQpOffsetY/Cb/Cr shall be in the range of [-12,
12].\n");
+return AVERROR_INVALIDDATA;
+}
+}
+
+if (pps->pps_palette_predictor_initializers_present_flag = get_bits1(gb)) {
+if ((pps->pps_num_palette_predictor_initializers =
get_ue_golomb_long(gb)) > 0) {
+pps->monochrome_palette_flag = get_bits1(gb);
+pps->luma_bit_depth_entry_minus8 = get_ue_golomb_long(gb);
+if (!pps->monochrome_palette_flag)
+pps->chroma_bit_depth_entry_minus8 = get_ue_golomb_long(gb);
+num_comps = pps->monochrome_palette_flag ? 1 : 3;
+for (int comp = 0; comp < num_comps; comp++)
+for (i = 0; i < pps->pps_num_palette_predictor_initializers;
i++)
+pps->pps_palette_predictor_initializer[comp][i] =
+get_bits(gb, 8 + (!comp ?
pps->luma_bit_depth_entry_minus8 :
+ pps->chroma_bit_depth_entry_minus8));
+}
+}
+
+return 0;
+}
+
static inline int setup_pps(AVCodecContext *avctx, GetBitContext *gb,
HEVCPPS *pps, HEVCSPS *sps)
{
@@ -1753,11 +1795,37 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
AVCodecContext *avctx,
if (get_bits1(gb)) { // pps_extension_present_flag
pps->pps_range_extensions_flag = get_bits1(gb);
-skip_bits(gb, 7); // pps_extension_7bits
+
+/* hevc-conformance-PS_A_VIDYO_3 in fate has
pps_multilayer_extension_flag (1),
+ * pps_3d_extension_flag (1) and pps_scc_extension_flag (1) but has
the wrong
+ * data for pps_multilayer_extension(), pps_3d_extension(), and
pps_scc_extension().
+ * To avoid regression for hevc-conformance-PS_A_VIDYO_3, here check
+ * pps_multilayer_extension_flag, pps_3d_extension_flag and
pps_scc_extension_flag
+ * only for SCC streams */
+if (sps->ptl.general_ptl.profile_idc == FF_PROFILE_HEVC_SCC) {
+pps->pps_multilayer_extension_flag = get_bits1(gb);
+pps->pps_3d_extension_flag = get_bits1(gb);
+pps->pps_scc_extension_flag= get_bits1(gb);
+skip_bits(gb, 4); // pps_extension_4bits
+} else
+skip_bits(gb, 7);
+
if (sps->ptl.general_ptl.profile_idc == FF_PROFILE_HEVC_REXT &&
pps->pps_range_extensions_flag) {
if ((ret = pps_range_extensions(gb, avctx, pps, sps)) < 0)
goto err;
}
+
+if (pps->pps_multilayer_extension_flag || pps->pps_3d_extension_flag) {
+av_log(avctx, AV_LOG_ERROR,
+ "multilayer_extension or 3d_extension not yet
implemented\n");
+ret = AVERROR_PATCHWELCOME;
+goto err;
+}
+
+if (pps->pps_scc_extension_flag) {
+if ((ret = pps_scc_extension(gb, avctx, pps, sps)) < 0)
+goto err;
+}
}
ret = setup_pps(avctx, gb, pps, sps);
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index be23758008..155b66062e 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -312,6 +312,9 @@ typedef struct HEVCPPS {
uint8_t slice_header_extension_present_flag;
uint8_t log2_max_transform_skip_block_size;
uint8_t pps_range_extensions_flag;
+uint8_t pps_multilayer_extension_flag;
+uint8_t pps_3d_extension_flag;
+uint8_t pps
[FFmpeg-devel] [PATCH v3 2/8] lavc/hevc_ps: Add sps parse support for HEVC SCC extension syntax
From: Linjie Fu
According to 7.3.2.2.3 in T-REC-H.265-201911.
Signed-off-by: Linjie Fu
Signed-off-by: Haihao Xiang
---
libavcodec/hevc.h| 3 +++
libavcodec/hevc_ps.c | 44 +---
libavcodec/hevc_ps.h | 15 +++
3 files changed, 59 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index 1804755327..6b454a75c1 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -154,6 +154,9 @@ enum {
// get near that, though, so set a lower limit here with the maximum
// possible value for 4K video (at most 135 16x16 Ctb rows).
HEVC_MAX_ENTRY_POINT_OFFSETS = HEVC_MAX_TILE_COLUMNS * 135,
+
+// A.3.7: Screen content coding extensions
+HEVC_MAX_PALETTE_PREDICTOR_SIZE = 128,
};
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 584e2ba0d6..d65efc1aef 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -909,7 +909,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
HEVCWindow *ow;
int ret = 0;
int log2_diff_max_min_transform_block_size;
-int bit_depth_chroma, start, vui_present, sublayer_ordering_info;
+int bit_depth_chroma, start, vui_present, sublayer_ordering_info,
num_comps;
int i;
// Coded parameters
@@ -1130,8 +1130,20 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
decode_vui(gb, avctx, apply_defdispwin, sps);
if (get_bits1(gb)) { // sps_extension_flag
-sps->sps_range_extension_flag = get_bits1(gb);
-skip_bits(gb, 7); //sps_extension_7bits = get_bits(gb, 7);
+sps->sps_range_extension_flag = get_bits1(gb);
+
+/* To keep consistency with the workaround for
hevc-conformance-PS_A_VIDYO_3
+ * in PPS, here ignore sps_multilayer_extension_flag,
sps_3d_extension_flag
+ * and sps_scc_extension_flag for non-SCC streams too. Note
multilayer_extension
+ * or 3d_extension is not implemented in FFmpeg */
+if (sps->ptl.general_ptl.profile_idc == FF_PROFILE_HEVC_SCC) {
+sps->sps_multilayer_extension_flag = get_bits1(gb);
+sps->sps_3d_extension_flag = get_bits1(gb);
+sps->sps_scc_extension_flag= get_bits1(gb);
+skip_bits(gb, 4); //sps_extension_4bits = get_bits(gb, 4);
+} else
+skip_bits(gb, 7);
+
if (sps->sps_range_extension_flag) {
sps->transform_skip_rotation_enabled_flag = get_bits1(gb);
sps->transform_skip_context_enabled_flag = get_bits1(gb);
@@ -1157,6 +1169,32 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
av_log(avctx, AV_LOG_WARNING,
"cabac_bypass_alignment_enabled_flag not yet
implemented\n");
}
+if (sps->sps_multilayer_extension_flag || sps->sps_3d_extension_flag) {
+av_log(avctx, AV_LOG_ERROR,
+ "multilayer_extension or 3d_extension not yet
implemented\n");
+return AVERROR_PATCHWELCOME;
+}
+
+if (sps->sps_scc_extension_flag) {
+sps->sps_curr_pic_ref_enabled_flag = get_bits1(gb);
+sps->palette_mode_enabled_flag = get_bits1(gb);
+if (sps->palette_mode_enabled_flag) {
+sps->palette_max_size = get_ue_golomb_long(gb);
+sps->delta_palette_max_predictor_size = get_ue_golomb_long(gb);
+sps->sps_palette_predictor_initializers_present_flag =
get_bits1(gb);
+
+if (sps->sps_palette_predictor_initializers_present_flag) {
+sps->sps_num_palette_predictor_initializers_minus1 =
get_ue_golomb_long(gb);
+num_comps = !sps->chroma_format_idc ? 1 : 3;
+for (int comp = 0; comp < num_comps; comp++)
+for (i = 0; i <=
sps->sps_num_palette_predictor_initializers_minus1; i++)
+sps->sps_palette_predictor_initializer[comp][i] =
+get_bits(gb, !comp ? sps->bit_depth :
sps->bit_depth_chroma);
+}
+}
+sps->motion_vector_resolution_control_idc = get_bits(gb, 2);
+sps->intra_boundary_filtering_disabled_flag = get_bits1(gb);
+}
}
if (apply_defdispwin) {
sps->output_window.left_offset += sps->vui.def_disp_win.left_offset;
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index 2a1bbf6489..be23758008 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -223,6 +223,21 @@ typedef struct HEVCSPS {
int persistent_rice_adaptation_enabled_flag;
int cabac_bypass_alignment_enabled_flag;
+// Not yet implemented
+int sps_multilayer_extension_flag;
+int sps_3d_extension_flag;
+
+
Re: [FFmpeg-devel] [PATCH v2 0/7] HEVC native support for Screen content coding
On Thu, Nov 19, 2020 at 5:50 AM Michael Niedermayer wrote: > On Thu, Oct 29, 2020 at 02:57:13PM +0100, Christophe Gisquet wrote: > > Hi, > > > > Le mar. 29 sept. 2020 à 17:55, Linjie Fu a > écrit : > > > I didn’t see such plans for now, hence adding sufficient error message > > > seems to be a proper way. > > > > Hi, as you are the only one active on this decoder, this shouldn't > matter, but: > > down the line, the ffmpeg project has no way of testing if someone > > breaks even the basic parsing of these extensions in the future. > > To test, the hardware you mention is needed, as well as maybe specific > tests. > > > > > At some point, fate lacks some support for verifying h/w decoding. It > > would be really nice if some of these companies with all this new > > awesome hardware would consider this, and for instance contribute fate > > instances to perform such test for the ffmpeg project. > > I agree! > Update on mail list for guys who may be interested too: Just discussed with Chris about this through IRC, including how to bridge and get this step further. Regards, Linjie ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avfilter/vf_unsharp: add 10bit support
On Fri, Oct 30, 2020 at 9:18 AM wrote:
> On Thu, Oct 29, 2020 at 09:09:00PM +0800, Linjie Fu wrote:
> > On Thu, Oct 29, 2020 at 7:16 PM wrote:
> >
> > > From: Limin Wang
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > > libavfilter/unsharp.h| 3 +
> > > libavfilter/vf_unsharp.c | 162
> > > +--
> > > 2 files changed, 90 insertions(+), 75 deletions(-)
> > >
> > > diff --git a/libavfilter/unsharp.h b/libavfilter/unsharp.h
> > > index a60b30f..253e32d 100644
> > > --- a/libavfilter/unsharp.h
> > > +++ b/libavfilter/unsharp.h
> > > @@ -48,9 +48,12 @@ typedef struct UnsharpContext {
> > > UnsharpFilterParam luma; ///< luma parameters (width, height,
> > > amount)
> > > UnsharpFilterParam chroma; ///< chroma parameters (width, height,
> > > amount)
> > > int hsub, vsub;
> > > +int bitdepth;
> > > +int bps;
> > > int nb_threads;
> > > int opencl;
> > > int (* apply_unsharp)(AVFilterContext *ctx, AVFrame *in, AVFrame
> > > *out);
> > > +int (* unsharp_slice)(AVFilterContext *ctx, void *arg, int jobnr,
> int
> > > nb_jobs);
> > >
> >
> > Just curious:
> > Any special reason for the function moving?
>
> Sorry, I'm not clear about your question.
>
> >
> > > } UnsharpContext;
> >
> >
> > > #endif /* AVFILTER_UNSHARP_H */
> > > diff --git a/libavfilter/vf_unsharp.c b/libavfilter/vf_unsharp.c
> > > index 7b430b6..416bf1c 100644
> > > --- a/libavfilter/vf_unsharp.c
> > > +++ b/libavfilter/vf_unsharp.c
> > > @@ -57,81 +57,90 @@ typedef struct TheadData {
> > > int height;
> > > } ThreadData;
> > >
> > > -static int unsharp_slice(AVFilterContext *ctx, void *arg, int jobnr,
> int
> > > nb_jobs)
> > > -{
> > > -ThreadData *td = arg;
> > > -UnsharpFilterParam *fp = td->fp;
> > > -uint32_t **sc = fp->sc;
> > > -uint32_t *sr = fp->sr;
> > > -const uint8_t *src2 = NULL; //silence a warning
> > > -const int amount = fp->amount;
> > > -const int steps_x = fp->steps_x;
> > > -const int steps_y = fp->steps_y;
> > > -const int scalebits = fp->scalebits;
> > > -const int32_t halfscale = fp->halfscale;
> > > -
> > > -uint8_t *dst = td->dst;
> > > -const uint8_t *src = td->src;
> > > -const int dst_stride = td->dst_stride;
> > > -const int src_stride = td->src_stride;
> > > -const int width = td->width;
> > > -const int height = td->height;
> > > -const int sc_offset = jobnr * 2 * steps_y;
> > > -const int sr_offset = jobnr * (MAX_MATRIX_SIZE - 1);
> > > -const int slice_start = (height * jobnr) / nb_jobs;
> > > -const int slice_end = (height * (jobnr+1)) / nb_jobs;
> > > -
> > > -int32_t res;
> > > -int x, y, z;
> > > -uint32_t tmp1, tmp2;
> > > -
> > > -if (!amount) {
> > > -av_image_copy_plane(dst + slice_start * dst_stride,
> dst_stride,
> > > -src + slice_start * src_stride,
> src_stride,
> > > -width, slice_end - slice_start);
> > > -return 0;
> > > -}
> > > -
> > > -for (y = 0; y < 2 * steps_y; y++)
> > > -memset(sc[sc_offset + y], 0, sizeof(sc[y][0]) * (width + 2 *
> > > steps_x));
> > > -
> > > -// if this is not the first tile, we start from (slice_start -
> > > steps_y),
> > > -// so we can get smooth result at slice boundary
> > > -if (slice_start > steps_y) {
> > > -src += (slice_start - steps_y) * src_stride;
> > > -dst += (slice_start - steps_y) * dst_stride;
> > > -}
> > > -
> > > -for (y = -steps_y + slice_start; y < steps_y + slice_end; y++) {
> > > -if (y < height)
> > > -src2 = src;
> > > -
> > > -memset(sr + sr_offset, 0, sizeof(sr[0]) * (2 * steps_x - 1));
> > > -for (x = -steps_x; x < width + steps_x; x++) {
> > > -tmp1 = x <= 0 ? src2[0] : x >= width ? src2[width-1] :
> > > src2[x];
> > > -for (z = 0; z < steps_x
Re: [FFmpeg-devel] [PATCH 1/3] avfilter/vf_unsharp: add 10bit support
On Thu, Oct 29, 2020 at 7:16 PM wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/unsharp.h| 3 +
> libavfilter/vf_unsharp.c | 162
> +--
> 2 files changed, 90 insertions(+), 75 deletions(-)
>
> diff --git a/libavfilter/unsharp.h b/libavfilter/unsharp.h
> index a60b30f..253e32d 100644
> --- a/libavfilter/unsharp.h
> +++ b/libavfilter/unsharp.h
> @@ -48,9 +48,12 @@ typedef struct UnsharpContext {
> UnsharpFilterParam luma; ///< luma parameters (width, height,
> amount)
> UnsharpFilterParam chroma; ///< chroma parameters (width, height,
> amount)
> int hsub, vsub;
> +int bitdepth;
> +int bps;
> int nb_threads;
> int opencl;
> int (* apply_unsharp)(AVFilterContext *ctx, AVFrame *in, AVFrame
> *out);
> +int (* unsharp_slice)(AVFilterContext *ctx, void *arg, int jobnr, int
> nb_jobs);
>
Just curious:
Any special reason for the function moving?
> } UnsharpContext;
> #endif /* AVFILTER_UNSHARP_H */
> diff --git a/libavfilter/vf_unsharp.c b/libavfilter/vf_unsharp.c
> index 7b430b6..416bf1c 100644
> --- a/libavfilter/vf_unsharp.c
> +++ b/libavfilter/vf_unsharp.c
> @@ -57,81 +57,90 @@ typedef struct TheadData {
> int height;
> } ThreadData;
>
> -static int unsharp_slice(AVFilterContext *ctx, void *arg, int jobnr, int
> nb_jobs)
> -{
> -ThreadData *td = arg;
> -UnsharpFilterParam *fp = td->fp;
> -uint32_t **sc = fp->sc;
> -uint32_t *sr = fp->sr;
> -const uint8_t *src2 = NULL; //silence a warning
> -const int amount = fp->amount;
> -const int steps_x = fp->steps_x;
> -const int steps_y = fp->steps_y;
> -const int scalebits = fp->scalebits;
> -const int32_t halfscale = fp->halfscale;
> -
> -uint8_t *dst = td->dst;
> -const uint8_t *src = td->src;
> -const int dst_stride = td->dst_stride;
> -const int src_stride = td->src_stride;
> -const int width = td->width;
> -const int height = td->height;
> -const int sc_offset = jobnr * 2 * steps_y;
> -const int sr_offset = jobnr * (MAX_MATRIX_SIZE - 1);
> -const int slice_start = (height * jobnr) / nb_jobs;
> -const int slice_end = (height * (jobnr+1)) / nb_jobs;
> -
> -int32_t res;
> -int x, y, z;
> -uint32_t tmp1, tmp2;
> -
> -if (!amount) {
> -av_image_copy_plane(dst + slice_start * dst_stride, dst_stride,
> -src + slice_start * src_stride, src_stride,
> -width, slice_end - slice_start);
> -return 0;
> -}
> -
> -for (y = 0; y < 2 * steps_y; y++)
> -memset(sc[sc_offset + y], 0, sizeof(sc[y][0]) * (width + 2 *
> steps_x));
> -
> -// if this is not the first tile, we start from (slice_start -
> steps_y),
> -// so we can get smooth result at slice boundary
> -if (slice_start > steps_y) {
> -src += (slice_start - steps_y) * src_stride;
> -dst += (slice_start - steps_y) * dst_stride;
> -}
> -
> -for (y = -steps_y + slice_start; y < steps_y + slice_end; y++) {
> -if (y < height)
> -src2 = src;
> -
> -memset(sr + sr_offset, 0, sizeof(sr[0]) * (2 * steps_x - 1));
> -for (x = -steps_x; x < width + steps_x; x++) {
> -tmp1 = x <= 0 ? src2[0] : x >= width ? src2[width-1] :
> src2[x];
> -for (z = 0; z < steps_x * 2; z += 2) {
> -tmp2 = sr[sr_offset + z + 0] + tmp1; sr[sr_offset + z +
> 0] = tmp1;
> -tmp1 = sr[sr_offset + z + 1] + tmp2; sr[sr_offset + z +
> 1] = tmp2;
> -}
> -for (z = 0; z < steps_y * 2; z += 2) {
> -tmp2 = sc[sc_offset + z + 0][x + steps_x] + tmp1;
> sc[sc_offset + z + 0][x + steps_x] = tmp1;
> -tmp1 = sc[sc_offset + z + 1][x + steps_x] + tmp2;
> sc[sc_offset + z + 1][x + steps_x] = tmp2;
> -}
> -if (x >= steps_x && y >= (steps_y + slice_start)) {
> -const uint8_t *srx = src - steps_y * src_stride + x -
> steps_x;
> -uint8_t *dsx = dst - steps_y * dst_stride + x -
> steps_x;
> -
> -res = (int32_t)*srx + int32_t) * srx -
> (int32_t)((tmp1 + halfscale) >> scalebits)) * amount) >> 16);
> -*dsx = av_clip_uint8(res);
> -}
> -}
> -if (y >= 0) {
> -dst += dst_stride;
> -src += src_stride;
> -}
> -}
> -return 0;
> +#define DEF_UNSHARP_SLICE_FUNC(name, nbits)
> \
> +static int name##_##nbits(AVFilterContext *ctx, void *arg, int jobnr, int
> nb_jobs)\
> +{
> \
> +ThreadData *td = arg;
> \
> +UnsharpFilterParam *fp = td->fp;
> \
> +UnsharpContext *s = ctx->priv;
> \
> +uint32_t **sc = fp->sc;
> \
> +uint32_t *sr =
Re: [FFmpeg-devel] [PATCH] avcodec/hevcdec: constrained intra predict, do not check top left IS_INTRA if it's not available
On Mon, Oct 26, 2020 at 10:29 PM Guangxin Xu wrote:
> The bug reporter confirmed the fix.
> https://trac.ffmpeg.org/ticket/8932
>
> ping for review and merge.
> thanks
>
> On Fri, Oct 16, 2020 at 9:57 PM Xu Guangxin wrote:
>
> > fix ticket: 8932
> >
> > For poc 2, we have tile boundary at x = 640.
> > When we predict cu(640,912),the top left pixel is not avaliable to the
> cu.
> > So, we can not check it's intra or not. We need set top[-1] = top[0]
> > directly.
> > see 8.4.4.2.1 for details
> > ---
> > libavcodec/hevcpred_template.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/hevcpred_template.c
> > b/libavcodec/hevcpred_template.c
> > index 6fe33546b1..e550707874 100644
> > --- a/libavcodec/hevcpred_template.c
> > +++ b/libavcodec/hevcpred_template.c
> > @@ -213,7 +213,7 @@ do { \
> > while (j < size_max_x && !IS_INTRA(j, -1))
> > j++;
> > if (j > 0)
> > -if (x0 > 0) {
> > +if (cand_up_left) {
> > EXTEND_LEFT_CIP(top, j, j + 1);
> > } else {
> > EXTEND_LEFT_CIP(top, j, j);
> > --
> > 2.17.1
> >
> >
Looks reasonable, also verified there is no garbage anymore.
Prefer to apply soon if no objections.
- Linjie
___
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 0/7] HEVC native support for Screen content coding
On Tue, Sep 29, 2020 at 22:03 Mark Thompson wrote: > On 10/09/2020 07:42, Haihao Xiang wrote: > > > Resend Linjie's patchset with the updates. > > > > > > As a part of the support for VA-API HEVC SCC decoding (gen12, Tiger > > > Lake+). > > > > > > The full support could be accessed in: > > > https://github.com/intel-media-ci/ffmpeg/pull/231 > > > > > > The VAAPI part would be provided later once the implementations of > > > native parsing and reference management are all decent. > > > > > > Linjie Fu (7): > > >lavc/avcodec: Add FF_PROFILE_HEVC_SCC for screen content coding > > >lavc/hevc_ps: Add sps parse support for HEVC SCC extension syntax > > >lavc/hevc_ps: Add pps parse support for HEVC SCC extension > > >lavc/hevc_ps: Add slice parse support for HEVC SCC extension > > >lavc/hevcdec: Fix the parsing for use_integer_mv_flag > > >lavc/hevcdec: Set max_num_merge_cand to uint8_t > > >lavc/hevc: Update reference list for SCC > > > > > > libavcodec/avcodec.h | 1 + > > > libavcodec/hevc.h | 3 ++ > > > libavcodec/hevc_ps.c | 118 +++-- > > > libavcodec/hevc_ps.h | 32 +++ > > > libavcodec/hevc_refs.c | 27 +- > > > libavcodec/hevcdec.c | 17 +- > > > libavcodec/hevcdec.h | 7 ++- > > > libavcodec/profiles.c | 1 + > > > 8 files changed, 197 insertions(+), 9 deletions(-) > > > > This looks generally pretty good, but the lack of a software > implementation is kindof unfortunate - is there any plan to do anything > about that? > > If not, I think you need to make sure that all of the newly-added flags > give a suitable error message to say that it isn't supported. (Especially > in cases like use_integer_mv_flag where it can return incorrect output > while saying that everything is fine.) I didn’t see such plans for now, hence adding sufficient error message seems to be a proper way. > > It seems to always hang with all threads waiting for each other when given > a non-software-decodable SCC stream with threads enabled (it hangs forever > entirely repeatably before the SIGINT): > > > > $ ./ffmpeg_g -threads 2 -i PPI_A_InterDigital_2.bit -f null - > > ... > > Stream #0:0: Video: hevc (Scc), yuv444p(tv), 1280x720, 25 fps, 25 > tbr, 1200k tbn, 25 tbc > > [hevc @ 0x57b3a680] high_precision_offsets_enabled_flag not yet > implemented > > [hevc @ 0x57b3a680] Overread PPS by 8 bits > > [New Thread 0x7344f700 (LWP 1954956)] > > [New Thread 0x72c4e700 (LWP 1954957)] > > Stream mapping: > > > >Stream #0:0 -> #0:0 (hevc (native) -> wrapped_avframe (native)) > > Press [q] to stop, [?] for help > > [hevc @ 0x57b3a680] high_precision_offsets_enabled_flag not yet > implemented > > [hevc @ 0x57b3a680] Overread PPS by 8 bits > > [hevc @ 0x57b3a680] PPS id out of range: 0 > > [hevc @ 0x57b3a680] Error parsing NAL unit #3. > > Error while decoding stream #0:0: Invalid data found when processing input > > > > Thread 1 "ffmpeg_g" received signal SIGINT, Interrupt. > > futex_wait_cancelable (private=0, expected=0, futex_word=0x57b4cd90) > at ../sysdeps/nptl/futex-internal.h:183 > > 183 ../sysdeps/nptl/futex-internal.h: No such file or directory. > > (gdb) i thr > >Id Target Id Frame > > * 1Thread 0x734561c0 (LWP 1954952) "ffmpeg_g" > futex_wait_cancelable (private=0, expected=0, futex_word=0x57b4cd90) at > ../sysdeps/nptl/futex-internal.h:183 > >2Thread 0x7344f700 (LWP 1954956) "ffmpeg_g" > futex_wait_cancelable (private=0, expected=0, futex_word=0x57b4cb80) at > ../sysdeps/nptl/futex-internal.h:183 > >3Thread 0x72c4e700 (LWP 1954957) "ffmpeg_g" > futex_wait_cancelable (private=0, expected=0, futex_word=0x57b4cd64) at > ../sysdeps/nptl/futex-internal.h:183 > > (gdb) thr ap al bt > > > > Thread 3 (Thread 0x72c4e700 (LWP 1954957)): > > #0 futex_wait_cancelable (private=0, expected=0, > futex_word=0x57b4cd64) at ../sysdeps/nptl/futex-internal.h:183 > > #1 __pthread_cond_wait_common (abstime=0x0, clockid=0, > mutex=0x57b4cdc0, cond=0x57b4cd38) at pthread_cond_wait.c:508 > > #2 __pthread_cond_wait (cond=0x57b4cd38, mutex=0x57b4cdc0) at > pthread_cond_wait.c:638 > > #3 0x560eaed8 in strict_pthread_cond_wait (cond=0x57b4cd38, > mutex=0x57b4cdc0)
Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: fix max_transform_hierarchy_depth_inter/intra
On Thu, Sep 3, 2020 at 1:32 PM Xiang, Haihao wrote: > > On Mon, 2020-04-13 at 13:06 +, Fu, Linjie wrote: > > > From: ffmpeg-devel On Behalf Of > > > Mark Thompson > > > Sent: Monday, April 13, 2020 20:20 > > > To: ffmpeg-devel@ffmpeg.org > > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: fix > > > max_transform_hierarchy_depth_inter/intra > > > > > > On 13/04/2020 05:32, Linjie Fu wrote: > > > > Set the max_transform_hierarchy_depth_inter/intra to 2 by default > > > > based on the Programmer's Reference Manuals (PRM) in [1]. > > > > > > > > Intel Encoder only supports 2 levels of quad-tree. That is: > > > > - max_transform_hierarchy_depth_inter/intra <= 2. > > > > > > > > [1] > > > > <https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc- > > > > > > kbl-vol10-hevc.pdf> > > > > > > > > Signed-off-by: Linjie Fu > > > > --- > > > > Fixed value for intel platform, makes more sense on TGL+ platform. > > > > (If conflict with other driver capability, we may add query support > > > > later) > > > > libavcodec/vaapi_encode_h265.c | 5 +++-- > > > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/libavcodec/vaapi_encode_h265.c > > > > > > b/libavcodec/vaapi_encode_h265.c > > > > index cd48545..d6cb82a 100644 > > > > --- a/libavcodec/vaapi_encode_h265.c > > > > +++ b/libavcodec/vaapi_encode_h265.c > > > > @@ -445,8 +445,9 @@ static int > > > > > > vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx) > > > > sps->log2_min_luma_transform_block_size_minus2 = 0; > > > > sps->log2_diff_max_min_luma_transform_block_size = 3; > > > > // Full transform hierarchy allowed (2-5). > > > > -sps->max_transform_hierarchy_depth_inter = 3; > > > > -sps->max_transform_hierarchy_depth_intra = 3; > > > > +// Default to 2 based on Programmer's Reference Manuals of Intel > > > > > > graphics > > > > +sps->max_transform_hierarchy_depth_inter = 2; > > > > +sps->max_transform_hierarchy_depth_intra = 2; > > > > // AMP works. > > > > sps->amp_enabled_flag = 1; > > > > // SAO and temporal MVP do not work. > > > > > > > > > > I don't much like the idea of changing this based on a value in a Kaby > > > Lake > > > document given that the current value hasn't had any problems on Kaby > > > Lake. > > > Can you explain the benefits of changing this? > > > > It fixes the encoding issue for HEVC on gen12+ platform. > > We didn't notice this either, until it triggers gpu hang for encoding on > > Tiger > > Lake (gen12). > > > > > Can you confirm that it continues to work on all the other > > > currently-working > > > platforms? > > > > > > > Yes, we set up CI and runs full-round tests for conformance and catch > > regression on different > > platforms(CFL/CML/ICL/KBL/SKL). > > > > Identical fix has been merged in gstreamer-vaapi, no regression is detected > > on > > other platforms. > > > https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/282/diffs?commit_id=17d82e14e78af901f1cd7f2344e173ad6ae6a8a6 > > Hi Mark, > > Till now we didn't see regression with Linjie's patch, do you have any other > concern on Linjie's patch? > Also ping for this, since TGL has been announced recently. - Linjie ___ 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] lavf/mux: allow unofficial extension by default for spatial data in mp4
On Fri, Aug 28, 2020 at 11:18 AM Linjie Fu wrote:
>
> Hi,
>
> On Fri, Aug 28, 2020 at 8:46 AM Andreas Rheinhardt
> wrote:
> >
> > Linjie Fu:
> > > Mp4 unofficial extension allows Stereo3D and Spherical Mapping data
> > > in header if users explicitly set "-strict unofficial" or values less
> > > than "-1".
> > >
> > > Currently side_data like stereo3D and spherical data in mp4 would be
> > > dropped by default in a transcoding procedure even if user uses streamcopy
> > > to get the same bitstreams. Spatial data missing in containers seems to
> > > cause troubles for the players like VLC while detecting the projection
> > > type
> > > for 360 video.
> > >
> > > Set the default value of "strict" to "unofficial" for mp4.
> > >
> > > Signed-off-by: Linjie Fu
> > > ---
> > > I would prefer to add the default value for format-specific options in
> > > something
> > > like AVCodecDefault, however didn't find one.
> > > libavformat/mux.c | 5 +
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/libavformat/mux.c b/libavformat/mux.c
> > > index 44d5e5d1c0..ffb9109a6f 100644
> > > --- a/libavformat/mux.c
> > > +++ b/libavformat/mux.c
> > > @@ -237,6 +237,11 @@ static int init_muxer(AVFormatContext *s,
> > > AVDictionary **options)
> > > const AVCodecDescriptor *desc;
> > > AVDictionaryEntry *e;
> > >
> > > +if (s->oformat) {
> > > +if (!strcmp("mp4", s->oformat->name))
> > > +s->strict_std_compliance = FF_COMPLIANCE_UNOFFICIAL;
> > > +}
> > > +
> > > if (options)
> > > av_dict_copy(, *options, 0);
> > >
> > 1. s->oformat must already be set at this point.
> > 2. You seem to believe that the only way for the user to set
> > strict_std_compliance etc. is by providing via the a dict provided to
> > avformat_init_output/write_header(). This is wrong. The user can also
> > set it before that. Your patch would break this.
>
> It's like a priority order issue of:
> 1. user specified somehow in AVFormatContext;
> 2. user explicitly sets through options;
> 3. default value for specific container.
>
> The logic for profile choosing in libopenh264enc seems to be good if we we had
> a default value of something like "unknown" instead of "normal", since we
> can't
> tell whether the "normal" is derived by user's choice or just a default value:
> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libopenh264enc.c#L198
>
> > Obviously you have no way to distinguish whether the user explicitly set
> > the option to FF_COMPLIANCE_NORMAL (and even less way to know whether
> > the user intentionally doesn't want unofficial extensions and therefore
> > opted to not touch strict_std_compliance).
>
> If I understood it correctly, user explicitly setting "strict" to
> "normal" is able to be distinguished.
> av_opt_set_dict() is able to replace the default "unofficial" with the
> user specified "normal":
> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mux.c#L243
>
> > 3. One could print a warning in case the such unofficial extensions are
> > dropped.
> Sure, a warning should be added.
>
> > 3. How "unofficial" is this extension anyway? After all, the default
> > mode intentionally differs from FF_COMPLIANCE_STRICT.
>
> Defined as unofficial in 86dee47e397fe6bb0907adae8d4a54138a947646.
>
> Seems to be defined in:
> https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
>
> which is also cited/referenced by youtube hellp with details for
> adding metadata by ffmpeg:
> https://support.google.com/youtube/answer/7278886?hl=en
>
To make this easier to be reproduced/verified, attached the clips:
https://drive.google.com/file/d/1tU1HuPvCzOyYY3UBp2Eh7Xi8NWldczxD/view?usp=sharing
$ ffmpeg -i
Professional+4K+360°+live+streaming+with+Insta360+Pro+and+Yi+360+VR.mp4
-c:v copy -an -y out.mp4
$ ffmpeg -i out.mp4
Then check the side data information.
___
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] lavf/mux: allow unofficial extension by default for spatial data in mp4
Hi,
On Fri, Aug 28, 2020 at 8:46 AM Andreas Rheinhardt
wrote:
>
> Linjie Fu:
> > Mp4 unofficial extension allows Stereo3D and Spherical Mapping data
> > in header if users explicitly set "-strict unofficial" or values less
> > than "-1".
> >
> > Currently side_data like stereo3D and spherical data in mp4 would be
> > dropped by default in a transcoding procedure even if user uses streamcopy
> > to get the same bitstreams. Spatial data missing in containers seems to
> > cause troubles for the players like VLC while detecting the projection type
> > for 360 video.
> >
> > Set the default value of "strict" to "unofficial" for mp4.
> >
> > Signed-off-by: Linjie Fu
> > ---
> > I would prefer to add the default value for format-specific options in
> > something
> > like AVCodecDefault, however didn't find one.
> > libavformat/mux.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/libavformat/mux.c b/libavformat/mux.c
> > index 44d5e5d1c0..ffb9109a6f 100644
> > --- a/libavformat/mux.c
> > +++ b/libavformat/mux.c
> > @@ -237,6 +237,11 @@ static int init_muxer(AVFormatContext *s, AVDictionary
> > **options)
> > const AVCodecDescriptor *desc;
> > AVDictionaryEntry *e;
> >
> > +if (s->oformat) {
> > +if (!strcmp("mp4", s->oformat->name))
> > +s->strict_std_compliance = FF_COMPLIANCE_UNOFFICIAL;
> > +}
> > +
> > if (options)
> > av_dict_copy(, *options, 0);
> >
> 1. s->oformat must already be set at this point.
> 2. You seem to believe that the only way for the user to set
> strict_std_compliance etc. is by providing via the a dict provided to
> avformat_init_output/write_header(). This is wrong. The user can also
> set it before that. Your patch would break this.
It's like a priority order issue of:
1. user specified somehow in AVFormatContext;
2. user explicitly sets through options;
3. default value for specific container.
The logic for profile choosing in libopenh264enc seems to be good if we we had
a default value of something like "unknown" instead of "normal", since we can't
tell whether the "normal" is derived by user's choice or just a default value:
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libopenh264enc.c#L198
> Obviously you have no way to distinguish whether the user explicitly set
> the option to FF_COMPLIANCE_NORMAL (and even less way to know whether
> the user intentionally doesn't want unofficial extensions and therefore
> opted to not touch strict_std_compliance).
If I understood it correctly, user explicitly setting "strict" to
"normal" is able to be distinguished.
av_opt_set_dict() is able to replace the default "unofficial" with the
user specified "normal":
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mux.c#L243
> 3. One could print a warning in case the such unofficial extensions are
> dropped.
Sure, a warning should be added.
> 3. How "unofficial" is this extension anyway? After all, the default
> mode intentionally differs from FF_COMPLIANCE_STRICT.
Defined as unofficial in 86dee47e397fe6bb0907adae8d4a54138a947646.
Seems to be defined in:
https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
which is also cited/referenced by youtube hellp with details for
adding metadata by ffmpeg:
https://support.google.com/youtube/answer/7278886?hl=en
- Linjie
___
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] lavf/mux: allow unofficial extension by default for spatial data in mp4
Mp4 unofficial extension allows Stereo3D and Spherical Mapping data
in header if users explicitly set "-strict unofficial" or values less
than "-1".
Currently side_data like stereo3D and spherical data in mp4 would be
dropped by default in a transcoding procedure even if user uses streamcopy
to get the same bitstreams. Spatial data missing in containers seems to
cause troubles for the players like VLC while detecting the projection type
for 360 video.
Set the default value of "strict" to "unofficial" for mp4.
Signed-off-by: Linjie Fu
---
I would prefer to add the default value for format-specific options in something
like AVCodecDefault, however didn't find one.
libavformat/mux.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 44d5e5d1c0..ffb9109a6f 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -237,6 +237,11 @@ static int init_muxer(AVFormatContext *s, AVDictionary
**options)
const AVCodecDescriptor *desc;
AVDictionaryEntry *e;
+if (s->oformat) {
+if (!strcmp("mp4", s->oformat->name))
+s->strict_std_compliance = FF_COMPLIANCE_UNOFFICIAL;
+}
+
if (options)
av_dict_copy(, *options, 0);
--
2.28.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, RFC] lavc/hevcdec: add invalid for skip_frame to skip invalid nalus before IRAP
Add "-skip_frame invalid" option to allow user to request decoder to skip
invalid nalus before an IRAP.
This would benefit decoding pipeline of bitstreams who didn't start from
an IRAP frame. NULL pointer pointing to missing reference may lead to
unexpected hang issues[1] in sub-level like hardware decoding.
Fixing the hang in driver is the first correct thing. Besides, adding a check
in nalu parsing and skip frames until we got the first IRAP would be another
good choice to be more robust for error tolerance.
Also this needs worker thread to update the skip_frames field in time.
[1] https://github.com/intel/media-driver/issues/992
Signed-off-by: Linjie Fu
---
Request for comments:
The purpose is to allow decoder to skip frames until an IRAP has arrived,
however
not sure whether we already had this in ffmpeg, hence submit a patch and
request for comments.
Skip logic identical for AVDISCARD_NONKEY in decode_nal_unit().
libavcodec/avcodec.h | 1 +
libavcodec/hevcdec.c | 5 -
libavcodec/options_table.h | 1 +
libavcodec/pthread_frame.c | 1 +
4 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c91b2fd169..376d7f4d6d 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -233,6 +233,7 @@ enum AVDiscard{
AVDISCARD_BIDIR = 16, ///< discard all bidirectional frames
AVDISCARD_NONINTRA= 24, ///< discard all non intra frames
AVDISCARD_NONKEY = 32, ///< discard all frames except keyframes
+AVDISCARD_INVALID = 33, ///< discard invalid packets like NALs before IRAP
AVDISCARD_ALL = 48, ///< discard all
};
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index b77df8d89f..78658fd537 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -539,8 +539,11 @@ static int hls_slice_header(HEVCContext *s)
ff_hevc_clear_refs(s);
}
sh->no_output_of_prior_pics_flag = 0;
-if (IS_IRAP(s))
+if (IS_IRAP(s)) {
sh->no_output_of_prior_pics_flag = get_bits1(gb);
+if (s->avctx->skip_frame == AVDISCARD_INVALID)
+s->avctx->skip_frame = AVDISCARD_DEFAULT;
+}
sh->pps_id = get_ue_golomb_long(gb);
if (sh->pps_id >= HEVC_MAX_PPS_COUNT || !s->ps.pps_list[sh->pps_id]) {
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index 1d0db1b5a4..d52bce5908 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -310,6 +310,7 @@ static const AVOption avcodec_options[] = {
{"bidir" , "discard all bidirectional frames",0,
AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_BIDIR }, INT_MIN, INT_MAX, V|D,
"avdiscard"},
{"nokey" , "discard all frames except keyframes", 0,
AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONKEY }, INT_MIN, INT_MAX, V|D,
"avdiscard"},
{"nointra" , "discard all frames except I frames", 0,
AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_NONINTRA}, INT_MIN, INT_MAX, V|D,
"avdiscard"},
+{"invalid" , "discard NALUs before IRAP", 0,
AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_INVALID }, INT_MIN, INT_MAX, V|D,
"avdiscard"},
{"all" , "discard all frames", 0,
AV_OPT_TYPE_CONST, {.i64 = AVDISCARD_ALL }, INT_MIN, INT_MAX, V|D,
"avdiscard"},
{"bidir_refine", "refine the two motion vectors used in bidirectional
macroblocks", OFFSET(bidir_refine), AV_OPT_TYPE_INT, {.i64 = 1 }, 0, 4, V|E},
#if FF_API_PRIVATE_OPT
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 3255aa9337..302e6149ac 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -259,6 +259,7 @@ static int update_context_from_thread(AVCodecContext *dst,
AVCodecContext *src,
dst->has_b_frames = src->has_b_frames;
dst->idct_algo= src->idct_algo;
+dst->skip_frame = src->skip_frame;
dst->bits_per_coded_sample = src->bits_per_coded_sample;
dst->sample_aspect_ratio = src->sample_aspect_ratio;
--
2.28.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/3] vaapi_encode: Rewrite slice/tile support
On Fri, Aug 14, 2020 at 5:51 AM Mark Thompson wrote: > > This precalculates all of the information we will need to define slice > and tile positions at init time rather than rebuilding some of it with > every slice. The control of tiles is generalised to match slices, so that > arbitrary tile and slice layouts are possible within the constraint that > slices can't cross tile boundaries (which comes from how VAAPI handles > slices and tiles). Support for the EQUAL_MULTI_ROWS slice structure fits > easily into this, so it is added at the same time. Some inputs for EQUAL_MULTI_ROWS slice structure, I believe there are some discussions in libva and hw behavior team. To be honest, I don't think the current notation/comment is suitable for what the hw could do. - Linjie ___ 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".
