Re: [FFmpeg-devel] [PATCH v2 2/3] fftools/opt_common: add timing and datetiming log flags
Hi Michael, thanks a lot for looking at this. > -Original Message- > From: ffmpeg-devel On Behalf Of > Michael Niedermayer > Sent: Sunday, February 2, 2025 2:14 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v2 2/3] fftools/opt_common: add > timing and datetiming log flags > > Hi softworkz > > On Thu, Jan 30, 2025 at 03:53:25AM +, softworkz wrote: > > From: softworkz > > > > This commit adds two logging flags: 'timing' and 'datetiming'. > > > > Usage: > > > > ffmpeg -loglevel +timing > > > > or > > > > ffmpeg -loglevel +datetiming > > > ./ffmpeg -loglevel +timing > ... > 02:04:00.926 Use -h to get full help or, even better, run 'man > ffmpeg' > 02:04:00.926 michael@box:~/ffmpeg/$ > > It seems the shell command prompt is after the last time > is this intended ? Of course not 😊 Where it's in use, I had also added printing of the word "EXIT" before exiting (to easily recognize crashed or killed vs regular terminations), that's probably why I've never seen this. Will submit an update, thank you very much, sw ___ 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] Democratization work in progress draft v2
On 1/31/25 11:01 AM, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of James Almer Sent: Friday, January 31, 2025 4:45 PM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] Democratization work in progress draft v2 Past involvement, including long-past involvement, is not only past, it is both indication of knowledge about the project and prediction of future involvement. For that reason, I believe that if this plan goes forward, it should include all past involvement, but possibly with the condition that the involvement continues presently. How about a quadratic attenuation of past commit counts, so that older commits count less than more recent ones? Such quadratic metrics tend to be such that for currently active contributors, it roughly correlates with square root of commit count (which is an increasing function) and therefore isn't meaningfully different. A similar thing was discovered in the N-papers-cited-N-times-each metric which was popular at one point in academia as an alternative to citation count. It turned out to maximize the area of an axis-bounded square when contributions were plotted, which is why for naturally occurring data it correlated pretty well with the square root of total citation count. While this isn't an entirely analogous situation, most contributors who are active have been active since they started contributing, so this doesn't do a whole lot except to pick out people who used to be active and then stopped and then started up again. - Leo Izen (Traneptora) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: add a simple ffv1 parser
On 01/02/2025 15:48, James Almer wrote:
Only setting key frames.
Signed-off-by: James Almer
---
configure| 1 +
libavcodec/Makefile | 1 +
libavcodec/ffv1_parser.c | 45
libavcodec/parsers.c | 1 +
4 files changed, 48 insertions(+)
create mode 100644 libavcodec/ffv1_parser.c
diff --git a/configure b/configure
index 06f641ead0..f09faaf505 100755
--- a/configure
+++ b/configure
@@ -3469,6 +3469,7 @@ vvc_qsv_decoder_select="vvc_mp4toannexb_bsf qsvdec"
aac_parser_select="adts_header mpeg4audio"
av1_parser_select="cbs_av1"
evc_parser_select="evcparse"
+ffv1_parser_select="rangecoder"
ftr_parser_select="adts_header mpeg4audio"
h264_parser_select="golomb h264dsp h264parse h264_sei"
hevc_parser_select="hevcparse hevc_sei"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a3ef11a258..1df595d58f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1207,6 +1207,7 @@ OBJS-$(CONFIG_DVBSUB_PARSER) += dvbsub_parser.o
OBJS-$(CONFIG_DVD_NAV_PARSER) += dvd_nav_parser.o
OBJS-$(CONFIG_DVDSUB_PARSER) += dvdsub_parser.o
OBJS-$(CONFIG_EVC_PARSER) += evc_parser.o
+OBJS-$(CONFIG_FFV1_PARSER) += ffv1_parser.o
OBJS-$(CONFIG_FLAC_PARSER) += flac_parser.o flacdata.o flac.o
OBJS-$(CONFIG_FTR_PARSER) += ftr_parser.o
OBJS-$(CONFIG_G723_1_PARSER) += g723_1_parser.o
diff --git a/libavcodec/ffv1_parser.c b/libavcodec/ffv1_parser.c
new file mode 100644
index 00..f9fd1152d0
--- /dev/null
+++ b/libavcodec/ffv1_parser.c
@@ -0,0 +1,45 @@
+/*
+ * 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
+ */
+
+#include "avcodec.h"
+#include "rangecoder.h"
+
+static int parse(AVCodecParserContext *s,
+ AVCodecContext *avctx,
+ const uint8_t **poutbuf, int *poutbuf_size,
+ const uint8_t *buf, int buf_size)
+{
+RangeCoder c;
+uint8_t keystate = 128;
+ff_init_range_decoder(&c, buf, buf_size);
+ff_build_rac_states(&c, 0.05 * (1LL << 32), 256 - 8);
+
+*poutbuf = buf;
+*poutbuf_size = buf_size;
+s->key_frame = get_rac(&c, &keystate);
+s->pict_type = AV_PICTURE_TYPE_I; //FIXME I vs. P, see ffv1dec.c
+s->field_order = AV_FIELD_UNKNOWN;
+s->picture_structure = AV_PICTURE_STRUCTURE_UNKNOWN;
+
+return buf_size;
You should consider exposing expose read_header() from ffv1dec.c, or
maybe decode_header(), which would give you everything else.
This patch would also help with hardware decoding, as a software decoder
wouldn't be spun up during probing.
OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital 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 2/2] doc/filters: Remove redundant *_cuda and *_npp filters since they are already in CUDA Video Filters section
On 2025-01-29 12:42 am, Danil Iashchenko wrote:
---
doc/filters.texi | 630 +--
1 file changed, 10 insertions(+), 620 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index c4f312d2b8..28be8920fd 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8619,45 +8619,6 @@ Set planes to filter. Default is first only.
This filter supports the all above options as @ref{commands}.
The removal should happen together with the shifting.
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] Democratization work in progress draft v2
On Sun, Feb 2, 2025 at 3:26 AM Leo Izen wrote: > While this isn't an entirely analogous situation, most contributors who > are active have been active since they started contributing, so this > doesn't do a whole lot except to pick out people who used to be active > and then stopped and then started up again. > I'd assume that's exactly the point, in this way a lot of uninformed people can come back from the past and they can be more easily manipulated to sway the community opinion or directly skew the vote, without having any idea what they are talking about. It's the same stuff that happened in mplayer days, same old same old. -- Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Democratization
On Sat, 1 Feb 2025, 14:46 Michael Niedermayer, wrote: > Hi > > On Wed, Jan 29, 2025 at 10:21:37PM +0100, Niklas Haas wrote: > > On Wed, 29 Jan 2025 21:51:27 +0100 Nicolas George > wrote: > > > Niklas Haas (12025-01-29): > [...] > > > > *Some members* of > > > what you call community have expressed violent opposition to Michael. > > > But *other members* have expressed, support for Michael, yet other > > > members have agreed to arguments on both side successively, and the > > > majority have not expressed anything. > > > > The CC was elected by a majority of the GA, so for all intents and > purposes, > > the CC is the closest representation of the majority opinion as we are > > likely to ever have. > > 1. The GA does not represent the community > 2. The GA is vulnerable to a simple governance attack > 3. The CC vote period was extended by the person running the vote while he > asked >specific people to join. > 4. from the small number of people supporting the GA system origianlly >several changed their mind (both me and nicolas for example liked the >GA idea originally IIRC) also paul opposed it publically immedeatly >when it was announced many years ago > > We can easily have something better > > The community is thousands of people not just 49 > > thx > Hi Michael, How are you not subject to a one-person "governance attack"? Kieran > ___ 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] Democratization
Hi On Sat, Feb 01, 2025 at 02:48:51PM +, Kieran Kunhya via ffmpeg-devel wrote: > On Sat, 1 Feb 2025, 14:46 Michael Niedermayer, > wrote: > > > Hi > > > > On Wed, Jan 29, 2025 at 10:21:37PM +0100, Niklas Haas wrote: > > > On Wed, 29 Jan 2025 21:51:27 +0100 Nicolas George > > wrote: > > > > Niklas Haas (12025-01-29): > > [...] > > > > > > *Some members* of > > > > what you call community have expressed violent opposition to Michael. > > > > But *other members* have expressed, support for Michael, yet other > > > > members have agreed to arguments on both side successively, and the > > > > majority have not expressed anything. > > > > > > The CC was elected by a majority of the GA, so for all intents and > > purposes, > > > the CC is the closest representation of the majority opinion as we are > > > likely to ever have. > > > > 1. The GA does not represent the community > > 2. The GA is vulnerable to a simple governance attack > > 3. The CC vote period was extended by the person running the vote while he > > asked > >specific people to join. > > 4. from the small number of people supporting the GA system origianlly > >several changed their mind (both me and nicolas for example liked the > >GA idea originally IIRC) also paul opposed it publically immedeatly > >when it was announced many years ago > > > > We can easily have something better > > > > The community is thousands of people not just 49 > > > > thx > > > > Hi Michael, > > How are you not subject to a one-person "governance attack"? I hate kim jong un thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway 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] FOSDEM meeting
No idea if you wanted to send something other than a jpg, but the link (as shared on #ffmpeg-devel) is https://meet.jit.si/ffmpeg_meeting OpenPGP_signature.asc Description: OpenPGP digital 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".
[FFmpeg-devel] [PATCH] avcodec: add a simple ffv1 parser
Only setting key frames.
Signed-off-by: James Almer
---
configure| 1 +
libavcodec/Makefile | 1 +
libavcodec/ffv1_parser.c | 45
libavcodec/parsers.c | 1 +
4 files changed, 48 insertions(+)
create mode 100644 libavcodec/ffv1_parser.c
diff --git a/configure b/configure
index 06f641ead0..f09faaf505 100755
--- a/configure
+++ b/configure
@@ -3469,6 +3469,7 @@ vvc_qsv_decoder_select="vvc_mp4toannexb_bsf qsvdec"
aac_parser_select="adts_header mpeg4audio"
av1_parser_select="cbs_av1"
evc_parser_select="evcparse"
+ffv1_parser_select="rangecoder"
ftr_parser_select="adts_header mpeg4audio"
h264_parser_select="golomb h264dsp h264parse h264_sei"
hevc_parser_select="hevcparse hevc_sei"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a3ef11a258..1df595d58f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1207,6 +1207,7 @@ OBJS-$(CONFIG_DVBSUB_PARSER) += dvbsub_parser.o
OBJS-$(CONFIG_DVD_NAV_PARSER) += dvd_nav_parser.o
OBJS-$(CONFIG_DVDSUB_PARSER) += dvdsub_parser.o
OBJS-$(CONFIG_EVC_PARSER) += evc_parser.o
+OBJS-$(CONFIG_FFV1_PARSER) += ffv1_parser.o
OBJS-$(CONFIG_FLAC_PARSER) += flac_parser.o flacdata.o flac.o
OBJS-$(CONFIG_FTR_PARSER) += ftr_parser.o
OBJS-$(CONFIG_G723_1_PARSER) += g723_1_parser.o
diff --git a/libavcodec/ffv1_parser.c b/libavcodec/ffv1_parser.c
new file mode 100644
index 00..f9fd1152d0
--- /dev/null
+++ b/libavcodec/ffv1_parser.c
@@ -0,0 +1,45 @@
+/*
+ * 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
+ */
+
+#include "avcodec.h"
+#include "rangecoder.h"
+
+static int parse(AVCodecParserContext *s,
+ AVCodecContext *avctx,
+ const uint8_t **poutbuf, int *poutbuf_size,
+ const uint8_t *buf, int buf_size)
+{
+RangeCoder c;
+uint8_t keystate = 128;
+ff_init_range_decoder(&c, buf, buf_size);
+ff_build_rac_states(&c, 0.05 * (1LL << 32), 256 - 8);
+
+*poutbuf = buf;
+*poutbuf_size = buf_size;
+s->key_frame = get_rac(&c, &keystate);
+s->pict_type = AV_PICTURE_TYPE_I; //FIXME I vs. P, see ffv1dec.c
+s->field_order = AV_FIELD_UNKNOWN;
+s->picture_structure = AV_PICTURE_STRUCTURE_UNKNOWN;
+
+return buf_size;
+}
+
+const AVCodecParser ff_ffv1_parser = {
+.codec_ids= { AV_CODEC_ID_FFV1 },
+.parser_parse = parse,
+};
diff --git a/libavcodec/parsers.c b/libavcodec/parsers.c
index 8bfd2dbce0..5387351fd0 100644
--- a/libavcodec/parsers.c
+++ b/libavcodec/parsers.c
@@ -45,6 +45,7 @@ extern const AVCodecParser ff_dvd_nav_parser;
extern const AVCodecParser ff_evc_parser;
extern const AVCodecParser ff_flac_parser;
extern const AVCodecParser ff_ftr_parser;
+extern const AVCodecParser ff_ffv1_parser;
extern const AVCodecParser ff_g723_1_parser;
extern const AVCodecParser ff_g729_parser;
extern const AVCodecParser ff_gif_parser;
--
2.48.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] Democratization
Hi On Wed, Jan 29, 2025 at 10:21:37PM +0100, Niklas Haas wrote: > On Wed, 29 Jan 2025 21:51:27 +0100 Nicolas George wrote: > > Niklas Haas (12025-01-29): [...] > > *Some members* of > > what you call community have expressed violent opposition to Michael. > > But *other members* have expressed, support for Michael, yet other > > members have agreed to arguments on both side successively, and the > > majority have not expressed anything. > > The CC was elected by a majority of the GA, so for all intents and purposes, > the CC is the closest representation of the majority opinion as we are > likely to ever have. 1. The GA does not represent the community 2. The GA is vulnerable to a simple governance attack 3. The CC vote period was extended by the person running the vote while he asked specific people to join. 4. from the small number of people supporting the GA system origianlly several changed their mind (both me and nicolas for example liked the GA idea originally IIRC) also paul opposed it publically immedeatly when it was announced many years ago We can easily have something better The community is thousands of people not just 49 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. 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] Democratization work in progress draft v2
Hi Michael, On Sat, 1 Feb 2025, 22:27 Michael Niedermayer, wrote: > > Lets be carefull here with the words. But the awnser is "yes" > Many developers have been paid to write commits. employees, contractors, > students > As an FFlabs employee (which I believe is the biggest GA cohort) and shareholder are you aware of anyone in your company instructing people to vote a certain way? Kieran ___ 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] Democratization work in progress draft v2
Hi James On Sat, Feb 01, 2025 at 10:30:21AM -0300, James Almer wrote: > On 1/31/2025 9:49 PM, Michael Niedermayer wrote: [...] > > > > > > > has worked. Changing it now because one person was unhappy with a CC (That > > > > This is a false statement. Iam not suggesting a change to the GA because of > > one CC > > iam suggesting a change because it is vulnerable to an attack. > > > > (The CC isnt even fixed by this, i think the concept of a CC elected out of > > a > > community thats full of mutual hate is a bad idea) > > > > But back to the topic, what do you suggest to fix the vulerability in the > > GA ? > > Or you dont care? > > Why do you say there's a vulnerability in the GA? The FAQ describes how to exploit it. And i belive others independantly found this issue as well. > Has it been exploited for Given the nature of this vulerability, its very hard to detect it being exploited > this to be an issue? While active eploitation, certainly makes an issue worse. In general and especially when exploitation is not detectable, this is something we cannot wait for > Did someone to your knowledge buy a developer to write > 20 commits and get them into the GA? Lets be carefull here with the words. But the awnser is "yes" Many developers have been paid to write commits. employees, contractors, students Do i know of someone being asked after that to vote in a specific way ? No, how could i know other peoples private communication Have people asked me how/if they should vote ? Yes, some people did ask. In general "few time" outside contributors being payed to do some work dont care about the votes, they come, do some work and leave. I would expect the random subscriber of 2000 on ffmpeg-devel to care more as they follow the list for a long term they care more about the consequences > Otherwise, you're making a big deal out > of an hypothetical, and that's really damaging to the project. > > I don't know if you realize, but you're being incredibly disrespectful with > almost everyone who has contributed anything in the last decade, treating > them as moles trying to bring down the project instead of contributing to > its success. I would appreciate if you keep this emotional drama out. We need to look with a clear head at this. Noone is disrespectful to people using ssh if ssh is vulnerable. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad 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] FOSDEM meeting
Sent from my iPhone > On Feb 1, 2025, at 9:28 AM, Devin Heitmueller > wrote: > > On Sat, Jan 25, 2025, 11:09 PM Marth64 wrote: >> >> Hello, >> >> Looking forward to it. > > Has a time/location been set for this? Hi Devin, The FFMPEG meeting at FOSDEM will happen at 5pm CET at Chez Theo, past the coffee line. A remote meeting link will be provided here before the start time. Thanks Vittorio > Thanks, > > Devin > ___ > 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] Democratization work in progress draft v2
Sent from my iPhone > On Feb 1, 2025, at 3:11 PM, Jean-Baptiste Kempf wrote: > > Hello, > >> On Sat, 1 Feb 2025, at 07:45, Zhao Zhili wrote: >> The proposal treat every GA member as suspect, and GA members with >> daily jobs guilty. >> >> The community should be based on trust and everyone should be trust >> equally, > > +1 > >> It’s dangerous to fix the vulnerability in the GA by make GA totally >> under control, which > > I agree with you Zhao, and everything you said. +1 here too ofc Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Democratization work in progress draft v2
Sent from my iPhone > On Feb 1, 2025, at 2:21 PM, Ronald S. Bultje wrote: > > Hi, > >> On Sat, Feb 1, 2025 at 1:45 AM Zhao Zhili < >> quinkblack-at-foxmail@ffmpeg.org> wrote: >> >> The proposal treat every GA member as suspect, and GA members with daily >> jobs guilty. > > > Thank you for saying this. I couldn't agree more. +1 Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Democratization work in progress draft v2
Hi James On Sat, Feb 01, 2025 at 10:30:21AM -0300, James Almer wrote: > On 1/31/2025 9:49 PM, Michael Niedermayer wrote: > > Hi James > > > > On Fri, Jan 31, 2025 at 12:44:50PM -0300, James Almer wrote: > > > On 1/31/2025 11:58 AM, Nicolas George wrote: > > > > Niklas Haas (12025-01-30): > > [...] > > > > On the other hand, I believe this whole plan is a bad idea. > > > Yes, it is a bad idea. We have had the current system in place for about > > > five years now, and besides one or two CC assemblages being inefficient, > > > it > > > > Do you remember this suggested addition to the FAQ ? > > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-January/338186.html > > > > It seems you dont remember it even though this was posted just a few days > > ago > > I knew this is needed to be put in the FAQ ;( > > I saw it, and i think that patch is anything but objective and completely > unacceptable. You're stating your opinion and discrediting a system in an > official document in the project's repository itself of all places. Do you > not see how absurd that is? The system is absurd, the text points this out in a mocking/ironic way. If you want me to reword this in a dry formal way, i can submit such a patch? If not, how do you suggest we move forward here ? We can replace the GA by a system that is not vulnerable We can treat the GA more as guidance and not a final authority We can publish the issue and warn our users and leave it vulnerable We can try to block every choice, and treat this like any "publish after 90day" security issue (ffmpeg community refuses to fix or publish) will reply to the 2nd part seperately thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire 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] libswresample/rematrix.c sane_layout
On Wed, Jan 29, 2025 at 8:29 PM Pavel Koshevoy wrote: > Hi, > > I have a file which I can't down-mix to stereo due to > AV_CHANNEL_ORDER_NATIVE requirement in sane_layout. > > ``` > $ ffmpeg -i COMMUNITY_HERO_2.mov -vn -af > 'aformat=sample_rates=48000:channel_layouts=stereo' -y /tmp/out.wav > ffmpeg version N-118381-g4ba9ae7742 Copyright (c) 2000-2025 the FFmpeg > developers > built with gcc 7 (SUSE Linux) > configuration: --prefix=/Developer/x86_64 --prefix=/Developer/x86_64 > --enable-runtime-cpudetect --enable-libzimg --enable-libx264 > --enable-libass --enable-libmodplug --enable-libxml2 --enable-libvmaf > --enable-shared --enable-pthreads --enable-gpl --enable-version3 > --enable-gnutls --enable-libfreetype --enable-pic --disable-static > --enable-shared --enable-rpath --enable-ffnvcodec --enable-debug > --disable-stripping --disable-optimizations --disable-mmx > libavutil 59. 56.100 / 59. 56.100 > libavcodec 61. 31.101 / 61. 31.101 > libavformat61. 9.106 / 61. 9.106 > libavdevice61. 4.100 / 61. 4.100 > libavfilter10. 9.100 / 10. 9.100 > libswscale 8. 13.100 / 8. 13.100 > libswresample 5. 4.100 / 5. 4.100 > libpostproc58. 4.100 / 58. 4.100 > Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'COMMUNITY_HERO_2.mov': > Metadata: > major_brand : qt > minor_version : 512 > compatible_brands: qt > encoder : Lavf58.29.100 > Duration: 00:02:02.86, start: 0.00, bitrate: 97805 kb/s > Stream #0:0[0x1]: Video: prores (LT) (apcs / 0x73637061), > yuv422p10le(top first), 1920x1080, 88583 kb/s, SAR 1:1 DAR 16:9, 29.97 fps, > 29.97 tbr, 30k tbn (default) > Metadata: > handler_name: VideoHandler > vendor_id : FFMP > encoder : Lavc58.54.100 prores > timecode: 14:25:46;28 > Stream #0:1[0x2]: Audio: pcm_s24le (in24 / 0x34326E69), 48000 Hz, 8 > channels (FL+FR+FC+LFE+SL+SR+BL+BR), s32 (24 bit), 9216 kb/s (default) > Metadata: > handler_name: SoundHandler > vendor_id : [0][0][0][0] > Stream #0:2[0x3](eng): Data: none (tmcd / 0x64636D74) > Metadata: > handler_name: TimeCodeHandler > timecode: 14:25:46;28 > Stream mapping: > Stream #0:1 -> #0:0 (pcm_s24le (native) -> pcm_s16le (native)) > Press [q] to stop, [?] for help > [auto_aresample_0 @ 0x7ff5bc004900] [SWR @ 0x7ff5bc0049f0] Input channel > layout '8 channels (FL+FR+FC+LFE+SL+SR+BL+BR)' is not supported > [auto_aresample_0 @ 0x7ff5bc004900] Failed to configure output pad on > auto_aresample_0 > [af#0:0 @ 0x21841830] Error reinitializing filters! > [af#0:0 @ 0x21841830] Task finished with error code: -22 (Invalid argument) > [af#0:0 @ 0x21841830] Terminating thread with return code -22 (Invalid > argument) > [aost#0:0/pcm_s16le @ 0x218412b0] [enc:pcm_s16le @ 0x21841770] Could not > open encoder before EOF > [aost#0:0/pcm_s16le @ 0x218412b0] Task finished with error code: -22 > (Invalid argument) > [aost#0:0/pcm_s16le @ 0x218412b0] Terminating thread with return code -22 > (Invalid argument) > [out#0/wav @ 0x21840b80] Nothing was written into output file, because at > least one of its streams received no packets. > size= 0KiB time=N/A bitrate=N/A speed=N/A > Conversion failed! > ``` > > If I remove 2 lines from sane_layout then I am able to process this file > successfully. > However IDK the implications of this change. > In any case, I'm attaching the patch here, and hopefully someone more > knowledgeable can come up with a more appropriate fix. > > > Just want to mention that this issue does not exist on release/6.1 branch, so it's probably a regressions introduced in ffmpeg 7+ ___ 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] Democratization work in progress draft v2
Hi Nicolas On Sat, Feb 01, 2025 at 09:44:50PM +0100, Nicolas George wrote: > Michael Niedermayer (12025-01-29): > > Hi all > > > > Heres my current "work in progress": (sending that before fosdem, so people > > can discuss if they like) > > Counter-proposal: > > By any sane measure of merit towards the project you would get more > votes than anybody else, that makes no sense. So, instead, you get 0 > vote because you do not take part in the votes, you organize them. > > You are officially the leader of the project, and as such the arbiter of > consensus among the community. You hold that role preferably by judging > the arguments, or more frequently by delegating that task to > maintainers, but if the arguments fail to convince, you can decide to > hold a vote. > > You decide on the voting body and the weight of each voter according to > the merit criteria of your choice. You do not make them public so as not > to trigger Goodhart's law. You should experiment with variations on the > criteria and see if they lead to a significant difference in result, and > see which variation most match your subjective assessment of people's > merit. > > The votes are public. Mandatory secrecy is not possible with online > votes and voluntary secrecy is not important in this case. > > People have to trust you about the results. If they do not trust the > leader, they can work on something else. > > You are free to delegate any of these tasks in order to be able to focus > on more interesting things. > > Peace on the mailing-list is also your duty as leader and arbiter of the > consensus among the community. You should delegate that duty to a team > of trusted moderators, same as maintainers. You can seek consensus to > choose them, using a vote if necessary. This is an interresting proposal. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- 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] checkasm: aacencdsp: Actually initialize ff_aac_pow34sf_tab
On Wed, Jan 29, 2025 at 11:58:54AM +0200, Martin Storsjö wrote: > This table is zero initialized by default, and has to be > explicitly initialized. > > Coincidentally, this fixes linking checkasm with Apple's older > linker. (In Xcode 15, Apple switched to a new linker. The one in > older toolchains seems to have a bug where it won't figure out to > load object files from a static library, if the only symbol > referenced in the object file is a "common" symbol, i.e. one for > a zero-initialized variable. This issue can also be reproduced with > newer Apple toolchains by passing -Wl,-ld_classic to the linker.) > --- > tests/checkasm/aacencdsp.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) this sometimes fails make -j32 fate-checkasm-aacencdsp TESTcheckasm-aacencdsp make -j32 fate-checkasm-aacencdsp TESTcheckasm-aacencdsp Test checkasm-aacencdsp failed. Look at tests/data/fate/checkasm-aacencdsp.err for details. make: *** [tests/Makefile:311: fate-checkasm-aacencdsp] Error 1 checkasm: using random seed 3314560428 SSE: - aacencdsp.abs_pow34 [OK] SSE2: quant_bands_signed_sse2 (aacencdsp.c:94) - aacencdsp.quant_bands [FAILED] AVX: - aacencdsp.quant_bands [OK] checkasm: 1 of 5 tests have failed threads=1 make: *** [tests/Makefile:311: fate-checkasm-aacencdsp] Error 1 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope 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".
[FFmpeg-devel] [PATCH] avfilter/avfilter: remove accidental loop index variable reset
Fixes ticket #11442.
Signed-off-by: James Almer
---
libavfilter/avfilter.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index 89b39445e6..e732556ffa 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -382,9 +382,9 @@ int ff_filter_config_links(AVFilterContext *filter)
/* Copy side data before link->srcpad->config_props() is called,
so the filter
* may remove it for the next filter in the chain */
if (inlink && inlink->nb_side_data && !link->nb_side_data) {
-for (i = 0; i < inlink->nb_side_data; i++) {
+for (int j = 0; j < inlink->nb_side_data; j++) {
ret = av_frame_side_data_clone(&link->side_data,
&link->nb_side_data,
- inlink->side_data[i], 0);
+ inlink->side_data[j], 0);
if (ret < 0) {
av_frame_side_data_free(&link->side_data,
&link->nb_side_data);
return ret;
--
2.48.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] avfilter/vf_scale: remove global side data when it no longer applies after scaling
Signed-off-by: James Almer
---
libavfilter/vf_scale.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 14ce1fbbd8..72618ec331 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -684,6 +684,16 @@ static int config_props(AVFilterLink *outlink)
flags_val);
av_freep(&flags_val);
+if (inlink->w != outlink->w || inlink->h != outlink->h) {
+av_frame_side_data_remove_by_props(&outlink->side_data,
&outlink->nb_side_data,
+ AV_SIDE_DATA_PROP_SIZE_DEPENDENT);
+}
+
+if (scale->in_primaries != scale->out_primaries || scale->in_transfer !=
scale->out_transfer) {
+av_frame_side_data_remove_by_props(&outlink->side_data,
&outlink->nb_side_data,
+ AV_SIDE_DATA_PROP_COLOR_DEPENDENT);
+}
+
if (!IS_SCALE2REF(ctx)) {
ff_framesync_uninit(&scale->fs);
ret = ff_framesync_init(&scale->fs, ctx, ctx->nb_inputs);
--
2.48.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libxvid: add check for invalid intra/inter matrix values
On Sat, 25 Jan 2025, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavcodec/libxvid.c | 4
1 file changed, 4 insertions(+)
Will apply.
Regards,
Marton
diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
index fbd33b7065..850e691403 100644
--- a/libavcodec/libxvid.c
+++ b/libavcodec/libxvid.c
@@ -617,6 +617,10 @@ static av_cold int xvid_encode_init(AVCodecContext *avctx)
x->intra_matrix =
x->inter_matrix = NULL;
+ret = ff_check_codec_matrices(avctx, FF_MATRIX_TYPE_INTRA |
FF_MATRIX_TYPE_INTER, 1, 255);
+if (ret < 0)
+return ret;
+
if (x->mpeg_quant)
x->vol_flags |= XVID_VOL_MPEGQUANT;
if ((avctx->intra_matrix || avctx->inter_matrix)) {
--
2.43.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] Democratization
James Almer (12025-02-01): > It does by definition. A definition is not an argument by itself. A definition is a way for people to speak the same language when they state their arguments. Multiple people have said that we do not agree with that definition. > >(both me and nicolas for example liked the > > GA idea originally IIRC) also paul opposed it publically immedeatly YRC > And why did you stop liking the idea? When I realized that it gives the most power to the very people who have tried to take over the project. > As it's been said before, proposing to change a system because you were not > satisfied with the current one sets a bad precedent, and signals you're ok > with a democratic system as long as it's to your liking, not as long as it's > agreed by the people participating in it. It is exactly as it is, I only wish Michael would dare stating it as it is: “I am still the leader of this project, appointed to carry the legacy, and democracy is happening under my supervision. The way we have implemented it is not working, so I am changing it. Preferably with general approval.” > How many times are you going to repeat this? Thousands of registered emails > in a mailing list (of which a bunch are removed for excessive bouncing > almost daily) is not thousands of people active in a community. Users are part of the FFmpeg community too. That make millions of people, possibly billions. Do we give users a say in the future of the project? Yes, we do! If a user suggests an interesting feature, one of us may decide to implement it. It has happened many times. Do we give users a vote in the future of the project? Of course not. Many users ask for features because they misunderstand the correct way of achieving their goal. We will not implement those features just because they are many. The point: a user has a say in the future of the project in as much the suggestions of that users have merit. Merit: remember that word. > Those 49 are people that have kept the project alive and progressing for at > least the last five years. So these 49 people have done more for the project than the people who have contributed just one or two patches in all? You are saying that the condition to have a vote that you approve is based on the level of merit of contributors towards the project. I believe that you just admitted that FFmpeg is and should be not a democracy but a meritocracy. Excellent. Now we can discuss how to do it properly, because everybody equal until an arbitrary cutoff is one of the stupidest meritocracy conceivable. -- 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] Democratization
Michael Niedermayer (12025-02-01): > * The CC is fundamentally broken The TC is even more fundamentally broken. 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] [PATCH 1/2] avformat/hls: .ts is always ok even if its a mov/mp4
On Fri, Jan 31, 2025 at 11:01:34PM +0100, Michael Niedermayer wrote: > Maybe fixes: 11435 > > Signed-off-by: Michael Niedermayer > --- > libavformat/hls.c | 4 > 1 file changed, 4 insertions(+) will apply patchset as it seems this fixes the issue according to the ticket [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Give a rich man 100$ and he will turn it into 1000$. Give a poor man 1000$ and he will spend it. 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/xpsnr: avoid division by zero
On 2025-01-28 03:18 pm, Gyan Doshi wrote: On 2025-01-28 01:44 am, Jan Ekström wrote: On Mon, Jan 27, 2025 at 9:23 PM Marton Balint wrote: On Mon, 27 Jan 2025, Gyan Doshi wrote: The ref input may have its frame rate unset, which would then lead to SIGFPE. Related to #11428 --- libavfilter/vf_xpsnr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavfilter/vf_xpsnr.c b/libavfilter/vf_xpsnr.c index 1b2c2a7c2c..8f86c188c5 100644 --- a/libavfilter/vf_xpsnr.c +++ b/libavfilter/vf_xpsnr.c @@ -568,7 +568,8 @@ static int config_input_ref(AVFilterLink *inlink) s->max_error_64 = (1 << s->depth) - 1; /* conventional limit */ s->max_error_64 *= s->max_error_64; - s->frame_rate = il->frame_rate.num / il->frame_rate.den; + // Avoid division by zero + s->frame_rate = il->frame_rate.den ? (il->frame_rate.num / il->frame_rate.den) : 25; I kind of prefer 0 instead of 25, as far as I see the code does not care, and 0 is better than an arbitrary value. I do agree with the sentiment, but I think at least for myself the real question is whether we should attempt to get "correct results" or not, and thus either fail if a frame rate is not properly set, or at the very least warn loudly that the results may be incorrect (interpreted as less than 32fps) if the fps value is left unset. Also I do wonder if we should utilize time base if frame rate is not set, as I see that 1/0 is utilized for "undefined/variable rate". Does PSNR expect an attributes match between the two inputs - resolution, framerate... ? If yes, then can we set it to the main input framerate. If that is unset, then we assume <32 and log a warning. I'll send a patch soon using the other inlink's rate unless someone has a better idea. 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] FOSDEM meeting
___ 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] Democratization
On Sat, 1 Feb 2025, 15:03 Michael Niedermayer, wrote: > Hi > > On Sat, Feb 01, 2025 at 02:48:51PM +, Kieran Kunhya via ffmpeg-devel > wrote: > > On Sat, 1 Feb 2025, 14:46 Michael Niedermayer, > > wrote: > > > > > Hi > > > > > > On Wed, Jan 29, 2025 at 10:21:37PM +0100, Niklas Haas wrote: > > > > On Wed, 29 Jan 2025 21:51:27 +0100 Nicolas George > > > wrote: > > > > > Niklas Haas (12025-01-29): > > > [...] > > > > > > > > *Some members* of > > > > > what you call community have expressed violent opposition to > Michael. > > > > > But *other members* have expressed, support for Michael, yet other > > > > > members have agreed to arguments on both side successively, and the > > > > > majority have not expressed anything. > > > > > > > > The CC was elected by a majority of the GA, so for all intents and > > > purposes, > > > > the CC is the closest representation of the majority opinion as we > are > > > > likely to ever have. > > > > > > 1. The GA does not represent the community > > > 2. The GA is vulnerable to a simple governance attack > > > 3. The CC vote period was extended by the person running the vote > while he > > > asked > > >specific people to join. > > > 4. from the small number of people supporting the GA system origianlly > > >several changed their mind (both me and nicolas for example liked > the > > >GA idea originally IIRC) also paul opposed it publically immedeatly > > >when it was announced many years ago > > > > > > We can easily have something better > > > > > > The community is thousands of people not just 49 > > > > > > thx > > > > > > > Hi Michael, > > > > How are you not subject to a one-person "governance attack"? > > I hate kim jong un > > thx > Interesting when you are questioned, the walls of text and paranoia stop. Kieran > ___ 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] Democratization work in progress draft v2
Michael Niedermayer (12025-01-29): > Hi all > > Heres my current "work in progress": (sending that before fosdem, so people > can discuss if they like) Counter-proposal: By any sane measure of merit towards the project you would get more votes than anybody else, that makes no sense. So, instead, you get 0 vote because you do not take part in the votes, you organize them. You are officially the leader of the project, and as such the arbiter of consensus among the community. You hold that role preferably by judging the arguments, or more frequently by delegating that task to maintainers, but if the arguments fail to convince, you can decide to hold a vote. You decide on the voting body and the weight of each voter according to the merit criteria of your choice. You do not make them public so as not to trigger Goodhart's law. You should experiment with variations on the criteria and see if they lead to a significant difference in result, and see which variation most match your subjective assessment of people's merit. The votes are public. Mandatory secrecy is not possible with online votes and voluntary secrecy is not important in this case. People have to trust you about the results. If they do not trust the leader, they can work on something else. You are free to delegate any of these tasks in order to be able to focus on more interesting things. Peace on the mailing-list is also your duty as leader and arbiter of the consensus among the community. You should delegate that duty to a team of trusted moderators, same as maintainers. You can seek consensus to choose them, using a vote if necessary. 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] Democratization
> -Original Message- > From: ffmpeg-devel On Behalf Of > Nicolas George > Sent: Saturday, February 1, 2025 9:21 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] Democratization > > Michael Niedermayer (12025-02-01): > > * The CC is fundamentally broken > > The TC is even more fundamentally broken. I agree to that and one of the reasons why I'm seeing it that way is that I wasn't able to make an informed decision when voting. There was just a list of names and for many of them I didn't really know what each candidate would stand for. So I made choices primarily based on whether I had good or bad experience with them in collaboration and communication - which is awful to use as criteria for such a voting. I'd rather vote for a candidate that I like less or I had been in disagreement with, if that person's goals and ideas align with mine - but how can I know? I might know for some but not for all of the candidates and I think similar applies to other members in the GA as well. Hence my suggestion to install certain "Positions", each with a certain area of responsibility and candidates who apply for a certain position would lay out their ideas, strategies, focus areas and what they are aiming to achieve within the period for which they get elected. This would allow to vote about directions for the project rather than just names of persons which you might not even know. sw ___ 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/9] Nvidia Video Codec SDK 13.0 support
On 30.01.2025 20:40, Timo Rothenpieler wrote: This series adds support for new features and capabilities added in todays release of the Video Codec SDK 13.0. Diego de Souza (7): avutil/hwcontext_cuda: add 4:2:2 pixel format support avcodec/nvdec: add 4:2:2 decoding and 10-bit support avcodec/cuviddec: add HEVC/H.264 4:2:2 and H.264 10-bit support avcodec/nvenc: add 4:2:2 encoding and H.264 10-bit support avcodec/nvenc: add UHQ to AV1 for NVENC avcodec/nvenc: add Temporal Filtering for AV1 and H.264 in NVENC avcodec/nvenc: add MV-HEVC encoding support Timo Rothenpieler (2): avcodec/nvenc: use encoder level options for qmin/qmax avcodec/nvenc: finalize SDK 13.0 support Will push this series minus the MV-HEVC patch tomorrow if nobody objects. ___ 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] Democratization
Hi Niklas On Wed, Jan 29, 2025 at 10:27:58PM +0100, Niklas Haas wrote: [...] > Michael is the current de-facto leader. It is literally impossible for me to > phrase it in any other way that does not unduly single him out as long as this > remains the status quo. In 2015 and before, i worked from waking up to going to bed on FFmpeg. Anything else i tried to delegate to someone else. During this time i called myself Leader or whatever term i used. Iam not doing that currently at all, iam NOT doing the job a leader should do. If the community by consensus or supermajority asks me to return as leader i may consider it. FFmpeg is run by the community, we atm have a simple consensus based process and whatever comes out of that is implemented. For code as well as non code. For a 2nd layer when consensus fails i proposed 2 voting processes one a flat democratic one and one a proportional one. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- 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] Democratization
I don't appreciate an inflammatory and accusatory email being sent privately, so I'll answer publicly. On 2/1/2025 12:26 PM, E-BLOKOS wrote: How much VIMEO paid you or vittorio to break Michael's work and rights? I don't work for Vimeo. I work for the same company currently employing Michael, of which he's a founder/shareholder. Since when one guy is talking for thousands (yes, and we are part of these silent thousands) No one person is talking for thousands... and in same time claiming "democracy"? we are fed up, sick and tired to receive in our email server ...except for you, it seems, seeing you're using "we". And are you subscribed to this mailing list for some specific reason? I don't think I've seen reviews or patches from you before. stupid kid behavior about a software that is open source and until now the first converter of the world in term of quality and popularity. So why change a winning method This is the question i and others are making. Asking for a change in governance suddenly because of a personal bad experience is not a good idea for the health of the project. if there is not some bad interests behind it like some stupid corporations like VIMEO and his agent provocateur vittorio coming from nowhere? https://it.linkedin.com/in/vittorio-giovara-70b26b326?trk=public_profile_samename-profile an advice for all who want to create trouble against the authors of ffmpeg. create your own fork and do what you want but stop to pollute this emailling list thanks. David OpenPGP_signature.asc Description: OpenPGP digital 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] Democratization work in progress draft v2
Hi, On Sat, Feb 1, 2025 at 1:45 AM Zhao Zhili < quinkblack-at-foxmail@ffmpeg.org> wrote: > The proposal treat every GA member as suspect, and GA members with daily > jobs guilty. Thank you for saying this. I couldn't agree more. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FOSDEM meeting
Hi Devin On Sat, Feb 01, 2025 at 09:27:50AM +0100, Devin Heitmueller wrote: > On Sat, Jan 25, 2025, 11:09 PM Marth64 wrote: > > > > Hello, > > > > Looking forward to it. > > Has a time/location been set for this? Do you expect they would tell teh community ahead of time so people could arrange to actually participate ? (I expected it but i was proofen wrong, middle of first day of fosdem I dont know anything) I think there are 3 options 1. nothing at all (like vdd2024) 2. private session and then a (not recorded) public session (like vdd2023) 3. announced days ahead, fully recorded from the minute the first person enters to the minute the last person leaves. And unlimited public participation. (what FFmpeg should be) and sure anyone wanting anonymity can be blured out thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/3] fftools/opt_common: add timing and datetiming log flags
Hi softworkz On Thu, Jan 30, 2025 at 03:53:25AM +, softworkz wrote: > From: softworkz > > This commit adds two logging flags: 'timing' and 'datetiming'. > > Usage: > > ffmpeg -loglevel +timing > > or > > ffmpeg -loglevel +datetiming ./ffmpeg -loglevel +timing ... 02:04:00.926 Use -h to get full help or, even better, run 'man ffmpeg' 02:04:00.926 michael@box:~/ffmpeg/$ It seems the shell command prompt is after the last time is this intended ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. 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] Democratization work in progress draft v2
On 1/31/2025 9:49 PM, Michael Niedermayer wrote: Hi James On Fri, Jan 31, 2025 at 12:44:50PM -0300, James Almer wrote: On 1/31/2025 11:58 AM, Nicolas George wrote: Niklas Haas (12025-01-30): [...] On the other hand, I believe this whole plan is a bad idea. Yes, it is a bad idea. We have had the current system in place for about five years now, and besides one or two CC assemblages being inefficient, it Do you remember this suggested addition to the FAQ ? https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-January/338186.html It seems you dont remember it even though this was posted just a few days ago I knew this is needed to be put in the FAQ ;( I saw it, and i think that patch is anything but objective and completely unacceptable. You're stating your opinion and discrediting a system in an official document in the project's repository itself of all places. Do you not see how absurd that is? has worked. Changing it now because one person was unhappy with a CC (That This is a false statement. Iam not suggesting a change to the GA because of one CC iam suggesting a change because it is vulnerable to an attack. (The CC isnt even fixed by this, i think the concept of a CC elected out of a community thats full of mutual hate is a bad idea) But back to the topic, what do you suggest to fix the vulerability in the GA ? Or you dont care? Why do you say there's a vulnerability in the GA? Has it been exploited for this to be an issue? Did someone to your knowledge buy a developer to write 20 commits and get them into the GA? Otherwise, you're making a big deal out of an hypothetical, and that's really damaging to the project. I don't know if you realize, but you're being incredibly disrespectful with almost everyone who has contributed anything in the last decade, treating them as moles trying to bring down the project instead of contributing to its success. OpenPGP_signature.asc Description: OpenPGP digital 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] Democratization
Hi Niklas On Wed, Jan 29, 2025 at 04:16:29PM +0100, Niklas Haas wrote: > On Wed, 29 Jan 2025 13:39:36 +0100 Nicolas George wrote: > > Zhao Zhili (12025-01-29): > > > I don’t stay long enough to know the history, but I don’t think delving > > > into history > > > helps the current situation. Let's talk less about history and hatred to > > > avoid creating > > > a self-fulfilling prophecy. > > > > “Those who cannot remember the past are condemned to repeat it.” > > > > The situation affecting the project right now is extremely similar to > > the events of ~15 years ago that led to a fork and harmed the project > > immensely. > > > > We are seeing the same strategy deployed. If we want to avoid the same > > harm happening, we need to realize how it happened the first time. > > I think the most important crux of the problem is a fundamental disagreement > between Michael and the "community" (for lack of a better term) about the role > of the CC (and by extension, the GA). > Michael is under the impression that they > (should) serve a mere advisory role, with Michael himself having final say in which michael is that ? * The GA is vulnerable to a governance attack, that needs to be fixed * The GA does not represent the community but only a select subset, that needs to be fixed * The CC is fundamentally broken * People keep repeating completely false statements about me, these people must be removed For the first 2 points i have posted a proposal, for the other 2 i may post proposals in the future [...] > I think that in summary, Michael is currently in the difficult position of > which > he would rather lose - control over the FFmpeg name, or the developers that > make > up the project. The project belongs to the people, but individuals who spread lies about me have no place in FFmpeg. 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] Democratization
Hi On Wed, Jan 29, 2025 at 07:36:31PM +, Kieran Kunhya via ffmpeg-devel wrote: > On Wed, Jan 29, 2025 at 6:27 PM Marth64 wrote: > > > > Here is an idea, > > Can we try to lay out the friction points in a table or bullet format > > where we can separate the issue from emotion and direct name calling? > > > > For example, > > " * Community has issue ABC but we can't move forward because senior > > leaders don't agree" > > " * Community has issue XYZ but we can't move forward because the > > framework doesn't support it" > > The community wants the GA/TC/CC to be sovereign, but Michael blocks > enforcement. The GA does not represent the community > The community wants transparency about infrastructure, but Michael > refuses to publish. thats just not true > The community doesn't want arbitrary censorship, but Michael and his > surrogates do. thats also not true It was also me who complained about the lack of recording and remote participation in VDD2024. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus 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] Democratization work in progress draft v2
Hello, On Sat, 1 Feb 2025, at 07:45, Zhao Zhili wrote: > The proposal treat every GA member as suspect, and GA members with > daily jobs guilty. > > The community should be based on trust and everyone should be trust > equally, +1 > It’s dangerous to fix the vulnerability in the GA by make GA totally > under control, which I agree with you Zhao, and everything you said. jbk -- Jean-Baptiste Kempf - President +33 672 704 734 https://jbkempf.com/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Democratization
On 2/1/2025 11:46 AM, Michael Niedermayer wrote: Hi On Wed, Jan 29, 2025 at 10:21:37PM +0100, Niklas Haas wrote: On Wed, 29 Jan 2025 21:51:27 +0100 Nicolas George wrote: Niklas Haas (12025-01-29): [...] *Some members* of what you call community have expressed violent opposition to Michael. But *other members* have expressed, support for Michael, yet other members have agreed to arguments on both side successively, and the majority have not expressed anything. The CC was elected by a majority of the GA, so for all intents and purposes, the CC is the closest representation of the majority opinion as we are likely to ever have. 1. The GA does not represent the community It does by definition. It's a list of the currently most active people, by either meeting a agreed upon criteria or by agreed exception if they don't meet it but are active in other forms. 2. The GA is vulnerable to a simple governance attack 3. The CC vote period was extended by the person running the vote while he asked specific people to join. You're aware that had courmisch not made it in, it would have been Vittorio instead, right? You're insinuating there was malice where instead there was an attempt of having more than five volunteers for a five places committee (Meaning, actually having a vote for it). 4. from the small number of people supporting the GA system origianlly several changed their mind (both me and nicolas for example liked the GA idea originally IIRC) also paul opposed it publically immedeatly when it was announced many years ago And why did you stop liking the idea? When i argued it was because one CC did not act as swiftly as you would have liked (or because you thought it was biased), you said that was not the case. So what changed your mind? We can easily have something better As it's been said before, proposing to change a system because you were not satisfied with the current one sets a bad precedent, and signals you're ok with a democratic system as long as it's to your liking, not as long as it's agreed by the people participating in it. A change should be proposed if the system in question is proven to be flawed, which has not happened. The community is thousands of people not just 49 How many times are you going to repeat this? Thousands of registered emails in a mailing list (of which a bunch are removed for excessive bouncing almost daily) is not thousands of people active in a community. Just look at these threads, and see how many different names are participating. It's not even 49, let alone thousands. You're heavily overestimating the amount of people that participate in the project. Those 49 are people that have kept the project alive and progressing for at least the last five years. And if you think someone is missing from that list, why haven't you proposed them when we voted to have exceptions added? Fwiw, as soon as we move to Forgejo/Gitlab, the amount of contributors should increase considerably, and next time the GA is formed by running the script, the composition will be very different. OpenPGP_signature.asc Description: OpenPGP digital 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] Democratization work in progress draft v2
> -Original Message- > From: ffmpeg-devel On Behalf Of Leo > Izen > Sent: Sunday, February 2, 2025 3:26 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] Democratization work in progress draft v2 > > On 1/31/25 11:01 AM, Soft Works wrote: [..] Hi Leo, > > How about a quadratic attenuation of past commit counts, so that > older commits count less than more recent ones? Shortly after sending I realized that it's exponential, not quadratic (which was the initial idea), sorry for the mixup. > Such quadratic metrics tend to be such that for currently active > contributors, it roughly correlates with square root of commit count > (which is an increasing function) and therefore isn't meaningfully > different. I'm not sure whether I can follow. Do you mean for 1. currently active contributors who have been active in the past 2. currently active contributors who have not been active in the past 3. for both equally? If you mean that it's equal for all in (1), that would be just like intended as the goal would be to give them more voting power than those in (2). It would also give those a vote who have contributed in the past but are no longer active, yet decreasing over time. > A similar thing was discovered in the N-papers-cited-N-times-each > metric > which was popular at one point in academia as an alternative to > citation > count. It turned out to maximize the area of an axis-bounded square > when > contributions were plotted, which is why for naturally occurring data > it > correlated pretty well with the square root of total citation count. > > While this isn't an entirely analogous situation, most contributors > who > are active have been active since they started contributing, > so this > doesn't do a whole lot except to pick out people who used to be > active > and then stopped and then started up again. I'm not sure how it was done in the case you are referring to, but it sounds like the time axis there would have been scaled to the begin of their activity, while in this case, it would be absolute. (please correct me if I'm misinterpreting) Also, in the academic area, one usually doesn't stop activity like it happens in case of ffmpeg, for which one would be given decreasing weight of votes over time. I'm not actually proposing this as a model, but some had said that contributions from past times (earlier than the 3-yr GA range) should give them more weight in voting, and my answer to that is, if this would be done, then it should be at least in a way that recent contributions will count more than older contributions. What was the outcome in the academic world - back to citation count? Best sw ___ 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] FOSDEM meeting
On Sat, Jan 25, 2025, 11:09 PM Marth64 wrote: > > Hello, > > Looking forward to it. Has a time/location been set for this? Thanks, Devin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avformat/riffdec: warn on invalid sample rate
On Fri, Jan 31, 2025 at 3:33 PM Marton Balint wrote:
>
>
>
> On Fri, 31 Jan 2025, Viraaj Raulgaonkar wrote:
>
> > On Fri, Jan 31, 2025 at 4:49 AM Marton Balint wrote:
> >>
> >>
> >>
> >> On Thu, 30 Jan 2025, Viraaj Raulgaonkar wrote:
> >>
> >> > If std_strict_compliance < FF_COMPLIANCE_STRICT, then warn the user of
> >> > the invalid sample rate instead of returning an error. This allows the
> >> > sample rate to be decoded in certain cases.
> >> >
> >> > Fixes Trac Ticket #11361.
> >> > ---
> >> > libavformat/riffdec.c | 7 +--
> >> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/libavformat/riffdec.c b/libavformat/riffdec.c
> >> > index b7a85a6ab2..1f4cacf1d5 100644
> >> > --- a/libavformat/riffdec.c
> >> > +++ b/libavformat/riffdec.c
> >> > @@ -180,9 +180,12 @@ int ff_get_wav_header(void *logctx, AVIOContext *pb,
> >> > par->bit_rate = bitrate;
> >> >
> >> > if (par->sample_rate <= 0) {
> >> > -av_log(logctx, AV_LOG_ERROR,
> >> > +int strict = ((AVFormatContext*)logctx)->strict_std_compliance
> >> > >= FF_COMPLIANCE_STRICT;
> >>
> >> You should change the type in the function declaration, not cast it here.
> >
> > Should I change the function declaration in a separate patch?
>
> The most clean way would be to change the type of logctx and also rename
> "logctx" it to "s" (a common variable name for an AVFormatContext) in the
> first patch, then do the sample rate change in the second patch.
Ok, I'll separate the patches and submit them for review.
Thanks,
Viraaj
>
> Regards,
> Marton
>
>
> >
> > Thanks,
> > Viraaj
> >
> >>
> >> Thanks,
> >> Marton
> >>
> >> > +av_log(logctx, strict ? AV_LOG_ERROR : AV_LOG_WARNING,
> >> >"Invalid sample rate: %d\n", par->sample_rate);
> >> > -return AVERROR_INVALIDDATA;
> >> > +if (strict)
> >> > +return AVERROR_INVALIDDATA;
> >> > +par->sample_rate = 0;
> >> > }
> >> > if (par->codec_id == AV_CODEC_ID_AAC_LATM) {
> >> > /* Channels and sample_rate values are those prior to applying
> >> > SBR
> >> > --
> >> > 2.39.5
> >> >
> >> > ___
> >> > ffmpeg-devel mailing list
> >> > ffmpeg-devel@ffmpeg.org
> >> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >> >
> >> > To unsubscribe, visit link above, or email
> >> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >> >
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >> To unsubscribe, visit link above, or email
> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4 2/2] avformat/riffdec: warn on invalid sample rate
If strict_std_compliance < FF_COMPLIANCE_STRICT, then warn the user of
the invalid sample rate instead of returning an error. In certain cases
the sample rate can get decoded later on during demux.
Fixes Trac Ticket #11361.
---
libavformat/riffdec.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavformat/riffdec.c b/libavformat/riffdec.c
index 2b269b1682..a3eee43a41 100644
--- a/libavformat/riffdec.c
+++ b/libavformat/riffdec.c
@@ -180,9 +180,12 @@ int ff_get_wav_header(AVFormatContext *s, AVIOContext *pb,
par->bit_rate = bitrate;
if (par->sample_rate <= 0) {
-av_log(s, AV_LOG_ERROR,
+int strict = s->strict_std_compliance >= FF_COMPLIANCE_STRICT;
+av_log(s, strict ? AV_LOG_ERROR : AV_LOG_WARNING,
"Invalid sample rate: %d\n", par->sample_rate);
-return AVERROR_INVALIDDATA;
+if (strict)
+return AVERROR_INVALIDDATA;
+par->sample_rate = 0;
}
if (par->codec_id == AV_CODEC_ID_AAC_LATM) {
/* Channels and sample_rate values are those prior to applying SBR
--
2.39.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4 1/2] avformat/riffdec: change declaration of ff_get_wav_header()
Change the type of logctx from void* to AVFormatContext*, since all
calls to ff_get_wav_header() pass an AVFormatContext* anyway.
---
libavformat/riff.h| 2 +-
libavformat/riffdec.c | 14 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavformat/riff.h b/libavformat/riff.h
index a93eadfeca..0b01b1fd20 100644
--- a/libavformat/riff.h
+++ b/libavformat/riff.h
@@ -67,7 +67,7 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecParameters
*par, int for_asf, int
int ff_put_wav_header(AVFormatContext *s, AVIOContext *pb, AVCodecParameters
*par, int flags);
enum AVCodecID ff_wav_codec_get_id(unsigned int tag, int bps);
-int ff_get_wav_header(void *logctx, AVIOContext *pb, AVCodecParameters *par,
+int ff_get_wav_header(AVFormatContext *s, AVIOContext *pb, AVCodecParameters
*par,
int size, int big_endian);
extern const AVCodecTag ff_codec_bmp_tags[]; // exposed through
avformat_get_riff_video_tags()
diff --git a/libavformat/riffdec.c b/libavformat/riffdec.c
index b7a85a6ab2..2b269b1682 100644
--- a/libavformat/riffdec.c
+++ b/libavformat/riffdec.c
@@ -92,14 +92,14 @@ static void parse_waveformatex(void *logctx, AVIOContext
*pb, AVCodecParameters
}
/* "big_endian" values are needed for RIFX file format */
-int ff_get_wav_header(void *logctx, AVIOContext *pb,
+int ff_get_wav_header(AVFormatContext *s, AVIOContext *pb,
AVCodecParameters *par, int size, int big_endian)
{
int id, channels = 0, ret;
uint64_t bitrate = 0;
if (size < 14) {
-avpriv_request_sample(logctx, "wav header size < 14");
+avpriv_request_sample(s, "wav header size < 14");
return AVERROR_INVALIDDATA;
}
@@ -140,18 +140,18 @@ int ff_get_wav_header(void *logctx, AVIOContext *pb,
if (size >= 18 && id != 0x0165) { /* We're obviously dealing with
WAVEFORMATEX */
int cbSize = avio_rl16(pb); /* cbSize */
if (big_endian) {
-avpriv_report_missing_feature(logctx, "WAVEFORMATEX support for
RIFX files");
+avpriv_report_missing_feature(s, "WAVEFORMATEX support for RIFX
files");
return AVERROR_PATCHWELCOME;
}
size -= 18;
cbSize = FFMIN(size, cbSize);
if (cbSize >= 22 && id == 0xfffe) { /* WAVEFORMATEXTENSIBLE */
-parse_waveformatex(logctx, pb, par);
+parse_waveformatex(s, pb, par);
cbSize -= 22;
size -= 22;
}
if (cbSize > 0) {
-ret = ff_get_extradata(logctx, par, pb, cbSize);
+ret = ff_get_extradata(s, par, pb, cbSize);
if (ret < 0)
return ret;
size -= cbSize;
@@ -164,7 +164,7 @@ int ff_get_wav_header(void *logctx, AVIOContext *pb,
int nb_streams, i;
size -= 4;
-ret = ff_get_extradata(logctx, par, pb, size);
+ret = ff_get_extradata(s, par, pb, size);
if (ret < 0)
return ret;
nb_streams = AV_RL16(par->extradata + 4);
@@ -180,7 +180,7 @@ int ff_get_wav_header(void *logctx, AVIOContext *pb,
par->bit_rate = bitrate;
if (par->sample_rate <= 0) {
-av_log(logctx, AV_LOG_ERROR,
+av_log(s, AV_LOG_ERROR,
"Invalid sample rate: %d\n", par->sample_rate);
return AVERROR_INVALIDDATA;
}
--
2.39.5
___
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".
