Re: [FFmpeg-devel] [PATCH v1] avcodec/vp9_superframe_split_bsf: Fix for possible null pointer dereference
Oops, you're absolutely right. I can't believe I missed ff_bsf_get_packet_ref.
My apologies for the false alarm.
It's a lesson for me to be more attentive.
Dawid
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Andreas Rheinhardt
> Sent: piątek, 6 października 2023 15:11
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v1] avcodec/vp9_superframe_split_bsf: Fix
> for possible null pointer dereference
>
> Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff Engineer/Samsung Electronics:
> >
> > Pointer ctx->priv_data->buffer_pkt->data, that can have only NULL value
> (checked at vp9_superframe_split_bsf.c:48), is dereferenced at
> vp9_superframe_split_bsf.c:57.
> >
>
> The rationale for a patch should be included in the commit message and not be
> sent as a reply to the actual patch.
>
> The warning is nonsense and you are breaking the whole BSF with this patch.
> It is
> perfectly normal for buffer_pkt->data to be NULL at line 48 and to be != NULL
> at
> line 57: There is a ff_bsf_get_packet_ref() in between which fills the packet.
>
> - Andreas
>
> >
> >> -Original Message-
> >> From: Dawid Kozinski
> >> Sent: piątek, 6 października 2023 13:02
> >> To: d.frankie...@samsung.com; ffmpeg-devel@ffmpeg.org
> >> Cc: Dawid Kozinski
> >> Subject: [PATCH v1] avcodec/vp9_superframe_split_bsf: Fix for
> >> possible null pointer dereference
> >>
> >> Signed-off-by: Dawid Kozinski
> >> ---
> >> libavcodec/vp9_superframe_split_bsf.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/vp9_superframe_split_bsf.c
> >> b/libavcodec/vp9_superframe_split_bsf.c
> >> index cddd48119c..4f94afc6d9 100644
> >> --- a/libavcodec/vp9_superframe_split_bsf.c
> >> +++ b/libavcodec/vp9_superframe_split_bsf.c
> >> @@ -45,7 +45,7 @@ static int vp9_superframe_split_filter(AVBSFContext
> >> *ctx, AVPacket *out)
> >> int i, j, ret, marker;
> >> int is_superframe = !!s->buffer_pkt->data;
> >>
> >> -if (!s->buffer_pkt->data) {
> >> +if (s->buffer_pkt->data) {
> >> ret = ff_bsf_get_packet_ref(ctx, s->buffer_pkt);
> >> if (ret < 0)
> >> return ret;
> >> --
> >> 2.25.1
> >
> >
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://protect2.fireeye.com/v1/url?k=17d2741b-76af9c5c-17d3ff54-
> 74fe485fff30-c67cc2f5726cb1a6&q=1&e=84d99260-3508-4d83-bca4-
> 3e475cf427c4&u=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmp
> eg-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 v2] lavc/libaribcaption.c: add MSZ characters related options
ping!
On 2023/09/29 19:31, TADANO Tokumei wrote:
On 2023/09/23 11:15, TADANO Tokumei wrote:
This is updated patch to "[PATCH] lavc/libaribcaption.c: add -replace_fullwidth_japanese
option" (Message-Id: <20230908130050.85688-1-aiming...@pc.nifty.jp>).
If specified fonts contain half-width glyphs, it make better rendering with
`-replace_msz_ascii false -replace_msz_japanese false` option for bitmap
sub_type.
This patch also fix a bug in libaribcaption.c. I prefer to apply this ASAP.
On 2023/09/23 11:00, TADANO Tokumei wrote:
This patch add MSZ (Middle Size; half width) characters related
options.
* add `-replace_msz_japanese` option introduced in version 1.0.1
of libaribcaption.
* add `-replace_msz_glyph` option introduced in version 1.1.0
of libaribcaption.
* rename `-replace_fullwidth_ascii` option to `-replace_msz_ascii`
to clarify option meaning.
* FIX: change all the `bool` option variables in `ARIBCaptionContext`
to `int`.
On some environments, a `bool` variable is small space than `int`.
If a `bool` option was specified by command line, following
variables would be filled and destroyed.
---
doc/decoders.texi | 28 --
libavcodec/libaribcaption.c | 40 -
2 files changed, 53 insertions(+), 15 deletions(-)
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 09b8314dd2..27b981b267 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -427,12 +427,6 @@ If your player cannot handle AVSubtitles with multiple ASS
rectangles properly,
set this option to @var{true} or define @env{ASS_SINGLE_RECT=1} to change
default behavior at compilation.
-@item -replace_fullwidth_ascii @var{boolean}
-Specify whether to replace MSZ (Middle Size, half width) fullwidth
-alphanumerics with halfwidth alphanumerics.
-
-The default is @var{true}.
-
@item -force_outline_text @var{boolean}
Specify whether always render outline text for all characters regardless of
the indication by charactor style.
@@ -459,6 +453,28 @@ Specify whether to render replaced DRCS characters as
Unicode characters.
The default is @var{true}.
+@item -replace_msz_ascii @var{boolean}
+Specify whether to replace MSZ (Middle Size, half width) fullwidth
+alphanumerics with halfwidth alphanumerics.
+
+The default is @var{true}.
+
+@item -replace_msz_japanese @var{boolean}
+Specify whether to replace some MSZ (Middle Size, half width) fullwidth
+japanese special characters with halfwidth ones.
+
+The default is @var{true}.
+
+@item -replace_msz_glyph @var{boolean}
+Specify whether to replace MSZ (Middle Size, half width) characters
+with halfwidth glyphs if the fonts supports it.
+This option works under FreeType or DirectWrite renderer
+with Adobe-Japan1 compliant fonts.
+e.g., IBM Plex Sans JP, Morisawa BIZ UDGothic, Morisawa BIZ UDMincho,
+Yu Gothic, Yu Mincho, and Meiryo.
+
+The default is @var{true}.
+
@item -canvas_size @var{image_size}
Specify the resolution of the canvas to render subtitles to; usually, this
should be frame size of input video.
diff --git a/libavcodec/libaribcaption.c b/libavcodec/libaribcaption.c
index 8a8c8f8cfd..ddff47633a 100644
--- a/libavcodec/libaribcaption.c
+++ b/libavcodec/libaribcaption.c
@@ -68,14 +68,20 @@ typedef struct ARIBCaptionContext {
int subtitle_type;
int encoding_scheme;
- bool ass_single_rect;
+ int ass_single_rect;
char *font;
- bool replace_fullwidth_ascii;
- bool force_stroke_text;
- bool ignore_background;
- bool ignore_ruby;
+ int force_stroke_text;
+ int ignore_background;
+ int ignore_ruby;
float stroke_width;
- bool replace_drcs;
+ int replace_drcs;
+ int replace_msz_ascii;
+#if defined(ARIBCC_VERSION)
+ int replace_msz_japanese;
+# if AV_VERSION_INT(ARIBCC_VERSION_MAJOR, ARIBCC_VERSION_MINOR,
ARIBCC_VERSION_PATCH) >= AV_VERSION_INT(1, 1, 0)
+ int replace_msz_glyph;
+# endif
+#endif
int64_t pts;
AVRational time_base;
@@ -1004,7 +1010,11 @@ static int aribcaption_init(AVCodecContext *avctx)
return AVERROR_EXTERNAL;
}
aribcc_decoder_set_replace_msz_fullwidth_ascii(ctx->decoder,
-
ctx->replace_fullwidth_ascii);
+ ctx->replace_msz_ascii);
+#if defined(ARIBCC_VERSION)
+ aribcc_decoder_set_replace_msz_fullwidth_japanese(ctx->decoder,
+ ctx->replace_msz_japanese);
+#endif
/* Similar behavior as ffmpeg tool to set canvas size */
if (ctx->canvas_width > 0 && ctx->canvas_height > 0 &&
@@ -1057,6 +1067,10 @@ static int aribcaption_init(AVCodecContext *avctx)
aribcc_renderer_set_force_no_background(ctx->renderer,
ctx->ignore_background);
aribcc_renderer_set_force_no_ruby(ctx->renderer, ctx->ignore_ruby);
aribcc_renderer_set_stroke_width(ctx->renderer, ctx->stroke_width);
+#if defined(ARIBCC_VE
Re: [FFmpeg-devel] [REFUND-REQUEST]] VDD23 Travel
On Sun, Oct 08, 2023 at 10:09:03AM +0800, Steven Liu wrote: > Nice to see you all after so long. > My request is for my flights, 9750,00 CNY Beijing from/to Abu Dhabi, > Abu Dhabi from/to Dublin this looks ok, ive quickly checked what prices are for this trip currently and the prices are similar thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] libavc/libx264: add support to propagate SSE values through encoder stats
Quoting Carotti, Elias via ffmpeg-devel (2023-10-02 19:35:09)
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 77a9f173b4..4c643c9066 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -129,6 +129,8 @@ typedef struct X264Context {
> int roi_warned;
>
> int mb_info;
> +
> +int64_t sse[3];
The values don't need to be preserved across frames, so might as well
put this on stack in the block calling ff_side_data_set_encoder_stats().
> } X264Context;
>
> static void X264_log(void *p, int level, const char *fmt, va_list args)
> @@ -726,7 +728,40 @@ FF_ENABLE_DEPRECATION_WARNINGS
>
> pkt->flags |= AV_PKT_FLAG_KEY*pic_out.b_keyframe;
> if (ret) {
> -ff_side_data_set_encoder_stats(pkt, (pic_out.i_qpplus1 - 1) *
> FF_QP2LAMBDA, NULL, 0, pict_type);
> +const AVPixFmtDescriptor *pix_desc =
> av_pix_fmt_desc_get(csp_to_pixfmt(pic_out.img.i_csp));
> +int error_count = 0;
> +int64_t *errors = NULL;
> +
> +if (ctx->flags & AV_CODEC_FLAG_PSNR) {
> +double scale[3] = { 1,
> +(1 << pix_desc->log2_chroma_h) * (double)(1 <<
> pix_desc->log2_chroma_w),
> +(1 << pix_desc->log2_chroma_h) * (double)(1 <<
> pix_desc->log2_chroma_w),
Any particular reason the cast is on the second value? It looks strange.
> +};
> +double mse;
> +int i;
> +
> +error_count = pix_desc->nb_components;
> +
> +av_log(ctx, AV_LOG_DEBUG, "PSNR values from libx264: %.3f %.3f
> %.3f.\n",
> + pic_out.prop.f_psnr[0], pic_out.prop.f_psnr[1],
> pic_out.prop.f_psnr[2]);
> +
> +for (i = 0; i < pix_desc->nb_components; ++i) {
for (int i
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/7] avformat/dump: print Frame Cropping side data info
Quoting James Almer (2023-10-07 18:24:58)
> Signed-off-by: James Almer
> ---
> libavformat/dump.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/libavformat/dump.c b/libavformat/dump.c
> index c0868a1bb3..8986e7c32a 100644
> --- a/libavformat/dump.c
> +++ b/libavformat/dump.c
> @@ -427,6 +427,23 @@ static void dump_s12m_timecode(void *ctx, const AVStream
> *st, const AVPacketSide
> }
> }
>
> +static void dump_cropping(void *ctx, const AVPacketSideData *sd)
> +{
> +uint32_t top, bottom, left, right;
> +
> +if (sd->size != sizeof(uint32_t) * 4) {
> +av_log(ctx, AV_LOG_ERROR, "invalid data\n");
> +return;
> +}
> +
> +top= AV_RL32(sd->data + 0);
> +bottom = AV_RL32(sd->data + 4);
> +left = AV_RL32(sd->data + 8);
> +right = AV_RL32(sd->data + 12);
> +
> +av_log(ctx, AV_LOG_INFO, "%d/%d/%d/%d", left, right, top, bottom);
%PRIu32?
Also, some user indication of which is which would be nice, like l:5/r:1/...
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/7] avformat/avformat: add a flag to signal muxers that support storing cropping values
Quoting James Almer (2023-10-07 18:25:00)
> Signed-off-by: James Almer
> ---
> libavformat/avformat.h | 1 +
> libavformat/mux.c | 8
> 2 files changed, 9 insertions(+)
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 9e7eca007e..c099ca8a01 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -500,6 +500,7 @@ typedef struct AVProbeData {
> The user or muxer can override this
> through
> AVFormatContext.avoid_negative_ts
> */
> +#define AVFMT_CROPPING 0x8 /**< Format supports storing cropping
> values */
I have mixed feeelings about this patch, for a bunch of reasons:
* It is quite ad-hoc - we don't do this for other side data types, and
this approach would not scale if we did.
* If we do want to signal this, we probably want to distinguish between
support for global and per-packet values.
* How do you expect this to be useful to the callers? I don't see this
flag actually being used in the ffmpeg CLI patch.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 6/7] fftools/ffmpeg: support applying container level cropping
Quoting James Almer (2023-10-07 18:25:02)
> Signed-off-by: James Almer
> ---
> fftools/ffmpeg.h| 3 +++
> fftools/ffmpeg_demux.c | 6 ++
> fftools/ffmpeg_enc.c| 24 +---
> fftools/ffmpeg_filter.c | 23 +++
> fftools/ffmpeg_opt.c| 3 +++
> 5 files changed, 48 insertions(+), 11 deletions(-)
>
> diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> index b059ecbb9f..94ada9d586 100644
> --- a/fftools/ffmpeg.h
> +++ b/fftools/ffmpeg.h
> @@ -155,6 +155,8 @@ typedef struct OptionsContext {
> intnb_hwaccel_output_formats;
> SpecifierOpt *autorotate;
> intnb_autorotate;
> +SpecifierOpt *apply_cropping;
> +intnb_apply_cropping;
I would prefer to handle this similarly to the "display_rotation"
option - give the user the option to override container-stored values
(which includes setting them to zero, to ignore them).
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/7] avformat/avformat: add a flag to signal muxers that support storing cropping values
On 10/10/2023 8:09 AM, Anton Khirnov wrote:
Quoting James Almer (2023-10-07 18:25:00)
Signed-off-by: James Almer
---
libavformat/avformat.h | 1 +
libavformat/mux.c | 8
2 files changed, 9 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 9e7eca007e..c099ca8a01 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -500,6 +500,7 @@ typedef struct AVProbeData {
The user or muxer can override this
through
AVFormatContext.avoid_negative_ts
*/
+#define AVFMT_CROPPING 0x8 /**< Format supports storing cropping
values */
I have mixed feeelings about this patch, for a bunch of reasons:
* It is quite ad-hoc - we don't do this for other side data types, and
this approach would not scale if we did.
* If we do want to signal this, we probably want to distinguish between
support for global and per-packet values.
This patch came to be after some discussion from the first iteration of
the set, where concerns about the cropping information being silently
lost if apply_cropping was disabled during a transcoding or codec copy
scenario where the output format didn't support storing said values.
* How do you expect this to be useful to the callers? I don't see this
flag actually being used in the ffmpeg CLI patch.
It's a format flag. Muxers use it, and the generic mux.c code will print
a warning if needed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/7] avformat/avformat: add a flag to signal muxers that support storing cropping values
Quoting James Almer (2023-10-10 13:13:46)
> On 10/10/2023 8:09 AM, Anton Khirnov wrote:
> > Quoting James Almer (2023-10-07 18:25:00)
> >> Signed-off-by: James Almer
> >> ---
> >> libavformat/avformat.h | 1 +
> >> libavformat/mux.c | 8
> >> 2 files changed, 9 insertions(+)
> >>
> >> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> >> index 9e7eca007e..c099ca8a01 100644
> >> --- a/libavformat/avformat.h
> >> +++ b/libavformat/avformat.h
> >> @@ -500,6 +500,7 @@ typedef struct AVProbeData {
> >> The user or muxer can override
> >> this through
> >> AVFormatContext.avoid_negative_ts
> >> */
> >> +#define AVFMT_CROPPING 0x8 /**< Format supports storing cropping
> >> values */
> >
> > I have mixed feeelings about this patch, for a bunch of reasons:
> > * It is quite ad-hoc - we don't do this for other side data types, and
> >this approach would not scale if we did.
> > * If we do want to signal this, we probably want to distinguish between
> >support for global and per-packet values.
>
> This patch came to be after some discussion from the first iteration of
> the set, where concerns about the cropping information being silently
> lost if apply_cropping was disabled during a transcoding or codec copy
> scenario where the output format didn't support storing said values.
>
> > * How do you expect this to be useful to the callers? I don't see this
> >flag actually being used in the ffmpeg CLI patch.
>
> It's a format flag. Muxers use it, and the generic mux.c code will print
> a warning if needed.
Why is it public then?
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 0/7] Container level frame cropping parameters
Quoting James Almer (2023-10-07 18:24:56) > This is a simple set to add support to stream wide, container level cropping > parameters, as featured in formats like Matroska and ISOBMFF. It's needed for > things like AV1 streams generated by certain hardware encoders that produce > dimension aligned output, and unlike H26x, can't export cropping info within > the bitstream. > In this set i add the packet side data type, mux and demux support to > Matroska, > and handling code to ffmpeg and ffplay. Missing is support for clap boxes in > ISOBMFF, and exporting the relevant side data from encoders like AMF. > > It's a rebased and updated version to the set i sent a month ago. Why is there no lavc-decoder handling? I would expect cropping side data submitted to lavc to be somehow propagated to decoded frames. Though there is a question of how to combine side data with the codec-level cropping. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/7] avformat/avformat: add a flag to signal muxers that support storing cropping values
On 10/10/2023 8:16 AM, Anton Khirnov wrote:
Quoting James Almer (2023-10-10 13:13:46)
On 10/10/2023 8:09 AM, Anton Khirnov wrote:
Quoting James Almer (2023-10-07 18:25:00)
Signed-off-by: James Almer
---
libavformat/avformat.h | 1 +
libavformat/mux.c | 8
2 files changed, 9 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 9e7eca007e..c099ca8a01 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -500,6 +500,7 @@ typedef struct AVProbeData {
The user or muxer can override this
through
AVFormatContext.avoid_negative_ts
*/
+#define AVFMT_CROPPING 0x8 /**< Format supports storing cropping
values */
I have mixed feeelings about this patch, for a bunch of reasons:
* It is quite ad-hoc - we don't do this for other side data types, and
this approach would not scale if we did.
* If we do want to signal this, we probably want to distinguish between
support for global and per-packet values.
This patch came to be after some discussion from the first iteration of
the set, where concerns about the cropping information being silently
lost if apply_cropping was disabled during a transcoding or codec copy
scenario where the output format didn't support storing said values.
* How do you expect this to be useful to the callers? I don't see this
flag actually being used in the ffmpeg CLI patch.
It's a format flag. Muxers use it, and the generic mux.c code will print
a warning if needed.
Why is it public then?
So the library user can know beforehand if the cropping information will
be lost or not, and choose accordingly. The warning is there for the
cases where it was ignored.
I can add a check to the CLI for it, but other than to abort or outright
ignore the user request to not apply cropping i don't see what it could
do, as mux.c already prints a warning.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/5] avformat/usmdec: do not return 0 when no packet was produced
Quoting Michael Niedermayer (2023-10-05 21:44:37) > Fixes: Assertion pkt->stream_index < (unsigned)s->nb_streams && "Invalid > stream index.\n" failed at libavformat/demux.c:617 > Fixes: > 62498/clusterfuzz-testcase-minimized-ffmpeg_dem_USM_fuzzer-4734740995112960 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/usmdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/usmdec.c b/libavformat/usmdec.c > index 1665eb8e551..b0079a1230c 100644 > --- a/libavformat/usmdec.c > +++ b/libavformat/usmdec.c > @@ -361,7 +361,7 @@ static int64_t parse_chunk(AVFormatContext *s, > AVIOContext *pb, > ret = avio_skip(pb, FFMAX(0, chunk_size - (ret - chunk_start))); > if (ret < 0) > return ret; > -return 0; > +return AVERROR(EAGAIN); I believe that should be FFERROR_REDO instead. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 4/7] avformat/avformat: add a flag to signal muxers that support storing cropping values
Quoting James Almer (2023-10-10 13:21:42)
> On 10/10/2023 8:16 AM, Anton Khirnov wrote:
> > Quoting James Almer (2023-10-10 13:13:46)
> >> On 10/10/2023 8:09 AM, Anton Khirnov wrote:
> >>> Quoting James Almer (2023-10-07 18:25:00)
> Signed-off-by: James Almer
> ---
> libavformat/avformat.h | 1 +
> libavformat/mux.c | 8
> 2 files changed, 9 insertions(+)
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 9e7eca007e..c099ca8a01 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -500,6 +500,7 @@ typedef struct AVProbeData {
> The user or muxer can
> override this through
>
> AVFormatContext.avoid_negative_ts
> */
> +#define AVFMT_CROPPING 0x8 /**< Format supports storing
> cropping values */
> >>>
> >>> I have mixed feeelings about this patch, for a bunch of reasons:
> >>> * It is quite ad-hoc - we don't do this for other side data types, and
> >>> this approach would not scale if we did.
> >>> * If we do want to signal this, we probably want to distinguish between
> >>> support for global and per-packet values.
> >>
> >> This patch came to be after some discussion from the first iteration of
> >> the set, where concerns about the cropping information being silently
> >> lost if apply_cropping was disabled during a transcoding or codec copy
> >> scenario where the output format didn't support storing said values.
> >>
> >>> * How do you expect this to be useful to the callers? I don't see this
> >>> flag actually being used in the ffmpeg CLI patch.
> >>
> >> It's a format flag. Muxers use it, and the generic mux.c code will print
> >> a warning if needed.
> >
> > Why is it public then?
>
> So the library user can know beforehand if the cropping information will
> be lost or not, and choose accordingly. The warning is there for the
> cases where it was ignored.
>
> I can add a check to the CLI for it, but other than to abort or outright
> ignore the user request to not apply cropping i don't see what it could
> do, as mux.c already prints a warning.
As I said above - there are MANY similar bits of information that the
muxer may or may not write. You cannot handle all of them with this
approach, and singling out cropping seems horribly ad-hoc to me.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/7] avcodec/packet: add a decoded frame cropping side data type
James Almer:
> Signed-off-by: James Almer
> ---
> libavcodec/packet.h | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/libavcodec/packet.h b/libavcodec/packet.h
> index b19409b719..6053d43c44 100644
> --- a/libavcodec/packet.h
> +++ b/libavcodec/packet.h
> @@ -299,6 +299,20 @@ enum AVPacketSideDataType {
> */
> AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
>
> +/**
> + * The number of pixels to discard from the
> + * top/bottom/left/right border of the decoded frame to obtain the
> sub-rectangle
> + * intended for presentation.
> + *
> + * @code
> + * u32le crop_top
> + * u32le crop_bottom
> + * u32le crop_left
> + * u32le crop_right
> + * @endcode
> + */
> +AV_PKT_DATA_FRAME_CROPPING,
> +
> /**
> * The number of side data types.
> * This is not part of the public API/ABI in the sense that it may
The data in ISOBMFF clap boxes is more general than that, therefore this
should be used so that this data can be preserved during remuxes.
See the earlier patchset by Neil Birkbeck for it:
https://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261465.html (there
is more of this discussion in subsequent months).
- 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] [PATCH 0/7] Container level frame cropping parameters
On 10/10/2023 8:17 AM, Anton Khirnov wrote: Quoting James Almer (2023-10-07 18:24:56) This is a simple set to add support to stream wide, container level cropping parameters, as featured in formats like Matroska and ISOBMFF. It's needed for things like AV1 streams generated by certain hardware encoders that produce dimension aligned output, and unlike H26x, can't export cropping info within the bitstream. In this set i add the packet side data type, mux and demux support to Matroska, and handling code to ffmpeg and ffplay. Missing is support for clap boxes in ISOBMFF, and exporting the relevant side data from encoders like AMF. It's a rebased and updated version to the set i sent a month ago. Why is there no lavc-decoder handling? I would expect cropping side data submitted to lavc to be somehow propagated to decoded frames. Though there is a question of how to combine side data with the codec-level cropping. I thought about adding lavc support alongside the CLI handling, yeah. And it should be a matter of adding the values to the existing ones in frame->crop_* as exported by decoders, which av_frame_apply_cropping() will then handle. And the reason i add support to the CLI by including a filter instead of leaving it up to lavc is that av_frame_apply_cropping() may not do exact cropping if AV_CODEC_FLAG_UNALIGNED is not set. ___ 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 5/7] fftools/ffmpeg_demux: Don't use fake object with av_opt_eval
Quoting Andreas Rheinhardt (2023-10-07 02:40:29) > The av_opt_eval family of functions emits errors messages on error > and can therefore not be used with fake objects when the AVClass > has a custom item_name callback. The AVClass for AVCodecContext > has such a custom callback (it searches whether an AVCodec is set > to use its name). In practice it means that whatever is directly > after the "cc" pointer to the AVClass for AVCodec in the stack frame > of ist_add() will be treated as a pointer to an AVCodec with > unpredictable consequences. > > Fix this by using an actual AVCodecContext instead of a fake object. > > Signed-off-by: Andreas Rheinhardt > --- > fftools/ffmpeg_demux.c | 15 +++ > 1 file changed, 7 insertions(+), 8 deletions(-) Ok -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 6/7] fftools/ffmpeg_demux: Fix leak on error
Quoting Andreas Rheinhardt (2023-10-07 02:40:30) > An AVFormatContext leaks on errors that happen before it is attached > to its permanent place (an InputFile). Fix this by attaching > it earlier. > > Given that it is not documented that avformat_close_input() is usable > with an AVFormatContext that has only been allocated with > avformat_alloc_context() and not opened with avformat_open_input(), > one error path before avformat_open_input() had to be treated > specially: It uses avformat_free_context(). > > Signed-off-by: Andreas Rheinhardt > --- > fftools/ffmpeg_demux.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) Ok -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 0/7] Container level frame cropping parameters
Quoting James Almer (2023-10-10 13:44:19) > On 10/10/2023 8:17 AM, Anton Khirnov wrote: > > Quoting James Almer (2023-10-07 18:24:56) > >> This is a simple set to add support to stream wide, container level > >> cropping > >> parameters, as featured in formats like Matroska and ISOBMFF. It's needed > >> for > >> things like AV1 streams generated by certain hardware encoders that produce > >> dimension aligned output, and unlike H26x, can't export cropping info > >> within > >> the bitstream. > >> In this set i add the packet side data type, mux and demux support to > >> Matroska, > >> and handling code to ffmpeg and ffplay. Missing is support for clap boxes > >> in > >> ISOBMFF, and exporting the relevant side data from encoders like AMF. > >> > >> It's a rebased and updated version to the set i sent a month ago. > > > > Why is there no lavc-decoder handling? I would expect cropping side data > > submitted to lavc to be somehow propagated to decoded frames. > > Though there is a question of how to combine side data with the > > codec-level cropping. > > I thought about adding lavc support alongside the CLI handling, yeah. > And it should be a matter of adding the values to the existing ones in > frame->crop_* as exported by decoders, which av_frame_apply_cropping() > will then handle. > > And the reason i add support to the CLI by including a filter instead of > leaving it up to lavc is that av_frame_apply_cropping() may not do exact > cropping if AV_CODEC_FLAG_UNALIGNED is not set. I intend to have the CLI always set AVCodecContext.apply_cropping=0 and have it handled by lavfi for this exact reason, just didn't get to actually doing it yet. Feel free and welcome to do it yourself. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [RFC] AG (GA?) VOTE
Hi all a vote on the General Assembly composition was apparently initiated with a duration of 6 days, i saw this in my inbox: "1009 23:49 Jean-Baptiste K (3,4K) Poll: FFmpeg AG members rules" There was no real prior discussion on the mailing list about this. There are 2 choices which are similar (update the list before each vote and update it twice a year) And a 3rd option that is probably not what the "opposition" wants I think (use the 2020 version, never update) First its neccessary to give the community a chance to discuss the GA composition choices, collect suggestions and then do a vote Now iam quite unprepared to really suggest something as i also didnt think about this much or expect this vote now but at least something like * keep everyone who had vote rights but add active developers each jan/july Is a more honest choice for the "opposition" than "never update" But hey why this matters, you might ask ? just recently we discussed having the domain be controlled by the GA now someone started a vote with no prior discussion on the ML (there was discussion in VDD only) basically only one real option to choose and 6 days duration. You might be happy with this specific change here in this case but This is one reason why I was so scared in relation to the GA controlling the domain. The GA composition is a dynamic thing with the way its setup currently and with this, can easily become very different from what anyone expects. This year you spend all your time in FFmpeg and are part of the GA, next someone else makes all decissions about FFmpeg and you have no vote in it. ABout this vote, I think this vote should be paused and proper disscussion should start, IF there is a need to do this vote now. Debian uses 2 weeks minimum discussion and 2 weeks voting IIRC so thats a start point for important votes like this one. For unimporatnt things (like SDR) something like a 7 day vote if noone minds should be fine but for things critical to FFmpegs decission making, i do not think these should be rushed. Thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 0/7] Container level frame cropping parameters
On 10/10/2023 8:54 AM, Anton Khirnov wrote: Quoting James Almer (2023-10-10 13:44:19) On 10/10/2023 8:17 AM, Anton Khirnov wrote: Quoting James Almer (2023-10-07 18:24:56) This is a simple set to add support to stream wide, container level cropping parameters, as featured in formats like Matroska and ISOBMFF. It's needed for things like AV1 streams generated by certain hardware encoders that produce dimension aligned output, and unlike H26x, can't export cropping info within the bitstream. In this set i add the packet side data type, mux and demux support to Matroska, and handling code to ffmpeg and ffplay. Missing is support for clap boxes in ISOBMFF, and exporting the relevant side data from encoders like AMF. It's a rebased and updated version to the set i sent a month ago. Why is there no lavc-decoder handling? I would expect cropping side data submitted to lavc to be somehow propagated to decoded frames. Though there is a question of how to combine side data with the codec-level cropping. I thought about adding lavc support alongside the CLI handling, yeah. And it should be a matter of adding the values to the existing ones in frame->crop_* as exported by decoders, which av_frame_apply_cropping() will then handle. And the reason i add support to the CLI by including a filter instead of leaving it up to lavc is that av_frame_apply_cropping() may not do exact cropping if AV_CODEC_FLAG_UNALIGNED is not set. I intend to have the CLI always set AVCodecContext.apply_cropping=0 and have it handled by lavfi for this exact reason, just didn't get to actually doing it yet. Feel free and welcome to do it yourself. The cropping filter doesn't look at the frame cropping fields, though. It in fact exports cropping into them if you pass it hw frames. It only looks at input arguments. So it doesn't seem like that can be done without changing the filter. ___ 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 0/7] Container level frame cropping parameters
Quoting James Almer (2023-10-10 13:58:00) > On 10/10/2023 8:54 AM, Anton Khirnov wrote: > > Quoting James Almer (2023-10-10 13:44:19) > >> On 10/10/2023 8:17 AM, Anton Khirnov wrote: > >>> Quoting James Almer (2023-10-07 18:24:56) > This is a simple set to add support to stream wide, container level > cropping > parameters, as featured in formats like Matroska and ISOBMFF. It's > needed for > things like AV1 streams generated by certain hardware encoders that > produce > dimension aligned output, and unlike H26x, can't export cropping info > within > the bitstream. > In this set i add the packet side data type, mux and demux support to > Matroska, > and handling code to ffmpeg and ffplay. Missing is support for clap > boxes in > ISOBMFF, and exporting the relevant side data from encoders like AMF. > > It's a rebased and updated version to the set i sent a month ago. > >>> > >>> Why is there no lavc-decoder handling? I would expect cropping side data > >>> submitted to lavc to be somehow propagated to decoded frames. > >>> Though there is a question of how to combine side data with the > >>> codec-level cropping. > >> > >> I thought about adding lavc support alongside the CLI handling, yeah. > >> And it should be a matter of adding the values to the existing ones in > >> frame->crop_* as exported by decoders, which av_frame_apply_cropping() > >> will then handle. > >> > >> And the reason i add support to the CLI by including a filter instead of > >> leaving it up to lavc is that av_frame_apply_cropping() may not do exact > >> cropping if AV_CODEC_FLAG_UNALIGNED is not set. > > > > I intend to have the CLI always set AVCodecContext.apply_cropping=0 and > > have it handled by lavfi for this exact reason, just didn't get to > > actually doing it yet. Feel free and welcome to do it yourself. > > The cropping filter doesn't look at the frame cropping fields, though. > It in fact exports cropping into them if you pass it hw frames. It only > looks at input arguments. So it doesn't seem like that can be done > without changing the filter. I mean ffmpeg CLI would look at the frame cropping fields and insert the crop filter accordingly, as it does for other bits of metadata. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] AG (GA?) VOTE
Quoting Michael Niedermayer (2023-10-10 13:56:45) > Hi all > > a vote on the General Assembly composition was apparently initiated with > a duration of 6 days, i saw this in my inbox: > "1009 23:49 Jean-Baptiste K (3,4K) Poll: FFmpeg AG members rules" > > There was no real prior discussion on the mailing list about this. > There are 2 choices which are similar > (update the list before each vote and update it twice a year) > And a 3rd option that is probably not what the "opposition" wants I think > (use the 2020 version, never update) "opposition"? Who is this opposition, who are they opposed to, and why the scare quotes? > First its neccessary to give the community a chance to discuss the GA > composition > choices, collect suggestions and then do a vote The community did have the chance to discuss this. The point was raised at VDD over 2 weeks ago, at the developer meeting you participated in. You even commented on this specific point. Then a summary of the meeting (including the intent to have a vote on this) was sent to this mailing list. If there was no discussion then perhaps it was because nobody was interested in discussing it. > Now iam quite unprepared to really suggest something as i also didnt think > about this > much or expect this vote now but at least something like > * keep everyone who had vote rights but add active developers each jan/july > > Is a more honest choice for the "opposition" than "never update" Why did you not suggest this choice before? You had more than two weeks to do so. > But hey why this matters, you might ask ? > just recently we discussed having the domain be controlled by the GA > now someone started a vote with no prior discussion on the ML (there was > discussion in VDD only) > basically only one real option to choose and 6 days duration. > You might be happy with this specific change here in this case but > This is one reason why I was so scared in relation to the GA controlling > the domain. The GA composition is a dynamic thing with the way its setup > currently and with this, can easily become very different from what anyone > expects. > This year you spend all your time in FFmpeg and are part of the GA, next > someone else makes all decissions about FFmpeg and you have no vote in it. > > ABout this vote, I think this vote should be paused and proper disscussion > should start, IF there is a need to do this vote now. > Debian uses 2 weeks minimum discussion and 2 weeks voting IIRC so thats a > start point for important votes like this one. > For unimporatnt things (like SDR) something like a 7 day vote if noone minds > should be fine but for things critical to FFmpegs decission making, i do not > think these should be rushed. I see no reason to pause anything. There were over two weeks to discuss this point. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] AG (GA?) VOTE
Hello, On Tue, 10 Oct 2023, at 13:56, Michael Niedermayer wrote: > a vote on the General Assembly composition was apparently initiated with > a duration of 6 days, i saw this in my inbox: > "1009 23:49 Jean-Baptiste K (3,4K) Poll: FFmpeg AG members rules" > > There was no real prior discussion on the mailing list about this. https://github.com/videolabs/libspatialaudio > There are 2 choices which are similar > (update the list before each vote and update it twice a year) > And a 3rd option that is probably not what the "opposition" wants I think > (use the 2020 version, never update) Those 3 were mentioned at VDD in the FFmpeg meeting you were in. It was also already discussed at FOSDEM this year and the previous, and people complained that I did not do that vote before. > First its neccessary to give the community a chance to discuss the GA > composition > choices, collect suggestions and then do a vote I think this was done. > Now iam quite unprepared to really suggest something as i also didnt > think about this > much or expect this vote now but at least something like > * keep everyone who had vote rights but add active developers each > jan/july > > Is a more honest choice for the "opposition" than "never update" That's an extra choice, in my opinion, and we could also have it, but it's a bit annoying that you say it now. But it's doable. Best, -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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] AG (GA?) VOTE
On Tue, 10 Oct 2023, at 14:42, Jean-Baptiste Kempf wrote: >> There was no real prior discussion on the mailing list about this. > http://ffmpeg.org/pipermail/ffmpeg-devel/2023-September/314772.html -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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] AG (GA?) VOTE
On Tue, Oct 10, 2023 at 02:32:57PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-10-10 13:56:45) > > Hi all > > > > a vote on the General Assembly composition was apparently initiated with > > a duration of 6 days, i saw this in my inbox: > > "1009 23:49 Jean-Baptiste K (3,4K) Poll: FFmpeg AG members rules" > > > > There was no real prior discussion on the mailing list about this. > > There are 2 choices which are similar > > (update the list before each vote and update it twice a year) > > And a 3rd option that is probably not what the "opposition" wants I think > > (use the 2020 version, never update) > > "opposition"? > Who is this opposition, who are they opposed to, and why the scare quotes? > > > First its neccessary to give the community a chance to discuss the GA > > composition > > choices, collect suggestions and then do a vote > > The community did have the chance to discuss this. The point was raised > at VDD over 2 weeks ago, at the developer meeting you participated in. > You even commented on this specific point. My health was somewhat bad on that day, theres no way i could have within a minute from learning about this during the meeting thought about what choices would make sense and suggest them. > > Then a summary of the meeting (including the intent to have a vote on > this) was sent to this mailing list. If there was no discussion then > perhaps it was because nobody was interested in discussing it. > > > Now iam quite unprepared to really suggest something as i also didnt think > > about this > > much or expect this vote now but at least something like > > * keep everyone who had vote rights but add active developers each jan/july > > > > Is a more honest choice for the "opposition" than "never update" > > Why did you not suggest this choice before? You had more than two weeks > to do so. Because it was said voting to happen after 6.1, So i thought there is plenty of time as 6.1 is not even branched yet I really did not expect to be surprised by a vote on the GA yesterday thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] AG (GA?) VOTE
On Tue, Oct 10, 2023 at 02:42:38PM +0200, Jean-Baptiste Kempf wrote: > Hello, > > On Tue, 10 Oct 2023, at 13:56, Michael Niedermayer wrote: > > a vote on the General Assembly composition was apparently initiated with > > a duration of 6 days, i saw this in my inbox: > > "1009 23:49 Jean-Baptiste K (3,4K) Poll: FFmpeg AG members rules" > > > > There was no real prior discussion on the mailing list about this. > > https://github.com/videolabs/libspatialaudio > > > There are 2 choices which are similar > > (update the list before each vote and update it twice a year) > > And a 3rd option that is probably not what the "opposition" wants I think > > (use the 2020 version, never update) > > Those 3 were mentioned at VDD in the FFmpeg meeting you were in. > It was also already discussed at FOSDEM this year and the previous, and > people complained that I did not do that vote before. > > > First its neccessary to give the community a chance to discuss the GA > > composition > > choices, collect suggestions and then do a vote > > I think this was done. > > > Now iam quite unprepared to really suggest something as i also didnt > > think about this > > much or expect this vote now but at least something like > > * keep everyone who had vote rights but add active developers each > > jan/july > > > > Is a more honest choice for the "opposition" than "never update" > > That's an extra choice, in my opinion, and we could also have it, but it's a > bit annoying that you say it now. > But it's doable. iam sorry, i would have brought this up sooner had i realized we are voting now. I was of the impression the vote would be after 6.1 OR someone would first suggest we should do a GA vote now before actually starting the vote. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] AG (GA?) VOTE
On Tue, Oct 10, 2023 at 02:32:57PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-10-10 13:56:45) > > Hi all > > > > a vote on the General Assembly composition was apparently initiated with > > a duration of 6 days, i saw this in my inbox: > > "1009 23:49 Jean-Baptiste K (3,4K) Poll: FFmpeg AG members rules" > > > > There was no real prior discussion on the mailing list about this. > > There are 2 choices which are similar > > (update the list before each vote and update it twice a year) > > And a 3rd option that is probably not what the "opposition" wants I think > > (use the 2020 version, never update) > > "opposition"? > Who is this opposition, who are they opposed to, and why the scare quotes? Ive added the "" because i think there is no real opposition But there are people who loose their vote rights with this vote. So if they vote for the obvious options they kind of self castrate for them this looks like 1. cut off my tail 2. cut off my balls 3. stop new developers after 2020 from having vote rights This must just looks like a choice between tea, window and airplane for some people, if you know what i mean (and yes it seems my humour is modulated by lack of reasonable sleep) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] AG (GA?) VOTE
Quoting Michael Niedermayer (2023-10-10 14:58:53) > On Tue, Oct 10, 2023 at 02:32:57PM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-10-10 13:56:45) > > > Hi all > > > > > > a vote on the General Assembly composition was apparently initiated with > > > a duration of 6 days, i saw this in my inbox: > > > "1009 23:49 Jean-Baptiste K (3,4K) Poll: FFmpeg AG members rules" > > > > > > There was no real prior discussion on the mailing list about this. > > > There are 2 choices which are similar > > > (update the list before each vote and update it twice a year) > > > And a 3rd option that is probably not what the "opposition" wants I think > > > (use the 2020 version, never update) > > > > "opposition"? > > Who is this opposition, who are they opposed to, and why the scare quotes? > > > > > First its neccessary to give the community a chance to discuss the GA > > > composition > > > choices, collect suggestions and then do a vote > > > > The community did have the chance to discuss this. The point was raised > > at VDD over 2 weeks ago, at the developer meeting you participated in. > > You even commented on this specific point. > > My health was somewhat bad on that day, theres no way i could have > within a minute from learning about this during the meeting thought > about what choices would make sense and suggest them. I am not saying you have to come up with options on the spot, I'm saying you were aware of the intent to have a vote on this. > > > > Then a summary of the meeting (including the intent to have a vote on > > this) was sent to this mailing list. If there was no discussion then > > perhaps it was because nobody was interested in discussing it. > > > > > Now iam quite unprepared to really suggest something as i also didnt > > > think about this > > > much or expect this vote now but at least something like > > > * keep everyone who had vote rights but add active developers each > > > jan/july > > > > > > Is a more honest choice for the "opposition" than "never update" > > > > Why did you not suggest this choice before? You had more than two weeks > > to do so. > > Because it was said voting to happen after 6.1, So i thought there is > plenty of time as 6.1 is not even branched yet I am not aware of anyone having said that. The main impetus for this vote is to unblock other votes we need to have. The foremost of them is electing new TC and CC, which is very long overdue at this point. That should be done before voting on SDR, which presumably you want to happen before 6.1 -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] AG (GA?) VOTE
Quoting Michael Niedermayer (2023-10-10 15:21:42) > On Tue, Oct 10, 2023 at 02:32:57PM +0200, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-10-10 13:56:45) > > > Hi all > > > > > > a vote on the General Assembly composition was apparently initiated with > > > a duration of 6 days, i saw this in my inbox: > > > "1009 23:49 Jean-Baptiste K (3,4K) Poll: FFmpeg AG members rules" > > > > > > There was no real prior discussion on the mailing list about this. > > > There are 2 choices which are similar > > > (update the list before each vote and update it twice a year) > > > And a 3rd option that is probably not what the "opposition" wants I think > > > (use the 2020 version, never update) > > > > "opposition"? > > Who is this opposition, who are they opposed to, and why the scare quotes? > > Ive added the "" because i think there is no real opposition > > But there are people who loose their vote rights with this vote. > So if they vote for the obvious options they kind of self castrate > > for them this looks like > > 1. cut off my tail > 2. cut off my balls > 3. stop new developers after 2020 from having vote rights > > This must just looks like a choice between tea, window and airplane for > some people, if you know what i mean > > (and yes it seems my humour is modulated by lack of reasonable sleep) You're supposing everyone wants voting rights. That is not so in my experience - I talked to multiple semi/formerly-active developers who believe they should not have voting rights on account of not being active enough. And for people who do want voting right - gathering and maintaining the required commit count requires only a very modest effort. So if someone loses voting rights then it can only be because they don't care enough about having them. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] AG (GA?) VOTE
On 10/10/2023 12:56 PM, Michael Niedermayer wrote: > a vote on the General Assembly composition was apparently initiated with > a duration of 6 days, i saw this in my inbox: > "1009 23:49 Jean-Baptiste K (3,4K) Poll: FFmpeg AG members rules" Without commenting on anything else, I thought it was important to note that I do not think this/these emails even made it to everyone who is allowed to vote, which is a problem. - Derek ___ 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] AG (GA?) VOTE
On 10/10/2023 11:05 AM, Derek Buitenhuis wrote: On 10/10/2023 12:56 PM, Michael Niedermayer wrote: a vote on the General Assembly composition was apparently initiated with a duration of 6 days, i saw this in my inbox: "1009 23:49 Jean-Baptiste K (3,4K) Poll: FFmpeg AG members rules" Without commenting on anything else, I thought it was important to note that I do not think this/these emails even made it to everyone who is allowed to vote, which is a problem. - Derek The email was sent from ffc...@gmx.de, a domain that some email providers apparently dislike? Google at least is fine with 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] [RFC] AG (GA?) VOTE
On 10/10/2023 3:09 PM, James Almer wrote: > The email was sent from ffc...@gmx.de, a domain that some email > providers apparently dislike? Google at least is fine with it. I did not get it, not even in my spam. Neither did Vittorio. - Derek ___ 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] AG (GA?) VOTE
James Almer (12023-10-10): > The email was sent from ffc...@gmx.de, a domain that some email providers > apparently dislike? Google at least is fine with it. I do not know if I am on the voting list, but I can attest that no mail with that origin address reached the MX for my address. Regards, -- Nicolas George ___ 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] AG (GA?) VOTE
On 10/10/2023 11:42 AM, Nicolas George wrote: James Almer (12023-10-10): The email was sent from ffc...@gmx.de, a domain that some email providers apparently dislike? Google at least is fine with it. I do not know if I am on the voting list, but I can attest that no mail with that origin address reached the MX for my address. Regards, If you were in the last General Assembly list, it should have been sent to you. ___ 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] AG (GA?) VOTE
> From: ffmpeg-devel On Behalf Of James Almer > Sent: 2023年10月10日 22:55 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [RFC] AG (GA?) VOTE > > On 10/10/2023 11:42 AM, Nicolas George wrote: > > James Almer (12023-10-10): > >> The email was sent from ffc...@gmx.de, a domain that some email providers > >> apparently dislike? Google at least is fine with it. > > > > I do not know if I am on the voting list, but I can attest that no mail > > with that origin address reached the MX for my address. > > > > Regards, > > If you were in the last General Assembly list, it should have been sent > to you. I searched my three email accounts listed in mailmap and failed to find the email. > ___ > 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] Release 6.1
On Mon, Oct 9, 2023 at 1:42 PM Michael Niedermayer wrote: > > On Mon, Oct 09, 2023 at 05:37:42AM +0200, Lynne wrote: > > Jul 6, 2023, 18:04 by d...@lynne.ee: > > > > > It's been a while since we've had a release, and we've had > > > a lot of new features in. > > > We did say we would make releases more often, and I think > > > it's about time we have a new release. > > > > > > Anything anyone wants to have merged or should we branch > > > off 6.1 in a few days? > > > > > > > Could we consider at least branching off 6.1? > > we can consider branching whenever theres a consensus to do so > People are always quick in saying what they want in / done before > releases/branching. But its rare that people later reply and say that an issue > was resolved. > This makes monitoring for what blockers remain painfull > i think for the next release we should automate this > because trac has a "Blocking" field and that could be set to 6.1 > for example and then one can just query trac for all open tickets > that are blocking "6.1" > Which would make it MUCH easier to know what is blocking it and would > make it easier to know when all blockers are gone > ATM one has to go over multiple threads and then figure out what people > asked for to be done first and then find out if the things are still > not done. > Sorry if I haven't chimed in about this. From my point of view, the things I need in 6.1 have landed. So I'm fine with 6.1 being released now. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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] AG (GA?) VOTE
On Tue, Oct 10, 2023 at 03:33:21PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-10-10 14:58:53) > > On Tue, Oct 10, 2023 at 02:32:57PM +0200, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2023-10-10 13:56:45) > > > > Hi all > > > > > > > > a vote on the General Assembly composition was apparently initiated with > > > > a duration of 6 days, i saw this in my inbox: > > > > "1009 23:49 Jean-Baptiste K (3,4K) Poll: FFmpeg AG members rules" > > > > > > > > There was no real prior discussion on the mailing list about this. > > > > There are 2 choices which are similar > > > > (update the list before each vote and update it twice a year) > > > > And a 3rd option that is probably not what the "opposition" wants I > > > > think > > > > (use the 2020 version, never update) > > > > > > "opposition"? > > > Who is this opposition, who are they opposed to, and why the scare quotes? > > > > > > > First its neccessary to give the community a chance to discuss the GA > > > > composition > > > > choices, collect suggestions and then do a vote > > > > > > The community did have the chance to discuss this. The point was raised > > > at VDD over 2 weeks ago, at the developer meeting you participated in. > > > You even commented on this specific point. > > > > My health was somewhat bad on that day, theres no way i could have > > within a minute from learning about this during the meeting thought > > about what choices would make sense and suggest them. > > I am not saying you have to come up with options on the spot, I'm saying > you were aware of the intent to have a vote on this. > > > > > > > Then a summary of the meeting (including the intent to have a vote on > > > this) was sent to this mailing list. If there was no discussion then > > > perhaps it was because nobody was interested in discussing it. > > > > > > > Now iam quite unprepared to really suggest something as i also didnt > > > > think about this > > > > much or expect this vote now but at least something like > > > > * keep everyone who had vote rights but add active developers each > > > > jan/july > > > > > > > > Is a more honest choice for the "opposition" than "never update" > > > > > > Why did you not suggest this choice before? You had more than two weeks > > > to do so. > > > > Because it was said voting to happen after 6.1, So i thought there is > > plenty of time as 6.1 is not even branched yet > > I am not aware of anyone having said that. The main impetus for this I had the impression the intent was to do the release first because the discussions about the vote added (and the votes itself would more so) cause delays to the release. At least I ended up spending significant time in vote releated threads that i did not spend on release & security related work. I would have to reread tons on logs to find which exact statments gave me that impression. > vote is to unblock other votes we need to have. The foremost of them is > electing new TC and CC, which is very long overdue at this point. > That should be done before voting on SDR, which presumably you want to > happen before 6.1 the SDR vote does not need to happen before 6.1 (its nice if it does but it does not have to) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] AG (GA?) VOTE
On Tue, Oct 10, 2023 at 03:38:22PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-10-10 15:21:42) > > On Tue, Oct 10, 2023 at 02:32:57PM +0200, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2023-10-10 13:56:45) > > > > Hi all > > > > > > > > a vote on the General Assembly composition was apparently initiated with > > > > a duration of 6 days, i saw this in my inbox: > > > > "1009 23:49 Jean-Baptiste K (3,4K) Poll: FFmpeg AG members rules" > > > > > > > > There was no real prior discussion on the mailing list about this. > > > > There are 2 choices which are similar > > > > (update the list before each vote and update it twice a year) > > > > And a 3rd option that is probably not what the "opposition" wants I > > > > think > > > > (use the 2020 version, never update) > > > > > > "opposition"? > > > Who is this opposition, who are they opposed to, and why the scare quotes? > > > > Ive added the "" because i think there is no real opposition > > > > But there are people who loose their vote rights with this vote. > > So if they vote for the obvious options they kind of self castrate > > > > for them this looks like > > > > 1. cut off my tail > > 2. cut off my balls > > 3. stop new developers after 2020 from having vote rights > > > > This must just looks like a choice between tea, window and airplane for > > some people, if you know what i mean > > > > (and yes it seems my humour is modulated by lack of reasonable sleep) > > You're supposing everyone wants voting rights. That is not so in my > experience - I talked to multiple semi/formerly-active developers who > believe they should not have voting rights on account of not being > active enough. Id like to talk to them ;) And thats what id like to say: I think its perfectly reasonable to choose not to vote if one is inactive. But to choose to cut ones fingers off so one cannot vote even when a critical need arrises is something different. > > And for people who do want voting right - gathering and maintaining the > required commit count requires only a very modest effort. So if someone > loses voting rights then it can only be because they don't care enough > about having them. Alot of things require only modest effort and we care about them still we fail to do them I think one reason is all these modest efforts add up to be not modest anymore another is keeping track of everything one needs to do If the world is empty and there is just FFmpeg and a developer in it then yes i agree with your statement fully bad example but imagine one would have to pick up trash from teh street 20 times to get a right to vote in the next gov. election. How many people would do that? How many people would regret when they then cannot vote ? I dont think people look ahead enough to say "i care about FFmpeg" i better make sure i keep my vote rights and do 20 commits. I would expect it to be rather "WTF we have a vote about putting a VPN add and installer on ffmpeg.org" let me ohhh uhh i have no vote rights!? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/libvmaf: remove deprecated options
Hi, On Mon, Oct 9, 2023 at 10:17 AM Kyle Swanson wrote: > On Thu, Oct 5, 2023 at 1:19 PM Kyle Swanson wrote: > > Removal of deprecated libvmaf filter options. These options have been > > deprecated since 3d29724c008d8f27fecf85757152789b074e8ef9 (Jan 23, > > 2022). Patch attached. > > I'll push this tomorrow. Pushed. Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/libvmaf: update pix_fmts
Hi, This patch adds 12/16-bit support to the libvmaf filter. Unless there are questions/reviews, I'll push tomorrow. Patch attached. Thanks, Kyle 0001-avfilter-libvmaf-update-pix_fmts.patch Description: Binary data ___ 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] libavformat/hlsenc: set HTTP options before writing WebVTT HLS playlists
Léon Spaans 于2023年10月7日周六 05:41写道：
>
> Fixes: Erroneous HTTP POST instead of HTTP PUT for WebVTT HLS variant
> playlists.
>
> Signed-off-by: Léon Spaans
> ---
> libavformat/hlsenc.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 08f3746ce7..8f7eee202e 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1580,7 +1580,9 @@ static int hls_window(AVFormatContext *s, int last,
> VariantStream *vs)
>
> set_http_options(s, &options, hls);
> snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? "%s.tmp" :
> "%s", vs->m3u8_name);
> -if ((ret = hlsenc_io_open(s, byterange_mode ? &hls->m3u8_out : &vs->out,
> temp_filename, &options)) < 0) {
> +ret = hlsenc_io_open(s, byterange_mode ? &hls->m3u8_out : &vs->out,
> temp_filename, &options);
> +av_dict_free(&options);
> +if (ret < 0) {
> if (hls->ignore_io_errors)
> ret = 0;
> goto fail;
> @@ -1635,8 +1637,11 @@ static int hls_window(AVFormatContext *s, int last,
> VariantStream *vs)
> ff_hls_write_end_list(byterange_mode ? hls->m3u8_out : vs->out);
>
> if (vs->vtt_m3u8_name) {
> +set_http_options(vs->vtt_avf, &options, hls);
> snprintf(temp_vtt_filename, sizeof(temp_vtt_filename), use_temp_file
> ? "%s.tmp" : "%s", vs->vtt_m3u8_name);
> -if ((ret = hlsenc_io_open(s, &hls->sub_m3u8_out, temp_vtt_filename,
> &options)) < 0) {
> +ret = hlsenc_io_open(s, &hls->sub_m3u8_out, temp_vtt_filename,
> &options);
> +av_dict_free(&options);
> +if (ret < 0) {
> if (hls->ignore_io_errors)
> ret = 0;
> goto fail;
> --
> 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".
LGTM
Thanks
Steven
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] nlmeans_vulkan: parallelize workgroup invocations
Oct 7, 2023, 17:08 by d...@lynne.ee: > Removes the clever subgroup parallel prefix computation, > and instead just computes the prefix inline. > Cuts down the number of dispatches by a huge amount. > > Provides a ~12x speedup (2.5fps to 30fps on a 7900XTX, > 2.1fps to 24fps on an Ada). > > Patch attached. > Going to push the patchset a bit later today. ___ 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".
