From: Zhao Zhili
MediaCodec can generate AV1CodecConfigurationRecord, which shouldn't
be put into packet->data. Skip four bytes and extract configOBUs
if it exist.
---
I did some test on Pixel 8 Pro. AV1 hardware encoding works with a lot
of bugs:
1. It's broken for width non-align
From: Zhao Zhili
When crop is skipped, av_strlcatf will access `str` which isn't
initialized properly.
---
libavcodec/mediacodecenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mediacodecenc.c b/libavcodec/mediacodecenc.c
index 6ca3968a24..e76ea81236 1
> On Sep 26, 2024, at 07:43, Marvin Scholz wrote:
>
> Mixing declarations and code is quite common in Objective-C (as can be
> seen by the number of warnings we have for this in Objective-C files)
> and forcing to not do it usually results in worse code, with unnecessary
> widely scoped variab
> On Sep 30, 2024, at 00:06, Filip Mašić wrote:
>
>>>
>>> On Sep 29, 2024, at 08:05, Michael Niedermayer
>> wrote:
>>>
>>> On Tue, Sep 24, 2024 at 12:16:13AM +0800, Zhao Zhili wrote:
>>>> From: Zhao Zhili
>>>>
> On Oct 1, 2024, at 14:55, Nuo Mi wrote:
>
> We still need several refactors to improve the current VVC decoder's
> performance,
> which will frequently break the API/ABI. To mitigate this, we've copied the
> executor from
> avutil to avcodec. Once the API/ABI is stable, we will move this c
> On Sep 29, 2024, at 08:05, Michael Niedermayer wrote:
>
> On Tue, Sep 24, 2024 at 12:16:13AM +0800, Zhao Zhili wrote:
>> From: Zhao Zhili
>>
>> ---
>> libavformat/img2enc.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>
From: Zhao Zhili
w_avg_8_2x2_c: 0.0 ( 0.00x)
w_avg_8_2x2_neon:0.0 ( 0.00x)
w_avg_8_4x4_c: 0.2 ( 1.00x)
w_avg_8_4x4_neon:0.0 ( 0.00x
From: Zhao Zhili
dmvr_8_12x20_c: 1.5 ( 1.00x)
dmvr_8_12x20_neon: 0.2 ( 6.56x)
dmvr_8_20x12_c: 1.0 ( 1.00x)
dmvr_8_20x12_neon: 0.2 ( 4.33x
From: Zhao Zhili
dmvr_hv_8_12x20_c: 8.0 ( 1.00x)
dmvr_hv_8_12x20_neon:1.2 ( 6.62x)
dmvr_hv_8_20x12_c: 8.0 ( 1.00x)
dmvr_hv_8_20x12_neon:0.9 ( 8.37x
From: Zhao Zhili
v4:
1. Rewords on Apple ABI
2. Remove const on some local variables
v3:
1. Remove some const modifier in function prototypes
2. Use 'uaddl' to replace 'uxtl then add' in patch 3/3
Zhao Zhili (3):
aarch64/vvc: Add w_avg
aarch64/vvc: Add dmvr_hv
a
From: Zhao Zhili
dmvr_hv_8_12x20_c: 8.0 ( 1.00x)
dmvr_hv_8_12x20_neon:1.2 ( 6.62x)
dmvr_hv_8_20x12_c: 8.0 ( 1.00x)
dmvr_hv_8_20x12_neon:0.9 ( 8.37x
From: Zhao Zhili
w_avg_8_2x2_c: 0.0 ( 0.00x)
w_avg_8_2x2_neon:0.0 ( 0.00x)
w_avg_8_4x4_c: 0.2 ( 1.00x)
w_avg_8_4x4_neon:0.0 ( 0.00x
From: Zhao Zhili
v3:
1. Remove some const modifier in function prototypes
2. Use 'uaddl' to replace 'uxtl then add' in patch 3/3
Zhao Zhili (3):
aarch64/vvc: Add w_avg
aarch64/vvc: Add dmvr_hv
aarch64/vvc: Add dmvr
libavcodec/aarch64/vvc/dsp_init.c | 50 +++
li
From: Zhao Zhili
w_avg_8_2x2_c: 0.0 ( 0.00x)
w_avg_8_2x2_neon:0.0 ( 0.00x)
w_avg_8_4x4_c: 0.2 ( 1.00x)
w_avg_8_4x4_neon:0.0 ( 0.00x
From: Zhao Zhili
dmvr_8_12x20_c: 1.5 ( 1.00x)
dmvr_8_12x20_neon: 0.2 ( 6.56x)
dmvr_8_20x12_c: 1.0 ( 1.00x)
dmvr_8_20x12_neon: 0.2 ( 4.33x
> On Sep 26, 2024, at 20:17, Martin Storsjö wrote:
>
> On Thu, 26 Sep 2024, Zhao Zhili wrote:
>
>> --- a/libavcodec/aarch64/vvc/dsp_init.c
>> +++ b/libavcodec/aarch64/vvc/dsp_init.c
>> @@ -52,6 +52,37 @@ void ff_vvc_avg_12_neon(uint8_t *dst
> On Sep 26, 2024, at 19:25, Martin Storsjö wrote:
>
> On Mon, 23 Sep 2024, Zhao Zhili wrote:
>
>> From: Zhao Zhili
>>
>> w_avg_8_2x2_c: 0.0 ( 0.00x)
>> w_avg_8_2x2_neon:
> On Sep 25, 2024, at 16:01, Martin Storsjö wrote:
>
> On Tue, 24 Sep 2024, Zhao Zhili wrote:
>
>> ffmpeg | branch: master | Zhao Zhili | Wed Sep 18
>> 21:11:44 2024 +0800| [e18b46d95fadcbaaf450bda9f1871849f2b0c586] | committer:
>> Zhao Zhili
>>
>
> On Sep 25, 2024, at 20:04, Martin Storsjö wrote:
>
> On Wed, 25 Sep 2024, Martin Storsjö wrote:
>
>> On Tue, 24 Sep 2024, Cameron Gutman wrote:
>>
>>> On Tue, Sep 24, 2024 at 7:16 AM Martin Storsjö wrote:
I don't hit any issues with any AV1 samples that I have, I guess I don't
ha
From: Zhao Zhili
For example, the default surface configuration on macOS is:
VK_FORMAT_A2B10G10R10_UNORM_PACK32 + VK_COLOR_SPACE_PASS_THROUGH_EXT
With HDR10 content and swapchain_colorspace_hint, the surface
configuration updated to:
VK_FORMAT_A2B10G10R10_UNORM_PACK32
> On Sep 24, 2024, at 22:16, Nuo Mi wrote:
>
> Due to the nature of multithreading, using a "ready check" mechanism may
> introduce a deadlock. For example:
>
> Suppose all tasks have been submitted to the executor, and the last thread
> checks the entire list and finds
> no ready tasks. It
> On Sep 18, 2024, at 21:11, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> Since c0666d8b, rgb24toyv12 is broken for width non-aligned to 16.
> Add a simple wrapper to handle the non-aligned part.
>
> Signed-off-by: Zhao Zhili
> Co-authored-by: johzzy
>
> On Sep 14, 2024, at 18:45, Anton Khirnov wrote:
>
> ---
> tests/fate/hevc.mak | 10 ++
> tests/ref/fate/hevc-mv-switch | 172 ++
> 2 files changed, 182 insertions(+)
> create mode 100644 tests/ref/fate/hevc-mv-switch
Fate break on macOS.
https://git
> On Sep 24, 2024, at 01:24, Cameron Gutman wrote:
>
> On Mon, Sep 23, 2024 at 6:07 AM Zhao Zhili wrote:
>>
>>
>>
>>> On Sep 21, 2024, at 05:39, Martin Storsjö wrote:
>>>
>>> From: Jan Ekström
>>>
>>&
From: Zhao Zhili
---
libavformat/img2enc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/img2enc.c b/libavformat/img2enc.c
index 526a11e5ee..41638d92b8 100644
--- a/libavformat/img2enc.c
+++ b/libavformat/img2enc.c
@@ -160,13 +160,13 @@ static int
From: Zhao Zhili
It's similar to av_get_frame_filename2 but with int64_t number
support. Make av_get_frame_filename* a wrapper over
ff_get_frame_filename.
Co-authored-by: Filip Mašić
---
libavformat/internal.h | 16
libavformat/utils.c| 11 ---
2 files change
ave added it to patch v2 1/2 and add co-authored-by you.
By the way, please don’t top-post.
0001-avformat-internal-Add-ff_get_frame_filename.patch
Description: Binary data
0002-avformat-img2enc-Fix-integer-truncation-when-frame_p.patch
Description: Binary data
>
> Thanks for the help with
From: Zhao Zhili
It's similar to av_get_frame_filename2 but with int64_t number
support. Make av_get_frame_filename* a wrapper over
ff_get_frame_filename.
Co-authored-by: Filip Mašić
---
libavformat/internal.h | 16
libavformat/utils.c| 11 ---
2 files change
> On Sep 19, 2024, at 21:46, nicolas.d...@gmail.com wrote:
>
> From: Nicolas Jorge Dato
>
> When in listener mode and writing, now libsrt supports multiple clients
> configured with the max_clients parameter.
>
> When max_clients=1 (default), it behaves as before.
> When max_clientes > 1, aft
> On Sep 23, 2024, at 18:18, Filip Mašić wrote:
>
> ---
> doc/APIchanges | 3 ++-
> libavfilter/vf_signature.c | 4 ++--
> libavformat/avformat.h | 22 ++
> libavformat/img2dec.c | 10 +-
> libavformat/segment.c | 4 ++--
> libavformat/ut
From: Zhao Zhili
It's similar to av_get_frame_filename2 but with int64_t number
support. Make av_get_frame_filename* a wrapper over
ff_get_frame_filename.
---
libavformat/internal.h | 16
libavformat/utils.c| 11 ---
2 files changed, 24 insertions(+), 3 dele
> On Sep 21, 2024, at 05:39, Martin Storsjö wrote:
>
> From: Jan Ekström
>
> Co-authored-by: Ruslan Chernenko
> Co-authored-by: Martin Storsjö
> ---
> This is a touched up version of Jan and Ruslan's patches for
> AV1 hwaccel via videotoolbox; I tried to polish the code a little
> by not ov
Drop patch 2/4 for now. It needs more polish.
See patch v2
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-September/333800.html
> On Sep 22, 2024, at 01:41, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> apply_bdof_8_8x16_c:
From: Zhao Zhili
dmvr_hv_8_12x20_c: 8.0 ( 1.00x)
dmvr_hv_8_12x20_neon:1.2 ( 6.62x)
dmvr_hv_8_20x12_c: 8.0 ( 1.00x)
dmvr_hv_8_20x12_neon:0.9 ( 8.37x
From: Zhao Zhili
dmvr_8_12x20_c: 2.2 ( 1.00x)
dmvr_8_12x20_neon: 0.5 ( 4.50x)
dmvr_8_20x12_c: 2.0 ( 1.00x)
dmvr_8_20x12_neon: 0.2 ( 8.00x
From: Zhao Zhili
w_avg_8_2x2_c: 0.0 ( 0.00x)
w_avg_8_2x2_neon:0.0 ( 0.00x)
w_avg_8_4x4_c: 0.2 ( 1.00x)
w_avg_8_4x4_neon:0.0 ( 0.00x
From: Zhao Zhili
tmp_array in dmvr_hv takes 33024 bytes on stack, which can be
dangerous.
---
v4:
1. Add DMVR_FILTER2 macro
2. Process first line out of loop to remove condition check.
libavcodec/vvc/inter_template.c | 33 ++---
1 file changed, 18 insertions
From: Zhao Zhili
w_avg_8_2x2_c: 0.0 ( 0.00x)
w_avg_8_2x2_neon:0.0 ( 0.00x)
w_avg_8_4x4_c: 0.2 ( 1.00x)
w_avg_8_4x4_neon:0.0 ( 0.00x
From: Zhao Zhili
dmvr_8_12x20_c: 2.2 ( 1.00x)
dmvr_8_12x20_neon: 0.5 ( 4.50x)
dmvr_8_20x12_c: 2.0 ( 1.00x)
dmvr_8_20x12_neon: 0.2 ( 8.00x
From: Zhao Zhili
dmvr_hv_8_12x20_c: 8.0 ( 1.00x)
dmvr_hv_8_12x20_neon:1.2 ( 6.62x)
dmvr_hv_8_20x12_c: 8.0 ( 1.00x)
dmvr_hv_8_20x12_neon:0.9 ( 8.37x
From: Zhao Zhili
apply_bdof_8_8x16_c:18.7 ( 1.00x)
apply_bdof_8_8x16_neon: 9.7 ( 1.93x)
apply_bdof_8_16x8_c:20.0 ( 1.00x)
apply_bdof_8_16x8_neon: 9.5 ( 2.11x
> On Sep 20, 2024, at 11:43, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> tmp_array in dmvr_hv takes 33024 bytes on stack, which can be
> dangerous.
I prefer version 3 personally
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-September/333709.html
> ---
&
From: Zhao Zhili
tmp_array in dmvr_hv takes 33024 bytes on stack, which can be
dangerous.
---
libavcodec/vvc/inter_template.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/libavcodec/vvc/inter_template.c b/libavcodec/vvc/inter_template.c
From: Zhao Zhili
tmp_array in dmvr_hv takes 33024 bytes on stack, which can be
dangerous.
---
libavcodec/vvc/ctu.h | 1 +
libavcodec/vvc/dsp.h | 2 +-
libavcodec/vvc/inter.c | 2 +-
libavcodec/vvc/inter_template.c | 12 +++-
libavcodec/x86/vvc
From: Zhao Zhili
tmp_array in dmvr_hv takes 33024 bytes on stack, which can be
dangerous. This patch fixed the C version and comment out the
x86 asm version.
---
libavcodec/vvc/ctu.h | 1 +
libavcodec/vvc/dsp.h | 2 +-
libavcodec/vvc/inter.c | 2
> On Sep 18, 2024, at 20:51, Martin Storsjö wrote:
>
> On Wed, 18 Sep 2024, Zhao Zhili wrote:
>
>> From: Zhao Zhili
>>
>> Since c0666d8b, rgb24toyv12 is broken for width non-aligned to 16.
>> Add a simple wrapper to handle the non-aligned part.
>
From: Zhao Zhili
Since c0666d8b, rgb24toyv12 is broken for width non-aligned to 16.
Add a simple wrapper to handle the non-aligned part.
Signed-off-by: Zhao Zhili
Co-authored-by: johzzy
---
v2: test width 2 and 540
libswscale/aarch64/rgb2rgb.c | 23 ++-
tests/checkasm
From: Zhao Zhili
Since c0666d8b, rgb24toyv12 is broken for width non-aligned to 16.
Add a simple wrapper to handle the non-aligned part.
Signed-off-by: Zhao Zhili
Co-authored-by: johzzy
---
libswscale/aarch64/rgb2rgb.c | 23 ++-
tests/checkasm/sw_rgb.c | 2 +-
2
From: Zhao Zhili
---
sample:
8054b4b8e62c0171476b40206d044590 Hierarchical.bit
https://drive.google.com/file/d/1U5WGWeSsMFiEkhsl_vL4NiMma-LLh02t/view?usp=sharing
Put Hierarchical.bit under $(TARGET_SAMPLES)/vvc
tests/fate/vvc.mak| 3 ++-
tests/ref/fate/vvc-output-ref | 35
> On Sep 15, 2024, at 08:46, Nuo Mi wrote:
>
> Hi Zhili
> Thank you for the patch.
>
>
> On Fri, Sep 13, 2024 at 2:35 PM Zhao Zhili <mailto:quinkbl...@foxmail.com>> wrote:
>
>> From: Zhao Zhili
>>
>> ff_vvc_output_frame is ca
From: Zhao Zhili
---
sample:
8054b4b8e62c0171476b40206d044590 Hierarchical.bit
https://drive.google.com/file/d/1U5WGWeSsMFiEkhsl_vL4NiMma-LLh02t/view?usp=sharing
tests/fate/vvc.mak | 1 +
tests/ref/fate/vvc-conformance-Hierarchical | 35 +
2 files
From: Zhao Zhili
ff_vvc_output_frame is called before actually decoding. It's possible
for ff_vvc_output_frame to select current frame to output. If current
frame is nonref frame, it will be released by ff_vvc_unref_frame.
Fix this by always marking the current frame
From: Zhao Zhili
ff_vvc_output_frame is called before actually decoding. It's possible
for ff_vvc_output_frame to select current frame to output. If current
frame is nonref frame, it will be released by ff_vvc_unref_frame.
Fix this by always marking the current frame
From: Zhao Zhili
ff_vvc_output_frame is called before actually decoding. It's possible
for ff_vvc_output_frame to select current frame to output. If current
frame is nonref frame, it will be released by ff_vvc_unref_frame.
Fix this by always marking the current frame
From: Zhao Zhili
put_luma_v_8_4x4_c: 1.0 ( 1.00x)
put_luma_v_8_4x4_neon: 0.0 ( 0.00x)
put_luma_v_8_8x8_c: 3.5 ( 1.00x)
put_luma_v_8_8x8_neon: 0.5 ( 7.00x
From: Zhao Zhili
avg_8_2x2_c: 0.2 ( 1.00x)
avg_8_2x2_neon: 0.2 ( 1.00x)
avg_8_4x4_c: 0.2 ( 1.00x)
avg_8_4x4_neon: 0.2 ( 1.00x
From: Zhao Zhili
On Apple M1:
put_chroma_hv_8_4x4_c: 1.7 ( 1.00x)
put_chroma_hv_8_4x4_neon:0.2 ( 7.67x)
put_chroma_hv_8_8x8_c: 5.5 ( 1.00x)
put_chroma_hv_8_8x8_neon
From: Zhao Zhili
put_chroma_h_8_4x4_c:0.4 ( 1.00x)
put_chroma_h_8_4x4_neon: 0.0 ( 0.00x)
put_chroma_h_8_4x4_i8mm: 0.1 ( 2.67x)
put_chroma_h_8_8x8_c:1.6 ( 1.00x
From: Zhao Zhili
put_chroma_h_8_4x4_c:0.2 ( 1.00x)
put_chroma_h_8_4x4_neon: 0.2 ( 1.00x)
put_chroma_h_8_8x8_c:0.8 ( 1.00x)
put_chroma_h_8_8x8_neon: 0.2 ( 3.00x
From: Zhao Zhili
With Apple M1 (no i8mm):
put_luma_hv_8_4x4_c: 2.2 ( 1.00x)
put_luma_hv_8_4x4_neon: 0.8 ( 3.00x)
put_luma_hv_8_8x8_c: 7.0 ( 1.00x)
put_luma_hv_8_8x8_neon
From: Zhao Zhili
sad_8x16_c: 0.8 ( 1.00x)
sad_8x16_neon: 0.2 ( 3.00x)
sad_16x8_c: 0.5 ( 1.00x)
sad_16x8_neon: 0.2 ( 2.00x
From: Zhao Zhili
b.eq is added by calc_all after each calc.
---
libavcodec/aarch64/h26x/qpel_neon.S | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/aarch64/h26x/qpel_neon.S
b/libavcodec/aarch64/h26x/qpel_neon.S
index 1fa5a1dd0e..417d43e365 100644
--- a/libavcodec/aarch64/h26x
From: Zhao Zhili
---
libavcodec/hevc/dsp_template.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc/dsp_template.c b/libavcodec/hevc/dsp_template.c
index aebccd1a0c..a0f79c2673 100644
--- a/libavcodec/hevc/dsp_template.c
+++ b/libavcodec/hevc
From: Zhao Zhili
put_luma_pixels_8_4x4_c: 0.2 ( 1.00x)
put_luma_pixels_8_4x4_neon: 0.2 ( 1.00x)
put_luma_pixels_8_8x8_c: 0.7 ( 1.00x)
put_luma_pixels_8_8x8_neon: 0.2 ( 3.22x
From: Zhao Zhili
Benchmark on Android pixel 8 with -fno-vectorize
put_luma_h_8_4x4_c: 0.2 ( 1.00x)
put_luma_h_8_4x4_neon: 0.2 ( 1.00x)
put_luma_h_8_4x4_i8mm: 0.0 ( 0.00x)
put_luma_h_8_8x8_c
From: Zhao Zhili
So vvc can reuse the implementation.
---
libavcodec/aarch64/Makefile | 4 +-
libavcodec/aarch64/h26x/dsp.h | 198 ++
.../{hevcdsp_epel_neon.S => h26x/epel_neon.S} | 0
.../{hevcdsp_qpel_neon.S => h26x/qpel_neon.S}
From: Zhao Zhili
---
libavcodec/aarch64/hevcdsp_init_aarch64.c | 66 +++
1 file changed, 18 insertions(+), 48 deletions(-)
diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index a90da0246e..26bbc8750f 100644
--- a
From: Zhao Zhili
Just share hevc implementation.
checkasm --test=vvc_mc --benchmark:
put_luma_h_8_4x4_c: 0.2 ( 1.00x)
put_luma_h_8_4x4_neon: 0.2 ( 1.00x)
put_luma_h_8_8x8_c: 1.0 ( 1.00x
From: Zhao Zhili
Patches 1~9 has been updated according to Martin's review.
Patches 10~14 are new.
I have created a PR on github:
https://github.com/quink-black/FFmpeg/pull/2
Zhao Zhili (14):
aarch64/hevc: Simplify function prototypes by macro
aarch64/hevc: Move epel/qpel to
From: Zhao Zhili
With Apple M1 (no i8mm):
put_luma_hv_8_4x4_c: 2.2 ( 1.00x)
put_luma_hv_8_4x4_neon: 0.8 ( 3.00x)
put_luma_hv_8_8x8_c: 7.0 ( 1.00x)
put_luma_hv_8_8x8_neon
From: Zhao Zhili
put_luma_v_8_4x4_c: 1.0 ( 1.00x)
put_luma_v_8_4x4_neon: 0.0 ( 0.00x)
put_luma_v_8_8x8_c: 3.5 ( 1.00x)
put_luma_v_8_8x8_neon: 0.5 ( 7.00x
From: Zhao Zhili
b.eq is added by calc_all after each calc.
---
libavcodec/aarch64/h26x/qpel_neon.S | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/aarch64/h26x/qpel_neon.S
b/libavcodec/aarch64/h26x/qpel_neon.S
index 8a372a76be..7868811b3b 100644
--- a/libavcodec/aarch64/h26x
> On Sep 9, 2024, at 18:35, Anton Khirnov wrote:
>
> Quoting Zhao Zhili (2024-09-07 19:13:40)
>> From: Zhao Zhili
>>
>> ---
>> libavcodec/hevc/dsp_template.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git
> On Sep 9, 2024, at 01:27, Martin Schitter wrote:
>
> ---
> libavcodec/dnxucdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/dnxucdec.c b/libavcodec/dnxucdec.c
> index 502e736..e9a2157 100644
> --- a/libavcodec/dnxucdec.c
> +++ b/libavcodec/dnxucdec.c
>
> On Sep 8, 2024, at 20:39, Timo Rothenpieler wrote:
>
> On 08.09.2024 10:15, Andreas Rheinhardt wrote:
>> Timo Rothenpieler:
>>> These can easily lead to incredibly confusing errors, and should
>>> practically never happen.
>>> I'd have loved to make this a -Werror even, but sadly there is way
From: Zhao Zhili
So vvc can reuse the implementation.
---
libavcodec/aarch64/Makefile | 4 +-
libavcodec/aarch64/h26x/dsp.h | 198 ++
.../{hevcdsp_epel_neon.S => h26x/epel_neon.S} | 0
.../{hevcdsp_qpel_neon.S => h26x/qpel_neon.S}
From: Zhao Zhili
---
libavcodec/hevc/dsp_template.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc/dsp_template.c b/libavcodec/hevc/dsp_template.c
index aebccd1a0c..a0f79c2673 100644
--- a/libavcodec/hevc/dsp_template.c
+++ b/libavcodec/hevc
From: Zhao Zhili
put_luma_pixels_8_4x4_c: 0.2 ( 1.00x)
put_luma_pixels_8_4x4_neon: 0.2 ( 1.00x)
put_luma_pixels_8_8x8_c: 0.7 ( 1.00x)
put_luma_pixels_8_8x8_neon: 0.2 ( 3.22x
From: Zhao Zhili
Benchmark on Android pixel 8 with -fno-vectorize
put_luma_h_8_4x4_c: 0.2 ( 1.00x)
put_luma_h_8_4x4_neon: 0.2 ( 1.00x)
put_luma_h_8_4x4_i8mm: 0.0 ( 0.00x)
put_luma_h_8_8x8_c
From: Zhao Zhili
Just share hevc implementation.
checkasm --test=vvc_mc --benchmark:
put_luma_h_8_4x4_c: 0.2 ( 1.00x)
put_luma_h_8_4x4_neon: 0.2 ( 1.00x)
put_luma_h_8_8x8_c: 1.0 ( 1.00x
From: Zhao Zhili
---
libavcodec/aarch64/hevcdsp_init_aarch64.c | 66 +++
1 file changed, 18 insertions(+), 48 deletions(-)
diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index a90da0246e..26bbc8750f 100644
--- a
> On Aug 26, 2024, at 20:54, Matthieu Bouron wrote:
>
> ---
>
> Diff with v2:
> - Dropped flac/vorbis/opus support
LGTM.
>
> ---
> configure | 8 +
> libavcodec/Makefile | 4 +
> libavcodec/allcodecs.c| 4 +
> libavcodec/mediacodecdec.c
From: Zhao Zhili
So vvc can reuse the implementation.
---
libavcodec/aarch64/Makefile | 2 +-
libavcodec/aarch64/h26x/dsp.h | 36 +++
.../{hevcdsp_sao_neon.S => h26x/sao_neon.S} | 2 +-
libavcodec/aarch64/hevcdsp_init_aarch64.c |
From: Zhao Zhili
---
libavcodec/aarch64/h26x/dsp.h | 6 +++-
libavcodec/aarch64/h26x/sao_neon.S| 44 +--
libavcodec/aarch64/hevcdsp_init_aarch64.c | 2 +-
libavcodec/aarch64/vvc/Makefile | 5 +--
libavcodec/aarch64/vvc/dsp_init.c | 6
From: Zhao Zhili
---
libavfilter/vf_unsharp.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/libavfilter/vf_unsharp.c b/libavfilter/vf_unsharp.c
index 52b2ab8d44..b5dd468b6f 100644
--- a/libavfilter/vf_unsharp.c
+++ b/libavfilter/vf_unsharp.c
@@ -74,7 +74,6
> On Aug 24, 2024, at 22:40, Matthieu Bouron wrote:
>
> ---
>
> Diff with the v1:
> - dropped support of ENCODING_PCM_24BIT_PACKED as it uses 3 consecutive bytes
> for one sample and there is no direct AVSampleFormat equivalent (that would
> require a dedicated copy routine to copy the 3 by
> On Aug 24, 2024, at 22:11, Matthieu Bouron wrote:
>
> On Fri, Aug 23, 2024 at 7:20 PM Zhao Zhili wrote:
>>
>> From: Zhao Zhili
>>
>> There is no more buffer to queue in draining state
>
> nit: There is no more input buffer to dequeue in draining s
Please squash these patches into a single one. We don’t use a incomplete patch
and
then fix it with another one (of course unless the first one has already got
merged).
> On Aug 24, 2024, at 01:23, Rajiv Harlalka wrote:
>
> Signed-off-by: Rajiv Harlalka
> ---
> libavfilter/vf_pu21.c | 6 ++---
From: Zhao Zhili
There is no more buffer to queue in draining state
Signed-off-by: Zhao Zhili
---
libavcodec/mediacodecdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 6d8dc600fe..0da5fe6729 100644
--- a
From: Zhao Zhili
There are two VTCompressionSessionRef been created, one for generating
extradata, and another for normal encoding. supported_props was been
overwritten without release.
---
libavcodec/videotoolboxenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec
> On Aug 14, 2024, at 21:36, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> It was shared with opencl implementation.
Ping. Any comments?
> ---
> libavfilter/unsharp.h| 62
> libavfilter/vf_unsharp.c | 34
> On Aug 16, 2024, at 10:06, gnattu via ffmpeg-devel
> wrote:
>
> The color range should be set to match the input when creating
> the VideoToolbox context. Otherwise, the new context will default
> to limited range, creates inconsistencies with full range inputs.
LGTM, thanks.
>
> Signed-
> On Aug 15, 2024, at 22:02, Gnattu OC via ffmpeg-devel
> wrote:
>
>
>
>> On Aug 15, 2024, at 19:59, Zhao Zhili wrote:
>>
>>
>>
>>> On Aug 10, 2024, at 14:06, gnattu via ffmpeg-devel
>>> wrote:
>>>
>>> In
> On Aug 10, 2024, at 17:52, epira...@gmail.com wrote:
>
> On 10 Aug 2024, at 8:13, gnattu via ffmpeg-devel wrote:
>
>> Hardware frames with RGB colorspace will not have a YCbCrMatrixKey.
>> Currently, it will spam the console with warning if rgb frame is
>> uploaded.
>
> Thanks, LGTM
Applie
> On Aug 8, 2024, at 23:46, Zhao Zhili wrote:
>
>
>> On Aug 7, 2024, at 23:58, cyfdel-at-hotmail@ffmpeg.org wrote:
>>
>> From: eaphone
>>
>> ---
>> libavdevice/gdigrab.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> On Aug 10, 2024, at 14:06, gnattu via ffmpeg-devel
> wrote:
>
> In vtenc_populate_extradata, supported_props should always be released
> to avoid memory leak.
>
> Regression from cd2f8a22e94700c68b1de7968df11e8bebfd315b
>
> Signed-off-by: gnattu
> ---
> libavcodec/videotoolboxenc.c | 13 +
From: Zhao Zhili
It was shared with opencl implementation.
---
libavfilter/unsharp.h| 62
libavfilter/vf_unsharp.c | 34 +-
2 files changed, 33 insertions(+), 63 deletions(-)
delete mode 100644 libavfilter/unsharp.h
diff --git a
From: Zhao Zhili
Filter init can change extradata from avcc/hvcc to annexb format.
With different passthrough logic, packets can still in avcc/hvcc
format. Use same passthrough logic for init and filter.
Signed-off-by: Zhao Zhili
---
libavcodec/bsf/filter_units.c | 5 -
1 file changed, 4
> On Aug 14, 2024, at 18:05, b...@gget.it wrote:
>
>
>>> Do you think it would be worth developing a command-line option so that
>>> exact cutting with minimal re-encoding would be easier?
>>
>> How do you plan to figure out the options needed to be passed to each
>> and every encoder, so tha
> vaapi drivers often lack proper image converesions and not all
> situations allow vagetimage or vaputimage with the image formats
> reported by the api. nv12 seems allowed in all circumstances.
>
> with this change now one can use the hwaccel directly without
> explicit conversions to nv12 for f
1 - 100 of 1053 matches
Mail list logo
