date:20240301

[FFmpeg-devel] [PATCH 4/4] lavc/vp9dsp: R-V V ipred tm

2024-03-01 Thread flow gg


From 3128765d298f5a44fd13be7b3da2ef88c96083f9 Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Sat, 2 Mar 2024 09:35:22 +0800
Subject: [PATCH 4/4] lavc/vp9dsp: R-V V ipred tm

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 | 143 +++
 libavcodec/riscv/vp9dsp.h|   8 ++
 libavcodec/riscv/vp9dsp_init.c   |   4 +
 3 files changed, 155 insertions(+)

diff --git a/libavcodec/riscv/vp9_intra_rvv.S b/libavcodec/riscv/vp9_intra_rvv.S
index 35fb0ebe10..a8265255c4 100644
--- a/libavcodec/riscv/vp9_intra_rvv.S
+++ b/libavcodec/riscv/vp9_intra_rvv.S
@@ -290,3 +290,146 @@ func ff_h_8x8_rvv, zve32x
 
 ret
 endfunc
+
+.macro tm_sum dst, top, offset
+lbu  t3, \offset(a2)
+sub  t3, t3, a4
+vadd.vx  \dst, \top, t3
+.endm
+
+func ff_tm_32x32_rvv, zve32x
+lbu  a4, -1(a3)
+li   t5, 32
+
+.macro tm_sum32 n1,n2,n3,n4,n5,n6,n7,n8
+
+vsetvli  zero, t5, e16, m4, ta, ma
+vle8.v   v8, (a3)
+vzext.vf2v28, v8
+
+tm_sum   v0, v28, \n1
+tm_sum   v4, v28, \n2
+tm_sum   v8, v28, \n3
+tm_sum   v12, v28, \n4
+tm_sum   v16, v28, \n5
+tm_sum   v20, v28, \n6
+tm_sum   v24, v28, \n7
+tm_sum   v28, v28, \n8
+
+.irp n 0, 4, 8, 12, 16, 20, 24, 28
+vmax.vx  v\n, v\n, zero
+.endr
+
+vsetvli  zero, zero, e8, m2, ta, ma
+.irp n 0, 4, 8, 12, 16, 20, 24, 28
+vnclipu.wi   v\n, v\n, 0
+vse8.v   v\n, (a0)
+add  a0, a0, a1
+.endr
+
+.endm
+
+tm_sum32 31, 30, 29, 28, 27, 26, 25, 24
+tm_sum32 23, 22, 21, 20, 19, 18, 17, 16
+tm_sum32 15, 14, 13, 12, 11, 10, 9, 8
+tm_sum32 7, 6, 5, 4, 3, 2, 1, 0
+
+ret
+endfunc
+
+func ff_tm_16x16_rvv, zve32x
+vsetivli  zero, 16, e16, m2, ta, ma
+vle8.vv8, (a3)
+vzext.vf2 v30, v8
+lbu   a4, -1(a3)
+
+tm_sum   v0, v30, 15
+tm_sum   v2, v30, 14
+tm_sum   v4, v30, 13
+tm_sum   v6, v30, 12
+tm_sum   v8, v30, 11
+tm_sum   v10, v30, 10
+tm_sum   v12, v30, 9
+tm_sum   v14, v30, 8
+tm_sum   v16, v30, 7
+tm_sum   v18, v30, 6
+tm_sum   v20, v30, 5
+tm_sum   v22, v30, 4
+tm_sum   v24, v30, 3
+tm_sum   v26, v30, 2
+tm_sum   v28, v30, 1
+tm_sum   v30, v30, 0
+
+.irp n 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30
+vmax.vx  v\n, v\n, zero
+.endr
+
+vsetvli  zero, zero, e8, m1, ta, ma
+.irp n 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28
+vnclipu.wi   v\n, v\n, 0
+vse8.v   v\n, (a0)
+add  a0, a0, a1
+.endr
+vnclipu.wi   v30, v30, 0
+vse8.v   v30, (a0)
+
+ret
+endfunc
+
+func ff_tm_8x8_rvv, zve32x
+vsetivli zero, 8, e16, m1, ta, ma
+vle8.v   v8, (a3)
+vzext.vf2v28, v8
+lbu  a4, -1(a3)
+
+tm_sum   v16, v28, 7
+tm_sum   v17, v28, 6
+tm_sum   v18, v28, 5
+tm_sum   v19, v28, 4
+tm_sum   v20, v28, 3
+tm_sum   v21, v28, 2
+tm_sum   v22, v28, 1
+tm_sum   v23, v28, 0
+
+.irp n 16, 17, 18, 19, 20, 21, 22, 23
+vmax.vx  v\n, v\n, zero
+.endr
+
+vsetvli  zero, zero, e8, mf2, ta, ma
+.irp n 16, 17, 18, 19, 20, 21, 22
+vnclipu.wi   v\n, v\n, 0
+vse8.v   v\n, (a0)
+add  a0, a0, a1
+.endr
+vnclipu.wi   v24, v23, 0
+vse8.v   v24, (a0)
+
+ret
+endfunc
+
+func ff_tm_4x4_rvv, zve32x
+vsetivli zero, 4, e16, mf2, ta, ma
+vle8.v   v8, (a3)
+vzext.vf2v28, v8
+lbu  a4, -1(a3)
+
+tm_sum   v16, v28, 3
+tm_sum   v17, v28, 2
+tm_sum   v18, v28, 1
+tm_sum   v19, v28, 0
+
+.irp n 16, 17, 18, 19
+vmax.vx  v\n, v\n, zero
+.endr
+
+vsetvli  zero, zero, e8, mf4, ta, ma
+.irp n 16, 17, 18
+vnclipu.wi   v\n, v\n, 0
+vse8.v   v\n, (a0)
+add  a0, a0, a1
+.endr
+vnclipu.wi   v24, v19, 0
+vse8.v   v24, (a0)
+
+ret
+endfunc
diff --git a/libavcodec/riscv/vp9dsp.h b/libavcodec/riscv/vp9dsp.h
index 2b2e0db0d8..cff2310e5c 100644
--- a/libavcodec/riscv/vp9dsp.h
+++ b/libavcodec/riscv/vp9dsp.h
@@

[FFmpeg-devel] [PATCH 3/4] lavc/vp9dsp: R-V V ipred hor

2024-03-01 Thread flow gg


From 173072b33d3237b924f3fa342e20558d96a72457 Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Sat, 2 Mar 2024 08:35:39 +0800
Subject: [PATCH 3/4] lavc/vp9dsp: R-V V ipred hor

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/vp9dsp.h|  6 
 libavcodec/riscv/vp9dsp_init.c   |  3 ++
 3 files changed, 65 insertions(+)

diff --git a/libavcodec/riscv/vp9_intra_rvv.S b/libavcodec/riscv/vp9_intra_rvv.S
index 88b54f37b0..35fb0ebe10 100644
--- a/libavcodec/riscv/vp9_intra_rvv.S
+++ b/libavcodec/riscv/vp9_intra_rvv.S
@@ -234,3 +234,59 @@ func ff_v_8x8_rvv, zve64x
 
 ret
 endfunc
+
+func ff_h_32x32_rvv, zve32x
+li   t0, 32
+addi a2, a2, 31
+vsetvli  zero, t0, e8, m2, ta, ma
+
+.rept 2
+.irp n 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30
+lbu  t1, (a2)
+addi a2, a2, -1
+vmv.v.x  v\n, t1
+.endr
+.irp n 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30
+vse8.v   v\n, (a0)
+add  a0, a0, a1
+.endr
+.endr
+
+ret
+endfunc
+
+func ff_h_16x16_rvv, zve32x
+addi a2, a2, 15
+vsetivli zero, 16, e8, m1, ta, ma
+
+.irp n 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23
+lbu  t1, (a2)
+addi a2, a2, -1
+vmv.v.x  v\n, t1
+.endr
+.irp n 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22
+vse8.v   v\n, (a0)
+add  a0, a0, a1
+.endr
+vse8.v   v23, (a0)
+
+ret
+endfunc
+
+func ff_h_8x8_rvv, zve32x
+addi a2, a2, 7
+vsetivli zero, 8, e8, mf2, ta, ma
+
+.irp n 8, 9, 10, 11, 12, 13, 14, 15
+lbu  t1, (a2)
+addi a2, a2, -1
+vmv.v.x  v\n, t1
+.endr
+.irp n 8, 9, 10, 11, 12, 13, 14
+vse8.v   v\n, (a0)
+add  a0, a0, a1
+.endr
+vse8.v   v15, (a0)
+
+ret
+endfunc
diff --git a/libavcodec/riscv/vp9dsp.h b/libavcodec/riscv/vp9dsp.h
index ae4fb266d0..2b2e0db0d8 100644
--- a/libavcodec/riscv/vp9dsp.h
+++ b/libavcodec/riscv/vp9dsp.h
@@ -66,5 +66,11 @@ void ff_v_16x16_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
 const uint8_t *a);
 void ff_v_8x8_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
   const uint8_t *a);
+void ff_h_32x32_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
+const uint8_t *a);
+void ff_h_16x16_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
+const uint8_t *a);
+void ff_h_8x8_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
+  const uint8_t *a);
 
 #endif  // #ifndef AVCODEC_RISCV_VP9DSP_RISCV_H
diff --git a/libavcodec/riscv/vp9dsp_init.c b/libavcodec/riscv/vp9dsp_init.c
index 9c550d40b5..16aeeb260a 100644
--- a/libavcodec/riscv/vp9dsp_init.c
+++ b/libavcodec/riscv/vp9dsp_init.c
@@ -54,6 +54,9 @@ static av_cold void vp9dsp_intrapred_init_rvv(VP9DSPContext *dsp, int bpp)
 dsp->intra_pred[TX_16X16][TOP_DC_PRED] = ff_dc_top_16x16_rvv;
 dsp->intra_pred[TX_32X32][VERT_PRED] = ff_v_32x32_rvv;
 dsp->intra_pred[TX_16X16][VERT_PRED] = ff_v_16x16_rvv;
+dsp->intra_pred[TX_32X32][HOR_PRED] = ff_h_32x32_rvv;
+dsp->intra_pred[TX_16X16][HOR_PRED] = ff_h_16x16_rvv;
+dsp->intra_pred[TX_8X8][HOR_PRED] = ff_h_8x8_rvv;
 }
 #endif
 }
-- 
2.44.0

___
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.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/4] lavc/vp9dsp: R-V V ipred vert

2024-03-01 Thread flow gg


From 7abd262daa281cee412a905ea75a5f10dd0b1fbe Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Fri, 1 Mar 2024 18:38:43 +0800
Subject: [PATCH 2/4] lavc/vp9dsp: R-V V ipred vert

C908:
vp9_vert_8x8_8bpp_c: 22.0
vp9_vert_8x8_8bpp_rvv_i64: 18.5
vp9_vert_16x16_8bpp_c: 71.2
vp9_vert_16x16_8bpp_rvv_i32: 50.7
vp9_vert_32x32_8bpp_c: 300.2
vp9_vert_32x32_8bpp_rvv_i32: 136.7
---
 libavcodec/riscv/vp9_intra_rvv.S | 35 
 libavcodec/riscv/vp9dsp.h|  6 ++
 libavcodec/riscv/vp9dsp_init.c   |  3 +++
 3 files changed, 44 insertions(+)

diff --git a/libavcodec/riscv/vp9_intra_rvv.S b/libavcodec/riscv/vp9_intra_rvv.S
index b3b0470cfc..88b54f37b0 100644
--- a/libavcodec/riscv/vp9_intra_rvv.S
+++ b/libavcodec/riscv/vp9_intra_rvv.S
@@ -199,3 +199,38 @@ endfunc
 func ff_dc_top_8x8_rvv, zve64x
 dc8x8 top
 endfunc
+
+func ff_v_32x32_rvv, zve32x
+vsetivli zero, 8, e8, mf2, ta, ma
+vle32.v  v8, (a3)
+
+.rept 31
+vse32.v  v8, (a0)
+add  a0, a0, a1
+.endr
+vse32.v  v8, (a0)
+
+ret
+endfunc
+
+func ff_v_16x16_rvv, zve32x
+vsetivli zero, 4, e8, mf4, ta, ma
+vle32.v  v8, (a3)
+
+.rept 15
+vse32.v  v8, (a0)
+add  a0, a0, a1
+.endr
+vse32.v  v8, (a0)
+
+ret
+endfunc
+
+func ff_v_8x8_rvv, zve64x
+ld   t0, (a3)
+vsetivli zero, 8, e64, m4, ta, ma
+vmv.v.x  v8, t0
+vsse64.v v8, (a0), a1
+
+ret
+endfunc
diff --git a/libavcodec/riscv/vp9dsp.h b/libavcodec/riscv/vp9dsp.h
index abd57bd836..ae4fb266d0 100644
--- a/libavcodec/riscv/vp9dsp.h
+++ b/libavcodec/riscv/vp9dsp.h
@@ -60,5 +60,11 @@ void ff_dc_129_16x16_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
  const uint8_t *a);
 void ff_dc_129_8x8_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
const uint8_t *a);
+void ff_v_32x32_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
+const uint8_t *a);
+void ff_v_16x16_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
+const uint8_t *a);
+void ff_v_8x8_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
+  const uint8_t *a);
 
 #endif  // #ifndef AVCODEC_RISCV_VP9DSP_RISCV_H
diff --git a/libavcodec/riscv/vp9dsp_init.c b/libavcodec/riscv/vp9dsp_init.c
index 69ab39004c..9c550d40b5 100644
--- a/libavcodec/riscv/vp9dsp_init.c
+++ b/libavcodec/riscv/vp9dsp_init.c
@@ -36,6 +36,7 @@ static av_cold void vp9dsp_intrapred_init_rvv(VP9DSPContext *dsp, int bpp)
 dsp->intra_pred[TX_8X8][DC_128_PRED] = ff_dc_128_8x8_rvv;
 dsp->intra_pred[TX_8X8][DC_129_PRED] = ff_dc_129_8x8_rvv;
 dsp->intra_pred[TX_8X8][TOP_DC_PRED] = ff_dc_top_8x8_rvv;
+dsp->intra_pred[TX_8X8][VERT_PRED] = ff_v_8x8_rvv;
 }
 
 if (bpp == 8 && flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
@@ -51,6 +52,8 @@ static av_cold void vp9dsp_intrapred_init_rvv(VP9DSPContext *dsp, int bpp)
 dsp->intra_pred[TX_16X16][DC_129_PRED] = ff_dc_129_16x16_rvv;
 dsp->intra_pred[TX_32X32][TOP_DC_PRED] = ff_dc_top_32x32_rvv;
 dsp->intra_pred[TX_16X16][TOP_DC_PRED] = ff_dc_top_16x16_rvv;
+dsp->intra_pred[TX_32X32][VERT_PRED] = ff_v_32x32_rvv;
+dsp->intra_pred[TX_16X16][VERT_PRED] = ff_v_16x16_rvv;
 }
 #endif
 }
-- 
2.44.0

___
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.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/4] lavc/vp9dsp: R-V V ipred dc

2024-03-01 Thread flow gg


From adaae06a3e18bccec1772a3134334cbea652ae77 Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Mon, 26 Feb 2024 14:42:17 +0800
Subject: [PATCH 1/4] lavc/vp9dsp: R-V V ipred dc

C908:
vp9_dc_8x8_8bpp_c: 46.0
vp9_dc_8x8_8bpp_rvv_i64: 41.0
vp9_dc_16x16_8bpp_c: 109.2
vp9_dc_16x16_8bpp_rvv_i32: 72.7
vp9_dc_32x32_8bpp_c: 365.2
vp9_dc_32x32_8bpp_rvv_i32: 165.5
vp9_dc_127_8x8_8bpp_c: 23.0
vp9_dc_127_8x8_8bpp_rvv_i64: 22.0
vp9_dc_127_16x16_8bpp_c: 70.2
vp9_dc_127_16x16_8bpp_rvv_i32: 51.7
vp9_dc_127_32x32_8bpp_c: 295.2
vp9_dc_127_32x32_8bpp_rvv_i32: 140.2
vp9_dc_128_8x8_8bpp_c: 23.0
vp9_dc_128_8x8_8bpp_rvv_i64: 22.0
vp9_dc_128_16x16_8bpp_c: 70.2
vp9_dc_128_16x16_8bpp_rvv_i32: 51.7
vp9_dc_128_32x32_8bpp_c: 295.2
vp9_dc_128_32x32_8bpp_rvv_i32: 140.2
vp9_dc_129_8x8_8bpp_c: 23.0
vp9_dc_129_8x8_8bpp_rvv_i64: 22.0
vp9_dc_129_16x16_8bpp_c: 70.2
vp9_dc_129_16x16_8bpp_rvv_i32: 51.7
vp9_dc_129_32x32_8bpp_c: 295.2
vp9_dc_129_32x32_8bpp_rvv_i32: 140.2
vp9_dc_left_8x8_8bpp_c: 38.0
vp9_dc_left_8x8_8bpp_rvv_i64: 36.0
vp9_dc_left_16x16_8bpp_c: 93.2
vp9_dc_left_16x16_8bpp_rvv_i32: 67.7
vp9_dc_left_32x32_8bpp_c: 333.2
vp9_dc_left_32x32_8bpp_rvv_i32: 158.5
vp9_dc_top_8x8_8bpp_c: 38.7
vp9_dc_top_8x8_8bpp_rvv_i64: 36.0
vp9_dc_top_16x16_8bpp_c: 93.2
vp9_dc_top_16x16_8bpp_rvv_i32: 67.7
vp9_dc_top_32x32_8bpp_c: 333.2
vp9_dc_top_32x32_8bpp_rvv_i32: 156.2
---
 libavcodec/riscv/Makefile|   2 +
 libavcodec/riscv/vp9_intra_rvv.S | 201 +++
 libavcodec/riscv/vp9dsp.h|  64 ++
 libavcodec/riscv/vp9dsp_init.c   |  61 ++
 libavcodec/vp9dsp.c  |   2 +
 libavcodec/vp9dsp.h  |   1 +
 6 files changed, 331 insertions(+)
 create mode 100644 libavcodec/riscv/vp9_intra_rvv.S
 create mode 100644 libavcodec/riscv/vp9dsp.h
 create mode 100644 libavcodec/riscv/vp9dsp_init.c

diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index dff8784102..c237e60800 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -60,5 +60,7 @@ OBJS-$(CONFIG_VC1DSP) += riscv/vc1dsp_init.o
 RVV-OBJS-$(CONFIG_VC1DSP) += riscv/vc1dsp_rvv.o
 OBJS-$(CONFIG_VP8DSP) += riscv/vp8dsp_init.o
 RVV-OBJS-$(CONFIG_VP8DSP) += riscv/vp8dsp_rvv.o
+OBJS-$(CONFIG_VP9_DECODER) += riscv/vp9dsp_init.o
+RVV-OBJS-$(CONFIG_VP9_DECODER) += riscv/vp9_intra_rvv.o
 OBJS-$(CONFIG_VORBIS_DECODER) += riscv/vorbisdsp_init.o
 RVV-OBJS-$(CONFIG_VORBIS_DECODER) += riscv/vorbisdsp_rvv.o
diff --git a/libavcodec/riscv/vp9_intra_rvv.S b/libavcodec/riscv/vp9_intra_rvv.S
new file mode 100644
index 00..b3b0470cfc
--- /dev/null
+++ b/libavcodec/riscv/vp9_intra_rvv.S
@@ -0,0 +1,201 @@
+/*
+ * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/riscv/asm.S"
+
+.macro getdc type size
+vmv.v.x  v16, zero
+.ifc \type,top
+vle8.v   v8, (a3)
+vwredsumu.vs v16, v8, v16
+vsetivli zero, 1, e16, m1, ta, ma
+vmv.x.s  t1, v16
+.ifc \size,32
+addi t1, t1, 16
+srai t1, t1, 5
+.elseif \size == 16
+addi t1, t1, 8
+srai t1, t1, 4
+.elseif \size == 8
+addi t1, t1, 4
+srai t1, t1, 3
+.endif
+.elseif \type == left
+vle8.v   v8, (a2)
+vwredsumu.vs v16, v8, v16
+vsetivli zero, 1, e16, m1, ta, ma
+vmv.x.s  t1, v16
+.ifc \size,32
+addi t1, t1, 16
+srai t1, t1, 5
+.elseif \size == 16
+addi t1, t1, 8
+srai t1, t1, 4
+.elseif \size == 8
+addi t1, t1, 4
+srai t1, t1, 3
+.endif
+.elseif \type == 127
+li   t1, 127
+.elseif \type == 128
+li   t1, 128
+.elseif \type == 129
+li   t1, 129
+.elseif \type == none
+vle8.v   v8, (a2)
+vwredsumu.vs v16, v8, v16
+vle8.v   v8, (a3)
+vwredsumu.vs v16, v8, v16
+vsetivli zero, 1, e16, m1, ta, ma
+vmv.x.s  t1, v16
+.ifc

Re: [FFmpeg-devel] [PATCH 3/3] lavc/vp9dsp: R-V V ipred dc dc_left dc_top

2024-03-01 Thread flow gg

please ignore this, updated in "[FFmpeg-devel] [PATCH 1/4] lavc/vp9dsp: R-V
V ipred dc"

flow gg  于2024年2月27日周二 00:19写道：

>
>
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] lavc/vp9dsp: R-V V ipred hor

2024-03-01 Thread flow gg

please ignore this, updated in "[FFmpeg-devel] [PATCH 1/4] lavc/vp9dsp: R-V
V ipred dc"

flow gg  于2024年2月27日周二 00:19写道：

>
>
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] lavc/vp9dsp: R-V V ipred vert

2024-03-01 Thread flow gg

please ignore this, updated in "[FFmpeg-devel] [PATCH 1/4] lavc/vp9dsp: R-V
V ipred dc"

flow gg  于2024年2月27日周二 00:19写道：

>
>
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/vvc/vvcdec: allow vvc_decode_close() on failed open

2024-03-01 Thread Nuo Mi

Pushed the VVC patch.
Thank you, Michael.

On Wed, Feb 28, 2024 at 6:47 AM Michael Niedermayer 
wrote:

> Fixes: division by 0
> Fixes:
> 67008/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-5873503163187200
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/vvc/vvcdec.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/vvc/vvcdec.c b/libavcodec/vvc/vvcdec.c
> index f024cbd067..570e2aa513 100644
> --- a/libavcodec/vvc/vvcdec.c
> +++ b/libavcodec/vvc/vvcdec.c
> @@ -950,13 +950,14 @@ static av_cold void vvc_decode_flush(AVCodecContext
> *avctx)
>  {
>  VVCContext *s  = avctx->priv_data;
>  int got_output = 0;
> -VVCFrameContext *last;
>
>  while (s->nb_delayed)
>  wait_delayed_frame(s, NULL, _output);
>
> -last = get_frame_context(s, s->fcs, s->nb_frames - 1);
> -ff_vvc_flush_dpb(last);
> +if (s->fcs) {
> +VVCFrameContext *last = get_frame_context(s, s->fcs, s->nb_frames
> - 1);
> +ff_vvc_flush_dpb(last);
> +}
>
>  s->eos = 1;
>  }
> --
> 2.17.1
>
> ___
> 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.org with subject "unsubscribe".
>
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] configure: Add missing vvc_decoder->cbs_h266 dependency

2024-03-01 Thread Nuo Mi

pushed, thank you, Andreas.

On Fri, Mar 1, 2024 at 7:51 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Signed-off-by: Andreas Rheinhardt 
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 574c9bf5f6..b5b233e852 100755
> --- a/configure
> +++ b/configure
> @@ -3036,7 +3036,7 @@ vp6f_decoder_select="vp6_decoder"
>  vp7_decoder_select="h264pred videodsp vp8dsp"
>  vp8_decoder_select="h264pred videodsp vp8dsp"
>  vp9_decoder_select="videodsp vp9_parser vp9_superframe_split_bsf"
> -vvc_decoder_select="cabac golomb videodsp"
> +vvc_decoder_select="cabac cbs_h266 golomb videodsp"
>  wcmv_decoder_select="inflate_wrapper"
>  webp_decoder_select="vp8_decoder exif"
>  wmalossless_decoder_select="llauddsp"
> --
> 2.40.1
>
> ___
> 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.org with subject "unsubscribe".
>
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule

2024-03-01 Thread Gyan Doshi




On 2024-03-01 11:03 pm, Anton Khirnov wrote:

* Any member of the TC who had a strong opinion on the question raised
   before it was raised should recuse themselves.

   In particular, must recuse themselves any member of the TC who:
   - participated in the discussion (on the ML, on IRC or elsewhere) in a
 specific direction (minor comments and questions being acceptable);
   - has a personal interest in the outcome;
   - is, was recently or soon will be employed by an entity having a
 personal interest in the outcome or has any kind of hierarchical
 relationship with such entity.
   Failure to do so would result, upon discovery, into the exclusion of
   all FFmpeg governance bodies, including the general assembly, for a
   duration of no less than five years.

   Additionally, any member of the general assembly can recuse any member
   of the TC without having to provide a reason.


I propose a narrower version for this last point as currently it has a 
mix of unenforceable, broad and harsh elements.



* Any member of the TC who has

  - had a major participation in the discussion or demonstrated a partisan
    disposition on the concerned issue at any public venue, or
  - a financial interest in the outcome, either directly or via current or
    anticipated employment or consideration

  is subject to recusal from participation in the TC activities related 
to the
  issue under consideration. This recusal may be effected either 
directly by
  the TC member, or by a vote of the Community Committee (CC) - the TC 
member

  must not participate in any such vote.

  Failure by the TC member to reveal any such involvement as described 
above,
  if judged intentional and material by the CC, shall result in 
exclusion of
  said member from all FFmpeg governance bodies for a period of no less 
than

  two years.


Regards,
Gyan

___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/x86/fpel: Remove remnants of MMX

2024-03-01 Thread Andreas Rheinhardt

Andreas Rheinhardt:
> Since 7cad4dba505f9ad0adf013dd5bdf02a57249eecc
> averaging functions only exist for MMXEXT and SSE2.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/x86/fpel.asm | 23 ---
>  1 file changed, 23 deletions(-)
> 
> diff --git a/libavcodec/x86/fpel.asm b/libavcodec/x86/fpel.asm
> index 278d1410fc..b07b789074 100644
> --- a/libavcodec/x86/fpel.asm
> +++ b/libavcodec/x86/fpel.asm
> @@ -25,16 +25,6 @@
>  
>  SECTION .text
>  
> -%macro PAVGB_MMX 4
> -LOAD   %3, %1
> -por%3, %2
> -pxor   %2, %1
> -pand   %2, %4
> -psrlq  %2, 1
> -psubb  %3, %2
> -SWAP   %2, %3
> -%endmacro
> -
>  ; void ff_put/avg_pixels(uint8_t *block, const uint8_t *pixels,
>  ;ptrdiff_t line_size, int h)
>  %macro OP_PIXELS 2
> @@ -49,12 +39,6 @@ SECTION .text
>  %endif
>  cglobal %1_pixels%2, 4,5,4
>  lea  r4, [r2*3]
> -%ifidn %1, avg
> -%if notcpuflag(mmxext)
> -pcmpeqd  m6, m6
> -paddbm6, m6
> -%endif
> -%endif
>  .loop:
>  %assign %%i 0
>  %rep LEN/mmsize
> @@ -63,17 +47,10 @@ cglobal %1_pixels%2, 4,5,4
>  LOAD m2, [r1+r2*2 + %%i]
>  LOAD m3, [r1+r4 + %%i]
>  %ifidn %1, avg
> -%if notcpuflag(mmxext)
> -PAVGB_MMX[r0 + %%i], m0, m4, m6
> -PAVGB_MMX[r0+r2 + %%i], m1, m5, m6
> -PAVGB_MMX[r0+r2*2 + %%i], m2, m4, m6
> -PAVGB_MMX[r0+r4 + %%i], m3, m5, m6
> -%else
>  pavgbm0, [r0 + %%i]
>  pavgbm1, [r0+r2 + %%i]
>  pavgbm2, [r0+r2*2 + %%i]
>  pavgbm3, [r0+r4 + %%i]
> -%endif
>  %endif
>  SAVE   [r0 + %%i], m0
>  SAVE[r0+r2 + %%i], m1

Will apply this patch tomorrow unless there are objections.

- Andreas

___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] avformat/wavdec: dynamically set max_size by default

2024-03-01 Thread Marton Balint





On Thu, 29 Feb 2024, Marton Balint wrote:




On Thu, 29 Feb 2024, Andreas Rheinhardt wrote:


 Marton Balint:

 The wav demuxer by default tried to demux 4096-byte packets which caused
 packets with very few number of samples for files with high channel
 count.
 This caused a significant overhead especially since the latest ffmpeg.c
 threading changes.

 So let's use a similar approach for selecting audio frame size which is
 already
 used in the PCM demuxer, which is to read 25 times per second but at most
 1024
 samples.


 1024 samples seems to be quite small, in particular for files with few
 channels (like stereo).


1024 is kind of a historical default. Also having multiples of 1024 is 
beneficial for some codecs which encode this many samples per frame.


In any case, I am not against somewhat increasing this, but it should be done 
for both PCM and WAV, it can be a separate patch and discussion.


I will apply this set soon unless there are other comments. Will send a 
patch after that to increase the default sample amount for wav and pcm.


Regards,
Marton
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3] avcodec/jpeg2000dec: support of 2 fields in 1 AVPacket

2024-03-01 Thread Tomas Härdin

sön 2024-02-25 klockan 05:14 +0100 skrev Jerome Martinez:
> On 24/02/2024 13:26, Tomas Härdin wrote:
> > 3a) if the codec is inherently interlaced, call the decoder once
> > 3b) if the codec is not inherently interlaced, call the decoder
> > twice,
> > with appropriate stride, and keep track of the number of bytes
> > decoded
> > so far so we know what offset to start the second decode from
> 
> 
> The place I see for that is in decode_simple_internal().
> But it is a very hot place I don't like to modify, and it seems to me
> some extra code for 99.% (or even more 9s) of files which don't
> need 
> such feature,

See below

> with more risk to forget this specific feature during a
> future dev e.g. not obvious to change also in ff_thread_decode_frame 
> when touching this part.

This is why we adds tests.

> I also needed to add a dedicated AVStream field for saying that the 
> decoder is able to manage this functionality (and is needed there).
> 
> What is the added value to call the decoder twice from decode.c
> rather 
> than recursive call (or a master function in the decoder calling the 
> current function twice, if preferred) inside the decoder only?

We get support for all codecs that can do SEPARATE_FIELDS in MXF,
rather than a half measure that only supports j2k, that we'd have to
fix later anyway.


> > The codecs for which 3b) applies include at least:
> > 
> > * jpeg2000
> 
> Our use case.
> 
> > * ffv1
> 
> FFV1 has its own flags internally for interlaced content (interleaved
> method only) and I expect no work for separated fields. the MXF/FFV1 
> spec does not plan separated fields for FFV1, and there is no byte in
> the essence label for that.

Ah, I missed that

> > * rawvideo
> > * tiff
> 
> I didn't find specifications for the essence label UL corresponding

ULs aren't for specifying interlacing type (though I wouldn't be
surprised if there's a mapping that misuse them for that)

> and 
> I have no file for that, as far as I understand it is highly
> theoretical 

I've had clients asking about VBI data in MXF, which sometimes are
stored as raw samples. It is not outside the realm of possibility that
someone using MXF for archival purposes would use raw video which, due
to the nature of capture equipment, would be stored as SEPARATE_FIELDS.
I'm not aware of a mapping document for this however, but I am aware of
people doing precisely this kind of stuff.

> but if it appears would be only a matter of mapping the MXF signaling
> to 
> the new AVStream field and supporting the feature in the decoders
> (even 
> if we implement the idea of calling the decoder twice, the decoder
> needs 
> to be expanded for this feature).

So in other words putting it into every decoder for which there exists
an MXF mapping for SEPARATE_FIELDS, rather than doing it properly?

/Tomas
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] swresample/resample: rework resample_one function to work the same way as the others

2024-03-01 Thread Marton Balint





On Fri, 1 Mar 2024, Michael Niedermayer wrote:


On Thu, Feb 29, 2024 at 06:55:01PM +0100, Marton Balint wrote:



On Thu, 29 Feb 2024, Michael Niedermayer wrote:


On Tue, Feb 27, 2024 at 10:48:10AM +0100, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 libswresample/resample.c  | 29 +++--
 libswresample/resample.h  |  4 ++--
 libswresample/resample_template.c | 14 --
 3 files changed, 21 insertions(+), 26 deletions(-)

diff --git a/libswresample/resample.c b/libswresample/resample.c
index 17cebad01b..89859dec79 100644
--- a/libswresample/resample.c
+++ b/libswresample/resample.c
@@ -356,26 +356,7 @@ static int multiple_resample(ResampleContext *c, AudioData 
*dst, int dst_size, A

 *consumed = 0;

-if (c->filter_length == 1 && c->phase_count == 1) {
-int64_t index2= (1LL<<32)*c->frac/c->src_incr + (1LL<<32)*c->index + 1;
-int64_t incr= (1LL<<32) * c->dst_incr / c->src_incr + 1;
-int new_size = (src_size * (int64_t)c->src_incr - c->frac + c->dst_incr - 
1) / c->dst_incr;
-
-dst_size = FFMAX(FFMIN(dst_size, new_size), 0);
-if (dst_size > 0) {
-for (i = 0; i < dst->ch_count; i++) {
-c->dsp.resample_one(dst->ch[i], src->ch[i], dst_size, index2, 
incr);
-if (i+1 == dst->ch_count) {
-c->index += dst_size * c->dst_incr_div;
-c->index += (c->frac + dst_size * (int64_t)c->dst_incr_mod) / 
c->src_incr;
-av_assert2(c->index >= 0);
-*consumed = c->index;
-c->frac   = (c->frac + dst_size * (int64_t)c->dst_incr_mod) % 
c->src_incr;
-c->index = 0;
-}
-}
-}
-} else {
+{
 int64_t end_index = (1LL + src_size - c->filter_length) * 
c->phase_count;
 int64_t delta_frac = (end_index - c->index) * c->src_incr - c->frac;
 int delta_n = (delta_frac + c->dst_incr - 1) / c->dst_incr;
@@ -386,8 +367,12 @@ static int multiple_resample(ResampleContext *c, AudioData 
*dst, int dst_size, A
 if (dst_size > 0) {
 /* resample_linear and resample_common should have same behavior
  * when frac and dst_incr_mod are zero */
-resample_func = (c->linear && (c->frac || c->dst_incr_mod)) ?
-c->dsp.resample_linear : c->dsp.resample_common;
+if (c->filter_length == 1 && c->phase_count == 1)
+resample_func = c->dsp.resample_one;
+else if (c->linear && (c->frac || c->dst_incr_mod))
+resample_func = c->dsp.resample_linear;
+else
+resample_func = c->dsp.resample_common;
 for (i = 0; i < dst->ch_count; i++)
 *consumed = resample_func(c, dst->ch[i], src->ch[i], dst_size, 
i+1 == dst->ch_count);
 }
diff --git a/libswresample/resample.h b/libswresample/resample.h
index 1731dad3cf..8cc29effe8 100644
--- a/libswresample/resample.h
+++ b/libswresample/resample.h
@@ -51,8 +51,8 @@ typedef struct ResampleContext {
 int phase_count_compensation;  /* desired phase_count when 
compensation is enabled */

 struct {
-void (*resample_one)(void *dst, const void *src,
- int n, int64_t index, int64_t incr);
+int (*resample_one)(struct ResampleContext *c, void *dst,
+const void *src, int n, int update_ctx);
 int (*resample_common)(struct ResampleContext *c, void *dst,
const void *src, int n, int update_ctx);
 int (*resample_linear)(struct ResampleContext *c, void *dst,
diff --git a/libswresample/resample_template.c 
b/libswresample/resample_template.c
index 4c227b9940..a8114ea918 100644
--- a/libswresample/resample_template.c
+++ b/libswresample/resample_template.c
@@ -72,17 +72,27 @@

 #endif

-static void RENAME(resample_one)(void *dest, const void *source,
- int dst_size, int64_t index2, int64_t incr)
+static int RENAME(resample_one)(ResampleContext *c,
+void *dest, const void *source,
+int dst_size, int update_ctx)
 {
 DELEM *dst = dest;
 const DELEM *src = source;
 int dst_index;



+int64_t index2 = (1LL << 32) * c->frac / c->src_incr + 1 + (1LL << 32) * 
c->index;
+int64_t incr   = (1LL << 32) * c->dst_incr / c->src_incr + 1;


This computation is done repeatedly for each channel, thats not needed
its enough if its done once


I consider that negligable for real cases, and it makes the code cleaner
doing the computations here.


It would make asm optimized functions more difficult to implement too while
being less efficient.




If you insist on this, then it is better to rework all the resample funcs to
work on all channels in a separate patch.


That would be work as IIRC there are asm

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio

2024-03-01 Thread Lynne

Mar 1, 2024, 21:33 by an...@khirnov.net:

> Quoting Lynne (2024-03-01 20:41:53)
>
>> Mar 1, 2024, 19:59 by an...@khirnov.net:
>>
>> > Quoting Lynne (2024-02-29 14:30:55)
>> >
>> >> We offer support for it. Someone must have used it.
>> >> I'm sure there are less used game codecs we support than Sonic.
>> >>
>> >
>> > [citation needed]
>> >
>> > Is there any evidence that it was used for anything other than
>> > development and testing? That anyone has any actual samples in it they'd
>> > like to play?
>> >
>>
>> There's always the possibility that someone encoded samples years
>> ago and deleted the originals. Same as with Snow.
>>
>> My only concern is that this sets a sensitive precedent to get rid of
>> old codec code with low weight under unclear conditions. Where do
>> we draw the line?
>> SMPTE? ISO/IEC standardization? IETF? AOM?
>> Having *a* spec (Sonic doesn't, but neither did FFv1 until a few years
>> ago)?
>> A single company pushing for it many years ago with no spec,
>> like SpeedHQ, or the many niche lossless/intra-only codecs?
>>
>> Or simply having one single implementation in FFmpeg, and no spec at all,
>> and having an experimental flag, and no activity for a very long amount of 
>> time?
>>
>
> I'd draw the line somewhere around what I said above - some evidence
> that it was used "seriously".
>

That is something I cannot agree with - it cuts off 70% of all codecs we 
support,
and zeroes out any potential chance of any codecs being developed by us.


>> If it's the last case, or simply being a one-off, I can agree with 
>> deprecating
>> and remove it next bump. But if the developer thinks they will have time and
>> have motivation to work on it in the future, I think we should leave it at 
>> just
>> deprecation plus disabling  building the encoder by default, until the issue 
>> is
>> brought up again at say, after the next version bump.
>> After all, CELT started out more than 10 years before Opus was standardized,
>> and its EC code has made it all the way to AV2 despite its core remaining
>> visibly similar over the years. And FFv1 was used as an inspiration for FLIC,
>> which went on to become JPEG-XL.
>>
>
> Sure, but there was active interest in all of these. I see no active
> interest in Sonic.
>

No one had any interest in CELT for years until it was used in Mumble,
or Speex initially, or FLIC, as it they were not competitive enough on its own,
and Vorbis, or Opus for the first few years.

The developer has said there's interest in continuing to work on it
in the future.
I don't see why we shouldn't give him a chance to work on it for
a bit longer before we bring it up again for removal. It's a simple
codec with no oddities like self-modifying assembly, codec to
demuxer to codec avpriv interaction or special API user considerations.
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: Restrict skipping Metadata AU cells to metadata streams

2024-03-01 Thread Andreas Rheinhardt

Marton Balint:
> 
> 
> On Fri, 1 Mar 2024, Andreas Rheinhardt wrote:
> 
>> Only metadata streams (stream type 0x15) are packed
>> in Metadata AU cells, so it should only be stripped
>> from them and not from all KLV streams.
>>
>> Fixes ticket #10828, a regression since
>> 468615f2045da325e0f73e8e668d49cf456ccb37.
> 
> I sent a patch for this yesterday:
> 
> https://ffmpeg.org/pipermail/ffmpeg-devel/2024-March/322432.html
> 

Sorry.
(Your commit message should mention that this is a regression caused by
468615f2045da325e0f73e8e668d49cf456ccb37.)

- Andreas

___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: Restrict skipping Metadata AU cells to metadata streams

2024-03-01 Thread Marton Balint





On Fri, 1 Mar 2024, Andreas Rheinhardt wrote:


Only metadata streams (stream type 0x15) are packed
in Metadata AU cells, so it should only be stripped
from them and not from all KLV streams.

Fixes ticket #10828, a regression since
468615f2045da325e0f73e8e668d49cf456ccb37.


I sent a patch for this yesterday:

https://ffmpeg.org/pipermail/ffmpeg-devel/2024-March/322432.html

Regards,
Marton
___
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.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/mpegts: Restrict skipping Metadata AU cells to metadata streams

2024-03-01 Thread Andreas Rheinhardt

Only metadata streams (stream type 0x15) are packed
in Metadata AU cells, so it should only be stripped
from them and not from all KLV streams.

Fixes ticket #10828, a regression since
468615f2045da325e0f73e8e668d49cf456ccb37.

Signed-off-by: Andreas Rheinhardt 
---
I really don't know mpegts; the above information is based
around reading ITU-T H.222.0 for about half an hour.

 libavformat/mpegts.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 836d5dd5a3..7c40e52262 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -1307,7 +1307,8 @@ skip:
 p += sl_header_bytes;
 buf_size -= sl_header_bytes;
 }
-if (pes->st->codecpar->codec_id == AV_CODEC_ID_SMPTE_KLV && 
buf_size >= 5) {
+if (pes->st->codecpar->codec_id == AV_CODEC_ID_SMPTE_KLV &&
+pes->stream_type == 0x15 && buf_size >= 5) {
 /* skip metadata access unit header */
 pes->pes_header_size += 5;
 p += 5;
-- 
2.40.1

___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v7 07/14] avutil/frame: add helper for adding side data w/ AVBufferRef to array

2024-03-01 Thread James Almer


On 3/1/2024 3:19 PM, Anton Khirnov wrote:

Quoting Jan Ekström (2024-02-29 17:42:54)

diff --git a/libavutil/frame.h b/libavutil/frame.h
index 47d0096bc4..908fd4a90d 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -1081,6 +1081,26 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData 
***sd, int *nb_sd,
  enum AVFrameSideDataType type,
  size_t size, unsigned int flags);
  
+/**

+ * Add a new side data entry to a set from an existing AVBufferRef.
+ *
+ * @param sdpointer to array of side data to which to add another entry.
+ * @param nb_sd pointer to an integer containing the number of entries in
+ *  the array.
+ * @param type  type of the added side data
+ * @param buf   AVBufferRef for which a new reference will be made


This seems inconsistent with av_frame_new_side_data_from_buf(), which
takes ownership of the buffer reference passed to it.
Is there a strong reason to do it differently here?


I asked for it. Taking ownership of the AVBufferRef and then expecting 
the caller to discard the pointer to it is awkward, and unlike any other 
function using AVBufferRef we have in the tree.


The alternative, to keep the behavior of taking ownership of the passed 
on reference, is to have this function take a pointer to pointer, and 
clearing it on success.

___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio

2024-03-01 Thread Anton Khirnov

Quoting Lynne (2024-03-01 20:41:53)
> Mar 1, 2024, 19:59 by an...@khirnov.net:
> 
> > Quoting Lynne (2024-02-29 14:30:55)
> >
> >> We offer support for it. Someone must have used it.
> >> I'm sure there are less used game codecs we support than Sonic.
> >>
> >
> > [citation needed]
> >
> > Is there any evidence that it was used for anything other than
> > development and testing? That anyone has any actual samples in it they'd
> > like to play?
> >
> 
> There's always the possibility that someone encoded samples years
> ago and deleted the originals. Same as with Snow.
> 
> My only concern is that this sets a sensitive precedent to get rid of
> old codec code with low weight under unclear conditions. Where do
> we draw the line?
> SMPTE? ISO/IEC standardization? IETF? AOM?
> Having *a* spec (Sonic doesn't, but neither did FFv1 until a few years
> ago)?
> A single company pushing for it many years ago with no spec,
> like SpeedHQ, or the many niche lossless/intra-only codecs?
> 
> Or simply having one single implementation in FFmpeg, and no spec at all,
> and having an experimental flag, and no activity for a very long amount of 
> time?

I'd draw the line somewhere around what I said above - some evidence
that it was used "seriously".

> If it's the last case, or simply being a one-off, I can agree with deprecating
> and remove it next bump. But if the developer thinks they will have time and
> have motivation to work on it in the future, I think we should leave it at 
> just
> deprecation plus disabling  building the encoder by default, until the issue 
> is
> brought up again at say, after the next version bump.
> After all, CELT started out more than 10 years before Opus was standardized,
> and its EC code has made it all the way to AV2 despite its core remaining
> visibly similar over the years. And FFv1 was used as an inspiration for FLIC,
> which went on to become JPEG-XL.

Sure, but there was active interest in all of these. I see no active
interest in Sonic.

-- 
Anton Khirnov
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio

2024-03-01 Thread Tomas Härdin

ons 2024-02-28 klockan 13:56 +0100 skrev J. Dekker:
> This was an experimental/research codec of which ffmpeg is the only
> encoder and decoder, development has stalled and these files don't
> exist
> in the wild.
> 
> Signed-off-by: J. Dekker 
> ---
>  Changelog   |    1 +
>  configure   |    3 -
>  libavcodec/Makefile |    3 -
>  libavcodec/allcodecs.c  |    3 -
>  libavcodec/codec_desc.c |   14 -
>  libavcodec/sonic.c  | 1125 -
> --
>  6 files changed, 1 insertion(+), 1148 deletions(-)
>  delete mode 100644 libavcodec/sonic.c

+1, modulo some technical points like not removing CodeIDs

/Tomas
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio

2024-03-01 Thread Lynne

Mar 1, 2024, 19:59 by an...@khirnov.net:

> Quoting Lynne (2024-02-29 14:30:55)
>
>> We offer support for it. Someone must have used it.
>> I'm sure there are less used game codecs we support than Sonic.
>>
>
> [citation needed]
>
> Is there any evidence that it was used for anything other than
> development and testing? That anyone has any actual samples in it they'd
> like to play?
>

There's always the possibility that someone encoded samples years
ago and deleted the originals. Same as with Snow.

My only concern is that this sets a sensitive precedent to get rid of
old codec code with low weight under unclear conditions. Where do
we draw the line?
SMPTE? ISO/IEC standardization? IETF? AOM?
Having *a* spec (Sonic doesn't, but neither did FFv1 until a few years
ago)?
A single company pushing for it many years ago with no spec,
like SpeedHQ, or the many niche lossless/intra-only codecs?

Or simply having one single implementation in FFmpeg, and no spec at all,
and having an experimental flag, and no activity for a very long amount of time?

If it's the last case, or simply being a one-off, I can agree with deprecating
and remove it next bump. But if the developer thinks they will have time and
have motivation to work on it in the future, I think we should leave it at just
deprecation plus disabling  building the encoder by default, until the issue is
brought up again at say, after the next version bump.
After all, CELT started out more than 10 years before Opus was standardized,
and its EC code has made it all the way to AV2 despite its core remaining
visibly similar over the years. And FFv1 was used as an inspiration for FLIC,
which went on to become JPEG-XL.
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio

2024-03-01 Thread Nicolas George

Anton Khirnov (12024-03-01):
> Is there any evidence that it was used for anything other than
> development and testing? That anyone has any actual samples in it they'd
> like to play?

Wrong question. The burden of proof is on whoever wants to remove, not
on the status quo.

And good luck proving nobody in the whole world ever chose to try this
codec and kept the file. Maybe they are not even subscribed to this list
right now. I know, shocking!

-- 
  Nicolas George
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio

2024-03-01 Thread Anton Khirnov

Quoting Lynne (2024-02-29 14:30:55)
> We offer support for it. Someone must have used it.
> I'm sure there are less used game codecs we support than Sonic.

[citation needed]

Is there any evidence that it was used for anything other than
development and testing? That anyone has any actual samples in it they'd
like to play?

-- 
Anton Khirnov
___
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.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] fftools/ffplay: stop printing non-public AVCodecContext fields

2024-03-01 Thread Anton Khirnov

They are documented as not intended for caller use.
---
 fftools/ffplay.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 5b54fab492..09b4846deb 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -1731,16 +1731,14 @@ display:
 
 av_bprint_init(, 0, AV_BPRINT_SIZE_AUTOMATIC);
 av_bprintf(,
-  "%7.2f %s:%7.3f fd=%4d aq=%5dKB vq=%5dKB sq=%5dB 
f=%"PRId64"/%"PRId64"   \r",
+  "%7.2f %s:%7.3f fd=%4d aq=%5dKB vq=%5dKB sq=%5dB \r",
   get_master_clock(is),
   (is->audio_st && is->video_st) ? "A-V" : (is->video_st ? 
"M-V" : (is->audio_st ? "M-A" : "   ")),
   av_diff,
   is->frame_drops_early + is->frame_drops_late,
   aqsize / 1024,
   vqsize / 1024,
-  sqsize,
-  is->video_st ? 
is->viddec.avctx->pts_correction_num_faulty_dts : 0,
-  is->video_st ? 
is->viddec.avctx->pts_correction_num_faulty_pts : 0);
+  sqsize);
 
 if (show_status == 1 && AV_LOG_INFO > av_log_get_level())
 fprintf(stderr, "%s", buf.str);
-- 
2.43.0

___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v7 10/14] avcodec: add helper for configuring AVCodecContext's frame side data

2024-03-01 Thread Anton Khirnov

Quoting Jan Ekström (2024-02-29 17:42:57)
> +/**
> + * Add multiple side data entries to an AVCodecContext set in one go, for
> + * example from an AVFrame.
> + *
> + * In case the function fails to add a side data entry, it will clear the
> + * whole side data set.
> + *
> + * @param avctx context to which the side data should be added
> + * @param sdarray of side data to use as input.
> + *  if null, clears out the side data for this context.
> + * @param nb_sd integer containing the number of entries in the array.
> + * @param flags Some combination of AV_FRAME_SIDE_DATA_SET_FLAG_* flags, or 
> 0.
> + *
> + * @return negative error code on failure, >=0 on success.
> + *
> + * @see av_frame_side_data_set_new_entry regarding the flags.
> + */
> +int avcodec_configure_side_data(AVCodecContext *avctx,
> +const AVFrameSideData **sd, const int nb_sd,
> +unsigned int flags);

Why should this be tied to avcodec and not just
av_frame_side_data_copy()?

-- 
Anton Khirnov
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v7 09/14] avcodec: add frame side data array to AVCodecContext

2024-03-01 Thread Anton Khirnov

Quoting Jan Ekström (2024-02-29 17:42:56)
> This allows configuring an encoder by using AVFrameSideData.
> ---
>  libavcodec/avcodec.h | 8 
>  libavcodec/options.c | 2 ++
>  2 files changed, 10 insertions(+)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 43859251cc..411f4caad3 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2120,6 +2120,14 @@ typedef struct AVCodecContext {
>   *   an error.
>   */
>  int64_t frame_num;
> +
> +/**
> + * Set containing static side data, such as HDR10 CLL / MDCV structures.
> + * - encoding: set by user

May be set by the caller before avcodec_open2(). Afterwards owned and
freed by the encoder.

> + * - decoding: unused
> + */
> +AVFrameSideData  **frame_side_data;
> +int nb_frame_side_data;

I don't like calling the field 'frame' side data, because it is not
associated with any frame.

I'd prefer to call it 'decoded_side_data' or 'raw_side_data', to be
consistent with existing 'coded_side_data'.

-- 
Anton Khirnov
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v7 07/14] avutil/frame: add helper for adding side data w/ AVBufferRef to array

2024-03-01 Thread Anton Khirnov

Quoting Jan Ekström (2024-02-29 17:42:54)
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 47d0096bc4..908fd4a90d 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -1081,6 +1081,26 @@ AVFrameSideData 
> *av_frame_side_data_new(AVFrameSideData ***sd, int *nb_sd,
>  enum AVFrameSideDataType type,
>  size_t size, unsigned int flags);
>  
> +/**
> + * Add a new side data entry to a set from an existing AVBufferRef.
> + *
> + * @param sdpointer to array of side data to which to add another entry.
> + * @param nb_sd pointer to an integer containing the number of entries in
> + *  the array.
> + * @param type  type of the added side data
> + * @param buf   AVBufferRef for which a new reference will be made

This seems inconsistent with av_frame_new_side_data_from_buf(), which
takes ownership of the buffer reference passed to it.
Is there a strong reason to do it differently here?

-- 
Anton Khirnov
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v7 06/14] avutil/frame: add helper for adding existing side data to array

2024-03-01 Thread Anton Khirnov

Quoting Jan Ekström (2024-02-29 17:42:53)
> @@ -872,6 +889,38 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData 
> ***sd, int *nb_sd,
>  return ret;
>  }
>  
> +int av_frame_side_data_from_sd(AVFrameSideData ***sd, int *nb_sd,
> +   const AVFrameSideData *src,
> +   unsigned int flags)
> +{
> +if (!sd || !src || !nb_sd || (*nb_sd && !*sd))
> +return AVERROR(EINVAL);

Overzealous checking is evil. This should be removed, or made into an
assert.

> +
> +{

These extra blocks are ugly.

> +AVBufferRef   *buf= av_buffer_ref(src->buf);
> +AVFrameSideData   *sd_dst = NULL;
> +
> +if (flags & AV_FRAME_SIDE_DATA_SET_FLAG_NO_DUPLICATES)
> +remove_side_data(sd, nb_sd, src->type);
> +
> +sd_dst = add_side_data_to_set_from_buf(sd, nb_sd, src->type, buf);
> +if (!sd_dst) {
> +av_buffer_unref();
> +return AVERROR(ENOMEM);
> +}
> +
> +{
> +int ret = av_dict_copy(_dst->metadata, src->metadata, 0);
> +if (ret < 0) {
> +remove_side_data_by_entry(sd, nb_sd, sd_dst);

Removing by the pointer is ugly. You could either
* assume add_side_data_to_set_from_buf() adds to the end and remove the
  last element
* have add_side_data_to_set_from_buf() return the index of the added
  element

> +return ret;
> +}
> +}
> +
> +return 0;
> +}
> +}
> +
>  AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
>  enum AVFrameSideDataType type)
>  {
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 726ca19a03..47d0096bc4 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -1081,6 +1081,25 @@ AVFrameSideData 
> *av_frame_side_data_new(AVFrameSideData ***sd, int *nb_sd,
>  enum AVFrameSideDataType type,
>  size_t size, unsigned int flags);
>  
> +/**
> + * Add a new side data entry to a set based on existing side data, taking
> + * a reference towards the contained AVBufferRef.
> + *
> + * @param sdpointer to array of side data to which to add another entry.
> + * @param nb_sd pointer to an integer containing the number of entries in
> + *  the array.
> + * @param src   side data which should be added to the set
> + * @param flags Some combination of AV_FRAME_SIDE_DATA_SET_FLAG_* flags, or 
> 0.
> + *
> + * @return negative error code on failure, >=0 on success. In case of
> + * AV_FRAME_SIDE_DATA_SET_FLAG_NO_DUPLICATES being set, entries
> + * of matching AVFrameSideDataType will be removed before the
> + * addition is attempted.
> + */
> +int av_frame_side_data_from_sd(AVFrameSideData ***sd, int *nb_sd,

av_frame_side_data_clone()?
av_frame_side_data_ref()?

-- 
Anton Khirnov
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v7 05/14] avutil/frame: add helper for adding side data to array

2024-03-01 Thread Anton Khirnov

Quoting Jan Ekström (2024-02-29 17:42:52)
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 921f2212cf..726ca19a03 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -1060,6 +1060,27 @@ const char *av_frame_side_data_name(enum 
> AVFrameSideDataType type);
>   */
>  void av_frame_side_data_free(AVFrameSideData ***sd, int *nb_sd);
>  
> +#define AV_FRAME_SIDE_DATA_SET_FLAG_NO_DUPLICATES (1 << 0)

Long name is long, also obsolete reference to sets.

AV_FRAME_SIDE_DATA_FLAG_UNIQUE?

-- 
Anton Khirnov
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule

2024-03-01 Thread Anton Khirnov

Hi all,
it seems the discussion died down, so I intend to start the vote on
Monday (2024-03-04).

The vote description will be as follows:

  There is disagreement about the appropriateness and interpretation of
  the following sentence in Technical Committee rules
  (doc/community.texi):

> If the disagreement involves a member of the TC, that member
> should recuse themselves from the decision.

  (see thread starting from [1] for more details)

  How should this sentence be changed? Rank the options below in your
  order of preference.

  [1] https://lists.ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321792.html
  Message-Id <170841737762.27417.14992162535824834...@lain.khirnov.net>

The options I see proposed so far are:

* 

* 

* Each TC member must vote on such decision according to what is, in
  their view, best for the project. If a TC member feels they are
  affected by a conflict of interest with regards to the case, they
  should announce it and recuse themselves from the TC discussion and
  vote. A conflict of interest is presumed to occur when a TC member has
  a personal interest (e.g. financial) in a specific outcome of the
  case.

* Any member of the TC who had a strong opinion on the question raised
  before it was raised should recuse themselves.

  In particular, must recuse themselves any member of the TC who:
  - participated in the discussion (on the ML, on IRC or elsewhere) in a
specific direction (minor comments and questions being acceptable);
  - has a personal interest in the outcome;
  - is, was recently or soon will be employed by an entity having a
personal interest in the outcome or has any kind of hierarchical
relationship with such entity.
  Failure to do so would result, upon discovery, into the exclusion of
  all FFmpeg governance bodies, including the general assembly, for a
  duration of no less than five years.

  Additionally, any member of the general assembly can recuse any member
  of the TC without having to provide a reason.

  If the application of these rules result in all members of the TC
  recused or if the remaining members do not feel comfortable being too
  few, that means the project is in a crisis of trust that needs to be
  resolved by the general assembly.

If you wish to propose another option (or I missed one in this thread),
please let me know ASAP.

Cheers,
-- 
Anton Khirnov
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] clarifying the TC conflict of interest rule

2024-03-01 Thread Anton Khirnov

Quoting Michael Niedermayer (2024-02-27 17:55:30)
> On Tue, Feb 27, 2024 at 08:20:30AM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-02-26 23:47:20)
> > > 
> > > Look at the 3 patches i just posted.
> > > I suspect we can move alot closer to what you suggest without a vote but
> > > simply by consensus
> > 
> > Your patches use a 'must' wording,
> 
> Then please reply to them and explain your point, why the wording
> is bad, what alternative wording you suggest and why thats better.
> Its a patch, we discuss patches here on ffmpeg-devel

Hijacking other people's patches without their consent is what we do NOT
do though.

> > while multiple people would prefer a
> > 'should'.
> >
> 
> > But even more importantly, you are leaving the disputed line as is, so
> > it's not solving the problem at all.
> 
> The questions about
> 1. allowing votes under conflict of interrest
> 2. if votes must be in the best interrest of the project
> 3. if one can vote on their own disagreements
> ...
> 
> are 3+ seperate things.
> 
> You are trying to pack good changes with a change that allows one to
> vote on ones own disagreements.

And you are trying to pass your personal opinions on which changes are
good (and by implication which are not-good) as objective facts. I wish
you'd stop doing that. I presented an argument for why *in my opinion*
there is no problem with TC members voting on their own patches. You are
welcome to disagree, but that is exactly why I am proposing a vote.

-- 
Anton Khirnov
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v7 09/14] avcodec: add frame side data array to AVCodecContext

2024-03-01 Thread James Almer


On 3/1/2024 1:03 PM, James Almer wrote:

On 2/29/2024 1:42 PM, Jan Ekström wrote:

This allows configuring an encoder by using AVFrameSideData.


Maybe mention that in the doxy for the field. Explain that it needs to 
be set before avcodec_open2() and is used to initialize an encoder.


And that it must be allocated with av_frame_side_data_new(), 
av_frame_side_data_from_sd() or av_frame_side_data_from_buf().





---
  libavcodec/avcodec.h | 8 
  libavcodec/options.c | 2 ++
  2 files changed, 10 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 43859251cc..411f4caad3 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2120,6 +2120,14 @@ typedef struct AVCodecContext {
   *   an error.
   */
  int64_t frame_num;
+
+    /**
+ * Set containing static side data, such as HDR10 CLL / MDCV 
structures.

+ * - encoding: set by user
+ * - decoding: unused
+ */
+    AVFrameSideData  **frame_side_data;
+    int nb_frame_side_data;
  } AVCodecContext;
  /**
diff --git a/libavcodec/options.c b/libavcodec/options.c
index 928e430ce9..7e39b49b7e 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -181,6 +181,8 @@ void avcodec_free_context(AVCodecContext **pavctx)
  av_freep(>inter_matrix);
  av_freep(>rc_override);
  av_channel_layout_uninit(>ch_layout);
+    av_frame_side_data_free(
+    >frame_side_data, >nb_frame_side_data);
  av_freep(pavctx);
  }

___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v7 05/14] avutil/frame: add helper for adding side data to array

2024-03-01 Thread James Almer


On 2/29/2024 1:42 PM, Jan Ekström wrote:

diff --git a/libavutil/frame.h b/libavutil/frame.h
index 921f2212cf..726ca19a03 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -1060,6 +1060,27 @@ const char *av_frame_side_data_name(enum 
AVFrameSideDataType type);
   */
  void av_frame_side_data_free(AVFrameSideData ***sd, int *nb_sd);
  
+#define AV_FRAME_SIDE_DATA_SET_FLAG_NO_DUPLICATES (1 << 0)

+
+/**
+ * Add a new side data entry to a set.
+ *
+ * @param sdpointer to array of side data to which to add another entry.


Or to NULL, to start a new array.


+ * @param nb_sd pointer to an integer containing the number of entries in
+ *  the array.
+ * @param type  type of the added side data
+ * @param size  size of the side data
+ * @param flags Some combination of AV_FRAME_SIDE_DATA_SET_FLAG_* flags, or 0.
+ *
+ * @return newly added side data on success, NULL on error. In case of
+ * AV_FRAME_SIDE_DATA_SET_FLAG_NO_DUPLICATES being set, entries
+ * of matching AVFrameSideDataType will be removed before the
+ * addition is attempted.
+ */
+AVFrameSideData *av_frame_side_data_new(AVFrameSideData ***sd, int *nb_sd,
+enum AVFrameSideDataType type,
+size_t size, unsigned int flags);
+
  /**
   * @}
   */

___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 14/38] lavu/opt: factor per-type dispatch out of av_opt_set()

2024-03-01 Thread Anton Khirnov

Quoting Michael Niedermayer (2024-02-23 23:50:10)
> Hi Anton
> 
> On Fri, Feb 23, 2024 at 02:58:36PM +0100, Anton Khirnov wrote:
> > Will be useful in following commits.
> > ---
> 
> breaks:
> 
> ./ffmpeg -y -request_channel_layout 3 -i 
> bug/401/mlp_5point1_downmixof6channel.mlp -bitexact 
> file-2-mlp_5point1_downmixof6channel.wav
> 
> [mlp @ 0x55690e23ff80] Error setting option request_channel_layout to value 3.
> [mlp @ 0x55690e23ed00] Failed to open codec in avformat_find_stream_info
> [mlp @ 0x55690e23ff80] Error setting option request_channel_layout to value 3.
> Input #0, mlp, from 'bug/401/mlp_5point1_downmixof6channel.mlp':
>   Duration: N/A, start: 0.00, bitrate: N/A
>   Stream #0:0: Audio: mlp, 48000 Hz, 5.1, s32 (24 bit)
> [mlp @ 0x55690e257900] Error setting option request_channel_layout to value 3.
> [aist#0:0/mlp @ 0x55690e254dc0] [dec:mlp @ 0x55690e256f40] Error while 
> opening decoder: Invalid argument
> [aost#0:0/pcm_s16le @ 0x55690e255a80] Error initializing a simple filtergraph
> Error opening output file file-2-mlp_5point1_downmixof6channel.wav.
> Error opening output files: Invalid argument
> 
> i suspect this isnt specific to the file but i can provide it if it
> doesnt reproduce with a other file

Cannot reproduce with another mlp or 5.1 ac3 file.

-- 
Anton Khirnov
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v7 09/14] avcodec: add frame side data array to AVCodecContext

2024-03-01 Thread James Almer


On 2/29/2024 1:42 PM, Jan Ekström wrote:

This allows configuring an encoder by using AVFrameSideData.


Maybe mention that in the doxy for the field. Explain that it needs to 
be set before avcodec_open2() and is used to initialize an encoder.



---
  libavcodec/avcodec.h | 8 
  libavcodec/options.c | 2 ++
  2 files changed, 10 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 43859251cc..411f4caad3 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2120,6 +2120,14 @@ typedef struct AVCodecContext {
   *   an error.
   */
  int64_t frame_num;
+
+/**
+ * Set containing static side data, such as HDR10 CLL / MDCV structures.
+ * - encoding: set by user
+ * - decoding: unused
+ */
+AVFrameSideData  **frame_side_data;
+int nb_frame_side_data;
  } AVCodecContext;
  
  /**

diff --git a/libavcodec/options.c b/libavcodec/options.c
index 928e430ce9..7e39b49b7e 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -181,6 +181,8 @@ void avcodec_free_context(AVCodecContext **pavctx)
  av_freep(>inter_matrix);
  av_freep(>rc_override);
  av_channel_layout_uninit(>ch_layout);
+av_frame_side_data_free(
+>frame_side_data, >nb_frame_side_data);
  
  av_freep(pavctx);

  }

___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/decode: give packet side data priority over global

2024-03-01 Thread James Almer


On 3/1/2024 12:29 PM, Anton Khirnov wrote:

Quoting James Almer (2024-03-01 13:37:43)

Restores the behavior prior to ae22271620df90567ba276832b33607d64e9ba9c, where
global side data would be inserted first to the output frame, resulting in both
two entries for the same type and having priority when fetched by the AVFrame
helpers.

This is a temporary fix for ticket #10857 until a proper method to select the
source for side data is implemented.


Does it actually fix the ticket? I think
ff_decode_frame_props_from_pkt() is called before the decoder adds
bitstream side data to the frame.


Oh, bitstream side data. I was thinking about packet side data (so also 
coming from lavf). Right, this would not work then, so patch dropped.

___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/bsf/mp3_header_decompress: Remove BSF

2024-03-01 Thread Anton Khirnov

Quoting Andreas Rheinhardt (2024-03-01 12:34:27)
> Will apply tomorrow unless there are objections.

Looks very good to me.

-- 
Anton Khirnov
___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/decode: give packet side data priority over global

2024-03-01 Thread Anton Khirnov

Quoting James Almer (2024-03-01 13:37:43)
> Restores the behavior prior to ae22271620df90567ba276832b33607d64e9ba9c, where
> global side data would be inserted first to the output frame, resulting in 
> both
> two entries for the same type and having priority when fetched by the AVFrame
> helpers.
> 
> This is a temporary fix for ticket #10857 until a proper method to select the
> source for side data is implemented.

Does it actually fix the ticket? I think
ff_decode_frame_props_from_pkt() is called before the decoder adds
bitstream side data to the frame.

-- 
Anton Khirnov
___
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.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avfilter: update filter timeline state only on main link

2024-03-01 Thread Gyan Doshi

At present, consume_update evaluates timeline state on all links for
a multi-input filter. This can lead to the filter being incorrectly
en/dis-abled when evaluation on a frame on a secondary link leads to
a different result than the frame on the current main link next in
line for processing.
---
 libavfilter/avfilter.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index daa7c3672a..d7ea993508 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -1430,7 +1430,8 @@ static void consume_update(FilterLinkInternal *li, const 
AVFrame *frame)
 AVFilterLink *const link = >l;
 update_link_current_pts(li, frame->pts);
 ff_inlink_process_commands(link, frame);
-link->dst->is_disabled = !ff_inlink_evaluate_timeline_at_frame(link, 
frame);
+if (link == link->dst->inputs[0])
+link->dst->is_disabled = !ff_inlink_evaluate_timeline_at_frame(link, 
frame);
 link->frame_count_out++;
 link->sample_count_out += frame->nb_samples;
 }
-- 
2.44.0

___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 5/5] lavf/demux: duplicate side_data in parse_packet()

2024-03-01 Thread James Almer


On 3/1/2024 10:49 AM, James Almer wrote:

On 3/1/2024 10:39 AM, Nicolas Gaullier wrote:

Signed-off-by: Nicolas Gaullier 
---
  libavformat/demux.c   |  23 ++-
  tests/ref/fate/concat-demuxer-simple2-lavf-ts | 164 +-
  tests/ref/fate/ts-demux   |   8 +-
  3 files changed, 104 insertions(+), 91 deletions(-)

diff --git a/libavformat/demux.c b/libavformat/demux.c
index 2e1d0ed66d..722bb35c4c 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -1186,7 +1186,7 @@ static int parse_packet(AVFormatContext *s, 
AVPacket *pkt,

  FFStream *const sti = ffstream(st);
  const uint8_t *data = pkt->data;
  int size = pkt->size;
-    int ret = 0, got_output = flush;
+    int ret = 0, got_output = flush, pkt_side_data_consumed = 0;
  if (!size && !flush && sti->parser->flags & 
PARSER_FLAG_COMPLETE_FRAMES) {

  // preserve 0-size sync packets
@@ -1231,10 +1231,19 @@ static int parse_packet(AVFormatContext *s, 
AVPacket *pkt,

  }
  if (pkt->side_data) {
-    out_pkt->side_data   = pkt->side_data;
-    out_pkt->side_data_elems = pkt->side_data_elems;
-    pkt->side_data  = NULL;
-    pkt->side_data_elems    = 0;
+    if (!pkt_side_data_consumed) {


Can't you just check for out_pkt->side_data instead?


Nevermind, i misread the code.

Please add a comment about how pkt_side_data_consumed prevents copying 
side data for the first (and potentially only) output iteration.





+    out_pkt->side_data   = pkt->side_data;
+    out_pkt->side_data_elems = pkt->side_data_elems;
+    pkt_side_data_consumed = 1;
+    } else for (int i = 0; i < pkt->side_data_elems; i++) {
+    const AVPacketSideData *const src_sd = 
>side_data[i];
+    uint8_t *dst_data = av_packet_new_side_data(out_pkt, 
src_sd->type, src_sd->size);

+    if (!dst_data) {
+    ret = AVERROR(ENOMEM);
+    goto fail;
+    }
+    memcpy(dst_data, src_sd->data, src_sd->size);
+    }
  }
  /* set the duration */
@@ -1286,6 +1295,10 @@ static int parse_packet(AVFormatContext *s, 
AVPacket *pkt,

  }
  fail:
+    if (pkt_side_data_consumed) {
+    pkt->side_data  = NULL;
+    pkt->side_data_elems    = 0;
+    }
  if (ret < 0)
  av_packet_unref(out_pkt);
  av_packet_unref(pkt);
diff --git a/tests/ref/fate/concat-demuxer-simple2-lavf-ts 
b/tests/ref/fate/concat-demuxer-simple2-lavf-ts

index 548cab01c6..ee49e331f3 100644
--- a/tests/ref/fate/concat-demuxer-simple2-lavf-ts
+++ b/tests/ref/fate/concat-demuxer-simple2-lavf-ts
@@ -7,19 +7,19 @@ 
video|1|18982|0.210911|15382|0.170911|3600|0.04|13092|84788|___|MPEGTS Strea
  
video|1|22582|0.250911|18982|0.210911|3600|0.04|12755|98700|___|MPEGTS Stream ID|224
  
video|1|26182|0.290911|22582|0.250911|3600|0.04|12023|111860|___|MPEGTS Stream ID|224
  audio|0|0|0.00|0|0.00|2351|0.026122|208|152844|K__|MPEGTS 
Stream ID|192

-audio|0|2351|0.026122|2351|0.026122|2351|0.026122|209|N/A|K__
-audio|0|4702|0.052244|4702|0.052244|2351|0.026122|209|N/A|K__
-audio|0|7053|0.078367|7053|0.078367|2351|0.026122|209|N/A|K__
-audio|0|9404|0.104489|9404|0.104489|2351|0.026122|209|N/A|K__
-audio|0|11755|0.130611|11755|0.130611|2351|0.026122|209|N/A|K__
-audio|0|14106|0.156733|14106|0.156733|2351|0.026122|209|N/A|K__
-audio|0|16457|0.182856|16457|0.182856|2351|0.026122|209|N/A|K__
-audio|0|18808|0.208978|18808|0.208978|2351|0.026122|209|N/A|K__
-audio|0|21159|0.235100|21159|0.235100|2351|0.026122|209|N/A|K__
-audio|0|23510|0.261222|23510|0.261222|2351|0.026122|209|N/A|K__
-audio|0|25861|0.287344|25861|0.287344|2351|0.026122|209|N/A|K__
-audio|0|28212|0.313467|28212|0.313467|2351|0.026122|209|N/A|K__
-audio|0|30563|0.339589|30563|0.339589|2351|0.026122|209|N/A|K__
+audio|0|2351|0.026122|2351|0.026122|2351|0.026122|209|N/A|K__|MPEGTS 
Stream ID|192
+audio|0|4702|0.052244|4702|0.052244|2351|0.026122|209|N/A|K__|MPEGTS 
Stream ID|192
+audio|0|7053|0.078367|7053|0.078367|2351|0.026122|209|N/A|K__|MPEGTS 
Stream ID|192
+audio|0|9404|0.104489|9404|0.104489|2351|0.026122|209|N/A|K__|MPEGTS 
Stream ID|192

+audio|0|11755|0.130611|11755|0.130611|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|14106|0.156733|14106|0.156733|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|16457|0.182856|16457|0.182856|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|18808|0.208978|18808|0.208978|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|21159|0.235100|21159|0.235100|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|23510|0.261222|23510|0.261222|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|25861|0.287344|25861|0.287344|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|28212|0.313467|28212|0.313467|2351|0.026122|209|N/A|K__|MPEGTS Stream

Re: [FFmpeg-devel] [PATCH v2 5/5] lavf/demux: duplicate side_data in parse_packet()

2024-03-01 Thread James Almer


On 3/1/2024 10:39 AM, Nicolas Gaullier wrote:

Signed-off-by: Nicolas Gaullier 
---
  libavformat/demux.c   |  23 ++-
  tests/ref/fate/concat-demuxer-simple2-lavf-ts | 164 +-
  tests/ref/fate/ts-demux   |   8 +-
  3 files changed, 104 insertions(+), 91 deletions(-)

diff --git a/libavformat/demux.c b/libavformat/demux.c
index 2e1d0ed66d..722bb35c4c 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -1186,7 +1186,7 @@ static int parse_packet(AVFormatContext *s, AVPacket *pkt,
  FFStream *const sti = ffstream(st);
  const uint8_t *data = pkt->data;
  int size = pkt->size;
-int ret = 0, got_output = flush;
+int ret = 0, got_output = flush, pkt_side_data_consumed = 0;
  
  if (!size && !flush && sti->parser->flags & PARSER_FLAG_COMPLETE_FRAMES) {

  // preserve 0-size sync packets
@@ -1231,10 +1231,19 @@ static int parse_packet(AVFormatContext *s, AVPacket 
*pkt,
  }
  
  if (pkt->side_data) {

-out_pkt->side_data   = pkt->side_data;
-out_pkt->side_data_elems = pkt->side_data_elems;
-pkt->side_data  = NULL;
-pkt->side_data_elems= 0;
+if (!pkt_side_data_consumed) {


Can't you just check for out_pkt->side_data instead?


+out_pkt->side_data   = pkt->side_data;
+out_pkt->side_data_elems = pkt->side_data_elems;
+pkt_side_data_consumed = 1;
+} else for (int i = 0; i < pkt->side_data_elems; i++) {
+const AVPacketSideData *const src_sd = >side_data[i];
+uint8_t *dst_data = av_packet_new_side_data(out_pkt, 
src_sd->type, src_sd->size);
+if (!dst_data) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+memcpy(dst_data, src_sd->data, src_sd->size);
+}
  }
  
  /* set the duration */

@@ -1286,6 +1295,10 @@ static int parse_packet(AVFormatContext *s, AVPacket 
*pkt,
  }
  
  fail:

+if (pkt_side_data_consumed) {
+pkt->side_data  = NULL;
+pkt->side_data_elems= 0;
+}
  if (ret < 0)
  av_packet_unref(out_pkt);
  av_packet_unref(pkt);
diff --git a/tests/ref/fate/concat-demuxer-simple2-lavf-ts 
b/tests/ref/fate/concat-demuxer-simple2-lavf-ts
index 548cab01c6..ee49e331f3 100644
--- a/tests/ref/fate/concat-demuxer-simple2-lavf-ts
+++ b/tests/ref/fate/concat-demuxer-simple2-lavf-ts
@@ -7,19 +7,19 @@ 
video|1|18982|0.210911|15382|0.170911|3600|0.04|13092|84788|___|MPEGTS Strea
  video|1|22582|0.250911|18982|0.210911|3600|0.04|12755|98700|___|MPEGTS 
Stream ID|224
  video|1|26182|0.290911|22582|0.250911|3600|0.04|12023|111860|___|MPEGTS 
Stream ID|224
  audio|0|0|0.00|0|0.00|2351|0.026122|208|152844|K__|MPEGTS Stream 
ID|192
-audio|0|2351|0.026122|2351|0.026122|2351|0.026122|209|N/A|K__
-audio|0|4702|0.052244|4702|0.052244|2351|0.026122|209|N/A|K__
-audio|0|7053|0.078367|7053|0.078367|2351|0.026122|209|N/A|K__
-audio|0|9404|0.104489|9404|0.104489|2351|0.026122|209|N/A|K__
-audio|0|11755|0.130611|11755|0.130611|2351|0.026122|209|N/A|K__
-audio|0|14106|0.156733|14106|0.156733|2351|0.026122|209|N/A|K__
-audio|0|16457|0.182856|16457|0.182856|2351|0.026122|209|N/A|K__
-audio|0|18808|0.208978|18808|0.208978|2351|0.026122|209|N/A|K__
-audio|0|21159|0.235100|21159|0.235100|2351|0.026122|209|N/A|K__
-audio|0|23510|0.261222|23510|0.261222|2351|0.026122|209|N/A|K__
-audio|0|25861|0.287344|25861|0.287344|2351|0.026122|209|N/A|K__
-audio|0|28212|0.313467|28212|0.313467|2351|0.026122|209|N/A|K__
-audio|0|30563|0.339589|30563|0.339589|2351|0.026122|209|N/A|K__
+audio|0|2351|0.026122|2351|0.026122|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|4702|0.052244|4702|0.052244|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|7053|0.078367|7053|0.078367|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|9404|0.104489|9404|0.104489|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|11755|0.130611|11755|0.130611|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|14106|0.156733|14106|0.156733|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|16457|0.182856|16457|0.182856|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|18808|0.208978|18808|0.208978|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|21159|0.235100|21159|0.235100|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|23510|0.261222|23510|0.261222|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|25861|0.287344|25861|0.287344|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|28212|0.313467|28212|0.313467|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|30563|0.339589|30563|0.339589|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
  video|1|29782|0.330911|26182|0.290911|3600|0.04|14098|124268|___|MPEGTS 
Stream ID|224

[FFmpeg-devel] [PATCH v2 5/5] lavf/demux: duplicate side_data in parse_packet()

2024-03-01 Thread Nicolas Gaullier

Signed-off-by: Nicolas Gaullier 
---
 libavformat/demux.c   |  23 ++-
 tests/ref/fate/concat-demuxer-simple2-lavf-ts | 164 +-
 tests/ref/fate/ts-demux   |   8 +-
 3 files changed, 104 insertions(+), 91 deletions(-)

diff --git a/libavformat/demux.c b/libavformat/demux.c
index 2e1d0ed66d..722bb35c4c 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -1186,7 +1186,7 @@ static int parse_packet(AVFormatContext *s, AVPacket *pkt,
 FFStream *const sti = ffstream(st);
 const uint8_t *data = pkt->data;
 int size = pkt->size;
-int ret = 0, got_output = flush;
+int ret = 0, got_output = flush, pkt_side_data_consumed = 0;
 
 if (!size && !flush && sti->parser->flags & PARSER_FLAG_COMPLETE_FRAMES) {
 // preserve 0-size sync packets
@@ -1231,10 +1231,19 @@ static int parse_packet(AVFormatContext *s, AVPacket 
*pkt,
 }
 
 if (pkt->side_data) {
-out_pkt->side_data   = pkt->side_data;
-out_pkt->side_data_elems = pkt->side_data_elems;
-pkt->side_data  = NULL;
-pkt->side_data_elems= 0;
+if (!pkt_side_data_consumed) {
+out_pkt->side_data   = pkt->side_data;
+out_pkt->side_data_elems = pkt->side_data_elems;
+pkt_side_data_consumed = 1;
+} else for (int i = 0; i < pkt->side_data_elems; i++) {
+const AVPacketSideData *const src_sd = >side_data[i];
+uint8_t *dst_data = av_packet_new_side_data(out_pkt, 
src_sd->type, src_sd->size);
+if (!dst_data) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+memcpy(dst_data, src_sd->data, src_sd->size);
+}
 }
 
 /* set the duration */
@@ -1286,6 +1295,10 @@ static int parse_packet(AVFormatContext *s, AVPacket 
*pkt,
 }
 
 fail:
+if (pkt_side_data_consumed) {
+pkt->side_data  = NULL;
+pkt->side_data_elems= 0;
+}
 if (ret < 0)
 av_packet_unref(out_pkt);
 av_packet_unref(pkt);
diff --git a/tests/ref/fate/concat-demuxer-simple2-lavf-ts 
b/tests/ref/fate/concat-demuxer-simple2-lavf-ts
index 548cab01c6..ee49e331f3 100644
--- a/tests/ref/fate/concat-demuxer-simple2-lavf-ts
+++ b/tests/ref/fate/concat-demuxer-simple2-lavf-ts
@@ -7,19 +7,19 @@ 
video|1|18982|0.210911|15382|0.170911|3600|0.04|13092|84788|___|MPEGTS Strea
 video|1|22582|0.250911|18982|0.210911|3600|0.04|12755|98700|___|MPEGTS 
Stream ID|224
 video|1|26182|0.290911|22582|0.250911|3600|0.04|12023|111860|___|MPEGTS 
Stream ID|224
 audio|0|0|0.00|0|0.00|2351|0.026122|208|152844|K__|MPEGTS Stream ID|192
-audio|0|2351|0.026122|2351|0.026122|2351|0.026122|209|N/A|K__
-audio|0|4702|0.052244|4702|0.052244|2351|0.026122|209|N/A|K__
-audio|0|7053|0.078367|7053|0.078367|2351|0.026122|209|N/A|K__
-audio|0|9404|0.104489|9404|0.104489|2351|0.026122|209|N/A|K__
-audio|0|11755|0.130611|11755|0.130611|2351|0.026122|209|N/A|K__
-audio|0|14106|0.156733|14106|0.156733|2351|0.026122|209|N/A|K__
-audio|0|16457|0.182856|16457|0.182856|2351|0.026122|209|N/A|K__
-audio|0|18808|0.208978|18808|0.208978|2351|0.026122|209|N/A|K__
-audio|0|21159|0.235100|21159|0.235100|2351|0.026122|209|N/A|K__
-audio|0|23510|0.261222|23510|0.261222|2351|0.026122|209|N/A|K__
-audio|0|25861|0.287344|25861|0.287344|2351|0.026122|209|N/A|K__
-audio|0|28212|0.313467|28212|0.313467|2351|0.026122|209|N/A|K__
-audio|0|30563|0.339589|30563|0.339589|2351|0.026122|209|N/A|K__
+audio|0|2351|0.026122|2351|0.026122|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|4702|0.052244|4702|0.052244|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|7053|0.078367|7053|0.078367|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|9404|0.104489|9404|0.104489|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|11755|0.130611|11755|0.130611|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|14106|0.156733|14106|0.156733|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|16457|0.182856|16457|0.182856|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|18808|0.208978|18808|0.208978|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|21159|0.235100|21159|0.235100|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|23510|0.261222|23510|0.261222|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|25861|0.287344|25861|0.287344|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|28212|0.313467|28212|0.313467|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
+audio|0|30563|0.339589|30563|0.339589|2351|0.026122|209|N/A|K__|MPEGTS Stream 
ID|192
 video|1|29782|0.330911|26182|0.290911|3600|0.04|14098|124268|___|MPEGTS 
Stream ID|224
 video|1|33382|0.370911|29782|0.330911|3600|0.04|13329|139120|___|MPEGTS 
Stream ID|224

[FFmpeg-devel] [PATCH v2 4/5] avcodec/h264_parser: fix start of packet for some broken streams

2024-03-01 Thread Nicolas Gaullier

Signed-off-by: Nicolas Gaullier 
---
 libavcodec/h264_parser.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 94cfbc481e..6b721ec253 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -124,7 +124,16 @@ static int h264_find_frame_end(H264ParseContext *p, const 
uint8_t *buf,
 if (nalu_type == H264_NAL_SEI || nalu_type == H264_NAL_SPS ||
 nalu_type == H264_NAL_PPS || nalu_type == H264_NAL_AUD) {
 if (pc->frame_start_found) {
-i++;
+/* Some streams in the wild are missing the zero_byte at 
the NAL_AUD:
+ * it is following just afterwards.
+ * To avoid any accidental borrowing of a byte in the 
previous frame
+ * (which would return a negative index and indicate that 
fetch_timestamps
+ * has to get the pts from the previous frame),
+ * better have the start of packet strictly aligned.
+ * To make it a more general rule, just test the following 
three bytes are null.
+ */
+i += 1 + (!p->is_avc && state == 5 && i == 3 && nalu_type 
== H264_NAL_AUD &&
+buf_size >= 9 && !AV_RB24(buf + 5));
 goto found;
 }
 } else if (nalu_type == H264_NAL_SLICE || nalu_type == 
H264_NAL_DPA ||
-- 
2.30.2

___
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.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 1/5] avcodec/parser: merge packets from the same frame

2024-03-01 Thread Nicolas Gaullier

The mpegts demuxer splits packets according to its max_packet_size.
This currently fills the AVCodecParserContext s->cur_frame_* arrays with
kind of 'empty' entries: no pts/dts.
This patch merges these entries, so the parser behaviour is independent
from the demuxer settings.
This patch is required for the following patch which will fetch 'past'
timestamps from past cur_frames.

Signed-off-by: Nicolas Gaullier 
---
 libavcodec/parser.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index efc28b8918..249f81d4bb 100644
--- a/libavcodec/parser.c
+++ b/libavcodec/parser.c
@@ -142,6 +142,7 @@ int av_parser_parse2(AVCodecParserContext *s, 
AVCodecContext *avctx,
 memset(dummy_buf, 0, sizeof(dummy_buf));
 buf = dummy_buf;
 } else if (s->cur_offset + buf_size != 
s->cur_frame_end[s->cur_frame_start_index]) { /* skip remainder packets */
+if (pos != s->cur_frame_pos[s->cur_frame_start_index] || pos <= 0 || 
pts != AV_NOPTS_VALUE ) {
 /* add a new packet descriptor */
 i = (s->cur_frame_start_index + 1) & (AV_PARSER_PTS_NB - 1);
 s->cur_frame_start_index = i;
@@ -150,6 +151,9 @@ int av_parser_parse2(AVCodecParserContext *s, 
AVCodecContext *avctx,
 s->cur_frame_pts[i]  = pts;
 s->cur_frame_dts[i]  = dts;
 s->cur_frame_pos[i]  = pos;
+} else {
+s->cur_frame_end[s->cur_frame_start_index] = s->cur_offset + 
buf_size;
+}
 }
 
 if (s->fetch_timestamp) {
-- 
2.30.2

___
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.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 3/5] avcodec/parser: fix fetch_timestamp in a scenario with unaligned packets

2024-03-01 Thread Nicolas Gaullier

Fix fetch_timestamp when the frame start is in a previous packet.

Signed-off-by: Nicolas Gaullier 
---
 libavcodec/parser.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index ede9e7e8b4..e4e9fbf48f 100644
--- a/libavcodec/parser.c
+++ b/libavcodec/parser.c
@@ -102,7 +102,7 @@ void ff_fetch_timestamp(AVCodecParserContext *s, int off, 
int remove, int fuzzy)
 s->dts= s->cur_frame_dts[i];
 s->pts= s->cur_frame_pts[i];
 s->pos= s->cur_frame_pos[i];
-s->offset = s->next_frame_offset - s->cur_frame_offset[i];
+s->offset = FFMAX( 0, s->next_frame_offset - 
s->cur_frame_offset[i]);
 }
 if (remove)
 s->cur_frame_offset[i] = INT64_MAX;
@@ -157,11 +157,11 @@ int av_parser_parse2(AVCodecParserContext *s, 
AVCodecContext *avctx,
 }
 
 if (s->fetch_timestamp) {
-s->fetch_timestamp = 0;
 s->last_pts= s->pts;
 s->last_dts= s->dts;
 s->last_pos= s->pos;
-ff_fetch_timestamp(s, 0, 0, 0);
+ff_fetch_timestamp(s, FFMIN(s->fetch_timestamp, 0), 0, 0);
+s->fetch_timestamp = 0;
 }
 /* WARNING: the returned index can be negative */
 index = s->parser->parser_parse(s, avctx, (const uint8_t **) poutbuf,
@@ -178,12 +178,13 @@ int av_parser_parse2(AVCodecParserContext *s, 
AVCodecContext *avctx,
 
 /* update the file pointer */
 if (*poutbuf_size) {
+s->fetch_timestamp   = index >= 0 || !s->frame_offset ? 1 : index;
+
 /* fill the data for the current frame */
 s->frame_offset = s->next_frame_offset;
 
 /* offset of the next frame */
 s->next_frame_offset = s->cur_offset + index;
-s->fetch_timestamp   = 1;
 } else {
 /* Don't return a pointer to dummy_buf. */
 *poutbuf = NULL;
-- 
2.30.2

___
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.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 0/5] avcodec/parser: fix fetch_timestamp in a scenario with unaligned packets

2024-03-01 Thread Nicolas Gaullier

This is the following of 
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=10843

The file submited by Michael highlighted 3 different and independent issues I 
missed in the first version:
- some corrupt mpegts files are missing the zero_byte at the NAL, but a "full" 
NAL start including the zero_byte
can be found just afterwards, so they can be identified. In some cases, there 
might be a terminal null byte
at the end of the previous frame and thus it is "borrowed" by current code to 
form a complete, full NAL start: 
in such a case, the fix fetch_timestamp now get the pts of the previous pes, 
which is not expected.
So, I've added a h264_parser patch (new patch 4)
- the index may be negative even for the very first packet, despite pointing to 
no data, so
I've added the "!s->frame_offset" condition to enable the "fetch timestamp in 
the past" patch
- the mpegts demuxer has a "split packets" logic according to its 
max_packet_size, and in my understanding,
the behavious of the current code does not look good, the cur_frame_arrays are 
fed with kind of "empty entries",
which now raises an issue because some "past entries" are required to get 
proper timestamps from the previous frame,
so this had to be fixed (new patch 1) : the entries of the splited packets 
should be merged to get consistent entries

Patch 3: I forced the AVCodecParserContext offset to be positive.
Patch 5: unchanged. Still not sure whether this patch is somewhat "required", 
"useless", or "bad".

What possibly remains: as seen with some h264 broken streams in the wild, there 
might be other broken stream issues (hevc?).
If such issues currently exists (but currently with no serious effect), there 
would be a regression in the PTS/DTS values.
So any testing with corrupt streams beyond h264 is wellcome to see if other 
parsers require a fix (say a hack).

For remembering, sample files and cover letter of the first version:
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/321819.html

Nicolas Gaullier (5):
  avcodec/parser: merge packets from the same frame
  avcodec/parser: reindent after previous commit
  avcodec/parser: fix fetch_timestamp in a scenario with unaligned
packets
  avcodec/h264_parser: fix start of packet for some broken streams
  lavf/demux: duplicate side_data in parse_packet()

 libavcodec/h264_parser.c  |  11 +-
 libavcodec/parser.c   |  29 ++--
 libavformat/demux.c   |  23 ++-
 tests/ref/fate/concat-demuxer-simple2-lavf-ts | 164 +-
 tests/ref/fate/ts-demux   |   8 +-
 5 files changed, 131 insertions(+), 104 deletions(-)

-- 
2.30.2

___
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.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 2/5] avcodec/parser: reindent after previous commit

2024-03-01 Thread Nicolas Gaullier

Signed-off-by: Nicolas Gaullier 
---
 libavcodec/parser.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index 249f81d4bb..ede9e7e8b4 100644
--- a/libavcodec/parser.c
+++ b/libavcodec/parser.c
@@ -143,14 +143,14 @@ int av_parser_parse2(AVCodecParserContext *s, 
AVCodecContext *avctx,
 buf = dummy_buf;
 } else if (s->cur_offset + buf_size != 
s->cur_frame_end[s->cur_frame_start_index]) { /* skip remainder packets */
 if (pos != s->cur_frame_pos[s->cur_frame_start_index] || pos <= 0 || 
pts != AV_NOPTS_VALUE ) {
-/* add a new packet descriptor */
-i = (s->cur_frame_start_index + 1) & (AV_PARSER_PTS_NB - 1);
-s->cur_frame_start_index = i;
-s->cur_frame_offset[i]   = s->cur_offset;
-s->cur_frame_end[i]  = s->cur_offset + buf_size;
-s->cur_frame_pts[i]  = pts;
-s->cur_frame_dts[i]  = dts;
-s->cur_frame_pos[i]  = pos;
+/* add a new packet descriptor */
+i = (s->cur_frame_start_index + 1) & (AV_PARSER_PTS_NB - 1);
+s->cur_frame_start_index = i;
+s->cur_frame_offset[i]   = s->cur_offset;
+s->cur_frame_end[i]  = s->cur_offset + buf_size;
+s->cur_frame_pts[i]  = pts;
+s->cur_frame_dts[i]  = dts;
+s->cur_frame_pos[i]  = pos;
 } else {
 s->cur_frame_end[s->cur_frame_start_index] = s->cur_offset + 
buf_size;
 }
-- 
2.30.2

___
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.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/decode: give packet side data priority over global

2024-03-01 Thread James Almer

Restores the behavior prior to ae22271620df90567ba276832b33607d64e9ba9c, where
global side data would be inserted first to the output frame, resulting in both
two entries for the same type and having priority when fetched by the AVFrame
helpers.

This is a temporary fix for ticket #10857 until a proper method to select the
source for side data is implemented.

Signed-off-by: James Almer 
---
This is meant to restore the old behavior in git master until
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=10880 is finally
implemented.

 libavcodec/decode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 7c67b18bc4..0dbbf4a6da 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1465,6 +1465,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (packet_sd) {
 AVFrameSideData *frame_sd;
 
+av_frame_remove_side_data(frame, sd_global_map[i].frame);
 frame_sd = av_frame_new_side_data(frame, sd_global_map[i].frame, 
size);
 if (!frame_sd)
 return AVERROR(ENOMEM);
-- 
2.44.0

___
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.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] configure: Add missing vvc_decoder->cbs_h266 dependency

2024-03-01 Thread Andreas Rheinhardt

Signed-off-by: Andreas Rheinhardt 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 574c9bf5f6..b5b233e852 100755
--- a/configure
+++ b/configure
@@ -3036,7 +3036,7 @@ vp6f_decoder_select="vp6_decoder"
 vp7_decoder_select="h264pred videodsp vp8dsp"
 vp8_decoder_select="h264pred videodsp vp8dsp"
 vp9_decoder_select="videodsp vp9_parser vp9_superframe_split_bsf"
-vvc_decoder_select="cabac golomb videodsp"
+vvc_decoder_select="cabac cbs_h266 golomb videodsp"
 wcmv_decoder_select="inflate_wrapper"
 webp_decoder_select="vp8_decoder exif"
 wmalossless_decoder_select="llauddsp"
-- 
2.40.1

___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/bsf/mp3_header_decompress: Remove BSF

2024-03-01 Thread Andreas Rheinhardt

Andreas Rheinhardt:
> This BSF is supposed to be used in conjunction with mp3_header_compress,
> which has been removed more than ten years ago in commit
> c6080d89009056530119ab794ad02e4d515c7754. It mangled the headers
> by removing the CRC field as well as fields that are supposed
> to stay constant for the entirety of a stream (which are put into
> extradata). This made these files unplayable; they need to be
> decompressed with the BSF first (which does not happen automatically).
> Even in this case the CRC does not get restored.
> 
> I am not aware that such compressed files exist at all; therefore
> this commit removes the BSF completely.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  doc/bitstream_filters.texi |   4 -
>  libavcodec/Makefile|   1 -
>  libavcodec/bitstream_filters.c |   1 -
>  libavcodec/bsf/Makefile|   1 -
>  libavcodec/bsf/mp3_header_decompress.c | 130 -
>  5 files changed, 137 deletions(-)
>  delete mode 100644 libavcodec/bsf/mp3_header_decompress.c
> 
> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> index d5bac105ff..e06de1a73a 100644
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -528,10 +528,6 @@ metadata header from each subtitle packet.
>  
>  See also the @ref{text2movsub} filter.
>  
> -@section mp3decomp
> -
> -Decompress non-standard compressed MP3 audio headers.
> -
>  @section mpeg2_metadata
>  
>  Modify metadata embedded in an MPEG-2 stream.
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 09ae5270b3..f28a6568de 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -1240,7 +1240,6 @@ OBJS-$(CONFIG_EXTRACT_EXTRADATA_BSF)  += 
> av1_parse.o h2645_parse.o
>  OBJS-$(CONFIG_H264_METADATA_BSF)  += h264_levels.o h2645data.o
>  OBJS-$(CONFIG_HAPQA_EXTRACT_BSF)  += hap.o
>  OBJS-$(CONFIG_HEVC_METADATA_BSF)  += h265_profile_level.o h2645data.o
> -OBJS-$(CONFIG_MP3_HEADER_DECOMPRESS_BSF)  += mpegaudiotabs.o
>  OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF)   += av1_parse.o
>  OBJS-$(CONFIG_TRUEHD_CORE_BSF)+= mlp_parse.o mlp.o
>  
> diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
> index 1bae113d92..12860c332b 100644
> --- a/libavcodec/bitstream_filters.c
> +++ b/libavcodec/bitstream_filters.c
> @@ -46,7 +46,6 @@ extern const FFBitStreamFilter ff_imx_dump_header_bsf;
>  extern const FFBitStreamFilter ff_media100_to_mjpegb_bsf;
>  extern const FFBitStreamFilter ff_mjpeg2jpeg_bsf;
>  extern const FFBitStreamFilter ff_mjpega_dump_header_bsf;
> -extern const FFBitStreamFilter ff_mp3_header_decompress_bsf;
>  extern const FFBitStreamFilter ff_mpeg2_metadata_bsf;
>  extern const FFBitStreamFilter ff_mpeg4_unpack_bframes_bsf;
>  extern const FFBitStreamFilter ff_mov2textsub_bsf;
> diff --git a/libavcodec/bsf/Makefile b/libavcodec/bsf/Makefile
> index 62609eb24e..fb70ad0c21 100644
> --- a/libavcodec/bsf/Makefile
> +++ b/libavcodec/bsf/Makefile
> @@ -25,7 +25,6 @@ OBJS-$(CONFIG_MEDIA100_TO_MJPEGB_BSF) += 
> bsf/media100_to_mjpegb.o
>  OBJS-$(CONFIG_MJPEG2JPEG_BSF) += bsf/mjpeg2jpeg.o
>  OBJS-$(CONFIG_MJPEGA_DUMP_HEADER_BSF) += bsf/mjpega_dump_header.o
>  OBJS-$(CONFIG_MOV2TEXTSUB_BSF)+= bsf/movsub.o
> -OBJS-$(CONFIG_MP3_HEADER_DECOMPRESS_BSF)  += bsf/mp3_header_decompress.o
>  OBJS-$(CONFIG_MPEG2_METADATA_BSF) += bsf/mpeg2_metadata.o
>  OBJS-$(CONFIG_MPEG4_UNPACK_BFRAMES_BSF)   += bsf/mpeg4_unpack_bframes.o
>  OBJS-$(CONFIG_NOISE_BSF)  += bsf/noise.o
> diff --git a/libavcodec/bsf/mp3_header_decompress.c 
> b/libavcodec/bsf/mp3_header_decompress.c
> deleted file mode 100644
> index a177029fe0..00
> --- a/libavcodec/bsf/mp3_header_decompress.c
> +++ /dev/null
> @@ -1,130 +0,0 @@
> -/*
> - * copyright (c) 2006 Michael Niedermayer 
> - *
> - * This file is part of FFmpeg.
> - *
> - * FFmpeg is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU Lesser General Public
> - * License as published by the Free Software Foundation; either
> - * version 2.1 of the License, or (at your option) any later version.
> - *
> - * FFmpeg is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> - * Lesser General Public License for more details.
> - *
> - * You should have received a copy of the GNU Lesser General Public
> - * License along with FFmpeg; if not, write to the Free Software
> - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> - */
> -
> -#include "libavutil/common.h"
> -#include "libavutil/intreadwrite.h"
> -#include "bsf.h"
> -#include "bsf_internal.h"
> -#include "defs.h"
> -#include "mpegaudiodecheader.h"
> -#include "mpegaudiodata.h"
> -
> -
> -static int mp3_header_decompress(AVBSFContext *ctx,

Re: [FFmpeg-devel] [PATCH 1/4] avformat/avio: Make avio_print_string_array() accept const pointers

2024-03-01 Thread Andreas Rheinhardt

Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  doc/APIchanges| 3 +++
>  libavformat/avio.h| 2 +-
>  libavformat/aviobuf.c | 2 +-
>  3 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 10f6667e9e..055e6848a3 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
>  
>  API changes, most recent first:
>  
> +2024-02-28 - xx - lavf 60.xx.100 - avio.h
> +  avio_print_string_array() now accepts an array of const pointers.
> +
>  2024-02-26 - xx - lavf 60.22.101 - avformat.h
>AV_DISPOSITION_DEPENDENT may now also be used for video streams
>intended to be merged with other video streams for presentation.
> diff --git a/libavformat/avio.h b/libavformat/avio.h
> index 887a397c37..43bce60ffd 100644
> --- a/libavformat/avio.h
> +++ b/libavformat/avio.h
> @@ -544,7 +544,7 @@ int avio_printf(AVIOContext *s, const char *fmt, ...) 
> av_printf_format(2, 3);
>   * Usually you don't need to use this function directly but its macro 
> wrapper,
>   * avio_print.
>   */
> -void avio_print_string_array(AVIOContext *s, const char *strings[]);
> +void avio_print_string_array(AVIOContext *s, const char * const strings[]);
>  
>  /**
>   * Write strings (const char *) to the context.
> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> index 76780bc852..d80b8527bb 100644
> --- a/libavformat/aviobuf.c
> +++ b/libavformat/aviobuf.c
> @@ -1400,7 +1400,7 @@ int avio_printf(AVIOContext *s, const char *fmt, ...)
>  return ret;
>  }
>  
> -void avio_print_string_array(AVIOContext *s, const char *strings[])
> +void avio_print_string_array(AVIOContext *s, const char *const strings[])
>  {
>  for(; *strings; strings++)
>  avio_write(s, (const unsigned char *)*strings, strlen(*strings));

Will apply this patchset tomorrow unless there are objections.

- Andreas

___
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.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/6] avcodec/aacenc: Move initializing DSP out of aacenc.c

2024-03-01 Thread Andreas Rheinhardt

Andreas Rheinhardt:
> Otherwise aacenc.o gets pulled in by the aacencdsp checkasm
> test and it in turn pulls the rest of lavc in.
> Besides being bad size-wise this also has the downside that
> it pulls in avpriv_(cga|vga16)_font from libavutil which are
> marked as being imported from another library when building
> libavcodec as a DLL and this breaks checkasm because it links
> both lavc and lavu statically.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/aaccoder.c | 26 +--
>  libavcodec/aaccoder_trellis.h |  2 +-
>  libavcodec/aaccoder_twoloop.h |  2 +-
>  libavcodec/aacenc.c   | 21 +++--
>  libavcodec/aacenc.h   |  9 +---
>  libavcodec/aacenc_is.c|  6 +--
>  libavcodec/aacenc_ltp.c   |  4 +-
>  libavcodec/aacenc_pred.c  |  6 +--
>  libavcodec/aacenc_utils.h | 24 ---
>  libavcodec/aacencdsp.h| 72 +++
>  libavcodec/mips/aaccoder_mips.c   |  1 +
>  libavcodec/riscv/aacencdsp_init.c |  5 +--
>  libavcodec/x86/aacencdsp_init.c   |  5 +--
>  tests/checkasm/aacencdsp.c| 10 ++---
>  14 files changed, 112 insertions(+), 81 deletions(-)
>  create mode 100644 libavcodec/aacencdsp.h
> 
> diff --git a/libavcodec/aaccoder.c b/libavcodec/aaccoder.c
> index 6291c16123..4ce54ca886 100644
> --- a/libavcodec/aaccoder.c
> +++ b/libavcodec/aaccoder.c
> @@ -108,10 +108,10 @@ static av_always_inline float 
> quantize_and_encode_band_cost_template(
>  return cost * lambda;
>  }
>  if (!scaled) {
> -s->abs_pow34(s->scoefs, in, size);
> +s->aacdsp.abs_pow34(s->scoefs, in, size);
>  scaled = s->scoefs;
>  }
> -s->quant_bands(s->qcoefs, in, scaled, size, !BT_UNSIGNED, 
> aac_cb_maxval[cb], Q34, ROUNDING);
> +s->aacdsp.quant_bands(s->qcoefs, in, scaled, size, !BT_UNSIGNED, 
> aac_cb_maxval[cb], Q34, ROUNDING);
>  if (BT_UNSIGNED) {
>  off = 0;
>  } else {
> @@ -311,7 +311,7 @@ static void encode_window_bands_info(AACEncContext *s, 
> SingleChannelElement *sce
>  float next_minrd = INFINITY;
>  int next_mincb = 0;
>  
> -s->abs_pow34(s->scoefs, sce->coeffs, 1024);
> +s->aacdsp.abs_pow34(s->scoefs, sce->coeffs, 1024);
>  start = win*128;
>  for (cb = 0; cb < CB_TOT_ALL; cb++) {
>  path[0][cb].cost = 0.0f;
> @@ -522,7 +522,7 @@ static void search_for_quantizers_anmr(AVCodecContext 
> *avctx, AACEncContext *s,
>  }
>  }
>  idx = 1;
> -s->abs_pow34(s->scoefs, sce->coeffs, 1024);
> +s->aacdsp.abs_pow34(s->scoefs, sce->coeffs, 1024);
>  for (w = 0; w < sce->ics.num_windows; w += sce->ics.group_len[w]) {
>  start = w*128;
>  for (g = 0; g < sce->ics.num_swb; g++) {
> @@ -668,7 +668,7 @@ static void search_for_quantizers_fast(AVCodecContext 
> *avctx, AACEncContext *s,
>  
>  if (!allz)
>  return;
> -s->abs_pow34(s->scoefs, sce->coeffs, 1024);
> +s->aacdsp.abs_pow34(s->scoefs, sce->coeffs, 1024);
>  ff_quantize_band_cost_cache_init(s);
>  
>  for (w = 0; w < sce->ics.num_windows; w += sce->ics.group_len[w]) {
> @@ -874,8 +874,8 @@ static void search_for_pns(AACEncContext *s, 
> AVCodecContext *avctx, SingleChanne
>  s->fdsp->vector_fmul_scalar(PNS, PNS, scale, 
> sce->ics.swb_sizes[g]);
>  pns_senergy = s->fdsp->scalarproduct_float(PNS, PNS, 
> sce->ics.swb_sizes[g]);
>  pns_energy += pns_senergy;
> -s->abs_pow34(NOR34, >coeffs[start_c], 
> sce->ics.swb_sizes[g]);
> -s->abs_pow34(PNS34, PNS, sce->ics.swb_sizes[g]);
> +s->aacdsp.abs_pow34(NOR34, >coeffs[start_c], 
> sce->ics.swb_sizes[g]);
> +s->aacdsp.abs_pow34(PNS34, PNS, sce->ics.swb_sizes[g]);
>  dist1 += quantize_band_cost(s, >coeffs[start_c],
>  NOR34,
>  sce->ics.swb_sizes[g],
> @@ -1012,8 +1012,8 @@ static void search_for_ms(AACEncContext *s, 
> ChannelElement *cpe)
>  S[i] =  M[i]
>- sce1->coeffs[start+(w+w2)*128+i];
>  }
> -s->abs_pow34(M34, M, sce0->ics.swb_sizes[g]);
> -s->abs_pow34(S34, S, sce0->ics.swb_sizes[g]);
> +s->aacdsp.abs_pow34(M34, M, sce0->ics.swb_sizes[g]);
> +s->aacdsp.abs_pow34(S34, S, sce0->ics.swb_sizes[g]);
>  for (i = 0; i < sce0->ics.swb_sizes[g]; i++ ) {
>  Mmax = FFMAX(Mmax, M34[i]);
>  Smax = FFMAX(Smax, S34[i]);
> @@ -1056,10 +1056,10 @@ static void search_for_ms(AACEncContext *s, 
> ChannelElement *cpe)
>- sce1->coeffs[start+(w+w2)*128+i];
>  }
>  
> -s->abs_pow34(L34, sce0->coeffs+start+(w+w2)*128, 
>

Re: [FFmpeg-devel] [PATCH] avcodec/x86/rv40dsp, simple_idct: Remove remnants of MMX

2024-03-01 Thread Andreas Rheinhardt

Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/x86/rv40dsp.asm | 10 --
>  libavcodec/x86/simple_idct.asm | 36 --
>  2 files changed, 46 deletions(-)
> 
> diff --git a/libavcodec/x86/rv40dsp.asm b/libavcodec/x86/rv40dsp.asm
> index e02ad2c63f..e3c37dd297 100644
> --- a/libavcodec/x86/rv40dsp.asm
> +++ b/libavcodec/x86/rv40dsp.asm
> @@ -401,15 +401,6 @@ FILTER_SSSE3  avg
>  
>  
>  %macro MAIN_LOOP   2
> -%if mmsize == 8
> -RV40_WCORE %2, r0, r1, r2
> -%if %1 == 16
> -RV40_WCORE %2, r0 + 8, r1 + 8, r2 + 8
> -%endif
> -
> -; Prepare for next loop
> -addr6, r5
> -%else
>  %ifidn %1, 8
>  RV40_WCORE %2, r0, r1, r2, r5
>  ; Prepare 2 next lines
> @@ -419,7 +410,6 @@ FILTER_SSSE3  avg
>  ; Prepare single next line
>  addr6, r5
>  %endif
> -%endif
>  
>  %endmacro
>  
> diff --git a/libavcodec/x86/simple_idct.asm b/libavcodec/x86/simple_idct.asm
> index 4139b6dab5..c79519372a 100644
> --- a/libavcodec/x86/simple_idct.asm
> +++ b/libavcodec/x86/simple_idct.asm
> @@ -783,62 +783,26 @@ SECTION .text
>  %macro PUT_PIXELS_CLAMPED_HALF 1
>  mova m0, [blockq+mmsize*0+%1]
>  mova m1, [blockq+mmsize*2+%1]
> -%if mmsize == 8
> -mova m2, [blockq+mmsize*4+%1]
> -mova m3, [blockq+mmsize*6+%1]
> -%endif
>  packuswb m0, [blockq+mmsize*1+%1]
>  packuswb m1, [blockq+mmsize*3+%1]
> -%if mmsize == 8
> -packuswb m2, [blockq+mmsize*5+%1]
> -packuswb m3, [blockq+mmsize*7+%1]
> -movq   [pixelsq], m0
> -movq[lsizeq+pixelsq], m1
> -movq  [2*lsizeq+pixelsq], m2
> -movq   [lsize3q+pixelsq], m3
> -%else
>  movq   [pixelsq], m0
>  movhps  [lsizeq+pixelsq], m0
>  movq  [2*lsizeq+pixelsq], m1
>  movhps [lsize3q+pixelsq], m1
> -%endif
>  %endmacro
>  
>  %macro ADD_PIXELS_CLAMPED 1
>  mova   m0, [blockq+mmsize*0+%1]
>  mova   m1, [blockq+mmsize*1+%1]
> -%if mmsize == 8
> -mova   m5, [blockq+mmsize*2+%1]
> -mova   m6, [blockq+mmsize*3+%1]
> -%endif
>  movq   m2, [pixelsq]
>  movq   m3, [pixelsq+lsizeq]
> -%if mmsize == 8
> -mova   m7, m2
> -punpcklbw  m2, m4
> -punpckhbw  m7, m4
> -paddsw m0, m2
> -paddsw m1, m7
> -mova   m7, m3
> -punpcklbw  m3, m4
> -punpckhbw  m7, m4
> -paddsw m5, m3
> -paddsw m6, m7
> -%else
>  punpcklbw  m2, m4
>  punpcklbw  m3, m4
>  paddsw m0, m2
>  paddsw m1, m3
> -%endif
>  packuswb   m0, m1
> -%if mmsize == 8
> -packuswb   m5, m6
> -movq   [pixelsq], m0
> -movq   [pixelsq+lsizeq], m5
> -%else
>  movq   [pixelsq], m0
>  movhps [pixelsq+lsizeq], m0
> -%endif
>  %endmacro
>  
>  INIT_MMX mmx

Will apply tomorrow unless there are objections.

- Andreas

___
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.org with subject "unsubscribe".

54 matches

Mail list logo