PR #20838 opened by mkver
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20838
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20838.patch
>From 549f85f6c3f32f90429bed8362e8817268fad862 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Tue, 4 Nov 2025 13:56:01 +0100
Subject: [PATC
On Tue, Nov 4, 2025 at 11:12 AM Nicolas George via ffmpeg-devel
wrote:
> Any service that alters a mail while forwarding it, like a mailing-list
> adding “[ffmpeg-devel]” in the subject line, will break the signature.
> What they are expected to do is to add a signature of their own, from
> their
> On Nov 5, 2025, at 02:15, Kacper Michajłow via ffmpeg-devel
> wrote:
>
> PR #20837 opened by Kacper Michajłow (kasper93)
> URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20837
> Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20837.patch
>
> In MSVC builds, object files built for s
On Tue, 4 Nov 2025, Nicolas George via ffmpeg-devel wrote:
> Carl Hetherington via ffmpeg-devel (HE12025-11-03):
> > Since 3b26b782eeded9b9ab7fac013cd1a83a30d68206 it would only look at the
> > first channel.
> >
> > Signed-off-by: [email protected]
> > ---
> > libavfilter/f_ebur128.c | 2 +-
> > 1
Hi Steven
On Thu, Oct 30, 2025 at 03:19:54PM +0800, Steven Liu via ffmpeg-devel wrote:
> Hi Folks,
>
>
> I would like to request reimbursement for the following expenses
> incurred attending the Google Summer of Code mentor summit.
>
> Description
Hi,
Le 4 novembre 2025 21:39:49 GMT+02:00, Nicolas George via ffmpeg-devel
a écrit :
>Niklas Haas via ffmpeg-devel (HE12025-11-03):
>> 4. Developers should announce when they begin working on a bounty, and then
>>nobody else should be able to claim it until a reasonable amount of
>>time
Carl Hetherington via ffmpeg-devel (HE12025-11-03):
> Since 3b26b782eeded9b9ab7fac013cd1a83a30d68206 it would only look at the
> first channel.
>
> Signed-off-by: [email protected]
> ---
> libavfilter/f_ebur128.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Hi. Thanks for the patch. I su
Niklas Haas via ffmpeg-devel (HE12025-11-03):
> 4. Developers should announce when they begin working on a bounty, and then
>nobody else should be able to claim it until a reasonable amount of
>time has passed. (Perhaps 12 weeks)
That seems rather reasonable, and in line with my position t
Michael Niedermayer via ffmpeg-devel (HE12025-10-16):
> As we all certainly know, this ML since a few months rewrites
> all "From:" headers to "X Y via ffmpeg-devel "
> We changed this because neither me nor timo nor rather unhelpfull AI
> could fix the bounce & dmarc issue
Hi. I do not know about
PR #20837 opened by Kacper Michajłow (kasper93)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20837
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20837.patch
In MSVC builds, object files built for shared or static libraries are
technically not compatible with each other. That's why bui
PR #20836 opened by Ramiro Polla (ramiro)
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20836
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20836.patch
384fe39623e932e68fe35af7d5b51fcd0a6c28fb introduced a regression in the
range conversion offset calculation, resulting in a slight gre
Hi all
ffmpeg-devel was set to discard non member mails, ive set it to hold non member
messages now (i know this was what it was set to long ago)
just in the last 2 days we had 3 messages which ive just let through.
So theres valuable non subscriber mails which we where loosing.
one of these was
Dear *FFmpeg*
We are pleased to inform you that *FFmpeg* is being awarded *100,000 USD*
by FLOSS/fund to support its continued development. We deeply appreciate
the work you do and its impact, and are happy to be a small part of
something that all of us derive immense value from.
You can read mor
Hi Team,
I hope this message finds you well. I wanted to drop a gentle reminder
regarding the patch I submitted recently. When you have a moment, could you
please review it? Your feedback is invaluable, and I look forward to any
insights or suggestions you might have.
Thank you so much for you
PR #20818 opened by mkver
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20818
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20818.patch
>From abf819cff61d779f131fa7c23232952b46496928 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Sun, 2 Nov 2025 15:03:33 +0100
Subject: [PATC
Hi,
Il 04/11/25 14:50, Zhao Zhili ha scritto:
The specification says that if either the numerator or the
denominator is zero then the SAR is to be intended unspecified.
Internally ffmpeg represents an unspecified SAR as 0/1, while
fractions with a zero denominator are not handled properly;
Is
> On Nov 4, 2025, at 21:37, Giovanni Mascellani via ffmpeg-devel
> wrote:
>
> The specification says that if either the numerator or the
> denominator is zero then the SAR is to be intended unspecified.
> Internally ffmpeg represents an unspecified SAR as 0/1, while
> fractions with a zero de
The specification says that if either the numerator or the
denominator is zero then the SAR is to be intended unspecified.
Internally ffmpeg represents an unspecified SAR as 0/1, while
fractions with a zero denominator are not handled properly;
so we bridge the gap by replacing x/0 with 0/1.
Sign
>
> Or is it the position of ffmpeg that the SMUSH vulnerability should be
> left in place until a full fix of the codec is made?
>
The issue was fixed a long time ago.
Also please don't top post.
Kieran
>
___
ffmpeg-devel mailing list -- ffmpeg-devel@
PR #20834 opened by Lynne
URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20834
Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20834.patch
The last merged PR (#20815) contained garbage.
>From fe6cdacc50a33bdbe18bdc6165b84e409cb2e680 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Tue, 4 Nov
Thank you for the quick response.
I had intended this as a medium-term fix to the referenced CVE that
Google found. In other words, SMUSH is specifically not secure. This
seems to be the most straightforward approach. It will prevent anyone
using auto-selection of the codec from being the v
Hi,
Experimental means part of an experiment. The SMUSH decoder might have
qualified as experimental while it was being implemented (reverse engineered?),
but not today.
What it is is unsupported, but the same could be said of, well, essentially
every codec in FFmpeg, as per the GPL/LGPL warra
22 matches
Mail list logo
