Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: TC/CC elections
> On Nov 29, 2023, at 5:42 PM, Ronald S. Bultje wrote: > > Does ranked voting allow expressing equal weight to multiple candidates? > For example, I prefer Jerry and Tom equally, but I prefer either one over > Spike. In theory that could depend on the implementation of ranked voting, it could require strict ordering or allow expressing equal rank. I did a quick test vote on the public CIVS instance using "proportional representation" and "rank of their favorite choice" mode and it appears to allow assigning equal rank to multiple candidates. - Cosmin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 11/13] avformat/demux: support inserting bitstream filters in demuxing scenarios
On 2023-11-30 03:25 am, James Almer wrote: On 11/28/2023 1:00 AM, Gyan Doshi wrote: On 2023-11-28 12:13 am, James Almer wrote: Packets will be passed to the bsf immediately after being generated by a demuxer, and no further data will be read from the input until all packets have been returned by the bsf. Do you plan to add a lib/cli option for user-specified insertions? No. This is internal to lavf, same as the muxing implementation. Will be useful for something like dts2pts in some cases. Is the existing -bsfs option not enough? It's not flagged with OPT_INPUT so can't be set for inputs. Regards, Gyan ___ 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] [ANNOUNCE] upcoming vote: TC/CC elections
Hi, On Wed, Nov 29, 2023 at 7:01 PM Cosmin Stejerean via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > > On Nov 29, 2023, at 3:14 PM, Michael Niedermayer > wrote: > > > > If you give Jerry a weight of 10 and give Tom a weight of 9, that means > > you prefer Jerry over Tom because 10 > 9 > > If you give Spike a weight of 20 that would mean you not only prefer > Spike > > over Tom OR Jerry but also over Tom AND Jerry. Because 20 > 10 + 9 > > > > OTOH if you give Spike a weight of 18 that would mean you prefer Spike > over > > Tom OR Jerry but you prefer Tom AND Jerry over Spike. > > Because: 9 < 10< 18 < 9 + 10 > > Tom < Jerry < Spike < Tom and Jerry > > Is this last example the kind of preference that people are likely to want > to express in practice? It seems much harder to reason about and much more > likely to lead to mistakes. > > Given a list of say 7 candidates running for 5 positions that's 21 > possible combinations and in theory weights would have to be assigned such > that the sum for each one of those 21 combinations is correctly ranked by > order of preference. > > I think the simplicity of the simpler ranked choice voting might outweigh > the benefit of expressing complex preferences with the sum of weights. > Does ranked voting allow expressing equal weight to multiple candidates? For example, I prefer Jerry and Tom equally, but I prefer either one over Spike. 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 2/2] lavfi: add qrencodesrc source
---
configure | 4 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vsrc_qrencode.c | 435
4 files changed, 441 insertions(+)
create mode 100644 libavfilter/vsrc_qrencode.c
diff --git a/configure b/configure
index d6e4a1e7df..f197f499dd 100755
--- a/configure
+++ b/configure
@@ -256,6 +256,7 @@ External library support:
--enable-libopus enable Opus de/encoding via libopus [no]
--enable-libplacebo enable libplacebo library [no]
--enable-libpulseenable Pulseaudio input via libpulse [no]
+ --enable-libqrencode enable QR encode generation via libqrencode [no]
--enable-librabbitmq enable RabbitMQ library [no]
--enable-librav1eenable AV1 encoding via rav1e [no]
--enable-librist enable RIST via librist [no]
@@ -1877,6 +1878,7 @@ EXTERNAL_LIBRARY_LIST="
libopus
libplacebo
libpulse
+libqrencode
librabbitmq
librav1e
librist
@@ -3763,6 +3765,7 @@ nnedi_filter_deps="gpl"
ocr_filter_deps="libtesseract"
ocv_filter_deps="libopencv"
openclsrc_filter_deps="opencl"
+qrencodesrc_filter_deps="libqrencode"
overlay_opencl_filter_deps="opencl"
overlay_qsv_filter_deps="libmfx"
overlay_qsv_filter_select="qsvvpp"
@@ -6803,6 +6806,7 @@ enabled libopus && {
}
enabled libplacebo&& require_pkg_config libplacebo "libplacebo >=
4.192.0" libplacebo/vulkan.h pl_vulkan_create
enabled libpulse && require_pkg_config libpulse libpulse
pulse/pulseaudio.h pa_context_new
+enabled libqrencode && require_pkg_config libqrencode libqrencode
qrencode.h QRcode_encodeString
enabled librabbitmq && require_pkg_config librabbitmq "librabbitmq >=
0.7.1" amqp.h amqp_new_connection
enabled librav1e && require_pkg_config librav1e "rav1e >= 0.5.0"
rav1e.h rav1e_context_new
enabled librist && require_pkg_config librist "librist >= 0.2.7"
librist/librist.h rist_receiver_create
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e49be354bb..3eee1ba085 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -597,6 +597,7 @@ OBJS-$(CONFIG_NULLSRC_FILTER)+=
vsrc_testsrc.o
OBJS-$(CONFIG_OPENCLSRC_FILTER) += vf_program_opencl.o opencl.o
OBJS-$(CONFIG_PAL75BARS_FILTER) += vsrc_testsrc.o
OBJS-$(CONFIG_PAL100BARS_FILTER) += vsrc_testsrc.o
+OBJS-$(CONFIG_QRENCODESRC_FILTER)+= vsrc_qrencode.o textutils.o
OBJS-$(CONFIG_RGBTESTSRC_FILTER) += vsrc_testsrc.o
OBJS-$(CONFIG_SIERPINSKI_FILTER) += vsrc_sierpinski.o
OBJS-$(CONFIG_SMPTEBARS_FILTER) += vsrc_testsrc.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index aa49703c6e..3d8c454ab0 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -559,6 +559,7 @@ extern const AVFilter ff_vsrc_mandelbrot;
extern const AVFilter ff_vsrc_mptestsrc;
extern const AVFilter ff_vsrc_nullsrc;
extern const AVFilter ff_vsrc_openclsrc;
+extern const AVFilter ff_vsrc_qrencodesrc;
extern const AVFilter ff_vsrc_pal75bars;
extern const AVFilter ff_vsrc_pal100bars;
extern const AVFilter ff_vsrc_rgbtestsrc;
diff --git a/libavfilter/vsrc_qrencode.c b/libavfilter/vsrc_qrencode.c
new file mode 100644
index 00..76ebbda999
--- /dev/null
+++ b/libavfilter/vsrc_qrencode.c
@@ -0,0 +1,435 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file QR encoder source.
+ *
+ * A QR code (quick-response code) is a type of two-dimensional matrix
+ * barcode, invented in 1994, by Japanese company Denso Wave for
+ * labelling automobile parts.
+ *
+ * This source uses the libqrencode library to generate QR code:
+ * https://fukuchi.org/works/qrencode/
+ */
+
+// #define DEBUG
+
+#include "libavutil/internal.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/lfg.h"
+#include "libavutil/random_seed.h"
+
+#include "avfilter.h"
+#include "internal.h"
+#include "formats.h"
+#include "textutils.h"
+#include "video.h"
+#include "libswscale/swscale.h"
+
+#include
+
+enum var_name {
+VAR_N,
+VAR_QW,
+VAR_T,
+VAR_W,
+VAR_VARS_NB
+};
+
+static const char
[FFmpeg-devel] [PATCH 1/2] lavfi: introduce textutils
Generalize drawtext utilities to make them usable in other filters.
This will be needed to introduce the QR code source and filter without
duplicating functionality.
---
libavfilter/Makefile | 2 +-
libavfilter/textutils.c | 379 +++
libavfilter/textutils.h | 182 +
libavfilter/vf_drawtext.c | 533 ++
4 files changed, 693 insertions(+), 403 deletions(-)
create mode 100644 libavfilter/textutils.c
create mode 100644 libavfilter/textutils.h
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index de51c2a403..e49be354bb 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -290,7 +290,7 @@ OBJS-$(CONFIG_DOUBLEWEAVE_FILTER)+= vf_weave.o
OBJS-$(CONFIG_DRAWBOX_FILTER)+= vf_drawbox.o
OBJS-$(CONFIG_DRAWGRAPH_FILTER) += f_drawgraph.o
OBJS-$(CONFIG_DRAWGRID_FILTER) += vf_drawbox.o
-OBJS-$(CONFIG_DRAWTEXT_FILTER) += vf_drawtext.o
+OBJS-$(CONFIG_DRAWTEXT_FILTER) += vf_drawtext.o textutils.o
OBJS-$(CONFIG_EDGEDETECT_FILTER) += vf_edgedetect.o edge_common.o
OBJS-$(CONFIG_ELBG_FILTER) += vf_elbg.o
OBJS-$(CONFIG_ENTROPY_FILTER)+= vf_entropy.o
diff --git a/libavfilter/textutils.c b/libavfilter/textutils.c
new file mode 100644
index 00..4598861161
--- /dev/null
+++ b/libavfilter/textutils.c
@@ -0,0 +1,379 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * text expansion utilities
+ */
+
+#include
+#include
+#include
+
+#include "textutils.h"
+#include "libavutil/avutil.h"
+#include "libavutil/error.h"
+#include "libavutil/file.h"
+#include "libavutil/time.h"
+
+static int ff_expand_text_function_internal(TextExpander *text_expander,
AVBPrint *bp,
+char *name, unsigned argc, char
**argv)
+{
+void *ctx = text_expander->ctx;
+TextExpanderFunction *functions = text_expander->functions;
+unsigned i;
+
+for (i = 0; i < text_expander->functions_nb; i++) {
+if (strcmp(name, functions[i].name))
+continue;
+if (argc < functions[i].argc_min) {
+av_log(ctx, AV_LOG_ERROR, "%%{%s} requires at least %d
arguments\n",
+ name, functions[i].argc_min);
+return AVERROR(EINVAL);
+}
+if (argc > functions[i].argc_max) {
+av_log(ctx, AV_LOG_ERROR, "%%{%s} requires at most %d arguments\n",
+ name, functions[i].argc_max);
+return AVERROR(EINVAL);
+}
+break;
+}
+if (i >= text_expander->functions_nb) {
+av_log(ctx, AV_LOG_ERROR, "%%{%s} is not known\n", name);
+return AVERROR(EINVAL);
+}
+
+return functions[i].func(ctx, bp, name, argc, argv);
+}
+
+/**
+ * Expand text template pointed to by *rtext.
+ *
+ * Expand text template defined in text using the logic defined in a text
+ * expander object.
+ *
+ * This function expects the text to be in the format
%{FUNCTION_NAME[:PARAMS]},
+ * where PARAMS is a sequence of strings separated by : and represents the
function
+ * arguments to use for the function evaluation.
+ *
+ * @param text_expander TextExpander object used to expand the text
+ * @param bp BPrint object where the expanded text is written to
+ * @param rtext pointer to pointer to the text to expand, it is updated to
point
+ * to the next part of the template to process
+ * @return negative value corresponding to an AVERROR error code in case of
+ * errors, a non-negative value otherwise
+ */
+static int ff_expand_text_function(TextExpander *text_expander, AVBPrint *bp,
char **rtext)
+{
+void *ctx = text_expander->ctx;
+const char *text = *rtext;
+char *argv[16] = { NULL };
+unsigned argc = 0, i;
+int ret;
+
+if (*text != '{') {
+av_log(ctx, AV_LOG_ERROR, "Stray %% near '%s'\n", text);
+return AVERROR(EINVAL);
+}
+text++;
+while (1) {
+if (!(argv[argc++] = av_get_token(, ":}"))) {
+ret = AVERROR(ENOMEM);
+goto end;
+}
+if (!*text) {
+av_log(ctx, AV_LOG_ERROR, "Unterminated %%{} near '%s'\n", *rtext);
+
[FFmpeg-devel] [POC][PATCHSET] Add qrencodesrc source
This is meant to introduce functionality to handle QR codes. This is still in early development stage (missing docs, padding functionality to avoid to insert a pad filter?), plus a filter will be added for adding a QR code on the input reading from metadata, and possibly at some point also a quirc-based decoder, but comments are welcome. QR codes are robust to lossy coding, therefore it should be possible to use them to compare a generated video with a reference one (in case they cannot be compared frame-by-frame). [PATCH 1/2] lavfi: introduce textutils [PATCH 2/2] lavfi: add qrencodesrc source ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 3/3] avfilter/vf_bwdif_vulkan: consider chroma subsampling when enforcing minimum dimensions
From: Cosmin Stejerean
Signed-off-by: Cosmin Stejerean
---
libavfilter/vf_bwdif_vulkan.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_bwdif_vulkan.c b/libavfilter/vf_bwdif_vulkan.c
index 690a89c4ba..6a886d11ac 100644
--- a/libavfilter/vf_bwdif_vulkan.c
+++ b/libavfilter/vf_bwdif_vulkan.c
@@ -362,13 +362,19 @@ static int bwdif_vulkan_config_output(AVFilterLink
*outlink)
outlink->frame_rate = av_mul_q(avctx->inputs[0]->frame_rate,
(AVRational){2, 1});
-if (outlink->w < 4 || outlink->h < 4) {
-av_log(avctx, AV_LOG_ERROR, "Video of less than 4 columns or lines is
not "
- "supported\n");
+const AVPixFmtDescriptor *desc =
av_pix_fmt_desc_get(vkctx->frames->sw_format);
+
+int h = link->h;
+int w = link->w;
+int h_chroma = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
+int w_chroma = AV_CEIL_RSHIFT(w, desc->log2_chroma_w);
+
+if (w < 4 || w_chroma < 4 || h < 4 || h_chroma < 4) {
+av_log(ctx, AV_LOG_ERROR, "Video with planes less than 4 columns or
lines is not supported\n");
return AVERROR(EINVAL);
}
-y->csp = av_pix_fmt_desc_get(vkctx->frames->sw_format);
+y->csp = desc;
y->filter = bwdif_vulkan_filter_frame;
return init_filter(avctx);
--
2.42.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/3] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions
From: Cosmin Stejerean
Fixes #10688
Signed-off-by: Cosmin Stejerean
---
libavfilter/vf_bwdif.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 137cd5ef13..80aa85a48b 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -191,12 +191,19 @@ static int config_props(AVFilterLink *link)
return ret;
}
-if (link->w < 3 || link->h < 4) {
-av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or 4 lines is
not supported\n");
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(link->format);
+
+int h = link->h;
+int w = link->w;
+int h_chroma = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
+int w_chroma = AV_CEIL_RSHIFT(w, desc->log2_chroma_w);
+
+if (w < 3 || w_chroma < 3 || h < 4 || h_chroma < 4) {
+av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3 columns or 4
lines is not supported\n");
return AVERROR(EINVAL);
}
-yadif->csp = av_pix_fmt_desc_get(link->format);
+yadif->csp = desc;
yadif->filter = filter;
ff_bwdif_init_filter_line(>dsp, yadif->csp->comp[0].depth);
--
2.42.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/3] avfilter/vf_bwdif_cuda: consider chroma subsampling when enforcing minimum dimensions
From: Cosmin Stejerean
Signed-off-by: Cosmin Stejerean
---
libavfilter/vf_bwdif_cuda.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_bwdif_cuda.c b/libavfilter/vf_bwdif_cuda.c
index a5ecfbadb6..7d9bf861b7 100644
--- a/libavfilter/vf_bwdif_cuda.c
+++ b/libavfilter/vf_bwdif_cuda.c
@@ -296,13 +296,20 @@ static int config_output(AVFilterLink *link)
link->frame_rate = av_mul_q(ctx->inputs[0]->frame_rate,
(AVRational){2, 1});
-if (link->w < 3 || link->h < 3) {
-av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or lines is
not supported\n");
+const AVPixFmtDescriptor *desc =
av_pix_fmt_desc_get(output_frames->sw_format);
+
+int h = link->h;
+int w = link->w;
+int h_chroma = AV_CEIL_RSHIFT(h, desc->log2_chroma_h);
+int w_chroma = AV_CEIL_RSHIFT(w, desc->log2_chroma_w);
+
+if (w < 3 || w_chroma < 3 || h < 3 || h_chroma < 3) {
+av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3 columns or
lines is not supported\n");
ret = AVERROR(EINVAL);
goto exit;
}
-y->csp = av_pix_fmt_desc_get(output_frames->sw_format);
+y->csp = desc;
y->filter = filter;
ret = CHECK_CU(cu->cuCtxPushCurrent(s->hwctx->cuda_ctx));
--
2.42.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 0/3] consider chroma subsampling for bwdif (including CUDA and Vulkan)
From: Cosmin Stejerean This fixes the issue reported in #10688. In v2 the checks for chroma plane are combined together and the fixes are extended to cover the Vulkan and CUDA implementations of bwdif. I have not had a chance to replicate the issue on CUDA or Vulkan but based on the dimension checks in those filters I believe they would have the same out of bounds issue. I kept the changes in separate patches since I've only properly tested the first one. I'll work on testing the CUDA and Vulkan implementations as well but meanwhile wanted to get some feedback on the overall approach. Cosmin Stejerean (3): avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions avfilter/vf_bwdif_cuda: consider chroma subsampling when enforcing minimum dimensions avfilter/vf_bwdif_vulkan: consider chroma subsampling when enforcing minimum dimensions libavfilter/vf_bwdif.c| 13 ++--- libavfilter/vf_bwdif_cuda.c | 13 ++--- libavfilter/vf_bwdif_vulkan.c | 14 ++ 3 files changed, 30 insertions(+), 10 deletions(-) -- 2.42.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] [ANNOUNCE] upcoming vote: TC/CC elections
> On Nov 29, 2023, at 3:14 PM, Michael Niedermayer > wrote: > > If you give Jerry a weight of 10 and give Tom a weight of 9, that means > you prefer Jerry over Tom because 10 > 9 > If you give Spike a weight of 20 that would mean you not only prefer Spike > over Tom OR Jerry but also over Tom AND Jerry. Because 20 > 10 + 9 > > OTOH if you give Spike a weight of 18 that would mean you prefer Spike over > Tom OR Jerry but you prefer Tom AND Jerry over Spike. > Because: 9 < 10< 18 < 9 + 10 > Tom < Jerry < Spike < Tom and Jerry Is this last example the kind of preference that people are likely to want to express in practice? It seems much harder to reason about and much more likely to lead to mistakes. Given a list of say 7 candidates running for 5 positions that's 21 possible combinations and in theory weights would have to be assigned such that the sum for each one of those 21 combinations is correctly ranked by order of preference. I think the simplicity of the simpler ranked choice voting might outweigh the benefit of expressing complex preferences with the sum of weights. - Cosmin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: TC/CC elections
On Tue, Nov 28, 2023 at 02:23:13PM +0100, Anton Khirnov wrote: > For the record, I've edited the vote description to make it more clear. > It now looks like this: > > Five people from the list below will become the members of the Technical > Committee (TC). Assign weights to each person according to how much you > want them to be in the committee (higher weight = higher preference). > > The system will assume you want to maximise the sum of weights of > selected candidates. E.g. if X is given a weight of 10 and Y and Z have > weights 8 and 6 respectively, then the voting algorithm will assume you > prefer a committee with both Y and Z over one with X, because 14 > 10. > However, giving Y and Z weight of 4 and 2 instead would have expressed > that X is preferred to a combination of Y and Z, because 6 < 10. My try in cooking word soup: The system will assume you want to maximise the sum of weights of the selected candidates. Some examples: If you give Jerry a weight of 10 and give Tom a weight of 9, that means you prefer Jerry over Tom because 10 > 9 If you give Spike a weight of 20 that would mean you not only prefer Spike over Tom OR Jerry but also over Tom AND Jerry. Because 20 > 10 + 9 OTOH if you give Spike a weight of 18 that would mean you prefer Spike over Tom OR Jerry but you prefer Tom AND Jerry over Spike. Because: 9 < 10< 18 < 9 + 10 Tom < Jerry < Spike < Tom and Jerry 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] [PATCH] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions
> On Nov 29, 2023, at 11:36 AM, Dennis Mungai wrote:
>
> On Wed, 29 Nov 2023 at 22:26, Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
>
>>
>>
>>> On Nov 28, 2023, at 5:30 AM, Thomas Mundt wrote:
>>>
>>> Hi Cosmin,
>>>
>>> Cosmin Stejerean via ffmpeg-devel schrieb am
>> Sa.,
>>> 25. Nov. 2023, 21:39:
>>>
Fixes #10688
Signed-off-by: Cosmin Stejerean
---
libavfilter/vf_bwdif.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 137cd5ef13..bce11c39f7 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -197,6 +197,18 @@ static int config_props(AVFilterLink *link)
}
yadif->csp = av_pix_fmt_desc_get(link->format);
+
+if (yadif->csp->nb_components > 1) {
+int w_chroma, h_chroma;
+h_chroma = AV_CEIL_RSHIFT(link->h, yadif->csp->log2_chroma_h);
+w_chroma = AV_CEIL_RSHIFT(link->w, yadif->csp->log2_chroma_w);
+
+if (w_chroma < 3 || h_chroma < 4) {
+av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3
columns or 4 lines is not supported\n");
+return AVERROR(EINVAL);
+}
+}
+
>>>
>>> Thanks for your quick patch.
>>> Could you please make the size check for all components and remove the
>> old
>>> one to avoid having two size checks in a row?
>>>
>>
>> Certainly, will send a v2 shortly.
>>
>> - Cosmin
>>
>>
> Does this change also need to be replicated to bwdif_cuda?
>
Good callout, it's like the that both bwdif_cuda and bwdif_vulkan need similar
updates as they both have checks for width and height and would likely
encounter the same problem on the chroma planes. I'll include both of those in
v2.
On a side note the minimum width and height requirements are a bit different
between the three filters in terms of whether 3x4, 3x3 or 4x4 are the minimum
required dimensions. I'm assuming this is intentional based on the underlying
filters but just wanted to double check whether it might be worth unifying all
of these to say min 4x4 for consistency.
- Cosmin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions
On Wed, 29 Nov 2023 at 22:26, Cosmin Stejerean via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
>
>
> > On Nov 28, 2023, at 5:30 AM, Thomas Mundt wrote:
> >
> > Hi Cosmin,
> >
> > Cosmin Stejerean via ffmpeg-devel schrieb am
> Sa.,
> > 25. Nov. 2023, 21:39:
> >
> >> Fixes #10688
> >>
> >> Signed-off-by: Cosmin Stejerean
> >> ---
> >> libavfilter/vf_bwdif.c | 12
> >> 1 file changed, 12 insertions(+)
> >>
> >> diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
> >> index 137cd5ef13..bce11c39f7 100644
> >> --- a/libavfilter/vf_bwdif.c
> >> +++ b/libavfilter/vf_bwdif.c
> >> @@ -197,6 +197,18 @@ static int config_props(AVFilterLink *link)
> >> }
> >>
> >> yadif->csp = av_pix_fmt_desc_get(link->format);
> >> +
> >> +if (yadif->csp->nb_components > 1) {
> >> +int w_chroma, h_chroma;
> >> +h_chroma = AV_CEIL_RSHIFT(link->h, yadif->csp->log2_chroma_h);
> >> +w_chroma = AV_CEIL_RSHIFT(link->w, yadif->csp->log2_chroma_w);
> >> +
> >> +if (w_chroma < 3 || h_chroma < 4) {
> >> +av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3
> >> columns or 4 lines is not supported\n");
> >> +return AVERROR(EINVAL);
> >> +}
> >> +}
> >> +
> >>
> >
> > Thanks for your quick patch.
> > Could you please make the size check for all components and remove the
> old
> > one to avoid having two size checks in a row?
> >
>
> Certainly, will send a v2 shortly.
>
> - Cosmin
>
>
Does this change also need to be replicated to bwdif_cuda?
___
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] avformat/matroskadec: Prevent expensive get_cue_desc lookups
On Thu, Mar 30, 2023 at 4:07 PM Tom Boshoven wrote:
>
> Due to the way the bandwidth estimation code works, the get_cue_desc
> function was called many times over.
> This function did a from-scratch lookup using a timestamp.
> This lookup was done using linear iteration (O(n)), resulting in
> significant overhead when many cues exist.
>
> This change uses ff_index_search_timestamp (binary search, O(log n))
> for the lookup.
> Additionally, the lookup is prevented entirely in most cases by
> maintaining the indexes of the cues (O(1)).
>
> Signed-off-by: Tom Boshoven
> ---
> libavformat/matroskadec.c | 64 +++
> 1 file changed, 38 insertions(+), 26 deletions(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 3a888e3ada..d974944945 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -4038,35 +4038,45 @@ typedef struct {
> int64_t end_offset;
> } CueDesc;
>
> -/* This function searches all the Cues and returns the CueDesc corresponding
> to
> - * the timestamp ts. Returned CueDesc will be such that start_time_ns <= ts <
> - * end_time_ns. All 4 fields will be set to -1 if ts >= file's duration or
> - * if an error occurred.
> +/**
> + * Find the index of the cue corresponding to the timestamp ts.
> */
> -static CueDesc get_cue_desc(AVFormatContext *s, int64_t ts, int64_t
> cues_start) {
> +static int get_cue_index(AVFormatContext *s, int64_t ts) {
> +MatroskaDemuxContext *matroska = s->priv_data;
> +FFStream *const sti = ffstream(s->streams[0]);
> +
> +if (ts >= (int64_t)(matroska->duration * matroska->time_scale))
> +return -1;
> +
> +// Look up the index entry corresponding to the timestamp (dividing by
> timescale)
> +return ff_index_search_timestamp(
> +sti->index_entries,
> +sti->nb_index_entries,
> +ts / matroska->time_scale,
> +AVSEEK_FLAG_ANY | AVSEEK_FLAG_BACKWARD
> +);
> +}
> +
> +/**
> + * Get the CueDesc for a specific index.
> + * For a given timestamp, the index can be obtained using get_cue_index.
> + */
> +static CueDesc get_cue_desc_from_index(AVFormatContext *s, int idx, int64_t
> cues_start) {
> MatroskaDemuxContext *matroska = s->priv_data;
> FFStream *const sti = ffstream(s->streams[0]);
> AVIndexEntry *const index_entries = sti->index_entries;
> int nb_index_entries = sti->nb_index_entries;
> CueDesc cue_desc;
> -int i;
>
> -if (ts >= (int64_t)(matroska->duration * matroska->time_scale))
> +if (idx < 0 || idx >= nb_index_entries) {
> return (CueDesc) {-1, -1, -1, -1};
> -for (i = 1; i < nb_index_entries; i++) {
> -if (index_entries[i - 1].timestamp * matroska->time_scale <= ts &&
> -index_entries[i].timestamp * matroska->time_scale > ts) {
> -break;
> -}
> }
> ---i;
> -if (index_entries[i].timestamp > matroska->duration)
> -return (CueDesc) {-1, -1, -1, -1};
> -cue_desc.start_time_ns = index_entries[i].timestamp *
> matroska->time_scale;
> -cue_desc.start_offset = index_entries[i].pos - matroska->segment_start;
> -if (i != nb_index_entries - 1) {
> -cue_desc.end_time_ns = index_entries[i + 1].timestamp *
> matroska->time_scale;
> -cue_desc.end_offset = index_entries[i + 1].pos -
> matroska->segment_start;
> +
> +cue_desc.start_time_ns = index_entries[idx].timestamp *
> matroska->time_scale;
> +cue_desc.start_offset = index_entries[idx].pos - matroska->segment_start;
> +if (idx != nb_index_entries - 1) {
> +cue_desc.end_time_ns = index_entries[idx + 1].timestamp *
> matroska->time_scale;
> +cue_desc.end_offset = index_entries[idx + 1].pos -
> matroska->segment_start;
> } else {
> cue_desc.end_time_ns = matroska->duration * matroska->time_scale;
> // FIXME: this needs special handling for files where Cues appear
> @@ -4140,7 +4150,8 @@ static int buffer_size_after_time_downloaded(int64_t
> time_ns, double search_sec,
> int64_t time_to_search_ns = (int64_t)(search_sec *
> nano_seconds_per_second);
> int64_t end_time_ns = time_ns + time_to_search_ns;
> double sec_downloaded = 0.0;
> -CueDesc desc_curr = get_cue_desc(s, time_ns, cues_start);
> +int cue_idx = get_cue_index(s, time_ns);
> +CueDesc desc_curr = get_cue_desc_from_index(s, cue_idx, cues_start);
> if (desc_curr.start_time_ns == -1)
>return -1;
> *sec_to_download = 0.0;
> @@ -4168,7 +4179,7 @@ static int buffer_size_after_time_downloaded(int64_t
> time_ns, double search_sec,
>}
>
>// Get the next Cue.
> - desc_curr = get_cue_desc(s, desc_curr.end_time_ns, cues_start);
> + desc_curr = get_cue_desc_from_index(s, ++cue_idx, cues_start);
> }
>
> while (desc_curr.start_time_ns != -1) {
> @@ -4197,7 +4208,7 @@ static int buffer_size_after_time_downloaded(int64_t
> time_ns, double search_sec,
>
Re: [FFmpeg-devel] [PATCH] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions
> On Nov 28, 2023, at 5:30 AM, Thomas Mundt wrote:
>
> Hi Cosmin,
>
> Cosmin Stejerean via ffmpeg-devel schrieb am Sa.,
> 25. Nov. 2023, 21:39:
>
>> Fixes #10688
>>
>> Signed-off-by: Cosmin Stejerean
>> ---
>> libavfilter/vf_bwdif.c | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
>> index 137cd5ef13..bce11c39f7 100644
>> --- a/libavfilter/vf_bwdif.c
>> +++ b/libavfilter/vf_bwdif.c
>> @@ -197,6 +197,18 @@ static int config_props(AVFilterLink *link)
>> }
>>
>> yadif->csp = av_pix_fmt_desc_get(link->format);
>> +
>> +if (yadif->csp->nb_components > 1) {
>> +int w_chroma, h_chroma;
>> +h_chroma = AV_CEIL_RSHIFT(link->h, yadif->csp->log2_chroma_h);
>> +w_chroma = AV_CEIL_RSHIFT(link->w, yadif->csp->log2_chroma_w);
>> +
>> +if (w_chroma < 3 || h_chroma < 4) {
>> +av_log(ctx, AV_LOG_ERROR, "Video with planes less than 3
>> columns or 4 lines is not supported\n");
>> +return AVERROR(EINVAL);
>> +}
>> +}
>> +
>>
>
> Thanks for your quick patch.
> Could you please make the size check for all components and remove the old
> one to avoid having two size checks in a row?
>
Certainly, will send a v2 shortly.
- Cosmin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/framesync: fix OOM case
Paul B Mahol (12023-11-27): > Attached. > From 8ce6bd0090666ef94b0455b7f8f4d3c05e273093 Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Mon, 27 Nov 2023 13:04:16 +0100 > Subject: [PATCH] avfilter/framesync: fix OOM case > > Fixes OOM when caller keeps adding frames into filtergraph > that reached EOF by other means, for example EOF is signalled > by other filter in filtergraph or by buffersink. > > Signed-off-by: Paul B Mahol > --- > libavfilter/framesync.c | 3 +++ > 1 file changed, 3 insertions(+) LGTM, good catch. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [ANNOUNCE] upcoming vote: TC/CC elections
On 28.11.23 21:30, Derek Buitenhuis wrote: On 11/28/2023 3:50 PM, Anton Khirnov wrote: Calling things generically bad is the opposite of helpful. I cannot offer help on making a paragraph that I don't fully understand become more comprehensible, as that would require I understand it fully. But, I would again like to state these votes should be scrapped and redone. People literally voted the opposite of what they wanted to by accident, due to this. FWIW the type in of weights is one of the two options to do a proportional representation for the vote. The other is the one we had used so far, by ranking the candidates from 1st to n-th. Both should serve our needs for proportional representation AFAICT and I don't assume they'd give us different results of the vote. But maybe Anton had a reason to pick one over the other. If Anton decides it's worth redoing it, we maybe just do the other option and be a bit more resilient to misinterpretation. -Thilo ___ 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 10 bit support v5 1/3] avcodec/amfenc: Fixes the color information in the output.
On Tue, Nov 28, 2023 at 8:13 PM Mark Thompson wrote: > I upgraded to 23.11.1 and see no change - the colour information is still > missing in the header but not the stream, and the two different sequence > parameter sets are identical to what they were before the change. > > Can you share what your trace_headers output looks like for the > out-of-band and in-band parameter sets? Are they identical for you? > Yes, it seems that they are identical for me and both have colour information (please find my output below). Is it possible to provide a video you tested? Probably I need to test the patch on your video input. Stream #0:0[0x1](und): Video: hevc (Main 10) (hvc1 / 0x31637668), yuv420p10le(tv, bt2020nc/bt2020/smpte2084, progressive), 3840x2160 [SAR 1:1 DAR 16:9], 2158 kb/s, 29.97 fps, 29.97 tbr, 30k tbn (default) Metadata: creation_time : 2018-11-26T22:40:26.00Z handler_name: Core Media Video vendor_id : [0][0][0][0] Side data: Mastering Display Metadata, has_primaries:1 has_luminance:1 r(0.7080,0.2920) g(0.1700,0.7970) b(0.1310 0.0460) wp(0.3127, 0.3290) min_luminance=0.00, max_luminance=1000.00 Content Light Level Metadata, MaxCLL=1000, MaxFALL=300 Stream mapping: Stream #0:0 -> #0:0 (hevc (native) -> hevc (hevc_amf)) [trace_headers @ 0226a49c4a80] Extradata [trace_headers @ 0226a49c4a80] Sequence Parameter Set [trace_headers @ 0226a49c4a80] 0 forbidden_zero_bit 0 = 0 [trace_headers @ 0226a49c4a80] 1 nal_unit_type 11 = 33 [trace_headers @ 0226a49c4a80] 7 nuh_layer_id 00 = 0 [trace_headers @ 0226a49c4a80] 13 nuh_temporal_id_plus1 001 = 1 [trace_headers @ 0226a49c4a80] 16 sps_video_parameter_set_id = 0 [trace_headers @ 0226a49c4a80] 20 sps_max_sub_layers_minus1 000 = 0 [trace_headers @ 0226a49c4a80] 23 sps_temporal_id_nesting_flag 1 = 1 [trace_headers @ 0226a49c4a80] 24 general_profile_space 00 = 0 [trace_headers @ 0226a49c4a80] 26 general_tier_flag 0 = 0 [trace_headers @ 0226a49c4a80] 27 general_profile_idc 1 = 1 [trace_headers @ 0226a49c4a80] 32 general_profile_compatibility_flag[0] 0 = 0 [trace_headers @ 0226a49c4a80] 33 general_profile_compatibility_flag[1] 1 = 1 [trace_headers @ 0226a49c4a80] 34 general_profile_compatibility_flag[2] 1 = 1 [trace_headers @ 0226a49c4a80] 35 general_profile_compatibility_flag[3] 0 = 0 [trace_headers @ 0226a49c4a80] 36 general_profile_compatibility_flag[4] 0 = 0 [trace_headers @ 0226a49c4a80] 37 general_profile_compatibility_flag[5] 0 = 0 [trace_headers @ 0226a49c4a80] 38 general_profile_compatibility_flag[6] 0 = 0 [trace_headers @ 0226a49c4a80] 39 general_profile_compatibility_flag[7] 0 = 0 [trace_headers @ 0226a49c4a80] 40 general_profile_compatibility_flag[8] 0 = 0 [trace_headers @ 0226a49c4a80] 41 general_profile_compatibility_flag[9] 0 = 0 [trace_headers @ 0226a49c4a80] 42 general_profile_compatibility_flag[10] 0 = 0 [trace_headers @ 0226a49c4a80] 43 general_profile_compatibility_flag[11] 0 = 0 [trace_headers @ 0226a49c4a80] 44 general_profile_compatibility_flag[12] 0 = 0 [trace_headers @ 0226a49c4a80] 45 general_profile_compatibility_flag[13] 0 = 0 [trace_headers @ 0226a49c4a80] 46 general_profile_compatibility_flag[14] 0 = 0 [trace_headers @ 0226a49c4a80] 47 general_profile_compatibility_flag[15] 0 = 0 [trace_headers @ 0226a49c4a80] 48 general_profile_compatibility_flag[16] 0 = 0 [trace_headers @ 0226a49c4a80] 49 general_profile_compatibility_flag[17] 0 = 0 [trace_headers @ 0226a49c4a80] 50 general_profile_compatibility_flag[18] 0 = 0 [trace_headers @ 0226a49c4a80] 51 general_profile_compatibility_flag[19] 0 = 0 [trace_headers @ 0226a49c4a80] 52 general_profile_compatibility_flag[20] 0 = 0 [trace_headers @ 0226a49c4a80] 53 general_profile_compatibility_flag[21] 0 = 0 [trace_headers @ 0226a49c4a80] 54 general_profile_compatibility_flag[22] 0 = 0 [trace_headers @ 0226a49c4a80] 55 general_profile_compatibility_flag[23] 0 = 0
Re: [FFmpeg-devel] [PATCH 02/13] fftools/ffmpeg_filter: make sub2video heartbeat more robust
Quoting Nicolas George (2023-11-27 10:40:18) > Anton Khirnov (12023-11-23): > > Avoid making decisions based on current graph input state, which makes > > the output dependent on the order in which the frames from different > > inputs are interleaved. > > > > Makes the output of fate-filter-overlay-dvdsub-2397 more correct - the > > subtitle appears two frames later, which is closer to its PTS as stored > > in the file. > > --- > > fftools/ffmpeg_filter.c | 3 +-- > > tests/ref/fate/filter-overlay-dvdsub-2397 | 4 ++-- > > tests/ref/fate/sub2video | 8 +--- > > 3 files changed, 8 insertions(+), 7 deletions(-) > > Just as I warned you, it breaks the test case I suggested: > > ./ffmpeg_g -xerror -i /tmp/dummy_with_sub.mkv -preset ultrafast -lavfi > '[0:s]setpts=PTS+60/TB[s] ; [0:v][s]overlay' -y /tmp/dummy_with_hardsub.mkv > > (/tmp/dummy_with_sub.mkv is created like I told a few days ago) > thousands of frame queued, eventually failing on OOM. You're offsetting two streams from the same file by 60 seconds, so you should expect about 60s of buffering - that is 1500 frames at 25fps. The maximum amount of frames I see buffered is 1602, which roughly corresponds to the expected number. So I don't think this demonstrates there actually is a problem. Also note that the output timestamps look better after the patch than before. -- 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] lavc/hevcdsp_qpel_neon: using movi.16b instead of movi.2d
Thank you for your reading and explaining carefully, Martin. Yes, you are right. I build with iOS 13.0, and FFmpeg 6.0. It seems that there is no ".arch" directive in asm.S. That is to say, it isn't a newest version. --Original-- From: "FFmpeg development discussions and patches" https://github.com/llvm/llvm-project/commit/9097a07e4e83b9f394598d53557247277b064b09.) Anyway, the change looks good, so I'll push it. // Martin ___ 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".
