date:20210916

Nicolas George (12021-09-12):
> Will push this series soon.

Series pushed.

ffmpeg + lsdvd + dvd2concat can now encode DVDs reasonably well.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/4] libavcodec/adts_header: add frame_length field and avpriv function to parse AAC ADTS header

2021-09-16 Thread Steven Liu

Nachiket Tarate  于2021年9月1日周三 下午10:39写道：
>
> These will be used by HLS demuxer in case of sample decryption.
>
> Signed-off-by: Nachiket Tarate 
> ---
>  libavcodec/adts_header.c |  1 +
>  libavcodec/adts_header.h | 15 +++
>  libavcodec/adts_parser.c | 31 +++
>  3 files changed, 47 insertions(+)
>
> diff --git a/libavcodec/adts_header.c b/libavcodec/adts_header.c
> index 0889820f8a..e4454529c4 100644
> --- a/libavcodec/adts_header.c
> +++ b/libavcodec/adts_header.c
> @@ -66,6 +66,7 @@ int ff_adts_header_parse(GetBitContext *gbc, 
> AACADTSHeaderInfo *hdr)
>  hdr->sample_rate= avpriv_mpeg4audio_sample_rates[sr];
>  hdr->samples= (rdb + 1) * 1024;
>  hdr->bit_rate   = size * 8 * hdr->sample_rate / hdr->samples;
> +hdr->frame_length   = size;
>
>  return size;
>  }
> diff --git a/libavcodec/adts_header.h b/libavcodec/adts_header.h
> index f615f6a9f9..166a28ffc9 100644
> --- a/libavcodec/adts_header.h
> +++ b/libavcodec/adts_header.h
> @@ -34,6 +34,7 @@ typedef struct AACADTSHeaderInfo {
>  uint8_t  sampling_index;
>  uint8_t  chan_config;
>  uint8_t  num_aac_frames;
> +uint32_t frame_length;
>  } AACADTSHeaderInfo;
>
>  /**
> @@ -47,4 +48,18 @@ typedef struct AACADTSHeaderInfo {
>   */
>  int ff_adts_header_parse(GetBitContext *gbc, AACADTSHeaderInfo *hdr);
>
> +/**
> + * Parse the ADTS frame header contained in the buffer, which is
> + * the first 54 bits.
> + * @param[in]  buf  Pointer to buffer containing the first 54 bits of the 
> frame.
> + * @param[in]  size Size of buffer containing the first 54 bits of the frame.
> + * @param[out] phdr Pointer to pointer to struct AACADTSHeaderInfo for which
> + * memory is allocated and header info is written into it. After using the 
> header
> + * information, the allocated memory must be freed by using av_free().
> + * @return Returns 0 on success, -1 if there is a sync word mismatch,
> + * -2 if the version element is invalid, -3 if the sample rate
> + * element is invalid, or -4 if the bit rate element is invalid.
> + */
> +int avpriv_adts_header_parse(AACADTSHeaderInfo **phdr, const uint8_t *buf, 
> size_t size);
> +
>  #endif /* AVCODEC_ADTS_HEADER_H */
> diff --git a/libavcodec/adts_parser.c b/libavcodec/adts_parser.c
> index 5c9f8ff6f2..4a1a8fd5f4 100644
> --- a/libavcodec/adts_parser.c
> +++ b/libavcodec/adts_parser.c
> @@ -42,3 +42,34 @@ int av_adts_header_parse(const uint8_t *buf, uint32_t 
> *samples, uint8_t *frames)
>  return AVERROR(ENOSYS);
>  #endif
>  }
> +
> +int avpriv_adts_header_parse(AACADTSHeaderInfo **phdr, const uint8_t *buf, 
> size_t size)
> +{
> +#if CONFIG_ADTS_HEADER
> +int ret = 0;
> +GetBitContext gb;
> +
> +if (!phdr || !buf || size < AV_AAC_ADTS_HEADER_SIZE)
> +return AVERROR_INVALIDDATA;
> +
> +*phdr = av_mallocz(sizeof(AACADTSHeaderInfo));
> +if (!*phdr)
> +return AVERROR(ENOMEM);
> +
> +ret = init_get_bits8(&gb, buf, AV_AAC_ADTS_HEADER_SIZE);
> +if (ret < 0) {
> +av_freep(phdr);
> +return ret;
> +}
> +
> +ret = ff_adts_header_parse(&gb, *phdr);
> +if (ret < 0) {
> +av_freep(phdr);
> +return ret;
> +}
> +
> +return 0;
> +#else
> +return AVERROR(ENOSYS);
> +#endif
> +}
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


looks have been fixed the suggestion from zhili.
Will apply patchset if no more comments
___
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] avformat/mxf: support MCA audio information

2021-09-16 Thread Tomas Härdin

ons 2021-09-15 klockan 12:14 +0200 skrev Marc-Antoine Arnaud:

+static int mxf_read_mca_sub_descriptor(void *arg, AVIOContext *pb, int
tag, int size, UID uid, int64_t klv_offset)
+{
+    MXFMCASubDescriptor *mca_sub_descriptor = arg;
+
+    if (IS_KLV_KEY(uid, mxf_mca_prefix)) {
+    if (IS_KLV_KEY(uid, mxf_mca_label_dictionnary_id)) {
+    avio_read(pb, mca_sub_descriptor-
>mca_label_dictionnary_id, 16);
+    }
+    if (IS_KLV_KEY(uid, mxf_mca_link_id)) {
+    avio_read(pb, mca_sub_descriptor->mca_link_id, 16);
+    }
+    if (IS_KLV_KEY(uid, mxf_soundfield_group_link_id)) {
+    avio_read(pb, mca_sub_descriptor->mca_group_link_id, 16);
+    }
+    }

This nesting of ifs is unnecessary

Rest of the patch looks fine. Passes FATE. Do you have a sample or two?

/Tomas

___
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 v5 00/12] Subtitle Filtering

Hendrik Leppkes (12021-09-15):
> Or perhaps some people have a day job, a life and other obligations
> that prevent them from spending time on FFmpeg every day, especially
> outside the weekend.
> But no, that can't be it, surely we are all just evil. /s

> Nothing here is being invented. You are trying to push a major API
> change to the core functionality of our libraries, these rules on how
> to do API changes on that level (or any level, really) have been in
> place and followed by everyone for years and years.
> If you don't believe that, feel free to check how any other major API
> change was handled in the past. Because the overall pattern is always
> the same.
> 
> Do you think I'm the only one thinking that way, only because I spoke
> up? The set certainly wouldn't have been applied if I hadn't said
> anything, it would've just sat there. Maybe someone else might've come
> forward eventually.

Thank you for having the patience and taking the time to explain this.

> As for the actual subject:
> - Part1, add subtitles to AVFrame in avutil. You can move
> enums/structs to avutil as needed (eg AVSubtitleRect or whatever), as
> long as they are still available the same way (eg. avcodec.h should
> include any new avutil header with them, so user code works without
> changes), but moving functions is a more tricky business, so we
> usually make new functions and cleanup their naming convention in the
> process, but I don't think any functions are involved here right now.
> 
> To dive a bit deeper into this, redundant fields should be removed,
> actual subtitle data should be refcounted (with AVBuffers in
> AVFrame->buf), all frame functionality need to properly account for
> the new data type.

There is another point to consider when designing subtitles in AVFrame:
since we intend it not only as a general API cleanup but as a prelude to
extending the API with filtering and such, we must not only think about
what is needed now, we must think about what may be needed later.

The few examples I have, not excluding questions I have not thought of:

- Right now, we have text subtitles and bitmap subtitles. But do we want
  to be able to handle mixed text and bitmap subtitles?

  To this, I would say: probably no. But we should give it a thought.

- Number of rectangles. Currently, the decoders usually output a very
  limited number of rectangles. OTOH, libass may output three alpha maps
  per glyph, that makes potentially hundreds of rectangles.

  Will the data structure be able to handle this efficiently?

  Consider also the issue of rectangles overlapping.

- Speaking of overlapping, we need a system to signal whether a new
  subtitle frame should replace the current one (like dvdsub, srt, etc.)
  or overlap with it (like ASS).

- Colorspace. All current bitmap subtitles formats are paletted. But
  palette pixel formats are bad for many treatments. Inside a filter
  chain, it would probably make sense to have them in a true color
  format.

- Global styles. ASS subtitles, in particular, contain reference to
  globally-defined styles. How do we handle that in libavfilter? I have
  no idea.

- Sparseness. Subtitles streams have gaps, and synchronization with
  other streams requires a next frame, that can be minutes away or never
  come. This needs to be solved in a way compatible with processing.

> - Part3, avfilter support for subtitles in AVFrames. At this point we
> have a defined structure to store subtitles in AVFrames, and actual
> code that can generate or consume them. When approaching this, the
> same rules apply as before, existing subtitle functionality, as crude
> as it may be, has to remain functional as exposed to the user.
> Internal under-the-hood changes are fine, as long as the user does not
> notice.
> 
> I'm not involved in internal avfilter design, so at this point you'll
> have to get Nicolas on board.

The most salient point is negotiation. I have already said it and I say
it again, because the format negotiation in libavfilter is a very
important aspect of what makes it work well, and it is also a very
tricky piece of code.

We need to decide which aspects of the subtitles formats are negotiated.

At least, obviously, the text or bitmap aspect will be, with a
conversion filter inserted automatically where needed.

But depending on the answers to the questions in part 1, we may need to
negotiate the pixel format and colorspace too.

Unfortunately, the current negotiation code is messy and fragile. We
cannot afford to pile new code on top of it. However good the new code
may be, adding it on top of messy code would only make it harder to
clean up and maintain later. I absolutely oppose that.

Therefore, if anybody wants to add something to libavfilter that
involves the negotiation, they should consider helping cleaning it up.
It would make your work easier afterwards, so you should do it if only
for that reason.

The first task, as I have mentioned, would probably be to add FATE tes

[FFmpeg-devel] [PATCH 1/5] avcodec/libsvtav1: Fix redundant setting of caps_internal

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/libsvtav1.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index fabc4e6..82ae2b9 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -561,12 +561,11 @@ const AVCodec ff_libsvtav1_encoder = {
 .receive_packet = eb_receive_packet,
 .close  = eb_enc_close,
 .capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS,
-.caps_internal  = FF_CODEC_CAP_AUTO_THREADS,
+.caps_internal  = FF_CODEC_CAP_AUTO_THREADS | FF_CODEC_CAP_INIT_CLEANUP,
 .pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
 AV_PIX_FMT_YUV420P10,
 AV_PIX_FMT_NONE },
 .priv_class = &class,
 .defaults   = eb_enc_defaults,
-.caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
 .wrapper_name   = "libsvtav1",
 };
-- 
1.8.3.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/5] avcodec/libsvtav1: make intra_refresh_type configurable

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/libsvtav1.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 82ae2b9..8c2c970 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -210,7 +210,8 @@ static int config_enc_params(EbSvtAv1EncConfiguration 
*param,
 param->min_qp_allowed   = avctx->qmin;
 }
 
-param->intra_refresh_type   = 2; /* Real keyframes only */
+/* 2 = IDR, closed GOP, 1 = CRA, open GOP */
+param->intra_refresh_type = avctx->flags & AV_CODEC_FLAG_CLOSED_GOP ? 2 : 
1;
 
 if (svt_enc->la_depth >= 0)
 param->look_ahead_distance  = svt_enc->la_depth;
@@ -548,6 +549,7 @@ static const AVCodecDefault eb_enc_defaults[] = {
 { "g", "-1"},
 { "qmin",  "0" },
 { "qmax",  "63"},
+{ "flags", "+cgop" },
 { NULL },
 };
 
-- 
1.8.3.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/5] doc: update for libsvtav1 encoder

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 doc/encoders.texi | 44 
 1 file changed, 44 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 8fccd73..64d604e 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1750,12 +1750,56 @@ You need to explicitly configure the build with 
@code{--enable-libsvtav1}.
 @table @option
 @item profile
 Set the encoding profile.
+@table @samp
+@item main
+@item high
+@item professional
+@end table
 
 @item level
 Set the operating point level.
+@table @samp
+@item 2.0
+@item 2.1
+@item 2.2
+@item 2.3
+@item 3.0
+@item 3.1
+@item 3.2
+@item 3.3
+@item 4.0
+@item 4.1
+@item 4.2
+@item 4.3
+@item 5.0
+@item 5.1
+@item 5.2
+@item 5.3
+@item 6.0
+@item 6.1
+@item 6.2
+@item 6.3
+@item 7.0
+@item 7.1
+@item 7.2
+@item 7.3
+@end table
+
+@item hielevel
+Set the Hierarchical prediction levels.
+@table @samp
+@item 3level
+@item 4level, This is the default.
+@end table
 
 @item tier
 Set the operating point tier.
+@table @samp
+@item main
+The main tier was designed for most applications. This is the default.
+@item high
+The high tier was designed for very demanding applications.
+@end table
 
 @item rc
 Set the rate control mode to use.
-- 
1.8.3.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 4/5] avcodec/libsvtav1: Fix CQP mode doesn't work as expection

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavcodec/libsvtav1.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 8c2c970..1f1f86b 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -208,6 +208,8 @@ static int config_enc_params(EbSvtAv1EncConfiguration 
*param,
 if (param->rate_control_mode) {
 param->max_qp_allowed   = avctx->qmax;
 param->min_qp_allowed   = avctx->qmin;
+} else {
+param->enable_tpl_la = 0; /* CQP need turn off enable_tp_la */
 }
 
 /* 2 = IDR, closed GOP, 1 = CRA, open GOP */
-- 
1.8.3.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 5/5] avcodec/libsvtav1: support constant quality mode

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 doc/encoders.texi  |  7 ++-
 libavcodec/libsvtav1.c | 10 +-
 libavcodec/version.h   |  2 +-
 3 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 64d604e..2300bb9 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1807,9 +1807,11 @@ Set the rate control mode to use.
 Possible modes:
 @table @option
 @item cqp
-Constant quantizer: use fixed values of qindex (dependent on the frame type)
+Constant quantizer(not set crf): use fixed values of qindex (dependent on the 
frame type)
 throughout the stream.  This mode is the default.
 
+Constant quality(set crf): maintain a constant QP throughout the stream.
+
 @item vbr
 Variable bitrate: use a target bitrate for the whole stream.
 
@@ -1826,6 +1828,9 @@ Set the minimum quantizer to use when using a bitrate 
mode.
 @item qp
 Set the quantizer used in cqp rate control mode (0-63).
 
+@item crf
+Select the quality for constant quality mode (0-63).
+
 @item sc_detection
 Enable scene change detection.
 
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 1f1f86b..29be4bd 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -66,6 +66,7 @@ typedef struct SvtContext {
 int rc_mode;
 int scd;
 int qp;
+int crf;
 
 int tier;
 
@@ -210,6 +211,10 @@ static int config_enc_params(EbSvtAv1EncConfiguration 
*param,
 param->min_qp_allowed   = avctx->qmin;
 } else {
 param->enable_tpl_la = 0; /* CQP need turn off enable_tp_la */
+if ( svt_enc->crf > 0) {
+param->qp = svt_enc->crf;
+param->enable_tpl_la = 1;
+}
 }
 
 /* 2 = IDR, closed GOP, 1 = CRA, open GOP */
@@ -523,13 +528,16 @@ static const AVOption options[] = {
 
 { "rc", "Bit rate control mode", OFFSET(rc_mode),
   AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 3, VE , "rc"},
-{ "cqp", "Constant quantizer", 0, AV_OPT_TYPE_CONST, { .i64 = 0 },  
INT_MIN, INT_MAX, VE, "rc" },
+{ "cqp", "Constant quantizer(not set crf), Constant quality(set crf)", 
0, AV_OPT_TYPE_CONST, { .i64 = 0 },  INT_MIN, INT_MAX, VE, "rc" },
 { "vbr", "Variable Bit Rate, use a target bitrate for the entire 
stream", 0, AV_OPT_TYPE_CONST, { .i64 = 1 },  INT_MIN, INT_MAX, VE, "rc" },
 { "cvbr", "Constrained Variable Bit Rate, use a target bitrate for 
each GOP", 0, AV_OPT_TYPE_CONST,{ .i64 = 2 },  INT_MIN, INT_MAX, VE, "rc" },
 
 { "qp", "Quantizer to use with cqp rate control mode", OFFSET(qp),
   AV_OPT_TYPE_INT, { .i64 = 50 }, 0, 63, VE },
 
+{ "crf", "Select the quality for constant quality mode", OFFSET(crf),
+  AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 63, VE },
+
 { "sc_detection", "Scene change detection", OFFSET(scd),
   AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
 
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 4b4fe54..b0a741b 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  59
 #define LIBAVCODEC_VERSION_MINOR   7
-#define LIBAVCODEC_VERSION_MICRO 103
+#define LIBAVCODEC_VERSION_MICRO 104
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
-- 
1.8.3.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/5] avcodec/libsvtav1: Fix redundant setting of caps_internal

2021-09-16 Thread Andreas Rheinhardt

lance.lmw...@gmail.com:
> From: Limin Wang 
> 
> Signed-off-by: Limin Wang 
> ---
>  libavcodec/libsvtav1.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> index fabc4e6..82ae2b9 100644
> --- a/libavcodec/libsvtav1.c
> +++ b/libavcodec/libsvtav1.c
> @@ -561,12 +561,11 @@ const AVCodec ff_libsvtav1_encoder = {
>  .receive_packet = eb_receive_packet,
>  .close  = eb_enc_close,
>  .capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS,
> -.caps_internal  = FF_CODEC_CAP_AUTO_THREADS,
> +.caps_internal  = FF_CODEC_CAP_AUTO_THREADS | FF_CODEC_CAP_INIT_CLEANUP,
>  .pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
>  AV_PIX_FMT_YUV420P10,
>  AV_PIX_FMT_NONE },
>  .priv_class = &class,
>  .defaults   = eb_enc_defaults,
> -.caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
>  .wrapper_name   = "libsvtav1",
>  };
> 
This is not redundant; the second initialization overrides the first. If
I read validate_thread_parameters in pthread.c correctly, this means
that 7d09579190d broke the ability to forward the threading parameters
to the actual encoder. But it never did this anyway, so it doesn't
matter. Should be fixed nevertheless.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] Plans for libavfilter

Since it is not healthy to keep everything for myself, here is a summary
of the projects I have in mind for the enhancement of libavfilter.

The thing is, there are a lot of dependencies between these projects.
Working on them in a proper order would make achieving the goals easier.
On the other hand, if task B depends on task A, then working B without
addressing A involves a little more work for B, but also a lot more work
for A, and a lot more work for everything else that depends on A.

This is one reason I am writing this mail: to make clear what needs to
be done, and how tasks depend on each-other and fit together.

The earliest tasks are not very sexy. They are about making the code
clearer or more robust and generic rather than adding features. It is
always boring. But they are necessary, because parts of the process is
quite shaky, and we cannot afford to build on shaky code.

If you want to help, please consider this and you will be welcome.

Now that is established the specifics:

- Multi-stage negotiation.

  That means negotiating properties that depend on other properties. I
  think the colorspace stuff is in that case, it cannot be negotiated
  until the pixel format is known.

- Media type negotiation.

  That means that filters that do not care about the contents of what
  they are filtering, filters that only act on the frame information
  fields, can also not care if they are filtering audio or video or
  other. There are a lot of these filters: pts manipulation, concat,
  split, selection, etc.

  We cannot afford to have to update every one of them if we want to add
  a new media type, so this is a prerequisite. And it is an aspect of
  multi-stage negotiation, since pixel format or sample format can only
  be negotiated once we know the media type.

- Partial graph configuration.

  Right now, the negotiation happens in steps, first query_formats then
  merge, then pick. But pick can be done on some links as soon as the
  formats are merged to a singleton while other filters are still
  delaying their query_formats, and once pick is done, the graph can
  start running. That would allow filters with constraints more complex
  than what AVFilterFormats can express. (We have a mechanism for that,
  used by amerge and one or two other filters; I introduced it early and
  it was a mistake, it is much too fragile and only converges in the
  simplest cases.)

- Partial graph re-configuration.

  If we can run a graph when not all filters are configured, then we can
  de-configure and re-configure part of a graph. That would bring us the
  support for changes in pixel format.

- Global running API.

  Right now, we make libavfilter activate filters by pumping
  request_frame() on one of the buffersinks, more or less randomly, and
  we hope it will result in something useful. We need a better API, one
  where we say libavfilter "start running these graphs", we push frames
  on input as we have them, we are notified when frames arrive on
  output.

- Inter-filter threading.

  This is a big one, and quite self-explanatory. It goes hand to hand
  with a global running API, because "start running these graphs" also
  means "start as many threads as you need and keep them ready".

  Note that the network protocols in libavformat requires the same
  thing. And I really do not want yet two other frigging threading
  subsystems. This is why I have started slowly working on an unique
  system suited for all needs, starting with both libavformat and
  libavfilter but keeping also libavcodec in mind.

- Out-of-band side-data.

  This is a mechanism to notify filters that the work they are currently
  doing may become irrelevant, or other kinds of urgent information.
  Filters can ignore it, and just do the work for nothing. But smarter
  filters can take it into account and just skip until it becomes
  relevant again.

- Seeking.

  This is when applications notify the outputs they want to jump at a
  specified time, and all the filters in the graph make sure the
  instruction reach the inputs.

  This is probably rather easy and does not depend on many other things.
  Out-of-band side-data is meant for that, among other things: notify a
  filter "you can skip processing the frames you have queued, because we
  are seeking anyway"; and if seeking fails, notify the user as fast as
  possible "we tried seeking, it will not happen".

  A few things need ironing out, though. Do we want to handle it in
  activate() or do we want a separate callback? Do we want a specific
  mechanism for seeking or something more generic for all the messages
  that go backwards in the graph? Do we want a queue for messages that
  go backwards or would a single message be enough?

- Subtitles.

  This one has been under the spotlight recently. What it means is
  rather obvious. But it if far from trivial.

  For starters, it requires the negotiation of media type, because we
  cannot afford to update all the utility filters for

Re: [FFmpeg-devel] Plans for libavfilter

2021-09-16 Thread Paul B Mahol

On Thu, Sep 16, 2021 at 1:55 PM Nicolas George  wrote:

> Since it is not healthy to keep everything for myself, here is a summary
> of the projects I have in mind for the enhancement of libavfilter.
>
> The thing is, there are a lot of dependencies between these projects.
> Working on them in a proper order would make achieving the goals easier.
> On the other hand, if task B depends on task A, then working B without
> addressing A involves a little more work for B, but also a lot more work
> for A, and a lot more work for everything else that depends on A.
>
> This is one reason I am writing this mail: to make clear what needs to
> be done, and how tasks depend on each-other and fit together.
>
> The earliest tasks are not very sexy. They are about making the code
> clearer or more robust and generic rather than adding features. It is
> always boring. But they are necessary, because parts of the process is
> quite shaky, and we cannot afford to build on shaky code.
>
> If you want to help, please consider this and you will be welcome.
>
> Now that is established the specifics:
>
> - Multi-stage negotiation.
>
>   That means negotiating properties that depend on other properties. I
>   think the colorspace stuff is in that case, it cannot be negotiated
>   until the pixel format is known.
>
> - Media type negotiation.
>
>   That means that filters that do not care about the contents of what
>   they are filtering, filters that only act on the frame information
>   fields, can also not care if they are filtering audio or video or
>   other. There are a lot of these filters: pts manipulation, concat,
>   split, selection, etc.
>
>   We cannot afford to have to update every one of them if we want to add
>   a new media type, so this is a prerequisite. And it is an aspect of
>   multi-stage negotiation, since pixel format or sample format can only
>   be negotiated once we know the media type.
>

This is short sighted and irrelevant and also source  of confusion for
users.

I really see no way to tell you to stop insisting on this nonsense. So I
kindly ask you
yet again to stop further work you planned on libavfilter for everyone else
good outcome.



> - Partial graph configuration.
>
>   Right now, the negotiation happens in steps, first query_formats then
>   merge, then pick. But pick can be done on some links as soon as the
>   formats are merged to a singleton while other filters are still
>   delaying their query_formats, and once pick is done, the graph can
>   start running. That would allow filters with constraints more complex
>   than what AVFilterFormats can express. (We have a mechanism for that,
>   used by amerge and one or two other filters; I introduced it early and
>   it was a mistake, it is much too fragile and only converges in the
>   simplest cases.)
>
> - Partial graph re-configuration.
>
>   If we can run a graph when not all filters are configured, then we can
>   de-configure and re-configure part of a graph. That would bring us the
>   support for changes in pixel format.
>
> - Global running API.
>
>   Right now, we make libavfilter activate filters by pumping
>   request_frame() on one of the buffersinks, more or less randomly, and
>   we hope it will result in something useful. We need a better API, one
>   where we say libavfilter "start running these graphs", we push frames
>   on input as we have them, we are notified when frames arrive on
>   output.
>
> - Inter-filter threading.
>
>   This is a big one, and quite self-explanatory. It goes hand to hand
>   with a global running API, because "start running these graphs" also
>   means "start as many threads as you need and keep them ready".
>
>   Note that the network protocols in libavformat requires the same
>   thing. And I really do not want yet two other frigging threading
>   subsystems. This is why I have started slowly working on an unique
>   system suited for all needs, starting with both libavformat and
>   libavfilter but keeping also libavcodec in mind.
>
>
This is the only useful entry so far.


> - Out-of-band side-data.
>
>   This is a mechanism to notify filters that the work they are currently
>   doing may become irrelevant, or other kinds of urgent information.
>   Filters can ignore it, and just do the work for nothing. But smarter
>   filters can take it into account and just skip until it becomes
>   relevant again.
>
> - Seeking.
>
>   This is when applications notify the outputs they want to jump at a
>   specified time, and all the filters in the graph make sure the
>   instruction reach the inputs.
>
>   This is probably rather easy and does not depend on many other things.
>   Out-of-band side-data is meant for that, among other things: notify a
>   filter "you can skip processing the frames you have queued, because we
>   are seeking anyway"; and if seeking fails, notify the user as fast as
>   possible "we tried seeking, it will not happen".
>
>   A few things need ironing out, though. Do we wan

Re: [FFmpeg-devel] [PATCH v2 05/14] avfilter/af_aresample: Use preinit instead of init_dict

Andreas Rheinhardt (12021-09-14):
> By using preinit, the SwrContext already exists directly after
> allocating the filter, so that the filter's AVClass's child_next
> becomes usable for setting options with the AV_OPT_SEARCH_CHILDREN
> search flag. This means that it is no longer necessary to use
> the init_dict callback for this filter.
> 
> Furthermore, the earlier code did not abide by the documentation
> of the init_dict callback at all: Instead of only returning the
> options that have not been recognized it always returned all options
> on any av_opt_set() error and errored out in this case; yet if
> the error was just caused by an unrecognized option, it should not
> error out at all and instead return said option.
> 
> This behaviour has been inherited by avfilter_init_dict(),
> contradicting its documentation. This is also fixed by this commit.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavfilter/af_aresample.c | 27 +++
>  1 file changed, 7 insertions(+), 20 deletions(-)

This looks like a good change. Thanks.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 14/14] avfilter/avfilter: Report all unrecognized options in avfilter_init_str

Andreas Rheinhardt (12021-09-14):
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavfilter/avfilter.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)

Looks ok.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Plans for libavfilter

Paul B Mahol (12021-09-16):
> This is short sighted and irrelevant and also source  of confusion for
> users.
> 
> I really see no way to tell you to stop insisting on this nonsense. So I
> kindly ask you
> yet again to stop further work you planned on libavfilter for everyone else
> good outcome.

If you want to discuss politely why you think this is a bad idea, I am
ready to listen to your arguments and present mine.

Otherwise, I do not care.

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 11/14] avfilter/avfilter: Use AV_DICT_DONT_STRDUP_(KEY|VAL) when possible

Andreas Rheinhardt (12021-09-14):
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavfilter/avfilter.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)

LGTM.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/5] avformat/sbgdec: Check for t0 overflow in expand_tseq()

Michael Niedermayer (12021-09-15):
> Fixes: signed integer overflow: 4611686025627387904 + 4611686025627387904 
> cannot be represented in type 'long'
> Fixes: 
> 35489/clusterfuzz-testcase-minimized-ffmpeg_dem_SBG_fuzzer-4862678601433088
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/sbgdec.c | 3 +++
>  1 file changed, 3 insertions(+)

No objection.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 12/14] avfilter/avfilter: Honour the short options documentation

Andreas Rheinhardt (12021-09-14):
> The documentation for filter arguments states that short options must
> precede long options (i.e. those of the form key=value). Yet if
> process_options() encounters arguments not abiding by this, it simply
> treats short options after a long option as if it were parsing short
> options for the first time. In particular, it overwrites options already
> set earlier, possibly via other short options. This is not how it is
> intended (as a comment in the code indicates).
> 
> This commit modifies the code to reject further shorthand options
> after a long option has been encountered. After all, avfilter_init_str()
> errors out upon unrecognized options, so it is intended to be picky.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavfilter/avfilter.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Since you have a good reason to use a pointer instead of a integer
boolean, then ok.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 13/14] avfilter/avfilter: Don't fail upon options for filter without AVClass

Andreas Rheinhardt (12021-09-14):
> Commit 62549f9655c48f0ec061087fa33a96040ce01145 added a check to
> (the predecessor of) avfilter_init_str() to error out if options
> were provided to a filter without options (or rather, without private
> class). This was fine at the time, yet soon afterwards commit
> fdd93eabfb2644f541f7aac9943abce26776ea73 added a generic option
> for all AVFilterContexts and since then it is wrong to error out
> in case options have been provided to a filter without AVClass.
> 
> To workaround this issue, several filters with timeline support
> added AVClasses and empty options; these will be removed in subsequent
> commits. Furthermore, the super2xsai filter supports slice threading,
> but no options and so has no AVClass, making it impossible to set
> the number of threads when using avfilter_init_str() (and therefore
> from the ffmpeg-tool). This is fixed by this commit, too.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> Now with a comment explaining the two functions of checking for priv.
> 
>  libavfilter/avfilter.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)

Ok, I suppose.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 09/14] avfilter/vf_scale: Honour the AVFilter.init_dict documentation

Andreas Rheinhardt (12021-09-14):
> The documentation states that unrecognized options need to be returned
> (just as av_opt_set_dict() would do). Yet the scale and scale2ref
> filters didn't abide by this: They simply copied all options
> and in case it contained an unrecognized option was among them,
> they would error out later in config_props. This violates the
> documentation of av_filter_init_dict().
> 
> Fix this by only keeping the recognized options and returning
> the unrecognized ones.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavfilter/vf_scale.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> index a1902a13cf..c31b92b847 100644
> --- a/libavfilter/vf_scale.c
> +++ b/libavfilter/vf_scale.c
> @@ -269,6 +269,8 @@ revert:
>  
>  static av_cold int init_dict(AVFilterContext *ctx, AVDictionary **opts)
>  {
> +const AVClass *class = sws_get_class();
> +const AVDictionaryEntry *entry = NULL;
>  ScaleContext *scale = ctx->priv;
>  int ret;
>  
> @@ -312,15 +314,23 @@ static av_cold int init_dict(AVFilterContext *ctx, 
> AVDictionary **opts)
>  scale->flags = 0;
>  
>  if (scale->flags_str && *scale->flags_str) {
> -const AVClass *class = sws_get_class();
>  const AVOption*o = av_opt_find(&class, "sws_flags", NULL, 0,
> AV_OPT_SEARCH_FAKE_OBJ);
>  int ret = av_opt_eval_flags(&class, o, scale->flags_str, 
> &scale->flags);
>  if (ret < 0)
>  return ret;
>  }
> -scale->opts = *opts;
> -*opts = NULL;
> +FFSWAP(AVDictionary *, *opts, scale->opts);
> +/* Now move all the unrecognized options back to opts. */
> +while (entry = av_dict_get(scale->opts, "", entry, 
> AV_DICT_IGNORE_SUFFIX)) {
> +if (!av_opt_find(&class, entry->key, NULL, 0, 
> AV_OPT_SEARCH_FAKE_OBJ)) {
> +if ((ret = av_dict_set(opts, entry->key, entry->value, 0)) < 0 ||
> +(ret = av_dict_set(&scale->opts, entry->key, NULL, 0)) < 0)
> +return ret;
> +/* Removing the entry from scale->opts invalidated entry. */
> +entry = NULL;
> +}
> +}
>  
>  return 0;
>  }

I managed to understand what this code does, but I find it quite
confusing.

First, correct me if I am wrong, but I think the entry parameter to
av_dict_get() is always NULL.

Second, I think if you swap removing the option from scale->opts and
adding it to opts you can avoid strduping the key.

And is entry->value not leaking?

But more importantly, is it not a convoluted implementation that would
be simplified by using preinit like you did for sws?

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 01/14] avfilter/vsrc_testsrc: Deduplicate AVClasses

Andreas Rheinhardt (12021-09-14):
> Signed-off-by: Andreas Rheinhardt 
> ---
> I am not resending all the deduplication patches;
> they can be e.g. found here:
> https://github.com/mkver/FFmpeg/commits/avfilter_deduplication
> 
>  libavfilter/vsrc_testsrc.c | 47 +-
>  1 file changed, 16 insertions(+), 31 deletions(-)

The deduplication patches are ok IMHO.

I do not maintain zscale nor spp but see nothing obviously wrong with
the patch.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] regarding hiding AVStream.first_dts member into AVStreamInternal

2021-09-16 Thread James Almer

Chromium could instead keep track of that timestamp in their own code.
It's what i did to remove the internal fields usage from our CLI tools.
See https://github.com/FFmpeg/FFmpeg/commit/ab4f299e23

On 9/16/2021 8:24 AM, Marek Behún wrote:

Hello James, liberato,

James, your commit 591b88e6787c [1] in FFmpeg hid the first_dts and
cur_dts members of AVStream structure into the internal member, making
them inaccessible from third party code.

The reasoning in the commit message says:
They are private fields, no reason to have them exposed in a public
header.

But the first_dts member is used in Chromium, in
media/filters/ffmpeg_demuxer.cc [2] in method FFmpegDemuxer::InitializeTask.

Chromium solved this by adding av_stream_get_first_dts() method into
their bundled ffmpeg copy [3].

This makes it now impossible to link Chromium with system-ffmpeg, which
was till now a possibility in Gentoo, and which we would like to have
also in the future.

James, what do you think the best approach is here?
Should the FFmpeg commit be reverted to unhide this member?
Or should Chromium be fixed not to use this member? (I confess I did
not study the code much, so I don't know why it is needed, besides that
Chromium tries to compute start_time_ variable with it.)

Thank you.

Marek

[1] https://github.com/FFmpeg/FFmpeg/commit/591b88e6787c

[2]
https://chromium.googlesource.com/chromium/+/refs/heads/trunk/media/filters/ffmpeg_demuxer.cc

[3]
https://chromium.googlesource.com/chromium/third_party/ffmpeg/+/95aab0fd83619408995720ce53d7a74790580220%5E%21/

___
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] avcodec/mmaldec: fix decoder freeze when flushing

2021-09-16 Thread Ho Ming Shun

When mmal_flush is called before any packets are sent,
enabling/disabling the MMAL ports seems to cause the decoder to not
output any packets after flushing.

Bug is triggered when using 'mpv --hwdec=mmal --start=1 test.mp4'.

Proposed workaround in MPV: https://github.com/mpv-player/mpv/pull/9189

Signed-off-by: Ho Ming Shun 
---
 libavcodec/mmaldec.c | 38 +++---
 1 file changed, 23 insertions(+), 15 deletions(-)

diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index 8c7d749742..6c3e5d99b6 100644
--- a/libavcodec/mmaldec.c
+++ b/libavcodec/mmaldec.c
@@ -145,19 +145,21 @@ static int ffmmal_set_ref(AVFrame *frame, FFPoolRef *pool,
 return 0;
 }
 
-static void ffmmal_stop_decoder(AVCodecContext *avctx)
+static void ffmmal_stop_decoder(AVCodecContext *avctx, int flush_ports)
 {
 MMALDecodeContext *ctx = avctx->priv_data;
 MMAL_COMPONENT_T *decoder = ctx->decoder;
 MMAL_BUFFER_HEADER_T *buffer;
 
-mmal_port_disable(decoder->input[0]);
-mmal_port_disable(decoder->output[0]);
-mmal_port_disable(decoder->control);
+if(flush_ports) {
+mmal_port_disable(decoder->input[0]);
+mmal_port_disable(decoder->output[0]);
+mmal_port_disable(decoder->control);
 
-mmal_port_flush(decoder->input[0]);
-mmal_port_flush(decoder->output[0]);
-mmal_port_flush(decoder->control);
+mmal_port_flush(decoder->input[0]);
+mmal_port_flush(decoder->output[0]);
+mmal_port_flush(decoder->control);
+}
 
 while ((buffer = mmal_queue_get(ctx->queue_decoded_frames)))
 mmal_buffer_header_release(buffer);
@@ -185,7 +187,7 @@ static av_cold int ffmmal_close_decoder(AVCodecContext 
*avctx)
 MMALDecodeContext *ctx = avctx->priv_data;
 
 if (ctx->decoder)
-ffmmal_stop_decoder(avctx);
+ffmmal_stop_decoder(avctx, 1);
 
 mmal_component_destroy(ctx->decoder);
 ctx->decoder = NULL;
@@ -456,14 +458,20 @@ static void ffmmal_flush(AVCodecContext *avctx)
 MMAL_COMPONENT_T *decoder = ctx->decoder;
 MMAL_STATUS_T status;
 
-ffmmal_stop_decoder(avctx);
+// MMAL will freeze if ports are enabled/disabled/flushed before
+// buffers are sent
+int flush_ports = ctx->packets_sent || ctx->extradata_sent;
 
-if ((status = mmal_port_enable(decoder->control, control_port_cb)))
-goto fail;
-if ((status = mmal_port_enable(decoder->input[0], input_callback)))
-goto fail;
-if ((status = mmal_port_enable(decoder->output[0], output_callback)))
-goto fail;
+ffmmal_stop_decoder(avctx, flush_ports);
+
+if(flush_ports) {
+if ((status = mmal_port_enable(decoder->control, control_port_cb)))
+goto fail;
+if ((status = mmal_port_enable(decoder->input[0], input_callback)))
+goto fail;
+if ((status = mmal_port_enable(decoder->output[0], output_callback)))
+goto fail;
+}
 
 return;
 
-- 
2.33.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 1/5] avcodec/libsvtav1: Fix redundant setting of caps_internal

On Thu, Sep 16, 2021 at 01:32:00PM +0200, Andreas Rheinhardt wrote:
> lance.lmw...@gmail.com:
> > From: Limin Wang 
> > 
> > Signed-off-by: Limin Wang 
> > ---
> >  libavcodec/libsvtav1.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> > index fabc4e6..82ae2b9 100644
> > --- a/libavcodec/libsvtav1.c
> > +++ b/libavcodec/libsvtav1.c
> > @@ -561,12 +561,11 @@ const AVCodec ff_libsvtav1_encoder = {
> >  .receive_packet = eb_receive_packet,
> >  .close  = eb_enc_close,
> >  .capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS,
> > -.caps_internal  = FF_CODEC_CAP_AUTO_THREADS,
> > +.caps_internal  = FF_CODEC_CAP_AUTO_THREADS | 
> > FF_CODEC_CAP_INIT_CLEANUP,
> >  .pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_YUV420P,
> >  AV_PIX_FMT_YUV420P10,
> >  AV_PIX_FMT_NONE },
> >  .priv_class = &class,
> >  .defaults   = eb_enc_defaults,
> > -.caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
> >  .wrapper_name   = "libsvtav1",
> >  };
> > 
> This is not redundant; the second initialization overrides the first. If
> I read validate_thread_parameters in pthread.c correctly, this means
> that 7d09579190d broke the ability to forward the threading parameters
> to the actual encoder. But it never did this anyway, so it doesn't
> matter. Should be fixed nevertheless.
Yes, It seems that the commit message is misleading, it's the second overrides 
the first.
I'll change it to " Fix override setting of caps_internal".

> 
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

-- 
Thanks,
Limin Wang
___
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] libavfilter/x86/vf_gblur: fixed the fate-test failed on MacOS

2021-09-16 Thread Zhao Zhili




> On Sep 16, 2021, at 3:48 PM, Wu, Jianhua  wrote:
> 
> Jianhua wrote:
>> From: Wu, Jianhua 
>> Sent: Thursday, September 16, 2021 3:34 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Cc: Wu, Jianhua 
>> Subject: [PATCH 1/2] libavfilter/x86/vf_gblur: fixed the fate-test failed on
>> MacOS
>> 
>> Signed-off-by: Wu Jianhua 
>> ---
> 
> Hi Zhili,
> 
> I have submitted the patches fixing the fate-test that failed on macOS. Could
> you help try to apply the patches to check if they work? Here is the link:
> http://ffmpeg.org/pipermail/ffmpeg-devel/2021-September/285376.html
> 
> And the illegal instructions:4 occurred might be the version of your GCC
> installed less than 4.7, which could be fixed by specific a compiler option,
> -mmacosx-version-min=10.x, by the way, the exact I used is 10.10. To enable
> it on FFmpeg, you might have to specify in the --extra-cflags option when
> configuring. But I recommend updating the GCC to the newest version, which
> can fix this as well. 

Thanks, the patch fixed both issues. By the way, the default toolchain
on macOS is clang, gcc has been dropped by Apple long time ago.

> 
> If there is another problem, feel free to let me know.
> 
> Best regards,
> Jianhua
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/apedec: Fix integer overflow in intermediate

On Wed, Sep 15, 2021 at 10:09:49PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: signed integer overflow: 559334865 * 4 cannot be represented in type 
> > 'int'
> > Fixes: 
> > 37929/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-6751932295806976
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/apedec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
> > index bf481ba3549..23318be0613 100644
> > --- a/libavcodec/apedec.c
> > +++ b/libavcodec/apedec.c
> > @@ -1337,7 +1337,7 @@ static void do_apply_filter(APEContext *ctx, int 
> > version, APEFilter *f,
> >  absres = FFABSU(res);
> >  if (absres)
> >  *f->adaptcoeffs = APESIGN(res) *
> > -  (8 << ((absres > f->avg * 3) + (absres > 
> > f->avg * 4 / 3)));
> > +  (8 << ((absres > f->avg * 3) + (absres > 
> > f->avg * 4LL / 3)));
> >  /* equivalent to the following code
> >  if (absres <= f->avg * 4 / 3)
> >  *f->adaptcoeffs = APESIGN(res) * 8;
> > 
> How about using f->avg + f->avg / 3? Given that you haven't modified the
> f->avg * 3 before, this should be save.

will apply this variant

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The day soldiers stop bringing you their problems is the day you have stopped 
leading them. They have either lost confidence that you can help or concluded 
you do not care. Either case is a failure of leadership. - Colin Powell


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/5] avformat/mvdec: Do not set invalid sample rate

On Thu, Sep 16, 2021 at 05:02:53PM +1000, Peter Ross wrote:
> On Wed, Sep 15, 2021 at 10:00:46PM +0200, Michael Niedermayer wrote:
> > Fixes: signed integer overflow: -682581959642593728 * 16 cannot be 
> > represented in type 'long'
> > Fixes: 
> > 37883/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-5311691517198336
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/mvdec.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavformat/mvdec.c b/libavformat/mvdec.c
> > index b1450e08da9..7573087c7cc 100644
> > --- a/libavformat/mvdec.c
> > +++ b/libavformat/mvdec.c
> > @@ -156,9 +156,10 @@ static int parse_audio_var(AVFormatContext *avctx, 
> > AVStream *st,
> >  } else if (!strcmp(name, "NUM_CHANNELS")) {
> >  return set_channels(avctx, st, var_read_int(pb, size));
> >  } else if (!strcmp(name, "SAMPLE_RATE")) {
> > -st->codecpar->sample_rate = var_read_int(pb, size);
> > -if (st->codecpar->sample_rate <= 0)
> > +int sample_rate = var_read_int(pb, size);
> > +if (sample_rate <= 0)
> >  return AVERROR_INVALIDDATA;
> > +st->codecpar->sample_rate = sample_rate;
> >  avpriv_set_pts_info(st, 33, 1, st->codecpar->sample_rate);
> >  } else if (!strcmp(name, "SAMPLE_WIDTH")) {
> >  uint64_t bpc = var_read_int(pb, size) * (uint64_t)8;
> 
> please apply

will do

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/5] avformat/sbgdec: Check for t0 overflow in expand_tseq()

On Thu, Sep 16, 2021 at 02:52:10PM +0200, Nicolas George wrote:
> Michael Niedermayer (12021-09-15):
> > Fixes: signed integer overflow: 4611686025627387904 + 4611686025627387904 
> > cannot be represented in type 'long'
> > Fixes: 
> > 35489/clusterfuzz-testcase-minimized-ffmpeg_dem_SBG_fuzzer-4862678601433088
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/sbgdec.c | 3 +++
> >  1 file changed, 3 insertions(+)
> 
> No objection.

will apply

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v5 00/12] Subtitle Filtering