Re: [FFmpeg-devel] [PATCH 1/4] lavc/vvc_parser: Remove max_b_frames setting
LGTM
On Fri, Apr 19, 2024 at 9:47 PM Jun Zhao wrote:
> From: Jun Zhao
>
> We don't used the max_b_frames field in decoder normally
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/vvc_parser.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavcodec/vvc_parser.c b/libavcodec/vvc_parser.c
> index e3501fa139..a0e10e1a7c 100644
> --- a/libavcodec/vvc_parser.c
> +++ b/libavcodec/vvc_parser.c
> @@ -187,7 +187,6 @@ static void set_parser_ctx(AVCodecParserContext *s,
> AVCodecContext *avctx,
>
> avctx->has_b_frames = (sps->sps_max_sublayers_minus1 + 1) > 2 ? 2 :
> sps->sps_max_sublayers_minus1;
> -avctx->max_b_frames = sps->sps_max_sublayers_minus1;
>
> if (sps->sps_ptl_dpb_hrd_params_present_flag &&
> sps->sps_timing_hrd_params_present_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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] lavc/vvc_parser: Fixed the has_b_frames setting
On Fri, Apr 19, 2024 at 9:55 PM Jun Zhao wrote:
> From: Jun Zhao
>
> has_b_frames used in decoder for size of the frame reordering
> buffer, setting this field from dpb_max_num_reorder_pics.
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/vvc_parser.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vvc_parser.c b/libavcodec/vvc_parser.c
> index a0e10e1a7c..5373875aae 100644
> --- a/libavcodec/vvc_parser.c
> +++ b/libavcodec/vvc_parser.c
> @@ -185,8 +185,8 @@ static void set_parser_ctx(AVCodecParserContext *s,
> AVCodecContext *avctx,
> avctx->color_range =
> sps->vui.vui_full_range_flag ? AVCOL_RANGE_JPEG :
> AVCOL_RANGE_MPEG;
>
> -avctx->has_b_frames = (sps->sps_max_sublayers_minus1 + 1) > 2 ? 2 :
> - sps->sps_max_sublayers_minus1;
> +avctx->has_b_frames =
> +
> sps->sps_dpb_params.dpb_max_num_reorder_pics[sps->sps_max_sublayers_minus1];
>
Should we relocate this to the decoder? Other codecs typically set this
parameter in the decoder.
thank you
>
> if (sps->sps_ptl_dpb_hrd_params_present_flag &&
> sps->sps_timing_hrd_params_present_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 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/4] lavc/vvc/refs: Use dpb_max_num_reorder_pics to control output
Hi Barry and Eliny,
LGTM.
Thank you for the patch.
Is it possible to provide the clip so we can add it to our CI?
ci like https://github.com/ffvvc/FFmpeg/actions
On Fri, Apr 19, 2024 at 9:48 PM Jun Zhao wrote:
> From: Jun Zhao
>
> Use dpb_max_num_reorder_pics to control output instead of
> dpb_max_dec_pic_buffering, when dpb_max_dec_pic_buffering
> is much larger than dpb_max_num_reorder_pics, it may cause
> dpb overflow error.
>
> Signed-off-by: Jun Zhao
> Signed-off-by: elinyhuang
> ---
> libavcodec/vvc/refs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vvc/refs.c b/libavcodec/vvc/refs.c
> index a5ee7338d6..6694bc4c51 100644
> --- a/libavcodec/vvc/refs.c
> +++ b/libavcodec/vvc/refs.c
> @@ -226,7 +226,7 @@ int ff_vvc_output_frame(VVCContext *s, VVCFrameContext
> *fc, AVFrame *out, const
>
> /* wait for more frames before output */
> if (!flush && s->seq_output == s->seq_decode && sps &&
> -nb_output <=
> sps->r->sps_dpb_params.dpb_max_dec_pic_buffering_minus1[sps->r->sps_max_sublayers_minus1]
> + 1)
> +nb_output <=
> sps->r->sps_dpb_params.dpb_max_num_reorder_pics[sps->r->sps_max_sublayers_minus1])
> return 0;
>
> if (nb_output) {
> --
> 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 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] tools: add target_enc_fuzzer.c
On 4/19/2024 10:10 PM, Michael Niedermayer wrote:
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
Makefile | 3 +
tools/Makefile| 3 +
tools/target_enc_fuzzer.c | 213 ++
3 files changed, 219 insertions(+)
create mode 100644 tools/target_enc_fuzzer.c
diff --git a/Makefile b/Makefile
index b309dbc4db9..de727cbe00e 100644
--- a/Makefile
+++ b/Makefile
@@ -52,6 +52,9 @@ $(TOOLS): %$(EXESUF): %.o
target_dec_%_fuzzer$(EXESUF): target_dec_%_fuzzer.o $(FF_DEP_LIBS)
$(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS)
$(LIBFUZZER_PATH)
+target_enc_%_fuzzer$(EXESUF): target_enc_%_fuzzer.o $(FF_DEP_LIBS)
+ $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS)
$(LIBFUZZER_PATH)
+
tools/target_bsf_%_fuzzer$(EXESUF): tools/target_bsf_%_fuzzer.o $(FF_DEP_LIBS)
$(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS)
$(LIBFUZZER_PATH)
diff --git a/tools/Makefile b/tools/Makefile
index 72e8e709a8d..2a11fa0ae62 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -5,6 +5,9 @@ TOOLS-$(CONFIG_ZLIB) += cws2fws
tools/target_dec_%_fuzzer.o: tools/target_dec_fuzzer.c
$(COMPILE_C) -DFFMPEG_DECODER=$*
+tools/target_enc_%_fuzzer.o: tools/target_enc_fuzzer.c
+ $(COMPILE_C) -DFFMPEG_ENCODER=$*
+
tools/target_bsf_%_fuzzer.o: tools/target_bsf_fuzzer.c
$(COMPILE_C) -DFFMPEG_BSF=$*
diff --git a/tools/target_enc_fuzzer.c b/tools/target_enc_fuzzer.c
new file mode 100644
index 000..bc9f98c1443
--- /dev/null
+++ b/tools/target_enc_fuzzer.c
@@ -0,0 +1,213 @@
+/*
+ * Copyright (c) 2024 Michael Niedermayer
+ *
+ * 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
+ *
+ * Based on target_dec_fuzzer
+ */
+
+#include "config.h"
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/cpu.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/mem.h"
+
+#include "libavcodec/avcodec.h"
+#include "libavcodec/bytestream.h"
+#include "libavcodec/codec_internal.h"
+#include "libavformat/avformat.h"
+
+int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size);
+
+extern const FFCodec * codec_list[];
+
+static void error(const char *err)
+{
+fprintf(stderr, "%s", err);
+exit(1);
+}
+
+static const FFCodec *c = NULL;
+static const FFCodec *AVCodecInitialize(enum AVCodecID codec_id)
+{
+const AVCodec *res;
+
+res = avcodec_find_decoder(codec_id);
+if (!res)
+error("Failed to find decoder");
+return ffcodec(res);
+}
+
+// Ensure we don't loop forever
+const uint32_t maxiteration = 8096;
+
+
+static int encode(AVCodecContext *enc_ctx, AVFrame *frame, AVPacket *pkt)
+{
+int ret;
+
+ret = avcodec_send_frame(enc_ctx, frame);
+if (ret < 0)
+return ret;
+
+while (ret >= 0) {
+ret = avcodec_receive_packet(enc_ctx, pkt);
+if (ret == AVERROR(EAGAIN)) {
+return 0;
+} else if (ret < 0) {
+return ret;
+}
+
+av_packet_unref(pkt);
+}
+av_assert0(0);
+}
+
+int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
+uint64_t maxpixels_per_frame = 512 * 512;
+uint64_t maxpixels;
+
+uint64_t maxsamples;
+const uint8_t *end = data + size;
+uint32_t it = 0;
+uint64_t nb_samples = 0;
+AVDictionary *opts = NULL;
+
+if (!c) {
+#ifdef FFMPEG_ENCODER
+#define ENCODER_SYMBOL0(CODEC) ff_##CODEC##_encoder
+#define ENCODER_SYMBOL(CODEC) ENCODER_SYMBOL0(CODEC)
+extern FFCodec ENCODER_SYMBOL(FFMPEG_ENCODER);
+codec_list[0] = _SYMBOL(FFMPEG_ENCODER);
+
+c = _SYMBOL(FFMPEG_ENCODER);
+#else
+c = AVCodecInitialize(FFMPEG_CODEC); // Done once.
+#endif
+av_log_set_level(AV_LOG_PANIC);
+}
+
+av_assert0(c->p.type == AVMEDIA_TYPE_VIDEO);
+
+maxpixels = maxpixels_per_frame * maxiteration;
+
+maxpixels_per_frame = FFMIN(maxpixels_per_frame , maxpixels);
+
+AVCodecContext* ctx = avcodec_alloc_context3(>p);
+if (!ctx)
+error("Failed memory allocation");
+
+if (ctx->max_pixels == 0 || ctx->max_pixels > maxpixels_per_frame)
+ctx->max_pixels = maxpixels_per_frame; //To
[FFmpeg-devel] [PATCH] tools: add target_enc_fuzzer.c
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
Makefile | 3 +
tools/Makefile| 3 +
tools/target_enc_fuzzer.c | 213 ++
3 files changed, 219 insertions(+)
create mode 100644 tools/target_enc_fuzzer.c
diff --git a/Makefile b/Makefile
index b309dbc4db9..de727cbe00e 100644
--- a/Makefile
+++ b/Makefile
@@ -52,6 +52,9 @@ $(TOOLS): %$(EXESUF): %.o
target_dec_%_fuzzer$(EXESUF): target_dec_%_fuzzer.o $(FF_DEP_LIBS)
$(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS)
$(LIBFUZZER_PATH)
+target_enc_%_fuzzer$(EXESUF): target_enc_%_fuzzer.o $(FF_DEP_LIBS)
+ $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS)
$(LIBFUZZER_PATH)
+
tools/target_bsf_%_fuzzer$(EXESUF): tools/target_bsf_%_fuzzer.o $(FF_DEP_LIBS)
$(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $^ $(ELIBS) $(FF_EXTRALIBS)
$(LIBFUZZER_PATH)
diff --git a/tools/Makefile b/tools/Makefile
index 72e8e709a8d..2a11fa0ae62 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -5,6 +5,9 @@ TOOLS-$(CONFIG_ZLIB) += cws2fws
tools/target_dec_%_fuzzer.o: tools/target_dec_fuzzer.c
$(COMPILE_C) -DFFMPEG_DECODER=$*
+tools/target_enc_%_fuzzer.o: tools/target_enc_fuzzer.c
+ $(COMPILE_C) -DFFMPEG_ENCODER=$*
+
tools/target_bsf_%_fuzzer.o: tools/target_bsf_fuzzer.c
$(COMPILE_C) -DFFMPEG_BSF=$*
diff --git a/tools/target_enc_fuzzer.c b/tools/target_enc_fuzzer.c
new file mode 100644
index 000..bc9f98c1443
--- /dev/null
+++ b/tools/target_enc_fuzzer.c
@@ -0,0 +1,213 @@
+/*
+ * Copyright (c) 2024 Michael Niedermayer
+ *
+ * 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
+ *
+ * Based on target_dec_fuzzer
+ */
+
+#include "config.h"
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/cpu.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/mem.h"
+
+#include "libavcodec/avcodec.h"
+#include "libavcodec/bytestream.h"
+#include "libavcodec/codec_internal.h"
+#include "libavformat/avformat.h"
+
+int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size);
+
+extern const FFCodec * codec_list[];
+
+static void error(const char *err)
+{
+fprintf(stderr, "%s", err);
+exit(1);
+}
+
+static const FFCodec *c = NULL;
+static const FFCodec *AVCodecInitialize(enum AVCodecID codec_id)
+{
+const AVCodec *res;
+
+res = avcodec_find_decoder(codec_id);
+if (!res)
+error("Failed to find decoder");
+return ffcodec(res);
+}
+
+// Ensure we don't loop forever
+const uint32_t maxiteration = 8096;
+
+
+static int encode(AVCodecContext *enc_ctx, AVFrame *frame, AVPacket *pkt)
+{
+int ret;
+
+ret = avcodec_send_frame(enc_ctx, frame);
+if (ret < 0)
+return ret;
+
+while (ret >= 0) {
+ret = avcodec_receive_packet(enc_ctx, pkt);
+if (ret == AVERROR(EAGAIN)) {
+return 0;
+} else if (ret < 0) {
+return ret;
+}
+
+av_packet_unref(pkt);
+}
+av_assert0(0);
+}
+
+int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
+uint64_t maxpixels_per_frame = 512 * 512;
+uint64_t maxpixels;
+
+uint64_t maxsamples;
+const uint8_t *end = data + size;
+uint32_t it = 0;
+uint64_t nb_samples = 0;
+AVDictionary *opts = NULL;
+
+if (!c) {
+#ifdef FFMPEG_ENCODER
+#define ENCODER_SYMBOL0(CODEC) ff_##CODEC##_encoder
+#define ENCODER_SYMBOL(CODEC) ENCODER_SYMBOL0(CODEC)
+extern FFCodec ENCODER_SYMBOL(FFMPEG_ENCODER);
+codec_list[0] = _SYMBOL(FFMPEG_ENCODER);
+
+c = _SYMBOL(FFMPEG_ENCODER);
+#else
+c = AVCodecInitialize(FFMPEG_CODEC); // Done once.
+#endif
+av_log_set_level(AV_LOG_PANIC);
+}
+
+av_assert0(c->p.type == AVMEDIA_TYPE_VIDEO);
+
+maxpixels = maxpixels_per_frame * maxiteration;
+
+maxpixels_per_frame = FFMIN(maxpixels_per_frame , maxpixels);
+
+AVCodecContext* ctx = avcodec_alloc_context3(>p);
+if (!ctx)
+error("Failed memory allocation");
+
+if (ctx->max_pixels == 0 || ctx->max_pixels > maxpixels_per_frame)
+ctx->max_pixels = maxpixels_per_frame; //To reduce false positive OOM
and hangs
+
+ctx->pix_fmt =
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Sat, Apr 20, 2024 at 12:31 AM James Almer wrote: > On 4/19/2024 7:28 PM, Paul B Mahol wrote: > > On Fri, Apr 19, 2024 at 11:58 PM Vittorio Giovara < > > vittorio.giov...@gmail.com> wrote: > > > >> On Fri, Apr 19, 2024 at 12:48 PM Ronald S. Bultje > >> wrote: > >> > >>> Hi, > >>> > >>> On Fri, Apr 19, 2024 at 2:06 PM Vittorio Giovara < > >>> vittorio.giov...@gmail.com> > >>> wrote: > >>> > On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster < > dcni...@gmail.com> > wrote: > > > If i recall correctly, there was a conversation not too long ago > >> about > what > > to do with all the SPI money. This seems to be a perfect use for it. > > 1. Set up and manage a gitlab instance > > 2. Move tickets from trac to there (possibly) > > 3. Move fate running to there > > > > +1 > > Another good idea would be to show negative influences the door, and > >> not > being afraid to ban them when needed. > Currently the CC is supposed to decide that but idk how many and which > people have access to the mailing list control panel. > > >>> > >>> The CC does not have authority to permanently ban people. See ( > >>> https://ffmpeg.org/community.html#Community-Committee-1): "The CC can > >>> remove privileges of offending members, including [..] temporary ban > from > >>> the community. [..] Indefinite bans from the community must be > confirmed > >> by > >>> the General Assembly, in a majority vote." > >>> > >>> Enough of us have access to the ML admin interface to assume this will > >> not > >>> be an issue. > >>> > >> > >> Thanks for the clarification, it's good to know. So correct me if I'm > >> wrong, the theoretical banning process is that a repeated offender is > >> reported enough times, the CC notices that the temporary bans have had > no > >> effects and decides to invoke the GA to confirm a ban? > >> > > > > By that time, if not already, GA will be majority of active bots or > > majority of active controlled figures. > > What bots? That makes no sense. > Current situation in FFmpeg makes no sense. Could someone explain current FFmpeg situation? > > > > > So in that hypothetical case, (I hope it does not happen), 0 transparency > > and 0 innovations, > > with questionable commits and contributors will remain in project, if not > > already happening. > > > > Its 2024 year, and FFmpeg still does not have proper subtitle support. > > I could continue writing and adding more to the list, but I'm very > generous > > today. > > > > > >> -- > >> Vittorio > >> ___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > >> To unsubscribe, visit link above, or email > >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > >> > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
Hi, On Fri, Apr 19, 2024 at 5:58 PM Vittorio Giovara wrote: > On Fri, Apr 19, 2024 at 12:48 PM Ronald S. Bultje > wrote: > > > Hi, > > > > On Fri, Apr 19, 2024 at 2:06 PM Vittorio Giovara < > > vittorio.giov...@gmail.com> > > wrote: > > > > > On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster < > > > dcni...@gmail.com> > > > wrote: > > > > > > > If i recall correctly, there was a conversation not too long ago > about > > > what > > > > to do with all the SPI money. This seems to be a perfect use for it. > > > > 1. Set up and manage a gitlab instance > > > > 2. Move tickets from trac to there (possibly) > > > > 3. Move fate running to there > > > > > > > > > > +1 > > > > > > Another good idea would be to show negative influences the door, and > not > > > being afraid to ban them when needed. > > > Currently the CC is supposed to decide that but idk how many and which > > > people have access to the mailing list control panel. > > > > > > > The CC does not have authority to permanently ban people. See ( > > https://ffmpeg.org/community.html#Community-Committee-1): "The CC can > > remove privileges of offending members, including [..] temporary ban from > > the community. [..] Indefinite bans from the community must be confirmed > by > > the General Assembly, in a majority vote." > > > > Enough of us have access to the ML admin interface to assume this will > not > > be an issue. > > > > Thanks for the clarification, it's good to know. So correct me if I'm > wrong, the theoretical banning process is that a repeated offender is > reported enough times, the CC notices that the temporary bans have had no > effects and decides to invoke the GA to confirm a ban? > Yes. But anyone else, even you, could start a GA permaban vote also. (I'm not suggesting you do this, I'm just saying it so it's clear that it doesn't have to be initiated by a CC member.) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On 4/19/2024 7:28 PM, Paul B Mahol wrote: On Fri, Apr 19, 2024 at 11:58 PM Vittorio Giovara < vittorio.giov...@gmail.com> wrote: On Fri, Apr 19, 2024 at 12:48 PM Ronald S. Bultje wrote: Hi, On Fri, Apr 19, 2024 at 2:06 PM Vittorio Giovara < vittorio.giov...@gmail.com> wrote: On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster < dcni...@gmail.com> wrote: If i recall correctly, there was a conversation not too long ago about what to do with all the SPI money. This seems to be a perfect use for it. 1. Set up and manage a gitlab instance 2. Move tickets from trac to there (possibly) 3. Move fate running to there +1 Another good idea would be to show negative influences the door, and not being afraid to ban them when needed. Currently the CC is supposed to decide that but idk how many and which people have access to the mailing list control panel. The CC does not have authority to permanently ban people. See ( https://ffmpeg.org/community.html#Community-Committee-1): "The CC can remove privileges of offending members, including [..] temporary ban from the community. [..] Indefinite bans from the community must be confirmed by the General Assembly, in a majority vote." Enough of us have access to the ML admin interface to assume this will not be an issue. Thanks for the clarification, it's good to know. So correct me if I'm wrong, the theoretical banning process is that a repeated offender is reported enough times, the CC notices that the temporary bans have had no effects and decides to invoke the GA to confirm a ban? By that time, if not already, GA will be majority of active bots or majority of active controlled figures. What bots? That makes no sense. So in that hypothetical case, (I hope it does not happen), 0 transparency and 0 innovations, with questionable commits and contributors will remain in project, if not already happening. Its 2024 year, and FFmpeg still does not have proper subtitle support. I could continue writing and adding more to the list, but I'm very generous today. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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] [RFC] 5 year plan & Inovation
On Fri, Apr 19, 2024 at 11:58 PM Vittorio Giovara < vittorio.giov...@gmail.com> wrote: > On Fri, Apr 19, 2024 at 12:48 PM Ronald S. Bultje > wrote: > > > Hi, > > > > On Fri, Apr 19, 2024 at 2:06 PM Vittorio Giovara < > > vittorio.giov...@gmail.com> > > wrote: > > > > > On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster < > > > dcni...@gmail.com> > > > wrote: > > > > > > > If i recall correctly, there was a conversation not too long ago > about > > > what > > > > to do with all the SPI money. This seems to be a perfect use for it. > > > > 1. Set up and manage a gitlab instance > > > > 2. Move tickets from trac to there (possibly) > > > > 3. Move fate running to there > > > > > > > > > > +1 > > > > > > Another good idea would be to show negative influences the door, and > not > > > being afraid to ban them when needed. > > > Currently the CC is supposed to decide that but idk how many and which > > > people have access to the mailing list control panel. > > > > > > > The CC does not have authority to permanently ban people. See ( > > https://ffmpeg.org/community.html#Community-Committee-1): "The CC can > > remove privileges of offending members, including [..] temporary ban from > > the community. [..] Indefinite bans from the community must be confirmed > by > > the General Assembly, in a majority vote." > > > > Enough of us have access to the ML admin interface to assume this will > not > > be an issue. > > > > Thanks for the clarification, it's good to know. So correct me if I'm > wrong, the theoretical banning process is that a repeated offender is > reported enough times, the CC notices that the temporary bans have had no > effects and decides to invoke the GA to confirm a ban? > By that time, if not already, GA will be majority of active bots or majority of active controlled figures. So in that hypothetical case, (I hope it does not happen), 0 transparency and 0 innovations, with questionable commits and contributors will remain in project, if not already happening. Its 2024 year, and FFmpeg still does not have proper subtitle support. I could continue writing and adding more to the list, but I'm very generous today. > -- > Vittorio > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Fri, Apr 19, 2024 at 12:48 PM Ronald S. Bultje wrote: > Hi, > > On Fri, Apr 19, 2024 at 2:06 PM Vittorio Giovara < > vittorio.giov...@gmail.com> > wrote: > > > On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster < > > dcni...@gmail.com> > > wrote: > > > > > If i recall correctly, there was a conversation not too long ago about > > what > > > to do with all the SPI money. This seems to be a perfect use for it. > > > 1. Set up and manage a gitlab instance > > > 2. Move tickets from trac to there (possibly) > > > 3. Move fate running to there > > > > > > > +1 > > > > Another good idea would be to show negative influences the door, and not > > being afraid to ban them when needed. > > Currently the CC is supposed to decide that but idk how many and which > > people have access to the mailing list control panel. > > > > The CC does not have authority to permanently ban people. See ( > https://ffmpeg.org/community.html#Community-Committee-1): "The CC can > remove privileges of offending members, including [..] temporary ban from > the community. [..] Indefinite bans from the community must be confirmed by > the General Assembly, in a majority vote." > > Enough of us have access to the ML admin interface to assume this will not > be an issue. > Thanks for the clarification, it's good to know. So correct me if I'm wrong, the theoretical banning process is that a repeated offender is reported enough times, the CC notices that the temporary bans have had no effects and decides to invoke the GA to confirm a ban? -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Fri, Apr 19, 2024 at 9:45 PM James Almer wrote: > On 4/19/2024 4:05 PM, Paul B Mahol wrote: > > On Fri, Apr 19, 2024 at 8:06 PM Vittorio Giovara < > vittorio.giov...@gmail.com> > > wrote: > > > >> On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster < > >> dcni...@gmail.com> > >> wrote: > >> > >>> If i recall correctly, there was a conversation not too long ago about > >> what > >>> to do with all the SPI money. This seems to be a perfect use for it. > >>> 1. Set up and manage a gitlab instance > >>> 2. Move tickets from trac to there (possibly) > >>> 3. Move fate running to there > >>> > >> > >> +1 > >> > >> Another good idea would be to show negative influences the door, and not > >> being afraid to ban them when needed. > >> Currently the CC is supposed to decide that but idk how many and which > >> people have access to the mailing list control panel. > >> > > > > Welcome to the New LibAV Order! > > Paul, please, can you stop with this? > I stand for Truth And Justice. You all stand for Force And Power. > ___ > 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] [RFC] 5 year plan & Inovation
Hi, On Fri, Apr 19, 2024 at 2:06 PM Vittorio Giovara wrote: > On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster < > dcni...@gmail.com> > wrote: > > > If i recall correctly, there was a conversation not too long ago about > what > > to do with all the SPI money. This seems to be a perfect use for it. > > 1. Set up and manage a gitlab instance > > 2. Move tickets from trac to there (possibly) > > 3. Move fate running to there > > > > +1 > > Another good idea would be to show negative influences the door, and not > being afraid to ban them when needed. > Currently the CC is supposed to decide that but idk how many and which > people have access to the mailing list control panel. > The CC does not have authority to permanently ban people. See ( https://ffmpeg.org/community.html#Community-Committee-1): "The CC can remove privileges of offending members, including [..] temporary ban from the community. [..] Indefinite bans from the community must be confirmed by the General Assembly, in a majority vote." Enough of us have access to the ML admin interface to assume this will not be an issue. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 3/3] avformat/avformat: Document return codes for av_format_(de)init
--- libavformat/avformat.h | 4 1 file changed, 4 insertions(+) diff --git a/libavformat/avformat.h b/libavformat/avformat.h index 8afdcd9fd0..f624fb1e2e 100644 --- a/libavformat/avformat.h +++ b/libavformat/avformat.h @@ -1944,12 +1944,16 @@ const char *avformat_license(void); * This function will be deprecated once support for older GnuTLS and * OpenSSL libraries is removed, and this function has no purpose * anymore. + * + * @return 0 for success or AVERROR code */ int avformat_network_init(void); /** * Undo the initialization done by avformat_network_init. Call it only * once for each time you called avformat_network_init. + * + * @return 0 for success or AVERROR code */ int avformat_network_deinit(void); -- 2.43.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 2/3] avformat/network: Return 0/AVERROR from ff_network_init()
---
libavformat/avio.c| 4 ++--
libavformat/network.c | 7 +++
libavformat/rtsp.c| 12 ++--
libavformat/rtspdec.c | 4 ++--
libavformat/sapdec.c | 4 ++--
libavformat/sapenc.c | 4 ++--
6 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/libavformat/avio.c b/libavformat/avio.c
index d109f3adff..f82edec779 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -123,8 +123,8 @@ static int url_alloc_for_protocol(URLContext **puc, const
URLProtocol *up,
int err;
#if CONFIG_NETWORK
-if (up->flags & URL_PROTOCOL_FLAG_NETWORK && !ff_network_init())
-return AVERROR(EIO);
+if (up->flags & URL_PROTOCOL_FLAG_NETWORK && (err=ff_network_init())<0)
+return err;
#endif
if ((flags & AVIO_FLAG_READ) && !up->url_read) {
av_log(NULL, AV_LOG_ERROR,
diff --git a/libavformat/network.c b/libavformat/network.c
index fb70f9cafc..134869a63f 100644
--- a/libavformat/network.c
+++ b/libavformat/network.c
@@ -59,11 +59,10 @@ int ff_network_init(void)
{
#if HAVE_WINSOCK2_H
WSADATA wsaData;
-
-if (WSAStartup(MAKEWORD(1,1), ))
-return 0;
+return ff_neterrno2(WSAStartup(MAKEWORD(1,1), ));
+#else
+return 0;
#endif
-return 1;
}
int ff_network_wait_fd(int fd, int write)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index b0c61ee00a..3db4ed11c2 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1740,8 +1740,8 @@ int ff_rtsp_connect(AVFormatContext *s)
return AVERROR(EINVAL);
}
-if (!ff_network_init())
-return AVERROR(EIO);
+if ((err = ff_network_init())<0)
+return err;
if (s->max_delay < 0) /* Not set by the caller */
s->max_delay = s->iformat ? DEFAULT_REORDERING_DELAY : 0;
@@ -2395,8 +2395,8 @@ static int sdp_read_header(AVFormatContext *s)
char url[MAX_URL_SIZE];
AVBPrint bp;
-if (!ff_network_init())
-return AVERROR(EIO);
+if ((err = ff_network_init())<0)
+return err;
if (s->max_delay < 0) /* Not set by the caller */
s->max_delay = DEFAULT_REORDERING_DELAY;
@@ -2522,8 +2522,8 @@ static int rtp_read_header(AVFormatContext *s)
AVBPrint sdp;
AVDictionary *opts = NULL;
-if (!ff_network_init())
-return AVERROR(EIO);
+if ((ret = ff_network_init())<0)
+return ret;
opts = map_to_opts(rt);
ret = ffurl_open_whitelist(, s->url, AVIO_FLAG_READ,
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index 10078ce2fa..3b0829694e 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -663,8 +663,8 @@ static int rtsp_listen(AVFormatContext *s)
int ret;
enum RTSPMethod methodcode;
-if (!ff_network_init())
-return AVERROR(EIO);
+if ((ret = ff_network_init())<0)
+return ret;
/* extract hostname and port */
av_url_split(proto, sizeof(proto), auth, sizeof(auth), host, sizeof(host),
diff --git a/libavformat/sapdec.c b/libavformat/sapdec.c
index 357c0dd514..719c26c6b8 100644
--- a/libavformat/sapdec.c
+++ b/libavformat/sapdec.c
@@ -70,8 +70,8 @@ static int sap_read_header(AVFormatContext *s)
int port;
int ret, i;
-if (!ff_network_init())
-return AVERROR(EIO);
+if ((ret = ff_network_init())<0)
+return ret;
av_url_split(NULL, 0, NULL, 0, host, sizeof(host), ,
path, sizeof(path), s->url);
diff --git a/libavformat/sapenc.c b/libavformat/sapenc.c
index 87a834a8d8..3305122524 100644
--- a/libavformat/sapenc.c
+++ b/libavformat/sapenc.c
@@ -80,8 +80,8 @@ static int sap_write_header(AVFormatContext *s)
int udp_fd;
AVDictionaryEntry* title = av_dict_get(s->metadata, "title", NULL, 0);
-if (!ff_network_init())
-return AVERROR(EIO);
+if ((ret = ff_network_init())<0)
+return ret;
/* extract hostname and port */
av_url_split(NULL, 0, NULL, 0, host, sizeof(host), _port,
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 1/3] avformat/network: add ff_neterrno2() for cases where we already have an errno
For example, WSAStartup()'s documentation says:
"A call to the WSAGetLastError function is not needed and should not be
used"
---
libavformat/network.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavformat/network.c b/libavformat/network.c
index f752efc411..fb70f9cafc 100644
--- a/libavformat/network.c
+++ b/libavformat/network.c
@@ -121,9 +121,14 @@ void ff_network_close(void)
}
#if HAVE_WINSOCK2_H
+
+}
int ff_neterrno(void)
{
-int err = WSAGetLastError();
+return ff_neterrno2(WSAGetLastError());
+}
+int ff_neterrno2(int err)
+{
switch (err) {
case WSAEWOULDBLOCK:
return AVERROR(EAGAIN);
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Fri, Apr 19, 2024 at 8:06 PM Vittorio Giovara wrote: > On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster < > dcni...@gmail.com> > wrote: > > > If i recall correctly, there was a conversation not too long ago about > what > > to do with all the SPI money. This seems to be a perfect use for it. > > 1. Set up and manage a gitlab instance > > 2. Move tickets from trac to there (possibly) > > 3. Move fate running to there > > > > +1 > > Another good idea would be to show negative influences the door, and not > being afraid to ban them when needed. > Currently the CC is supposed to decide that but idk how many and which > people have access to the mailing list control panel. > Welcome to the New LibAV Order! -- > Vittorio > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster wrote: > If i recall correctly, there was a conversation not too long ago about what > to do with all the SPI money. This seems to be a perfect use for it. > 1. Set up and manage a gitlab instance > 2. Move tickets from trac to there (possibly) > 3. Move fate running to there > +1 Another good idea would be to show negative influences the door, and not being afraid to ban them when needed. Currently the CC is supposed to decide that but idk how many and which people have access to the mailing list control panel. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Fri, Apr 19, 2024, 19:35 Zhao Zhili wrote: > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > Niklas Haas > > Sent: 2024年4月19日 22:50 > > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation > > > > On Thu, 18 Apr 2024 22:53:51 +0200 Michael Niedermayer < > mich...@niedermayer.cc> wrote: > > > A plugin system moves this patch-management to people who actually > > > care, that is the authors of the codecs and (de)muxers. > > > > A plugin system will only solve this insomuch as plugin authors will > > just host their plugin code on GitHub instead of bothering with the > > mailing list. > > > > I think it runs a good risk of basically killing the project. > > VLC is plugin based, gstreamer is plugin based too (which went t far > ), > I don't think plugin is that dangerous. > > Firstly, we can enable plugin interface only with enable-gpl. > > Secondly, we can have a less stable plugin interface than public API, for > our > development convenience, and encourage plugin authors to contribute to > upstream. > > > > > > Our productivity as is, is not good, many patches are ignored. > > > The people caring about these patches are their Authors and yet they > > > are powerless as they must sometimes wait many months for reviews > > > > So, rather than all of the above, what I think we should do is contract > > somebody to set up, manage, host and maintain a GitLab instance for us. > > > > This would probably be the single most cost effective boost to both > > community growth and innovation I can think of, as it will remove > > several of the major grievances and barriers to entry with the > > ML+pingspam model. > > +1. > > I can't remember how many patches I have ping. It's really frustration. > I ask for permission to commit mostly due to this. > > Now I can keep track of my own patches, but it's still not easy to filter > out > patches I'm interested to review (I can blame the email client, but blame > it > doesn't help). I'm sure I can review more patches with a new workflow. > If i recall correctly, there was a conversation not too long ago about what to do with all the SPI money. This seems to be a perfect use for it. 1. Set up and manage a gitlab instance 2. Move tickets from trac to there (possibly) 3. Move fate running to there Etc > ___ 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/2] avformat/network: Return a proper negative error code from ff_network_init()
On 4/19/2024 2:23 PM, Andrew Sayers wrote: --- libavformat/network.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/network.c b/libavformat/network.c index f752efc411..d518bb0541 100644 --- a/libavformat/network.c +++ b/libavformat/network.c @@ -63,7 +63,7 @@ int ff_network_init(void) if (WSAStartup(MAKEWORD(1,1), )) return 0; #endif -return 1; +return -1; This will make avformat_network_init() fail on all targets but Windows. Also, there are a lot of ff_network_init() callers that check for 0 as failure and anything else as success. What needs to be done is to make ff_network_init() return ff_neterrno() on WSAStartup() failure and 0 on success on Windows, and 0 for every other target (where there's no chance of failure), and the callers be adapted to check for < 0 and propagate the returned error value if so. } int ff_network_wait_fd(int fd, int write) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
> -Original Message- > From: ffmpeg-devel On Behalf Of Niklas Haas > Sent: 2024年4月19日 22:50 > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation > > On Thu, 18 Apr 2024 22:53:51 +0200 Michael Niedermayer > wrote: > > A plugin system moves this patch-management to people who actually > > care, that is the authors of the codecs and (de)muxers. > > A plugin system will only solve this insomuch as plugin authors will > just host their plugin code on GitHub instead of bothering with the > mailing list. > > I think it runs a good risk of basically killing the project. VLC is plugin based, gstreamer is plugin based too (which went t far ), I don't think plugin is that dangerous. Firstly, we can enable plugin interface only with enable-gpl. Secondly, we can have a less stable plugin interface than public API, for our development convenience, and encourage plugin authors to contribute to upstream. > > > Our productivity as is, is not good, many patches are ignored. > > The people caring about these patches are their Authors and yet they > > are powerless as they must sometimes wait many months for reviews > > So, rather than all of the above, what I think we should do is contract > somebody to set up, manage, host and maintain a GitLab instance for us. > > This would probably be the single most cost effective boost to both > community growth and innovation I can think of, as it will remove > several of the major grievances and barriers to entry with the > ML+pingspam model. +1. I can't remember how many patches I have ping. It's really frustration. I ask for permission to commit mostly due to this. Now I can keep track of my own patches, but it's still not easy to filter out patches I'm interested to review (I can blame the email client, but blame it doesn't help). I'm sure I can review more patches with a new workflow. > > We can use a system like VLC's auto-merge bot, where any MR that has at > least one developer approval, no unresolved issues, and no activity for > N days gets *automatically* merged. > > I'm sure that if we try, we can find an interested party willing to fund > this. (Maybe SPI?) > > > Besides that, developers are leaving for various reasons and they > > are forced to setup full forks not being able to maintain their > > code in any other way. > > IMO A plugin system would improve productivity as everyone could work > > on their own terms. > > No week or month long delays and weekly pinging patches > > No risk about patches being rejected or ignored > > No need to read every other discussion on the ML. One can just > > simply work on their own plugin looking just at the API documentation > > ... > > > > > > > > > > > > > * ffchat > > > > (expand into realtime chat / zoom) this would > > > > bring in more users and developers, and we basically have almost > > > > all parts for it already but some people where against it > > > > > > This seems like a user application on top of FFmpeg, not something that > > > should be part of FFmpeg core. Can you explain what modifications in > > > FFmpeg would be necessary for something like this? > > > > ffmpeg, ffplay, ffprobe are also user applications. > > > > > > > > > > > * client side / in browser support > > > > (expand towards webapps, webpages using ffmpeg client side in the > > > > browser) > > > > bring in more users and developers, and it will be costly for us > > > > if we let others take this area as its important and significant > > > > > > I don't understand this point - don't all major browsers already vendor > > > FFmpeg for decoding? > > > > FFmpeg does more than decoding. > > > > > > > > > > > * AI / neural network filters and codecs > > > > The future seems to be AI based. Future Filters and Codecs will use > > > > neural networks. FFmpeg can be at the forefront, developing these > > > > > > We already have TensorFlow support, no? (vf_sr etc.) What more is > > > needed? > > > > more of that AND more convenience > > > > lets pick a comparission > > to run fate > > you write "make fate" > > if you want to do it with the samples its > > make fate-rsync ; make fate > > > > if you want to use vf_sr, its reading the docs, looking at some scripts > > reading their docs > > and i presume selecting a training set ? creating a model ? > > > > how many people do that ? > > > > thx > > > > [...] > > > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > I have often repented speaking, but never of holding my tongue. > > -- Xenocrates > > ___ > > 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] [PATCH v2 2/2] avformat/avformat: Document return codes for av_format_(de)init
--- libavformat/avformat.h | 4 1 file changed, 4 insertions(+) diff --git a/libavformat/avformat.h b/libavformat/avformat.h index 8afdcd9fd0..ea816a0b22 100644 --- a/libavformat/avformat.h +++ b/libavformat/avformat.h @@ -1944,12 +1944,16 @@ const char *avformat_license(void); * This function will be deprecated once support for older GnuTLS and * OpenSSL libraries is removed, and this function has no purpose * anymore. + * + * @return 0 on success, <0 on error. */ int avformat_network_init(void); /** * Undo the initialization done by avformat_network_init. Call it only * once for each time you called avformat_network_init. + * + * @return 0 on success, <0 on error. */ int avformat_network_deinit(void); -- 2.43.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/2] avformat/network: Return a proper negative error code from ff_network_init()
--- libavformat/network.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/network.c b/libavformat/network.c index f752efc411..d518bb0541 100644 --- a/libavformat/network.c +++ b/libavformat/network.c @@ -63,7 +63,7 @@ int ff_network_init(void) if (WSAStartup(MAKEWORD(1,1), )) return 0; #endif -return 1; +return -1; } int ff_network_wait_fd(int fd, int write) -- 2.43.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avformat/utils: handle errors > 0 in avformat_network_init()
On 4/19/2024 1:59 PM, Andrew Sayers wrote:
---
libavformat/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 4dded7aea4..855723a406 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -560,7 +560,7 @@ int avformat_network_init(void)
{
#if CONFIG_NETWORK
int ret;
-if ((ret = ff_network_init()) < 0)
+if ((ret = ff_network_init()))
ff_network_init() needs to be fixed to return negative error values
instead. This change will make it return 1 on error on Windows.
return ret;
if ((ret = ff_tls_init()) < 0)
return ret;
___
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] avformat/avformat: Document return codes for av_format_(de)init
--- libavformat/avformat.h | 4 1 file changed, 4 insertions(+) diff --git a/libavformat/avformat.h b/libavformat/avformat.h index 8afdcd9fd0..0feaeded0e 100644 --- a/libavformat/avformat.h +++ b/libavformat/avformat.h @@ -1944,12 +1944,16 @@ const char *avformat_license(void); * This function will be deprecated once support for older GnuTLS and * OpenSSL libraries is removed, and this function has no purpose * anymore. + * + * @return 0 on success, !=0 on error. */ int avformat_network_init(void); /** * Undo the initialization done by avformat_network_init. Call it only * once for each time you called avformat_network_init. + * + * @return 0 on success, !=0 on error. */ int avformat_network_deinit(void); -- 2.43.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avformat/utils: handle errors > 0 in avformat_network_init()
---
libavformat/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 4dded7aea4..855723a406 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -560,7 +560,7 @@ int avformat_network_init(void)
{
#if CONFIG_NETWORK
int ret;
-if ((ret = ff_network_init()) < 0)
+if ((ret = ff_network_init()))
return ret;
if ((ret = ff_tls_init()) < 0)
return ret;
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/5] avcodec/vaapi_av1: Use ProgressFrames
The rationale here is exactly the same as for using them for AV1:
It avoids av_frame_ref() when putting the same frame into
multiple reference slots. (In case av_frame_ref() failed,
the context would be left in an inconsistent state that
claimed that an AVFrame was valid (i.e. not blank), when
in fact it was not valid.)
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vaapi_av1.c | 61 +++---
1 file changed, 15 insertions(+), 46 deletions(-)
diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
index 1f563483b9..20651a0ac2 100644
--- a/libavcodec/vaapi_av1.c
+++ b/libavcodec/vaapi_av1.c
@@ -18,17 +18,11 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
-#include "libavutil/frame.h"
#include "hwaccel_internal.h"
#include "vaapi_decode.h"
#include "internal.h"
#include "av1dec.h"
-#include "thread.h"
-
-typedef struct VAAPIAV1FrameRef {
-AVFrame *frame;
-int valid;
-} VAAPIAV1FrameRef;
+#include "progressframe.h"
typedef struct VAAPIAV1DecContext {
VAAPIDecodeContext base;
@@ -40,8 +34,8 @@ typedef struct VAAPIAV1DecContext {
* applying film grain here. And current_display_picture will be
* used to apply film grain and push to downstream.
*/
-VAAPIAV1FrameRef ref_tab[AV1_NUM_REF_FRAMES];
-AVFrame *tmp_frame;
+ProgressFrame ref_tab[AV1_NUM_REF_FRAMES];
+ProgressFrame tmp_frame;
} VAAPIAV1DecContext;
static VASurfaceID vaapi_av1_surface_id(AV1Frame *vf)
@@ -70,32 +64,14 @@ static int8_t vaapi_av1_get_bit_depth_idx(AVCodecContext
*avctx)
return bit_depth == 8 ? 0 : bit_depth == 10 ? 1 : 2;
}
-static int vaapi_av1_decode_init(AVCodecContext *avctx)
-{
-VAAPIAV1DecContext *ctx = avctx->internal->hwaccel_priv_data;
-
-ctx->tmp_frame = av_frame_alloc();
-if (!ctx->tmp_frame)
-return AVERROR(ENOMEM);
-
-for (int i = 0; i < FF_ARRAY_ELEMS(ctx->ref_tab); i++) {
-ctx->ref_tab[i].frame = av_frame_alloc();
-if (!ctx->ref_tab[i].frame)
-return AVERROR(ENOMEM);
-ctx->ref_tab[i].valid = 0;
-}
-
-return ff_vaapi_decode_init(avctx);
-}
-
static int vaapi_av1_decode_uninit(AVCodecContext *avctx)
{
VAAPIAV1DecContext *ctx = avctx->internal->hwaccel_priv_data;
-av_frame_free(>tmp_frame);
+ff_progress_frame_unref(>tmp_frame);
for (int i = 0; i < FF_ARRAY_ELEMS(ctx->ref_tab); i++)
-av_frame_free(>ref_tab[i].frame);
+ff_progress_frame_unref(>ref_tab[i]);
return ff_vaapi_decode_uninit(avctx);
}
@@ -125,12 +101,12 @@ static int vaapi_av1_start_frame(AVCodecContext *avctx,
goto fail;
if (apply_grain) {
-if (ctx->tmp_frame->buf[0])
-av_frame_unref(ctx->tmp_frame);
-err = ff_thread_get_buffer(avctx, ctx->tmp_frame,
AV_GET_BUFFER_FLAG_REF);
+ff_progress_frame_unref(>tmp_frame);
+err = ff_progress_frame_get_buffer(avctx, >tmp_frame,
+ AV_GET_BUFFER_FLAG_REF);
if (err < 0)
goto fail;
-pic->output_surface = ff_vaapi_get_surface_id(ctx->tmp_frame);
+pic->output_surface = ff_vaapi_get_surface_id(ctx->tmp_frame.f);
} else {
pic->output_surface = ff_vaapi_get_surface_id(s->cur_frame.f);
}
@@ -265,8 +241,8 @@ static int vaapi_av1_start_frame(AVCodecContext *avctx,
if (pic_param.pic_info_fields.bits.frame_type == AV1_FRAME_KEY &&
frame_header->show_frame)
pic_param.ref_frame_map[i] = VA_INVALID_ID;
else
-pic_param.ref_frame_map[i] = ctx->ref_tab[i].valid ?
-
ff_vaapi_get_surface_id(ctx->ref_tab[i].frame) :
+pic_param.ref_frame_map[i] = ctx->ref_tab[i].f ?
+
ff_vaapi_get_surface_id(ctx->ref_tab[i].f) :
vaapi_av1_surface_id(>ref[i]);
}
for (int i = 0; i < AV1_REFS_PER_FRAME; i++) {
@@ -370,17 +346,10 @@ static int vaapi_av1_end_frame(AVCodecContext *avctx)
for (int i = 0; i < AV1_NUM_REF_FRAMES; i++) {
if (header->refresh_frame_flags & (1 << i)) {
-if (ctx->ref_tab[i].frame->buf[0])
-av_frame_unref(ctx->ref_tab[i].frame);
+ff_progress_frame_unref(>ref_tab[i]);
-if (apply_grain) {
-ret = av_frame_ref(ctx->ref_tab[i].frame, ctx->tmp_frame);
-if (ret < 0)
-return ret;
-ctx->ref_tab[i].valid = 1;
-} else {
-ctx->ref_tab[i].valid = 0;
-}
+if (apply_grain)
+ff_progress_frame_ref(>ref_tab[i], >tmp_frame);
}
}
@@ -431,7 +400,7 @@ const FFHWAccel ff_av1_vaapi_hwaccel = {
.end_frame= vaapi_av1_end_frame,
.decode_slice = vaapi_av1_decode_slice,
.frame_priv_data_size = sizeof(VAAPIDecodePicture),
-
[FFmpeg-devel] [PATCH 4/5] avcodec/av1dec: Make av1_frame_replace() out of av1_frame_ref()
Signed-off-by: Andreas Rheinhardt
---
libavcodec/av1dec.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 2a1a249bc4..21ba9d475d 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -683,16 +683,15 @@ static void av1_frame_unref(AV1Frame *f)
f->coded_lossless = 0;
}
-static void av1_frame_ref(AVCodecContext *avctx, AV1Frame *dst, const AV1Frame
*src)
+static void av1_frame_replace(AV1Frame *dst, const AV1Frame *src)
{
+av_assert1(dst != src);
+
ff_refstruct_replace(>header_ref, src->header_ref);
dst->raw_frame_header = src->raw_frame_header;
-if (!src->f)
-return;
-
-ff_progress_frame_ref(>pf, >pf);
+ff_progress_frame_replace(>pf, >pf);
ff_refstruct_replace(>hwaccel_picture_private,
src->hwaccel_picture_private);
@@ -1191,10 +1190,8 @@ static void update_reference_list(AVCodecContext *avctx)
const AV1RawFrameHeader *header = s->raw_frame_header;
for (int i = 0; i < AV1_NUM_REF_FRAMES; i++) {
-if (header->refresh_frame_flags & (1 << i)) {
-av1_frame_unref(>ref[i]);
-av1_frame_ref(avctx, >ref[i], >cur_frame);
-}
+if (header->refresh_frame_flags & (1 << i))
+av1_frame_replace(>ref[i], >cur_frame);
}
}
@@ -1324,10 +1321,8 @@ static int av1_receive_frame_internal(AVCodecContext
*avctx, AVFrame *frame)
s->raw_frame_header = >obu.frame_header;
if (s->raw_frame_header->show_existing_frame) {
-av1_frame_unref(>cur_frame);
-
-av1_frame_ref(avctx, >cur_frame,
-
>ref[s->raw_frame_header->frame_to_show_map_idx]);
+av1_frame_replace(>cur_frame,
+
>ref[s->raw_frame_header->frame_to_show_map_idx]);
update_reference_list(avctx);
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/5] avcodec/av1dec: Use ProgressFrames
AV1 can put a frame into multiple reference slots;
up until now, this involved creating a new reference
to the underlying AVFrame; therefore av1_frame_ref()
could fail.
This commit changes this by using the ProgressFrame API
to share the underlying AVFrames.
(Hint: vaapi_av1_surface_id() checked whether the AV1Frames
contained in the AV1DecContext were NULL or not (of course
they were not); this has been changed to actually check for
whether said AV1Frame is blank or not.)
Signed-off-by: Andreas Rheinhardt
---
1. The AV1 patches are basically untested (apart from FATE and
compilation). Could someone please test them?
2. An alternative is to use an array of AV1Frames and an array of
pointers to AV1Frames. The former have refcounts where each pointer
to an AV1Frame is considered to own a reference. av1_frame_ref()
would boil down to incrementing a refcount and setting a pointer.
3. Is there a specific reason that vulkan checked pict_type
instead of setting whether e.g. buf[0] or data[0] was set
(as is customarily done)?
libavcodec/av1dec.c | 92 +++--
libavcodec/av1dec.h | 8 +++-
libavcodec/dxva2_av1.c | 8 ++--
libavcodec/nvdec_av1.c | 4 +-
libavcodec/vaapi_av1.c | 6 +--
libavcodec/vdpau_av1.c | 7 ++--
libavcodec/vulkan_av1.c | 4 +-
7 files changed, 47 insertions(+), 82 deletions(-)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index b4b741054a..2a1a249bc4 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -38,8 +38,8 @@
#include "itut35.h"
#include "hwconfig.h"
#include "profiles.h"
+#include "progressframe.h"
#include "refstruct.h"
-#include "thread.h"
/**< same with Div_Lut defined in spec 7.11.3.7 */
static const uint16_t div_lut[AV1_DIV_LUT_NUM] = {
@@ -672,7 +672,7 @@ static int get_pixel_format(AVCodecContext *avctx)
static void av1_frame_unref(AV1Frame *f)
{
-av_frame_unref(f->f);
+ff_progress_frame_unref(>pf);
ff_refstruct_unref(>hwaccel_picture_private);
ff_refstruct_unref(>header_ref);
f->raw_frame_header = NULL;
@@ -683,20 +683,16 @@ static void av1_frame_unref(AV1Frame *f)
f->coded_lossless = 0;
}
-static int av1_frame_ref(AVCodecContext *avctx, AV1Frame *dst, const AV1Frame
*src)
+static void av1_frame_ref(AVCodecContext *avctx, AV1Frame *dst, const AV1Frame
*src)
{
-int ret;
-
ff_refstruct_replace(>header_ref, src->header_ref);
dst->raw_frame_header = src->raw_frame_header;
-if (!src->f->buf[0])
-return 0;
+if (!src->f)
+return;
-ret = av_frame_ref(dst->f, src->f);
-if (ret < 0)
-goto fail;
+ff_progress_frame_ref(>pf, >pf);
ff_refstruct_replace(>hwaccel_picture_private,
src->hwaccel_picture_private);
@@ -725,12 +721,6 @@ static int av1_frame_ref(AVCodecContext *avctx, AV1Frame
*dst, const AV1Frame *s
sizeof(dst->ref_frame_sign_bias));
memcpy(dst->order_hints, src->order_hints,
sizeof(dst->order_hints));
-
-return 0;
-
-fail:
-av1_frame_unref(dst);
-return AVERROR(ENOMEM);
}
static av_cold int av1_decode_free(AVCodecContext *avctx)
@@ -738,16 +728,9 @@ static av_cold int av1_decode_free(AVCodecContext *avctx)
AV1DecContext *s = avctx->priv_data;
AV1RawMetadataITUTT35 itut_t35;
-for (int i = 0; i < FF_ARRAY_ELEMS(s->ref); i++) {
-if (s->ref[i].f) {
-av1_frame_unref(>ref[i]);
-av_frame_free(>ref[i].f);
-}
-}
-if (s->cur_frame.f) {
-av1_frame_unref(>cur_frame);
-av_frame_free(>cur_frame.f);
-}
+for (int i = 0; i < FF_ARRAY_ELEMS(s->ref); i++)
+av1_frame_unref(>ref[i]);
+av1_frame_unref(>cur_frame);
av_buffer_unref(>seq_data_ref);
ff_refstruct_unref(>seq_ref);
ff_refstruct_unref(>header_ref);
@@ -863,16 +846,6 @@ static av_cold int av1_decode_init(AVCodecContext *avctx)
s->pkt = avctx->internal->in_pkt;
s->pix_fmt = AV_PIX_FMT_NONE;
-for (int i = 0; i < FF_ARRAY_ELEMS(s->ref); i++) {
-s->ref[i].f = av_frame_alloc();
-if (!s->ref[i].f)
-return AVERROR(ENOMEM);
-}
-
-s->cur_frame.f = av_frame_alloc();
-if (!s->cur_frame.f)
-return AVERROR(ENOMEM);
-
ret = ff_cbs_init(>cbc, AV_CODEC_ID_AV1, avctx);
if (ret < 0)
return ret;
@@ -934,7 +907,8 @@ static int av1_frame_alloc(AVCodecContext *avctx, AV1Frame
*f)
return ret;
}
-if ((ret = ff_thread_get_buffer(avctx, f->f, AV_GET_BUFFER_FLAG_REF)) < 0)
+ret = ff_progress_frame_get_buffer(avctx, >pf, AV_GET_BUFFER_FLAG_REF);
+if (ret < 0)
goto fail;
frame = f->f;
@@ -1211,23 +1185,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
return 0;
}
-static int update_reference_list(AVCodecContext *avctx)
+static void update_reference_list(AVCodecContext *avctx)
{
AV1DecContext *s = avctx->priv_data;
const AV1RawFrameHeader *header = s->raw_frame_header;
[FFmpeg-devel] [PATCH 2/5] avcodec/hevcdec: Use union for AVFrame* and ProgressFrame
It avoids having to sync ProgressFrame.f and the pointer
typically used to access the AVFrame.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevc_refs.c | 2 --
libavcodec/hevcdec.c | 1 -
libavcodec/hevcdec.h | 8 ++--
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 192d311696..8da9ec982a 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -34,7 +34,6 @@ void ff_hevc_unref_frame(HEVCFrame *frame, int flags)
frame->flags &= ~flags;
if (!frame->flags) {
ff_progress_frame_unref(>tf);
-frame->frame = NULL;
av_frame_unref(frame->frame_grain);
frame->needs_fg = 0;
@@ -87,7 +86,6 @@ static HEVCFrame *alloc_frame(HEVCContext *s)
AV_GET_BUFFER_FLAG_REF);
if (ret < 0)
return NULL;
-frame->frame = frame->tf.f;
frame->rpl = ff_refstruct_allocz(s->pkt.nb_nals * sizeof(*frame->rpl));
if (!frame->rpl)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 1974bf9cb3..50433957f7 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -3418,7 +3418,6 @@ static int hevc_ref_frame(HEVCFrame *dst, HEVCFrame *src)
int ret;
ff_progress_frame_ref(>tf, >tf);
-dst->frame = dst->tf.f;
if (src->needs_fg) {
ret = av_frame_ref(dst->frame_grain, src->frame_grain);
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index 24fcbf440a..e82daf6679 100644
--- a/libavcodec/hevcdec.h
+++ b/libavcodec/hevcdec.h
@@ -352,9 +352,13 @@ typedef struct DBParams {
#define HEVC_SEQUENCE_COUNTER_INVALID (HEVC_SEQUENCE_COUNTER_MASK + 1)
typedef struct HEVCFrame {
-AVFrame *frame;
+union {
+struct {
+AVFrame *frame;
+};
+ProgressFrame tf;
+};
AVFrame *frame_grain;
-ProgressFrame tf;
int needs_fg; /* 1 if grain needs to be applied by the decoder */
MvField *tab_mvf; ///< RefStruct reference
RefPicList *refPicList;
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/5] avcodec/progressframe: Explain how unnamed union can simplify accesses
This relies on the common initial seqence guarantee
(and on C11 support for unnamed members).
Signed-off-by: Andreas Rheinhardt
---
Alternatively, we could rely on type punning via unions and even use
union {
AVFrame *const f;
ProgressFrame pf;
};
libavcodec/progressframe.h | 12
1 file changed, 12 insertions(+)
diff --git a/libavcodec/progressframe.h b/libavcodec/progressframe.h
index dc841f30d2..428a461659 100644
--- a/libavcodec/progressframe.h
+++ b/libavcodec/progressframe.h
@@ -58,6 +58,18 @@
struct AVCodecContext;
+/**
+ * The ProgressFrame structure.
+ * Hint: It is guaranteed that the AVFrame pointer is at the start
+ * of ProgressFrame. This allows to use an unnamed
+ * union {
+ *struct {
+ *AVFrame *f;
+ *};
+ *ProgressFrame pf;
+ * };
+ * to simplify accessing the embedded AVFrame.
+ */
typedef struct ProgressFrame {
struct AVFrame *f;
struct ProgressInternal *progress;
--
2.40.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] avcodec/hevcdec: Fix precedence, bogus film grain warning
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/hevcdec.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index a2c967cf09..1974bf9cb3 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -2898,10 +2898,10 @@ static int hevc_frame_start(HEVCContext *s)
> goto fail;
>
> if (s->ref->needs_fg &&
> -( s->sei.common.film_grain_characteristics.present &&
> -
> !ff_h274_film_grain_params_supported(s->sei.common.film_grain_characteristics.model_id,
> - s->ref->frame->format))
> - || !av_film_grain_params_select(s->ref->frame)) {
> +(s->sei.common.film_grain_characteristics.present &&
> +
> !ff_h274_film_grain_params_supported(s->sei.common.film_grain_characteristics.model_id,
> + s->ref->frame->format)
> + || !av_film_grain_params_select(s->ref->frame))) {
> av_log_once(s->avctx, AV_LOG_WARNING, AV_LOG_DEBUG,
> >film_grain_warning_shown,
> "Unsupported film grain parameters. Ignoring film
> grain.\n");
> s->ref->needs_fg = 0;
Approved by Niklas on IRC and pushed.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On 19 Apr 2024, at 16:50, Niklas Haas wrote: > On Thu, 18 Apr 2024 22:53:51 +0200 Michael Niedermayer > wrote: >> A plugin system moves this patch-management to people who actually >> care, that is the authors of the codecs and (de)muxers. > > A plugin system will only solve this insomuch as plugin authors will > just host their plugin code on GitHub instead of bothering with the > mailing list. > > I think it runs a good risk of basically killing the project. > >> Our productivity as is, is not good, many patches are ignored. >> The people caring about these patches are their Authors and yet they >> are powerless as they must sometimes wait many months for reviews > > So, rather than all of the above, what I think we should do is contract > somebody to set up, manage, host and maintain a GitLab instance for us. > > This would probably be the single most cost effective boost to both > community growth and innovation I can think of, as it will remove > several of the major grievances and barriers to entry with the > ML+pingspam model. I agree with that. IMO extending patchwork while possible is just a stopgap measure and requires quite a bit of effort too that is probably better spent elsewhere. Using Trac to manage patches additionally just adds even more inconsistent places to have patch info that go out of sync with reality like patchwork already does… I am by no means a die hard GitLab fan, quite the contrary, but I still believe it is a vast improvement over the Mailing List workflow and if there are shortcomings in the tooling so that some peoples workflows can continue to work, efforts are probably better spent overcoming these, rather than „beating a dead horse“ (patching Patchwork). > > We can use a system like VLC's auto-merge bot, where any MR that has at > least one developer approval, no unresolved issues, and no activity for > N days gets *automatically* merged. Just to clarify, it does not automatically merge but rather tags them and a maintainer still does the actual merge. > > I'm sure that if we try, we can find an interested party willing to fund > this. (Maybe SPI?) > >> Besides that, developers are leaving for various reasons and they >> are forced to setup full forks not being able to maintain their >> code in any other way. >> IMO A plugin system would improve productivity as everyone could work >> on their own terms. >> No week or month long delays and weekly pinging patches >> No risk about patches being rejected or ignored >> No need to read every other discussion on the ML. One can just >> simply work on their own plugin looking just at the API documentation >> ... >> >> >> >>> * ffchat (expand into realtime chat / zoom) this would bring in more users and developers, and we basically have almost all parts for it already but some people where against it >>> >>> This seems like a user application on top of FFmpeg, not something that >>> should be part of FFmpeg core. Can you explain what modifications in >>> FFmpeg would be necessary for something like this? >> >> ffmpeg, ffplay, ffprobe are also user applications. >> >> >>> * client side / in browser support (expand towards webapps, webpages using ffmpeg client side in the browser) bring in more users and developers, and it will be costly for us if we let others take this area as its important and significant >>> >>> I don't understand this point - don't all major browsers already vendor >>> FFmpeg for decoding? >> >> FFmpeg does more than decoding. >> >> >>> * AI / neural network filters and codecs The future seems to be AI based. Future Filters and Codecs will use neural networks. FFmpeg can be at the forefront, developing these >>> >>> We already have TensorFlow support, no? (vf_sr etc.) What more is >>> needed? >> >> more of that AND more convenience >> >> lets pick a comparission >> to run fate >> you write "make fate" >> if you want to do it with the samples its >> make fate-rsync ; make fate >> >> if you want to use vf_sr, its reading the docs, looking at some scripts >> reading their docs >> and i presume selecting a training set ? creating a model ? >> >> how many people do that ? >> >> thx >> >> [...] >> >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> I have often repented speaking, but never of holding my tongue. >> -- Xenocrates >> ___ >> 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] [RFC] 5 year plan & Inovation
On Thu, 18 Apr 2024 22:53:51 +0200 Michael Niedermayer wrote: > A plugin system moves this patch-management to people who actually > care, that is the authors of the codecs and (de)muxers. A plugin system will only solve this insomuch as plugin authors will just host their plugin code on GitHub instead of bothering with the mailing list. I think it runs a good risk of basically killing the project. > Our productivity as is, is not good, many patches are ignored. > The people caring about these patches are their Authors and yet they > are powerless as they must sometimes wait many months for reviews So, rather than all of the above, what I think we should do is contract somebody to set up, manage, host and maintain a GitLab instance for us. This would probably be the single most cost effective boost to both community growth and innovation I can think of, as it will remove several of the major grievances and barriers to entry with the ML+pingspam model. We can use a system like VLC's auto-merge bot, where any MR that has at least one developer approval, no unresolved issues, and no activity for N days gets *automatically* merged. I'm sure that if we try, we can find an interested party willing to fund this. (Maybe SPI?) > Besides that, developers are leaving for various reasons and they > are forced to setup full forks not being able to maintain their > code in any other way. > IMO A plugin system would improve productivity as everyone could work > on their own terms. > No week or month long delays and weekly pinging patches > No risk about patches being rejected or ignored > No need to read every other discussion on the ML. One can just > simply work on their own plugin looking just at the API documentation > ... > > > > > > > > * ffchat > > > (expand into realtime chat / zoom) this would > > > bring in more users and developers, and we basically have almost > > > all parts for it already but some people where against it > > > > This seems like a user application on top of FFmpeg, not something that > > should be part of FFmpeg core. Can you explain what modifications in > > FFmpeg would be necessary for something like this? > > ffmpeg, ffplay, ffprobe are also user applications. > > > > > > > * client side / in browser support > > > (expand towards webapps, webpages using ffmpeg client side in the > > > browser) > > > bring in more users and developers, and it will be costly for us > > > if we let others take this area as its important and significant > > > > I don't understand this point - don't all major browsers already vendor > > FFmpeg for decoding? > > FFmpeg does more than decoding. > > > > > > > * AI / neural network filters and codecs > > > The future seems to be AI based. Future Filters and Codecs will use > > > neural networks. FFmpeg can be at the forefront, developing these > > > > We already have TensorFlow support, no? (vf_sr etc.) What more is > > needed? > > more of that AND more convenience > > lets pick a comparission > to run fate > you write "make fate" > if you want to do it with the samples its > make fate-rsync ; make fate > > if you want to use vf_sr, its reading the docs, looking at some scripts > reading their docs > and i presume selecting a training set ? creating a model ? > > how many people do that ? > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I have often repented speaking, but never of holding my tongue. > -- Xenocrates > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/4] lavc/vvc/refs: Use dpb_max_num_reorder_pics to control output
From: Jun Zhao
Use dpb_max_num_reorder_pics to control output instead of
dpb_max_dec_pic_buffering, when dpb_max_dec_pic_buffering
is much larger than dpb_max_num_reorder_pics, it may cause
dpb overflow error.
Signed-off-by: Jun Zhao
Signed-off-by: elinyhuang
---
libavcodec/vvc/refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vvc/refs.c b/libavcodec/vvc/refs.c
index a5ee7338d6..6694bc4c51 100644
--- a/libavcodec/vvc/refs.c
+++ b/libavcodec/vvc/refs.c
@@ -226,7 +226,7 @@ int ff_vvc_output_frame(VVCContext *s, VVCFrameContext *fc,
AVFrame *out, const
/* wait for more frames before output */
if (!flush && s->seq_output == s->seq_decode && sps &&
-nb_output <=
sps->r->sps_dpb_params.dpb_max_dec_pic_buffering_minus1[sps->r->sps_max_sublayers_minus1]
+ 1)
+nb_output <=
sps->r->sps_dpb_params.dpb_max_num_reorder_pics[sps->r->sps_max_sublayers_minus1])
return 0;
if (nb_output) {
--
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 3/4] lavc/vvc_parser: Fixed the has_b_frames setting
From: Jun Zhao
has_b_frames used in decoder for size of the frame reordering
buffer, setting this field from dpb_max_num_reorder_pics.
Signed-off-by: Jun Zhao
---
libavcodec/vvc_parser.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vvc_parser.c b/libavcodec/vvc_parser.c
index a0e10e1a7c..5373875aae 100644
--- a/libavcodec/vvc_parser.c
+++ b/libavcodec/vvc_parser.c
@@ -185,8 +185,8 @@ static void set_parser_ctx(AVCodecParserContext *s,
AVCodecContext *avctx,
avctx->color_range =
sps->vui.vui_full_range_flag ? AVCOL_RANGE_JPEG : AVCOL_RANGE_MPEG;
-avctx->has_b_frames = (sps->sps_max_sublayers_minus1 + 1) > 2 ? 2 :
- sps->sps_max_sublayers_minus1;
+avctx->has_b_frames =
+
sps->sps_dpb_params.dpb_max_num_reorder_pics[sps->sps_max_sublayers_minus1];
if (sps->sps_ptl_dpb_hrd_params_present_flag &&
sps->sps_timing_hrd_params_present_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 2/4] lavc/libxevd: Fixed the has_b_frames setting
From: Jun Zhao
has_b_frames used in decoder for size of the frame
reordering buffer, and we don't used the max_b_frames
in decoder.
Signed-off-by: Jun Zhao
---
libavcodec/libxevd.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavcodec/libxevd.c b/libavcodec/libxevd.c
index c6c7327e65..479d9be046 100644
--- a/libavcodec/libxevd.c
+++ b/libavcodec/libxevd.c
@@ -170,14 +170,12 @@ static int export_stream_params(const XevdContext *xectx,
AVCodecContext *avctx)
}
// the function returns sps->num_reorder_pics
-ret = xevd_config(xectx->id, XEVD_CFG_GET_MAX_CODING_DELAY,
>max_b_frames, );
+ret = xevd_config(xectx->id, XEVD_CFG_GET_MAX_CODING_DELAY,
>has_b_frames, );
if (XEVD_FAILED(ret)) {
av_log(avctx, AV_LOG_ERROR, "Failed to get max_coding_delay\n");
return AVERROR_EXTERNAL;
}
-avctx->has_b_frames = (avctx->max_b_frames) ? 1 : 0;
-
return 0;
}
--
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 1/4] lavc/vvc_parser: Remove max_b_frames setting
From: Jun Zhao
We don't used the max_b_frames field in decoder normally
Signed-off-by: Jun Zhao
---
libavcodec/vvc_parser.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/vvc_parser.c b/libavcodec/vvc_parser.c
index e3501fa139..a0e10e1a7c 100644
--- a/libavcodec/vvc_parser.c
+++ b/libavcodec/vvc_parser.c
@@ -187,7 +187,6 @@ static void set_parser_ctx(AVCodecParserContext *s,
AVCodecContext *avctx,
avctx->has_b_frames = (sps->sps_max_sublayers_minus1 + 1) > 2 ? 2 :
sps->sps_max_sublayers_minus1;
-avctx->max_b_frames = sps->sps_max_sublayers_minus1;
if (sps->sps_ptl_dpb_hrd_params_present_flag &&
sps->sps_timing_hrd_params_present_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] avcodec/hevcdec: Fix precedence, bogus film grain warning
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevcdec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index a2c967cf09..1974bf9cb3 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2898,10 +2898,10 @@ static int hevc_frame_start(HEVCContext *s)
goto fail;
if (s->ref->needs_fg &&
-( s->sei.common.film_grain_characteristics.present &&
-
!ff_h274_film_grain_params_supported(s->sei.common.film_grain_characteristics.model_id,
- s->ref->frame->format))
- || !av_film_grain_params_select(s->ref->frame)) {
+(s->sei.common.film_grain_characteristics.present &&
+
!ff_h274_film_grain_params_supported(s->sei.common.film_grain_characteristics.model_id,
+ s->ref->frame->format)
+ || !av_film_grain_params_select(s->ref->frame))) {
av_log_once(s->avctx, AV_LOG_WARNING, AV_LOG_DEBUG,
>film_grain_warning_shown,
"Unsupported film grain parameters. Ignoring film
grain.\n");
s->ref->needs_fg = 0;
--
2.40.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] avcodec/nvenc: High bit depth encoding for HEVC
On 19/04/2024 13:29, Lynne wrote:
Apr 19, 2024, 10:39 by ffmpeg-devel@ffmpeg.org:
From: Diego Felix de Souza
Adding 10-bit encoding support for HEVC if the input is 8-bit. In
case of 8-bit input content, NVENC performs an internal CUDA 8 to
10-bit conversion of the input prior to encoding. Currently, only
AV1 supports encoding 8-bit content as 10-bit.
Signed-off-by: Diego Felix de Souza
---
libavcodec/nvenc.c | 10 +-
libavcodec/nvenc_hevc.c | 3 +++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 794174a53f..e48224347d 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -514,7 +514,7 @@ static int nvenc_check_capabilities(AVCodecContext *avctx)
}
ret = nvenc_check_cap(avctx, NV_ENC_CAPS_SUPPORT_10BIT_ENCODE);
-if (IS_10BIT(ctx->data_pix_fmt) && ret <= 0) {
+if ((IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) && ret <= 0) {
av_log(avctx, AV_LOG_WARNING, "10 bit encode not supported\n");
return AVERROR(ENOSYS);
}
@@ -1420,8 +1420,8 @@ static av_cold int nvenc_setup_hevc_config(AVCodecContext
*avctx)
break;
}
-// force setting profile as main10 if input is 10 bit
-if (IS_10BIT(ctx->data_pix_fmt)) {
+// force setting profile as main10 if input is 10 bit or if it should be
encoded as 10 bit
+if (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) {
cc->profileGUID = NV_ENC_HEVC_PROFILE_MAIN10_GUID;
avctx->profile = AV_PROFILE_HEVC_MAIN_10;
}
@@ -1435,8 +1435,8 @@ static av_cold int nvenc_setup_hevc_config(AVCodecContext
*avctx)
hevc->chromaFormatIDC = IS_YUV444(ctx->data_pix_fmt) ? 3 : 1;
#ifdef NVENC_HAVE_NEW_BIT_DEPTH_API
-hevc->inputBitDepth = hevc->outputBitDepth =
-IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
+hevc->inputBitDepth = IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10 :
NV_ENC_BIT_DEPTH_8;
+hevc->outputBitDepth = (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth)
? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
#else
hevc->pixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
#endif
diff --git a/libavcodec/nvenc_hevc.c b/libavcodec/nvenc_hevc.c
index b949cb1bd7..d54e5f2512 100644
--- a/libavcodec/nvenc_hevc.c
+++ b/libavcodec/nvenc_hevc.c
@@ -183,6 +183,9 @@ static const AVOption options[] = {
{ "fullres", "Two Pass encoding is enabled where first Pass is full
resolution",
0,AV_OPT_TYPE_CONST, { .i64 = NV_ENC_TWO_PASS_FULL_RESOLUTION },
0, 0, VE, .unit =
"multipass" },
#endif
+#ifdef NVENC_HAVE_NEW_BIT_DEPTH_API
+{ "highbitdepth", "Enable 10 bit encode for 8 bit
input",OFFSET(highbitdepth),AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
+#endif
#ifdef NVENC_HAVE_LDKFS
{ "ldkfs","Low delay key frame scale; Specifies the Scene Change frame
size increase allowed in case of single frame VBV and CBR",
OFFSET(ldkfs),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UCHAR_MAX, VE },
--
2.34.1
Rather than introducing a new setting, could you
instead use AVCodecContext.sw_pix_fmt?
It's currently documented as being unused for encoding,
but it fits the purpose.
Vulkan can also use it.
I'm not sure I'm a fan of that.
Setting sw_pix_fmt to some arbitrary 10bit format seems super random.
How would that even look like from a users point of view who wanted to
utilize this up-conversion mode via cli?
___
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] avcodec/nvenc: High bit depth encoding for HEVC
Apr 19, 2024, 10:39 by ffmpeg-devel@ffmpeg.org:
> From: Diego Felix de Souza
>
> Adding 10-bit encoding support for HEVC if the input is 8-bit. In
> case of 8-bit input content, NVENC performs an internal CUDA 8 to
> 10-bit conversion of the input prior to encoding. Currently, only
> AV1 supports encoding 8-bit content as 10-bit.
>
> Signed-off-by: Diego Felix de Souza
> ---
> libavcodec/nvenc.c | 10 +-
> libavcodec/nvenc_hevc.c | 3 +++
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index 794174a53f..e48224347d 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
> @@ -514,7 +514,7 @@ static int nvenc_check_capabilities(AVCodecContext *avctx)
> }
>
> ret = nvenc_check_cap(avctx, NV_ENC_CAPS_SUPPORT_10BIT_ENCODE);
> -if (IS_10BIT(ctx->data_pix_fmt) && ret <= 0) {
> +if ((IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) && ret <= 0) {
> av_log(avctx, AV_LOG_WARNING, "10 bit encode not supported\n");
> return AVERROR(ENOSYS);
> }
> @@ -1420,8 +1420,8 @@ static av_cold int
> nvenc_setup_hevc_config(AVCodecContext *avctx)
> break;
> }
>
> -// force setting profile as main10 if input is 10 bit
> -if (IS_10BIT(ctx->data_pix_fmt)) {
> +// force setting profile as main10 if input is 10 bit or if it should be
> encoded as 10 bit
> +if (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) {
> cc->profileGUID = NV_ENC_HEVC_PROFILE_MAIN10_GUID;
> avctx->profile = AV_PROFILE_HEVC_MAIN_10;
> }
> @@ -1435,8 +1435,8 @@ static av_cold int
> nvenc_setup_hevc_config(AVCodecContext *avctx)
> hevc->chromaFormatIDC = IS_YUV444(ctx->data_pix_fmt) ? 3 : 1;
>
> #ifdef NVENC_HAVE_NEW_BIT_DEPTH_API
> -hevc->inputBitDepth = hevc->outputBitDepth =
> -IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10 :
> NV_ENC_BIT_DEPTH_8;
> +hevc->inputBitDepth = IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10
> : NV_ENC_BIT_DEPTH_8;
> +hevc->outputBitDepth = (IS_10BIT(ctx->data_pix_fmt) ||
> ctx->highbitdepth) ? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
> #else
> hevc->pixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
> #endif
> diff --git a/libavcodec/nvenc_hevc.c b/libavcodec/nvenc_hevc.c
> index b949cb1bd7..d54e5f2512 100644
> --- a/libavcodec/nvenc_hevc.c
> +++ b/libavcodec/nvenc_hevc.c
> @@ -183,6 +183,9 @@ static const AVOption options[] = {
> { "fullres", "Two Pass encoding is enabled where first Pass is full
> resolution",
> 0,AV_OPT_TYPE_CONST, { .i64 =
> NV_ENC_TWO_PASS_FULL_RESOLUTION },0, 0,
> VE, .unit = "multipass" },
> #endif
> +#ifdef NVENC_HAVE_NEW_BIT_DEPTH_API
> +{ "highbitdepth", "Enable 10 bit encode for 8 bit
> input",OFFSET(highbitdepth),AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> +#endif
> #ifdef NVENC_HAVE_LDKFS
> { "ldkfs","Low delay key frame scale; Specifies the Scene Change
> frame size increase allowed in case of single frame VBV and CBR",
> OFFSET(ldkfs),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UCHAR_MAX, VE },
> --
> 2.34.1
>
Rather than introducing a new setting, could you
instead use AVCodecContext.sw_pix_fmt?
It's currently documented as being unused for encoding,
but it fits the purpose.
Vulkan can also use it.
___
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] avformat: enable UDP IPv6 multicast interface selection using zone index
This message has been marked as Public on 04/19/2024 10:23Z. On Thursday, April 11, 2024 3:01 PM Ignjatović, Lazar (RS) wrote: > avformat: enable UDP IPv6 multicast interface selection using zone index > > Enabled IPv6 interface selection using zone index. Properly resolved > interface index in places where default 0 interface index is used > (marked with TODO: within udp.c). Adjusted binding for multicast > sockets that are used for reading from the network. > > For mcast addresses, bind to mcast address is attempted as before. > In case that this fails, which will happen on Windows, socket is bound > to INADDR_ANY/IN6ADDR_ANY_INIT depending on address family. Actual > interface selection is performed using udp_set_multicast_interface to > point to the desired interface for sending. Anyone got a chance to take a look at the final version of this patch? Any comments? Lazar Ignjatović Associate Software Engineer Cubic Defense // Digital Intelligence cubic.com ___ 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] avcodec/nvenc: High bit depth encoding for HEVC
From: Diego Felix de Souza
Adding 10-bit encoding support for HEVC if the input is 8-bit. In
case of 8-bit input content, NVENC performs an internal CUDA 8 to
10-bit conversion of the input prior to encoding. Currently, only
AV1 supports encoding 8-bit content as 10-bit.
Signed-off-by: Diego Felix de Souza
---
libavcodec/nvenc.c | 10 +-
libavcodec/nvenc_hevc.c | 3 +++
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 794174a53f..e48224347d 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -514,7 +514,7 @@ static int nvenc_check_capabilities(AVCodecContext *avctx)
}
ret = nvenc_check_cap(avctx, NV_ENC_CAPS_SUPPORT_10BIT_ENCODE);
-if (IS_10BIT(ctx->data_pix_fmt) && ret <= 0) {
+if ((IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) && ret <= 0) {
av_log(avctx, AV_LOG_WARNING, "10 bit encode not supported\n");
return AVERROR(ENOSYS);
}
@@ -1420,8 +1420,8 @@ static av_cold int nvenc_setup_hevc_config(AVCodecContext
*avctx)
break;
}
-// force setting profile as main10 if input is 10 bit
-if (IS_10BIT(ctx->data_pix_fmt)) {
+// force setting profile as main10 if input is 10 bit or if it should be
encoded as 10 bit
+if (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) {
cc->profileGUID = NV_ENC_HEVC_PROFILE_MAIN10_GUID;
avctx->profile = AV_PROFILE_HEVC_MAIN_10;
}
@@ -1435,8 +1435,8 @@ static av_cold int nvenc_setup_hevc_config(AVCodecContext
*avctx)
hevc->chromaFormatIDC = IS_YUV444(ctx->data_pix_fmt) ? 3 : 1;
#ifdef NVENC_HAVE_NEW_BIT_DEPTH_API
-hevc->inputBitDepth = hevc->outputBitDepth =
-IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
+hevc->inputBitDepth = IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10 :
NV_ENC_BIT_DEPTH_8;
+hevc->outputBitDepth = (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth)
? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
#else
hevc->pixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
#endif
diff --git a/libavcodec/nvenc_hevc.c b/libavcodec/nvenc_hevc.c
index b949cb1bd7..d54e5f2512 100644
--- a/libavcodec/nvenc_hevc.c
+++ b/libavcodec/nvenc_hevc.c
@@ -183,6 +183,9 @@ static const AVOption options[] = {
{ "fullres", "Two Pass encoding is enabled where first Pass is full
resolution",
0,
AV_OPT_TYPE_CONST, { .i64 = NV_ENC_TWO_PASS_FULL_RESOLUTION },0,
0, VE, .unit = "multipass" },
#endif
+#ifdef NVENC_HAVE_NEW_BIT_DEPTH_API
+{ "highbitdepth", "Enable 10 bit encode for 8 bit
input",OFFSET(highbitdepth),AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
+#endif
#ifdef NVENC_HAVE_LDKFS
{ "ldkfs","Low delay key frame scale; Specifies the Scene Change
frame size increase allowed in case of single frame VBV and CBR",
OFFSET(ldkfs),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UCHAR_MAX, VE },
--
2.34.1
---
NVIDIA GmbH
Wuerselen
Amtsgericht Aachen
HRB 8361
Managing Directors: Rebecca Peters, Donald Robertson, Janet Hall, Ludwig von
Reiche
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
___
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/nvenc: High bit depth encoding for HEVC
Hi Roman and Timo, Timo is right. As a general rule, hybrid video coding standards allow encoders to take advantage of encoding a 8-bit input as 10-bit due to the interpolation filters (inter and intra) and transform coding at 10-bit depth. This can generate a better prediction and reduced banding artifacts in smooth gradient areas, e.g., in the sky. On the particular case of the NVIDIA Video Codec SDK, we do a simple 8 bit > 10 bit conversion. No SDR > HDR conversion is performed. Due to video being encoded as 10 bits, it results to better de-correlation and hence better compression at same quality. We have observed ~3-5% BD-rate savings due to this feature. Although you are right, that the same could be acomplished with an external filter, I would still humbly ask you to consider including this patch into FFmpeg. Besides the fact that this patch, as I explained before, is a more efficient way to achieve the same result due to memory accesses and storage, the same feature is already supported in FFmpeg for AV1 (av1_nvenc). Hence, it would not make sense to the user perfom in one way for AV1 and another way for HEVC. Best regards, Diego On 19.04.24, 09:39, "Roman Arzumanyan" wrote: External email: Use caution opening links or attachments Thanks for the explanation, Timo! I was hoping that 8>10 bit up-conversion which happens in the driver may bring some goodness like SDR > HDR conversion, recently presented by NV. Or some other algo which is easier to keep proprietary. Otherwise, although it is convenient in some use cases, it doesn't look more tempting than, say, a similar 8>10 bit NPP up-conversion which shall yield the same (presumably SoL) performance. чт, 18 апр. 2024 г. в 16:32, Timo Rothenpieler mailto:t...@rothenpieler.org>>: On 18/04/2024 14:29, Roman Arzumanyan wrote: > Hi Diego, > Asking for my own education. > > As far as you've explained, the 8 > 10 bit conversion happens within the > driver, that's understandable. > But how does it influence the output? Does it perform some sort of > proprietary SDR > HDR conversion under the hood that maps the ranges? > What's gonna be the user observable difference between these 2 scenarios? > 1) 8 bit input > HEVC 8 bit profile > 8 bit HEVC output > 2) 8 bit input > 10 bit up conversion > HEVC 10 bit profile > 10 bit > HEVC output > > Better visual quality? Smaller compressed file size? > In other words, what's the purpose of this feature except enabling new > Video Codec SDK capability? Video Codecs tend to be more efficient with 10 bit, even if it's just 8 bit content that's been up-converted to 10 bit. I.e. yes, it'll (Or can, at least. Not sure if it's a given.) produce smaller/higher quality content for the same input. As for the exact reason, I can't explain, but it's a well known concept. --- NVIDIA GmbH Wuerselen Amtsgericht Aachen HRB 8361 Managing Directors: Rebecca Peters, Donald Robertson, Janet Hall, Ludwig von Reiche --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ 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/nvenc: High bit depth encoding for HEVC
Thanks for the explanation, Timo! I was hoping that 8>10 bit up-conversion which happens in the driver may bring some goodness like SDR > HDR conversion, recently presented by NV. Or some other algo which is easier to keep proprietary. Otherwise, although it is convenient in some use cases, it doesn't look more tempting than, say, a similar 8>10 bit NPP up-conversion which shall yield the same (presumably SoL) performance. чт, 18 апр. 2024 г. в 16:32, Timo Rothenpieler : > On 18/04/2024 14:29, Roman Arzumanyan wrote: > > Hi Diego, > > Asking for my own education. > > > > As far as you've explained, the 8 > 10 bit conversion happens within the > > driver, that's understandable. > > But how does it influence the output? Does it perform some sort of > > proprietary SDR > HDR conversion under the hood that maps the ranges? > > What's gonna be the user observable difference between these 2 scenarios? > > 1) 8 bit input > HEVC 8 bit profile > 8 bit HEVC output > > 2) 8 bit input > 10 bit up conversion > HEVC 10 bit profile > 10 bit > > HEVC output > > > > Better visual quality? Smaller compressed file size? > > In other words, what's the purpose of this feature except enabling new > > Video Codec SDK capability? > > Video Codecs tend to be more efficient with 10 bit, even if it's just 8 > bit content that's been up-converted to 10 bit. > I.e. yes, it'll (Or can, at least. Not sure if it's a given.) produce > smaller/higher quality content for the same input. > > As for the exact reason, I can't explain, but it's a well known concept. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Fri, Apr 19, 2024 at 1:19 AM Michael Niedermayer wrote: > On Thu, Apr 18, 2024 at 06:13:40PM -0300, James Almer wrote: > > On 4/18/2024 5:53 PM, Michael Niedermayer wrote: > > > On Thu, Apr 18, 2024 at 04:02:07PM +0200, Niklas Haas wrote: > > > > On Wed, 17 Apr 2024 15:58:32 +0200 Michael Niedermayer < > mich...@niedermayer.cc> wrote: > > > > > Hi all > > > > > > > > > > The pace of inovation in FFmpeg has been slowing down. > > > > > Most work is concentarted nowadays on code refactoring, and adding > > > > > support for new codecs and formats. > > > > > > > > > > Should we > > > > > * make a list of longer term goals > > > > > * vote on them > > > > > * and then together work towards implementing them > > > > > ? > > > > > > > > > > (The idea here is to increase the success of larger efforts > > > > > than adding codecs and refactoring code) > > > > > It would then also not be possible for individuals to object > > > > > to a previously agreed goal. > > > > > And it would add ideas for which we can try to get funding/grants > for > > > > > > > > > > (larger scale changes need consensus first that we as a whole want > > > > > them before we would be able to ask for funding/grants for them) > > > > > > > > > > Some ideas and why they would help FFmpeg: > > > > > > > > > > * Switch to a plugin architecture > > > > > (Increase the number of developers willing to contribute and > reduce > > > > > friction as the team and community grows) > > > > > > > > This would almost surely hurt productivity > > > > > > i dont agree, ill elaborae below > > > > > > > > > > as it will require exposing, > > > > versioning, documenting and maintaining a vast number of internal > APIs > > > > > > yes to some extend that is needed. It can be more or less depending > > > on how things are implemented > > > > > > > > > > which we are currently at the liberty of modifying freely. > > > > > > we are modifying these APIs for decades. That modification of APIs > > > their documentation and all code using them costs time. > > > > The AVCodec hooks being internal allowed us to add autoinserted bsfs and > to > > painlessly rewrite the decouple I/O callbacks to work as a pure pull > based > > interface. Were said internals public, that wouldn't have been possible. > > A decoder API needs packet in, frame out. > AVPacket and AVFrame are public. > (and a bunch of key-value data like width / height / timebase / > pixelformat / aspect / ... > teh struct for that is also public since a long time) > I dont see the problem. > > you have the decoder API facing the user, that causes no problems, > i dont agree that having a decoder API (or encoder, muxer, demuxer, ...) > facing a plugin would be a bigger problem than the APIs we already have > public > sure there are details, sure there are things that need one to think about > and sleep over and all that but these are from a high level point of > view simple and also the same interfaces to what we already have public > > > > > > > > > > More so we have issues with patch-management. And i claim this is > > > not the mailing list but a lack of time and in some cases a lack of > > > interrest in many areas. > > > > > > A plugin system moves this patch-management to people who actually > > > care, that is the authors of the codecs and (de)muxers. > > > > > > Our productivity as is, is not good, many patches are ignored. > > > > A lot of patches fall through the cracks rather than being ignored. > > There are people that send patchsets unthreaded (Because of misconfigured > > git send-email i suppose), and it makes browsing your mailbox hard. > > well i can say that i dont review many patches anymore because i just dont > have > the time, its not that i cant keep track of what i wanted to review. > > either i make a note in a TODO list or i keep the patch marked as NEW > in my mail user agent. > > trac in some sense or patchwork are just more public TODO lists > that can be shared between people so if one doesnt do it another > developer sees it and can do it. > > > > > > > The people caring about these patches are their Authors and yet they > > > are powerless as they must sometimes wait many months for reviews > > > Besides that, developers are leaving for various reasons and they > > > are forced to setup full forks not being able to maintain their > > > code in any other way. > > > IMO A plugin system would improve productivity as everyone could work > > > on their own terms. > > > > You say the ML is not the problem, but it sort of is. An MR based > > development would greatly improve this problem. > > People historically where very opposed to merge requests > > But, having a public git repo (that people already have) > asking for it to be merged. You get a merge commit and someone will > probably > feel offended by that. (thats not what you meant i guess) > but i would 100% support doing git merge requests. > (there are good arguments from people much smarter than me why >
