> On May 20, 2024, at 09:12, Marvin Scholz wrote:
>
> Fix #10884
LGTM except the commit subject should mention videotoolbox or vt in short.
> ---
> libavutil/hwcontext_videotoolbox.c | 54 +-
> 1 file changed, 38 insertions(+), 16 deletions(-)
>
> diff --git a/lib
From: Zhao Zhili
It's a common usecase to request a video size after crop. Before
this patch, user must know the video size before crop, then set
crop_right/crop_bottom accordingly. Since HEVC can have different
CTU size, it's not easy to get/deduce the video size before crop.
With the
From: Zhao Zhili
Signed-off-by: Zhao Zhili
---
libavcodec/mediacodecenc.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mediacodecenc.c b/libavcodec/mediacodecenc.c
index bfff149039..a42270551b 100644
--- a/libavcodec/mediacodecenc.c
+++ b
From: Zhao Zhili
It's a common usecase to request a video size after crop. Before
this patch, user must know the video size before crop, then set
crop_right/crop_bottom accordingly. Since HEVC can have different
CTU size, it's not easy to get/deduce the video size before crop.
With the
From: Zhao Zhili
There is no bsf for other codecs to modify crop info except H.265.
For H.265, the assumption that FFALIGN(width, 16)xFFALIGN(height, 16)
is the video resolution can be wrong, since the encoder can use CTU
larger than 16x16. In that case, use FFALIGN(width, 16) - width
as
From: Zhao Zhili
There is no bsf for other codecs to modify crop info except H.265.
For H.265, the assumption that FFALIGN(width, 16)xFFALIGN(height, 16)
is the video resolution can be wrong, since the encoder can use CTU
larger than 16x16. In that case, use FFALIGN(width, 16) - width
as
From: Zhao Zhili
---
The patchset for master branch isn't suitable for release branch, since it
implement a new feature in bsf.
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=11882
libavcodec/mediacodecenc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
> On May 23, 2024, at 15:08, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> Signed-off-by: Zhao Zhili
> ---
> libavcodec/mediacodecenc.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/mediacodecenc.c b/libavcodec/medi
> On May 21, 2024, at 09:56, Gnattu OC via ffmpeg-devel
> wrote:
>
>>
>> On May 20, 2024, at 09:12, Marvin Scholz wrote:
>>
>> Fix #10884
>> ---
>> libavutil/hwcontext_videotoolbox.c | 54 +-
>> 1 file changed, 38 insertions(+), 16 deletions(-)
>>
>> diff --git
> On May 24, 2024, at 02:41, epira...@gmail.com wrote:
>
>
> On 23 May 2024, at 18:05, Zhao Zhili wrote:
>
>>> On May 21, 2024, at 09:56, Gnattu OC via ffmpeg-devel
>>> wrote:
>>>
>>>>
>>>> On May 20, 2024, at 09:12, M
> On May 27, 2024, at 23:22, Rémi Denis-Courmont wrote:
>
> The generally expected behaviour is for software to append from the
> current position, not to keep resetting. See also how shell works:
> # (foo && bar) > file
> ...would normally concatenate the output of both commands to file.
>
>
+682,13 @@ bailout:
> static av_cold int mediacodec_close(AVCodecContext *avctx)
> {
> MediaCodecEncContext *s = avctx->priv_data;
> +
> +#if __ANDROID_API__ >= 26
> +if (strlen(s->bitrate_ctrl_socket) != 0) {
> +mediacodecenc_ctrl_deinit(avctx);
> +
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.
tests/checkasm/sw_rgb.c | 126
1 fi
From: Zhao Zhili
Test on Apple M1:
rgb24_to_uv_1080_c: 7.0
rgb24_to_uv_1080_neon: 5.5
rgb24_to_uv_1280_c: 8.2
rgb24_to_uv_1280_neon: 6.0
rgb24_to_uv_4096_c: 26.2
rgb24_to_uv_4096_neon: 20.7
rgb24_to_uv_half_540_c: 6.5
rgb24_to_uv_half_540_neon: 3.0
rgb24_to_uv_half_640_c: 8.0
From: Zhao Zhili
---
The test still failed on x86, but success on arm64 and longarch.
I have tried to call rgb24ToY_c and ff_rgb24ToY_avx directly and
compare the results, they don't match.
https://github.com/quink-black/FFmpeg/actions/runs/9347753270
https://patchwork.ffmpeg.org/pr
From: Zhao Zhili
Test on Apple M1:
rgb24_to_uv_1080_c: 7.0
rgb24_to_uv_1080_neon: 5.5
rgb24_to_uv_1280_c: 8.2
rgb24_to_uv_1280_neon: 6.0
rgb24_to_uv_4096_c: 26.2
rgb24_to_uv_4096_neon: 20.7
rgb24_to_uv_half_540_c: 6.5
rgb24_to_uv_half_540_neon: 3.0
rgb24_to_uv_half_640_c: 8.0
> On Jun 3, 2024, at 16:07, Martin Storsjö wrote:
>
> 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/li
> On Jun 3, 2024, at 22:17, Rémi Denis-Courmont wrote:
>
> Le maanantaina 3. kesäkuuta 2024, 16.11.15 EEST Zhao Zhili a écrit :
>>> See https://github.com/mstorsjo/FFmpeg/actions/runs/9346228714 for one
>>> example run of these actions with your patches.
>> Wo
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..fadc9568f8 100644
--- a/libavutil
From: Zhao Zhili
---
tests/checkasm/sw_rgb.c | 103
1 file changed, 103 insertions(+)
diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index 7cd815e5be..cc9b957461 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -24,6
From: Zhao Zhili
The inline asm doesn't work on Android.
---
libavutil/aarch64/timer.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/aarch64/timer.h b/libavutil/aarch64/timer.h
index fadc9568f8..13a58b48e4 100644
--- a/libavutil/aarch64/timer.h
+++ b/liba
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.h"
#elif HAVE_MACH_ABS
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_to_uv_half_640_c: 7.5
> On Jun 4, 2024, at 21:58, James Almer wrote:
>
> On 6/4/2024 10:55 AM, Zhao Zhili wrote:
>> From: Zhao Zhili
>> ---
>> tests/checkasm/sw_rgb.c | 103
>> 1 file changed, 103 insertions(+)
>> diff --git a/t
> 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
&g
From: Zhao Zhili
The line width 8 is supposed to test corner case, while the
performance doesn't matter. Width 1080 is also a case of
unaligned to 16.
Width 1920 meant for benchmark (together with --runs options).
---
v2: add bgr24 support
Feel free to remove 128 and/or 1280 from input_
> On Jun 6, 2024, at 19:51, Shiqi Zhu wrote:
I’m afraid this has the same issue as libavdevice/sdl[1].
[1]
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230918063728.198377-1-haihao.xi...@intel.com/
>
> Signed-off-by: Shiqi Zhu
> ---
> configure| 1 +
> libavfilt
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..fadc9568f8 100644
--- a/libavutil
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.h"
#elif HAVE_MACH_ABS
From: Zhao Zhili
B0 is defined by system header.
---
tests/checkasm/llviddsp.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/tests/checkasm/llviddsp.c b/tests/checkasm/llviddsp.c
index b75c0ea099..9f8de65df4 100644
--- a/tests/checkasm/llviddsp.c
+++ b
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.2
rgb24_to_uv_half_8_neon: 0.2
> On Jun 7, 2024, at 10:12, Hiccup Zhu wrote:
>
> On Thu, 6 Jun 2024 at 20:20, Zhao Zhili wrote:
>>
>>
>> On Jun 6, 2024, at 19:51, Shiqi Zhu wrote:
>>
>>
>> I’m afraid this has the same issue as libavdevice/sdl[1].
>>
>>
> 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
> On Jun 7, 2024, at 16:38, Martin Storsjö wrote:
>
> 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
> 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 buil
> 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 buil
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..fadc9568f8 100644
--- a/libavutil
From: Zhao Zhili
---
v3: add ff_read_time() rather than use av_gettime_relative() to get
nanosecond precision.
libavutil/timer.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavutil/timer.h b/libavutil/timer.h
index 2cd299eca3..3e5d5ef23f 100644
--- a/libavutil/timer.h
From: Zhao Zhili
B0 is defined by system header, see f0f596dbc6b for ref.
---
v3: add f0f596dbc6b as ref.
tests/checkasm/llviddsp.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/tests/checkasm/llviddsp.c b/tests/checkasm/llviddsp.c
index b75c0ea099
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.2
rgb24_to_uv_half_8_neon: 0.2
> On Jun 10, 2024, at 19:59, Martin Storsjö wrote:
>
> On Fri, 7 Jun 2024, Zhao Zhili wrote:
>
>> From: Zhao Zhili
>>
>
> No further comments from me, on this patchset. (Rémi had a comment on 2/4
> though - I don't have a strong opinion on that matter
From: Zhao Zhili
On m1, kpc_get_counter_count(KPC_MASK) return 8. The exact value
doesn't matter in our case.
---
libavutil/macos_kperf.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/libavutil/macos_kperf.c b/libavutil/macos_kperf.c
index a0bc8
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 error happened due to define
From: Zhao Zhili
The check should be >= 0, not > 0. The check itself is redundant
since uninit only being called after init is success.
---
tests/checkasm/checkasm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> On Jun 13, 2024, at 10:04, Shiqi Zhu wrote:
>
> On Thu, 13 Jun 2024 at 01:36, Zhao Zhili <mailto:quinkbl...@foxmail.com>> wrote:
>>
>> From: Zhao Zhili
>>
>> The check should be >= 0, not > 0. The check itself is redundant
>>
> 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
>> av_gettime_relative (whil
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.3
bgr24_to_uv_half_8_c: 45.0
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_to_uv_half_8_c: 17.9
> On Jun 14, 2024, at 19:09, Martin Storsjö wrote:
>
> 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
> possibl
> On Jun 12, 2024, at 23:22, 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_t
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_to_uv_half_8_c: 16.4
From: Zhao Zhili
When thread_count be zero, it will be run on current thread like
!HAVE_THREADS.
---
libavutil/executor.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/libavutil/executor.c b/libavutil/executor.c
index 26691fe157..fb20104b58
From: Zhao Zhili
---
libavcodec/vvc/dec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index f5603306f3..4ce2b1c6bd 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -1024,7 +1024,7 @@ static av_cold int
> On Jun 17, 2024, at 15:05, Anton Khirnov wrote:
>
> Quoting Zhao Zhili (2024-06-17 07:19:26)
>> From: Zhao Zhili
>>
>> When thread_count be zero, it will be run on current thread like
>> !HAVE_THREADS.
>
> Other APIs treat zero to mean "auto&
> On Jun 17, 2024, at 16:45, Hendrik Leppkes wrote:
>
> On Mon, Jun 17, 2024 at 10:03 AM Zhao Zhili wrote:
>>
>>
>>
>>> On Jun 17, 2024, at 15:05, Anton Khirnov wrote:
>>>
>>> Quoting Zhao Zhili (2024-06-17 07:19:26)
>>>>
> 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 comp
> On Jun 17, 2024, at 19:10, Martin Storsjö wrote:
>
> 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 somewh
From: Zhao Zhili
mach/mach_time.h was included only when CONFIG_MACOS_KPERF wasn't
been defined.
Signed-off-by: Zhao Zhili
---
libavutil/timer.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavutil/timer.h b/libavutil/timer.h
index 6bd6a0c645..9fe6aa1385 1
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 changed, 10 insertions(+), 6 dele
> On Jun 18, 2024, at 19:50, Nuo Mi wrote:
>
> On Mon, Jun 17, 2024 at 5:28 PM Zhao Zhili wrote:
>
>>
>>
>>> On Jun 17, 2024, at 16:45, Hendrik Leppkes wrote:
>>>
>>> On Mon, Jun 17, 2024 at 10:03 AM Zhao Zhili
>> wrote:
>>
> 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
> écrit :
>> From: Zhao Zhili
>>
>> Test on Apple M1 with kperf
>>
>> bgra_to_uv_8_c: 13.4
>> bgra_to_uv_8_neon: 37.4
&
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_to_uv_half_8_c: 16.4
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_to_uv_half_8_c: 17.9
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.3
bgr24_to_uv_half_8_c: 45.0
> 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:
>>>
>>&
> On Jun 20, 2024, at 20:49, Martin Storsjö wrote:
>
> 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
From: Zhao Zhili
Make its behavior consistent with other decoders, e.g., H.264/H.265.
Signed-off-by: Zhao Zhili
---
libavcodec/vvc/dec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index f5603306f3..4ce2b1c6bd 100644
--- a
From: Zhao Zhili
Before the patch, disable threads support at configure/build time
was the only method to force zero thread in executor. However,
it's common practice for libavcodec to run on caller's thread when
user specify thread number to one. And for WASM environment, whether
t
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: 155.9 : 550.2
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 : 294.0 : 830.7
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: 146.4 : 558.9
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 : 294.0 : 830.7
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: 155.9 : 550.2
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: 146.4 : 558.9
> On Jun 24, 2024, at 19:55, Martin Storsjö wrote:
>
> 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
From: Zhao Zhili
configure use "-Wl,-framework,foo" and "-framework foo" to specify
dependencies on Apple frameworks. These two styles essentially do
the same thing when build ffmpeg. However, they do make difference
when generate pkg-config files. Some tools interact wi
From: Zhao Zhili
With wasi-sdk toolchain [1], now you can
./configure --cc=${wasi-sdk}/bin/clang \
--cxx=${wasi-sdk}/bin/clang++ \
--ar=${wasi-sdk}/bin/ar \
--strip=${wasi-sdk}/bin/strip \
--nm=${wasi-sdk}/bin/llvm-nm \
--ranlib=${wasi-sdk}/bin/ranlib
From: Zhao Zhili
configure use "-Wl,-framework,foo" and "-framework foo" to specify
dependencies on Apple frameworks. These two styles essentially do
the same thing when build ffmpeg. However, they do make difference
when generate pkg-config files. Some tools interact wi
From: Zhao Zhili
Don't assume tempnam is available when !HAVE_MKSTEMP. Check tempnam
explicitly in configure.
Signed-off-by: Zhao Zhili
---
configure | 2 ++
libavutil/file_open.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
From: Zhao Zhili
fd_dup is unused when fd and pipe have been disabled. This also
fix build error with wasi since 'dup' isn't available.
Signed-off-by: Zhao Zhili
---
libavformat/file.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/file.c b/libavform
> On Jun 22, 2024, at 21:13, Niklas Haas wrote:
>
> Hey,
>
> As some of you know, I got contracted (by STF 2024) to work on improving
> swscale, over the course of the next couple of months. I want to share my
> current plans and gather feedback + measure sentiment.
>
> ## Problem statement
>
From: Zhao Zhili
fd_dup is unused when fd and pipe have been disabled. This also
fix build error with wasi since 'dup' isn't available.
Signed-off-by: Zhao Zhili
---
libavformat/file.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/file.c b/libavform
From: Zhao Zhili
Don't assume tempnam is available when !HAVE_MKSTEMP. Check tempnam
explicitly in configure.
Signed-off-by: Zhao Zhili
---
configure | 2 ++
libavutil/file_open.c | 8 +---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/configure b/conf
From: Zhao Zhili
---
The code can be simplified by always creating mutex/cond. I'm not sure
it worth the overhead. Please note !HAVE_THREADS don't have the same
problem since it has mock implementation of ff_mutex_lock/unlock.
libavutil/executor.c | 9 ++---
1 file changed, 6
> On Jul 1, 2024, at 21:14, Nuo Mi wrote:
>
> On Sun, Jun 30, 2024 at 6:45 PM Zhao Zhili wrote:
>
>> From: Zhao Zhili
>>
>> ---
>> The code can be simplified by always creating mutex/cond. I'm not sure
>> it worth the overhead. Please note !HA
---
libavcodec/speexdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/speexdec.c b/libavcodec/speexdec.c
index 35270e6723..fccceab74c 100644
--- a/libavcodec/speexdec.c
+++ b/libavcodec/speexdec.c
@@ -1586,5 +1586,5 @@ const AVCodec ff_speex_decoder = {
.clo
---
doc/APIchanges | 3 +++
libavcodec/avpacket.c | 15 +++
libavcodec/packet.h | 5 +
libavcodec/tests/avpacket.c | 9 +
libavcodec/version.h| 2 +-
5 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/A
There is a little chance that user specified contradicted options
like -streaming 0 -ldash 1, however, it's more likely that user
didn't know or forgot to enable streaming for ldash. So enabling
streaming automatically to make the feature easier to use, similar
like enable FF_MOV_FLAG_FRAGMENT/EMPT
Try to make the feature easier to use, especially since the user
have enabled -strict experimental manually. The user shouldn't
be surprised that hls_playlist is enabled for lhls automatically,
so change the log level from warning to info for that.
---
doc/muxers.texi | 2 +-
libavformat/das
---
doc/muxers.texi | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 67c281d171..a24b09a387 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -362,12 +362,13 @@ Ignore IO errors during open and write. Useful for
long-duration r
It's not being used. For backward compatibility, AV_OPT_TYPE_RATIONAL
cannot be changed to use it.
---
libavutil/opt.h | 2 ++
libavutil/version.h | 3 +++
2 files changed, 5 insertions(+)
diff --git a/libavutil/opt.h b/libavutil/opt.h
index 2820435eec..bf1a8b84fa 100644
--- a/libavutil/opt.h
Use PCM_S16 so the codec_id will be updated later according to
bits_per_coded_sample.
---
libavformat/isom_tags.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/isom_tags.c b/libavformat/isom_tags.c
index d0400b18fc..62e60470a8 100644
--- a/libavformat/isom_tag
Make get_int/set_int symetric. The int64_t to double to int64_t
conversion is unprecise for large value.
---
libavutil/opt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index c7001dbcd3..b2be63828d 100644
--- a/libavutil/opt.c
+++ b/lib
Make get_int/set_int symetric. The int64_t to double to int64_t
conversion is unprecise for large value.
---
libavutil/opt.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index c7001dbcd3..cfda31ea2f 100644
--- a/libavutil/opt.c
+++ b/lib
---
libavformat/movenc.c | 8 +
libavformat/movenc.h | 1 +
tests/ref/fate/movenc | 80 +--
3 files changed, 49 insertions(+), 40 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index f8731d33c5..01dfd21a43 100644
--- a/libavfo
---
libavformat/movenc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 38ff90833a..634a829f28 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -4427,7 +4427,7 @@ static int mov_write_mfhd_tag(AVIOCo
---
libavformat/movenc.c | 17 -
libavformat/movenc.h | 1 +
tests/ref/fate/movenc | 4 ++--
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 634a829f28..06d3819591 100644
--- a/libavformat/movenc.c
+++ b/libavfor
traf_number indicates the ‘traf’ number that contains the sync sample.
The number ranges from 1 (the first ‘traf’ is numbered 1) in each ‘moof’.
For A-V interleaved fmp4 with two traf boxes inside a moof, tfra box
was broken.
---
libavformat/movenc.c | 4 +++-
libavformat/movenc.h | 2 ++
test
---
libavformat/movenc.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 01dfd21a43..3c7c951c7d 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -4939,16 +4939,16 @@ st
From: Zhao Zhili
The last frame is corrupted. It has different results on different
platform.
---
tests/fate/screen.mak| 3 ++-
tests/ref/fate/zmbv-8bit | 1 -
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/fate/screen.mak b/tests/fate/screen.mak
index bd6d228544
1 - 100 of 1472 matches
Mail list logo
