Quoting James Almer (2024-06-02 02:39:36)
> To be in line with vvc, you'd also need to move the x86/ files to their
> own hevc folder.
I considered that, but the patch already seemed big enough and I didn't
want to risk even more arch-specific breakage and/or bikeshedding. So
I'd rather leave thi
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tiff.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 846d817cdc..fd4116aec4 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -422,7 +422,7 @@ static void av_always_inlin
Fixes libavcodec/decode.c:1035:61: runtime error: member access within
null pointer of type 'const struct AVCodecHWConfigInternal'.
This can happen when hwaccel fails to initialize and hw_configs[i] is
NULL.
Signed-off-by: Kacper Michajłow
---
libavcodec/decode.c | 2 +-
1 file changed, 1 inser
On 5/31/2024 2:47 PM, Anton Khirnov wrote:
---
libavcodec/Makefile | 12 ++-
libavcodec/aarch64/hevcdsp_init_aarch64.c | 2 +-
libavcodec/arm/hevcdsp_arm.h | 2 +-
libavcodec/arm/hevcdsp_init_arm.c | 2 +-
libavcodec/arm/hevc
> I think we can drop the 2x2 transforms. In all likelihood, scalar code
will
> end up faster than vector code on future hardware, especially out-of-order
> pipelines.
I want to drop 2x2, but since there's only one function to handle all
situations instead of 7*7 functions, how can I drop only 2x2
Le perjantaina 31. toukokuuta 2024, 0.21.51 EEST Sean McGovern a écrit :
> ---
> libavcodec/bfin/README | 6 --
> libavcodec/sh4/README | 6 --
> libavcodec/sparc/README | 6 --
> 3 files changed, 18 deletions(-)
> delete mode 100644 libavcodec/bfin/README
> delete mode 100644 lib
This just computes the direct coefficient and hands over to code shared
with VP8. Accordingly the bulk of changes are just rewriting the VP8
code to share.
Nothing to write home about:
vp7_idct_dc_add_c: 1.7
vp7_idct_dc_add_rvv_i32: 1.2
---
libavcodec/riscv/vp7dsp_init.c | 12 +++-
As with idct_dc_add, most of the code is shared with, and replaces, the
previous VP8 function. To improve performance, we break down the 16x4
matrix into 4 rows, rather than 4 squares. Thus strided loads and
stores are avoided, and the 4 DC calculations are vectored.
Unfortunately this requires a v
Le lauantaina 1. kesäkuuta 2024, 21.01.16 EEST [email protected] a écrit :
> From: sunyuechi
>
> C908 X60
> avg_8_2x2_c:1.01.0
> avg_8_2x2_rvv_i32 :1.01.
On 5/30/2024 6:21 PM, Sean McGovern wrote:
---
Changelog| 1 +
libavcodec/alpha/Makefile| 10 -
libavcodec/alpha/asm.h | 153 --
libavcodec/alpha/blockdsp_alpha.c| 49 -
libavcodec/alpha/hpeldsp_alpha.c | 213
> In keeping in line with the rest of the project, that should probably go
into
> **libavcodec/riscv/vvc/**
> Expanding the macro 49 times, with up to 14 **branches** to get there is
maybe not
> such a great idea. It might look nice on the checkasm µbenchmarks because
the
> branches under test get
From: sunyuechi
C908 X60
avg_8_2x2_c:1.01.0
avg_8_2x2_rvv_i32 :1.01.0
avg_8_2x4_c:1.72.0
avg_8_2x4_rvv_i
---
src/index | 12
1 file changed, 12 insertions(+)
diff --git a/src/index b/src/index
index 442db4b..920a5bb 100644
--- a/src/index
+++ b/src/index
@@ -35,6 +35,18 @@
News
+ June 2rd, 2024, native xHE-AAC decoder
+
+ FFmpeg now implements a native xHE-AAC decoder. Cu
On Thu, May 30, 2024 at 5:21 PM Sean McGovern wrote:
>
> ---
> libavcodec/bfin/README | 6 --
> libavcodec/sh4/README | 6 --
> libavcodec/sparc/README | 6 --
> 3 files changed, 18 deletions(-)
> delete mode 100644 libavcodec/bfin/README
> delete mode 100644 libavcodec/sh4/READM
fre 2024-05-17 klockan 15:49 +0200 skrev Michael Niedermayer:
> * Paul to work on FFmpeg full time. My idea here is that he can work
> on whatever
> he likes in FFmpeg (so its not full time employment for specific
> work but
> simply full time employment for him to work on whatever he likes in
Tomas Härdin:
> lör 2024-06-01 klockan 15:13 +0200 skrev Andreas Rheinhardt:
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/hevc_ps.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
>> index 7b486ce0af..1a459ad054
lör 2024-06-01 klockan 15:13 +0200 skrev Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/hevc_ps.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index 7b486ce0af..1a459ad054 100644
> --- a/libavco
Le lauantaina 1. kesäkuuta 2024, 12.11.28 EEST Rémi Denis-Courmont a écrit :
> The 8x8 pixel arrays are not necessarily aligned to 64 bits, so the
> current code leads to Bus error on real hardware. This reproducible
> with FATE's vc1_ilaced_twomv test case.
http://fate.ffmpeg.org/report.cgi?time=
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevc_ps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 7b486ce0af..1a459ad054 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -200,7 +200,7 @@ int ff_hevc_deco
On 2024-05-31 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 unfinished file is completely useless unless it
is
On Wed, 29 May 2024 at 23:47, James Almer wrote:
>
> Signed-off-by: James Almer
> ---
> libavformat/matroskadec.c | 53 +++
> 1 file changed, 43 insertions(+), 10 deletions(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 2f07e
The 8x8 pixel arrays are not necessarily aligned to 64 bits, so the
current code leads to Bus error on real hardware. This reproducible
with FATE's vc1_ilaced_twomv test case.
The new "pessimist" code can trivially be shared for 16x16 pixel
arrays so we also do that. FWIW, this also nominally redu
The OS may silently fix (emulate) unaligned hardware access exceptions.
This is extremely slow and code should be fixed not to rely on unaligned
access on affected hardware. Accordingly this requests that the OS
disable emulation and instead throw Bus error, which will be caught by
checkasm's signa
Le lauantaina 1. kesäkuuta 2024, 0.06.55 EEST averne a écrit :
> As for your second question, I probably should've given some
> context about this decision. Initially I thought about writing a
> vaapi driver, but for a number of reasons I decided against it.
VA-API would be difficult anyway as it
24 matches
Mail list logo
