On Thu, 11 Jul 2024, James Almer wrote:
Should make strict compilers happy.
Also, make AV_COPY128 use integer operations while at it.
Signed-off-by: James Almer
---
libavutil/x86/intreadwrite.h | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/libavutil/x86/in
On Thu, 11 Jul 2024, James Almer wrote:
On 7/11/2024 10:54 AM, Martin Storsjö wrote:
On Thu, 11 Jul 2024, Martin Storsjö wrote:
On Thu, 11 Jul 2024, James Almer wrote:
On 7/11/2024 10:08 AM, Martin Storsjö wrote:
On Wed, 10 Jul 2024, James Almer wrote:
ffmpeg | branch: master | James
On Thu, 11 Jul 2024, Martin Storsjö wrote:
On Thu, 11 Jul 2024, James Almer wrote:
On 7/11/2024 10:08 AM, Martin Storsjö wrote:
On Wed, 10 Jul 2024, James Almer wrote:
ffmpeg | branch: master | James Almer | Wed Jul
10 13:00:20 2024 -0300| [bd1bcb07e0f29c135103a402d71b343a09ad1690
On Thu, 11 Jul 2024, James Almer wrote:
On 7/11/2024 10:08 AM, Martin Storsjö wrote:
On Wed, 10 Jul 2024, James Almer wrote:
ffmpeg | branch: master | James Almer | Wed Jul 10
13:00:20 2024 -0300| [bd1bcb07e0f29c135103a402d71b343a09ad1690] |
committer: James Almer
x86/intreadwrite: use
On Wed, 10 Jul 2024, James Almer wrote:
ffmpeg | branch: master | James Almer | Wed Jul 10 13:00:20
2024 -0300| [bd1bcb07e0f29c135103a402d71b343a09ad1690] | committer: James Almer
x86/intreadwrite: use intrinsics instead of inline asm for AV_COPY128
This has the benefit of removing any SSE -
On Fri, 5 Jul 2024, James Almer wrote:
On 7/5/2024 2:38 AM, Anton Khirnov wrote:
Quoting James Almer (2024-07-04 22:45:28)
On 7/4/2024 4:04 PM, Anton Khirnov wrote:
Filter output is not bitexact.
---
Reference file at https://up.khirnov.net/7r.pcm, please put it in
filter-reference/atempo.pcm
On Wed, 3 Jul 2024, Steven Liu wrote:
Martin Storsjö 于2024年7月3日周三 04:46写道：
On Wed, 26 Jun 2024, Martin Storsjö wrote:
> Previously, vs->start_pos was never 0 here, unless using the
> -hls_segment_size option, which wasn't allowed for SEGMENT_TYPE_FMP4.
> Therefore, this
On Thu, 4 Jul 2024, Anton Khirnov wrote:
Filter output is not bitexact.
---
Reference file at https://up.khirnov.net/7r.pcm, please put it in
filter-reference/atempo.pcm
---
tests/fate/filter-audio.mak | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tests/fate/filter-audio.
On Wed, 3 Jul 2024, Rajiv Harlalka wrote:
ffmpeg | branch: master | Rajiv Harlalka | Thu Mar
21 13:53:29 2024 +0530| [fc446eea05b9bc7de9a3c6b56dae8255bb5c5b5d] | committer: Anton
Khirnov
tests/fate/filter-audio.mak: add test for atempo audio filter
Signed-off-by: Rajiv Harlalka
Signed-off-
---
tests/fate/filter-audio.mak | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 8120620afe..cf6065b93f 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -413,6 +413,7 @@ fate-filter-hdcd-s32p: CMP = one
On Mon, 24 Jun 2024, Martin Storsjö wrote:
---
This might be needed in dav1d in the future.
---
gas-preprocessor.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index 20b927f..19b0131 100755
--- a/gas-preprocessor.pl
+++ b/gas
On Wed, 26 Jun 2024, Martin Storsjö wrote:
Previously, vs->start_pos was never 0 here, unless using the
-hls_segment_size option, which wasn't allowed for SEGMENT_TYPE_FMP4.
Therefore, this if statement was practically always taken anyway.
Remove this bogus if statement, to allow cha
Previously, the bitrate advertised in the master playlist would only
be based on the nominal values in either AVCodecParameters bit_rate,
or via AVCPBProperties max_bitrate. On top of this, a
fudge factor of 10% is added, to account for container overhead.
Neither of these bitrates may be known, a
This matches what is done in the corresponding case for
HLS_SINGLE_FILE.
Normally, vs->size is already initialized correctly - but when
writing the initial segment, with mp4 files, vs->size has been set
to the size of the init segment, while range_length contains the
real size of the first segment
Previously, vs->start_pos was never 0 here, unless using the
-hls_segment_size option, which wasn't allowed for SEGMENT_TYPE_FMP4.
Therefore, this if statement was practically always taken anyway.
Remove this bogus if statement, to allow changing vs->start_pos
to reflect the right value when not u
When not using HLS_SINGLE_FILE or hls_segment_size, we're writing
each segment into a separate file. In that case, the file start pos for
each segment will be zero.
This matches the case in (hls->max_seg_size > 0) above, where we
decide to switch to a new file.
This fixes the calculation of "vs->
Both the read_byte variable (which is accumulated into
append_single_file) and the return value are int64_t;
give the ret variable the right corresponding type too.
---
libavformat/hlsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsen
On Mon, 24 Jun 2024, Steven Liu wrote:
On Jun 24, 2024, at 16:49, Martin Storsjö wrote:
When not using HLS_SINGLE_FILE or hls_segment_size, we're writing
each segment into a separate file. In that case, the file start pos for
each segment will be zero.
This matches the case in
Versions of MSVC older than 17.9 error out here with the following
error:
src/libavcodec/vvc/filter.c(815): error C2059: syntax error: '}'
src/libavcodec/vvc/filter.c(832): error C2065: 'all_zero_bs': undeclared
identifier
src/libavcodec/vvc/filter.c(836): error C2065: 'all_zero_bs':
---
This might be needed in dav1d in the future.
---
gas-preprocessor.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index 20b927f..19b0131 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -958,7 +958,7 @@ sub handle_se
---
gas-preprocessor.pl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gas-preprocessor.pl b/gas-preprocessor.pl
index b0c343e..20b927f 100755
--- a/gas-preprocessor.pl
+++ b/gas-preprocessor.pl
@@ -1169,6 +1169,8 @@ sub handle_serialized_line {
$line =~ s/\.syntax/$comm$&/x if $a
On Mon, 24 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Test on Apple M1 with kperf:
: -O3 : -O3 -fno-vectorize
abgr_to_uv_8_c : 19.4 : 26.1
abgr_to_uv_8_neon : 29.9 : 51.1
abgr_to_uv_128_c
On Mon, 24 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Test on Apple M1 with kperf
: -O3 : -O3 -fno-vectorize
bgra_to_uv_8_c : 13.4 : 27.5
bgra_to_uv_8_neon : 37.4 : 41.7
bgra_to_uv_128_c
On Mon, 24 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Test on Apple M1 with kperf
: -O3 : -O3 -fno-vectorize
bgr24_to_uv_8_c : 28.5 : 52.5
bgr24_to_uv_8_neon : 54.5 : 59.7
bgr24_to_uv_128_c
Previously, the bitrate advertised in the master playlist would only
be based on the nominal values in either AVCodecParameters bit_rate,
or via AVCPBProperties max_bitrate. On top of this, a
fudge factor of 10% is added, to account for container overhead.
Neither of these bitrates may be known, a
This matches what is done in the corresponding case for
HLS_SINGLE_FILE.
Normally, vs->size is already initialized correctly - but when
writing the initial segment, with mp4 files, vs->size has been set
to the size of the init segment, while range_length contains the
real size of the first segment
When not using HLS_SINGLE_FILE or hls_segment_size, we're writing
each segment into a separate file. In that case, the file start pos for
each segment will be zero.
This matches the case in (hls->max_seg_size > 0) above, where we
decide to switch to a new file.
This fixes the calculation of "vs->
Both the read_byte variable (which is accumulated into
append_single_file) and the return value are int64_t;
give the ret variable the right corresponding type too.
---
libavformat/hlsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsen
On Thu, 20 Jun 2024, Dennis Sädtler wrote:
On 2024-06-20 15:47, Timo Rothenpieler wrote:
On 20/06/2024 15:46, Martin Storsjö wrote:
On Wed, 19 Jun 2024, Martin Storsjö wrote:
This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable
On Sat, 22 Jun 2024, Brad Smith wrote:
[PATCH] aarch64: Add OpenBSD runtime detection of dotprod and i8mm using sysctl
Signed-off-by: Brad Smith
---
libavutil/aarch64/cpu.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/libavutil/aarch64/cpu.c b/libavut
On Wed, 19 Jun 2024, Martin Storsjö wrote:
This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
On Thu, 20 Jun 2024, Zhao Zhili wrote:
On Jun 19, 2024, at 20:05, Rémi Denis-Courmont wrote:
Le 19 juin 2024 11:24:28 GMT+02:00, Zhao Zhili mailto:quinkbl...@foxmail.com>> a écrit :
On Jun 19, 2024, at 15:07, Rémi Denis-Courmont wrote:
Le 15 juin 2024 11:57:18 GMT+02:00, Zhao Zhili a é
This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)
This results in a file
On Mon, 17 Jun 2024, Gyan Doshi via ffmpeg-devel wrote:
On 2024-06-17 04:08 pm, Martin Storsjö wrote:
On Sat, 15 Jun 2024, Gyan Doshi wrote:
On 2024-06-15 03:54 am, Dennis Sädtler via ffmpeg-devel wrote:
On 2024-06-14 13:23, Gyan Doshi wrote:
On 2024-06-14 04:35 pm, Timo Rothenpieler
On Sun, 16 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Test on Apple M1 with kperf:
abgr_to_uv_8_c: 19.4
abgr_to_uv_8_neon: 29.9
abgr_to_uv_128_c: 146.4
abgr_to_uv_128_neon: 85.1
abgr_to_uv_1080_c: 1162.6
abgr_to_uv_1080_neon: 819.6
abgr_to_uv_1920_c: 2063.6
abgr_to_uv_1920_neon: 1435.1
abgr
On Sat, 15 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Test on Apple M1 with kperf
bgr24_to_uv_8_c: 41.5
bgr24_to_uv_8_neon: 41.8
bgr24_to_uv_128_c: 133.5
bgr24_to_uv_128_neon: 94.3
bgr24_to_uv_1080_c: 960.5
bgr24_to_uv_1080_neon: 751.0
bgr24_to_uv_1920_c: 1695.3
bgr24_to_uv_1920_neon: 1357.
On Sat, 15 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Test on Apple M1 with kperf
bgra_to_uv_8_c: 13.4
bgra_to_uv_8_neon: 37.4
bgra_to_uv_128_c: 155.9
bgra_to_uv_128_neon: 91.7
bgra_to_uv_1080_c: 1173.2
bgra_to_uv_1080_neon: 822.7
bgra_to_uv_1920_c: 2078.2
bgra_to_uv_1920_neon: 1437.7
bgra_
On Tue, 18 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
On m1, kpc_get_counter_count(KPC_MASK) return 8 in my test. The
exact value doesn't matter in our case, as long as we have a
sufficiently large array
Signed-off-by: Zhao Zhili
---
libavutil/macos_kperf.c | 16 ++--
1 file cha
On Mon, 17 Jun 2024, Zhao Zhili wrote:
On Jun 17, 2024, at 19:15, Martin Storsjö wrote:
On Wed, 12 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Firstly, make ff_kperf_cycles as an implementation of AV_READ_TIME
avoids code duplication.
Secondly, fix compilation error since 6a18c0bc87e
On Mon, 17 Jun 2024, Martin Storsjö wrote:
On Wed, 12 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Firstly, make ff_kperf_cycles as an implementation of AV_READ_TIME
avoids code duplication.
Secondly, fix compilation error since 6a18c0bc87e when macos-kperf
is enabled. mach_time.h is
On Wed, 12 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Firstly, make ff_kperf_cycles as an implementation of AV_READ_TIME
avoids code duplication.
Secondly, fix compilation error since 6a18c0bc87e when macos-kperf
is enabled. mach_time.h is included only when CONFIG_MACOS_KPERF
is 0. The err
On Wed, 12 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
On m1, kpc_get_counter_count(KPC_MASK) return 8. The exact value
doesn't matter in our case.
This is somewhat unexpected, I had expected that this API was originally
tested on an m1. I guess it might depend on what OS version you're us
On Sat, 15 Jun 2024, Gyan Doshi wrote:
On 2024-06-15 03:54 am, Dennis Sädtler via ffmpeg-devel wrote:
On 2024-06-14 13:23, Gyan Doshi wrote:
On 2024-06-14 04:35 pm, Timo Rothenpieler wrote:
On 14/06/2024 12:44, Martin Storsjö wrote:
On Fri, 14 Jun 2024, Gyan Doshi wrote:
On 2024-06-14 02
The default timer register pmccntr_el0 usually requires enabling
access with e.g. a kernel module.
On macOS, using cntvct_el0 gives measurements with the same
magnitude as mach_absolute_time (which is used currently), but
possibly with a little less overhead/noise.
---
cntvct_el0 should have less
On Fri, 14 Jun 2024, Timo Rothenpieler wrote:
On 14/06/2024 12:44, Martin Storsjö wrote:
On Fri, 14 Jun 2024, Gyan Doshi wrote:
On 2024-06-14 02:18 am, Martin Storsjö wrote:
On Thu, 13 Jun 2024, Gyan Doshi wrote:
On 2024-06-13 06:20 pm, Martin Storsjö wrote:
I'd otherwise want to
On Fri, 14 Jun 2024, Zhao Zhili wrote:
On Jun 13, 2024, at 20:54, Martin Storsjö wrote:
On Fri, 7 Jun 2024, Martin Storsjö wrote:
The default timer register pmccntr_el0 usually requires enabling
access with e.g. a kernel module.
---
cntvct_el0 has significantly better resolution than
On Fri, 14 Jun 2024, Gyan Doshi wrote:
On 2024-06-14 02:18 am, Martin Storsjö wrote:
On Thu, 13 Jun 2024, Gyan Doshi wrote:
On 2024-06-13 06:20 pm, Martin Storsjö wrote:
I'd otherwise want to push this, but I'm not entirely satisfied with
the option name quite yet. I'm
On Thu, 13 Jun 2024, Gyan Doshi wrote:
On 2024-06-13 06:20 pm, Martin Storsjö wrote:
On Wed, 5 Jun 2024, Martin Storsjö wrote:
This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point
On Fri, 7 Jun 2024, Martin Storsjö wrote:
The default timer register pmccntr_el0 usually requires enabling
access with e.g. a kernel module.
---
cntvct_el0 has significantly better resolution than
av_gettime_relative (while the unscaled nanosecond output of
clock_gettime is much higher
On Wed, 5 Jun 2024, Martin Storsjö wrote:
This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
On Fri, 7 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Test on Apple M1:
rgb24_to_uv_8_c: 0.0
rgb24_to_uv_8_neon: 0.2
rgb24_to_uv_128_c: 1.0
rgb24_to_uv_128_neon: 0.5
rgb24_to_uv_1080_c: 7.0
rgb24_to_uv_1080_neon: 5.7
rgb24_to_uv_1920_c: 12.5
rgb24_to_uv_1920_neon: 9.5
rgb24_to_uv_half_8_c: 0
On Fri, 7 Jun 2024, Ramiro Polla wrote:
chrRangeFromJpeg_8_c: 28.5
chrRangeFromJpeg_8_neon: 21.2
chrRangeFromJpeg_24_c: 81.2
chrRangeFromJpeg_24_neon: 34.7
chrRangeFromJpeg_128_c: 425.2
chrRangeFromJpeg_128_neon: 162.0
chrRangeFromJpeg_144_c: 480.2
chrRangeFromJpeg_144_neon: 180.2
chrRangeFromJp
On Sun, 9 Jun 2024, Rémi Denis-Courmont wrote:
This seems to have been omitted in
880e2aa23645ed9871c66ee1cbd00f93c72d2d73.
---
configure | 5 -
1 file changed, 5 deletions(-)
diff --git a/configure b/configure
index e69ed55837..4e27e6fd2b 100755
--- a/configure
+++ b/configure
@@ -2130,7 +2
On Sun, 9 Jun 2024, Rémi Denis-Courmont wrote:
The vendor has long since switched to Arm, wit the last product reaching
their official end-of-life over 11 years ago. Linux support for the ISA
was dropped 7 years ago. More importantly, this architecture was never
supported by upstream GCC, and th
On Fri, 7 Jun 2024, Zhao Zhili wrote:
On Jun 7, 2024, at 17:09, Martin Storsjö wrote:
On Fri, 7 Jun 2024, Zhao Zhili wrote:
Note both tests use clang as compiler, which has vectorization
enabled by default with -O3.
FWIW, for more interesting benchmarks, you can configure the build with
On Fri, 7 Jun 2024, Rémi Denis-Courmont wrote:
Le 7 juin 2024 12:12:45 GMT+03:00, "Martin Storsjö" a écrit :
The default timer register pmccntr_el0 usually requires enabling
access with e.g. a kernel module.
---
cntvct_el0 has significantly better resolution than
av_gettime_relat
The default timer register pmccntr_el0 usually requires enabling
access with e.g. a kernel module.
---
cntvct_el0 has significantly better resolution than
av_gettime_relative (while the unscaled nanosecond output of
clock_gettime is much higher resolution).
In one tested case, the cntvct_el0 timer
On Fri, 7 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
---
libavutil/timer.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavutil/timer.h b/libavutil/timer.h
index 2cd299eca3..74c4d84e69 100644
--- a/libavutil/timer.h
+++ b/libavutil/timer.h
@@ -46,6 +46,8 @@
#include "macos_kperf
On Fri, 7 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
It will fallback to mach_absolute_time inside libavutil/timer.h
---
libavutil/aarch64/timer.h | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/libavutil/aarch64/timer.h b/libavutil/aarch64/timer.h
index 8b28fd354c.
On Fri, 7 Jun 2024, Zhao Zhili wrote:
Note both tests use clang as compiler, which has vectorization
enabled by default with -O3.
FWIW, for more interesting benchmarks, you can configure the build with
--optflags="-O3 -fno-vectorize".
(Although, the benchmarks against a compiler vectorized
On Fri, 7 Jun 2024, Zhao Zhili wrote:
On Jun 7, 2024, at 16:21, Martin Storsjö wrote:
On Fri, 7 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
B0 is defined by system header.
Can you add more details about which header defines this? (I did a quick grep
in a copy of the android NDK
On Fri, 7 Jun 2024, Martin Storsjö wrote:
On Fri, 7 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
B0 is defined by system header.
Can you add more details about which header defines this? (I did a quick grep
in a copy of the android NDK, and found it in asm-generic/termbits-common.h
On Fri, 7 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
B0 is defined by system header.
Can you add more details about which header defines this? (I did a quick
grep in a copy of the android NDK, and found it in
asm-generic/termbits-common.h.)
// Martin
__
This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)
This results in a file
On Tue, 4 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
Test on Apple M1:
rgb24_to_uv_1080_c: 7.2
rgb24_to_uv_1080_neon: 5.5
rgb24_to_uv_1280_c: 8.2
rgb24_to_uv_1280_neon: 6.2
rgb24_to_uv_1920_c: 12.5
rgb24_to_uv_1920_neon: 9.5
rgb24_to_uv_half_540_c: 6.5
rgb24_to_uv_half_540_neon: 3.0
rgb24_
On Wed, 5 Jun 2024, Zhao Zhili wrote:
On Jun 5, 2024, at 14:29, Rémi Denis-Courmont wrote:
Le 4 juin 2024 16:55:01 GMT+03:00, Zhao Zhili mailto:quinkbl...@foxmail.com>> a écrit :
From: Zhao Zhili
Test on Apple M1:
rgb24_to_uv_1080_c: 7.2
rgb24_to_uv_1080_neon: 5.5
rgb24_to_uv_1280_c: 8.2
r
On Tue, 4 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
The inline asm doesn't work on Android.
Using pmccntr_el0 doen't work, no, but instead of falling back to
clock_gettime, you may want to use cntvct_el0 instead of pmccntr_el0. IIRC
that works on Android, at least it worked a number of
On Mon, 3 Jun 2024, Zhao Zhili wrote:
diff --git a/libswscale/aarch64/input.S b/libswscale/aarch64/input.S
new file mode 100644
index 00..0a46475723
--- /dev/null
+++ b/libswscale/aarch64/input.S
@@ -0,0 +1,229 @@
+/*
+ * Copyright (c) 2024 Zhao Zhili
+ *
+ * This file is part of FFmpeg
On Mon, 3 Jun 2024, Zhao Zhili wrote:
From: Zhao Zhili
---
I need help on the test. It succeed with the following patch on ARM64,
but failed with x86. I'm not sure whether the issue is in the test, or
hidden in x86 asm, and I don't know x86 asm.
Note that by default, the output of swscale ca
On Sun, 2 Jun 2024, Dennis Sädtler wrote:
On 2024-06-02 21:36, Martin Storsjö wrote:
On Sat, 1 Jun 2024, Dennis Sädtler via ffmpeg-devel wrote:
Should the ftyp atom also be updated to remove brands no longer required
for non-fragmented files?
I'm not sure how important that is in real-
On Sat, 1 Jun 2024, Dennis Sädtler via ffmpeg-devel wrote:
Should the ftyp atom also be updated to remove brands no longer required
for non-fragmented files?
I'm not sure how important that is in real-world scenarios, so it might
not be worth it to deal with some of the additional changes requi
On Fri, 31 May 2024, Timo Rothenpieler wrote:
On 31/05/2024 10:53, Martin Storsjö wrote:
This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the
This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)
This results in a file
On Wed, 22 May 2024, Andreas Rheinhardt wrote:
VVC does not have MMX code at all, so one can use the stricter
declare_func to also check that the MMX state has not been clobbered
with (which would be an ABI violation).
Signed-off-by: Andreas Rheinhardt
---
tests/checkasm/vvc_alf.c | 4 ++--
1 f
The loop filters can write before the pointer given to them;
the actual test invocations correctly used an offset, while
the benchmark calls were lacking an offset. Therefore, when
running with benchmarking, these tests could have spurious
failures.
---
tests/checkasm/h264dsp.c | 4 ++--
1 file ch
On Tue, 21 May 2024, Martin Storsjö wrote:
Don't benchmark every single combination of widths and heights;
only benchmark cases which are squares (like in vvc_mc.c).
Contrary to vvc_mc, which increases sizes by doubling dimensions,
vvc_alf tests all sizes in increments of 4. Limit benchma
On Tue, 21 May 2024, Rémi Denis-Courmont wrote:
Le 21 mai 2024 09:37:18 GMT+03:00, "Martin Storsjö" a écrit :
On Tue, 21 May 2024, Rémi Denis-Courmont wrote:
Hi,
VVC benchmarks have increased checksam runtime by at least an order of
magnitude. It's become so prohibitiv
Don't benchmark every single combination of widths and heights;
only benchmark cases which are squares (like in vvc_mc.c).
Contrary to vvc_mc, which increases sizes by doubling dimensions,
vvc_alf tests all sizes in increments of 4. Limit benchmarking to
the cases which are powers of two.
This re
On Tue, 21 May 2024, Rémi Denis-Courmont wrote:
Hi,
Le 20 mai 2024 03:42:03 GMT+03:00, Stone Chen a
écrit :
Adds checkasm for DMVR SAD AVX2 implementation.
Benchmarks ( AMD 7940HS )
vvc_sad_8x8_c: 70.0
vvc_sad_8x8_avx2: 10.0
vvc_sad_16x16_c: 280.0
vvc_sad_16x16_avx2: 20.0
vvc_sad_32x32_c: 1
On Sat, 11 May 2024, Ramiro Polla wrote:
On Sun, Jan 21, 2024 at 10:57 PM Ramiro Polla wrote:
---
libavcodec/aarch64/idctdsp_init_aarch64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/aarch64/idctdsp_init_aarch64.c
b/libavcodec/aarch64/idctdsp_init_aarch64
On Sat, 11 May 2024, Lynne via ffmpeg-devel wrote:
Unintentionally removed as part of 03cf10164578aed33f4d0cb5b69d63669c01a538.
Untested, but its assumed that unlike most of the old ARM code,
this one was still working.
---
libavcodec/aac/aacdec_float.c | 5 +
1 file changed, 5 insertions(+)
On Tue, 7 May 2024, Rémi Denis-Courmont wrote:
---
Makefile | 2 +-
configure | 3 +++
doc/APIchanges| 3 +++
ffbuild/arch.mak | 1 +
libavutil/cpu.h | 1 +
libavutil/tests/cpu.c | 1 +
tests/checkasm/checkasm.c | 1 +
7 files changed,
On Tue, 7 May 2024, Rémi Denis-Courmont wrote:
---
libavutil/riscv/cpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
index c3683b06d0..69d1afe853 100644
--- a/libavutil/riscv/cpu.c
+++ b/libavutil/riscv/cpu.c
@@ -29,14 +29,
On Tue, 7 May 2024, Andreas Rheinhardt wrote:
Martin Storsjö:
On Mon, 6 May 2024, James Almer wrote:
It ignores and overwrites the previous values.
Fixes running the test under ubsan.
Signed-off-by: James Almer
---
tests/checkasm/blockdsp.c | 3 ++-
1 file changed, 2 insertions(+), 1
On Mon, 6 May 2024, James Almer wrote:
It ignores and overwrites the previous values.
Fixes running the test under ubsan.
Signed-off-by: James Almer
---
tests/checkasm/blockdsp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
The change is probably correct, but what issue is ubsan co
On Fri, 3 May 2024, Rémi Denis-Courmont wrote:
This adds the Linux-specific function call to detect CPU features. Unlike
the more portable auxillary vector, this supports extensions other than
single lettered ones. At this point, FFmpeg already needs this to detect
Zba and Zbb at run-time, and p
On Tue, 30 Apr 2024, Andreas Rheinhardt wrote:
Regression since fd172185580c1ccdcfb90bbfdb59fa806fad3117;
triggered by vp4/KTkvw8dg1J8.avi in the FATE suite, but not
when running fate as this code is not used when the bitexact
flag is set.
Bisecting done by ami_stuff, patch from user Mika Fisch
This fixes crashes in the mspel tests on x86.
---
tests/checkasm/vc1dsp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tests/checkasm/vc1dsp.c b/tests/checkasm/vc1dsp.c
index 407d9e5fe8..f18f0f8251 100644
--- a/tests/checkasm/vc1dsp.c
+++ b/tests/checkasm/vc1dsp.c
@@
On Thu, 25 Apr 2024, Derek Buitenhuis wrote:
Changes since last set:
* Updated commit message with RFC references.
* Properly support Retry-After as both a date and integer number of seconds.
I have tested this against both an HTTP-Date and seconds, and confirmed
it to work.
Derek Buitenhuis
On Mon, 22 Apr 2024, Derek Buitenhuis wrote:
This patch set adds support for properly handling HTTP 429 codes,
and their rate limiting, which is widely used and is standardized.
Changes since first set:
* Added AVERROR_HTTP_TOO_MANY_REQUESTS top error_entries in error.c, per
Andreas' review.
On Mon, 22 Apr 2024, Derek Buitenhuis wrote:
Not every use case benefits from setting retries in terms of the backoff.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c| 12 +---
libavformat/version.h | 2 +-
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/libav
On Mon, 22 Apr 2024, Derek Buitenhuis wrote:
429 and 503 codes can, and often do (e.g. all Google Cloud
Storage URLs can), return a Retry-After header with the error,
indicating how long to wait, in seconds, before retrying again.
If it is not respected by, for example, using our default backoff
On Mon, 22 Apr 2024, Derek Buitenhuis wrote:
Added in thep previous commit.
Signed-off-by: Derek Buitenhuis
---
libavformat/http.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/http.c b/libavformat/http.c
index ed20359552..bbace2694f 100644
--- a/libavformat/http.c
+++ b
On Mon, 22 Apr 2024, Derek Buitenhuis wrote:
Added in thep previous commit.
Typo in the commit message
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link abov
On Wed, 17 Apr 2024, Marvin Scholz wrote:
This fixes the checks to properly use runtime feature detection and
check the SDK version (*_MAX_ALLOWED) instead of the targeted version
for the relevant APIs.
As these things are pretty hard to think straight about, it could be good
with a more conc
On Wed, 17 Apr 2024, Ramiro Polla wrote:
This patch set adds fdct to checkasm and neon-optimized fdct for aarch64.
Ramiro Polla (2):
checkasm: add test for fdct
lavc/aarch64/fdct: add neon-optimized fdct for aarch64
libavcodec/aarch64/Makefile | 2 +
libavcodec/aarch64/fdct.h
Travis is no longer relevant for attempting to run CI jobs in our
setup.
---
.travis.yml | 30 --
1 file changed, 30 deletions(-)
delete mode 100644 .travis.yml
diff --git a/.travis.yml b/.travis.yml
deleted file mode 100644
index 784b7bdf73..00
--- a/.travis.
On Wed, 17 Apr 2024, Ramiro Polla wrote:
The code is imported from libjpeg-turbo-3.0.1. The neon registers used
have been changed to avoid modifying v8-v15.
---
libavcodec/aarch64/Makefile | 2 +
libavcodec/aarch64/fdct.h | 26 ++
libavcodec/aarch64/fdctdsp_init_aa
On Wed, 10 Apr 2024, J. Dekker wrote:
The exclude_guest option only has an effect on x86. Omitting
'exclude_guest' defaults to zero which implies that you can count guest
events should you run one. Some non-x86 kernels just ignore it, while
others (e.g. the Asahi Linux kernels) require the user
On Tue, 9 Apr 2024, James Almer wrote:
On 4/4/2024 7:29 AM, Martin Storsjö wrote:
This is based on a spec at https://aomediacodec.github.io/id3-emsg/,
further based on ISO/IEC 23009-1:2019.
Within libavformat, timed ID3 metadata (already supported by the
mpegts demuxer and muxer) is handled
101 - 200 of 1052 matches
Mail list logo
