the condition being tested was the same as the stop condition for the
containing loop,
so inside the loop it would always test positive
---
libavcodec/aacenc_tns.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavcodec/aacenc_tns.c b/libavcodec/aacenc_tns.c
index 60
(resent due to not adding mail-list into the CC)
Hey there!
Thanks for checking out the patch;
As for videotoolbox_av1_start_frame:
For the av_fast_realloc call it's mostly the same thing as
ff_videotoolbox_buffer_copy defined at libavcodec/videotoolbox.c:79. It
takes a pointer to a bitstream, its
Okay, yeah.
Took a better look and indeed it should be (vtctx->bitstream_size + size)
for the av_fast_realloc.
Will send an update on this patch today.
On Sun, 12 May 2024 at 11:53, Ruslan Chernenko wrote:
> (resent due to not adding mail-list into the CC)
> Hey there!
> Thanks for checking out
From: sunyuechi
C908:
vp9_avg4_8bpp_c: 1.2
vp9_avg4_8bpp_rvv_i64: 1.0
vp9_avg8_8bpp_c: 3.7
vp9_avg8_8bpp_rvv_i64: 1.5
vp9_avg16_8bpp_c: 14.7
vp9_avg16_8bpp_rvv_i64: 3.5
vp9_avg32_8bpp_c: 57.7
vp9_avg32_8bpp_rvv_i64: 10.0
vp9_avg64_8bpp_c: 229.0
vp9_avg64_8bpp_rvv_i64: 31.7
---
libavcodec/riscv/M
From: sunyuechi
C908:
vp9_tm_4x4_8bpp_c: 116.5
vp9_tm_4x4_8bpp_rvv_i32: 43.5
vp9_tm_8x8_8bpp_c: 416.2
vp9_tm_8x8_8bpp_rvv_i32: 86.0
vp9_tm_16x16_8bpp_c: 1665.5
vp9_tm_16x16_8bpp_rvv_i32: 187.2
vp9_tm_32x32_8bpp_c: 6974.2
vp9_tm_32x32_8bpp_rvv_i32: 625.7
---
libavcodec/riscv/vp9_intra_rvv.S | 141
From: sunyuechi
C908:
vp9_put4_8bpp_c: 0.7
vp9_put4_8bpp_rvi: 0.5
vp9_put8_8bpp_c: 2.5
vp9_put8_8bpp_rvi: 0.5
vp9_put16_8bpp_c: 16.7
vp9_put16_8bpp_rvi: 1.5
vp9_put32_8bpp_c: 37.2
vp9_put32_8bpp_rvi: 5.7
vp9_put64_8bpp_c: 107.5
vp9_put64_8bpp_rvi: 21.7
---
libavcodec/riscv/Makefile | 3 +-
From: sunyuechi
C908:
vp9_hor_8x8_8bpp_c: 74.7
vp9_hor_8x8_8bpp_rvv_i32: 35.7
vp9_hor_16x16_8bpp_c: 175.5
vp9_hor_16x16_8bpp_rvv_i32: 80.2
vp9_hor_32x32_8bpp_c: 510.2
vp9_hor_32x32_8bpp_rvv_i32: 264.0
---
libavcodec/riscv/vp9_intra_rvv.S | 56
libavcodec/riscv/vp
From: sunyuechi
C908:
vp9_avg_bilin_4h_8bpp_c: 5.2
vp9_avg_bilin_4h_8bpp_rvv_i64: 2.2
vp9_avg_bilin_4v_8bpp_c: 5.5
vp9_avg_bilin_4v_8bpp_rvv_i64: 2.2
vp9_avg_bilin_8h_8bpp_c: 20.0
vp9_avg_bilin_8h_8bpp_rvv_i64: 4.5
vp9_avg_bilin_8v_8bpp_c: 21.0
vp9_avg_bilin_8v_8bpp_rvv_i64: 4.2
vp9_avg_bilin_16h
From: sunyuechi
C908:
vp9_vert_8x8_8bpp_c: 22.0
vp9_vert_8x8_8bpp_rvi: 15.7
vp9_vert_16x16_8bpp_c: 71.2
vp9_vert_16x16_8bpp_rvi: 39.0
vp9_vert_32x32_8bpp_c: 300.2
vp9_vert_32x32_8bpp_rvi: 135.2
---
libavcodec/riscv/Makefile| 1 +
libavcodec/riscv/vp9_intra_rvi.S | 71 +++
From: sunyuechi
C908:
vp9_avg_bilin_4hv_8bpp_c: 11.0
vp9_avg_bilin_4hv_8bpp_rvv_i64: 3.7
vp9_avg_bilin_8hv_8bpp_c: 38.7
vp9_avg_bilin_8hv_8bpp_rvv_i64: 7.2
vp9_avg_bilin_16hv_8bpp_c: 147.0
vp9_avg_bilin_16hv_8bpp_rvv_i64: 14.2
vp9_avg_bilin_32hv_8bpp_c: 574.5
vp9_avg_bilin_32hv_8bpp_rvv_i64: 42.7
From: sunyuechi
C908 X60
vp9_avg_8tap_smooth_4hv_8bpp_c : 32.0 28.2
vp9_avg_8tap_smooth_4hv_8bpp_rvv_i32 : 15.0 13.2
vp9_avg_8tap_smooth_8hv_8bpp_c : 98.0 86.2
vp9_avg_8tap_smo
From: sunyuechi
C908 X60
vp9_avg_8tap_smooth_4h_8bpp_c : 13.0 11.2
vp9_avg_8tap_smooth_4h_8bpp_rvv_i32:5.04.2
vp9_avg_8tap_smooth_4v_8bpp_c : 13.7 12.5
vp9_avg_8tap_smo
> It should be possible to improve ordering to avoid immediate dependency
from ADD to SD
Okay, updated it.
Additionally improved the mc-tap_64 on vlen>=256 and something
于2024年5月12日周日 18:04写道：
> From: sunyuechi
>
> C908:
> vp9_vert_8x8_8bpp_c: 22.0
> vp9_vert_8x8_8bpp_rvi: 15.7
> vp9_vert_16x
---
libavcodec/h264dsp.c | 2 +
libavcodec/h264dsp.h | 2 +
libavcodec/riscv/Makefile| 2 +
libavcodec/riscv/h264dsp_init.c | 40
libavcodec/riscv/startcode_rvb.S | 81
libavcodec/riscv/vc1dsp_init.c | 7 ++-
---
libavcodec/riscv/Makefile| 1 +
libavcodec/riscv/h264dsp_init.c | 3 +++
libavcodec/riscv/startcode_rvv.S | 44
libavcodec/riscv/vc1dsp_init.c | 16 +++-
4 files changed, 58 insertions(+), 6 deletions(-)
create mode 100644 libavcodec/riscv
Le sunnuntaina 12. toukokuuta 2024, 13.55.14 EEST Rémi Denis-Courmont a écrit
:
> ---
> libavcodec/riscv/Makefile| 1 +
> libavcodec/riscv/h264dsp_init.c | 3 +++
> libavcodec/riscv/startcode_rvv.S | 44
> libavcodec/riscv/vc1dsp_init.c | 16 +++--
Improve scene detection accuracy by comparing frame with both previous and
next frame (creates one frame delay).
Add new mode parameter and new method to compute the frame difference using
cubic square to increase the weight of small changes and new mean formula.
This improves accuracy significantl
Improve scene detection accuracy by comparing frame with both previous and
next frame (creates one frame delay).
Add new mode parameter and new method to compute the frame difference using
cubic square to increase the weight of small changes and new mean formula.
This improves accuracy significantl
On 12.05.2024 10:53, Yotam Ofek wrote:
the condition being tested was the same as the stop condition for the
containing loop,
so inside the loop it would always test positive
---
libavcodec/aacenc_tns.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavcodec/aace
On Sun, May 12, 2024 at 1:05 PM wrote:
> Improve scene detection accuracy by comparing frame with both previous and
> next frame (creates one frame delay).
> Add new mode parameter and new method to compute the frame difference using
> cubic square to increase the weight of small changes and new
Le sunnuntaina 12. toukokuuta 2024, 13.55.13 EEST Rémi Denis-Courmont a écrit
:
> ---
> libavcodec/h264dsp.c | 2 +
> libavcodec/h264dsp.h | 2 +
> libavcodec/riscv/Makefile| 2 +
> libavcodec/riscv/h264dsp_init.c | 40
> libavcodec/riscv/start
Le perjantaina 10. toukokuuta 2024, 11.21.14 EEST u...@foxmail.com a écrit :
> From: sunyuechi
>
> C908 X60
> vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_c: 14.7 13.2
> vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_rvv_i32 : 2.5 2.2
> v
Nope :)
Last commit that touched this was 9 years ago, seems like it's an oversight
that was never noticed/fixed.
The native AAC encoder is stable, even if this code was supposed to behave
differently, it's probably good enough as is, and I think that having this
redundant conditional is bad for re
From: sunyuechi
C908 X60
vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_c: 14.7 13.2
vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_rvv_i32 : 2.5 2.2
vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_c: 3.7 3.5
vc1dsp.avg_vc1_mspel_pixel
It seems like it can't... update using AV_CPU_FLAG_RV_MISALIGNED
Rémi Denis-Courmont 于2024年5月12日周日 19:48写道：
> Le perjantaina 10. toukokuuta 2024, 11.21.14 EEST u...@foxmail.com a
> écrit :
> > From: sunyuechi
> >
> > C908 X60
> > vc1dsp.avg_
From: sunyuechi
C908 X60
vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_c: 14.7 13.2
vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_rvv_i32 : 2.5 2.2
vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_c: 3.7 3.5
vc1dsp.avg_vc1_mspel_pixel
On 12/05/2024 14:24, Yotam Ofek wrote:
Nope :)
Last commit that touched this was 9 years ago, seems like it's an oversight
that was never noticed/fixed.
The native AAC encoder is stable, even if this code was supposed to behave
differently, it's probably good enough as is, and I think that having
flac_lpc_16_13_c: 2841.3
flac_lpc_16_13_sse4: 2151.8
flac_lpc_16_16_c: 3382.8
flac_lpc_16_16_sse4: 2228.3
flac_lpc_16_29_c: 5800.3
flac_lpc_16_29_sse4: 3727.3
flac_lpc_16_32_c: 5972.8
flac_lpc_16_32_sse4: 4052.3
Signed-off-by: James Almer
---
libavcodec/x86/flacdsp.asm| 13 +++--
lib
Signed-off-by: James Almer
---
libavcodec/flacdec.c | 8 ++--
libavcodec/flacdsp.c | 20
libavcodec/flacdsp.h | 3 +++
3 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
index 91bbdc657d..6e6a2896b4 100644
--- a/l
Signed-off-by: James Almer
---
tests/checkasm/flacdsp.c | 24
1 file changed, 24 insertions(+)
diff --git a/tests/checkasm/flacdsp.c b/tests/checkasm/flacdsp.c
index d694c1093b..343bee41ed 100644
--- a/tests/checkasm/flacdsp.c
+++ b/tests/checkasm/flacdsp.c
@@ -83,6 +83,
flac_wasted_32_c: 851.3
flac_wasted_32_sse2: 53.3
Signed-off-by: James Almer
---
libavcodec/x86/flacdsp.asm| 15 +++
libavcodec/x86/flacdsp_init.c | 3 +++
2 files changed, 18 insertions(+)
diff --git a/libavcodec/x86/flacdsp.asm b/libavcodec/x86/flacdsp.asm
index f38eb7db76..3
Signed-off-by: James Almer
---
tests/checkasm/flacdsp.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/tests/checkasm/flacdsp.c b/tests/checkasm/flacdsp.c
index 343bee41ed..6abdd255a3 100644
--- a/tests/checkasm/flacdsp.c
+++ b/tests/checkasm/flacdsp.c
@@ -104,6 +104,2
flac_wasted_33_c: 214.1
flac_wasted_33_sse4: 133.6
flac_wasted_33_avx2: 93.1
Signed-off-by: James Almer
---
libavcodec/x86/flacdsp.asm| 24
libavcodec/x86/flacdsp_init.c | 6 ++
2 files changed, 30 insertions(+)
diff --git a/libavcodec/x86/flacdsp.asm b/libavco
On Sat May 4, 2024 at 9:05 PM CEST, Michael Niedermayer wrote:
> On Sat, May 04, 2024 at 09:11:12AM +0800, flow gg wrote:
> > [...]
> > If you need to use git-send-email, I may not be able to submit any code
> > If you do not need to use git-send-email, it is troublesome for the
> > reviewer and th
James Almer:
> Signed-off-by: James Almer
> ---
> libavcodec/flacdec.c | 8 ++--
> libavcodec/flacdsp.c | 20
> libavcodec/flacdsp.h | 3 +++
> 3 files changed, 25 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
> index 91bbdc
Le sunnuntaina 12. toukokuuta 2024, 19.06.54 EEST James Almer a écrit :
> Signed-off-by: James Almer
> ---
> tests/checkasm/flacdsp.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/tests/checkasm/flacdsp.c b/tests/checkasm/flacdsp.c
> index d694c1093b..343bee4
Signed-off-by: James Almer
---
tests/checkasm/flacdsp.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/tests/checkasm/flacdsp.c b/tests/checkasm/flacdsp.c
index d694c1093b..ee0897ed01 100644
--- a/tests/checkasm/flacdsp.c
+++ b/tests/checkasm/flacdsp.c
@@ -83,6 +8
On 5/12/2024 1:15 PM, Andreas Rheinhardt wrote:
James Almer:
Signed-off-by: James Almer
---
libavcodec/flacdec.c | 8 ++--
libavcodec/flacdsp.c | 20
libavcodec/flacdsp.h | 3 +++
3 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/libavcodec/flacdec.
T-Head C908:
flac_wasted_32_c: 949.0
flac_wasted_32_rvv_i32: 278.7
---
libavcodec/riscv/flacdsp_init.c | 7 ++-
libavcodec/riscv/flacdsp_rvv.S | 15 +++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/libavcodec/riscv/flacdsp_init.c b/libavcodec/riscv/flacdsp
T-Head C908:
flac_wasted_33_c: 1040.0
flac_wasted_33_rvv_i64: 711.2
---
libavcodec/riscv/flacdsp_init.c | 4
libavcodec/riscv/flacdsp_rvv.S | 16
2 files changed, 20 insertions(+)
diff --git a/libavcodec/riscv/flacdsp_init.c b/libavcodec/riscv/flacdsp_init.c
index 404
On 5/12/2024 2:07 PM, Rémi Denis-Courmont wrote:
T-Head C908:
flac_wasted_32_c: 949.0
flac_wasted_32_rvv_i32: 278.7
---
libavcodec/riscv/flacdsp_init.c | 7 ++-
libavcodec/riscv/flacdsp_rvv.S | 15 +++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/liba
flac_wasted_32_c: 851.3
flac_wasted_32_sse2: 41.3
Signed-off-by: James Almer
---
libavcodec/x86/flacdsp.asm| 24
libavcodec/x86/flacdsp_init.c | 3 +++
2 files changed, 27 insertions(+)
diff --git a/libavcodec/x86/flacdsp.asm b/libavcodec/x86/flacdsp.asm
index f38e
flac_wasted_33_c: 214.1
flac_wasted_33_sse4: 103.2
Signed-off-by: James Almer
---
Removed the AVX2 one as the lane crossing in pmovsxdq removed pretty much all
speed up for processing twice the amount of data.
libavcodec/x86/flacdsp.asm| 25 +
libavcodec/x86/flacdsp_
Le sunnuntaina 12. toukokuuta 2024, 21.37.28 EEST James Almer a écrit :
> Not sure if you're taking it into account, but the minimum blocksize is
> 16
Granted, this only fills a single 8-vector vector group (v8-v15), so only a
quarter of the register bank (v0-v31), which is unusually low. But tha
T-Head C908:
flac_wasted_33_c: 786.2
flac_wasted_33_rvv_i64: 486.5
---
libavcodec/riscv/flacdsp_init.c | 4
libavcodec/riscv/flacdsp_rvv.S | 16
2 files changed, 20 insertions(+)
diff --git a/libavcodec/riscv/flacdsp_init.c b/libavcodec/riscv/flacdsp_init.c
index 404
On Sat, May 11, 2024 at 10:51:04PM +0200, Andreas Rheinhardt wrote:
> This way said function sets everything (except for the actual
> contents of the frame's data). Also rename it to prepare_picture()
> given its new role.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/mpegvideo_enc.c
On 12/05/2024 20:51, James Almer wrote:
flac_wasted_32_c: 851.3
flac_wasted_32_sse2: 41.3
Signed-off-by: James Almer
---
libavcodec/x86/flacdsp.asm| 24
libavcodec/x86/flacdsp_init.c | 3 +++
2 files changed, 27 insertions(+)
diff --git a/libavcodec/x86/flacds
Signed-off-by: James Almer
---
libavcodec/flacdec.c | 7 +--
libavcodec/flacdsp.c | 15 +++
libavcodec/flacdsp.h | 2 ++
3 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
index 6e6a2896b4..460d3bc01e 100644
--- a/libavcod
Signed-off-by: James Almer
---
tests/checkasm/flacdsp.c | 32
1 file changed, 32 insertions(+)
diff --git a/tests/checkasm/flacdsp.c b/tests/checkasm/flacdsp.c
index 96b7d05f7e..6f8e8817b5 100644
--- a/tests/checkasm/flacdsp.c
+++ b/tests/checkasm/flacdsp.c
@@ -8
The only multiplicators used in scalarproduct_and_madd_*
are -1, 0 and +1. Yet it is of type int and the checkasm
test uses the complete range of int for it, leading to overflows
that don't happen for actual users.
Fix this by using a more reasonable range for mul: Given
that it is used in v1[i] +
Fixes: CID1500300 Unchecked return value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/notchlc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/notchlc.c b/libavcodec/notchlc.c
index 6dd3f884407..30427f4ba92 100644
--- a/li
It seems nothing prevents such overflow even though odd
Fixes: CID1441934 Unintentional integer overflow
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/pcm-dvdenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/pcm-dvdenc.c b
If its not replaced we would have a negative index used in an array potentially
Helps: CID1440385 Negative array index read
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/proresenc_anatoliy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --gi
Fixes: CID1477406 Improper use of negative value
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/qsvdec.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index ed0bfe4c8b8..a51ddace622 1006
On Sun, May 12, 2024 at 02:29:57AM +0200, Lynne via ffmpeg-devel wrote:
> On 12/05/2024 02:18, Michael Niedermayer wrote:
> > On Sun, May 12, 2024 at 02:13:06AM +0200, Lynne via ffmpeg-devel wrote:
> > > On 12/05/2024 02:03, Michael Niedermayer wrote:
> > > > Fixes: CID1473514 Uninitialized scalar
On Mon, May 06, 2024 at 02:38:45AM +0200, Michael Niedermayer wrote:
> Fixes: CID1596534 Dereference after null check
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/h2645_sei.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
will appl
On Mon, May 06, 2024 at 03:23:07AM +0200, Michael Niedermayer wrote:
> Fixes: CID1439574 Dereference after null check
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/h264_slice.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
will apply
[.
On Sun, May 05, 2024 at 01:52:00AM +0200, Michael Niedermayer wrote:
> Fixes: CID1529220 Unused value
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/fmvc.c | 1 -
> 1 file changed, 1 deletion(-)
will apply
[...]
--
Michael GnuPG fingerprint:
On Fri, May 03, 2024 at 11:54:58PM +0200, Michael Niedermayer wrote:
> Fixes: CID1538861 Uninitialized scalar variable
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/decode.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
will apply what
On Sat, May 11, 2024 at 08:33:06PM -0400, Brad Smith wrote:
> MAINTAINERS: add myself as *BSD maintainer
>
> I try to help out with *BSD patches or build related issues where I can.
>
> Signed-off-by: Brad Smith
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
will apply
thx
[...]
On Sat, May 11, 2024 at 03:22:53AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/base64.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
will apply patchset
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
On Ma, 2024-05-13 at 03:20 +0200, Michael Niedermayer wrote:
> Fixes: CID1477406 Improper use of negative value
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/qsvdec.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git
On Mon, 13 May 2024, 02:32 Michael Niedermayer,
wrote:
> On Mon, May 06, 2024 at 03:23:07AM +0200, Michael Niedermayer wrote:
> > Fixes: CID1439574 Dereference after null check
> >
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/h264_slice.c |
Le 6 mai 2024 04:23:07 GMT+03:00, Michael Niedermayer
a écrit :
>Fixes: CID1439574 Dereference after null check
If SPS is guaranteed to be non-NULL, there should probably be an assertion to
document it, and it should be *before* that alleged dereference (which is not
visible in the patch con
Le 5 mai 2024 02:51:59 GMT+03:00, Michael Niedermayer
a écrit :
>Fixes: CID1454676 Out-of-bounds read
It's a stretch to call this "fixing". It just asserts that the situation
doesn't happen, in other words, that it is a false positive from the static
analyser.
The code change looks OK, but
On Wo, 2024-05-08 at 14:03 +0800, Xiang, Haihao wrote:
> From: Haihao Xiang
>
> Signed-off-by: Haihao Xiang
> ---
> libavfilter/qsvvpp.c | 52
> 1 file changed, 29 insertions(+), 23 deletions(-)
>
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qs
On Vr, 2024-05-10 at 11:55 +0200, David Rosca wrote:
> Matches other hwaccels.
> ---
> libavcodec/vaapi_decode.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index 8e9f647c20..3c4030c073 100644
> --- a/libavcodec/vaapi_decod
tor 2024-05-02 klockan 13:44 -0400 skrev Vittorio Giovara:
> I believe the path forward would be designing a system that can
> accommodate
> both workflows, a main git{hub,lab} interface which can send and
> mirror the
> discussion happening on the mailing list for those who prefer emails.
> Such
>
sön 2024-05-12 klockan 01:07 +0200 skrev Tomas Härdin:
> fre 2024-05-10 klockan 14:48 +0200 skrev Andreas Rheinhardt:
> > Tomas Härdin:
> > > ons 2024-05-08 klockan 17:06 -0300 skrev James Almer:
> > > > On 5/8/2024 5:01 PM, Marton Balint wrote:
> > > > >
> > > > >
> > > > > On Wed, 8 May 2024, T
69 matches
Mail list logo
