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
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:
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
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
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 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
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 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
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 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 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 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 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 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
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_
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 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
__
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:
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, 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:
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:
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
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, 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
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 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 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 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 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 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, 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 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, 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 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, 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
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 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
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 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 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 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 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 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 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 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 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
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 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 é
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 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 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
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
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->
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, 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
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
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
abgr_to_uv_8_c : 19.4 : 26.1
abgr_to_uv_8_neon : 29.9 : 51.1
abgr_to_uv_128_c
---
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
---
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
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':
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
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
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->
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
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, 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
On Tue, 28 Sep 2021, Andreas Rheinhardt wrote:
This patch increases several stack buffers in order to fix
stack-buffer-overflows (e.g. in put_hevc_qpel_uni_hv_9 in
line 814 of hevcdsp_template.c) detected with ASAN in the hevc_pel
checkasm test.
The buffers are increased by the minimal amount ne
The refactoring in 844890b1bc86316a38bc9e1dbf8ba0dd254307e3 caused
fate-source to point out that this could be av_clip_uintp2.
Signed-off-by: Martin Storsjö
---
libavfilter/vf_fftfilt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_fftfilt.c b/libavfilter
oming Clang 14) enabled an optimization
that does this, which broke the current version of this function
(which intentionally left the variables uninitialized, but silencing
warnings about being uninitialized). See [1] for discussion on
the matter.
[1] https://reviews.llvm.org/D105169#3069555
Sig
On Fri, 3 Sep 2021, Martin Storsjö wrote:
This gives rather big speedups on these functions:
Before:
put_h264_qpel_8_mc01_8_neon: 241.0 131.5 138.7
put_h264_qpel_8_mc02_8_neon: 214.7 121.2 127.5
put_h264_qpel_8_mc03_8_neon: 242.5 131.2 135.7
put_h264_qpel_8_mc11_8_neon
On Mon, 18 Oct 2021, Paul B Mahol wrote:
lgtm
Thanks, pushed.
// 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-requ...@ffmpeg.o
On Sat, 16 Oct 2021, J. Dekker wrote:
Signed-off-by: J. Dekker
---
libavcodec/arm/hevcdsp_init_neon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/arm/hevcdsp_init_neon.c
b/libavcodec/arm/hevcdsp_init_neon.c
index 201a088dac..112edb5edd 100644
--- a/libavcode
On Sat, 16 Oct 2021, J. Dekker wrote:
This reverts commit 2589060b92eeeb944c6e2b50e38412c0c5fabcf4.
Signed-off-by: J. Dekker
---
libavcodec/arm/hevcdsp_qpel_neon.S | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
Ok, once commit 1/2 is finalized. But it would be good t
On Thu, 7 Oct 2021, J. Dekker wrote:
--bench on AWS Graviton:
hevc_sao_edge_16x16_8_c: 1857.0
hevc_sao_edge_16x16_8_neon: 211.0
hevc_sao_edge_32x32_8_c: 7802.2
hevc_sao_edge_32x32_8_neon: 808.2
hevc_sao_edge_48x48_8_c: 16764.2
hevc_sao_edge_48x48_8_neon: 1796.5
hevc_sao_edge_64x64_8_c: 32647.5
On Thu, 7 Oct 2021, J. Dekker wrote:
--bench on AWS Graviton:
hevc_sao_edge_8x8_8_c: 516.0
hevc_sao_edge_8x8_8_neon: 81.0
Signed-off-by: J. Dekker
---
libavcodec/aarch64/hevcdsp_init_aarch64.c | 3 ++
libavcodec/aarch64/hevcdsp_sao_neon.S | 52 +++
2 files changed, 55 i
On Thu, 7 Oct 2021, J. Dekker wrote:
--bench on AWS Graviton:
hevc_sao_band_8x8_8_c: 317.5
hevc_sao_band_8x8_8_neon: 97.5
hevc_sao_band_16x16_8_c: 1115.0
hevc_sao_band_16x16_8_neon: 322.7
hevc_sao_band_32x32_8_c: 4599.2
hevc_sao_band_32x32_8_neon: 1246.2
hevc_sao_band_48x48_8_c: 10021.7
hevc_sa
On Thu, 7 Oct 2021, J. Dekker wrote:
--bench on AWS Graviton:
hevc_sao_edge_16x16_8_c: 1857.0
hevc_sao_edge_16x16_8_neon: 211.0
hevc_sao_edge_32x32_8_c: 7802.2
hevc_sao_edge_32x32_8_neon: 808.2
hevc_sao_edge_48x48_8_c: 16764.2
hevc_sao_edge_48x48_8_neon: 1796.5
hevc_sao_edge_64x64_8_c: 32647.5
On Thu, 7 Oct 2021, J. Dekker wrote:
Signed-off-by: J. Dekker
---
libavcodec/aarch64/hevcdsp_sao_neon.S | 103 +++---
1 file changed, 44 insertions(+), 59 deletions(-)
diff --git a/libavcodec/aarch64/hevcdsp_sao_neon.S
b/libavcodec/aarch64/hevcdsp_sao_neon.S
index 263747149
On Tue, 26 Oct 2021, J. Dekker wrote:
On 19 Oct 2021, at 10:40, Martin Storsjö wrote:
This one had the right indentation to start with, don't reindent it
according to the new incorrectly indented code you're adding.
Yep. This was a mistake, some of (my) previously pushed code i
On Thu, 28 Oct 2021, Steven Liu wrote:
2021年10月28日 下午2:32，Lingjiang Fang 写道：
keep align with movenc, or it seems a little weired when debug
---
libavformat/flvenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 3f24c7e192..f4798dc9a6
On Sat, 6 Nov 2021, Andreas Rheinhardt wrote:
Martin Storsjö:
Passing an uninitialized variable as argument to a function is
undefined behaviour (UB). The compiler can assume that UB does not
happen.
Hence, the compiler can assume that the variables are never
uninitialized when passed as
On Sat, 6 Nov 2021, Andreas Rheinhardt wrote:
Martin Storsjö:
On Sat, 6 Nov 2021, Andreas Rheinhardt wrote:
For GCC and Clang av_uninit(x) is defined as x=x. And that is a problem:
In case this macro is used to declare an automatic variable that is
could be declared with the register storage
On Fri, 12 Nov 2021, Lynne wrote:
The UUID library is even more ubiquitous than iconv, and it hasn't
changed its API and ABI for maybe 20 years.
MediaFoundation and dshow already depends on it silently, and
The "uuid" library on Windows is something entirely different, it's just a
collection
On Fri, 12 Nov 2021, Jonathan Wright wrote:
Hi,
This patch changes all AArch64 assembly code to use:
ret x
instead of:
br x
"ret x" is already used in a lot of places so this patch makes it
consistent across the code base. This does not change behavior or
performance.
In addition,
On Fri, 12 Nov 2021, Jonathan Wright wrote:
Hi,
This patch adds Branch Target Identifiers (BTIs) to all functions defined
in AArch64 assembly files. Most of the BTI landing pads are added
automatically by the 'function' macro.
BTI support is turned on or off at compile time based on the presen
On Wed, 17 Nov 2021, J. Dekker wrote:
The assembly is written assuming that the width is a multiple of 8.
However the real issue is the functions were errorneously assigned to
the 2, 4, 6 & 12 widths. This behaviour never broke the decoder as
samples which trigger the functions for these widths
On Wed, 17 Nov 2021, J. Dekker wrote:
This reverts commit 2589060b92eeeb944c6e2b50e38412c0c5fabcf4 which was
originally to fix the FATE test. The real cause of the test breakage was
fixed in 8dc8f04036eb27c8ad419839d4ed3bc67c44fe7a.
Signed-off-by: J. Dekker
LGTM. (Remember to update the comm
On Wed, 17 Nov 2021, J. Dekker wrote:
--bench on AWS Graviton:
hevc_sao_edge_16x16_8_c: 1857.0
hevc_sao_edge_16x16_8_neon: 211.0
hevc_sao_edge_32x32_8_c: 7802.2
hevc_sao_edge_32x32_8_neon: 808.2
hevc_sao_edge_48x48_8_c: 16764.2
hevc_sao_edge_48x48_8_neon: 1796.5
hevc_sao_edge_64x64_8_c: 32647.5
On Wed, 17 Nov 2021, J. Dekker wrote:
--bench on AWS Graviton:
hevc_sao_edge_8x8_8_c: 516.0
hevc_sao_edge_8x8_8_neon: 81.0
Signed-off-by: J. Dekker
---
libavcodec/aarch64/hevcdsp_init_aarch64.c | 3 ++
libavcodec/aarch64/hevcdsp_sao_neon.S | 51 +++
2 files changed, 54
On Wed, 17 Nov 2021, J. Dekker wrote:
--bench on AWS Graviton:
hevc_sao_band_8x8_8_c: 317.5
hevc_sao_band_8x8_8_neon: 97.5
hevc_sao_band_16x16_8_c: 1115.0
hevc_sao_band_16x16_8_neon: 322.7
hevc_sao_band_32x32_8_c: 4599.2
hevc_sao_band_32x32_8_neon: 1246.2
hevc_sao_band_48x48_8_c: 10021.7
hevc_s
On Wed, 17 Nov 2021, J. Dekker wrote:
Signed-off-by: J. Dekker
---
libavcodec/aarch64/hevcdsp_sao_neon.S | 195 --
1 file changed, 90 insertions(+), 105 deletions(-)
Now matches the 9,25 indentation like other ASM.
No it doesn't.
This changes the indentation of the pr
On Thu, 25 Nov 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/udp.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/libavformat/udp.c b/libavformat/udp.c
index bbe5aec..b8b0e19 100644
--- a/libavformat/udp.c
+++ b/l
On Thu, 25 Nov 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/protocols.texi | 4
libavformat/rtpproto.c | 17 ++---
libavformat/rtsp.c | 3 +++
libavformat/rtsp.h | 1 +
4 files changed, 22 insertions(+), 3 deletions(-)
dif
On Thu, 25 Nov 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
doc/protocols.texi | 4
libavformat/rtpproto.c | 17 ++---
libavformat/rtsp.c | 3 +++
libavformat/rtsp.h | 1 +
4 files changed, 22 insertions(+), 3 deletions(-)
dif
On Fri, 26 Nov 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
Reviewed-by: Martin Storsjö
Technically, I haven't reviewed this version yet - including such a header
would indicate that I have approvd it, which I haven't.
Although in practice, this version looks fine to m
On Wed, 1 Dec 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/rtsp.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index e6a4993..ec8be8b 100644
--- a/l
On Wed, 1 Dec 2021, lance.lmw...@gmail.com wrote:
On Wed, Dec 01, 2021 at 03:55:37PM +0200, Martin Storsjö wrote:
On Wed, 1 Dec 2021, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavformat/rtsp.c | 30
On Thu, 2 Dec 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/rtsp.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index e6a4993..249a019 100644
--- a/libavform
On Thu, 2 Dec 2021, lance.lmw...@gmail.com wrote:
From: Limin Wang
this allows getting rid of the hardcoded max size of SDP.
Reviewed-by: Martin Storsjö
Signed-off-by: Limin Wang
---
libavformat/rtsp.c | 25 +
1 file changed, 9 insertions(+), 16 deletions(-)
LGTM
1 - 100 of 1464 matches
Mail list logo
