[FFmpeg-devel] [PATCH 17/21] aarch64: hevc: Reorder qpel_hv functions to prepare for templating
--- libavcodec/aarch64/hevcdsp_qpel_neon.S | 695 + 1 file changed, 355 insertions(+), 340 deletions(-) diff --git a/libavcodec/aarch64/hevcdsp_qpel_neon.S b/libavcodec/aarch64/hevcdsp_qpel_neon.S index 06832603d9..ad568e415b 100644 --- a/libavcodec/aarch64/hevcdsp_qpel_neon.S +++ b/libavcodec/aarch64/hevcdsp_qpel_neon.S @@ -2146,29 +2146,6 @@ function ff_hevc_put_hevc_qpel_uni_w_v64_8_neon, export=1 ret endfunc -#if HAVE_I8MM -ENABLE_I8MM - -function ff_hevc_put_hevc_qpel_uni_hv4_8_neon_i8mm, export=1 -add w10, w4, #7 -lsl x10, x10, #7 -sub sp, sp, x10 // tmp_array -str x30, [sp, #-48]! -stp x4, x6, [sp, #16] -stp x0, x1, [sp, #32] -sub x1, x2, x3, lsl #1 -sub x1, x1, x3 -add x0, sp, #48 -mov x2, x3 -add x3, x4, #7 -mov x4, x5 -bl X(ff_hevc_put_hevc_qpel_h4_8_neon_i8mm) -ldp x4, x6, [sp, #16] -ldp x0, x1, [sp, #32] -ldr x30, [sp], #48 -b hevc_put_hevc_qpel_uni_hv4_8_end_neon -endfunc - function hevc_put_hevc_qpel_uni_hv4_8_end_neon mov x9, #(MAX_PB_SIZE * 2) load_qpel_filterh x6, x5 @@ -2195,26 +2172,6 @@ function hevc_put_hevc_qpel_uni_hv4_8_end_neon 2: ret endfunc -function ff_hevc_put_hevc_qpel_uni_hv6_8_neon_i8mm, export=1 -add w10, w4, #7 -lsl x10, x10, #7 -sub sp, sp, x10 // tmp_array -str x30, [sp, #-48]! -stp x4, x6, [sp, #16] -stp x0, x1, [sp, #32] -sub x1, x2, x3, lsl #1 -sub x1, x1, x3 -add x0, sp, #48 -mov x2, x3 -add w3, w4, #7 -mov x4, x5 -bl X(ff_hevc_put_hevc_qpel_h6_8_neon_i8mm) -ldp x4, x6, [sp, #16] -ldp x0, x1, [sp, #32] -ldr x30, [sp], #48 -b hevc_put_hevc_qpel_uni_hv6_8_end_neon -endfunc - function hevc_put_hevc_qpel_uni_hv6_8_end_neon mov x9, #(MAX_PB_SIZE * 2) load_qpel_filterh x6, x5 @@ -2244,26 +2201,6 @@ function hevc_put_hevc_qpel_uni_hv6_8_end_neon 2: ret endfunc -function ff_hevc_put_hevc_qpel_uni_hv8_8_neon_i8mm, export=1 -add w10, w4, #7 -lsl x10, x10, #7 -sub sp, sp, x10 // tmp_array -str x30, [sp, #-48]! -stp x4, x6, [sp, #16] -stp x0, x1, [sp, #32] -sub x1, x2, x3, lsl #1 -sub x1, x1, x3 -add x0, sp, #48 -mov x2, x3 -add w3, w4, #7 -mov x4, x5 -bl X(ff_hevc_put_hevc_qpel_h8_8_neon_i8mm) -ldp x4, x6, [sp, #16] -ldp x0, x1, [sp, #32] -ldr x30, [sp], #48 -b hevc_put_hevc_qpel_uni_hv8_8_end_neon -endfunc - function hevc_put_hevc_qpel_uni_hv8_8_end_neon mov x9, #(MAX_PB_SIZE * 2) load_qpel_filterh x6, x5 @@ -2291,26 +2228,6 @@ function hevc_put_hevc_qpel_uni_hv8_8_end_neon 2: ret endfunc -function ff_hevc_put_hevc_qpel_uni_hv12_8_neon_i8mm, export=1 -add w10, w4, #7 -lsl x10, x10, #7 -sub sp, sp, x10 // tmp_array -stp x7, x30, [sp, #-48]! -stp x4, x6, [sp, #16] -stp x0, x1, [sp, #32] -sub x1, x2, x3, lsl #1 -sub x1, x1, x3 -mov x2, x3 -add x0, sp, #48 -add w3, w4, #7 -mov x4, x5 -bl X(ff_hevc_put_hevc_qpel_h12_8_neon_i8mm) -ldp x4, x6, [sp, #16] -ldp x0, x1, [sp, #32] -ldp x7, x30, [sp], #48 -b hevc_put_hevc_qpel_uni_hv12_8_end_neon -endfunc - function hevc_put_hevc_qpel_uni_hv12_8_end_neon mov x9, #(MAX_PB_SIZE * 2) load_qpel_filterh x6, x5 @@ -2338,26 +2255,6 @@ function hevc_put_hevc_qpel_uni_hv12_8_end_neon 2: ret endfunc -function ff_hevc_put_hevc_qpel_uni_hv16_8_neon_i8mm, export=1 -add w10, w4, #7 -lsl x10, x10, #7 -sub sp, sp, x10 // tmp_array -stp x7, x30, [sp, #-48]! -stp x4, x6, [sp, #16] -stp x0, x1, [sp, #32] -add x0, sp, #48 -sub
[FFmpeg-devel] [PATCH 16/21] aarch64: hevc: Deduplicate the hevc_put_hevc_qpel_uni_w_hv*_8_end_neon functions
The hv32 and hv64 functions were identical - both loop and process 16 pixels at a time. The hv16 function was near identical, except for the outer loop (and using sp instead of a separate register). Given the size of these functions, the extra cost of the outer loop is negligible, so use the same function for hv16 as well. This removes over 200 lines of duplicated assembly, and over 4 KB of binary size. --- libavcodec/aarch64/hevcdsp_qpel_neon.S | 220 + 1 file changed, 3 insertions(+), 217 deletions(-) diff --git a/libavcodec/aarch64/hevcdsp_qpel_neon.S b/libavcodec/aarch64/hevcdsp_qpel_neon.S index c04e8dbea8..06832603d9 100644 --- a/libavcodec/aarch64/hevcdsp_qpel_neon.S +++ b/libavcodec/aarch64/hevcdsp_qpel_neon.S @@ -4381,231 +4381,17 @@ function ff_hevc_put_hevc_qpel_uni_w_hv16_8_neon_i8mm, export=1 b hevc_put_hevc_qpel_uni_w_hv16_8_end_neon endfunc -function hevc_put_hevc_qpel_uni_w_hv16_8_end_neon -ldp q16, q1, [sp] -add sp, sp, x10 -ldp q17, q2, [sp] -add sp, sp, x10 -ldp q18, q3, [sp] -add sp, sp, x10 -ldp q19, q4, [sp] -add sp, sp, x10 -ldp q20, q5, [sp] -add sp, sp, x10 -ldp q21, q6, [sp] -add sp, sp, x10 -ldp q22, q7, [sp] -add sp, sp, x10 -1: -ldp q23, q31, [sp] -add sp, sp, x10 -QPEL_FILTER_H v24, v16, v17, v18, v19, v20, v21, v22, v23 -QPEL_FILTER_H2 v25, v16, v17, v18, v19, v20, v21, v22, v23 -QPEL_FILTER_H v26, v1, v2, v3, v4, v5, v6, v7, v31 -QPEL_FILTER_H2 v27, v1, v2, v3, v4, v5, v6, v7, v31 -QPEL_UNI_W_HV_16 -subsw22, w22, #1 -b.eq2f - -ldp q16, q1, [sp] -add sp, sp, x10 -QPEL_FILTER_H v24, v17, v18, v19, v20, v21, v22, v23, v16 -QPEL_FILTER_H2 v25, v17, v18, v19, v20, v21, v22, v23, v16 -QPEL_FILTER_H v26, v2, v3, v4, v5, v6, v7, v31, v1 -QPEL_FILTER_H2 v27, v2, v3, v4, v5, v6, v7, v31, v1 -QPEL_UNI_W_HV_16 -subsw22, w22, #1 -b.eq2f - -ldp q17, q2, [sp] -add sp, sp, x10 -QPEL_FILTER_H v24, v18, v19, v20, v21, v22, v23, v16, v17 -QPEL_FILTER_H2 v25, v18, v19, v20, v21, v22, v23, v16, v17 -QPEL_FILTER_H v26, v3, v4, v5, v6, v7, v31, v1, v2 -QPEL_FILTER_H2 v27, v3, v4, v5, v6, v7, v31, v1, v2 -QPEL_UNI_W_HV_16 -subsw22, w22, #1 -b.eq2f - -ldp q18, q3, [sp] -add sp, sp, x10 -QPEL_FILTER_H v24, v19, v20, v21, v22, v23, v16, v17, v18 -QPEL_FILTER_H2 v25, v19, v20, v21, v22, v23, v16, v17, v18 -QPEL_FILTER_H v26, v4, v5, v6, v7, v31, v1, v2, v3 -QPEL_FILTER_H2 v27, v4, v5, v6, v7, v31, v1, v2, v3 -QPEL_UNI_W_HV_16 -subsw22, w22, #1 -b.eq2f - -ldp q19, q4, [sp] -add sp, sp, x10 -QPEL_FILTER_H v24, v20, v21, v22, v23, v16, v17, v18, v19 -QPEL_FILTER_H2 v25, v20, v21, v22, v23, v16, v17, v18, v19 -QPEL_FILTER_H v26, v5, v6, v7, v31, v1, v2, v3, v4 -QPEL_FILTER_H2 v27, v5, v6, v7, v31, v1, v2, v3, v4 -QPEL_UNI_W_HV_16 -subsw22, w22, #1 -b.eq2f - -ldp q20, q5, [sp] -add sp, sp, x10 -QPEL_FILTER_H v24, v21, v22, v23, v16, v17, v18, v19, v20 -QPEL_FILTER_H2 v25, v21, v22, v23, v16, v17, v18, v19, v20 -QPEL_FILTER_H v26, v6, v7, v31, v1, v2, v3, v4, v5 -QPEL_FILTER_H2 v27, v6, v7, v31, v1, v2, v3, v4, v5 -QPEL_UNI_W_HV_16 -subsw22, w22, #1 -b.eq2f - -ldp q21, q6, [sp] -add sp, sp, x10 -QPEL_FILTER_H v24, v22, v23, v16, v17, v18, v19, v20, v21 -QPEL_FILTER_H2 v25, v22, v23, v16, v17, v18, v19, v20, v21 -QPEL_FILTER_H v26, v7, v31, v1, v2, v3, v4, v5, v6 -QPEL_FILTER_H2 v27, v7, v31, v1, v2, v3, v4, v5, v6 -QPEL_UNI_W_HV_16 -subsw22, w22, #1 -b.eq2f - -ldp q22, q7, [sp] -add sp, sp, x10 -QPEL_FILTER_H v24, v23, v16, v17, v18, v19, v20, v21, v22 -QPEL_FILTER_H2 v25, v23, v16, v17, v18, v19, v20, v21, v22 -QPEL_FILTER_H v26, v31, v1, v2, v3, v4, v5, v6, v7 -QPEL_FILTER_H2 v27, v31, v1, v2, v3, v4, v5, v6, v7 -QPE
[FFmpeg-devel] [PATCH 18/21] aarch64: hevc: Produce plain neon versions of qpel_hv
As the plain neon qpel_h functions process two rows at a time,
we need to allocate storage for h+8 rows instead of h+7.
By allocating storage for h+8 rows, incrementing the stack
pointer won't end up at the right spot in the end. Store the
intended final stack pointer value in a register x14 which we
store on the stack.
AWS Graviton 3:
put_hevc_qpel_hv4_8_c: 386.0
put_hevc_qpel_hv4_8_neon: 125.7
put_hevc_qpel_hv4_8_i8mm: 83.2
put_hevc_qpel_hv6_8_c: 749.0
put_hevc_qpel_hv6_8_neon: 207.0
put_hevc_qpel_hv6_8_i8mm: 166.0
put_hevc_qpel_hv8_8_c: 1305.2
put_hevc_qpel_hv8_8_neon: 216.5
put_hevc_qpel_hv8_8_i8mm: 213.0
put_hevc_qpel_hv12_8_c: 2570.5
put_hevc_qpel_hv12_8_neon: 480.0
put_hevc_qpel_hv12_8_i8mm: 398.2
put_hevc_qpel_hv16_8_c: 4158.7
put_hevc_qpel_hv16_8_neon: 659.7
put_hevc_qpel_hv16_8_i8mm: 593.5
put_hevc_qpel_hv24_8_c: 8626.7
put_hevc_qpel_hv24_8_neon: 1653.5
put_hevc_qpel_hv24_8_i8mm: 1398.7
put_hevc_qpel_hv32_8_c: 14646.0
put_hevc_qpel_hv32_8_neon: 2566.2
put_hevc_qpel_hv32_8_i8mm: 2287.5
put_hevc_qpel_hv48_8_c: 31072.5
put_hevc_qpel_hv48_8_neon: 6228.5
put_hevc_qpel_hv48_8_i8mm: 5291.0
put_hevc_qpel_hv64_8_c: 53847.2
put_hevc_qpel_hv64_8_neon: 9856.7
put_hevc_qpel_hv64_8_i8mm: 8831.0
---
libavcodec/aarch64/hevcdsp_init_aarch64.c | 6 +
libavcodec/aarch64/hevcdsp_qpel_neon.S| 166 +-
2 files changed, 104 insertions(+), 68 deletions(-)
diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index ea0d26c019..105c26017b 100644
--- a/libavcodec/aarch64/hevcdsp_init_aarch64.c
+++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c
@@ -265,6 +265,10 @@ NEON8_FNPROTO(qpel_v, (int16_t *dst,
const uint8_t *src, ptrdiff_t srcstride,
int height, intptr_t mx, intptr_t my, int width),);
+NEON8_FNPROTO(qpel_hv, (int16_t *dst,
+const uint8_t *src, ptrdiff_t srcstride,
+int height, intptr_t mx, intptr_t my, int width),);
+
NEON8_FNPROTO(qpel_hv, (int16_t *dst,
const uint8_t *src, ptrdiff_t srcstride,
int height, intptr_t mx, intptr_t my, int width), _i8mm);
@@ -436,6 +440,8 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c,
const int bit_depth)
NEON8_FNASSIGN_SHARED_32(c->put_hevc_qpel_uni_w, 0, 1, qpel_uni_w_h,);
+NEON8_FNASSIGN(c->put_hevc_qpel, 1, 1, qpel_hv,);
+
if (have_i8mm(cpu_flags)) {
NEON8_FNASSIGN(c->put_hevc_epel, 0, 1, epel_h, _i8mm);
NEON8_FNASSIGN(c->put_hevc_epel, 1, 1, epel_hv, _i8mm);
diff --git a/libavcodec/aarch64/hevcdsp_qpel_neon.S
b/libavcodec/aarch64/hevcdsp_qpel_neon.S
index ad568e415b..7bffb991a7 100644
--- a/libavcodec/aarch64/hevcdsp_qpel_neon.S
+++ b/libavcodec/aarch64/hevcdsp_qpel_neon.S
@@ -3804,7 +3804,8 @@ function hevc_put_hevc_qpel_hv4_8_end_neon
.endm
1: calc_all
.purgem calc
-2: ret
+2: mov sp, x14
+ret
endfunc
function hevc_put_hevc_qpel_hv6_8_end_neon
@@ -3831,7 +3832,8 @@ function hevc_put_hevc_qpel_hv6_8_end_neon
.endm
1: calc_all
.purgem calc
-2: ret
+2: mov sp, x14
+ret
endfunc
function hevc_put_hevc_qpel_hv8_8_end_neon
@@ -3857,7 +3859,8 @@ function hevc_put_hevc_qpel_hv8_8_end_neon
.endm
1: calc_all
.purgem calc
-2: ret
+2: mov sp, x14
+ret
endfunc
function hevc_put_hevc_qpel_hv12_8_end_neon
@@ -3882,7 +3885,8 @@ function hevc_put_hevc_qpel_hv12_8_end_neon
.endm
1: calc_all2
.purgem calc
-2: ret
+2: mov sp, x14
+ret
endfunc
function hevc_put_hevc_qpel_hv16_8_end_neon
@@ -3906,7 +3910,8 @@ function hevc_put_hevc_qpel_hv16_8_end_neon
.endm
1: calc_all2
.purgem calc
-2: ret
+2: mov sp, x14
+ret
endfunc
function hevc_put_hevc_qpel_hv32_8_end_neon
@@ -3937,162 +3942,187 @@ function hevc_put_hevc_qpel_hv32_8_end_neon
add sp, sp, #32
subsw6, w6, #16
b.hi0b
-add w10, w3, #6
-add sp, sp, #64 // discard rest of first line
-lsl x10, x10, #7
-add sp, sp, x10 // tmp_array without first line
+mov sp, x14
ret
endfunc
-#if HAVE_I8MM
-ENABLE_I8MM
-function ff_hevc_put_hevc_qpel_hv4_8_neon_i8mm, export=1
-add w10, w3, #7
+.macro qpel_hv suffix
+function ff_hevc_put_hevc_qpel_hv4_8_\suffix, export=1
+add w10, w3, #8
mov x7, #128
lsl x10, x10, #7
+mov x14, sp
sub sp, sp, x10 // tmp_array
-stp x5, x30, [sp, #-32]!
-stp x0, x3, [sp, #16]
-add x0, sp, #32
+stp x5, x30, [sp, #-48]!
+stp x0, x3, [sp, #16]
+str x14, [sp, #32]
+add x0, sp, #48
[FFmpeg-devel] [PATCH 19/21] aarch64: hevc: Produce plain neon versions of qpel_uni_hv
As the plain neon qpel_h functions process two rows at a time,
we need to allocate storage for h+8 rows instead of h+7.
By allocating storage for h+8 rows, incrementing the stack
pointer won't end up at the right spot in the end. Store the
intended final stack pointer value in a register x14 which we
store on the stack.
AWS Graviton 3:
put_hevc_qpel_uni_hv4_8_c: 384.2
put_hevc_qpel_uni_hv4_8_neon: 127.5
put_hevc_qpel_uni_hv4_8_i8mm: 85.5
put_hevc_qpel_uni_hv6_8_c: 705.5
put_hevc_qpel_uni_hv6_8_neon: 224.5
put_hevc_qpel_uni_hv6_8_i8mm: 176.2
put_hevc_qpel_uni_hv8_8_c: 1136.5
put_hevc_qpel_uni_hv8_8_neon: 216.5
put_hevc_qpel_uni_hv8_8_i8mm: 214.0
put_hevc_qpel_uni_hv12_8_c: 2259.5
put_hevc_qpel_uni_hv12_8_neon: 498.5
put_hevc_qpel_uni_hv12_8_i8mm: 410.7
put_hevc_qpel_uni_hv16_8_c: 3824.7
put_hevc_qpel_uni_hv16_8_neon: 670.0
put_hevc_qpel_uni_hv16_8_i8mm: 603.7
put_hevc_qpel_uni_hv24_8_c: 8113.5
put_hevc_qpel_uni_hv24_8_neon: 1474.7
put_hevc_qpel_uni_hv24_8_i8mm: 1351.5
put_hevc_qpel_uni_hv32_8_c: 14744.5
put_hevc_qpel_uni_hv32_8_neon: 2599.7
put_hevc_qpel_uni_hv32_8_i8mm: 2266.0
put_hevc_qpel_uni_hv48_8_c: 32800.0
put_hevc_qpel_uni_hv48_8_neon: 5650.0
put_hevc_qpel_uni_hv48_8_i8mm: 5011.7
put_hevc_qpel_uni_hv64_8_c: 57856.2
put_hevc_qpel_uni_hv64_8_neon: 9863.5
put_hevc_qpel_uni_hv64_8_i8mm: 8767.7
---
libavcodec/aarch64/hevcdsp_init_aarch64.c | 5 +
libavcodec/aarch64/hevcdsp_qpel_neon.S| 156 ++
2 files changed, 102 insertions(+), 59 deletions(-)
diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index 105c26017b..0531db027b 100644
--- a/libavcodec/aarch64/hevcdsp_init_aarch64.c
+++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c
@@ -277,6 +277,10 @@ NEON8_FNPROTO(qpel_uni_v, (uint8_t *dst, ptrdiff_t
dststride,
const uint8_t *src, ptrdiff_t srcstride,
int height, intptr_t mx, intptr_t my, int width),);
+NEON8_FNPROTO(qpel_uni_hv, (uint8_t *dst, ptrdiff_t dststride,
+const uint8_t *src, ptrdiff_t srcstride,
+int height, intptr_t mx, intptr_t my, int width),);
+
NEON8_FNPROTO(qpel_uni_hv, (uint8_t *dst, ptrdiff_t dststride,
const uint8_t *src, ptrdiff_t srcstride,
int height, intptr_t mx, intptr_t my, int width), _i8mm);
@@ -441,6 +445,7 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c,
const int bit_depth)
NEON8_FNASSIGN_SHARED_32(c->put_hevc_qpel_uni_w, 0, 1, qpel_uni_w_h,);
NEON8_FNASSIGN(c->put_hevc_qpel, 1, 1, qpel_hv,);
+NEON8_FNASSIGN(c->put_hevc_qpel_uni, 1, 1, qpel_uni_hv,);
if (have_i8mm(cpu_flags)) {
NEON8_FNASSIGN(c->put_hevc_epel, 0, 1, epel_h, _i8mm);
diff --git a/libavcodec/aarch64/hevcdsp_qpel_neon.S
b/libavcodec/aarch64/hevcdsp_qpel_neon.S
index 7bffb991a7..f285ab7461 100644
--- a/libavcodec/aarch64/hevcdsp_qpel_neon.S
+++ b/libavcodec/aarch64/hevcdsp_qpel_neon.S
@@ -2169,7 +2169,8 @@ function hevc_put_hevc_qpel_uni_hv4_8_end_neon
.endm
1: calc_all
.purgem calc
-2: ret
+2: mov sp, x14
+ret
endfunc
function hevc_put_hevc_qpel_uni_hv6_8_end_neon
@@ -2198,7 +2199,8 @@ function hevc_put_hevc_qpel_uni_hv6_8_end_neon
.endm
1: calc_all
.purgem calc
-2: ret
+2: mov sp, x14
+ret
endfunc
function hevc_put_hevc_qpel_uni_hv8_8_end_neon
@@ -2225,7 +2227,8 @@ function hevc_put_hevc_qpel_uni_hv8_8_end_neon
.endm
1: calc_all
.purgem calc
-2: ret
+2: mov sp, x14
+ret
endfunc
function hevc_put_hevc_qpel_uni_hv12_8_end_neon
@@ -2252,7 +2255,8 @@ function hevc_put_hevc_qpel_uni_hv12_8_end_neon
.endm
1: calc_all2
.purgem calc
-2: ret
+2: mov sp, x14
+ret
endfunc
function hevc_put_hevc_qpel_uni_hv16_8_end_neon
@@ -2286,21 +2290,17 @@ function hevc_put_hevc_qpel_uni_hv16_8_end_neon
add sp, sp, #32
subsw7, w7, #16
b.ne0b
-add w10, w4, #6
-add sp, sp, x12 // discard rest of first line
-lsl x10, x10, #7
-add sp, sp, x10 // tmp_array without first line
+mov sp, x14
ret
endfunc
-#if HAVE_I8MM
-ENABLE_I8MM
-
-function ff_hevc_put_hevc_qpel_uni_hv4_8_neon_i8mm, export=1
-add w10, w4, #7
+.macro qpel_uni_hv suffix
+function ff_hevc_put_hevc_qpel_uni_hv4_8_\suffix, export=1
+add w10, w4, #8
lsl x10, x10, #7
+mov x14, sp
sub sp, sp, x10 // tmp_array
-str x30, [sp, #-48]!
+stp x30, x14,[sp, #-48]!
stp x4, x6, [sp, #16]
stp x0, x1, [sp, #32]
sub x1, x2, x3, lsl #1
@@ -2309,18 +2309,19 @@ function ff_hevc_put_hevc_qpel_uni_hv4_8_neon_i8mm,
export=1
mov
[FFmpeg-devel] [PATCH 20/21] aarch64: hevc: Produce plain neon versions of qpel_uni_w_hv
As the plain neon qpel_h functions process two rows at a time,
we need to allocate storage for h+8 rows instead of h+7.
AWS Graviton 3:
put_hevc_qpel_uni_w_hv4_8_c: 422.2
put_hevc_qpel_uni_w_hv4_8_neon: 140.7
put_hevc_qpel_uni_w_hv4_8_i8mm: 100.7
put_hevc_qpel_uni_w_hv8_8_c: 1208.0
put_hevc_qpel_uni_w_hv8_8_neon: 268.2
put_hevc_qpel_uni_w_hv8_8_i8mm: 261.5
put_hevc_qpel_uni_w_hv16_8_c: 4297.2
put_hevc_qpel_uni_w_hv16_8_neon: 802.2
put_hevc_qpel_uni_w_hv16_8_i8mm: 731.2
put_hevc_qpel_uni_w_hv32_8_c: 15518.5
put_hevc_qpel_uni_w_hv32_8_neon: 3085.2
put_hevc_qpel_uni_w_hv32_8_i8mm: 2783.2
put_hevc_qpel_uni_w_hv64_8_c: 57254.5
put_hevc_qpel_uni_w_hv64_8_neon: 11787.5
put_hevc_qpel_uni_w_hv64_8_i8mm: 10659.0
---
libavcodec/aarch64/hevcdsp_init_aarch64.c | 6 +++
libavcodec/aarch64/hevcdsp_qpel_neon.S| 47 +++
2 files changed, 37 insertions(+), 16 deletions(-)
diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index 0531db027b..e9ee901322 100644
--- a/libavcodec/aarch64/hevcdsp_init_aarch64.c
+++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c
@@ -305,6 +305,11 @@ NEON8_FNPROTO(epel_uni_w_hv, (uint8_t *_dst, ptrdiff_t
_dststride,
int height, int denom, int wx, int ox,
intptr_t mx, intptr_t my, int width), _i8mm);
+NEON8_FNPROTO_PARTIAL_5(qpel_uni_w_hv, (uint8_t *_dst, ptrdiff_t _dststride,
+const uint8_t *_src, ptrdiff_t _srcstride,
+int height, int denom, int wx, int ox,
+intptr_t mx, intptr_t my, int width),);
+
NEON8_FNPROTO_PARTIAL_5(qpel_uni_w_hv, (uint8_t *_dst, ptrdiff_t _dststride,
const uint8_t *_src, ptrdiff_t _srcstride,
int height, int denom, int wx, int ox,
@@ -446,6 +451,7 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c,
const int bit_depth)
NEON8_FNASSIGN(c->put_hevc_qpel, 1, 1, qpel_hv,);
NEON8_FNASSIGN(c->put_hevc_qpel_uni, 1, 1, qpel_uni_hv,);
+NEON8_FNASSIGN_PARTIAL_5(c->put_hevc_qpel_uni_w, 1, 1, qpel_uni_w_hv,);
if (have_i8mm(cpu_flags)) {
NEON8_FNASSIGN(c->put_hevc_epel, 0, 1, epel_h, _i8mm);
diff --git a/libavcodec/aarch64/hevcdsp_qpel_neon.S
b/libavcodec/aarch64/hevcdsp_qpel_neon.S
index f285ab7461..df7032b692 100644
--- a/libavcodec/aarch64/hevcdsp_qpel_neon.S
+++ b/libavcodec/aarch64/hevcdsp_qpel_neon.S
@@ -4164,7 +4164,7 @@ qpel_hv neon_i8mm
DISABLE_I8MM
#endif
-.macro QPEL_UNI_W_HV_HEADER width
+.macro QPEL_UNI_W_HV_HEADER width, suffix
ldp x14, x15, [sp] // mx, my
ldr w13, [sp, #16] // width
stp x19, x30, [sp, #-80]!
@@ -4173,7 +4173,7 @@ DISABLE_I8MM
stp x24, x25, [sp, #48]
stp x26, x27, [sp, #64]
mov x19, sp
-mov x11, #9088
+mov x11, #(MAX_PB_SIZE*(MAX_PB_SIZE+8)*2)
sub sp, sp, x11
mov x20, x0
mov x21, x1
@@ -4190,7 +4190,16 @@ DISABLE_I8MM
mov w26, #-6
sub w26, w26, w5// -shift
mov w27, w13// width
-bl X(ff_hevc_put_hevc_qpel_h\width\()_8_neon_i8mm)
+.ifc \suffix, neon
+.if \width >= 32
+mov w6, #\width
+bl X(ff_hevc_put_hevc_qpel_h32_8_neon)
+.else
+bl X(ff_hevc_put_hevc_qpel_h\width\()_8_\suffix)
+.endif
+.else
+bl X(ff_hevc_put_hevc_qpel_h\width\()_8_\suffix)
+.endif
movrel x9, qpel_filters
add x9, x9, x23, lsl #3
ld1 {v0.8b}, [x9]
@@ -4552,33 +4561,39 @@ function hevc_put_hevc_qpel_uni_w_hv16_8_end_neon
ret
endfunc
-#if HAVE_I8MM
-ENABLE_I8MM
-
-function ff_hevc_put_hevc_qpel_uni_w_hv4_8_neon_i8mm, export=1
-QPEL_UNI_W_HV_HEADER 4
+.macro qpel_uni_w_hv suffix
+function ff_hevc_put_hevc_qpel_uni_w_hv4_8_\suffix, export=1
+QPEL_UNI_W_HV_HEADER 4, \suffix
b hevc_put_hevc_qpel_uni_w_hv4_8_end_neon
endfunc
-function ff_hevc_put_hevc_qpel_uni_w_hv8_8_neon_i8mm, export=1
-QPEL_UNI_W_HV_HEADER 8
+function ff_hevc_put_hevc_qpel_uni_w_hv8_8_\suffix, export=1
+QPEL_UNI_W_HV_HEADER 8, \suffix
b hevc_put_hevc_qpel_uni_w_hv8_8_end_neon
endfunc
-function ff_hevc_put_hevc_qpel_uni_w_hv16_8_neon_i8mm, export=1
-QPEL_UNI_W_HV_HEADER 16
+function ff_hevc_put_hevc_qpel_uni_w_hv16_8_\suffix, export=1
+QPEL_UNI_W_HV_HEADER 16, \suffix
b hevc_put_hevc_qpel_uni_w_hv16_8_end_neon
endfunc
-function ff_hevc_put_hevc_qpel_uni_w_hv32_8_neon_i8mm, export=1
-QPEL_UNI_W_HV_HEADER 32
+function ff_hevc_put_hevc_qpel_uni_w_hv32_8_\suffix, export=1
+QPEL_UNI_W_HV_HEADER 32, \suffix
b hevc_put_hevc_qpel_uni_w_hv16_8_end_neon
endfunc
-funct
[FFmpeg-devel] [PATCH 21/21] aarch64: hevc: Produce plain neon versions of qpel_bi_hv
As the plain neon qpel_h functions process two rows at a time,
we need to allocate storage for h+8 rows instead of h+7.
By allocating storage for h+8 rows, incrementing the stack
pointer won't end up at the right spot in the end. Store the
intended final stack pointer value in a register x14 which we
store on the stack.
AWS Graviton 3:
put_hevc_qpel_bi_hv4_8_c: 385.7
put_hevc_qpel_bi_hv4_8_neon: 131.0
put_hevc_qpel_bi_hv4_8_i8mm: 92.2
put_hevc_qpel_bi_hv6_8_c: 701.0
put_hevc_qpel_bi_hv6_8_neon: 239.5
put_hevc_qpel_bi_hv6_8_i8mm: 191.0
put_hevc_qpel_bi_hv8_8_c: 1162.0
put_hevc_qpel_bi_hv8_8_neon: 228.0
put_hevc_qpel_bi_hv8_8_i8mm: 225.2
put_hevc_qpel_bi_hv12_8_c: 2305.0
put_hevc_qpel_bi_hv12_8_neon: 558.0
put_hevc_qpel_bi_hv12_8_i8mm: 483.2
put_hevc_qpel_bi_hv16_8_c: 3965.2
put_hevc_qpel_bi_hv16_8_neon: 732.7
put_hevc_qpel_bi_hv16_8_i8mm: 656.5
put_hevc_qpel_bi_hv24_8_c: 8709.7
put_hevc_qpel_bi_hv24_8_neon: 1555.2
put_hevc_qpel_bi_hv24_8_i8mm: 1448.7
put_hevc_qpel_bi_hv32_8_c: 14818.0
put_hevc_qpel_bi_hv32_8_neon: 2763.7
put_hevc_qpel_bi_hv32_8_i8mm: 2468.0
put_hevc_qpel_bi_hv48_8_c: 32855.5
put_hevc_qpel_bi_hv48_8_neon: 6107.2
put_hevc_qpel_bi_hv48_8_i8mm: 5452.7
put_hevc_qpel_bi_hv64_8_c: 57591.5
put_hevc_qpel_bi_hv64_8_neon: 10660.2
put_hevc_qpel_bi_hv64_8_i8mm: 9580.0
---
libavcodec/aarch64/hevcdsp_init_aarch64.c | 5 +
libavcodec/aarch64/hevcdsp_qpel_neon.S| 164 +-
2 files changed, 103 insertions(+), 66 deletions(-)
diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index e9ee901322..e24dd0cbda 100644
--- a/libavcodec/aarch64/hevcdsp_init_aarch64.c
+++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c
@@ -319,6 +319,10 @@ NEON8_FNPROTO(qpel_bi_v, (uint8_t *dst, ptrdiff_t
dststride,
const uint8_t *src, ptrdiff_t srcstride, const int16_t *src2,
int height, intptr_t mx, intptr_t my, int width),);
+NEON8_FNPROTO(qpel_bi_hv, (uint8_t *dst, ptrdiff_t dststride,
+const uint8_t *src, ptrdiff_t srcstride, const int16_t *src2,
+int height, intptr_t mx, intptr_t my, int width),);
+
NEON8_FNPROTO(qpel_bi_hv, (uint8_t *dst, ptrdiff_t dststride,
const uint8_t *src, ptrdiff_t srcstride, const int16_t *src2,
int height, intptr_t mx, intptr_t my, int width), _i8mm);
@@ -452,6 +456,7 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c,
const int bit_depth)
NEON8_FNASSIGN(c->put_hevc_qpel, 1, 1, qpel_hv,);
NEON8_FNASSIGN(c->put_hevc_qpel_uni, 1, 1, qpel_uni_hv,);
NEON8_FNASSIGN_PARTIAL_5(c->put_hevc_qpel_uni_w, 1, 1, qpel_uni_w_hv,);
+NEON8_FNASSIGN(c->put_hevc_qpel_bi, 1, 1, qpel_bi_hv,);
if (have_i8mm(cpu_flags)) {
NEON8_FNASSIGN(c->put_hevc_epel, 0, 1, epel_h, _i8mm);
diff --git a/libavcodec/aarch64/hevcdsp_qpel_neon.S
b/libavcodec/aarch64/hevcdsp_qpel_neon.S
index df7032b692..8ddaa32b70 100644
--- a/libavcodec/aarch64/hevcdsp_qpel_neon.S
+++ b/libavcodec/aarch64/hevcdsp_qpel_neon.S
@@ -4590,14 +4590,6 @@ endfunc
qpel_uni_w_hv neon
-#if HAVE_I8MM
-ENABLE_I8MM
-
-qpel_uni_w_hv neon_i8mm
-
-DISABLE_I8MM
-#endif
-
function hevc_put_hevc_qpel_bi_hv4_8_end_neon
mov x9, #(MAX_PB_SIZE * 2)
load_qpel_filterh x7, x6
@@ -4620,7 +4612,8 @@ function hevc_put_hevc_qpel_bi_hv4_8_end_neon
.endm
1: calc_all
.purgem calc
-2: ret
+2: mov sp, x14
+ret
endfunc
function hevc_put_hevc_qpel_bi_hv6_8_end_neon
@@ -4650,7 +4643,8 @@ function hevc_put_hevc_qpel_bi_hv6_8_end_neon
.endm
1: calc_all
.purgem calc
-2: ret
+2: mov sp, x14
+ret
endfunc
function hevc_put_hevc_qpel_bi_hv8_8_end_neon
@@ -4678,7 +4672,8 @@ function hevc_put_hevc_qpel_bi_hv8_8_end_neon
.endm
1: calc_all
.purgem calc
-2: ret
+2: mov sp, x14
+ret
endfunc
function hevc_put_hevc_qpel_bi_hv16_8_end_neon
@@ -4723,83 +4718,87 @@ function hevc_put_hevc_qpel_bi_hv16_8_end_neon
subsx10, x10, #16
add x4, x4, #32
b.ne0b
-add w10, w5, #7
-lsl x10, x10, #7
-sub x10, x10, x6, lsl #1 // part of first line
-add sp, sp, x10 // tmp_array without first line
+mov sp, x14
ret
endfunc
-#if HAVE_I8MM
-ENABLE_I8MM
-
-function ff_hevc_put_hevc_qpel_bi_hv4_8_neon_i8mm, export=1
-add w10, w5, #7
+.macro qpel_bi_hv suffix
+function ff_hevc_put_hevc_qpel_bi_hv4_8_\suffix, export=1
+add w10, w5, #8
lsl x10, x10, #7
+mov x14, sp
sub sp, sp, x10 // tmp_array
-stp x7, x30, [sp, #-48]!
+stp x7, x30, [sp, #-64]!
stp x4, x5, [sp, #16]
stp x0, x1, [sp, #32]
+str x14,[sp, #4
Re: [FFmpeg-devel] [PATCH v2] avfilter: propagate colorspace and color_range from buffer filter and between AVFilterLink.
On Mon, 25 Mar 2024 16:02:23 +0100 Niklas Haas wrote:
> On Mon, 25 Mar 2024 15:36:26 +0100 Damiano Galassi wrote:
> > On Mon, Mar 25, 2024 at 2:40 PM Niklas Haas wrote:
> >
> > > > ffmpeg -i in.mp4 -vf
> > > > "scale='width=1920:height=1080',zscale='width=1920:height=1080'" out.mp4
> > > > ffmpeg -i in.jpg -vf "zscale='width=1920:height=1080'" out.jpg
> > > >
> > > > it doesn't need a specific mp4 or jpg file.
> > >
> > > I cannot reproduce any error with your first command line.
> >
> >
> > here's a sample file, and the output I get:
> >
> > https://subler.org/downloads/test.mp4
> > https://gist.github.com/galad87/a6ddc3318cf20cd2f1ac7d053e1a0786
>
> Okay, I see the problem. Basically, swap_color_spaces() doesn't re-run
> after pick_formats() settles a filter's format. So swap_color_spaces()
> never actually sets zscale's preferred output format, because at that
> point there are still multiple options for swscale's output format.
>
> This patch appears to help, but I'm honestly not sure what exactly the
> difference is between this REDUCE_FORMATS() and swap_color_spaces(), or
> actually, for what case the latter even exists.
I *think* that the former is intended for picking an exact match,
whereas the latter is intended for picking the *best* remaining match
(where bestness can be meaningfully measured by some score)
So based on this, given that csp/range is only concerned with exact
matches, after the suggest patch we can just delete swap_color_spaces()
and swap_color_ranges(). Good riddance, too.
>
> diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
> index bb5399c55e8..3b8f7464889 100644
> --- a/libavfilter/avfiltergraph.c
> +++ b/libavfilter/avfiltergraph.c
> @@ -794,6 +794,10 @@ static int reduce_formats_on_filter(AVFilterContext
> *filter)
> nb_formats, ff_add_format);
> REDUCE_FORMATS(int, AVFilterFormats,samplerates,
> formats,
> nb_formats, ff_add_format);
> +REDUCE_FORMATS(int, AVFilterFormats,color_spaces,
> formats,
> + nb_formats, ff_add_format);
> +REDUCE_FORMATS(int, AVFilterFormats,color_ranges,
> formats,
> + nb_formats, ff_add_format);
>
> /* reduce channel layouts */
> for (i = 0; i < filter->nb_inputs; i++) {
___
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: properly reduce YUV colorspace format lists
From: Niklas Haas
Doing this with REDUCE_FORMATS() instead of swap_color_*() is not only
shorter, but more importantly comes with the benefit of being done
inside a loop, allowing us to correctly propagate complex graphs
involving multiple conversion filters (e.g. -vf scale,zscale).
The latter family of swapping functions is only used to settle the
best *remaining* entry if no exact match was found, and as such was
never the correct solution to YUV colorspaces, which only care about
exact matches.
---
libavfilter/avfiltergraph.c | 84 ++---
1 file changed, 4 insertions(+), 80 deletions(-)
diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
index bb5399c55e8..12ff7d6ffb9 100644
--- a/libavfilter/avfiltergraph.c
+++ b/libavfilter/avfiltergraph.c
@@ -794,6 +794,10 @@ static int reduce_formats_on_filter(AVFilterContext
*filter)
nb_formats, ff_add_format);
REDUCE_FORMATS(int, AVFilterFormats,samplerates, formats,
nb_formats, ff_add_format);
+REDUCE_FORMATS(int, AVFilterFormats,color_spaces,formats,
+ nb_formats, ff_add_format);
+REDUCE_FORMATS(int, AVFilterFormats,color_ranges,formats,
+ nb_formats, ff_add_format);
/* reduce channel layouts */
for (i = 0; i < filter->nb_inputs; i++) {
@@ -906,82 +910,6 @@ static void swap_samplerates(AVFilterGraph *graph)
swap_samplerates_on_filter(graph->filters[i]);
}
-static void swap_color_spaces_on_filter(AVFilterContext *filter)
-{
-AVFilterLink *link = NULL;
-enum AVColorSpace csp;
-int i;
-
-for (i = 0; i < filter->nb_inputs; i++) {
-link = filter->inputs[i];
-if (link->type == AVMEDIA_TYPE_VIDEO &&
-link->outcfg.color_spaces->nb_formats == 1)
-break;
-}
-if (i == filter->nb_inputs)
-return;
-
-csp = link->outcfg.color_spaces->formats[0];
-
-for (i = 0; i < filter->nb_outputs; i++) {
-AVFilterLink *outlink = filter->outputs[i];
-if (outlink->type != AVMEDIA_TYPE_VIDEO)
-continue;
-/* there is no meaningful 'score' between different yuv matrices,
- * so just prioritize an exact match if it exists */
-for (int j = 0; j < outlink->incfg.color_spaces->nb_formats; j++) {
-if (csp == outlink->incfg.color_spaces->formats[j]) {
-FFSWAP(int, outlink->incfg.color_spaces->formats[0],
- outlink->incfg.color_spaces->formats[j]);
-break;
-}
-}
-}
-}
-
-static void swap_color_spaces(AVFilterGraph *graph)
-{
-for (int i = 0; i < graph->nb_filters; i++)
-swap_color_spaces_on_filter(graph->filters[i]);
-}
-
-static void swap_color_ranges_on_filter(AVFilterContext *filter)
-{
-AVFilterLink *link = NULL;
-enum AVColorRange range;
-int i;
-
-for (i = 0; i < filter->nb_inputs; i++) {
-link = filter->inputs[i];
-if (link->type == AVMEDIA_TYPE_VIDEO &&
-link->outcfg.color_ranges->nb_formats == 1)
-break;
-}
-if (i == filter->nb_inputs)
-return;
-
-range = link->outcfg.color_ranges->formats[0];
-
-for (i = 0; i < filter->nb_outputs; i++) {
-AVFilterLink *outlink = filter->outputs[i];
-if (outlink->type != AVMEDIA_TYPE_VIDEO)
-continue;
-for (int j = 0; j < outlink->incfg.color_ranges->nb_formats; j++) {
-if (range == outlink->incfg.color_ranges->formats[j]) {
-FFSWAP(int, outlink->incfg.color_ranges->formats[0],
- outlink->incfg.color_ranges->formats[j]);
-break;
-}
-}
-}
-}
-
-static void swap_color_ranges(AVFilterGraph *graph)
-{
-for (int i = 0; i < graph->nb_filters; i++)
-swap_color_ranges_on_filter(graph->filters[i]);
-}
-
#define CH_CENTER_PAIR (AV_CH_FRONT_LEFT_OF_CENTER |
AV_CH_FRONT_RIGHT_OF_CENTER)
#define CH_FRONT_PAIR (AV_CH_FRONT_LEFT | AV_CH_FRONT_RIGHT)
#define CH_STEREO_PAIR (AV_CH_STEREO_LEFT | AV_CH_STEREO_RIGHT)
@@ -1258,10 +1186,6 @@ static int graph_config_formats(AVFilterGraph *graph,
void *log_ctx)
if ((ret = reduce_formats(graph)) < 0)
return ret;
-/* for video filters, ensure that the best colorspace metadata is selected
*/
-swap_color_spaces(graph);
-swap_color_ranges(graph);
-
/* for audio filters, ensure the best format, sample rate and channel
layout
* is selected */
swap_sample_fmts(graph);
--
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] avfilter: fix YUV colorspace negotiation for YUVJ
On Mon, 25 Mar 2024 14:40:44 +0100 Niklas Haas wrote: > From: Niklas Haas > > Ironically, despite being introduced to make YUVJ unnecessary, the new > YUV negotiation logic failed to actually negotiate YUVJ formats > themselves correctly, leading to errors when passing YUVJ frames into > a filter graph. (They were effectively treated like RGB or Grayscale > formats, rather than as forced-full-range YUV, and hence did not have > their colorspace matrix correctly negotiated) > > Fix this by splitting off the YUVJ check from ff_fmt_is_regular_yuv(). > Obviously, we can trivially undo this change again once YUVJ is actually > deleted from the codebase. Breaks FATE, I will investigate. ___ 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 12/12] avutil/opt: Don't cast when the result might be misaligned
A pointer conversion is UB if the resulting pointer is not
correctly aligned for the resultant type, even if no
load/store is ever performed through that pointer (C11 6.3.2.3 (7)).
This may happen in opt_copy_elem(), because the pointers are
converted even when they belong to a type that does not guarantee
sufficient alignment.
Fix this by deferring the cast after having checked the type.
Also make the casts -Wcast-qual safe and avoid an indirection
for src.
Signed-off-by: Andreas Rheinhardt
---
libavutil/opt.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index 3130606337..5fa8870707 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -2028,18 +2028,19 @@ void *av_opt_ptr(const AVClass *class, void *obj, const
char *name)
static int opt_copy_elem(void *logctx, enum AVOptionType type,
void *dst, const void *src)
{
-uint8_t **dst8 = (uint8_t **)dst;
-const uint8_t **src8 = (const uint8_t **)src;
-
if (type == AV_OPT_TYPE_STRING) {
-if (*dst8 != *src8)
-av_freep(dst8);
-if (*src8) {
-*dst8 = av_strdup(*src8);
-if (!*dst8)
+const char *src_str = *(const char *const *)src;
+char **dstp = (char **)dst;
+if (*dstp != src_str)
+av_freep(dstp);
+if (src_str) {
+*dstp = av_strdup(src_str);
+if (!*dstp)
return AVERROR(ENOMEM);
}
} else if (type == AV_OPT_TYPE_BINARY) {
+const uint8_t *const *src8 = (const uint8_t *const *)src;
+uint8_t **dst8 = (uint8_t **)dst;
int len = *(const int *)(src8 + 1);
if (*dst8 != *src8)
av_freep(dst8);
@@ -2052,12 +2053,12 @@ static int opt_copy_elem(void *logctx, enum
AVOptionType type,
} else if (type == AV_OPT_TYPE_CONST) {
// do nothing
} else if (type == AV_OPT_TYPE_DICT) {
-AVDictionary **sdict = (AVDictionary **)src;
-AVDictionary **ddict = (AVDictionary **)dst;
-if (*sdict != *ddict)
-av_dict_free(ddict);
-*ddict = NULL;
-return av_dict_copy(ddict, *sdict, 0);
+const AVDictionary *sdict = *(const AVDictionary * const *)src;
+AVDictionary **ddictp = (AVDictionary **)dst;
+if (sdict != *ddictp)
+av_dict_free(ddictp);
+*ddictp = NULL;
+return av_dict_copy(ddictp, sdict, 0);
} else if (type == AV_OPT_TYPE_CHLAYOUT) {
if (dst != src)
return av_channel_layout_copy(dst, src);
--
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] [PATCH 13/13] fftools/ffmpeg_mux_init: Fix double-free on error
MATCH_PER_STREAM_OPT iterates over all options of a given
OptionDef and tests whether they apply to the current stream;
if so, they are set to ost->apad, otherwise, the code errors
out. If no error happens, ost->apad is av_strdup'ed in order
to take ownership of this pointer.
But this means that setting it originally was premature,
as it leads to double-frees when an error happens lateron.
This can simply be reproduced with
ffmpeg -filter_complex anullsrc -apad bar -apad:n baz -f null -
This is a regression since 83ace80bfd80fcdba2c65fa1d554923ea931d5bd.
Fix this by using a temporary variable instead of directly
setting ost->apad. Also only strdup the string if it actually
is != NULL.
Signed-off-by: Andreas Rheinhardt
---
fftools/ffmpeg_mux_init.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 818d76acda..83ddb21844 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -832,6 +832,7 @@ static int new_stream_audio(Muxer *mux, const
OptionsContext *o,
int channels = 0;
char *layout = NULL;
char *sample_fmt = NULL;
+const char *apad = NULL;
MATCH_PER_STREAM_OPT(audio_channels, i, channels, oc, st);
if (channels) {
@@ -854,8 +855,12 @@ static int new_stream_audio(Muxer *mux, const
OptionsContext *o,
MATCH_PER_STREAM_OPT(audio_sample_rate, i, audio_enc->sample_rate, oc,
st);
-MATCH_PER_STREAM_OPT(apad, str, ost->apad, oc, st);
-ost->apad = av_strdup(ost->apad);
+MATCH_PER_STREAM_OPT(apad, str, apad, oc, st);
+if (apad) {
+ost->apad = av_strdup(apad);
+if (!ost->apad)
+return AVERROR(ENOMEM);
+}
}
return 0;
--
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] [PATCH 14/14] avutil/avstring: Avoid av_strdup(NULL)
Signed-off-by: Andreas Rheinhardt --- libavutil/avstring.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/avstring.c b/libavutil/avstring.c index 2071dd36a5..8702fe0455 100644 --- a/libavutil/avstring.c +++ b/libavutil/avstring.c @@ -299,7 +299,7 @@ char *av_append_path_component(const char *path, const char *component) char *fullpath; if (!path) -return av_strdup(component); +return component ? av_strdup(component) : NULL; if (!component) return av_strdup(path); -- 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] avformat/mov_chan: Use anonymous union
On Mon, Mar 25, 2024 at 4:01 PM Andreas Rheinhardt wrote: > > Right, it is an anonymous enum, not union. Amended locally. > > - Andreas Can confirm this eliminates the warnings, lgtm. ___ 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] Added alpha layer support for smartblur
On 3/25/24 9:49 AM, Andrea Mastroberti wrote:
Signed-off-by: Andrea Mastroberti <10736...@polimi.it>
---
doc/filters.texi | 20 -
libavfilter/version.h | 2 +-
libavfilter/vf_smartblur.c | 44 ++
3 files changed, 55 insertions(+), 11 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 913365671d..30b3627724 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -22688,9 +22688,27 @@ whether a pixel should be blurred or not. The
option value must be an
integer in the range [-30,30]. A value of 0 will filter all the image,
a value included in [0,30] will filter flat areas and a value included
in [-30,0] will filter edges. Default value is @option{luma_threshold}.
+
+@item alpha_radius, ar
+Set the alpha radius. The option value must be a float number in
+the range [0.1,5.0] that specifies the variance of the gaussian filter
+used to blur the image (slower if larger). Default value is 1.0.
+
+@item alpha_strength, as
+Set the alpha strength. The option value must be a float number
+in the range [-1.0,1.0] that configures the blurring. A value included
+in [0.0,1.0] will blur the image whereas a value included in
+[-1.0,0.0] will sharpen the image. Default value is 1.0.
+
+@item alpha_threshold, at
+Set the alpha threshold used as a coefficient to determine
+whether a pixel should be blurred or not. The option value must be an
+integer in the range [-30,30]. A value of 0 will filter all the image,
+a value included in [0,30] will filter flat areas and a value included
+in [-30,0] will filter edges. Default value is 0.
@end table
-If a chroma option is not explicitly set, the corresponding luma value
+If a chroma or alpha option is not explicitly set, the corresponding
luma value
is set.
@section sobel
diff --git a/libavfilter/version.h b/libavfilter/version.h
index d5a6bc143a..f01b3f8e91 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -32,7 +32,7 @@
#include "version_major.h"
#define LIBAVFILTER_VERSION_MINOR 0
-#define LIBAVFILTER_VERSION_MICRO 100
+#define LIBAVFILTER_VERSION_MICRO 101
#define LIBAVFILTER_VERSION_INT
AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
diff --git a/libavfilter/vf_smartblur.c b/libavfilter/vf_smartblur.c
index ae0ec05b2d..bc377d0b92 100644
--- a/libavfilter/vf_smartblur.c
+++ b/libavfilter/vf_smartblur.c
@@ -54,6 +54,7 @@ typedef struct SmartblurContext {
const AVClass *class;
FilterParam luma;
FilterParam chroma;
+ FilterParam alpha;
int hsub;
int vsub;
unsigned int sws_flags;
@@ -77,6 +78,13 @@ static const AVOption smartblur_options[] = {
{ "chroma_threshold", "set chroma threshold",
OFFSET(chroma.threshold), AV_OPT_TYPE_INT, {.i64=THRESHOLD_MIN-1},
THRESHOLD_MIN-1, THRESHOLD_MAX, .flags=FLAGS },
{ "ct", "set chroma threshold",
OFFSET(chroma.threshold), AV_OPT_TYPE_INT, {.i64=THRESHOLD_MIN-1},
THRESHOLD_MIN-1, THRESHOLD_MAX, .flags=FLAGS },
+ { "alpha_radius", "set alpha radius", OFFSET(alpha.radius),
AV_OPT_TYPE_FLOAT, {.dbl=1.0}, RADIUS_MIN, RADIUS_MAX, .flags=FLAGS },
+ { "ar" , "set alpha radius", OFFSET(alpha.radius),
AV_OPT_TYPE_FLOAT, {.dbl=1.0}, RADIUS_MIN, RADIUS_MAX, .flags=FLAGS },
+ { "alpha_strength", "set alpha strength",
OFFSET(alpha.strength), AV_OPT_TYPE_FLOAT, {.dbl=1.0}, STRENGTH_MIN,
STRENGTH_MAX, .flags=FLAGS },
+ { "as", "set alpha strength", OFFSET(alpha.strength),
AV_OPT_TYPE_FLOAT, {.dbl=1.0}, STRENGTH_MIN, STRENGTH_MAX,
.flags=FLAGS },
+ { "alpha_threshold", "set alpha threshold",
OFFSET(alpha.threshold), AV_OPT_TYPE_INT, {.i64=0}, THRESHOLD_MIN,
THRESHOLD_MAX, .flags=FLAGS },
+ { "at", "set alpha threshold",
OFFSET(alpha.threshold), AV_OPT_TYPE_INT, {.i64=0}, THRESHOLD_MIN,
THRESHOLD_MAX, .flags=FLAGS },
+
{ NULL }
};
@@ -86,7 +94,7 @@ static av_cold int init(AVFilterContext *ctx)
{
SmartblurContext *s = ctx->priv;
- /* make chroma default to luma values, if not explicitly set */
+ /* make chroma and alpha default to luma values, if not
explicitly set */
if (s->chroma.radius < RADIUS_MIN)
s->chroma.radius = s->luma.radius;
if (s->chroma.strength < STRENGTH_MIN)
@@ -94,15 +102,23 @@ static av_cold int init(AVFilterContext *ctx)
if (s->chroma.threshold < THRESHOLD_MIN)
s->chroma.threshold = s->luma.threshold;
- s->luma.quality = s->chroma.quality = 3.0;
+ if (s->alpha.radius < RADIUS_MIN)
+ s->alpha.radius = s->alpha.radius;
+ if (s->alpha.strength < STRENGTH_MIN)
+ s->alpha.strength = s->alpha.strength;
+ if (s->alpha.threshold < THRESHOLD_MIN)
+ s->alpha.threshold = s->alpha.threshold;
+
+ s->luma.quality = s->chroma.quality = s->alpha.quality = 3.0;
s->sws_flags = SWS_BICUBIC;
av_log(ctx, AV_LOG_VERBOSE,
"luma_radius:%f luma_strength:%f luma_threshold:%d "
Re: [FFmpeg-devel] [PATCH 14/14] avutil/avstring: Avoid av_strdup(NULL)
On Mon, Mar 25, 2024 at 12:38 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote: > Signed-off-by: Andreas Rheinhardt > --- > libavutil/avstring.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavutil/avstring.c b/libavutil/avstring.c > index 2071dd36a5..8702fe0455 100644 > --- a/libavutil/avstring.c > +++ b/libavutil/avstring.c > @@ -299,7 +299,7 @@ char *av_append_path_component(const char *path, const > char *component) > char *fullpath; > > if (!path) > -return av_strdup(component); > +return component ? av_strdup(component) : NULL; > if (!component) > return av_strdup(path); > isn't this what av_strdup already does? -- Vittorio ___ 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/14] avutil/avstring: Avoid av_strdup(NULL)
Vittorio Giovara:
> On Mon, Mar 25, 2024 at 12:38 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavutil/avstring.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavutil/avstring.c b/libavutil/avstring.c
>> index 2071dd36a5..8702fe0455 100644
>> --- a/libavutil/avstring.c
>> +++ b/libavutil/avstring.c
>> @@ -299,7 +299,7 @@ char *av_append_path_component(const char *path, const
>> char *component)
>> char *fullpath;
>>
>> if (!path)
>> -return av_strdup(component);
>> +return component ? av_strdup(component) : NULL;
>> if (!component)
>> return av_strdup(path);
>>
>
> isn't this what av_strdup already does?
It's not documented to do so. It could also decide to treat
av_strdup(NULL) as av_strdup("").
- 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/3] avformat/wady: Check >0 samplerate and channels 1 || 2.
On Wed, Mar 20, 2024 at 03:19:24AM +0100, Michael Niedermayer wrote: > The WADY decoder only supports mono and stereo > > This fixes a probetest failure > > Signed-off-by: Michael Niedermayer > --- > libavformat/wady.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) will apply patch 1 and 2 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: PGP signature ___ 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/vf_colorspace: use colorspace negotiation API
Fixes a regression due to the fact that the colorspace filter does
not use the new API introduced by 8c7934f73ab6c568acaa.
The scale filter uses it since 45e09a30419cc2a7251e, and the setparams
filter since 3bf80df3ccd32aed23f0.
Example:
ffmpeg -f lavfi -i testsrc -vf setparams=color_primaries=bt470bg:
color_trc=smpte170m:colorspace=bt470bg,colorspace=bt709:range=tv,scale
,showinfo -f null -frames 1 -
Before:
color_range:unknown color_space:unknown color_primaries:bt709 ...
After:
color_range:tv color_space:bt709 color_primaries:bt709 ...
There is still an issue with the color_range when it is not specified:
the documentation states the output defaults to the same value as the
input, but it does not seem possible to implement currently.
Signed-off-by: Nicolas Gaullier
---
libavfilter/vf_colorspace.c | 62 +
1 file changed, 36 insertions(+), 26 deletions(-)
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index f367ce17c6..b1e1b9b719 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -432,8 +432,7 @@ static int create_filtergraph(AVFilterContext *ctx,
if (out->color_trc != s->out_trc) s->out_txchr = NULL;
if (in->colorspace != s->in_csp ||
in->color_range != s->in_rng) s->in_lumacoef = NULL;
-if (out->colorspace != s->out_csp ||
-out->color_range != s->out_rng) s->out_lumacoef = NULL;
+if (out->color_range != s->out_rng) s->rgb2yuv = NULL;
if (!s->out_primaries || !s->in_primaries) {
s->in_prm = in->color_primaries;
@@ -562,26 +561,8 @@ static int create_filtergraph(AVFilterContext *ctx,
redo_yuv2rgb = 1;
}
-if (!s->out_lumacoef) {
-s->out_csp = out->colorspace;
+if (!s->rgb2yuv) {
s->out_rng = out->color_range;
-s->out_lumacoef = av_csp_luma_coeffs_from_avcsp(s->out_csp);
-if (!s->out_lumacoef) {
-if (s->out_csp == AVCOL_SPC_UNSPECIFIED) {
-if (s->user_all == CS_UNSPECIFIED) {
-av_log(ctx, AV_LOG_ERROR,
- "Please specify output colorspace\n");
-} else {
-av_log(ctx, AV_LOG_ERROR,
- "Unsupported output color property %d\n",
s->user_all);
-}
-} else {
-av_log(ctx, AV_LOG_ERROR,
- "Unsupported output colorspace %d (%s)\n", s->out_csp,
- av_color_space_name(s->out_csp));
-}
-return AVERROR(EINVAL);
-}
redo_rgb2yuv = 1;
}
@@ -686,6 +667,26 @@ static av_cold int init(AVFilterContext *ctx)
{
ColorSpaceContext *s = ctx->priv;
+s->out_csp = s->user_csp == AVCOL_SPC_UNSPECIFIED ?
+ default_csp[FFMIN(s->user_all, CS_NB)] : s->user_csp;
+s->out_lumacoef = av_csp_luma_coeffs_from_avcsp(s->out_csp);
+if (!s->out_lumacoef) {
+if (s->out_csp == AVCOL_SPC_UNSPECIFIED) {
+if (s->user_all == CS_UNSPECIFIED) {
+av_log(ctx, AV_LOG_ERROR,
+ "Please specify output colorspace\n");
+} else {
+av_log(ctx, AV_LOG_ERROR,
+ "Unsupported output color property %d\n", s->user_all);
+}
+} else {
+av_log(ctx, AV_LOG_ERROR,
+ "Unsupported output colorspace %d (%s)\n", s->out_csp,
+ av_color_space_name(s->out_csp));
+}
+return AVERROR(EINVAL);
+}
+
ff_colorspacedsp_init(&s->dsp);
return 0;
@@ -745,10 +746,10 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
} else {
out->color_trc = s->user_trc;
}
-out->colorspace = s->user_csp == AVCOL_SPC_UNSPECIFIED ?
- default_csp[FFMIN(s->user_all, CS_NB)] :
s->user_csp;
-out->color_range = s->user_rng == AVCOL_RANGE_UNSPECIFIED ?
- in->color_range : s->user_rng;
+// FIXME color_range must be set in query_formats for negotiation.
+// The value updated here will not be propagated further in the graph.
+if (s->user_rng == AVCOL_RANGE_UNSPECIFIED)
+out->color_range = outlink->color_range = in->color_range;
if (rgb_sz != s->rgb_sz) {
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(out->format);
int uvw = in->width >> desc->log2_chroma_w;
@@ -838,10 +839,19 @@ static int query_formats(AVFilterContext *ctx)
AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
AV_PIX_FMT_NONE
};
-int res;
+int res, ret;
ColorSpaceContext *s = ctx->priv;
+AVFilterLink *outlink = ctx->outputs[0];
AVFilterFormats *formats = ff_make_format_list(pix_fmts);
+if (ret = ff_formats_ref(ff_make_formats_list_singleton(s->out_csp),
+ &outlink->incfg.c
Re: [FFmpeg-devel] [PATCH] avfilter/vf_stack: round down internal item heights
On 23/03/2024 16:30, Timo Rothenpieler wrote:
Following situation:
Someone wants to stack two yuv420p frames of the size 3x3 pixel each.
Now the various AV_CEIL_RSHIFT() calculations calculate a height of 2
pixel for each items subsampled planes.
However, for example in case of a vstack, the output frames will have a
height of 6, so the subsampled planes one of 3.
When the filter now tries to stack two items with a rounded-up height of
2 into a frame with a height of 3, it'll write an entire extra line past
the end of a buffer.
This patch instead rounds down all the item heights, to avoid this
situation. It's not ideal either, since now lines might be missed. But
that is definitely preferable over writing past the end of the
bufferThis patch instead rounds down all the item heights, to avoid this
situation. It's not ideal either, since now lines might be missed. But
that is definitely preferable over writing past the end of the buffer.
---
libavfilter/vf_stack.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_stack.c b/libavfilter/vf_stack.c
index 2bb3d9b1d2..46e7d6b7f5 100644
--- a/libavfilter/vf_stack.c
+++ b/libavfilter/vf_stack.c
@@ -220,11 +220,11 @@ static int config_output(AVFilterLink *outlink)
return ret;
}
-item->height[1] = item->height[2] = AV_CEIL_RSHIFT(inlink->h, s->desc->log2_chroma_h);
+item->height[1] = item->height[2] = inlink->h / (1 <<
s->desc->log2_chroma_h);
item->height[0] = item->height[3] = inlink->h;
if (i) {
-item->y[1] = item->y[2] = AV_CEIL_RSHIFT(height,
s->desc->log2_chroma_h);
+item->y[1] = item->y[2] = height / (1 <<
s->desc->log2_chroma_h);
item->y[0] = item->y[3] = height;
height += ctx->inputs[i]->h;
@@ -244,7 +244,7 @@ static int config_output(AVFilterLink *outlink)
return ret;
}
-item->height[1] = item->height[2] = AV_CEIL_RSHIFT(inlink->h, s->desc->log2_chroma_h);
+item->height[1] = item->height[2] = inlink->h / (1 <<
s->desc->log2_chroma_h);
item->height[0] = item->height[3] = inlink->h;
if (i) {
@@ -278,14 +278,14 @@ static int config_output(AVFilterLink *outlink)
return ret;
}
-item->height[1] = item->height[2] = AV_CEIL_RSHIFT(inlink->h, s->desc->log2_chroma_h);
+item->height[1] = item->height[2] = inlink->h / (1 <<
s->desc->log2_chroma_h);
item->height[0] = item->height[3] = inlink->h;
if ((ret = av_image_fill_linesizes(item->x, inlink->format, inw)) < 0) {
return ret;
}
-item->y[1] = item->y[2] = AV_CEIL_RSHIFT(inh, s->desc->log2_chroma_h);
+item->y[1] = item->y[2] = inh / (1 << s->desc->log2_chroma_h);
item->y[0] = item->y[3] = inh;
inw += ctx->inputs[k]->w;
}
@@ -322,7 +322,7 @@ static int config_output(AVFilterLink *outlink)
return ret;
}
-item->height[1] = item->height[2] = AV_CEIL_RSHIFT(inlink->h, s->desc->log2_chroma_h);
+item->height[1] = item->height[2] = inlink->h / (1 <<
s->desc->log2_chroma_h);
item->height[0] = item->height[3] = inlink->h;
p2 = arg;
@@ -370,7 +370,7 @@ static int config_output(AVFilterLink *outlink)
return ret;
}
-item->y[1] = item->y[2] = AV_CEIL_RSHIFT(inh, s->desc->log2_chroma_h);
+item->y[1] = item->y[2] = inh / (1 << s->desc->log2_chroma_h);
item->y[0] = item->y[3] = inh;
width = FFMAX(width, inlink->w + inw);
ping
I'm pretty sure this patch is not the correct solution.
But right now there is a pretty nasty heap overflow in the filter that
should be addressed somehow.
___
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] avutil/frame: add a flag to not create duplicate entries in a side data array
Signed-off-by: James Almer
---
libavutil/frame.c | 14 ++
libavutil/frame.h | 28
2 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index d7a32cdc92..a780e62fd0 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -774,6 +774,13 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData
***sd, int *nb_sd,
if (flags & AV_FRAME_SIDE_DATA_FLAG_UNIQUE)
remove_side_data(sd, nb_sd, type);
+if (flags & AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND) {
+for (int i = 0; i < *nb_sd; i++) {
+AVFrameSideData *entry = ((*sd)[i]);
+if (entry->type == type)
+return entry;
+}
+}
ret = add_side_data_from_buf(sd, nb_sd, type, buf);
if (!ret)
@@ -798,6 +805,13 @@ int av_frame_side_data_clone(AVFrameSideData ***sd, int
*nb_sd,
if (flags & AV_FRAME_SIDE_DATA_FLAG_UNIQUE)
remove_side_data(sd, nb_sd, src->type);
+if (flags & AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND) {
+for (int i = 0; i < *nb_sd; i++) {
+AVFrameSideData *entry = ((*sd)[i]);
+if (entry->type == src->type)
+return 0;
+}
+}
sd_dst = add_side_data_from_buf(sd, nb_sd, src->type, buf);
if (!sd_dst) {
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 8aa05ec127..7cc55a455e 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -1003,7 +1003,14 @@ const char *av_frame_side_data_name(enum
AVFrameSideDataType type);
*/
void av_frame_side_data_free(AVFrameSideData ***sd, int *nb_sd);
+/**
+ * Remove existing entries before adding new ones.
+ */
#define AV_FRAME_SIDE_DATA_FLAG_UNIQUE (1 << 0)
+/**
+ * Don't add a new entry if another of the same type exists.
+ */
+#define AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND (1 << 1)
/**
* Add new side data entry to an array.
@@ -1016,10 +1023,12 @@ void av_frame_side_data_free(AVFrameSideData ***sd, int
*nb_sd);
* @param size size of the side data
* @param flags Some combination of AV_FRAME_SIDE_DATA_FLAG_* flags, or 0.
*
- * @return newly added side data on success, NULL on error. In case of
- * AV_FRAME_SIDE_DATA_FLAG_UNIQUE being set, entries of matching
- * AVFrameSideDataType will be removed before the addition is
- * attempted.
+ * @return newly added side data on success, NULL on error.
+ * @note In case of AV_FRAME_SIDE_DATA_FLAG_UNIQUE being set, entries of
+ * matching AVFrameSideDataType will be removed before the addition
+ * is attempted.
+ * @note In case of AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND being set, if an
+ * entry of the same type already exists, it will be returned instead.
*/
AVFrameSideData *av_frame_side_data_new(AVFrameSideData ***sd, int *nb_sd,
enum AVFrameSideDataType type,
@@ -1037,10 +1046,13 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData
***sd, int *nb_sd,
* for the buffer.
* @param flags Some combination of AV_FRAME_SIDE_DATA_FLAG_* flags, or 0.
*
- * @return negative error code on failure, >=0 on success. In case of
- * AV_FRAME_SIDE_DATA_FLAG_UNIQUE being set, entries of matching
- * AVFrameSideDataType will be removed before the addition is
- * attempted.
+ * @return negative error code on failure, >=0 on success.
+ * @note In case of AV_FRAME_SIDE_DATA_FLAG_UNIQUE being set, entries of
+ * matching AVFrameSideDataType will be removed before the addition
+ * is attempted.
+ * @note In case of AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND being set, if an
+ * entry of the same type as the one from src already exists, this
+ * function will be a no-op.
*/
int av_frame_side_data_clone(AVFrameSideData ***sd, int *nb_sd,
const AVFrameSideData *src, unsigned int flags);
--
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 14/14] avutil/avstring: Avoid av_strdup(NULL)
On Mon, Mar 25, 2024 at 12:55 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Vittorio Giovara:
> > On Mon, Mar 25, 2024 at 12:38 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> libavutil/avstring.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavutil/avstring.c b/libavutil/avstring.c
> >> index 2071dd36a5..8702fe0455 100644
> >> --- a/libavutil/avstring.c
> >> +++ b/libavutil/avstring.c
> >> @@ -299,7 +299,7 @@ char *av_append_path_component(const char *path,
> const
> >> char *component)
> >> char *fullpath;
> >>
> >> if (!path)
> >> -return av_strdup(component);
> >> +return component ? av_strdup(component) : NULL;
> >> if (!component)
> >> return av_strdup(path);
> >>
> >
> > isn't this what av_strdup already does?
>
> It's not documented to do so. It could also decide to treat
> av_strdup(NULL) as av_strdup("").
>
Ah fair point, but should we not update its documentation instead?
--
Vittorio
___
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/14] avutil/avstring: Avoid av_strdup(NULL)
On 3/25/2024 1:55 PM, Andreas Rheinhardt wrote:
Vittorio Giovara:
On Mon, Mar 25, 2024 at 12:38 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
Signed-off-by: Andreas Rheinhardt
---
libavutil/avstring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/avstring.c b/libavutil/avstring.c
index 2071dd36a5..8702fe0455 100644
--- a/libavutil/avstring.c
+++ b/libavutil/avstring.c
@@ -299,7 +299,7 @@ char *av_append_path_component(const char *path, const
char *component)
char *fullpath;
if (!path)
-return av_strdup(component);
+return component ? av_strdup(component) : NULL;
if (!component)
return av_strdup(path);
isn't this what av_strdup already does?
It's not documented to do so. It could also decide to treat
av_strdup(NULL) as av_strdup("").
Even if undocumented, that would be an unexpected change in behavior.
I'm with Vittorio, we should mention the actual behavior in the doxy and
make it official.
___
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/14] avutil/avstring: Avoid av_strdup(NULL)
James Almer:
> On 3/25/2024 1:55 PM, Andreas Rheinhardt wrote:
>> Vittorio Giovara:
>>> On Mon, Mar 25, 2024 at 12:38 PM Andreas Rheinhardt <
>>> andreas.rheinha...@outlook.com> wrote:
>>>
Signed-off-by: Andreas Rheinhardt
---
libavutil/avstring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/avstring.c b/libavutil/avstring.c
index 2071dd36a5..8702fe0455 100644
--- a/libavutil/avstring.c
+++ b/libavutil/avstring.c
@@ -299,7 +299,7 @@ char *av_append_path_component(const char *path,
const
char *component)
char *fullpath;
if (!path)
- return av_strdup(component);
+ return component ? av_strdup(component) : NULL;
if (!component)
return av_strdup(path);
>>>
>>> isn't this what av_strdup already does?
>>
>> It's not documented to do so. It could also decide to treat
>> av_strdup(NULL) as av_strdup("").
>
> Even if undocumented, that would be an unexpected change in behavior.
> I'm with Vittorio, we should mention the actual behavior in the doxy and
> make it official.
The problematic thing is that this behaviour is also mostly insane. Or
rather: If you care to distinguish "returns NULL due to allocation
failure" and "returns NULL due to NULL src", then you have to check src
for NULL anyway and then you could also just have checked before calling
av_strdup and avoided it in case src is NULL. This code here is the only
example I found for which the current behaviour is actually reasonable.
- 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 v2 1/2] avutil/timestamp: introduce av_ts_make_time_string2 for better precision
On Sat, 23 Mar 2024, Marton Balint wrote:
av_ts_make_time_string() used "%.6g" format, but this format was losing
precision even when the timestamp to be printed was not that large. For example
for 3 hours (10800) seconds, only 1 decimal digit was printed, which made this
format inaccurate when it was used in e.g. the silencedetect filter. Other
detection filters printing timestamps had similar issues. Also time base
parameter of the function was *AVRational instead of AVRational.
Resolve these problems by introducing a new function, av_ts_make_time_string2().
We change the used format to "%.*f", use a precision of 6, except when printing
values near 0, in which case we calculate the precision dynamically to aim for
a similar precision in normal form as with %.6g. No longer using scientific
representation can make parsing the timestamp easier for the users, we can
safely do this because the theoretical maximum of INT64_MAX*INT32_MAX still
fits into the string buffer in normal form.
We somewhat imitate %g by trimming ending zeroes and the potential decimal
point characters. In order not to trim "inf" as well, we assume that the
decimal point string does not contain the letter "f". Note that depending on
printf %f implementation, we might trim "infinity" to "inf".
Thanks for Allan Cady for bringing up this issue.
Will apply the series, so it can make it into 7.0.
Regards,
Marton
Signed-off-by: Marton Balint
---
doc/APIchanges| 5 +
libavutil/Makefile| 1 +
libavutil/timestamp.c | 36
libavutil/timestamp.h | 8
libavutil/version.h | 2 +-
5 files changed, 51 insertions(+), 1 deletion(-)
create mode 100644 libavutil/timestamp.c
diff --git a/doc/APIchanges b/doc/APIchanges
index 2796b4d0c2..9c6fa381e1 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,11 @@ The last version increases of all libraries were on 2024-03-07
API changes, most recent first:
+2024-03-xx - xx - lavu 59.5.100 - timestamp.h
+ Add av_ts_make_time_string2() for better timestamp precision, the new
+ function accepts AVRational as time base instead of *AVRational, and is not
+ an inline function like its predecessor.
+
2024-03-xx - xx - lavc 61.3.100 - jni.h
Add av_jni_set_android_app_ctx() and av_jni_get_android_app_ctx().
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 008fcfcd9c..6e6fa8d800 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -174,6 +174,7 @@ OBJS = adler32.o
\
threadmessage.o \
time.o \
timecode.o \
+ timestamp.o \
tree.o \
twofish.o\
utils.o \
diff --git a/libavutil/timestamp.c b/libavutil/timestamp.c
new file mode 100644
index 00..2a3e3012a4
--- /dev/null
+++ b/libavutil/timestamp.c
@@ -0,0 +1,36 @@
+/*
+ * 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 "timestamp.h"
+
+char *av_ts_make_time_string2(char *buf, int64_t ts, AVRational tb)
+{
+if (ts == AV_NOPTS_VALUE) {
+snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
+} else {
+double val = av_q2d(tb) * ts;
+double log = floor(log10(fabs(val)));
+int precision = (isfinite(log) && log < 0) ? -log + 5 : 6;
+int last = snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.*f", precision,
val);
+last = FFMIN(last, AV_TS_MAX_STRING_SIZE - 1) - 1;
+for (; last && buf[last] == '0'; last--);
+for (; last && buf[last] != 'f' && (buf[last] < '0' || buf[0] > '9');
last--);
+buf[last + 1] = '\0';
+}
+return buf;
+}
diff --git a/libavutil/timestamp.h b/libavutil/timestamp.h
index 2b37781eba..7e6da894df 100644
--- a/libavutil/timestamp.h
+++ b/libavutil/timestamp.h
@@ -62,6 +62,14 @@ static inline char *av_ts_make_string(char *buf, int64_t ts)
* @param tb the timebase o
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/jpeg2000htdec: Check M_b / magp before using it in a shift
On Thu, Mar 21, 2024 at 04:07:14PM +0100, Tomas Härdin wrote: > ons 2024-03-20 klockan 21:35 +0100 skrev Tomas Härdin: > > ons 2024-03-20 klockan 14:12 +0100 skrev Michael Niedermayer: > > > On Wed, Mar 20, 2024 at 12:20:11PM +0100, Tomas Härdin wrote: > > > > ons 2024-03-20 klockan 03:59 +0100 skrev Michael Niedermayer: > > > > > Fixes: shift exponent -1 is negative > > > > > Fixes: 65378/clusterfuzz-testcase-minimized- > > > > > ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5457678193197056 > > > > > > > > > > Found-by: continuous fuzzing process > > > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > > > Signed-off-by: Michael Niedermayer > > > > > --- > > > > > libavcodec/jpeg2000htdec.c | 3 +++ > > > > > 1 file changed, 3 insertions(+) > > > > > > > > > > diff --git a/libavcodec/jpeg2000htdec.c > > > > > b/libavcodec/jpeg2000htdec.c > > > > > index 6b9898d3ff..0b94bb5da2 100644 > > > > > --- a/libavcodec/jpeg2000htdec.c > > > > > +++ b/libavcodec/jpeg2000htdec.c > > > > > @@ -1193,6 +1193,9 @@ ff_jpeg2000_decode_htj2k(const > > > > > Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *c > > > > > > > > > > int32_t M_b = magp; > > > > > > > > > > + if (magp >= 31) > > > > > + return AVERROR_INVALIDDATA; > > > > > > > > This isn't where the error is, assuming it even is an error. It's > > > > either expn or nguardbits that are wrong, and they should be > > > > detected > > > > and reported as such in jpeg2000dec.c. Checking this in every > > > > call > > > > to > > > > ff_jpeg2000_decode_htj2k() is wasteful. > > > > > > > > nguardbits can be 0..7 and expn can be 0..31. Table A.11 > > > > indicates > > > > that > > > > Ssize can be up to 38 bits, so M_b >= 31 is in fact perfectly > > > > valid. > > > > > > > A > > > > more appropriate error might be AVERROR_PATCHWELCOME. > > > > > > indeed, i will change it to AVERROR_PATCHWELCOME > > > > Please also move it further up so as to not waste cycles checking it > > every time > > To be more precise, get_qcx() looks like the proper place for it will apply with teh check moved there thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: PGP signature ___ 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/4] avcodec/vmixdec: Check shift before use
On Wed, Mar 20, 2024 at 03:59:21AM +0100, Michael Niedermayer wrote: > Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int' > Fixes: > 65909/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VMIX_fuzzer-519459745831321 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/vmixdec.c | 3 +++ > 1 file changed, 3 insertions(+) will apply patches 2-4 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny individual rights cannot claim to be defenders of minorities. - Ayn Rand signature.asc Description: PGP signature ___ 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/4] avcodec/jpeg2000htdec: Check M_b / magp before using it in a shift
On Mon, Mar 25, 2024 at 08:13:13PM +0100, Michael Niedermayer wrote: > On Thu, Mar 21, 2024 at 04:07:14PM +0100, Tomas Härdin wrote: > > ons 2024-03-20 klockan 21:35 +0100 skrev Tomas Härdin: > > > ons 2024-03-20 klockan 14:12 +0100 skrev Michael Niedermayer: > > > > On Wed, Mar 20, 2024 at 12:20:11PM +0100, Tomas Härdin wrote: > > > > > ons 2024-03-20 klockan 03:59 +0100 skrev Michael Niedermayer: > > > > > > Fixes: shift exponent -1 is negative > > > > > > Fixes: 65378/clusterfuzz-testcase-minimized- > > > > > > ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5457678193197056 > > > > > > > > > > > > Found-by: continuous fuzzing process > > > > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > > > > Signed-off-by: Michael Niedermayer > > > > > > --- > > > > > > libavcodec/jpeg2000htdec.c | 3 +++ > > > > > > 1 file changed, 3 insertions(+) > > > > > > > > > > > > diff --git a/libavcodec/jpeg2000htdec.c > > > > > > b/libavcodec/jpeg2000htdec.c > > > > > > index 6b9898d3ff..0b94bb5da2 100644 > > > > > > --- a/libavcodec/jpeg2000htdec.c > > > > > > +++ b/libavcodec/jpeg2000htdec.c > > > > > > @@ -1193,6 +1193,9 @@ ff_jpeg2000_decode_htj2k(const > > > > > > Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *c > > > > > > > > > > > > int32_t M_b = magp; > > > > > > > > > > > > + if (magp >= 31) > > > > > > + return AVERROR_INVALIDDATA; > > > > > > > > > > This isn't where the error is, assuming it even is an error. It's > > > > > either expn or nguardbits that are wrong, and they should be > > > > > detected > > > > > and reported as such in jpeg2000dec.c. Checking this in every > > > > > call > > > > > to > > > > > ff_jpeg2000_decode_htj2k() is wasteful. > > > > > > > > > > nguardbits can be 0..7 and expn can be 0..31. Table A.11 > > > > > indicates > > > > > that > > > > > Ssize can be up to 38 bits, so M_b >= 31 is in fact perfectly > > > > > valid. > > > > > > > > > A > > > > > more appropriate error might be AVERROR_PATCHWELCOME. > > > > > > > > indeed, i will change it to AVERROR_PATCHWELCOME > > > > > > Please also move it further up so as to not waste cycles checking it > > > every time > > > > To be more precise, get_qcx() looks like the proper place for it > > will apply with teh check moved there the values that are causing undefined behavior for htj2k are used in normal j2k knowing which type of j2k we have seems decided by COC/COD/COX so i dont think we can check in QCX, because a later COX could make it both invalid or valid and we cannot check in COX as a later QCX can similarly change it thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: PGP signature ___ 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/6 v2] avutil/frame: add a flag to not create duplicate entries in a side data array
Signed-off-by: James Almer
---
libavutil/frame.c | 14 ++
libavutil/frame.h | 28
2 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index d7a32cdc92..a780e62fd0 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -774,6 +774,13 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData
***sd, int *nb_sd,
if (flags & AV_FRAME_SIDE_DATA_FLAG_UNIQUE)
remove_side_data(sd, nb_sd, type);
+if (flags & AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND) {
+for (int i = 0; i < *nb_sd; i++) {
+AVFrameSideData *entry = ((*sd)[i]);
+if (entry->type == type)
+return entry;
+}
+}
ret = add_side_data_from_buf(sd, nb_sd, type, buf);
if (!ret)
@@ -798,6 +805,13 @@ int av_frame_side_data_clone(AVFrameSideData ***sd, int
*nb_sd,
if (flags & AV_FRAME_SIDE_DATA_FLAG_UNIQUE)
remove_side_data(sd, nb_sd, src->type);
+if (flags & AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND) {
+for (int i = 0; i < *nb_sd; i++) {
+AVFrameSideData *entry = ((*sd)[i]);
+if (entry->type == src->type)
+return 0;
+}
+}
sd_dst = add_side_data_from_buf(sd, nb_sd, src->type, buf);
if (!sd_dst) {
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 8aa05ec127..7cc55a455e 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -1003,7 +1003,14 @@ const char *av_frame_side_data_name(enum
AVFrameSideDataType type);
*/
void av_frame_side_data_free(AVFrameSideData ***sd, int *nb_sd);
+/**
+ * Remove existing entries before adding new ones.
+ */
#define AV_FRAME_SIDE_DATA_FLAG_UNIQUE (1 << 0)
+/**
+ * Don't add a new entry if another of the same type exists.
+ */
+#define AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND (1 << 1)
/**
* Add new side data entry to an array.
@@ -1016,10 +1023,12 @@ void av_frame_side_data_free(AVFrameSideData ***sd, int
*nb_sd);
* @param size size of the side data
* @param flags Some combination of AV_FRAME_SIDE_DATA_FLAG_* flags, or 0.
*
- * @return newly added side data on success, NULL on error. In case of
- * AV_FRAME_SIDE_DATA_FLAG_UNIQUE being set, entries of matching
- * AVFrameSideDataType will be removed before the addition is
- * attempted.
+ * @return newly added side data on success, NULL on error.
+ * @note In case of AV_FRAME_SIDE_DATA_FLAG_UNIQUE being set, entries of
+ * matching AVFrameSideDataType will be removed before the addition
+ * is attempted.
+ * @note In case of AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND being set, if an
+ * entry of the same type already exists, it will be returned instead.
*/
AVFrameSideData *av_frame_side_data_new(AVFrameSideData ***sd, int *nb_sd,
enum AVFrameSideDataType type,
@@ -1037,10 +1046,13 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData
***sd, int *nb_sd,
* for the buffer.
* @param flags Some combination of AV_FRAME_SIDE_DATA_FLAG_* flags, or 0.
*
- * @return negative error code on failure, >=0 on success. In case of
- * AV_FRAME_SIDE_DATA_FLAG_UNIQUE being set, entries of matching
- * AVFrameSideDataType will be removed before the addition is
- * attempted.
+ * @return negative error code on failure, >=0 on success.
+ * @note In case of AV_FRAME_SIDE_DATA_FLAG_UNIQUE being set, entries of
+ * matching AVFrameSideDataType will be removed before the addition
+ * is attempted.
+ * @note In case of AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND being set, if an
+ * entry of the same type as the one from src already exists, this
+ * function will be a no-op.
*/
int av_frame_side_data_clone(AVFrameSideData ***sd, int *nb_sd,
const AVFrameSideData *src, unsigned int flags);
--
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/6 v2] avutil/frame: add helper for adding side data w/ AVBufferRef to array
Signed-off-by: James Almer
---
libavutil/frame.c | 43 +++
libavutil/frame.h | 35 +++
2 files changed, 78 insertions(+)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index a780e62fd0..33c077998a 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -789,6 +789,49 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData
***sd, int *nb_sd,
return ret;
}
+AVFrameSideData *av_frame_side_data_add(AVFrameSideData ***sd, int *nb_sd,
+enum AVFrameSideDataType type,
+AVBufferRef **pbuf, unsigned int flags)
+{
+AVFrameSideData *sd_dst = NULL;
+AVBufferRef *buf;
+
+if (!sd || !pbuf || !nb_sd || (*nb_sd && !*sd))
+return NULL;
+
+if (flags & AV_FRAME_SIDE_DATA_FLAG_UNIQUE)
+remove_side_data(sd, nb_sd, type);
+if (flags & AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND) {
+for (int i = 0; i < *nb_sd; i++) {
+AVFrameSideData *entry = ((*sd)[i]);
+if (entry->type == type) {
+if (!(flags & AV_FRAME_SIDE_DATA_FLAG_NEW_REF))
+av_buffer_unref(pbuf);
+return entry;
+}
+}
+}
+
+if (flags & AV_FRAME_SIDE_DATA_FLAG_NEW_REF)
+buf = av_buffer_ref(*pbuf);
+else
+buf = *pbuf;
+if (!buf)
+return NULL;
+
+sd_dst = add_side_data_from_buf(sd, nb_sd, type, buf);
+if (!sd_dst) {
+if (flags & AV_FRAME_SIDE_DATA_FLAG_NEW_REF)
+av_buffer_unref(&buf);
+return NULL;
+}
+
+if (!(flags & AV_FRAME_SIDE_DATA_FLAG_NEW_REF))
+*pbuf = NULL;
+
+return sd_dst;
+}
+
int av_frame_side_data_clone(AVFrameSideData ***sd, int *nb_sd,
const AVFrameSideData *src, unsigned int flags)
{
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 7cc55a455e..e03ce39af7 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -1011,6 +1011,10 @@ void av_frame_side_data_free(AVFrameSideData ***sd, int
*nb_sd);
* Don't add a new entry if another of the same type exists.
*/
#define AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND (1 << 1)
+/**
+ * Create a new reference instead of taking ownership of the passed in one.
+ */
+#define AV_FRAME_SIDE_DATA_FLAG_NEW_REF (1 << 2)
/**
* Add new side data entry to an array.
@@ -1029,11 +1033,41 @@ void av_frame_side_data_free(AVFrameSideData ***sd, int
*nb_sd);
* is attempted.
* @note In case of AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND being set, if an
* entry of the same type already exists, it will be returned instead.
+ * @note AV_FRAME_SIDE_DATA_FLAG_NEW_REF has no effect in this function.
*/
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 an array from an existing AVBufferRef.
+ *
+ * @param sdpointer to array of side data to which to add another entry,
+ * or to NULL in order 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 buf Pointer to AVBufferRef to add to the array. On success,
+ * the function takes ownership of the AVBufferRef and *buf is
+ * set to NULL, unless AV_FRAME_SIDE_DATA_FLAG_NEW_REF is set
+ * in which case the ownership will remain with the caller.
+ * @param flags Some combination of AV_FRAME_SIDE_DATA_FLAG_* flags, or 0.
+ *
+ * @return newly added side data on success, NULL on error.
+ * @note In case of AV_FRAME_SIDE_DATA_FLAG_UNIQUE being set, entries of
+ * matching AVFrameSideDataType will be removed before the addition
+ * is attempted.
+ * @note In case of AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND being set, if an
+ * entry of the same type already exists, it will be returned instead
+ * and the array will be unchanged.
+ * @note In case of AV_FRAME_SIDE_DATA_FLAG_NEW_REF being set, the ownership
+ * of *buf will remain with the caller.
+ *
+ */
+AVFrameSideData *av_frame_side_data_add(AVFrameSideData ***sd, int *nb_sd,
+enum AVFrameSideDataType type,
+AVBufferRef **buf, unsigned int flags);
+
/**
* Add a new side data entry to an array based on existing side data, taking
* a reference towards the contained AVBufferRef.
@@ -1053,6 +1087,7 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData
***sd, int *nb_sd,
* @note In case of AV_FRAME_SIDE_DATA_FLAG_DONT_APPEND being set, if an
* entry of the same type as the one from src already exists, this
* function will be a no-op.
+ * @note AV_FRAME_SIDE_DATA_FLAG_NEW_REF has no effect
[FFmpeg-devel] [PATCH 3/6 v2] avutil/frame: add helper to remove side data of a given type from an array
Signed-off-by: James Almer
---
libavutil/frame.c | 6 ++
libavutil/frame.h | 5 +
2 files changed, 11 insertions(+)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 33c077998a..10c7d3ebf0 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -882,6 +882,12 @@ const AVFrameSideData *av_frame_side_data_get_c(const
AVFrameSideData * const *s
return NULL;
}
+void av_frame_side_data_remove(AVFrameSideData ***sd, int *nb_sd,
+ enum AVFrameSideDataType type)
+{
+remove_side_data(sd, nb_sd, type);
+}
+
AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
enum AVFrameSideDataType type)
{
diff --git a/libavutil/frame.h b/libavutil/frame.h
index e03ce39af7..043f446b38 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -1121,6 +1121,11 @@ const AVFrameSideData
*av_frame_side_data_get(AVFrameSideData * const *sd,
nb_sd, type);
}
+/**
+ * Remove and free all side data instances of the given type from an array.
+ */
+void av_frame_side_data_remove(AVFrameSideData ***sd, int *nb_sd,
+ enum AVFrameSideDataType type);
/**
* @}
*/
--
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 4/6 v2] avutil/mastering_display_metadata: add a new allocator function that returns a size
av_mastering_display_metadata_alloc() is not useful in scenarios where you need
to
know the runtime size of AVMasteringDisplayMetadata.
Signed-off-by: James Almer
---
libavutil/mastering_display_metadata.c | 13 +
libavutil/mastering_display_metadata.h | 9 +
2 files changed, 22 insertions(+)
diff --git a/libavutil/mastering_display_metadata.c
b/libavutil/mastering_display_metadata.c
index 6069347617..ea41f13f9d 100644
--- a/libavutil/mastering_display_metadata.c
+++ b/libavutil/mastering_display_metadata.c
@@ -18,6 +18,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include
#include
#include
@@ -29,6 +30,18 @@ AVMasteringDisplayMetadata
*av_mastering_display_metadata_alloc(void)
return av_mallocz(sizeof(AVMasteringDisplayMetadata));
}
+AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc_size(size_t
*size)
+{
+AVMasteringDisplayMetadata *mastering =
av_mallocz(sizeof(AVMasteringDisplayMetadata));
+if (!mastering)
+return NULL;
+
+if (size)
+*size = sizeof(*mastering);
+
+return mastering;
+}
+
AVMasteringDisplayMetadata
*av_mastering_display_metadata_create_side_data(AVFrame *frame)
{
AVFrameSideData *side_data = av_frame_new_side_data(frame,
diff --git a/libavutil/mastering_display_metadata.h
b/libavutil/mastering_display_metadata.h
index c23b07c3cd..52fcef9e37 100644
--- a/libavutil/mastering_display_metadata.h
+++ b/libavutil/mastering_display_metadata.h
@@ -77,6 +77,15 @@ typedef struct AVMasteringDisplayMetadata {
*/
AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc(void);
+/**
+ * Allocate an AVMasteringDisplayMetadata structure and set its fields to
+ * default values. The resulting struct can be freed using av_freep().
+ *
+ * @return An AVMasteringDisplayMetadata filled with default values or NULL
+ * on failure.
+ */
+AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc_size(size_t
*size);
+
/**
* Allocate a complete AVMasteringDisplayMetadata and add it to the frame.
*
--
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 5/6 v2] avcodec/decode: make the AVFrameSideData helper wrappers not depend on frames
They will be useful to fill arrays stored in other structs.
Signed-off-by: James Almer
---
libavcodec/av1dec.c | 7 +--
libavcodec/cri.c| 3 +-
libavcodec/decode.c | 97 ++---
libavcodec/decode.h | 28 ++--
libavcodec/dpx.c| 3 +-
libavcodec/h2645_sei.c | 4 +-
libavcodec/h264_slice.c | 3 +-
libavcodec/hevcdec.c| 6 ++-
libavcodec/libdav1d.c | 7 +--
libavcodec/libjxldec.c | 3 +-
libavcodec/mjpegdec.c | 3 +-
libavcodec/mpeg12dec.c | 11 +++--
libavcodec/pngdec.c | 8 ++--
libavcodec/qsvdec.c | 4 +-
libavcodec/tiff.c | 3 +-
libavcodec/webp.c | 3 +-
16 files changed, 117 insertions(+), 76 deletions(-)
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 32a795e758..54bedc27e1 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -964,7 +964,8 @@ static int export_itut_t35(AVCodecContext *avctx, AVFrame
*frame,
if (!ret)
break;
-ret = ff_frame_new_side_data_from_buf(avctx, frame,
AV_FRAME_DATA_A53_CC, &buf, NULL);
+ret = ff_frame_new_side_data_from_buf(avctx, &frame->side_data,
&frame->nb_side_data,
+ AV_FRAME_DATA_A53_CC, &buf);
if (ret < 0)
return ret;
@@ -1028,7 +1029,7 @@ static int export_metadata(AVCodecContext *avctx, AVFrame
*frame)
if (s->mdcv) {
AVMasteringDisplayMetadata *mastering;
-ret = ff_decode_mastering_display_new(avctx, frame, &mastering);
+ret = ff_decode_mastering_display_new(avctx, &frame->side_data,
&frame->nb_side_data, &mastering);
if (ret < 0)
return ret;
@@ -1051,7 +1052,7 @@ static int export_metadata(AVCodecContext *avctx, AVFrame
*frame)
if (s->cll) {
AVContentLightMetadata *light;
-ret = ff_decode_content_light_new(avctx, frame, &light);
+ret = ff_decode_content_light_new(avctx, &frame->side_data,
&frame->nb_side_data, &light);
if (ret < 0)
return ret;
diff --git a/libavcodec/cri.c b/libavcodec/cri.c
index 990e52ac99..94468e7515 100644
--- a/libavcodec/cri.c
+++ b/libavcodec/cri.c
@@ -398,7 +398,8 @@ skip:
}
if (hflip || vflip) {
-ff_frame_new_side_data(avctx, p, AV_FRAME_DATA_DISPLAYMATRIX,
+ff_frame_new_side_data(avctx, &p->side_data, &p->nb_side_data,
+ AV_FRAME_DATA_DISPLAYMATRIX,
sizeof(int32_t) * 9, &rotation);
if (rotation) {
av_display_rotation_set((int32_t *)rotation->data, 0.f);
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 34bcb7cc64..ca7519d3c2 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1799,87 +1799,114 @@ int ff_decode_preinit(AVCodecContext *avctx)
* @retval 0 side data of this type can be added to frame
* @retval 1 side data of this type should not be added to frame
*/
-static int side_data_pref(const AVCodecContext *avctx, AVFrame *frame,
- enum AVFrameSideDataType type)
+static int side_data_pref(const AVCodecContext *avctx, AVFrameSideData ***sd,
+ int *nb_sd, enum AVFrameSideDataType type)
{
DecodeContext *dc = decode_ctx(avctx->internal);
// Note: could be skipped for `type` without corresponding packet sd
-if (av_frame_get_side_data(frame, type)) {
+if (av_frame_side_data_get(*sd, *nb_sd, type)) {
if (dc->side_data_pref_mask & (1ULL << type))
return 1;
-av_frame_remove_side_data(frame, type);
+av_frame_side_data_remove(sd, nb_sd, type);
}
return 0;
}
-
-int ff_frame_new_side_data(const AVCodecContext *avctx, AVFrame *frame,
- enum AVFrameSideDataType type, size_t size,
+int ff_frame_new_side_data(const AVCodecContext *avctx, AVFrameSideData ***sd,
+ int *nb_sd, enum AVFrameSideDataType type, size_t
size,
AVFrameSideData **psd)
{
-AVFrameSideData *sd;
-
-if (side_data_pref(avctx, frame, type)) {
+if (side_data_pref(avctx, sd, nb_sd, type)) {
if (psd)
*psd = NULL;
return 0;
}
-sd = av_frame_new_side_data(frame, type, size);
-if (psd)
-*psd = sd;
+*psd = av_frame_side_data_new(sd, nb_sd, type, size, 0);
-return sd ? 0 : AVERROR(ENOMEM);
+return *psd ? 0 : AVERROR(ENOMEM);
}
-int ff_frame_new_side_data_from_buf(const AVCodecContext *avctx,
-AVFrame *frame, enum AVFrameSideDataType
type,
-AVBufferRef **buf, AVFrameSideData **psd)
+int ff_frame_new_side_data_from_buf(const AVCodecContext *avctx,
AVFrameSideData ***sd,
+int *nb_sd, enum AVFrameSideDataType type,
+AVBufferRef **buf)
{
-AVFrame
[FFmpeg-devel] [PATCH 6/6 v2] avcodec/hevcdec: export global side data in AVCodecContext
Signed-off-by: James Almer
---
libavcodec/avcodec.h | 2 +-
libavcodec/h2645_sei.c | 217 ++---
libavcodec/h2645_sei.h | 2 +
libavcodec/hevcdec.c | 4 +
libavcodec/pthread_frame.c | 10 ++
5 files changed, 146 insertions(+), 89 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 83dc487251..968009a192 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2071,7 +2071,7 @@ typedef struct AVCodecContext {
* - encoding: may be set by user before calling avcodec_open2() for
* encoder configuration. Afterwards owned and freed by the
* encoder.
- * - decoding: unused
+ * - decoding: may be set by libavcodec in avcodec_open2().
*/
AVFrameSideData **decoded_side_data;
int nb_decoded_side_data;
diff --git a/libavcodec/h2645_sei.c b/libavcodec/h2645_sei.c
index a9f4e01de8..7c11d7e449 100644
--- a/libavcodec/h2645_sei.c
+++ b/libavcodec/h2645_sei.c
@@ -529,6 +529,124 @@ static int is_frame_packing_type_valid(SEIFpaType type,
enum AVCodecID codec_id)
type >= SEI_FPA_TYPE_SIDE_BY_SIDE;
}
+static int h2645_sei_to_side_data(AVCodecContext *avctx, H2645SEI *sei,
+ AVFrameSideData ***sd, int *nb_sd)
+{
+int ret;
+
+for (unsigned i = 0; i < sei->unregistered.nb_buf_ref; i++) {
+H2645SEIUnregistered *unreg = &sei->unregistered;
+AVBufferRef *buf;
+
+if (!unreg->buf_ref[i])
+continue;
+
+buf = av_buffer_ref(unreg->buf_ref[i]);
+if (!buf)
+return AVERROR(ENOMEM);
+
+if (!av_frame_side_data_add(sd, nb_sd, AV_FRAME_DATA_SEI_UNREGISTERED,
&buf, 0)) {
+av_buffer_unref(&buf);
+return AVERROR(ENOMEM);
+}
+}
+
+if (sei->ambient_viewing_environment.present) {
+H2645SEIAmbientViewingEnvironment *env =
+&sei->ambient_viewing_environment;
+AVBufferRef *buf;
+size_t size;
+
+AVAmbientViewingEnvironment *dst_env =
+av_ambient_viewing_environment_alloc(&size);
+if (!dst_env)
+return AVERROR(ENOMEM);
+
+buf = av_buffer_create((uint8_t *)dst_env, size, NULL, NULL, 0);
+if (!buf) {
+av_free(dst_env);
+return AVERROR(ENOMEM);
+}
+
+ret = ff_frame_new_side_data_from_buf(avctx, sd, nb_sd,
+
AV_FRAME_DATA_AMBIENT_VIEWING_ENVIRONMENT, &buf);
+
+if (ret < 0)
+return ret;
+
+dst_env->ambient_illuminance = av_make_q(env->ambient_illuminance,
1);
+dst_env->ambient_light_x = av_make_q(env->ambient_light_x,
5);
+dst_env->ambient_light_y = av_make_q(env->ambient_light_y,
5);
+}
+
+if (sei->mastering_display.present) {
+// HEVC uses a g,b,r ordering, which we convert to a more natural r,g,b
+const int mapping[3] = {2, 0, 1};
+const int chroma_den = 5;
+const int luma_den = 1;
+int i;
+AVMasteringDisplayMetadata *metadata;
+
+ret = ff_decode_mastering_display_new(avctx, sd, nb_sd, &metadata);
+if (ret < 0)
+return ret;
+
+if (metadata) {
+for (i = 0; i < 3; i++) {
+const int j = mapping[i];
+metadata->display_primaries[i][0].num =
sei->mastering_display.display_primaries[j][0];
+metadata->display_primaries[i][0].den = chroma_den;
+metadata->display_primaries[i][1].num =
sei->mastering_display.display_primaries[j][1];
+metadata->display_primaries[i][1].den = chroma_den;
+}
+metadata->white_point[0].num =
sei->mastering_display.white_point[0];
+metadata->white_point[0].den = chroma_den;
+metadata->white_point[1].num =
sei->mastering_display.white_point[1];
+metadata->white_point[1].den = chroma_den;
+
+metadata->max_luminance.num = sei->mastering_display.max_luminance;
+metadata->max_luminance.den = luma_den;
+metadata->min_luminance.num = sei->mastering_display.min_luminance;
+metadata->min_luminance.den = luma_den;
+metadata->has_luminance = 1;
+metadata->has_primaries = 1;
+
+av_log(avctx, AV_LOG_DEBUG, "Mastering Display Metadata:\n");
+av_log(avctx, AV_LOG_DEBUG,
+ "r(%5.4f,%5.4f) g(%5.4f,%5.4f) b(%5.4f %5.4f) wp(%5.4f,
%5.4f)\n",
+ av_q2d(metadata->display_primaries[0][0]),
+ av_q2d(metadata->display_primaries[0][1]),
+ av_q2d(metadata->display_primaries[1][0]),
+ av_q2d(metadata->display_primaries[1][1]),
+ av_q2d(metadata->display_primaries[2][0]),
+ av_q2d(metadata->display_primaries[2][1
[FFmpeg-devel] [PATCH] Added alpha layer support for smartblur - reformatted patch
--- Begin Message ---
Signed-off-by: Andrea Mastroberti <10736...@polimi.it>
---
doc/filters.texi | 20 -
libavfilter/version.h | 2 +-
libavfilter/vf_smartblur.c | 44 ++
3 files changed, 55 insertions(+), 11 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 913365671d..30b3627724 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -22688,9 +22688,27 @@ whether a pixel should be blurred or not. The option
value must be an
integer in the range [-30,30]. A value of 0 will filter all the image,
a value included in [0,30] will filter flat areas and a value included
in [-30,0] will filter edges. Default value is @option{luma_threshold}.
+
+@item alpha_radius, ar
+Set the alpha radius. The option value must be a float number in
+the range [0.1,5.0] that specifies the variance of the gaussian filter
+used to blur the image (slower if larger). Default value is 1.0.
+
+@item alpha_strength, as
+Set the alpha strength. The option value must be a float number
+in the range [-1.0,1.0] that configures the blurring. A value included
+in [0.0,1.0] will blur the image whereas a value included in
+[-1.0,0.0] will sharpen the image. Default value is 1.0.
+
+@item alpha_threshold, at
+Set the alpha threshold used as a coefficient to determine
+whether a pixel should be blurred or not. The option value must be an
+integer in the range [-30,30]. A value of 0 will filter all the image,
+a value included in [0,30] will filter flat areas and a value included
+in [-30,0] will filter edges. Default value is 0.
@end table
-If a chroma option is not explicitly set, the corresponding luma value
+If a chroma or alpha option is not explicitly set, the corresponding luma value
is set.
@section sobel
diff --git a/libavfilter/version.h b/libavfilter/version.h
index d5a6bc143a..f01b3f8e91 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -32,7 +32,7 @@
#include "version_major.h"
#define LIBAVFILTER_VERSION_MINOR 0
-#define LIBAVFILTER_VERSION_MICRO 100
+#define LIBAVFILTER_VERSION_MICRO 101
#define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
diff --git a/libavfilter/vf_smartblur.c b/libavfilter/vf_smartblur.c
index ae0ec05b2d..bc377d0b92 100644
--- a/libavfilter/vf_smartblur.c
+++ b/libavfilter/vf_smartblur.c
@@ -54,6 +54,7 @@ typedef struct SmartblurContext {
const AVClass *class;
FilterParam luma;
FilterParam chroma;
+FilterParam alpha;
int hsub;
int vsub;
unsigned int sws_flags;
@@ -77,6 +78,13 @@ static const AVOption smartblur_options[] = {
{ "chroma_threshold", "set chroma threshold", OFFSET(chroma.threshold),
AV_OPT_TYPE_INT, {.i64=THRESHOLD_MIN-1}, THRESHOLD_MIN-1, THRESHOLD_MAX,
.flags=FLAGS },
{ "ct", "set chroma threshold", OFFSET(chroma.threshold),
AV_OPT_TYPE_INT, {.i64=THRESHOLD_MIN-1}, THRESHOLD_MIN-1, THRESHOLD_MAX,
.flags=FLAGS },
+{ "alpha_radius","set alpha radius",OFFSET(alpha.radius),
AV_OPT_TYPE_FLOAT, {.dbl=1.0}, RADIUS_MIN, RADIUS_MAX, .flags=FLAGS },
+{ "ar" ,"set alpha radius",OFFSET(alpha.radius),
AV_OPT_TYPE_FLOAT, {.dbl=1.0}, RADIUS_MIN, RADIUS_MAX, .flags=FLAGS },
+{ "alpha_strength", "set alpha strength", OFFSET(alpha.strength),
AV_OPT_TYPE_FLOAT, {.dbl=1.0}, STRENGTH_MIN, STRENGTH_MAX, .flags=FLAGS },
+{ "as", "set alpha strength", OFFSET(alpha.strength),
AV_OPT_TYPE_FLOAT, {.dbl=1.0}, STRENGTH_MIN, STRENGTH_MAX, .flags=FLAGS },
+{ "alpha_threshold", "set alpha threshold", OFFSET(alpha.threshold),
AV_OPT_TYPE_INT, {.i64=0}, THRESHOLD_MIN, THRESHOLD_MAX, .flags=FLAGS },
+{ "at", "set alpha threshold", OFFSET(alpha.threshold),
AV_OPT_TYPE_INT, {.i64=0}, THRESHOLD_MIN, THRESHOLD_MAX, .flags=FLAGS },
+
{ NULL }
};
@@ -86,7 +94,7 @@ static av_cold int init(AVFilterContext *ctx)
{
SmartblurContext *s = ctx->priv;
-/* make chroma default to luma values, if not explicitly set */
+/* make chroma and alpha default to luma values, if not explicitly set */
if (s->chroma.radius < RADIUS_MIN)
s->chroma.radius = s->luma.radius;
if (s->chroma.strength < STRENGTH_MIN)
@@ -94,15 +102,23 @@ static av_cold int init(AVFilterContext *ctx)
if (s->chroma.threshold < THRESHOLD_MIN)
s->chroma.threshold = s->luma.threshold;
-s->luma.quality = s->chroma.quality = 3.0;
+if (s->alpha.radius < RADIUS_MIN)
+s->alpha.radius = s->alpha.radius;
+if (s->alpha.strength < STRENGTH_MIN)
+s->alpha.strength = s->alpha.strength;
+if (s->alpha.threshold < THRESHOLD_MIN)
+s->alpha.threshold = s->alpha.threshold;
+
+s->luma.quality = s->chroma.quality = s->alpha.quality = 3.0;
s->sws_flags = SWS_BICUBIC;
av_log(ctx, AV_LOG_VERBOSE,
"luma_radius:%f luma_strength:%f luma_threshold:%d "
- "
Re: [FFmpeg-devel] [RFC] 7.0 blocking issues
Mar 25, 2024, 14:50 by ffm...@haasn.xyz: > On Mon, 25 Mar 2024 07:20:56 +0100 "Jean-Baptiste Kempf" > wrote: > >> Hello, >> >> On Mon, 25 Mar 2024, at 01:03, Michael Niedermayer wrote: >> > Should i wait till all issues marked as blocking 7.0 on trac are fixed >> > before branching ? >> >> I think you should branch now. >> And get things fixed in the 7.0 branch. >> > > +1 > > This is a big change and some breakage is inevitable. Most bugs will > probably only be found once the software is released and deployed. > > When a big milestone gets bogged down by months (if not years) of > "blocking bugs", my understanding is that it will simply never get > released, and users might as well resort to using git master / nightly > builds at that point. > > (Any possible allusion to *other* big open source software projects is > purely coincidental) > +1, we should branch so we can unblock master from receiving large patchsets and release next week ___ 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] fftools/ffmpeg_filter: remove unused struct from InputFilterPriv
On 3/24/2024 10:36 AM, James Almer wrote:
It's already in InputFilterOptions.
Signed-off-by: James Almer
---
fftools/ffmpeg_filter.c | 16
1 file changed, 16 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 3d88482d07..171e47be9e 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -145,22 +145,6 @@ typedef struct InputFilterPriv {
int displaymatrix_present;
int32_t displaymatrix[9];
-// fallback parameters to use when no input is ever sent
-struct {
-AVRational time_base;
-
-int format;
-
-int width;
-int height;
-AVRational sample_aspect_ratio;
-enum AVColorSpace color_space;
-enum AVColorRange color_range;
-
-int sample_rate;
-AVChannelLayout ch_layout;
-} fallback;
-
struct {
AVFrame *frame;
Will apply the set soon.
___
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/h264_idct: Fix incorrect xmm spilling on win64
On Sun, Mar 24, 2024 at 8:21 PM Henrik Gramner wrote: > > Broken in afa471d0efed1df5dca6eeeb2fcdd211ae4cad4e. It just happened > to work before due to x86inc.asm previously performing XMM spills in > INIT_MMX mode which was more of a bug than an intentional feature. Will apply. ___ 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/6 v2] avutil/mastering_display_metadata: add a new allocator function that returns a size
James Almer:
> av_mastering_display_metadata_alloc() is not useful in scenarios where you
> need to
> know the runtime size of AVMasteringDisplayMetadata.
>
> Signed-off-by: James Almer
> ---
> libavutil/mastering_display_metadata.c | 13 +
> libavutil/mastering_display_metadata.h | 9 +
> 2 files changed, 22 insertions(+)
>
> diff --git a/libavutil/mastering_display_metadata.c
> b/libavutil/mastering_display_metadata.c
> index 6069347617..ea41f13f9d 100644
> --- a/libavutil/mastering_display_metadata.c
> +++ b/libavutil/mastering_display_metadata.c
> @@ -18,6 +18,7 @@
> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> */
>
> +#include
> #include
> #include
>
> @@ -29,6 +30,18 @@ AVMasteringDisplayMetadata
> *av_mastering_display_metadata_alloc(void)
> return av_mallocz(sizeof(AVMasteringDisplayMetadata));
> }
>
> +AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc_size(size_t
> *size)
> +{
> +AVMasteringDisplayMetadata *mastering =
> av_mallocz(sizeof(AVMasteringDisplayMetadata));
> +if (!mastering)
> +return NULL;
> +
> +if (size)
> +*size = sizeof(*mastering);
> +
> +return mastering;
> +}
> +
> AVMasteringDisplayMetadata
> *av_mastering_display_metadata_create_side_data(AVFrame *frame)
> {
> AVFrameSideData *side_data = av_frame_new_side_data(frame,
> diff --git a/libavutil/mastering_display_metadata.h
> b/libavutil/mastering_display_metadata.h
> index c23b07c3cd..52fcef9e37 100644
> --- a/libavutil/mastering_display_metadata.h
> +++ b/libavutil/mastering_display_metadata.h
> @@ -77,6 +77,15 @@ typedef struct AVMasteringDisplayMetadata {
> */
> AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc(void);
>
> +/**
> + * Allocate an AVMasteringDisplayMetadata structure and set its fields to
> + * default values. The resulting struct can be freed using av_freep().
> + *
> + * @return An AVMasteringDisplayMetadata filled with default values or NULL
> + * on failure.
> + */
> +AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc_size(size_t
> *size);
> +
> /**
> * Allocate a complete AVMasteringDisplayMetadata and add it to the frame.
> *
Instead of this we should have a generic allocator like
void *av_frame_side_data_allocate(enum AVFrameSideDataType, size_t
*size, size_t elem_count), with the latter being used for the allocators
that allocate arrays (like AVRegionOfInterest); it has to be set to zero
for the others. This will also avoid creating new
av_*_create_side_data() functions.
- 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/6 v2] avutil/mastering_display_metadata: add a new allocator function that returns a size
On 3/25/2024 5:40 PM, Andreas Rheinhardt wrote:
James Almer:
av_mastering_display_metadata_alloc() is not useful in scenarios where you need
to
know the runtime size of AVMasteringDisplayMetadata.
Signed-off-by: James Almer
---
libavutil/mastering_display_metadata.c | 13 +
libavutil/mastering_display_metadata.h | 9 +
2 files changed, 22 insertions(+)
diff --git a/libavutil/mastering_display_metadata.c
b/libavutil/mastering_display_metadata.c
index 6069347617..ea41f13f9d 100644
--- a/libavutil/mastering_display_metadata.c
+++ b/libavutil/mastering_display_metadata.c
@@ -18,6 +18,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
*/
+#include
#include
#include
@@ -29,6 +30,18 @@ AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc(void)
return av_mallocz(sizeof(AVMasteringDisplayMetadata));
}
+AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc_size(size_t *size)
+{
+AVMasteringDisplayMetadata *mastering =
av_mallocz(sizeof(AVMasteringDisplayMetadata));
+if (!mastering)
+return NULL;
+
+if (size)
+*size = sizeof(*mastering);
+
+return mastering;
+}
+
AVMasteringDisplayMetadata
*av_mastering_display_metadata_create_side_data(AVFrame *frame)
{
AVFrameSideData *side_data = av_frame_new_side_data(frame,
diff --git a/libavutil/mastering_display_metadata.h
b/libavutil/mastering_display_metadata.h
index c23b07c3cd..52fcef9e37 100644
--- a/libavutil/mastering_display_metadata.h
+++ b/libavutil/mastering_display_metadata.h
@@ -77,6 +77,15 @@ typedef struct AVMasteringDisplayMetadata {
*/
AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc(void);
+/**
+ * Allocate an AVMasteringDisplayMetadata structure and set its fields to
+ * default values. The resulting struct can be freed using av_freep().
+ *
+ * @return An AVMasteringDisplayMetadata filled with default values or NULL
+ * on failure.
+ */
+AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc_size(size_t
*size);
+
/**
* Allocate a complete AVMasteringDisplayMetadata and add it to the frame.
*
Instead of this we should have a generic allocator like
void *av_frame_side_data_allocate(enum AVFrameSideDataType, size_t
*size, size_t elem_count), with the latter being used for the allocators
that allocate arrays (like AVRegionOfInterest); it has to be set to zero
for the others. This will also avoid creating new
av_*_create_side_data() functions.
I don't mind a function like that being added to simplify future
additions, but this API is orthogonal to the frame side data one. It's
also used in packets, for example, and right now lavf is using
sizeof(AVMasteringDisplayMetadata) because
av_mastering_display_metadata_alloc() is not useful.
- 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".
___
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/6 v2] avutil/mastering_display_metadata: add a new allocator function that returns a size
James Almer:
> On 3/25/2024 5:40 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> av_mastering_display_metadata_alloc() is not useful in scenarios
>>> where you need to
>>> know the runtime size of AVMasteringDisplayMetadata.
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> libavutil/mastering_display_metadata.c | 13 +
>>> libavutil/mastering_display_metadata.h | 9 +
>>> 2 files changed, 22 insertions(+)
>>>
>>> diff --git a/libavutil/mastering_display_metadata.c
>>> b/libavutil/mastering_display_metadata.c
>>> index 6069347617..ea41f13f9d 100644
>>> --- a/libavutil/mastering_display_metadata.c
>>> +++ b/libavutil/mastering_display_metadata.c
>>> @@ -18,6 +18,7 @@
>>> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>>> 02110-1301 USA
>>> */
>>> +#include
>>> #include
>>> #include
>>> @@ -29,6 +30,18 @@ AVMasteringDisplayMetadata
>>> *av_mastering_display_metadata_alloc(void)
>>> return av_mallocz(sizeof(AVMasteringDisplayMetadata));
>>> }
>>> +AVMasteringDisplayMetadata
>>> *av_mastering_display_metadata_alloc_size(size_t *size)
>>> +{
>>> + AVMasteringDisplayMetadata *mastering =
>>> av_mallocz(sizeof(AVMasteringDisplayMetadata));
>>> + if (!mastering)
>>> + return NULL;
>>> +
>>> + if (size)
>>> + *size = sizeof(*mastering);
>>> +
>>> + return mastering;
>>> +}
>>> +
>>> AVMasteringDisplayMetadata
>>> *av_mastering_display_metadata_create_side_data(AVFrame *frame)
>>> {
>>> AVFrameSideData *side_data = av_frame_new_side_data(frame,
>>> diff --git a/libavutil/mastering_display_metadata.h
>>> b/libavutil/mastering_display_metadata.h
>>> index c23b07c3cd..52fcef9e37 100644
>>> --- a/libavutil/mastering_display_metadata.h
>>> +++ b/libavutil/mastering_display_metadata.h
>>> @@ -77,6 +77,15 @@ typedef struct AVMasteringDisplayMetadata {
>>> */
>>> AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc(void);
>>> +/**
>>> + * Allocate an AVMasteringDisplayMetadata structure and set its
>>> fields to
>>> + * default values. The resulting struct can be freed using av_freep().
>>> + *
>>> + * @return An AVMasteringDisplayMetadata filled with default values
>>> or NULL
>>> + * on failure.
>>> + */
>>> +AVMasteringDisplayMetadata
>>> *av_mastering_display_metadata_alloc_size(size_t *size);
>>> +
>>> /**
>>> * Allocate a complete AVMasteringDisplayMetadata and add it to the
>>> frame.
>>> *
>>
>> Instead of this we should have a generic allocator like
>> void *av_frame_side_data_allocate(enum AVFrameSideDataType, size_t
>> *size, size_t elem_count), with the latter being used for the allocators
>> that allocate arrays (like AVRegionOfInterest); it has to be set to zero
>> for the others. This will also avoid creating new
>> av_*_create_side_data() functions.
>
> I don't mind a function like that being added to simplify future
> additions, but this API is orthogonal to the frame side data one. It's
> also used in packets, for example, and right now lavf is using
> sizeof(AVMasteringDisplayMetadata) because
> av_mastering_display_metadata_alloc() is not useful.
>
The API proposed by me is supposed to make API like
av_mastering_display_metadata_alloc_size() redundant and therefore these
two additions are not orthogonal.
- 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] Fixes #10509
>
>
>
On Mon, Mar 25, 2024 at 2:04 AM Marton Balint wrote:
>
>
> On Sun, 24 Mar 2024, Poorva wrote:
>
> > From 0874a55ad33bb4df2789cbafc5247c0ae3d97e6a Mon Sep 17 00:00:00 2001
> > From: PoorvaGaikar
> > Date: Sat, 9 Mar 2024 00:27:25 +0530
> > Subject: [PATCH v2] avfilter/f_select.c: add support for iw and ih
> constants
>
> You should mention the fixed ticket number in the commit message.
>
> >
> > ---
> > doc/filters.texi | 6 ++
> > libavfilter/f_select.c | 14 ++
> > 2 files changed, 20 insertions(+)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 913365671d..e73dc9c1bf 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -30737,6 +30737,12 @@ missing.
> > That basically means that an input frame is selected if its pts is
> within the
> > interval set by the concat demuxer.
> >
> > +@item iw @emph{(video only)}
> > +Represents the width of the input video frame
> > +
> > +@item ih @emph{(video only)}
> > +Represents the height of the input video frame
> > +
> > @end table
> >
> > The default value of the select expression is "1".
> > diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
> > index 9b330a0673..ccfe915ee1 100644
> > --- a/libavfilter/f_select.c
> > +++ b/libavfilter/f_select.c
> > @@ -90,6 +90,9 @@ static const char *const var_names[] = {
> >
> > "concatdec_select", ///< frame is within the interval set by the
> concat demuxer
> >
> > +"ih",///< ih: Represents the height of the input
> video frame.
> > +"iw",///< iw: Represents the width of the input
> video frame.
> > +
> > NULL
> > };
> >
> > @@ -144,6 +147,9 @@ enum var_name {
> >
> > VAR_CONCATDEC_SELECT,
> >
> > +VAR_IH,
> > +VAR_IW,
> > +
> > VAR_VARS_NB
> > };
> >
> > @@ -264,6 +270,9 @@ static int config_input(AVFilterLink *inlink)
> > select->var_values[VAR_CONSUMED_SAMPLES_N] = NAN;
> > select->var_values[VAR_SAMPLES_N] = NAN;
> >
> > +select->var_values[VAR_IH] = NAN;
> > +select->var_values[VAR_IW] = NAN;
> > +
> > select->var_values[VAR_SAMPLE_RATE] =
> > inlink->type == AVMEDIA_TYPE_AUDIO ? inlink->sample_rate : NAN;
> >
> > @@ -370,6 +379,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > }
> > break;
> > }
> > +if (inlink->type == AVMEDIA_TYPE_VIDEO){
> > +select->var_values[VAR_IH] = frame->height;
> > +select->var_values[VAR_IW] = frame->width;
> > +}
>
> There is a switch(inlink->type) just above this, so you should put these
> there to the corresponding case AVMEDIA_TYPE_VIDEO, and not create a new
> block.
>
>
> > select->select = res = av_expr_eval(select->expr,
> select->var_values, NULL);
> > av_log(inlink->dst, AV_LOG_DEBUG,
> > @@ -546,3 +559,4 @@ const AVFilter ff_vf_select = {
> > .flags = AVFILTER_FLAG_DYNAMIC_OUTPUTS |
> AVFILTER_FLAG_METADATA_ONLY,
> > };
> > #endif /* CONFIG_SELECT_FILTER */
> > +
>
> This is still an uneeded newline.
>
Thank you for your feedback on the Git patch I submitted for review.
I have rectified the problem by adding the necessary changes .
The updated patch file is attached for your review.
>
>
> 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".
>
v3-0001-avfilter-f_select.c-add-support-for-iw-and-ih-con.patch
Description: Binary data
___
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] 7.0 blocking issues
On Mon, Mar 25, 2024 at 09:20:25PM +0100, Lynne wrote: > Mar 25, 2024, 14:50 by ffm...@haasn.xyz: > > > On Mon, 25 Mar 2024 07:20:56 +0100 "Jean-Baptiste Kempf" > > wrote: > > > >> Hello, > >> > >> On Mon, 25 Mar 2024, at 01:03, Michael Niedermayer wrote: > >> > Should i wait till all issues marked as blocking 7.0 on trac are fixed > >> > before branching ? > >> > >> I think you should branch now. > >> And get things fixed in the 7.0 branch. > >> > > > > +1 > > > > This is a big change and some breakage is inevitable. Most bugs will > > probably only be found once the software is released and deployed. > > > > When a big milestone gets bogged down by months (if not years) of > > "blocking bugs", my understanding is that it will simply never get > > released, and users might as well resort to using git master / nightly > > builds at that point. > > > > (Any possible allusion to *other* big open source software projects is > > purely coincidental) > > > > +1, we should branch so we can unblock master from receiving ok, ill make the branch within the next 24h probably We do have several open security issues still though (some have patches on the ML) I still have to check if ossfuzz is hiding any issues in unrelated tickets (ossfuzz did that often previously and this can unveil surprises) Also iam behind with backporting security fixes to release branches, (this may seem unrelated but it isnt because i always try to backport each of my security fixes to all branches we still maintain at the same time, so id like to get the other branches uptodate with backports to keep backports in sync with a new 7.0) All in all, iam not sure I will manage to release 7.0 in 7 days but ill do the branch and we will see. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: PGP signature ___ 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 2/2] lavc/get_buffer: Add a warning on failed allocation from a fixed pool
On 25/03/2024 07:35, Xiang, Haihao wrote: On Di, 2024-03-19 at 22:52 +, Mark Thompson wrote: On 19/03/2024 04:16, Xiang, Haihao wrote: On Ma, 2024-03-18 at 21:33 +, Mark Thompson wrote: On 18/03/2024 05:53, Xiang, Haihao wrote: On So, 2024-03-17 at 20:51 +, Mark Thompson wrote: For hardware cases where we are forced to have a fixed pool of frames allocated up-front (such as array textures on decoder output), suggest a possible workaround to the user if an allocation fails because the pool is exhausted. --- Perhaps helpful; any thoughts? The warning comes out before any errors, looking like: [mpeg2video @ 0x560ff51b4600] Failed to allocate a vaapi/nv12 frame from a fixed pool of hardware frames. [mpeg2video @ 0x560ff51b4600] Consider setting extra_hw_frames to a larger value (currently set to 8, giving a pool size of 14). [mpeg2video @ 0x560ff51b4600] get_buffer() failed [vist#0:0/mpeg2video @ 0x560ff5199840] [dec:mpeg2video @ 0x560ff51b3b40] Error submitting packet to decoder: Operation not permitted I'm OK to print such warning so user may know how to work around it. But now many cases are impacted by this error (e.g. https://trac.ffmpeg.org/ticket/10856 ), I think it is a regression to user. I still prefer to use a dynamic buffer pool instead fixed frame pool to avoid such error when the dynamic buffer pool can work. How would we implement this on D3D11 or D3D12? I understand not all can support dynamic frame pool, your patch is useful for decoders using fixed pool. But for driver which doesn't require array textures, I think we'd be better to use dynamic frame pool instead so user needn't worry about frame allocation. For example, we may use dynamic frame pool for vaapi with iHD driver, what do you think about adding a quirk to enable dynamic frame pool for special drivers ? I think we should come to a conclusion on what the generic code for this case should be and then consider whether any special cases are needed. When compared to the state right now, I agree with you that just switching VAAPI to always be dynamic would probably be better just to avoid the nasty failures, but given that we need to improve the situation for cases (like D3D11) where we don't have an ad-hoc workaround we should be comparing to whatever that concludes rather than the broken state right now. Hi Mark, I agree with you. Will you push this patch ? We may switch to dynamic frame pool for vaapi cases later after pushing your patch. Ok, pushed. Thoughts: * Passthrough filter chains can have the two queues worth of frames stored (when e.g. only editing metadata). * Possibly fixable by just doubling the extra frames added? That seems very clumsy. * Filters have no idea how big to make a pool when it is fixed. * lavfi would need negotiation backwards through the whole graph to make this work. * Encoders have no way to signal that they want to hold on to more frames. * New API needed? * Without negotiation in lavfi it would be hard to work out in ffmpeg /which/ pool to increase the size of in the presence of nontrivial filter graphs, though. * V4L2 M2M decode does not use hwcontext, but suffers from the same problems with a fixed pool. * Not updated since e0da916, probably broken by it in some cases. (Does warn with the ad-hoc workaround option "num_capture_buffers".) * Does anyone ever use this in the ffmpeg utility? Thanks, - Mark ___ 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/6 v2] avutil/mastering_display_metadata: add a new allocator function that returns a size
On 3/25/2024 6:02 PM, Andreas Rheinhardt wrote:
James Almer:
On 3/25/2024 5:40 PM, Andreas Rheinhardt wrote:
James Almer:
av_mastering_display_metadata_alloc() is not useful in scenarios
where you need to
know the runtime size of AVMasteringDisplayMetadata.
Signed-off-by: James Almer
---
libavutil/mastering_display_metadata.c | 13 +
libavutil/mastering_display_metadata.h | 9 +
2 files changed, 22 insertions(+)
diff --git a/libavutil/mastering_display_metadata.c
b/libavutil/mastering_display_metadata.c
index 6069347617..ea41f13f9d 100644
--- a/libavutil/mastering_display_metadata.c
+++ b/libavutil/mastering_display_metadata.c
@@ -18,6 +18,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA
*/
+#include
#include
#include
@@ -29,6 +30,18 @@ AVMasteringDisplayMetadata
*av_mastering_display_metadata_alloc(void)
return av_mallocz(sizeof(AVMasteringDisplayMetadata));
}
+AVMasteringDisplayMetadata
*av_mastering_display_metadata_alloc_size(size_t *size)
+{
+ AVMasteringDisplayMetadata *mastering =
av_mallocz(sizeof(AVMasteringDisplayMetadata));
+ if (!mastering)
+ return NULL;
+
+ if (size)
+ *size = sizeof(*mastering);
+
+ return mastering;
+}
+
AVMasteringDisplayMetadata
*av_mastering_display_metadata_create_side_data(AVFrame *frame)
{
AVFrameSideData *side_data = av_frame_new_side_data(frame,
diff --git a/libavutil/mastering_display_metadata.h
b/libavutil/mastering_display_metadata.h
index c23b07c3cd..52fcef9e37 100644
--- a/libavutil/mastering_display_metadata.h
+++ b/libavutil/mastering_display_metadata.h
@@ -77,6 +77,15 @@ typedef struct AVMasteringDisplayMetadata {
*/
AVMasteringDisplayMetadata *av_mastering_display_metadata_alloc(void);
+/**
+ * Allocate an AVMasteringDisplayMetadata structure and set its
fields to
+ * default values. The resulting struct can be freed using av_freep().
+ *
+ * @return An AVMasteringDisplayMetadata filled with default values
or NULL
+ * on failure.
+ */
+AVMasteringDisplayMetadata
*av_mastering_display_metadata_alloc_size(size_t *size);
+
/**
* Allocate a complete AVMasteringDisplayMetadata and add it to the
frame.
*
Instead of this we should have a generic allocator like
void *av_frame_side_data_allocate(enum AVFrameSideDataType, size_t
*size, size_t elem_count), with the latter being used for the allocators
that allocate arrays (like AVRegionOfInterest); it has to be set to zero
for the others. This will also avoid creating new
av_*_create_side_data() functions.
I don't mind a function like that being added to simplify future
additions, but this API is orthogonal to the frame side data one. It's
also used in packets, for example, and right now lavf is using
sizeof(AVMasteringDisplayMetadata) because
av_mastering_display_metadata_alloc() is not useful.
The API proposed by me is supposed to make API like
av_mastering_display_metadata_alloc_size() redundant and therefore these
two additions are not orthogonal.
Just because there's a frame side data type for MDM does not make the
new alloc function redundant. The frame side data API is one API
wrapping others. You don't see code using the AVHash API when they only
care about AVMD5. MDM is and should be standalone.
av_mastering_display_metadata_alloc() should be deprecated and removed
after this, too. That will ensure we still have a single symbol for this.
Regarding the av_*_create_side_data() functions, they were never needed.
They are a convenient wrapper/shortcut, and your
av_frame_side_data_allocate() would not really replace them as you'd
still need to use av_frame_add_side_data() afterwards.
___
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 00/21] aarch64: hevc: Add missing hevc_pel NEON functions
On Mon, 25 Mar 2024, Martin Storsjö wrote: Since some time, we have pretty complete AArch64 NEON coverage for the hevc decoder. However, some of these functions require the I8MM instruction set extension, and many of them (but not all) lack a plain NEON version. This patchset fills in a regular NEON version of all functions where we have an I8MM function. For context; the I8MM instruction set extension is a mandatory part of armv8.6-a. E.g. Apple M2, AWS Graviton 3 have it, but Apple M1 and Ampere Altra don't. This patchset takes decoding of a 1080p HEVC clip from 402 fps to 649 fps on an Apple M1. Patch #2 also fixes a subtle bug in the existing implementation; two functions relied on the contents on the stack, below the stack pointer, being untouched within a function. If a signal gets delivered, those parts of the stack could be clobbered. I know this is a bit short notice for a patchset of this size - but, would people be OK with merging this patchset before the impending 7.0 branch (which is made within the next 24h)? The patches pass all my tricky build configurations, they give a very non-negligible speedup on many common CPUs, and patch #2 fixes a real bug in the existing impleemntations. (A bug fix patch can of course be backported after the branch too, but performance optimizations aren't generally relevant for backporting.) // Martin ___ 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] 7.0 blocking issues
On Mon, 25 Mar 2024 at 21:10, Michael Niedermayer wrote: > On Mon, Mar 25, 2024 at 09:20:25PM +0100, Lynne wrote: > > Mar 25, 2024, 14:50 by ffm...@haasn.xyz: > > > > > On Mon, 25 Mar 2024 07:20:56 +0100 "Jean-Baptiste Kempf" < > j...@videolan.org> wrote: > > > > > >> Hello, > > >> > > >> On Mon, 25 Mar 2024, at 01:03, Michael Niedermayer wrote: > > >> > Should i wait till all issues marked as blocking 7.0 on trac are > fixed > > >> > before branching ? > > >> > > >> I think you should branch now. > > >> And get things fixed in the 7.0 branch. > > >> > > > > > > +1 > > > > > > This is a big change and some breakage is inevitable. Most bugs will > > > probably only be found once the software is released and deployed. > > > > > > When a big milestone gets bogged down by months (if not years) of > > > "blocking bugs", my understanding is that it will simply never get > > > released, and users might as well resort to using git master / nightly > > > builds at that point. > > > > > > (Any possible allusion to *other* big open source software projects is > > > purely coincidental) > > > > > > > +1, we should branch so we can unblock master from receiving > > ok, ill make the branch within the next 24h probably > > We do have several open security issues still though (some have patches on > the ML) > > I still have to check if ossfuzz is hiding any issues in unrelated tickets > (ossfuzz did that often previously and this can unveil surprises) > > Also iam behind with backporting security fixes to release branches, > (this may seem unrelated but it isnt because i always try to backport > each of my security fixes to all branches we still maintain at the same > time, > so id like to get the other branches uptodate with backports to keep > backports > in sync with a new 7.0) > Have you considered making a particular release an LTS so you don't have to backport to so many branches? Kieran ___ 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 03/10] avutil/common: Don't auto-include mem.h
On Mon, Mar 25, 2024 at 02:53:17AM +0100, Andreas Rheinhardt wrote: > There are lots of files that don't need it: The number of object > files that actually need it went down from 2011 to 884 here. > > Keep it for external users in order to not cause breakages. > > Also improve the other headers a bit while just at it. breaks mips build: src/libavformat/asfdec_f.c: In function ‘asf_read_stream_properties’: src/libavformat/asfdec_f.c:438:38: error: implicit declaration of function ‘av_bswap32’; did you mean ‘av_escape’? [-Werror=implicit-function-declaration] asf_st->palette[i] = av_bswap32(((uint32_t *)st->codecpar->extradata)[i]); ^~ av_escape cc1: some warnings being treated as errors src/ffbuild/common.mak:81: recipe for target 'libavformat/asfdec_f.o' failed make: *** [libavformat/asfdec_f.o] Error 1 make: *** Waiting for unfinished jobs [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: PGP signature ___ 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] avformat/dvdvideodec: add explicit inttypes.h include
Since log statements printing int64 were made portable in 4464b7eeb194e98ac115f18d2b6be67361407c8a, let us include inttypes.h explicitly (as it is unclear where PRId64 and such are coming from now). Reported-by: Traneptora Signed-off-by: Marth64 --- libavformat/dvdvideodec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c index 761ac97ec6..4959edab5c 100644 --- a/libavformat/dvdvideodec.c +++ b/libavformat/dvdvideodec.c @@ -30,6 +30,8 @@ * 7) Close the dvdnav VM, and free dvdread's IFO structures */ +#include + #include #include #include -- 2.34.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] avformat/dvdvideodec: add explicit inttypes.h include
v2 on the way. ___ 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 03/10] avutil/common: Don't auto-include mem.h
Michael Niedermayer: > On Mon, Mar 25, 2024 at 02:53:17AM +0100, Andreas Rheinhardt wrote: >> There are lots of files that don't need it: The number of object >> files that actually need it went down from 2011 to 884 here. >> >> Keep it for external users in order to not cause breakages. >> >> Also improve the other headers a bit while just at it. > > breaks mips build: > > src/libavformat/asfdec_f.c: In function ‘asf_read_stream_properties’: > src/libavformat/asfdec_f.c:438:38: error: implicit declaration of function > ‘av_bswap32’; did you mean ‘av_escape’? > [-Werror=implicit-function-declaration] > asf_st->palette[i] = av_bswap32(((uint32_t > *)st->codecpar->extradata)[i]); > ^~ > av_escape > cc1: some warnings being treated as errors > src/ffbuild/common.mak:81: recipe for target 'libavformat/asfdec_f.o' failed > make: *** [libavformat/asfdec_f.o] Error 1 > make: *** Waiting for unfinished jobs > Thanks. There is a #if HAVE_BIGENDIAN that uses swaps which I did not recognize. I will fix and test this patch on more arches, including BE ones. - 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 13/13] fftools/ffmpeg_mux_init: Fix double-free on error
I had actually applied this patch while looking into a ticket near the same code path. LGTM. ___ 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 00/21] aarch64: hevc: Add missing hevc_pel NEON functions
> On Mon, 25 Mar 2024, Martin Storsjö wrote: > >> Since some time, we have pretty complete AArch64 NEON coverage >> for the hevc decoder. >> >> However, some of these functions require the I8MM instruction set >> extension, and many of them (but not all) lack a plain NEON >> version. >> >> This patchset fills in a regular NEON version of all functions >> where we have an I8MM function. >> >> For context; the I8MM instruction set extension is a mandatory >> part of armv8.6-a. E.g. Apple M2, AWS Graviton 3 have it, >> but Apple M1 and Ampere Altra don't. >> >> This patchset takes decoding of a 1080p HEVC clip from 402 >> fps to 649 fps on an Apple M1. >> >> Patch #2 also fixes a subtle bug in the existing implementation; >> two functions relied on the contents on the stack, below the >> stack pointer, being untouched within a function. If a signal >> gets delivered, those parts of the stack could be clobbered. > > I know this is a bit short notice for a patchset of this size - but, would > people be OK with merging this patchset before the impending 7.0 branch > (which is made within the next 24h)? > > The patches pass all my tricky build configurations, they give a very > non-negligible speedup on many common CPUs, and patch #2 fixes a real bug in > the existing impleemntations. (A bug fix patch can of course be backported > after the branch too, but performance optimizations aren't generally relevant > for backporting.) > > // Martin Yes, please. I will tomorrow morning if you didn’t already push. -- jd ___ 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] 7.0 blocking issues
On Mon, Mar 25, 2024 at 09:18:09PM +, Kieran Kunhya wrote: > On Mon, 25 Mar 2024 at 21:10, Michael Niedermayer > wrote: > > > On Mon, Mar 25, 2024 at 09:20:25PM +0100, Lynne wrote: > > > Mar 25, 2024, 14:50 by ffm...@haasn.xyz: > > > > > > > On Mon, 25 Mar 2024 07:20:56 +0100 "Jean-Baptiste Kempf" < > > j...@videolan.org> wrote: > > > > > > > >> Hello, > > > >> > > > >> On Mon, 25 Mar 2024, at 01:03, Michael Niedermayer wrote: > > > >> > Should i wait till all issues marked as blocking 7.0 on trac are > > fixed > > > >> > before branching ? > > > >> > > > >> I think you should branch now. > > > >> And get things fixed in the 7.0 branch. > > > >> > > > > > > > > +1 > > > > > > > > This is a big change and some breakage is inevitable. Most bugs will > > > > probably only be found once the software is released and deployed. > > > > > > > > When a big milestone gets bogged down by months (if not years) of > > > > "blocking bugs", my understanding is that it will simply never get > > > > released, and users might as well resort to using git master / nightly > > > > builds at that point. > > > > > > > > (Any possible allusion to *other* big open source software projects is > > > > purely coincidental) > > > > > > > > > > +1, we should branch so we can unblock master from receiving > > > > ok, ill make the branch within the next 24h probably > > > > We do have several open security issues still though (some have patches on > > the ML) > > > > I still have to check if ossfuzz is hiding any issues in unrelated tickets > > (ossfuzz did that often previously and this can unveil surprises) > > > > Also iam behind with backporting security fixes to release branches, > > (this may seem unrelated but it isnt because i always try to backport > > each of my security fixes to all branches we still maintain at the same > > time, > > so id like to get the other branches uptodate with backports to keep > > backports > > in sync with a new 7.0) > > > > Have you considered making a particular release an LTS so you don't have to > backport to so many branches? The work is proportional to the number of patches in master to backport and approximately proportional to the amount of conflicts in the oldest branch OTOH adding 5 more release branches between existing ones doesnt make a big difference, because if the patch conflicts nowhere theres nothing extra to do and if it does conflict in one branch whatever needs to be done i do once not twice if a 2nd branch has the same reason for a conflict. fewer branches would just reduce the work on the tarball making and testing side. So while marking releases "LTS" is not a bad idea. It wouldnt reduce the backporting work by a noticable amount i think thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: PGP signature ___ 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] fate: fix sub2video_{basic, time_limited} on big-endian targets
Hi, On Fri, Mar 8, 2024, 10:11 Sean McGovern wrote: > On Wed, Mar 6, 2024, 18:48 Sean McGovern wrote: > >> The reference file uses BGRA pixel format, so request it here. >> --- >> tests/fate/ffmpeg.mak | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak >> index 669c878c7f..77e93693b9 100644 >> --- a/tests/fate/ffmpeg.mak >> +++ b/tests/fate/ffmpeg.mak >> @@ -62,6 +62,7 @@ fate-sub2video: CMD = framecrc -auto_conversion_filters >> \ >> FATE_SAMPLES_FFMPEG-$(call FRAMECRC, VOBSUB, DVDSUB, SCALE_FILTER) += >> fate-sub2video_basic >> fate-sub2video_basic: CMD = framecrc -auto_conversion_filters \ >>-i $(TARGET_SAMPLES)/sub/vobsub.idx \ >> + -pix_fmt bgra \ >>-fps_mode passthrough -copyts \ >>-filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ >>-c:v rawvideo -threads 1 >> @@ -71,6 +72,7 @@ fate-sub2video_basic: CMD = framecrc >> -auto_conversion_filters \ >> FATE_SAMPLES_FFMPEG-$(call FRAMECRC, SUP, PGSSUB, SCALE_FILTER >> RAWVIDEO_ENCODER) += fate-sub2video_time_limited >> fate-sub2video_time_limited: CMD = framecrc -auto_conversion_filters \ >>-i $(TARGET_SAMPLES)/sub/pgs_sub.sup \ >> + -pix_fmt bgra \ >>-fps_mode passthrough -copyts \ >>-t 15 \ >>-filter_complex "sws_flags=+accurate_rnd+bitexact\;[0:s:0]scale" \ >> -- >> 2.39.2 > > Ping review again, I was rather hoping this could make it into 7.0. -- Sean McGovern ___ 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 1/2] avutil/timestamp: introduce av_ts_make_time_string2 for better precision
> On Sat, 23 Mar 2024, Marton Balint wrote:
>> av_ts_make_time_string() used "%.6g" format, but this format was losing
>> precision even when the timestamp to be printed was not that large. For
>> example
>> for 3 hours (10800) seconds, only 1 decimal digit was printed, which made
>> this
>> format inaccurate when it was used in e.g. the silencedetect filter. Other
>> detection filters printing timestamps had similar issues. Also time base
>> parameter of the function was *AVRational instead of AVRational.
>>
>> Resolve these problems by introducing a new function,
>> av_ts_make_time_string2().
>>
>> We change the used format to "%.*f", use a precision of 6, except when
>> printing
>> values near 0, in which case we calculate the precision dynamically to aim
>> for
>> a similar precision in normal form as with %.6g. No longer using scientific
>> representation can make parsing the timestamp easier for the users, we can
>> safely do this because the theoretical maximum of INT64_MAX*INT32_MAX still
>> fits into the string buffer in normal form.
>>
>> We somewhat imitate %g by trimming ending zeroes and the potential decimal
>> point characters. In order not to trim "inf" as well, we assume that the
>> decimal point string does not contain the letter "f". Note that depending on
>> printf %f implementation, we might trim "infinity" to "inf".
>>
>> Thanks for Allan Cady for bringing up this issue.
> Will apply the series, so it can make it into 7.0.
> Regards,
> Marton
This looks great. I ran the patch against my test program with a couple
dozen vectors of inputs, and it looks perfect to me.
Thanks to both of you Marton and Andreas for seeing this through. I
really appreciate it.
Allan
>>
>> Signed-off-by: Marton Balint
>> ---
>> doc/APIchanges | 5 +
>> libavutil/Makefile | 1 +
>> libavutil/timestamp.c | 36
>> libavutil/timestamp.h | 8
>> libavutil/version.h | 2 +-
>> 5 files changed, 51 insertions(+), 1 deletion(-)
>> create mode 100644 libavutil/timestamp.c
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index 2796b4d0c2..9c6fa381e1 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -2,6 +2,11 @@ The last version increases of all libraries were on
>> 2024-03-07
>>
>> API changes, most recent first:
>>
>> +2024-03-xx - xx - lavu 59.5.100 - timestamp.h
>> + Add av_ts_make_time_string2() for better timestamp precision, the new
>> + function accepts AVRational as time base instead of *AVRational, and is
>> not
>> + an inline function like its predecessor.
>> +
>> 2024-03-xx - xx - lavc 61.3.100 - jni.h
>> Add av_jni_set_android_app_ctx() and av_jni_get_android_app_ctx().
>>
>> diff --git a/libavutil/Makefile b/libavutil/Makefile
>> index 008fcfcd9c..6e6fa8d800 100644
>> --- a/libavutil/Makefile
>> +++ b/libavutil/Makefile
>> @@ -174,6 +174,7 @@ OBJS = adler32.o
>> \
>> threadmessage.o \
>> time.o \
>> timecode.o \
>> + timestamp.o \
>> tree.o \
>> twofish.o \
>> utils.o \
>> diff --git a/libavutil/timestamp.c b/libavutil/timestamp.c
>> new file mode 100644
>> index 00..2a3e3012a4
>> --- /dev/null
>> +++ b/libavutil/timestamp.c
>> @@ -0,0 +1,36 @@
>> +/*
>> + * 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 "timestamp.h"
>> +
>> +char *av_ts_make_time_string2(char *buf, int64_t ts, AVRational tb)
>> +{
>> + if (ts == AV_NOPTS_VALUE) {
>> + snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
>> + } else {
>> + double val = av_q2d(tb) * ts;
>> + double log = floor(log10(fabs(val)));
>> + int precision = (isfinite(log) && log < 0) ? -log + 5 : 6;
>> + int last = snprintf(buf, AV_TS_MAX_STRING_SIZE, "
Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb: Fix heap buffer overflow
On Mon, Mar 25, 2024 at 04:09:00PM +0800, Zhao Zhili wrote: > From: Zhao Zhili > > Fixes: out of array write > Fixes: > 64407/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_MP4TOANNEXB_fuzzer-4966763443650560 > > mp4toannexb_filter counts the number of bytes needed in the first > pass and allocate the memory, then do memcpy in the second pass. > Update sps/pps size in the loop makes the count invalid in the > case of SPS/PPS occur after IDR slice. This patch process in-band > SPS/PPS before the two pass loops. > --- > libavcodec/bsf/h264_mp4toannexb.c | 59 --- > 1 file changed, 46 insertions(+), 13 deletions(-) I confirm this fixes the testcase this or some other fix is needed for 7.0 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: PGP signature ___ 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 v4 1/2] avcodec/ccaption_dec: don't print multiple \an and \pos tags
This also fixes https://trac.ffmpeg.org/ticket/10927 (recently reported by a user) ___ 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] avformat/avidec: support huge durations
On Tue, Oct 03, 2023 at 08:53:33PM +0200, Michael Niedermayer wrote:
> On Tue, Oct 03, 2023 at 11:10:20AM +0200, Tomas Härdin wrote:
> > mån 2023-10-02 klockan 21:03 +0200 skrev Michael Niedermayer:
> > > On Mon, Oct 02, 2023 at 11:07:47AM +0200, Anton Khirnov wrote:
> > > > Quoting Michael Niedermayer (2023-10-01 00:28:56)
> > > > > On Sat, Sep 30, 2023 at 10:18:38PM +0200, Anton Khirnov wrote:
> > > > > > Quoting Michael Niedermayer (2023-09-30 16:31:43)
> > > > > > > On Sat, Sep 30, 2023 at 04:04:03PM +0200, Michael Niedermayer
> > > > > > > wrote:
> > > > > > > > On Sat, Sep 30, 2023 at 11:35:19AM +0200, Marton Balint
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Sat, 30 Sep 2023, Michael Niedermayer wrote:
> > > > > > > > >
> > > > > > > > > > Fixes: signed integer overflow: 109817402400 *
> > > > > > > > > > 301990077 cannot be represented in type 'long long'
> > > > > > > > > > Fixes: 51896/clusterfuzz-testcase-minimized-
> > > > > > > > > > ffmpeg_dem_AVI_fuzzer-6706191715139584
> > > > > > > > > >
> > > > > > > > > > Found-by: continuous fuzzing process
> > > > > > > > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > > > > > > > Signed-off-by: Michael Niedermayer
> > > > > > > > > >
> > > > > > > > > > ---
> > > > > > > > > > libavformat/avidec.c | 12 ++--
> > > > > > > > > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/libavformat/avidec.c
> > > > > > > > > > b/libavformat/avidec.c
> > > > > > > > > > index 00bd7a98a9d..cfc693842b7 100644
> > > > > > > > > > --- a/libavformat/avidec.c
> > > > > > > > > > +++ b/libavformat/avidec.c
> > > > > > > > > > @@ -27,6 +27,7 @@
> > > > > > > > > > #include "libavutil/avstring.h"
> > > > > > > > > > #include "libavutil/opt.h"
> > > > > > > > > > #include "libavutil/dict.h"
> > > > > > > > > > +#include "libavutil/integer.h"
> > > > > > > > > > #include "libavutil/internal.h"
> > > > > > > > > > #include "libavutil/intreadwrite.h"
> > > > > > > > > > #include "libavutil/mathematics.h"
> > > > > > > > > > @@ -476,7 +477,7 @@ static int
> > > > > > > > > > calculate_bitrate(AVFormatContext *s)
> > > > > > > > > > AVStream *st = s->streams[i];
> > > > > > > > > > FFStream *const sti = ffstream(st);
> > > > > > > > > > int64_t duration;
> > > > > > > > > > - int64_t bitrate;
> > > > > > > > > > + int64_t bitrate = 0;
> > > > > > > > > >
> > > > > > > > > > for (j = 0; j < sti->nb_index_entries; j++)
> > > > > > > > > > len += sti->index_entries[j].size;
> > > > > > > > > > @@ -484,7 +485,14 @@ static int
> > > > > > > > > > calculate_bitrate(AVFormatContext *s)
> > > > > > > > > > if (sti->nb_index_entries < 2 || st->codecpar-
> > > > > > > > > > >bit_rate > 0)
> > > > > > > > > > continue;
> > > > > > > > > > duration = sti->index_entries[j-1].timestamp -
> > > > > > > > > > sti->index_entries[0].timestamp;
> > > > > > > > > > - bitrate = av_rescale(8*len, st->time_base.den,
> > > > > > > > > > duration * st->time_base.num);
> > > > > > > > > > + if (INT64_MAX / duration >= st->time_base.num)
> > > > > > > > > > {
> > > > > > > > > > + bitrate = av_rescale(8*len, st-
> > > > > > > > > > >time_base.den, duration * st->time_base.num);
> > > > > > > > >
> > > > > > > > > Why not always use the AVInteger version? This is not
> > > > > > > > > performance sensitive
> > > > > > > > > as far as I see.
> > > > > > > >
> > > > > > > > We can, i will have to fix the rounding though so it
> > > > > > > > matches av_rescale()
> > > > > > >
> > > > > > > will apply this with just AVInteger and fixed rounding with
> > > > > > > my next push probably
> > > > > >
> > > > > > This seems MUCH less readable to me.
> > > > >
> > > > > we can add a av_rescale_2den()
> > > >
> > > > Won't av_rescale_q(len, (AVRational){8, duration}, st->time_base)
> > > > achieve the same effect?
> > >
> > > duration is 64bit AVRational is 32/32 bit, so i would expect that to
> > > not
> > > work.
> > > If duration was fitting in 32bit then duration * st->time_base.num
> > > would not
> > > have overflowed
> >
> > Maybe we need a 64/64-bit version of AVRational..
>
> Iam not convinced at this point that we need that.
> But its not hard to do, our AVInteger code will do any size integers by just
> changing a single number.
>
> The real annoyance is if you have 32/32 and 64/64 rationals then suddenly
> you need many functions to handle both. Sofar only a fuzzed file exceeded
> our 64 * 64 / 64 == 64 * 32/32 * 32/32 rescale in one place
> adding a 64 * 64 / (64 * 64) rescale would fix that one which seems more
> limited in spreading complexity through the codebase
Ill apply this below, because its undefined behavior and needs to be fixed.
If someone has a better solution please replace my code with it.
@@ -476,7 +477,7 @@ static int calculate_bitrate(A
Re: [FFmpeg-devel] [PATCH 4/6] avformat/cafdec: saturate start + size into 64bit
On Sat, Sep 30, 2023 at 06:32:07PM +0200, Michael Niedermayer wrote:
> On Fri, Sep 29, 2023 at 08:41:23PM -0300, James Almer wrote:
> > On 9/29/2023 8:19 PM, Michael Niedermayer wrote:
> > > Fixes: signed integer overflow: 64 + 9223372036854775803 cannot be
> > > represented in type 'long long'
> > > Fixes:
> > > 51896/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-6536881135550464
> > >
> > > Found-by: continuous fuzzing process
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavformat/cafdec.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavformat/cafdec.c b/libavformat/cafdec.c
> > > index e92e3279fc6..0e50a3cfe68 100644
> > > --- a/libavformat/cafdec.c
> > > +++ b/libavformat/cafdec.c
> > > @@ -435,7 +435,7 @@ static int read_packet(AVFormatContext *s, AVPacket
> > > *pkt)
> > > /* don't read past end of data chunk */
> > > if (caf->data_size > 0) {
> > > -left = (caf->data_start + caf->data_size) - avio_tell(pb);
> > > +left = av_sat_add64(caf->data_start, caf->data_size) -
> > > avio_tell(pb);
> >
> > avio_tell(pb) here is guaranteed to be bigger than caf->data_start, which is
> > the offset where the DATA chunk starts, so the result of this calculation
> > will be <= INT64_MAX even if you don't saturate it and instead cast it to
> > uint64_t. Nonetheless, if the DATA chunk ends at an offset that would not
> > fit in an int64_t, then we can't parse it to begin with due to AVIOContext
> > API limitations.
> >
>
> > Maybe we should just abort in read_header() if data_start + data_size >
> > INT64_MAX, instead of pretending we can parse the file, invalid or not, by
> > saturating values.
>
> yes ill try that
ossfuzz moved the testcases all to another unrelated issues (62276)
ill apply this as suggested with the check in read_header() below:
diff --git a/libavformat/cafdec.c b/libavformat/cafdec.c
index 72809fd1de2..07a2939a7a6 100644
--- a/libavformat/cafdec.c
+++ b/libavformat/cafdec.c
@@ -343,6 +343,9 @@ static int read_header(AVFormatContext *s)
avio_skip(pb, 4); /* edit count */
caf->data_start = avio_tell(pb);
caf->data_size = size < 0 ? -1 : size - 4;
+if (caf->data_start < 0 || caf->data_size > INT64_MAX -
caf->data_start)
+return AVERROR_INVALIDDATA;
+
if (caf->data_size > 0 && (pb->seekable & AVIO_SEEKABLE_NORMAL))
avio_skip(pb, caf->data_size);
found_data = 1;
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
signature.asc
Description: PGP signature
___
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 6/6] avformat/iff: Saturate avio_tell() + 12
On Sat, Sep 30, 2023 at 01:20:01AM +0200, Michael Niedermayer wrote: > Fixes: signed integer overflow: 9223372036854775796 + 12 cannot be > represented in type 'long long' > Fixes: > 51896/clusterfuzz-testcase-minimized-ffmpeg_dem_IFF_fuzzer-4898373660704768 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/iff.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply the patches from this patchset that have received no comments [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Homeopathy is like voting while filling the ballot out with transparent ink. Sometimes the outcome one wanted occurs. Rarely its worse than filling out a ballot properly. signature.asc Description: PGP signature ___ 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 v4 1/2] avcodec/ccaption_dec: don't print multiple \an and \pos tags
This should be withheld until after 7.0. In the same bug report it appears that 1 user is making use of the erroneous tags via an external script for a valid purpose. I don’t want to break people’s workflow even though it’s invalid ASS. After 7.0 I will revive this patchset and with additional fixes. I apologize for the inconvenience. Please don’t merge, and I’ll be more careful next time.. ___ 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 01/10] avformat/concatdec: Check user_duration sum
Fixes:
62276/clusterfuzz-testcase-minimized-ffmpeg_dem_CONCAT_fuzzer-6434245599690752
Fixes: signed integer overflow: 922337202677300 + 2233700 cannot be
represented in type 'long'
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/concatdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index ac541a592fa..f1401e43530 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -679,6 +679,8 @@ static int concat_read_header(AVFormatContext *avf)
cat->files[i].user_duration = cat->files[i].outpoint -
cat->files[i].inpoint;
}
cat->files[i].duration = cat->files[i].user_duration;
+if (time + (uint64_t)cat->files[i].user_duration > INT64_MAX)
+return AVERROR_INVALIDDATA;
time += cat->files[i].user_duration;
}
if (i == cat->nb_files) {
--
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] [PATCH 02/10] avformat/jacosubdec: Use 64bit for abs
Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself Fixes: 62276/clusterfuzz-testcase-minimized-ffmpeg_dem_JACOSUB_fuzzer-5401294942371840 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/jacosubdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/jacosubdec.c b/libavformat/jacosubdec.c index 447397b6a77..dabb298a264 100644 --- a/libavformat/jacosubdec.c +++ b/libavformat/jacosubdec.c @@ -150,7 +150,7 @@ static int get_shift(unsigned timeres, const char *buf) } ret = (int64_t)h*3600 + (int64_t)m*60 + s; -if (FFABS(ret) > (INT64_MAX - FFABS(d)) / timeres) +if (FFABS(ret) > (INT64_MAX - FFABS((int64_t)d)) / timeres) return 0; ret = sign * (ret * timeres + d); -- 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] [PATCH 03/10] avformat/mov: use 64bit for intermediate for rounding
Fixes: signed integer overflow: 1768972133 + 968491058 cannot be represented in type 'int' Fixes: 62276/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-4802790784303104 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/mov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index f954b924a02..e5e704caeb1 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -8993,7 +8993,7 @@ static int mov_read_timecode_track(AVFormatContext *s, AVStream *st) /* 60 fps content have tmcd_nb_frames set to 30 but tc_rate set to 60, so * we multiply the frame number with the quotient. * See tickets #9492, #9710. */ -rounded_tc_rate = (tc_rate.num + tc_rate.den / 2) / tc_rate.den; +rounded_tc_rate = (tc_rate.num + tc_rate.den / 2LL) / tc_rate.den; /* Work around files where tmcd_nb_frames is rounded down from frame rate * instead of up. See ticket #5978. */ if (tmcd_nb_frames == tc_rate.num / tc_rate.den && -- 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] [PATCH 04/10] avformat/timecode: use 64bit for intermediate for rounding in fps_from_frame_rate()
Fixes:
62276/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-4802790784303104
Fixes: signed integer overflow: 1768972133 + 968491058 cannot be represented in
type 'int'
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavutil/timecode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/timecode.c b/libavutil/timecode.c
index b93f05b4b82..bd879bd3cc0 100644
--- a/libavutil/timecode.c
+++ b/libavutil/timecode.c
@@ -210,7 +210,7 @@ static int fps_from_frame_rate(AVRational rate)
{
if (!rate.den || !rate.num)
return -1;
-return (rate.num + rate.den/2) / rate.den;
+return (rate.num + rate.den/2LL) / rate.den;
}
int av_timecode_check_frame_rate(AVRational rate)
--
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] [PATCH 05/10] avformat/rpl: Use 64bit for total_audio_size and check it
Fixes: 62276/clusterfuzz-testcase-minimized-ffmpeg_dem_RPL_fuzzer-4677434693517312 Fixes: signed integer overflow: 556 * 8 cannot be represented in type 'long long' Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/rpl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/libavformat/rpl.c b/libavformat/rpl.c index 3f10e51d482..09d0b68f748 100644 --- a/libavformat/rpl.c +++ b/libavformat/rpl.c @@ -118,7 +118,7 @@ static int rpl_read_header(AVFormatContext *s) AVIOContext *pb = s->pb; RPLContext *rpl = s->priv_data; AVStream *vst = NULL, *ast = NULL; -int total_audio_size; +int64_t total_audio_size; int error = 0; const char *endptr; char audio_type[RPL_LINE_LENGTH]; @@ -303,6 +303,8 @@ static int rpl_read_header(AVFormatContext *s) if (ast) av_add_index_entry(ast, offset + video_size, total_audio_size, audio_size, audio_size * 8, 0); +if (total_audio_size/8 + (uint64_t)audio_size >= INT64_MAX/8) +return AVERROR_INVALIDDATA; total_audio_size += audio_size * 8; } -- 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] [PATCH 06/10] avformat/sbgdec: Check for negative duration
Fixes: signed integer overflow: 9223372036854775807 - -800 cannot be
represented in type 'long'
Fixes:
62276/clusterfuzz-testcase-minimized-ffmpeg_dem_SBG_fuzzer-5133181743136768
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/sbgdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/sbgdec.c b/libavformat/sbgdec.c
index bc2469afd17..e60eb1481ea 100644
--- a/libavformat/sbgdec.c
+++ b/libavformat/sbgdec.c
@@ -387,7 +387,7 @@ static int parse_options(struct sbg_parser *p)
case 'L':
FORWARD_ERROR(parse_optarg(p, opt, &oarg));
r = str_to_time(oarg.s, &p->scs.opt_duration);
-if (oarg.e != oarg.s + r) {
+if (oarg.e != oarg.s + r || p->scs.opt_duration < 0) {
snprintf(p->err_msg, sizeof(p->err_msg),
"syntax error for option -L");
return AVERROR_INVALIDDATA;
--
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] [PATCH 07/10] avformat/wavdec: sanity check channels and bps before using them for block_align
Fixes:
62276/clusterfuzz-testcase-minimized-ffmpeg_dem_W64_fuzzer-4704044498944000
Fixes: signed integer overflow: 520464 * 8224 cannot be represented in type
'int'
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/wavdec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 668c8adc36b..89855670d9c 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -34,6 +34,7 @@
#include "libavutil/log.h"
#include "libavutil/mathematics.h"
#include "libavutil/opt.h"
+#include "libavcodec/internal.h"
#include "avformat.h"
#include "avio.h"
#include "avio_internal.h"
@@ -908,7 +909,9 @@ static int w64_read_header(AVFormatContext *s)
if (ret < 0)
return ret;
avio_skip(pb, FFALIGN(size, INT64_C(8)) - size);
-if (st->codecpar->block_align) {
+if (st->codecpar->block_align &&
+st->codecpar->ch_layout.nb_channels < FF_SANE_NB_CHANNELS &&
+st->codecpar->bits_per_coded_sample < 128) {
int block_align = st->codecpar->block_align;
block_align = FFMAX(block_align,
--
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] [PATCH 08/10] avformat/wavdec: satuarte next_tag_ofs, data_end
Fixes: signed integer overflow: 5053074104798691550 + 5053074104259715104
cannot be represented in type 'long'
Fixes:
62276/clusterfuzz-testcase-minimized-ffmpeg_dem_WAV_fuzzer-6515315309936640
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/wavdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 89855670d9c..0fed1ee6398 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -453,7 +453,7 @@ static int wav_read_header(AVFormatContext *s)
}
if (rf64 || bw64) {
-next_tag_ofs = wav->data_end = avio_tell(pb) + data_size;
+next_tag_ofs = wav->data_end = av_sat_add64(avio_tell(pb),
data_size);
} else if (size != 0x) {
data_size= size;
next_tag_ofs = wav->data_end = size ? next_tag_ofs : INT64_MAX;
--
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] [PATCH 09/10] avformat/matroskadec: Check timescale
Fixes: 3.82046e+18 is outside the range of representable values of type 'unsigned int' Fixes: 62276/clusterfuzz-testcase-minimized-ffmpeg_dem_WEBM_DASH_MANIFEST_fuzzer-6381436594421760 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/matroskadec.c | 4 1 file changed, 4 insertions(+) diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c index 8897fd622c6..8e031c618ba 100644 --- a/libavformat/matroskadec.c +++ b/libavformat/matroskadec.c @@ -3195,6 +3195,10 @@ static int matroska_parse_tracks(AVFormatContext *s) track->time_scale); track->time_scale = 1.0; } + +if (matroska->time_scale * track->time_scale > UINT_MAX) +return AVERROR_INVALIDDATA; + avpriv_set_pts_info(st, 64, matroska->time_scale * track->time_scale, 1000 * 1000 * 1000);/* 64 bit pts in ns */ -- 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] [PATCH 10/10] avformat/westwood_vqa: Fix 2g packets
Fixes: signed integer overflow: 2147483424 * 2 cannot be represented in type 'int' Fixes: 62276/clusterfuzz-testcase-minimized-ffmpeg_dem_WSVQA_fuzzer-4576211411795968 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/westwood_vqa.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/westwood_vqa.c b/libavformat/westwood_vqa.c index 954710a6f00..3a31e3f5e8e 100644 --- a/libavformat/westwood_vqa.c +++ b/libavformat/westwood_vqa.c @@ -262,7 +262,7 @@ static int wsvqa_read_packet(AVFormatContext *s, break; case SND2_TAG: /* 2 samples/byte, 1 or 2 samples per frame depending on stereo */ -pkt->duration = (chunk_size * 2) / wsvqa->channels; +pkt->duration = (chunk_size * 2LL) / wsvqa->channels; break; } break; -- 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".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/osq: avoid several signed integer overflows
On Tue, Dec 26, 2023 at 05:37:30PM +0100, Michael Niedermayer wrote: > Fixes: signed integer overflow: 178459578 + 2009763270 cannot be represented > in type 'int' > Fixes: > 62285/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-5013423686287360 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/osq.c | 24 > 1 file changed, 12 insertions(+), 12 deletions(-) will apply this and patch 3 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: PGP signature ___ 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] avformat/jacosubdec: clarify code
On Wed, Oct 11, 2023 at 08:10:14PM +0200, Michael Niedermayer wrote: > add comments, rename variables and indent things differently > > Is it clearer now ? > > Signed-off-by: Michael Niedermayer > --- > libavformat/jacosubdec.c | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threats related to an insecure 5G network, it needs to rethink the extent to which it values corporate profits and government espionage over security.-Bruce Schneier signature.asc Description: PGP signature ___ 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/2] libavformat/hls.c: support in-stream ID3 metadata update.
This patch adds support for updating HLS metadata passed as ID3 frames.
This seems like a pretty straight-forward improvement. Updating the
metadaata of the first stream seems to be the mechanism is other places
in the code and works as expected.
---
libavformat/hls.c | 54 ---
1 file changed, 32 insertions(+), 22 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index f6b44c2e35..ba6634d57a 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -93,6 +93,12 @@ enum PlaylistType {
PLS_TYPE_VOD
};
+#define ID3_PRIV_OWNER_TS "com.apple.streaming.transportStreamTimestamp"
+#define ID3_PRIV_OWNER_AUDIO_SETUP "com.apple.streaming.audioDescription"
+
+#define ID3v2_PRIV_OWNER_TS ID3v2_PRIV_METADATA_PREFIX ID3_PRIV_OWNER_TS
+#define ID3v2_PRIV_OWNER_AUDIO_SETUP ID3v2_PRIV_METADATA_PREFIX
ID3_PRIV_OWNER_AUDIO_SETUP
+
/*
* Each playlist has its own demuxer. If it currently is active,
* it has an open AVIOContext too, and potentially an AVPacket
@@ -150,9 +156,7 @@ struct playlist {
int64_t id3_offset; /* in stream original tb */
uint8_t* id3_buf; /* temp buffer for id3 parsing */
unsigned int id3_buf_size;
-AVDictionary *id3_initial; /* data from first id3 tag */
-int id3_found; /* ID3 tag found at some point */
-int id3_changed; /* ID3 tag data has changed at some point */
+AVDictionary *last_id3; /* data from the last id3 tag */
ID3v2ExtraMeta *id3_deferred_extra; /* stored here until subdemuxer is
opened */
HLSAudioSetupInfo audio_setup_info;
@@ -270,7 +274,7 @@ static void free_playlist_list(HLSContext *c)
av_freep(&pls->main_streams);
av_freep(&pls->renditions);
av_freep(&pls->id3_buf);
-av_dict_free(&pls->id3_initial);
+av_dict_free(&pls->last_id3);
ff_id3v2_free_extra_meta(&pls->id3_deferred_extra);
av_freep(&pls->init_sec_buf);
av_packet_free(&pls->pkt);
@@ -1083,15 +1087,13 @@ static void parse_id3(AVFormatContext *s, AVIOContext
*pb,
AVDictionary **metadata, int64_t *dts, HLSAudioSetupInfo
*audio_setup_info,
ID3v2ExtraMetaAPIC **apic, ID3v2ExtraMeta **extra_meta)
{
-static const char id3_priv_owner_ts[] =
"com.apple.streaming.transportStreamTimestamp";
-static const char id3_priv_owner_audio_setup[] =
"com.apple.streaming.audioDescription";
ID3v2ExtraMeta *meta;
ff_id3v2_read_dict(pb, metadata, ID3v2_DEFAULT_MAGIC, extra_meta);
for (meta = *extra_meta; meta; meta = meta->next) {
if (!strcmp(meta->tag, "PRIV")) {
ID3v2ExtraMetaPRIV *priv = &meta->data.priv;
-if (priv->datasize == 8 && !av_strncasecmp(priv->owner,
id3_priv_owner_ts, 44)) {
+if (priv->datasize == 8 && !av_strncasecmp(priv->owner,
ID3_PRIV_OWNER_TS, strlen(ID3_PRIV_OWNER_TS))) {
/* 33-bit MPEG timestamp */
int64_t ts = AV_RB64(priv->data);
av_log(s, AV_LOG_DEBUG, "HLS ID3 audio timestamp %"PRId64"\n",
ts);
@@ -1099,7 +1101,9 @@ static void parse_id3(AVFormatContext *s, AVIOContext *pb,
*dts = ts;
else
av_log(s, AV_LOG_ERROR, "Invalid HLS ID3 audio timestamp
%"PRId64"\n", ts);
-} else if (priv->datasize >= 8 && !av_strncasecmp(priv->owner,
id3_priv_owner_audio_setup, 36)) {
+} else if (priv->datasize >= 8 &&
+ !av_strncasecmp(priv->owner,
ID3_PRIV_OWNER_AUDIO_SETUP, 36) &&
+ audio_setup_info) {
ff_hls_senc_read_audio_setup_info(audio_setup_info,
priv->data, priv->datasize);
}
} else if (!strcmp(meta->tag, "APIC") && apic)
@@ -1113,9 +1117,10 @@ static int id3_has_changed_values(struct playlist *pls,
AVDictionary *metadata,
{
const AVDictionaryEntry *entry = NULL;
const AVDictionaryEntry *oldentry;
+
/* check that no keys have changed values */
while ((entry = av_dict_iterate(metadata, entry))) {
-oldentry = av_dict_get(pls->id3_initial, entry->key, NULL,
AV_DICT_MATCH_CASE);
+oldentry = av_dict_get(pls->last_id3, entry->key, NULL,
AV_DICT_MATCH_CASE);
if (!oldentry || strcmp(oldentry->value, entry->value) != 0)
return 1;
}
@@ -1143,35 +1148,40 @@ static void handle_id3(AVIOContext *pb, struct playlist
*pls)
ID3v2ExtraMetaAPIC *apic = NULL;
ID3v2ExtraMeta *extra_meta = NULL;
int64_t timestamp = AV_NOPTS_VALUE;
+// Only set audio_setup_info on first id3 chunk.
+HLSAudioSetupInfo *audio_setup_info = pls->last_id3 ? NULL :
&pls->audio_setup_info;
-parse_id3(pls->ctx, pb, &metadata, ×tamp, &pls->audio_setup_info,
&apic, &extra_meta);
+parse_id3(pls->ctx, pb, &metadata, ×tamp, audio_setup_info, &apic,
&extra_meta);
-if (timestamp != AV_NOPTS_VALUE) {
+if (pls->id3_mpegts_timestamp == AV_NOPTS_VALUE && timesta
[FFmpeg-devel] [PATCH 2/2] Add fate test for hls metadata update.
This patch adds a FATE test for the new HLS metadata update. The fate sample consists of a two segment AAC hls stream. The first segment has test title 1 as title metadata while the second has test title 2. In the log, we can see that test title 2 is reported for the stream, indicating that the metadata was updated with the second segment. Romain --- tests/fate/demux.mak | 3 + tests/ref/fate/hls-adts-meta-demux | 124 + 2 files changed, 127 insertions(+) create mode 100644 tests/ref/fate/hls-adts-meta-demux diff --git a/tests/fate/demux.mak b/tests/fate/demux.mak index d9b9045f0b..7243c2c163 100644 --- a/tests/fate/demux.mak +++ b/tests/fate/demux.mak @@ -160,6 +160,9 @@ fate-ts-demux: CMD = ffprobe_demux $(TARGET_SAMPLES)/ac3/mp3ac325-4864-small.ts FATE_FFPROBE_DEMUX-$(CONFIG_MPEGTS_DEMUXER) += fate-ts-timed-id3-demux fate-ts-timed-id3-demux: CMD = ffprobe_demux $(TARGET_SAMPLES)/mpegts/id3.ts +FATE_FFPROBE_DEMUX-$(CONFIG_MPEGTS_DEMUXER) += fate-hls-adts-meta-demux +fate-fate-hls-adts-meta-demux: CMD = ffprobe_demux $(TARGET_SAMPLES)/hls-adts-meta/stream.m3u8 + FATE_SAMPLES_DEMUX += $(FATE_SAMPLES_DEMUX-yes) FATE_SAMPLES_FFMPEG += $(FATE_SAMPLES_DEMUX) FATE_FFPROBE_DEMUX += $(FATE_FFPROBE_DEMUX-yes) diff --git a/tests/ref/fate/hls-adts-meta-demux b/tests/ref/fate/hls-adts-meta-demux new file mode 100644 index 00..ab944695fc --- /dev/null +++ b/tests/ref/fate/hls-adts-meta-demux @@ -0,0 +1,124 @@ +packet|codec_type=audio|stream_index=0|pts=3416400|pts_time=37.96|dts=3416400|dts_time=37.96|duration=2090|duration_time=0.023222|size=368|pos=0|flags=K__|data_hash=CRC32:c371b0d9 +packet|codec_type=audio|stream_index=0|pts=3418490|pts_time=37.983222|dts=3418490|dts_time=37.983222|duration=2090|duration_time=0.023222|size=390|pos=368|flags=K__|data_hash=CRC32:950c52b2 +packet|codec_type=audio|stream_index=0|pts=3420580|pts_time=38.006444|dts=3420580|dts_time=38.006444|duration=2090|duration_time=0.023222|size=357|pos=758|flags=K__|data_hash=CRC32:3e672212 +packet|codec_type=audio|stream_index=0|pts=3422669|pts_time=38.029656|dts=3422669|dts_time=38.029656|duration=2090|duration_time=0.023222|size=426|pos=1115|flags=K__|data_hash=CRC32:817b6e4c +packet|codec_type=audio|stream_index=0|pts=3424759|pts_time=38.052878|dts=3424759|dts_time=38.052878|duration=2090|duration_time=0.023222|size=368|pos=1541|flags=K__|data_hash=CRC32:c4c6e1ed +packet|codec_type=audio|stream_index=0|pts=3426849|pts_time=38.076100|dts=3426849|dts_time=38.076100|duration=2090|duration_time=0.023222|size=389|pos=1909|flags=K__|data_hash=CRC32:67cb6dd9 +packet|codec_type=audio|stream_index=0|pts=3428939|pts_time=38.099322|dts=3428939|dts_time=38.099322|duration=2090|duration_time=0.023222|size=352|pos=2298|flags=K__|data_hash=CRC32:7a56ff53 +packet|codec_type=audio|stream_index=0|pts=3431029|pts_time=38.122544|dts=3431029|dts_time=38.122544|duration=2090|duration_time=0.023222|size=378|pos=2650|flags=K__|data_hash=CRC32:f8d5ef58 +packet|codec_type=audio|stream_index=0|pts=3433118|pts_time=38.145756|dts=3433118|dts_time=38.145756|duration=2090|duration_time=0.023222|size=384|pos=3028|flags=K__|data_hash=CRC32:73a4fb1c +packet|codec_type=audio|stream_index=0|pts=3435208|pts_time=38.168978|dts=3435208|dts_time=38.168978|duration=2090|duration_time=0.023222|size=353|pos=3412|flags=K__|data_hash=CRC32:4ea999b5 +packet|codec_type=audio|stream_index=0|pts=3437298|pts_time=38.192200|dts=3437298|dts_time=38.192200|duration=2090|duration_time=0.023222|size=417|pos=3765|flags=K__|data_hash=CRC32:4540aec8 +packet|codec_type=audio|stream_index=0|pts=3439388|pts_time=38.215422|dts=3439388|dts_time=38.215422|duration=2090|duration_time=0.023222|size=361|pos=4182|flags=K__|data_hash=CRC32:635a04f4 +packet|codec_type=audio|stream_index=0|pts=3441478|pts_time=38.238644|dts=3441478|dts_time=38.238644|duration=2090|duration_time=0.023222|size=399|pos=4543|flags=K__|data_hash=CRC32:94583c18 +packet|codec_type=audio|stream_index=0|pts=3443567|pts_time=38.261856|dts=3443567|dts_time=38.261856|duration=2090|duration_time=0.023222|size=384|pos=4942|flags=K__|data_hash=CRC32:21070d79 +packet|codec_type=audio|stream_index=0|pts=3445657|pts_time=38.285078|dts=3445657|dts_time=38.285078|duration=2090|duration_time=0.023222|size=378|pos=5326|flags=K__|data_hash=CRC32:bd5beb97 +packet|codec_type=audio|stream_index=0|pts=3447747|pts_time=38.308300|dts=3447747|dts_time=38.308300|duration=2090|duration_time=0.023222|size=362|pos=5704|flags=K__|data_hash=CRC32:8bb15fb7 +packet|codec_type=audio|stream_index=0|pts=3449837|pts_time=38.331522|dts=3449837|dts_time=38.331522|duration=2090|duration_time=0.023222|size=365|pos=6066|flags=K__|data_hash=CRC32:a1801ece +packet|codec_type=audio|stream_index=0|pts=3451927|pts_time=38.354744|dts=3451927|dts_time=38.354744|duration=2090|duration_time=0.023222|size=390|pos=6431|flags=K__|data_hash=CRC32:8eb3880b +packet|codec_type=audio|stream_index=0|pts=3454016|pts_ti
Re: [FFmpeg-devel] [PATCH 2/3] avformat/mov: Do not deallocate heif_item in a input dependant way
On 3/22/2024 8:08 PM, Michael Niedermayer wrote: Fixes: out of array access Fixes: 67070/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5685384082161664 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavformat/mov.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index f954b924a0..a87ce5cefe 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -8077,7 +8077,7 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb, MOVAtom atom) } item_count = (version < 2) ? avio_rb16(pb) : avio_rb32(pb); -heif_item = av_realloc_array(c->heif_item, item_count, sizeof(*c->heif_item)); +heif_item = av_realloc_array(c->heif_item, FFMAX(item_count, c->nb_heif_item), sizeof(*c->heif_item)); if (!heif_item) return AVERROR(ENOMEM); c->heif_item = heif_item; @@ -8202,7 +8202,7 @@ static int mov_read_iinf(MOVContext *c, AVIOContext *pb, MOVAtom atom) avio_rb24(pb); // flags. entry_count = version ? avio_rb32(pb) : avio_rb16(pb); -heif_item = av_realloc_array(c->heif_item, entry_count, sizeof(*c->heif_item)); +heif_item = av_realloc_array(c->heif_item, FFMAX(entry_count, c->nb_heif_item), sizeof(*c->heif_item)); if (!heif_item) return AVERROR(ENOMEM); c->heif_item = heif_item; LGTM. ___ 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/mov: don't use cur_item_id as array index
Signed-off-by: James Almer
---
libavformat/mov.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index f954b924a0..9f2ea97a5b 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -8085,7 +8085,6 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
memset(c->heif_item + c->nb_heif_item, 0,
sizeof(*c->heif_item) * (item_count - c->nb_heif_item));
c->nb_heif_item = FFMAX(c->nb_heif_item, item_count);
-c->cur_item_id = 0;
av_log(c->fc, AV_LOG_TRACE, "iloc: item_count %d\n", item_count);
for (int i = 0; i < item_count; i++) {
@@ -8127,7 +8126,7 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return atom.size;
}
-static int mov_read_infe(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+static int mov_read_infe(MOVContext *c, AVIOContext *pb, MOVAtom atom, int idx)
{
AVBPrint item_name;
int64_t size = atom.size;
@@ -8164,21 +8163,19 @@ static int mov_read_infe(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
avio_skip(pb, size);
if (ret)
-av_bprint_finalize(&item_name, &c->heif_item[c->cur_item_id].name);
-c->heif_item[c->cur_item_id].item_id = item_id;
-c->heif_item[c->cur_item_id].type= item_type;
+av_bprint_finalize(&item_name, &c->heif_item[idx].name);
+c->heif_item[idx].item_id = item_id;
+c->heif_item[idx].type= item_type;
switch (item_type) {
case MKTAG('a','v','0','1'):
case MKTAG('h','v','c','1'):
-ret = heif_add_stream(c, &c->heif_item[c->cur_item_id]);
+ret = heif_add_stream(c, &c->heif_item[idx]);
if (ret < 0)
return ret;
break;
}
-c->cur_item_id++;
-
return 0;
}
@@ -8210,14 +8207,13 @@ static int mov_read_iinf(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
memset(c->heif_item + c->nb_heif_item, 0,
sizeof(*c->heif_item) * (entry_count - c->nb_heif_item));
c->nb_heif_item = FFMAX(c->nb_heif_item, entry_count);
-c->cur_item_id = 0;
for (int i = 0; i < entry_count; i++) {
MOVAtom infe;
infe.size = avio_rb32(pb) - 8;
infe.type = avio_rl32(pb);
-ret = mov_read_infe(c, pb, infe);
+ret = mov_read_infe(c, pb, infe, i);
if (ret < 0)
return ret;
}
--
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] Fwd: [PATCH] fftools/ffplay: split filters & show modes cycling into separate keys
I am forwarding a patch from December that seems to have been overlooked.
See the original threads in the archive:
https://ffmpeg.org/pipermail/ffmpeg-devel/2023-December/318613.html
https://ffmpeg.org/pipermail/ffmpeg-devel/2023-December/318654.html
Forwarded message from Ondřej Fiala on Tue Dec 19, 2023 at 3:02 AM:
---
It's annoying to have to go through the audio visualization modes when you
just want to switch back-and-forth between two video filters. It also makes
the code simpler.
doc/ffplay.texi | 5 -
fftools/ffplay.c | 10 --
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index 93f77eeece..91d138a974 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -241,8 +241,11 @@ Cycle subtitle channel in the current program.
@item c
Cycle program.
+@item d
+Cycle show modes.
+
@item w
-Cycle video filters or show modes.
+Cycle video filters.
@item s
Step to the next frame.
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 873ee8cc74..2eb616a88a 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -3370,14 +3370,12 @@ static void event_loop(VideoState *cur_stream)
case SDLK_t:
stream_cycle_channel(cur_stream, AVMEDIA_TYPE_SUBTITLE);
break;
+case SDLK_d:
+toggle_audio_display(cur_stream);
+break;
case SDLK_w:
-if (cur_stream->show_mode == SHOW_MODE_VIDEO &&
cur_stream->vfilter_idx < nb_vfilters - 1) {
-if (++cur_stream->vfilter_idx >= nb_vfilters)
-cur_stream->vfilter_idx = 0;
-} else {
+if (++cur_stream->vfilter_idx >= nb_vfilters)
cur_stream->vfilter_idx = 0;
-toggle_audio_display(cur_stream);
-}
break;
case SDLK_PAGEUP:
if (cur_stream->ic->nb_chapters <= 1) {
--
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] avformat/mov: don't use cur_item_id as array index
On Mon, Mar 25, 2024 at 10:28:52PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > libavformat/mov.c | 16 ++-- > 1 file changed, 6 insertions(+), 10 deletions(-) havnt tested, but it improves the code, so definityl LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Some people wanted to paint the bikeshed green, some blue and some pink. People argued and fought, when they finally agreed, only rust was left. signature.asc Description: PGP signature ___ 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/mov: don't use cur_item_id as array index
On 3/25/2024 11:18 PM, Michael Niedermayer wrote: On Mon, Mar 25, 2024 at 10:28:52PM -0300, James Almer wrote: Signed-off-by: James Almer --- libavformat/mov.c | 16 ++-- 1 file changed, 6 insertions(+), 10 deletions(-) havnt tested, but it improves the code, so definityl LGTM thx Applied, thanks. ___ 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] tests: Remove fate-libx265-hdr10
Ping. Is it OK to apply the patch as it is? > On Mar 23, 2024, at 06:36, Jan Ekström wrote: > > On Fri, Mar 22, 2024 at 10:18 PM Anton Khirnov wrote: >> >> Quoting Zhao Zhili (2024-03-22 13:43:43) >>> From: Zhao Zhili >>> >>> The test depends on the compile option of x265. It failed when >>> HIGH_BIT_DEPTH isn't enabled. It also failed when asan is enabled >>> because of memory issue inside of x265, which I don't think can >>> be fixed within FFmpeg. >> >> I suggested some time ago we should mark x265 as experimental. It didn't >> receive much enthusiasm, and some probably considered it a joke, but I >> was mostly serious. It has major memory safety issues that have been >> ignored for years. >> > > Yea, I recall when I was testing my patch set with valgrind about half > a year ago, some of the memory issues showed up there as well. The > problem being that most users are happily oblivious to these issues as > long as the piece of software "seems to work". Which is a line that > x265 does cross. > > Thus at least on my side the reason for not much enthusiasm for > marking it experimental at this point came from it being on the output > side (and thus not handling random input/being a parser) as well as it > most likely receiving much less understanding from users than just > complaints about command lines which had worked for ages suddenly > breaking. > > Jan > ___ > 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".
[FFmpeg-devel] [PATCH 1/7] avcodec/hcadec: do not set hfr_group_count to invalid values
Fixes:
62285/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HCA_fuzzer-6247136417087488
Fixes: out of array write
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/hcadec.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hcadec.c b/libavcodec/hcadec.c
index 026b998341c..8c8c235f7b3 100644
--- a/libavcodec/hcadec.c
+++ b/libavcodec/hcadec.c
@@ -212,6 +212,7 @@ static int init_hca(AVCodecContext *avctx, const uint8_t
*extradata,
int8_t r[16] = { 0 };
unsigned b, chunk;
int version, ret;
+unsigned hfr_group_count;
init_flush(avctx);
@@ -336,11 +337,12 @@ static int init_hca(AVCodecContext *avctx, const uint8_t
*extradata,
if (c->total_band_count < c->base_band_count)
return AVERROR_INVALIDDATA;
-c->hfr_group_count = ceil2(c->total_band_count - (c->base_band_count +
c->stereo_band_count),
+hfr_group_count = ceil2(c->total_band_count - (c->base_band_count +
c->stereo_band_count),
c->bands_per_hfr_group);
-if (c->base_band_count + c->stereo_band_count + (unsigned
long)c->hfr_group_count > 128ULL)
+if (c->base_band_count + c->stereo_band_count + (uint64_t)hfr_group_count
> 128ULL)
return AVERROR_INVALIDDATA;
+c->hfr_group_count = hfr_group_count;
for (int i = 0; i < avctx->ch_layout.nb_channels; i++) {
c->ch[i].chan_type = r[i];
--
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] [PATCH 2/7] avcodec/hcadec: do not allow code to continue after failed init
Fixes:
62285/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HCA_fuzzer-6247136417087488
Fixes: out of array write
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/hcadec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hcadec.c b/libavcodec/hcadec.c
index 8c8c235f7b3..88146c7cdd3 100644
--- a/libavcodec/hcadec.c
+++ b/libavcodec/hcadec.c
@@ -538,8 +538,10 @@ static int decode_frame(AVCodecContext *avctx, AVFrame
*frame,
return AVERROR_INVALIDDATA;
} else if (AV_RB16(avpkt->data + 6) <= avpkt->size) {
ret = init_hca(avctx, avpkt->data, AV_RB16(avpkt->data + 6));
-if (ret < 0)
+if (ret < 0) {
+c->crc_table = NULL; // signal that init has not finished
return ret;
+}
offset = AV_RB16(avpkt->data + 6);
if (offset == avpkt->size)
return avpkt->size;
--
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] [PATCH 3/7] avcodec/qoadec: Fix undefined overflow in lms_predict
Fixes: signed integer overflow: -1575944192 + -602931200 cannot be represented
in type 'int'
Fixes:
62285/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QOA_fuzzer-6470469339185152
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/qoadec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/qoadec.c b/libavcodec/qoadec.c
index 75099d1199f..c5cf351f9c1 100644
--- a/libavcodec/qoadec.c
+++ b/libavcodec/qoadec.c
@@ -67,7 +67,7 @@ static int qoa_lms_predict(QOAChannel *lms)
{
int prediction = 0;
for (int i = 0; i < QOA_LMS_LEN; i++)
-prediction += lms->weights[i] * lms->history[i];
+prediction += (unsigned)lms->weights[i] * lms->history[i];
return prediction >> 13;
}
--
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] [PATCH 4/7] avcodec/rtv1: fix undefined FFALIGN
Fixes: signed integer overflow: 2147483647 + 4 cannot be represented in type 'int' Fixes: 62285/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RTV1_fuzzer-6324303861514240 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/rtv1.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/rtv1.c b/libavcodec/rtv1.c index 06afe9e873c..807c8a34666 100644 --- a/libavcodec/rtv1.c +++ b/libavcodec/rtv1.c @@ -113,6 +113,8 @@ static int decode_frame(AVCodecContext *avctx, AVFrame *p, width = bytestream2_get_le32(&gb); height = bytestream2_get_le32(&gb); +if (width > INT_MAX-4U || height > INT_MAX-4U) +return AVERROR_INVALIDDATA; ret = ff_set_dimensions(avctx, FFALIGN(width, 4), FFALIGN(height, 4)); if (ret < 0) return ret; -- 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] [PATCH 5/7] avcodec/truemotion1: Height not being a multiple of 4 is unsupported
mb_change_bits is given space based on height >> 2, while more data is read
Fixes: out of array access
Fixes:
62285/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION1_fuzzer-5201925062590464.fuzz
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/truemotion1.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/truemotion1.c b/libavcodec/truemotion1.c
index 6b0ee225691..784576d01b3 100644
--- a/libavcodec/truemotion1.c
+++ b/libavcodec/truemotion1.c
@@ -408,6 +408,11 @@ static int truemotion1_decode_header(TrueMotion1Context *s)
return AVERROR_PATCHWELCOME;
}
+if (s->h & 3) {
+avpriv_request_sample(s->avctx, "Frame with height not being a
multiple of 4");
+return AVERROR_PATCHWELCOME;
+}
+
if (s->w != s->avctx->width || s->h != s->avctx->height ||
new_pix_fmt != s->avctx->pix_fmt) {
av_frame_unref(s->frame);
--
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] [PATCH 6/7] avcodec/wavarc: Avoid signed integer overflow in sample
Fixes: signed integer overflow: -2147483648 + -25122315 cannot be represented in type 'int' Fixes: 62285/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVARC_fuzzer-6199806972198912 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/wavarc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/wavarc.c b/libavcodec/wavarc.c index 09ed4d473a2..99cbaf01091 100644 --- a/libavcodec/wavarc.c +++ b/libavcodec/wavarc.c @@ -374,7 +374,7 @@ static int decode_2slp(AVCodecContext *avctx, for (int o = 0; o < order; o++) sum += s->filter[ch][o] * (unsigned)samples[n + 70 - o - 1]; -samples[n + 70] = get_srice(gb, k) + (sum >> 4); +samples[n + 70] = get_srice(gb, k) + (unsigned)(sum >> 4); } finished = 1; break; -- 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] [PATCH 7/7] avcodec/wavarc: avoid signed integer overflow in AC code
Fixes:
62285/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVARC_fuzzer-659847401740697
Fixes: signed integer overflow: 65312 * 34078 cannot be represented in type
'int'
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/wavarc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/wavarc.c b/libavcodec/wavarc.c
index 99cbaf01091..aa1af6330bb 100644
--- a/libavcodec/wavarc.c
+++ b/libavcodec/wavarc.c
@@ -414,7 +414,7 @@ static int ac_init(AVCodecContext *avctx,
static uint16_t ac_get_prob(WavArcContext *s)
{
-return ((s->freq_range - 1) + (s->ac_value - s->ac_low) * s->freq_range) /
+return ((s->freq_range - 1) + (s->ac_value - s->ac_low) *
(unsigned)s->freq_range) /
((s->ac_high - s->ac_low) + 1U);
}
@@ -439,8 +439,8 @@ static int ac_normalize(AVCodecContext *avctx,
WavArcContext *s, GetBitContext *
goto fail;
range = (s->ac_high - s->ac_low) + 1;
-s->ac_high = (range * s->range_high) / s->freq_range + s->ac_low - 1;
-s->ac_low += (range * s->range_low) / s->freq_range;
+s->ac_high = (range * (unsigned)s->range_high) / s->freq_range + s->ac_low
- 1;
+s->ac_low += (range * (unsigned)s->range_low) / s->freq_range;
if (s->ac_high < s->ac_low)
goto fail;
--
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".
Re: [FFmpeg-devel] [PATCH 4/7] avcodec/rtv1: fix undefined FFALIGN
On 3/25/2024 11:30 PM, Michael Niedermayer wrote: Fixes: signed integer overflow: 2147483647 + 4 cannot be represented in type 'int' Fixes: 62285/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RTV1_fuzzer-6324303861514240 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/rtv1.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/rtv1.c b/libavcodec/rtv1.c index 06afe9e873c..807c8a34666 100644 --- a/libavcodec/rtv1.c +++ b/libavcodec/rtv1.c @@ -113,6 +113,8 @@ static int decode_frame(AVCodecContext *avctx, AVFrame *p, width = bytestream2_get_le32(&gb); height = bytestream2_get_le32(&gb); +if (width > INT_MAX-4U || height > INT_MAX-4U) Does this promote width and height to unsigned? If not, you may want to cast them to unsigned (or check for < 0) and remove the then unnecessary U to the 4. +return AVERROR_INVALIDDATA; ret = ff_set_dimensions(avctx, FFALIGN(width, 4), FFALIGN(height, 4)); if (ret < 0) return ret; ___ 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/7] avcodec/rtv1: fix undefined FFALIGN
James Almer: > On 3/25/2024 11:30 PM, Michael Niedermayer wrote: >> Fixes: signed integer overflow: 2147483647 + 4 cannot be represented >> in type 'int' >> Fixes: >> 62285/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RTV1_fuzzer-6324303861514240 >> >> Found-by: continuous fuzzing process >> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> Signed-off-by: Michael Niedermayer >> --- >> libavcodec/rtv1.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/libavcodec/rtv1.c b/libavcodec/rtv1.c >> index 06afe9e873c..807c8a34666 100644 >> --- a/libavcodec/rtv1.c >> +++ b/libavcodec/rtv1.c >> @@ -113,6 +113,8 @@ static int decode_frame(AVCodecContext *avctx, >> AVFrame *p, >> width = bytestream2_get_le32(&gb); >> height = bytestream2_get_le32(&gb); >> + if (width > INT_MAX-4U || height > INT_MAX-4U) > > Does this promote width and height to unsigned? If not, you may want to > cast them to unsigned (or check for < 0) and remove the then unnecessary > U to the 4. The right hand side of the comparisons is an unsigned; if width and height are ints (as i presume based upon the commit message), they get promoted to unsigned. > >> + return AVERROR_INVALIDDATA; >> ret = ff_set_dimensions(avctx, FFALIGN(width, 4), >> FFALIGN(height, 4)); >> if (ret < 0) >> return ret; > ___ > 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] [FFmpeg-cvslog] avcodec: remove deprecated FF_CODEC_CRYSTAL_HD
On Thu, Mar 07, 2024 at 02:41:51PM +, James Almer wrote: > ffmpeg | branch: master | James Almer | Sat Jan 20 > 10:35:23 2024 -0300| [5b23b18d40ead8606c92d967279b3f43c94d8a60] | committer: > James Almer > > avcodec: remove deprecated FF_CODEC_CRYSTAL_HD > > Signed-off-by: James Almer > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=5b23b18d40ead8606c92d967279b3f43c94d8a60 > --- > > configure | 13 - > libavcodec/Makefile| 1 - > libavcodec/allcodecs.c | 6 - > libavcodec/crystalhd.c | 825 > - > libavcodec/version_major.h | 3 - > 5 files changed, 848 deletions(-) this broke googles ossfuzz https://oss-fuzz-build-logs.storage.googleapis.com/log-18bed149-95b6-4741-843f-64431f9ec142.txt https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=67316&q=ffmpeg blindly written fix submited here: https://github.com/google/oss-fuzz/pull/11734 (if it fails build dont hesitate to fix it before i wake up and have time later tomorrow) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: PGP signature ___ 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/h264_parse: Fix error code in decode_extradata
From: Zhao Zhili
---
libavcodec/h264_parse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
index 3378650fd5..09d3b9dc05 100644
--- a/libavcodec/h264_parse.c
+++ b/libavcodec/h264_parse.c
@@ -468,7 +468,7 @@ int ff_h264_decode_extradata(const uint8_t *data, int size,
H264ParamSets *ps,
int ret;
if (!data || size <= 0)
-return -1;
+return AVERROR(EINVAL);
if (data[0] == 1) {
int i, cnt, nalsize;
--
2.25.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] Add optimization in swscale for LA.
> 2024年3月16日 11:03，Shiyou Yin 写道： > > [PATCH 1/3] swscale: [LA] Optimize range convert for yuvj420p. > [PATCH 2/3] swscale: [LA] Optimize yuv2plane1_8_c. > [PATCH 3/3] swscale: [LA] Optimize swscale funcs in input.c > > ___ > 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”. Hi, Michale Could you please help to review this patch set, thanks. ___ 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/3] avcodec/Makefile: Remove redundant dependencies on hevc_data.o
hevc_data.c only provides ff_hevc_diag_scan tables and neither the QSV HEVC encoder nor the HEVC parser use these directly and the indirect dependency is already accounted for in the dependencies of the hevcparse subsystem since b0c61209cd30f9ddf3356d5ded6df488f25d1bd5, so remove these spurious dependencies. Signed-off-by: Andreas Rheinhardt --- libavcodec/Makefile | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 9ce6d445c1..6eefeeae6e 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -440,8 +440,7 @@ OBJS-$(CONFIG_HEVC_MEDIACODEC_ENCODER) += mediacodecenc.o OBJS-$(CONFIG_HEVC_MF_ENCODER) += mfenc.o mf_utils.o OBJS-$(CONFIG_HEVC_NVENC_ENCODER) += nvenc_hevc.o nvenc.o OBJS-$(CONFIG_HEVC_QSV_DECODER)+= qsvdec.o -OBJS-$(CONFIG_HEVC_QSV_ENCODER)+= qsvenc_hevc.o hevc_ps_enc.o \ - hevc_data.o +OBJS-$(CONFIG_HEVC_QSV_ENCODER)+= qsvenc_hevc.o hevc_ps_enc.o OBJS-$(CONFIG_HEVC_RKMPP_DECODER) += rkmppdec.o OBJS-$(CONFIG_HEVC_VAAPI_ENCODER) += vaapi_encode_h265.o h265_profile_level.o \ h2645data.o @@ -1196,7 +1195,7 @@ OBJS-$(CONFIG_GSM_PARSER) += gsm_parser.o OBJS-$(CONFIG_H261_PARSER) += h261_parser.o OBJS-$(CONFIG_H263_PARSER) += h263_parser.o OBJS-$(CONFIG_H264_PARSER) += h264_parser.o h264data.o -OBJS-$(CONFIG_HEVC_PARSER) += hevc_parser.o hevc_data.o +OBJS-$(CONFIG_HEVC_PARSER) += hevc_parser.o OBJS-$(CONFIG_HDR_PARSER) += hdr_parser.o OBJS-$(CONFIG_IPU_PARSER) += ipu_parser.o OBJS-$(CONFIG_JPEG2000_PARSER) += jpeg2000_parser.o -- 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] [PATCH 2/3] avcodec/qsvenc_hevc: Switch to cbs_h265 to create missing VPS
Old MXF runtime versions did not support writing VPS
and therefore one derived from the SPS has been generated
via ad-hoc code in lavc/hevc_ps_enc.c that is only used
for this purpose. Yet this duplicates the functionality
from cbs_h265, so replace it with the latter.
This patch has been tested by generating VPS from the
SPS and PPS from hevc-conformance files from the
FATE-suite. There were some minor differences, mostly
due to hevc_ps_enc.c not handling the profile constraint
flags like general_max_12bit_constraint_flag.
Signed-off-by: Andreas Rheinhardt
---
Would be nice if someone could actually check this with a QSV version
that needs this hack.
(Do people really need this any more?)
configure| 2 +-
libavcodec/Makefile | 2 +-
libavcodec/hevc_ps_enc.c | 121
libavcodec/qsvenc_hevc.c | 168 +--
4 files changed, 77 insertions(+), 216 deletions(-)
delete mode 100644 libavcodec/hevc_ps_enc.c
diff --git a/configure b/configure
index 9fa639fca6..6c181197b4 100755
--- a/configure
+++ b/configure
@@ -3341,7 +3341,7 @@ hevc_mf_encoder_deps="mediafoundation"
hevc_nvenc_encoder_deps="nvenc"
hevc_nvenc_encoder_select="atsc_a53"
hevc_qsv_decoder_select="hevc_mp4toannexb_bsf qsvdec"
-hevc_qsv_encoder_select="hevcparse qsvenc"
+hevc_qsv_encoder_select="cbs_h265 qsvenc"
hevc_rkmpp_decoder_deps="rkmpp"
hevc_rkmpp_decoder_select="hevc_mp4toannexb_bsf"
hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 6eefeeae6e..d06b837c60 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -440,7 +440,7 @@ OBJS-$(CONFIG_HEVC_MEDIACODEC_ENCODER) += mediacodecenc.o
OBJS-$(CONFIG_HEVC_MF_ENCODER) += mfenc.o mf_utils.o
OBJS-$(CONFIG_HEVC_NVENC_ENCODER) += nvenc_hevc.o nvenc.o
OBJS-$(CONFIG_HEVC_QSV_DECODER)+= qsvdec.o
-OBJS-$(CONFIG_HEVC_QSV_ENCODER)+= qsvenc_hevc.o hevc_ps_enc.o
+OBJS-$(CONFIG_HEVC_QSV_ENCODER)+= qsvenc_hevc.o
OBJS-$(CONFIG_HEVC_RKMPP_DECODER) += rkmppdec.o
OBJS-$(CONFIG_HEVC_VAAPI_ENCODER) += vaapi_encode_h265.o
h265_profile_level.o \
h2645data.o
diff --git a/libavcodec/hevc_ps_enc.c b/libavcodec/hevc_ps_enc.c
deleted file mode 100644
index 72641b2ffb..00
--- a/libavcodec/hevc_ps_enc.c
+++ /dev/null
@@ -1,121 +0,0 @@
-/*
- * HEVC Parameter Set encoding
- *
- * 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 "put_golomb.h"
-#include "hevc_ps.h"
-#include "put_bits.h"
-
-static void write_ptl_layer(PutBitContext *pb, PTLCommon *ptl)
-{
-int i;
-
-put_bits(pb, 2, ptl->profile_space);
-put_bits(pb, 1, ptl->tier_flag);
-put_bits(pb, 5, ptl->profile_idc);
-for (i = 0; i < 32; i++)
-put_bits(pb, 1, ptl->profile_compatibility_flag[i]);
-put_bits(pb, 1, ptl->progressive_source_flag);
-put_bits(pb, 1, ptl->interlaced_source_flag);
-put_bits(pb, 1, ptl->non_packed_constraint_flag);
-put_bits(pb, 1, ptl->frame_only_constraint_flag);
-put_bits32(pb, 0); // reserved
-put_bits(pb, 12, 0); // reserved
-}
-
-static void write_ptl(PutBitContext *pb, PTL *ptl, int max_num_sub_layers)
-{
-int i;
-
-write_ptl_layer(pb, &ptl->general_ptl);
-put_bits(pb, 8, ptl->general_ptl.level_idc);
-
-for (i = 0; i < max_num_sub_layers - 1; i++) {
-put_bits(pb, 1, ptl->sub_layer_profile_present_flag[i]);
-put_bits(pb, 1, ptl->sub_layer_level_present_flag[i]);
-}
-
-if (max_num_sub_layers > 1)
-for (i = max_num_sub_layers - 1; i < 8; i++)
-put_bits(pb, 2, 0); // reserved
-
-for (i = 0; i < max_num_sub_layers - 1; i++) {
-if (ptl->sub_layer_profile_present_flag[i])
-write_ptl_layer(pb, &ptl->sub_layer_ptl[i]);
-if (ptl->sub_layer_level_present_flag[i])
-put_bits(pb, 8, ptl->sub_layer_ptl[i].level_idc);
-}
-}
-
-int ff_hevc_encode_nal_vps(HEVCVPS *vps, unsigned int id,
- uint8_t *buf, int buf_size)
-{
-PutBitContext pb;
-int i, data_size;
-
-init_put_bits(&pb, buf, buf_size);
-put_bits(&pb, 4, id);
-put_bits(&pb, 2, 3);
[FFmpeg-devel] [PATCH 3/3] avcodec/hevc_ps: Make ff_hevc_parse_ps static
It is only used here since its other caller (qsvenc_hevc.c)
has been switched to cbs_h265.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/hevc_ps.c | 14 +++---
libavcodec/hevc_ps.h | 13 -
2 files changed, 7 insertions(+), 20 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index cbef3ef4cd..4e2c36b448 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -866,9 +866,9 @@ static int map_pixel_format(AVCodecContext *avctx, HEVCSPS
*sps)
return 0;
}
-int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb, unsigned int *sps_id,
- int apply_defdispwin, const HEVCVPS * const *vps_list,
- AVCodecContext *avctx)
+static int hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb, unsigned int
*sps_id,
+ int apply_defdispwin, const HEVCVPS * const
*vps_list,
+ AVCodecContext *avctx)
{
HEVCWindow *ow;
int ret = 0;
@@ -879,7 +879,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
sps->vps_id = get_bits(gb, 4);
-if (vps_list && !vps_list[sps->vps_id]) {
+if (!vps_list[sps->vps_id]) {
av_log(avctx, AV_LOG_ERROR, "VPS %d does not exist\n",
sps->vps_id);
return AVERROR_INVALIDDATA;
@@ -1307,9 +1307,9 @@ int ff_hevc_decode_nal_sps(GetBitContext *gb,
AVCodecContext *avctx,
}
memcpy(sps->data, gb->buffer, sps->data_size);
-ret = ff_hevc_parse_sps(sps, gb, &sps_id,
-apply_defdispwin,
-ps->vps_list, avctx);
+ret = hevc_parse_sps(sps, gb, &sps_id,
+ apply_defdispwin,
+ ps->vps_list, avctx);
if (ret < 0) {
ff_refstruct_unref(&sps);
return ret;
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index cc75aeb8d3..82fa5bf820 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -447,19 +447,6 @@ typedef struct HEVCParamSets {
const HEVCPPS *pps;
} HEVCParamSets;
-/**
- * Parse the SPS from the bitstream into the provided HEVCSPS struct.
- *
- * @param sps_id the SPS id will be written here
- * @param apply_defdispwin if set 1, the default display window from the VUI
- * will be applied to the video dimensions
- * @param vps_list if non-NULL, this function will validate that the SPS refers
- * to an existing VPS
- */
-int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb, unsigned int *sps_id,
- int apply_defdispwin, const HEVCVPS * const *vps_list,
- AVCodecContext *avctx);
-
int ff_hevc_decode_nal_vps(GetBitContext *gb, AVCodecContext *avctx,
HEVCParamSets *ps);
int ff_hevc_decode_nal_sps(GetBitContext *gb, AVCodecContext *avctx,
--
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] [PATCH] avformat/httpauth: add SHA-256 Digest Authorization
- add SHA-256 Digest Authorization for RFC7616 using avutil/hash.h
Signed-off-by: Eugene-bitsensing
---
libavformat/httpauth.c | 116 -
libavformat/httpauth.h | 8 +++
2 files changed, 123 insertions(+), 1 deletion(-)
diff --git a/libavformat/httpauth.c b/libavformat/httpauth.c
index 9780928357..8391b6f32f 100644
--- a/libavformat/httpauth.c
+++ b/libavformat/httpauth.c
@@ -25,6 +25,7 @@
#include "internal.h"
#include "libavutil/random_seed.h"
#include "libavutil/md5.h"
+#include "libavutil/hash.h"
#include "urldecode.h"
static void handle_basic_params(HTTPAuthState *state, const char *key,
@@ -236,6 +237,114 @@ static char *make_digest_auth(HTTPAuthState *state, const
char *username,
return authstr;
}
+/**
+ * Generate a digest reply SHA-256, according to RFC 7616.
+ * TODO : support other RFIC 7616 Algorithm
+ */
+static char *make_digest_auth_sha(HTTPAuthState *state, const char *username,
+ const char *password, const char *uri,
+ const char *method, const char *algorithm)
+{
+DigestParams *digest = &state->digest_params;
+int len;
+uint32_t cnonce_buf[2];
+char cnonce[17];
+char nc[9];
+int i;
+char A1hash[65], A2hash[65], response[65];
+struct AVHashContext *hashctx;
+uint8_t hash[64];
+char *authstr;
+
+digest->nc++;
+snprintf(nc, sizeof(nc), "%08x", digest->nc);
+
+/* Generate a client nonce. */
+for (i = 0; i < 2; i++)
+cnonce_buf[i] = av_get_random_seed();
+ff_data_to_hex(cnonce, (const uint8_t*) cnonce_buf, sizeof(cnonce_buf), 1);
+
+/* Allocate a hash context based on the provided algorithm */
+int ret = av_hash_alloc(&hashctx, algorithm);
+if (ret < 0) {
+return NULL;
+}
+
+/* Initialize the hash context */
+av_hash_init(hashctx);
+
+/* Update the hash context with A1 data */
+av_hash_update(hashctx, (const uint8_t *)username, strlen(username));
+av_hash_update(hashctx, (const uint8_t *)":", 1);
+av_hash_update(hashctx, (const uint8_t *)state->realm,
strlen(state->realm));
+av_hash_update(hashctx, (const uint8_t *)":", 1);
+av_hash_update(hashctx, (const uint8_t *)password, strlen(password));
+av_hash_final(hashctx, hash);
+ff_data_to_hex(A1hash, hash, av_hash_get_size(hashctx), 1);
+
+/* Initialize the hash context for A2 */
+av_hash_init(hashctx);
+av_hash_update(hashctx, (const uint8_t *)method, strlen(method));
+av_hash_update(hashctx, (const uint8_t *)":", 1);
+av_hash_update(hashctx, (const uint8_t *)uri, strlen(uri));
+av_hash_final(hashctx, hash);
+ff_data_to_hex(A2hash, hash, av_hash_get_size(hashctx), 1);
+
+/* Initialize the hash context for response */
+av_hash_init(hashctx);
+av_hash_update(hashctx, (const uint8_t *)A1hash, strlen(A1hash));
+av_hash_update(hashctx, (const uint8_t *)":", 1);
+av_hash_update(hashctx, (const uint8_t *)digest->nonce,
strlen(digest->nonce));
+av_hash_update(hashctx, (const uint8_t *)":", 1);
+av_hash_update(hashctx, (const uint8_t *)nc, strlen(nc));
+av_hash_update(hashctx, (const uint8_t *)":", 1);
+av_hash_update(hashctx, (const uint8_t *)cnonce, strlen(cnonce));
+av_hash_update(hashctx, (const uint8_t *)":", 1);
+av_hash_update(hashctx, (const uint8_t *)digest->qop, strlen(digest->qop));
+av_hash_update(hashctx, (const uint8_t *)":", 1);
+av_hash_update(hashctx, (const uint8_t *)A2hash, strlen(A2hash));
+av_hash_final(hashctx, hash);
+ff_data_to_hex(response, hash, av_hash_get_size(hashctx), 1);
+
+/* Free the hash context */
+av_hash_freep(&hashctx);
+
+len = strlen(username) + strlen(state->realm) + strlen(digest->nonce) +
+ strlen(uri) + strlen(response) + strlen(digest->algorithm) +
+ strlen(digest->opaque) + strlen(digest->qop) + strlen(cnonce) +
+ strlen(nc) + 150;
+
+authstr = av_malloc(len);
+if (!authstr) {
+return NULL;
+}
+
+/* Generate Header same way as *make_digest_auth */
+snprintf(authstr, len, "Authorization: Digest ");
+
+av_strlcatf(authstr, len, "username=\"%s\"", username);
+av_strlcatf(authstr, len, ", realm=\"%s\"", state->realm);
+av_strlcatf(authstr, len, ", nonce=\"%s\"", digest->nonce);
+av_strlcatf(authstr, len, ", uri=\"%s\"", uri);
+av_strlcatf(authstr, len, ", response=\"%s\"", response);
+
+if (digest->algorithm[0])
+av_strlcatf(authstr, len, ", algorithm=\"%s\"", digest->algorithm);
+
+if (digest->opaque[0])
+av_strlcatf(authstr, len, ", opaque=\"%s\"", digest->opaque);
+if (digest->qop[0]) {
+av_strlcatf(authstr, len, ", qop=\"%s\"",digest->qop);
+av_strlcatf(authstr, len, ", cnonce=\"%s\"", cnonce);
+av_strlcatf(authstr, len, ", nc=%s", nc);
+}
+
+av_strlcatf(authstr, len, "\r\n");
+
+
Re: [FFmpeg-devel] [PATCH 00/21] aarch64: hevc: Add missing hevc_pel NEON functions
On Mon, 25 Mar 2024, at 22:56, J. Dekker wrote: >> On Mon, 25 Mar 2024, Martin Storsjö wrote: >> >>> Since some time, we have pretty complete AArch64 NEON coverage >>> for the hevc decoder. >>> >>> However, some of these functions require the I8MM instruction set >>> extension, and many of them (but not all) lack a plain NEON >>> version. >>> >>> This patchset fills in a regular NEON version of all functions >>> where we have an I8MM function. >>> >>> For context; the I8MM instruction set extension is a mandatory >>> part of armv8.6-a. E.g. Apple M2, AWS Graviton 3 have it, >>> but Apple M1 and Ampere Altra don't. >>> >>> This patchset takes decoding of a 1080p HEVC clip from 402 >>> fps to 649 fps on an Apple M1. >>> >>> Patch #2 also fixes a subtle bug in the existing implementation; >>> two functions relied on the contents on the stack, below the >>> stack pointer, being untouched within a function. If a signal >>> gets delivered, those parts of the stack could be clobbered. >> >> I know this is a bit short notice for a patchset of this size - but, would >> people be OK with merging this patchset before the impending 7.0 branch >> (which is made within the next 24h)? >> >> The patches pass all my tricky build configurations, they give a very >> non-negligible speedup on many common CPUs, and patch #2 fixes a real bug in >> the existing impleemntations. (A bug fix patch can of course be backported >> after the branch too, but performance optimizations aren't generally >> relevant for backporting.) >> >> // Martin > > Yes, please. I will tomorrow morning if you didn’t already push. +1 -- Jean-Baptiste Kempf - President +33 672 704 734 https://jbkempf.com/ ___ 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] avutil/hwcontext_qsv: Fix mixed declaration and code
On So, 2024-03-24 at 21:30 +0100, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavutil/hwcontext_qsv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index e5e043d2d1..c7c7878644 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -1121,7 +1121,8 @@ fail:
> static int qsv_init_internal_session(AVHWFramesContext *ctx,
> mfxSession *session, int upload)
> {
> - AVQSVFramesContext *frames_hwctx = ctx->hwctx;
> + QSVFramesContext *s = ctx->hwctx;
> + AVQSVFramesContext *frames_hwctx = &s->p;
> QSVDeviceContext *device_priv = ctx->device_ctx->hwctx;
> AVQSVDeviceContext *hwctx = &device_priv->p;
> int opaque = 0;
> @@ -1153,7 +1154,6 @@ static int qsv_init_internal_session(AVHWFramesContext
> *ctx,
> }
>
> #if QSV_HAVE_OPAQUE
> - QSVFramesContext *s = ctx->hwctx;
> opaque = !!(frames_hwctx->frame_type & MFX_MEMTYPE_OPAQUE_FRAME);
> #endif
>
LGTM,
- Haihao
___
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 2/2] lavc/get_buffer: Add a warning on failed allocation from a fixed pool
On Di, 2024-03-19 at 22:52 +, Mark Thompson wrote: > On 19/03/2024 04:16, Xiang, Haihao wrote: > > On Ma, 2024-03-18 at 21:33 +, Mark Thompson wrote: > > > On 18/03/2024 05:53, Xiang, Haihao wrote: > > > > On So, 2024-03-17 at 20:51 +, Mark Thompson wrote: > > > > > For hardware cases where we are forced to have a fixed pool of frames > > > > > allocated up-front (such as array textures on decoder output), suggest > > > > > a possible workaround to the user if an allocation fails because the > > > > > pool is exhausted. > > > > > --- > > > > > Perhaps helpful; any thoughts? > > > > > > > > > > The warning comes out before any errors, looking like: > > > > > > > > > > [mpeg2video @ 0x560ff51b4600] Failed to allocate a vaapi/nv12 frame > > > > > from a > > > > > fixed pool of hardware frames. > > > > > [mpeg2video @ 0x560ff51b4600] Consider setting extra_hw_frames to a > > > > > larger > > > > > value (currently set to 8, giving a pool size of 14). > > > > > [mpeg2video @ 0x560ff51b4600] get_buffer() failed > > > > > [vist#0:0/mpeg2video @ 0x560ff5199840] [dec:mpeg2video @ > > > > > 0x560ff51b3b40] > > > > > Error > > > > > submitting packet to decoder: Operation not permitted > > > > > > > > I'm OK to print such warning so user may know how to work around it. But > > > > now > > > > many cases are impacted by this error > > > > (e.g. https://trac.ffmpeg.org/ticket/10856 > > > > ), I think it is a regression to user. I still prefer to use a dynamic > > > > buffer > > > > pool instead fixed frame pool to avoid such error when the dynamic > > > > buffer > > > > pool > > > > can work. > > > > > > How would we implement this on D3D11 or D3D12? > > > > I understand not all can support dynamic frame pool, your patch is useful > > for > > decoders using fixed pool. But for driver which doesn't require array > > textures, > > I think we'd be better to use dynamic frame pool instead so user needn't > > worry > > about frame allocation. For example, we may use dynamic frame pool for vaapi > > with iHD driver, what do you think about adding a quirk to enable dynamic > > frame > > pool for special drivers ? > > I think we should come to a conclusion on what the generic code for this case > should be and then consider whether any special cases are needed. > > When compared to the state right now, I agree with you that just switching > VAAPI to always be dynamic would probably be better just to avoid the nasty > failures, but given that we need to improve the situation for cases (like > D3D11) where we don't have an ad-hoc workaround we should be comparing to > whatever that concludes rather than the broken state right now. Hi Mark, I agree with you. Will you push this patch ? We may switch to dynamic frame pool for vaapi cases later after pushing your patch. Thanks Haihao ___ 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".
