On Wed, 9 Jul 2025, Georgii Zagoruiko wrote:
diff --git a/libavcodec/aarch64/vvc/alf.S b/libavcodec/aarch64/vvc/alf.S
index 8801b3afb6..9c9765ead1 100644
--- a/libavcodec/aarch64/vvc/alf.S
+++ b/libavcodec/aarch64/vvc/alf.S
@@ -291,3 +291,281 @@ function ff_alf_filter_chroma_kernel_10_neon, expo
On Fri, 18 Jul 2025, James Almer wrote:
ffmpeg | branch: master | James Almer | Tue Jul 15 19:00:21
2025 -0300| [3cd5672bfeb796342d24228a78f2e733c0a40e7d] | committer: James Almer
fate/lavf-container: add test for APV in MP4
Signed-off-by: James Almer
http://git.videolan.org/gitweb.cgi/ff
On Sun, 13 Jul 2025, Michael Niedermayer wrote:
Hi all
Do people want Forgejo or Gitlab on code.ffmpeg.org for testing?
F. code.ffmpeg.org should run Forgejo
G. code.ffmpeg.org should run Gitlab
No strong opinion between the two. I have a lot of experience with Gitlab
(which I find quite wo
On Thu, 10 Jul 2025, Jiawei wrote:
In addition, can you provide a bug record or a reproduction method? I think
it should also be fixed in the GCC community, and I will report the problems
you encounter in test to GCC Bugzilla.
https://patchwork.ffmpeg.org/check/125495/
If you build ffmpeg wi
On Thu, 10 Jul 2025, Jiawei wrote:
Hi Martin,
Is there any progress for this patch, should I resend it to the mailing list
again?
When I posted the updated version of the patch, the patchwork test runners
noticed that this patch causes test failures on Loongarch. So modern
versions of GCC
On Tue, 8 Jul 2025, Marvin Scholz wrote:
The use of this protocol was already discouraged and warned about
for years with the recommendation to use the HLS demuxer instead.
---
doc/protocols.texi | 20 ---
libavformat/Makefile| 2 -
libavformat/hlsproto.c | 318 ---
On Sat, 28 Jun 2025, Michael Niedermayer wrote:
Its a few years since the last change to fateserver, i think we dont
have a script to update the checkout on the server from a git push.
Its a while, i dont remember exactly :)
so you have to update that checkout after pushing possibly
I don't th
On Fri, 27 Jun 2025, Kacper Michajlow wrote:
On Fri, Jun 27, 2025, 14:44 Martin Storsjö wrote:
On Wed, 18 Jun 2025, Michael Niedermayer wrote:
> Hi Martin
>
> On Fri, Jun 13, 2025 at 01:57:05PM +0300, Martin Storsjö wrote:
>> If there were failures while running tests, e.g
On Wed, 18 Jun 2025, Michael Niedermayer wrote:
Hi Martin
On Fri, Jun 13, 2025 at 01:57:05PM +0300, Martin Storsjö wrote:
If there were failures while running tests, e.g. if failing to
compile checkasm or any other of the test programs, there are no
failed tests per se, and the number of
: Re: [FFmpeg-devel] [PATCH] configure: Make MSVC version grabbing more
robust
Hi Martin!
On 2025-06-21 13:37 +0300, Martin Storsjö wrote:
> > On 21. Jun 2025, at 12.20, Alexander Strasser via ffmpeg-devel
wrote:
> >
> >
> > On 2025-06-21 00:03 +0200, Kacper Michajlow wr
On Sat, 21 Jun 2025, Kacper Michajlow wrote:
On Sat, 21 Jun 2025 at 12:34, Martin Storsjö wrote:
On Sat, 21 Jun 2025, Kacper Michajlow wrote:
> On Fri, 20 Jun 2025 at 22:26, Hendrik Leppkes
> wrote:
>>
>> On Fri, Jun 20, 2025 at 9:25 PM Timo Rothenpieler
wrote:
>>
On Sat, 21 Jun 2025, Kacper Michajlow wrote:
On Fri, 20 Jun 2025 at 22:26, Hendrik Leppkes
wrote:
On Fri, Jun 20, 2025 at 9:25 PM Timo Rothenpieler wrote:
>
> On 19.06.2025 22:21, Martin Storsjö wrote:
> > On Fri, 13 Jun 2025, Martin Storsjö wrote:
> >
> >> When
> On 21. Jun 2025, at 12.20, Alexander Strasser via ffmpeg-devel
> wrote:
>
>
> On 2025-06-21 00:03 +0200, Kacper Michajlow wrote:
>> On Fri, 20 Jun 2025 at 22:26, Hendrik Leppkes
>> wrote:
>>>
>>> On Fri, Jun 20, 2025 at 9:25 PM Timo Rothenpieler
>>> wrote:
Likely this patch bro
On Fri, 13 Jun 2025, Martin Storsjö wrote:
When running plain "cl", to get the MSVC version, it prints the
version header on stderr, while the usage instructions are printed
on stdout. Usually, the version on stderr gets flushed first,
so "head -n1" gets the line it expects
On Fri, 6 Jun 2025, Logaprakash Ramajayam wrote:
Checked FATE tests and gha-aarch64 git workflow.
From 34cdef26eaebcf98916e9881b3a04f4f698f09c6 Mon Sep 17 00:00:00 2001
From: Logaprakash Ramajayam
Date: Thu, 5 Jun 2025 01:33:39 -0700
Subject: [PATCH] swscale/aarch64/output: Implement neon asse
On Mon, 9 Jun 2025, Harshitha Sarangu Suresh wrote:
From 4ca5eae1e7164f78296719f19aef97239e5b046a Mon Sep 17 00:00:00 2001
From: Harshitha Suresh
Date: Mon, 19 May 2025 22:37:20 +0530
Subject: [PATCH] swscale/aarch64/output: Implement neon assembly for
yuv2nv12cX_c().
yuv2nv12cX_2_512_accurat
On Mon, 16 Jun 2025, Kacper Michajlow wrote:
On Mon, 16 Jun 2025 at 09:40, Martin Storsjö wrote:
On Sat, 14 Jun 2025, Kacper Michajlow wrote:
> On Sat, 14 Jun 2025 at 03:03, Kacper Michajłow wrote:
>>
>> LLVM tools print installation path upon execution. If one uses LLVM
&
On Wed, 11 Jun 2025, Lynne wrote:
ffmpeg | branch: master | Lynne | Mon May 12 18:42:09 2025
+0200| [a9b2c10eee9cf28ecbce2f1972564f4aa826a855] | committer: Lynne
hwcontext_vulkan: use host image copy
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=a9b2c10eee9cf28ecbce2f1972564f4aa
On Mon, 16 Jun 2025, Martin Storsjö wrote:
From: Jiawei
This patch modifies the FFmpeg build system to allow GCC to use the
`-ftree-vectorize` flag when the compiler version is 13 or newer.
Enabling this flag can improve performance through better loop analysis
and auto-vectorization (SIMD
From: Jiawei
This patch modifies the FFmpeg build system to allow GCC to use the
`-ftree-vectorize` flag when the compiler version is 13 or newer.
Enabling this flag can improve performance through better loop analysis
and auto-vectorization (SIMD) opportunities in modern GCC versions.
The expli
On Sat, 14 Jun 2025, Kacper Michajlow wrote:
On Sat, 14 Jun 2025 at 03:03, Kacper Michajłow wrote:
LLVM tools print installation path upon execution. If one uses LLVM
tools bundled with Microsoft Visual Studio installation, they would be
incorrectly detected as Microsoft's ones.
Microsoft to
On Sun, 15 Jun 2025, Michael Niedermayer wrote:
Hi Martin
On Fri, Jun 13, 2025 at 11:42:11AM +0300, Martin Storsjö wrote:
On Fri, 13 Jun 2025, Jiawei wrote:
This patch modifies the FFmpeg build system to allow GCC to use the
`-ftree-vectorize` flag when the compiler version is 13 or newer
On Mon, 16 Jun 2025, Zhao Zhili wrote:
From: Zhao Zhili
---
tests/checkasm/h264dsp.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c
index f5f9650224..006532e08b 100644
--- a/tests/checkasm/h264dsp.c
+++ b/t
On Fri, 13 Jun 2025, Tristan Matthews wrote:
---
tests/checkasm/h264dsp.c | 37 +
1 file changed, 37 insertions(+)
Both patches LGTM, thank you!
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http
When running plain "cl", to get the MSVC version, it prints the
version header on stderr, while the usage instructions are printed
on stdout. Usually, the version on stderr gets flushed first,
so "head -n1" gets the line it expects, but some times (in particular
when running MSVC wrapped in wine),
On Fri, 13 Jun 2025, Tristan Matthews wrote:
On Fri, Jun 13, 2025 at 2:08 AM Martin Storsjö wrote:
On Fri, 13 Jun 2025, Tristan Matthews wrote:
Good catch, also I realized that the output buffers were too small,
will be fixed in the next version.
Why was that too small? If we write (and
If there were failures while running tests, e.g. if failing to
compile checkasm or any other of the test programs, there are no
failed tests per se, and the number of succeessful tests is
equal to the total number of tests.
For these cases, check the job status code instead of declaring
them as a
On Fri, 13 Jun 2025, Jiawei wrote:
This patch modifies the FFmpeg build system to allow GCC to use the
`-ftree-vectorize` flag when the compiler version is 13 or newer.
Enabling this flag can improve performance through better loop analysis
and auto-vectorization (SIMD) opportunities in modern G
On Thu, 12 Jun 2025, Martin Storsjö wrote:
This fixes building with Clang in MSVC mode, for x86, which was
broken in 6e49b8699657b808b7dc80033f2c3f2d0e029fa3 (in Nov 2024);
previously it failed with undefined symbols for the constants
defined with DECLARE_ASM_CONST, accessed via inline assembly
On Fri, 13 Jun 2025, Zhao Zhili wrote:
From: Zhao Zhili
The segment_duration must not be set to zero when writing the moov
atom for the second time. This is related to edit lists in standard
MP4 files.
---
libavformat/movenc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff
On Fri, 13 Jun 2025, Tristan Matthews wrote:
On Thu, Jun 12, 2025 at 4:14 PM Martin Storsjö wrote:
On Thu, 12 Jun 2025, Tristan Matthews wrote:
---
tests/checkasm/h264dsp.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/tests/checkasm/h264dsp.c b
On Thu, 12 Jun 2025, Tristan Matthews wrote:
---
tests/checkasm/h264dsp.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c
index d1228ed985..5fba31cf69 100644
--- a/tests/checkasm/h264dsp.c
+++ b/tests/c
On Thu, 12 Jun 2025, Zhao Zhili wrote:
From: Zhao Zhili
---
libavformat/movenc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index cd5b45f6fe..93af0723db 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -7781,6 +7781,11 @@
On Thu, 12 Jun 2025, Jiawei wrote:
This patch modifies the FFmpeg build system to allow GCC to use the
`-ftree-vectorize` flag when the compiler version is 13 or newer.
Enabling this flag can improve performance through better loop analysis
and auto-vectorization (SIMD) opportunities in modern G
On Thu, 12 Jun 2025, Jiawei wrote:
This patch modifies the FFmpeg build system to allow gcc use '-ftree-vectorize'
option in newer releases.
Modern GCC versions can be benefit when using the `-ftree-vectorize` flag.
Through it can optimizations in loop analysis and SIMD code generation.
Versio
On Thu, 12 Jun 2025, Martin Storsjö wrote:
On Thu, 12 Jun 2025, Jiawei wrote:
This patch modifies the FFmpeg build system to allow gcc use
'-ftree-vectorize'
option in newer releases.
Modern GCC versions can be benefit when using the `-ftree-vectorize` flag.
Through it can optimi
On Mon, 31 Mar 2025, Kacper Michajłow wrote:
Clang x86_64-pc-windows-msvc doesn't define __GNUC__.
Signed-off-by: Kacper Michajłow
---
libavformat/internal.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index fe428d85eb..bf8
On Mon, 31 Mar 2025, Kacper Michajłow wrote:
Fixes use of bultins on clang x86_64-pc-windows-msvc which does not
define any __GNUC__. Also on other targets __GNUC__ is defined to 4 by
default, so any feature testing based on version is not really valid.
Signed-off-by: Kacper Michajłow
---
liba
On Thu, 29 May 2025, 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 auto-vectorization capabilities
through extensive opti
This fixes building with Clang in MSVC mode, for x86, which was
broken in 6e49b8699657b808b7dc80033f2c3f2d0e029fa3 (in Nov 2024);
previously it failed with undefined symbols for the constants
defined with DECLARE_ASM_CONST, accessed via inline assembly.
Before 57861911a34e1c33796be97f2b2f44e05fffd
On Wed, 11 Jun 2025, Kacper Michajlow wrote:
On Mon, 31 Mar 2025 at 14:03, Kacper Michajłow wrote:
Fixes use of bultins on clang x86_64-pc-windows-msvc which does not
define any __GNUC__. Also on other targets __GNUC__ is defined to 4 by
default, so any feature testing based on version is not
On Fri, 6 Jun 2025, Jack Lau via ffmpeg-devel wrote:
add the missing data structure pkey in the tls_context
properly set this pkey and free it
Signed-off-by: Jack Lau
---
libavformat/tls_openssl.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
LGTM,
On Fri, 6 Jun 2025, Harshitha Sarangu Suresh wrote:
Changed indentation, checked for FATE tests and gha-aarch64 git
workflow. Everything passed.
I doubt that everything passed; this doesn't even compile. See below:
@@ -275,7 +291,10 @@ av_cold void ff_sws_init_swscale_aarch64(SwsInternal *c)
On Thu, 5 Jun 2025, Dmitriy Kovalenko wrote:
Some of the versions of Apple Clang produces a ton of the warnings
related to the missing nullablity specifiers on the existing codebase of
ffmpeg which significantly slows down the compilation becuase of the
produced output size (especially on CI as
On Sat, 31 May 2025, Dmitriy Kovalenko wrote:
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
On Sat, 31 May 2025, Dmitriy Kovalenko wrote:
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 b
On Thu, 5 Jun 2025, Jack Lau wrote:
On Jun 5, 2025, at 15:02, Martin Storsjö wrote:
On Thu, 5 Jun 2025, Jack Lau via ffmpeg-devel wrote:
fix the missing data structure pkey in the tls_context
Signed-off-by: Jack Lau
---
libavformat/tls_openssl.c | 30 +-
1 file
On Thu, 5 Jun 2025, Jack Lau via ffmpeg-devel wrote:
fix the missing data structure pkey in the tls_context
Signed-off-by: Jack Lau
---
libavformat/tls_openssl.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
Thanks, this does fix the build break. Howev
On Wed, 4 Jun 2025, Jack Lau wrote:
ffmpeg | branch: master | Jack Lau | Fri May 16 20:15:05
2025 +0800| [167e343bbe75515a80db8ee72ffa0c607c944a00] | committer: Steven Liu
avformat/whip: Add WHIP muxer support for subsecond latency streaming
This breaks compilation with OpenSSL 1.1.1t:
src
On Mon, 2 Jun 2025, Martin Storsjö wrote:
This avoids warnings like
cl : Command line warning D9002 : ignoring unknown option '-g'
---
gas-preprocessor.pl | 1 +
1 file changed, 1 insertion(+)
Pushed.
// Martin
___
ffmpeg-devel ma
On Tue, 3 Jun 2025, Niklas Haas wrote:
On Mon, 02 Jun 2025 15:41:33 -0300 James Almer wrote:
GCC/Clang is smart enough to emit minss/maxss the same way as these functions.
The only theoretical benefit was in x86_32, where x87 floats are used, but the
penalty of making the clipping opaque to th
This avoids warnings like
cl : Command line warning D9002 : ignoring unknown option '-g'
---
gas-preprocessor.pl | 1 +
1 file changed, 1 insertion(+)
diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index aa3abc0..62c1a04 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -
On Mon, 2 Jun 2025, Harshitha Sarangu Suresh wrote:
From 7260822a578130a713c1455cca6cdd06f1540db8 Mon Sep 17 00:00:00 2001
From: Harshitha Suresh
Date: Mon, 19 May 2025 22:37:20 +0530
Subject: [PATCH] swscale/aarch64/output: Implement neon assembly for
yuv2nv12cX_c()
yuv2nv12cX_2_512_accurate
On Sun, 1 Jun 2025, Andreas Rheinhardt wrote:
Patch attached.
LGTM, thanks.
// 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-r
On Sat, 31 May 2025, Dmitriy Kovalenko wrote:
Correct. I meant dual issue
https://developer.arm.com/documentation/ddi0460/d/Cycle-Timings-and-Interlock-Behavior/Dual-issue
Do not top post.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
On Sat, 31 May 2025, Dmitriy Kovalenko wrote:
Great. I send another version with the reverted change for the asr
register change. What is the correct process to reply for the inline
changes then? Inline email answer or cover letter?
Do not top post. Reply to review comments in an inline reply
On Fri, 30 May 2025, Dmitriy Kovalenko wrote:
=== Feedback response ===
FWIW, the procedure is to respond to inline comments by replying to the
mails where those comments were made. When they're included here, they end
up as part of your suggested commit message.
Anyway, now this time, the
On Fri, 30 May 2025, Dmitriy Kovalenko wrote:
If you with "non-performant mobile" mean small in-order cores, most of them can handle repeated
accumulation like these even faster, if you sequence these so that all accumulations to one register is
sequentially. E.g. first all "smlal \u_dst1\().4
On Fri, 30 May 2025, Dmitriy Kovalenko wrote:
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 b
On Fri, 30 May 2025, Dmitriy Kovalenko wrote:
All the comments were addressed
If you fail to read the inline responses, we can end this conversation
right here.
And how did you test the prefetch, because I literally run a native
benchmarking on the device right now and I see that with the
On Thu, 29 May 2025, Dmitriy Kovalenko wrote:
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.
Don't top post.
There are still at least 5 of my comments unaddressed. If you are not
going to addr
On Thu, 29 May 2025, Martin Storsjö wrote:
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
On Thu, 29 May 2025, Martin Storsjö wrote:
In this case, they also add a direct dependence on
the updated pointer register from the directly preceding instruction, which
_is_ harmful on in-order cores, unless it entirely ignores the instruction.)
I did benchmark this, and indeed it causes a
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 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
On Wed, 28 May 2025, softworkz . wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Martin Storsjö
Sent: Mittwoch, 28. Mai 2025 10:29
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
On Wed, 28 May 2025, softw
On Wed, 28 May 2025, softworkz . wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Martin Storsjö
Sent: Mittwoch, 28. Mai 2025 10:27
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
As we are talking about
On Wed, 28 May 2025, softworkz . wrote:
I haven't looked into in detail it myself, but it is a known issue
since
some of the ffmepg multithreading work a couple years ago. It does
happen
occasionally in all build configurations, more or less often.
Yup. I thought about patching it in the build
t 10:54 PM PDT, Martin Storsjö wrote:
On Tue, 27 May 2025, softworkz . wrote:
Hi,
I have an issue with the CI builds for Mac in a way that it prints
tons of lines like this:
ld: warning: no platform load command found in
'libavcodec/libavcodec.a[1008](sao_10bit.o)', assuming: macO
On Wed, 28 May 2025, softworkz . wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Martin Storsjö
Sent: Mittwoch, 28. Mai 2025 07:55
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
These warnings appeared s
On Tue, 27 May 2025, softworkz . wrote:
Hi,
I have an issue with the CI builds for Mac in a way that it prints
tons of lines like this:
ld: warning: no platform load command found in
'libavcodec/libavcodec.a[1008](sao_10bit.o)', assuming: macOS
ld: warning: no platform load command found in
On Mon, 26 May 2025, Coia Prant wrote:
Can u backport it to released branch?
Please don't top-post here.
Sure, that can probably be reasonable; I can try to backport it to a few
release branches within a day or two.
// Martin
___
ffmpeg-devel ma
On Tue, 27 May 2025, Niklas Haas wrote:
From: Niklas Haas
Because of the lack of an external ABI on low-level kernels, we cannot
directly test internal functions. Instead, we construct a minimal op chain
consisting of a read, the op to be tested, and a write.
The bigger complication arises fr
On Tue, 27 May 2025, Niklas Haas wrote:
From: Niklas Haas
We split the standard macro into its body (implementation) and declaration,
and use a macro argument in place of the raw `memcmp` call, with the major
difference that we now take the number of pixels to compare instead of the
number of
On Mon, 26 May 2025, Gyan Doshi wrote:
Usage of hybrid_fragmented and faststart together can result in files with
loss of sync and bitstream parsing errors upon playback.
---
libavformat/movenc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
On Sun, 25 May 2025, Martin Storsjö wrote:
On Fri, 23 May 2025, Coia Prant wrote:
On Windows Arm64
`uname -m` returned `x86_64` instead of `aarch64`
Link: https://github.com/msys2/msys2-runtime/issues/171
On x86 32-bit toolchain msys2 environment
`uname -m` returned `x86_64` instead of `i686
On Thu, 22 May 2025, Harshitha Sarangu Suresh wrote:
This optimization provides 5x improvement for the module. The boost in
performance was calculated by adding C timers inside the C function and the
optimized neon intrinsic function.
From 904144c2db9e5e72d56360c4c2eb38d426852901 Mon Sep 17
On Mon, 26 May 2025, Andreas Rheinhardt wrote:
ffmpeg | branch: master | Andreas Rheinhardt |
Thu May 22 15:57:13 2025 +0200| [0401ca714a2714743573e27c384ffa810fd31a92] |
committer: Andreas Rheinhardt
avcodec/asvenc: Don't waste bits encoding non-visible part
Up until now, the encoder repli
On Fri, 23 May 2025, Coia Prant wrote:
On Windows Arm64
`uname -m` returned `x86_64` instead of `aarch64`
Link: https://github.com/msys2/msys2-runtime/issues/171
On x86 32-bit toolchain msys2 environment
`uname -m` returned `x86_64` instead of `i686` or `x86`
So check MSYSTEM_CARCH on windows
On Thu, 22 May 2025, James Almer wrote:
ffmpeg | branch: master | James Almer | Thu May 22 19:23:35
2025 -0300| [622a72b5ea5f2022b173355d65d513df2d75000b] | committer: James Almer
tests/fate/ac3: add a second ac3_fixed encoder test
Exercising the lavfi filtergraph codepath to choose the best
On Wed, 21 May 2025, Andreas Rheinhardt wrote:
Martin Storsjö:
On Wed, 21 May 2025, Andreas Rheinhardt wrote:
Jiawei:
This patch modifies the FFmpeg build system to remove the explicit
disabling
of GCC's auto-vectorization feature.
Modern GCC versions (>= 10.0) have demonstrate
On Wed, 21 May 2025, Andreas Rheinhardt wrote:
Jiawei:
This patch modifies the FFmpeg build system to remove the explicit disabling
of GCC's auto-vectorization feature.
Modern GCC versions (>= 10.0) have demonstrated stable auto-vectorization
capabilities through extensive optimizations in loo
On Sun, 18 May 2025, Niklas Haas wrote:
From: Niklas Haas
---
tests/checkasm/checkasm.c | 1 +
tests/checkasm/checkasm.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 71d1e5766c..c77216ed57 100644
--- a/tests/checkasm/checkasm.c
On Fri, 16 May 2025, softworkz . wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Martin
Storsjö
Sent: Freitag, 16. Mai 2025 10:19
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/graphprint: Now, make it a
Killer-Feature!
On
On Fri, 16 May 2025, softworkz . wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Martin
Storsjö
Sent: Freitag, 16. Mai 2025 08:22
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/graphprint: Now, make it a
Killer-Feature!
On Thu, 15 May 2025
If there were failures while running tests, e.g. if failing to
compile checkasm or any other of the test programs, there are no
failed tests per se, and the number of succeessful tests is
equal to the total number of tests.
For these cases, check the job status code instead of declaring
them as a
On Thu, 15 May 2025, softworkz wrote:
ffmpeg | branch: master | softworkz | Thu May 15
23:10:02 2025 +0200| [1f2b8d7238eff4ab8a4d8d6177e250b8180d51f4] | committer: softworkz
fftools/graphprint: Now, make it a Killer-Feature!
remember this: -sg <= means Show Graph
Signed-off-by: softworkz
On Fri, 16 May 2025, Ramiro Polla wrote:
Use 16-byte alignment (align=4) instead of 4-byte (align=2) in the function and
const macros. This improves instruction fetch and NEON load performance on
modern AArch64 CPUs.
---
libavutil/aarch64/asm.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletio
On Mon, 12 May 2025, Coia Prant wrote:
On Windows Arm64
`uname -m` returned `x86_64` instead of `aarch64`
Link: https://github.com/msys2/msys2-runtime/issues/171
But `uname -s` contains `ARM64` suffix
So check suffix on windows arm64 (for clangarm64)
This problem also in VideoLAN/x264
Link: ht
On Sat, 3 May 2025, Nuo Mi wrote:
Hi Martin,Great, it works!
HEVC is included in v2.
Thanks great, thanks for looking into it! The checkasm aspects of patches
5-7/7 look good to me.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On Fri, 2 May 2025, Martin Storsjö wrote:
On Tue, 29 Apr 2025, Martin Storsjö wrote:
Since GCC 10 and llvm.org Clang 11, -fno-common is the default.
However Apple's Xcode Clang hasn't followed suit yet, and still
defaults to -fcommon.
Compiling with -fcommon causes uninitiali
On Fri, 2 May 2025, Nuo Mi wrote:
On Fri, May 2, 2025 at 3:49 PM Martin Storsjö wrote:
On Fri, 2 May 2025, Nuo Mi wrote:
> From: Shaun Loo
>
> This is a part of Google Summer of Code 2023
>
> AVX2:
> - vvc_sao.sao_band [OK]
&g
On Tue, 29 Apr 2025, Martin Storsjö wrote:
Since GCC 10 and llvm.org Clang 11, -fno-common is the default.
However Apple's Xcode Clang hasn't followed suit yet, and still
defaults to -fcommon.
Compiling with -fcommon causes uninitialized global variables to
be treated as "common
On Fri, 2 May 2025, Nuo Mi wrote:
From: Shaun Loo
This is a part of Google Summer of Code 2023
AVX2:
- vvc_sao.sao_band [OK]
- vvc_sao.sao_edge [OK]
Co-authored-by: Nuo Mi
---
tests/checkasm/Makefile | 2 +-
tests/checkasm/checkasm.c | 1 +
tests/checkasm/checkasm.h | 1 +
tests/checka
On Tue, 29 Apr 2025, Zhao Zhili wrote:
On Apr 25, 2025, at 16:25, Martin Storsjö wrote:
On Tue, 15 Apr 2025, Zhao Zhili wrote:
+tbx v3.8b, {v16.16b-v17.16b}, v3.8b
Is there any specific reason for preferring tbx over tbl here? (I know the
existing code used tbx
Since GCC 10 and llvm.org Clang 11, -fno-common is the default.
However Apple's Xcode Clang hasn't followed suit yet, and still
defaults to -fcommon.
Compiling with -fcommon causes uninitialized global variables to
be treated as "common" (which allows multiple object files to have
similar definiti
On Wed, 23 Apr 2025, Zhao Zhili wrote:
From: Zhao Zhili
On rpi5 (A76):
put_hevc_pel_bi_w_pixels4_8_c: 90.0 ( 1.00x)
put_hevc_pel_bi_w_pixels4_8_neon: 34.1 ( 2.64x)
put_hevc_pel_bi_w_pixels6_8_c: 188.3 ( 1.00x)
put_hevc_pel
On Tue, 15 Apr 2025, Zhao Zhili wrote:
From: Zhao Zhili
int8_t[] is enough for offset_table of 8 bit streams.
On rpi5:
Before After
hevc_sao_band_8_8_c: 252.3 ( 1.00x) 252.3 ( 1.00x)
hevc_sao_band_8_8_neon:95.8 ( 2.63x) 61.0
On Thu, 24 Apr 2025, Zhao Zhili wrote:
On Apr 24, 2025, at 10:24, Steven Liu wrote:
On Apr 23, 2025, at 20:59, Zhao Zhili
wrote:
Hi Zhili,
From: Zhao Zhili
---
libavformat/hls.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavformat/hls.c b/libavfo
On Tue, 1 Apr 2025, yinshiyou...@loongson.cn wrote:
-原始邮件-
发件人: "Martin Storsjö"
发送时间:2025-04-01 17:35:16 (星期二)
收件人: ffmpeg-devel@ffmpeg.org
抄送: jinbo , yinshiyou...@loongson.cn, "Lu Wang"
主题: Re: [PATCH 3/4] checkasm: hevc_pel: Use helpers for checking for write
1 - 100 of 1320 matches
Mail list logo
