Le 30 mai 2025 03:46:05 GMT+03:00, Michael Niedermayer
a écrit :
>On Mon, May 26, 2025 at 11:43:15AM +0300, Rémi Denis-Courmont wrote:
>>
>>
>> Le 26 mai 2025 00:37:08 GMT+03:00, Michael Niedermayer
>> a écrit :
>> >Hi Rémi
>> >
>> >On Sat, May 24, 2025 at 07:10:57PM +0300, Rémi Denis-Courm
On 5/29/25 7:58 PM, Michael Niedermayer wrote:
On Tue, May 27, 2025 at 01:24:57PM -0500, Ethan Halsall wrote:
Signed-off-by: Ethan Halsall
---
libavfilter/vf_mcdeint.c | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_mcdeint
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Donnerstag, 29. Mai 2025 16:44
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
>
> softworkz . (HE12025-05-28):
> >
Patches attached.
- Andreas
From 749b698708288909ca14b51b51621ac837046daf Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Fri, 23 May 2025 15:58:03 +0200
Subject: [PATCH 1/5] avcodec/ac3dec: Hardcode tables to save space
The code to initialize the ungrouped bap mantissa tables
(bap 3 or
On Tue, May 27, 2025 at 09:55:33AM +0200, Niklas Haas wrote:
> From: Niklas Haas
>
> This covers most 8-bit and 16-bit ops, and some 32-bit ops. It also covers all
> floating point operations. While this is not yet 100% coverage, it's good
> enough for the vast majority of formats out there.
>
>
Andreas Rheinhardt:
> Patches attached.
>
> - Andreas
>
The first patch has been lgtm'ed by Martin on IRC and applied. Will
apply the rest of this patchset tomorrow unless there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
On Tue, May 27, 2025 at 01:24:57PM -0500, Ethan Halsall wrote:
> Signed-off-by: Ethan Halsall
> ---
> libavfilter/vf_mcdeint.c | 32
> 1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter/vf_mcdeint.c b/libavfilter/vf_mcdeint.c
> index 82
On Mon, May 26, 2025 at 11:43:15AM +0300, Rémi Denis-Courmont wrote:
>
>
> Le 26 mai 2025 00:37:08 GMT+03:00, Michael Niedermayer
> a écrit :
> >Hi Rémi
> >
> >On Sat, May 24, 2025 at 07:10:57PM +0300, Rémi Denis-Courmont wrote:
> >> Le torstaina 22. toukokuuta 2025, 9.32.18 Itä-Euroopan kesäai
On Thu, May 08, 2025 at 11:57:33PM +0200, Michael Niedermayer wrote:
> The code uses int, unsigned int and uint16_t to store num_entry_point_offsets
> This limits it to the smallest of the 3.
> Alternatively uint16_t can be changed and then a larger limit used.
> A Check will still be needed.
>
>
On Thu, May 08, 2025 at 11:57:34PM +0200, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes:
> 394638693/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SPEEX_fuzzer-4868142996455424
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/project
On 28.05.2025 14:43, faeez kadiri wrote:
Hi all,
Just a gentle reminder regarding my patch submission:
I do intend to look at this, but haven't found time yet.
Will hopefully get to it this weekend.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.o
I appreciate the review for both the commits. I did fix all the unrelated
changes and iterated in the new version, would appreciate the rearview.
> On May 29, 2025, at 20:53, Martin Storsjö wrote:
>
> On Tue, 27 May 2025, Dmitriy Kovalenko wrote:
>
>> This particular set of changes is a small
This patch integrates so called double bufferring when we are loading
2 batch of elements at a time and then processing them in parallel. On the
moden arm processors especially Apple Silicon it gives a visible
benefit, for subsampled pixel processing it is especially nice because
it allows to read
I've found quite a few ways to optimize existing ffmpeg's rgb to yuv
subsampled conversion. In this patch stack I'll try to
improve the perofrmance.
This particular set of changes is a small improvement to all the
existing functions and macro. The biggest performance gain is
coming from post loadi
This is a follow up based on the review feedbakc by Martin Storsj??. I
fixed all the identation issues and added post load increment to the all
used macros and macroed back all the code that was unmacroed in the
previous version.
Per the prefetching instructions: They definetely not giving visible
On Tue, 27 May 2025, Dmitriy Kovalenko wrote:
This patches integrates so called double bufferring when we are loading
2 batch elements at a time and then processing them in parallel. On the
moden arm processors especially Apple Silicon it gives a visible
benefit, for subsampled pixel processing
On Thu, May 29, 2025 at 07:26:09PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Hi
> >
> > On Thu, May 29, 2025 at 04:37:16PM +0800, Zhao Zhili wrote:
> >>
> >>
> >>> On May 29, 2025, at 15:03, Jiawei wrote:
> >>>
> >>> This patch modifies the FFmpeg build system to remove the expl
On Tue, 27 May 2025, Dmitriy Kovalenko wrote:
This particular set of changes is a small improvement to all the
existing functions and macro. The biggest performance gain is
coming from post loading increment of the pointer and immediate
prefetching
How certain are you about the prefetching act
Michael Niedermayer:
> Hi
>
> On Thu, May 29, 2025 at 04:37:16PM +0800, Zhao Zhili wrote:
>>
>>
>>> On May 29, 2025, at 15:03, Jiawei wrote:
>>>
>>> This patch modifies the FFmpeg build system to remove the explicit disabling
>>> of GCC's auto-vectorization feature.
>>>
>>> Modern GCC versions ha
Signed-off-by: Frank Plowman
---
Was requested on IRC.
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index d1d87752b9..485cca6c75 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -266,7 +266,7 @@ Codecs:
vp8
Hi
On Thu, May 29, 2025 at 04:37:16PM +0800, Zhao Zhili wrote:
>
>
> > On May 29, 2025, at 15:03, Jiawei wrote:
> >
> > This patch modifies the FFmpeg build system to remove the explicit disabling
> > of GCC's auto-vectorization feature.
> >
> > Modern GCC versions have demonstrated stable au
softworkz . (HE12025-05-28):
>Also, I cannot
> consider people as trustworthy while they are going crazy.
Oh, yes, I dare say insulting your betters is the best strategy.
I have no qualms saying « your betters » since I was barely involved in
this
On Wed, May 28, 2025 at 09:59:30PM +, Tristan Matthews via ffmpeg-devel
wrote:
> On Wednesday, May 28th, 2025 at 11:17 AM, Michael Niedermayer
> wrote:
>
> > Hi
> >
> > If someone has spare time, there are some public open issues on:
> > https://issues.oss-fuzz.com/issues?q=status:open com
On 29/05/2025 11:20, Jiawei wrote:
>
> 在 2025/5/29 16:37, Zhao Zhili 写道:
>>
>>> On May 29, 2025, at 15:03, Jiawei wrote:
>>>
>>> This patch modifies the FFmpeg build system to remove the explicit disabling
>>> of GCC's auto-vectorization feature.
>>>
>>> Modern GCC versions have demonstrated stab
> On May 29, 2025, at 18:20, Jiawei wrote:
>
>
> 在 2025/5/29 16:37, Zhao Zhili 写道:
>>
>>> On May 29, 2025, at 15:03, Jiawei wrote:
>>>
>>> This patch modifies the FFmpeg build system to remove the explicit disabling
>>> of GCC's auto-vectorization feature.
>>>
>>> Modern GCC versions have
在 2025/5/29 16:37, Zhao Zhili 写道:
On May 29, 2025, at 15:03, Jiawei wrote:
This patch modifies the FFmpeg build system to remove the explicit disabling
of GCC's auto-vectorization feature.
Modern GCC versions have demonstrated stable auto-vectorization capabilities
through extensive optimiz
softworkz . (HE12025-05-29):
> That nobody has responded is not much surprising
Yes, nobody responded after less than twelve hours, that must be a
conspiracy.
--
Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/
> On May 29, 2025, at 15:03, Jiawei wrote:
>
> This patch modifies the FFmpeg build system to remove the explicit disabling
> of GCC's auto-vectorization feature.
>
> Modern GCC versions have demonstrated stable auto-vectorization capabilities
> through extensive optimizations in loop analysis
28 matches
Mail list logo
