[FFmpeg-devel] [PATCH 1/7] proresdec2: port and fix for cached reader
Summary of changes
- move back to regular, non-macro, get_bits API
- reduce the lookup to switch the coding method
- shorter reads wherever possible, in particular for the end of bitstream
(16 bits instead of 32, as per the above)
There are cases that really need longer lengths (larger EG codes) of up
to 27 bits.
Win64: 6.10 -> 4.87 (~20% speedup)
Reference for an hypothetical 32bits version of the cached reader:
Win32: 11.4 -> 9.8 (14%, because iDCT is not SIMDed)
---
libavcodec/proresdec2.c | 53 ++---
1 file changed, 23 insertions(+), 30 deletions(-)
diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index 9297860946..6e243cfc17 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -24,9 +24,7 @@
* Known FOURCCs: 'apch' (HQ), 'apcn' (SD), 'apcs' (LT), 'apco' (Proxy),
'ap4h' (), 'ap4x' ( XQ)
*/
-//#define DEBUG
-
-#define LONG_BITSTREAM_READER
+#define CACHED_BITSTREAM_READER 1
#include "config_components.h"
@@ -422,35 +420,37 @@ static int decode_picture_header(AVCodecContext *avctx,
const uint8_t *buf, cons
return pic_data_size;
}
-#define DECODE_CODEWORD(val, codebook, SKIP)\
+/* bitstream_read may fail on 32bits ARCHS for >24 bits, so use long version
there */
+#if 0 //BITSTREAM_BITS == 32
+# define READ_BITS get_bits_long
+#else
+# define READ_BITS get_bits
+#endif
+
+#define DECODE_CODEWORD(val, codebook) \
do {\
unsigned int rice_order, exp_order, switch_bits;\
unsigned int q, buf, bits; \
\
-UPDATE_CACHE(re, gb); \
-buf = GET_CACHE(re, gb);\
+buf = show_bits(gb, 14);\
\
/* number of bits to switch between rice and exp golomb */ \
switch_bits = codebook & 3;\
rice_order = codebook >> 5; \
exp_order = (codebook >> 2) & 7; \
\
-q = 31 - av_log2(buf); \
+q = 13 - av_log2(buf); \
\
if (q > switch_bits) { /* exp golomb */ \
bits = exp_order - switch_bits + (q<<1);\
-if (bits > FFMIN(MIN_CACHE_BITS, 31)) \
-return AVERROR_INVALIDDATA; \
-val = SHOW_UBITS(re, gb, bits) - (1 << exp_order) + \
+val = READ_BITS(gb, bits) - (1 << exp_order) + \
((switch_bits + 1) << rice_order); \
-SKIP(re, gb, bits); \
} else if (rice_order) {\
-SKIP_BITS(re, gb, q+1); \
-val = (q << rice_order) + SHOW_UBITS(re, gb, rice_order); \
-SKIP(re, gb, rice_order); \
+skip_remaining(gb, q+1);\
+val = (q << rice_order) + get_bits(gb, rice_order); \
} else {\
val = q;\
-SKIP(re, gb, q+1); \
+skip_remaining(gb, q+1);\
} \
} while (0)
@@ -466,9 +466,7 @@ static av_always_inline int decode_dc_coeffs(GetBitContext
*gb, int16_t *out,
int16_t prev_dc;
int code, i, sign;
-OPEN_READER(re, gb);
-
-DECODE_CODEWORD(code, FIRST_DC_CB, LAST_SKIP_BITS);
+DECODE_CODEWORD(code, FIRST_DC_CB);
prev_dc = TOSIGNED(code);
out[0] = prev_dc;
@@ -477,13 +475,12 @@ static av_always_inline int
decode_dc_coeffs(GetBitContext *gb, int16_t *out,
code = 5;
sign = 0;
for (i = 1; i < blocks_per_slice; i++, out += 64) {
-DECODE_CODEWORD(code, dc_codebook[FFMIN(code, 6U)], LAST_SKIP_BITS);
+DECODE_CODEWORD(code, dc_codebook[FFMIN(code, 6U)]);
if(code) sign ^= -(code & 1);
else sign = 0;
prev_dc += (((code + 1) >> 1) ^ sign) - sign;
out[0] = prev_dc;
}
-CLOSE_READER(re, gb);
return 0;
[FFmpeg-devel] [PATCH 2/7] proresdec2: store precomputed EC parameters
Having the various orders and offsets stored in a codebook is compact
but causes additional computations. Using instead a table for the
precomputed results achieve some speedups at the cost of ~132 bytes.
Around 5% speedup.
---
libavcodec/proresdec2.c | 54 +++--
1 file changed, 47 insertions(+), 7 deletions(-)
diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index 6e243cfc17..65e8b01755 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -427,6 +427,7 @@ static int decode_picture_header(AVCodecContext *avctx,
const uint8_t *buf, cons
# define READ_BITS get_bits
#endif
+/* Kept for reference and because clearer for first DC */
#define DECODE_CODEWORD(val, codebook) \
do {\
unsigned int rice_order, exp_order, switch_bits;\
@@ -454,18 +455,41 @@ static int decode_picture_header(AVCodecContext *avctx,
const uint8_t *buf, cons
} \
} while (0)
+/* number of bits to switch between rice and exp golomb */
+#define DECODE_CODEWORD2(val, switch_bits, rice_order, diff, offset)\
+do {\
+unsigned int q, buf, bits; \
+\
+buf = show_bits(gb, 14);\
+q = 13 - av_log2(buf); \
+\
+if (q > switch_bits) { /* exp golomb */ \
+bits = (q<<1) + (int)diff; \
+val = READ_BITS(gb, bits) + (int)offset;\
+} else if (rice_order) {\
+skip_remaining(gb, q+1);\
+val = (q << rice_order) + get_bits(gb, rice_order); \
+} else {\
+val = q;\
+skip_remaining(gb, q+1);\
+} \
+} while (0)
+
+
#define TOSIGNED(x) (((x) >> 1) ^ (-((x) & 1)))
#define FIRST_DC_CB 0xB8
-static const uint8_t dc_codebook[7] = { 0x04, 0x28, 0x28, 0x4D, 0x4D, 0x70,
0x70};
+static const char dc_codebook[7][4] = {
+{ 0, 0, 1, -1 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 },
+{ 1, 2, 2, 0 }, { 1, 2, 2, 0 }, { 0, 3, 4, -8 }, { 0, 3, 4, -8 }
+};
static av_always_inline int decode_dc_coeffs(GetBitContext *gb, int16_t *out,
int blocks_per_slice)
{
int16_t prev_dc;
int code, i, sign;
-
DECODE_CODEWORD(code, FIRST_DC_CB);
prev_dc = TOSIGNED(code);
out[0] = prev_dc;
@@ -475,7 +499,9 @@ static av_always_inline int decode_dc_coeffs(GetBitContext
*gb, int16_t *out,
code = 5;
sign = 0;
for (i = 1; i < blocks_per_slice; i++, out += 64) {
-DECODE_CODEWORD(code, dc_codebook[FFMIN(code, 6U)]);
+unsigned int dccb = FFMIN(code, 6U);
+DECODE_CODEWORD2(code, dc_codebook[dccb][0], dc_codebook[dccb][1],
+ dc_codebook[dccb][2], dc_codebook[dccb][3]);
if(code) sign ^= -(code & 1);
else sign = 0;
prev_dc += (((code + 1) >> 1) ^ sign) - sign;
@@ -485,8 +511,18 @@ static av_always_inline int decode_dc_coeffs(GetBitContext
*gb, int16_t *out,
}
// adaptive codebook switching lut according to previous run/level values
-static const uint8_t run_to_cb[16] = { 0x06, 0x06, 0x05, 0x05, 0x04, 0x29,
0x29, 0x29, 0x29, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x4C };
-static const uint8_t lev_to_cb[10] = { 0x04, 0x0A, 0x05, 0x06, 0x04, 0x28,
0x28, 0x28, 0x28, 0x4C };
+static const char run_to_cb[16][4] = {
+{ 2, 0, -1, 1 }, { 2, 0, -1, 1 }, { 1, 0, 0, 0 }, { 1, 0, 0, 0 }, {
0, 0, 1, -1 },
+{ 1, 1, 1, 0 }, { 1, 1, 1, 0 }, { 1, 1, 1, 0 }, { 1, 1, 1, 0 },
+{ 0, 1, 2, -2 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 }, {
0, 1, 2, -2 }, { 0, 1, 2, -2 },
+{ 0, 2, 3, -4 }
+};
+
+static const char lev_to_cb[10][4] = {
+{ 0, 0, 1, -1 }, { 2, 0, 0, -1 }, { 1, 0, 0, 0 }, { 2, 0, -1, 1 }, {
0, 0, 1, -1 },
+{ 0, 1, 2, -2 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 },
+{ 0, 2, 3, -4 }
+};
static av_always_inline int decode_ac_coeffs(AVCodecContext *avctx,
GetBitContext *gb,
int16_t *out, int
blocks_per_slice)
@@ -504,18 +540,22 @@ static av_always_inline int
decode_ac_coeffs(AVCodecContext *avctx, GetBitContex
block_mask = blo
[FFmpeg-devel] [PATCH 3/7] proresdec2: use VLC for level instead of EC switch
x86/x64: 61/52 -> 55/46
Around 7-10% speedup.
Run and DC do not lend themselves to such changes, likely because
their distribution is less skewed, and need larger average vlc read
iterations.
---
libavcodec/proresdec.h | 1 +
libavcodec/proresdec2.c | 77 ++---
2 files changed, 66 insertions(+), 12 deletions(-)
diff --git a/libavcodec/proresdec.h b/libavcodec/proresdec.h
index 1e48752e6f..7ebacaeb21 100644
--- a/libavcodec/proresdec.h
+++ b/libavcodec/proresdec.h
@@ -22,6 +22,7 @@
#ifndef AVCODEC_PRORESDEC_H
#define AVCODEC_PRORESDEC_H
+#define CACHED_BITSTREAM_READER 1
#include "get_bits.h"
#include "blockdsp.h"
#include "proresdsp.h"
diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index 65e8b01755..91c689d9ef 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -24,17 +24,17 @@
* Known FOURCCs: 'apch' (HQ), 'apcn' (SD), 'apcs' (LT), 'apco' (Proxy),
'ap4h' (), 'ap4x' ( XQ)
*/
-#define CACHED_BITSTREAM_READER 1
+//#define DEBUG
#include "config_components.h"
#include "libavutil/internal.h"
#include "libavutil/mem_internal.h"
+#include "libavutil/thread.h"
#include "avcodec.h"
#include "codec_internal.h"
#include "decode.h"
-#include "get_bits.h"
#include "hwaccel_internal.h"
#include "hwconfig.h"
#include "idctdsp.h"
@@ -129,8 +129,64 @@ static void unpack_alpha_12(GetBitContext *gb, uint16_t
*dst, int num_coeffs,
}
}
+#define AC_BITS 12
+#define PRORES_LEV_BITS 9
+
+static const uint8_t ac_info[] = { 0x04, 0x0A, 0x05, 0x06, 0x28, 0x4C };
+static VLC ac_vlc[6];
+
+static av_cold void init_vlcs(void)
+{
+int i;
+for (i = 0; i < sizeof(ac_info); i++) {
+uint32_t ac_codes[1<> 5; /* rice code order */
+exp_order = (codebook >> 2) & 7; /* exp golomb code order */
+
+switch_val = (switch_bits+1) << rice_order;
+
+// Values are actually transformed, but this is more a wrapping
+for (ac = 0; ac <1<= switch_val) {
+val += (1 << exp_order) - switch_val;
+exponent = av_log2(val);
+bits = exponent+1+switch_bits-exp_order/*0*/ +
exponent+1/*val*/;
+code = val;
+} else if (rice_order) {
+bits = (val >> rice_order)/*0*/ + 1/*1*/ + rice_order/*val*/;
+code = (1 << rice_order) | val;
+} else {
+bits = val/*0*/ + 1/*1*/;
+code = 1;
+}
+if (bits > max_bits) max_bits = bits;
+ac_bits [ac] = bits;
+ac_codes[ac] = code;
+}
+
+ff_free_vlc(ac_vlc+i);
+
+if (init_vlc(ac_vlc+i, PRORES_LEV_BITS, 1pix_fmt = AV_PIX_FMT_NONE;
+// init dc_tables
+ff_thread_once(&init_static_once, init_vlcs);
+
if (avctx->bits_per_raw_sample == 10){
ctx->unpack_alpha = unpack_alpha_10;
} else if (avctx->bits_per_raw_sample == 12){
@@ -510,7 +569,7 @@ static av_always_inline int decode_dc_coeffs(GetBitContext
*gb, int16_t *out,
return 0;
}
-// adaptive codebook switching lut according to previous run/level values
+// adaptive codebook switching lut according to previous run values
static const char run_to_cb[16][4] = {
{ 2, 0, -1, 1 }, { 2, 0, -1, 1 }, { 1, 0, 0, 0 }, { 1, 0, 0, 0 }, {
0, 0, 1, -1 },
{ 1, 1, 1, 0 }, { 1, 1, 1, 0 }, { 1, 1, 1, 0 }, { 1, 1, 1, 0 },
@@ -518,12 +577,6 @@ static const char run_to_cb[16][4] = {
{ 0, 2, 3, -4 }
};
-static const char lev_to_cb[10][4] = {
-{ 0, 0, 1, -1 }, { 2, 0, 0, -1 }, { 1, 0, 0, 0 }, { 2, 0, -1, 1 }, {
0, 0, 1, -1 },
-{ 0, 1, 2, -2 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 },
-{ 0, 2, 3, -4 }
-};
-
static av_always_inline int decode_ac_coeffs(AVCodecContext *avctx,
GetBitContext *gb,
int16_t *out, int
blocks_per_slice)
{
@@ -540,8 +593,9 @@ static av_always_inline int decode_ac_coeffs(AVCodecContext
*avctx, GetBitContex
block_mask = blocks_per_slice - 1;
for (pos = block_mask;;) {
+static const uint8_t ctx_to_tbl[] = { 0, 1, 2, 3, 0, 4, 4, 4, 4, 5 };
+const VLC* tbl = ac_vlc + ctx_to_tbl[FFMIN(level, 9)];
unsigned int runcb = FFMIN(run, 15);
-unsigned int levcb = FFMIN(level, 9);
bits_rem = get_bits_left(gb);
if (!bits_rem || (bits_rem < 16 && !show_bits(gb, bits_rem)))
break;
@@ -554,8 +608,7 @@ static av_always_inline int decode_ac_coeffs(AVCodecContext
*avctx, GetBitContex
return AVERROR_INVALIDDATA;
}
-DECODE_CODEWORD2(level, lev_to_cb[levcb][0], lev_to_cb[levcb][1],
-lev_to_cb[levcb][2], lev_to_cb[levcb][3]);
+level = get_vlc2(gb, tbl->table, PRORES_LEV_BITS, 3);
level += 1;
[FFmpeg-devel] [PATCH 4/7] proresdec2: offset VLCs by 1 to avoid 1 add
Pretty harmless, but not much gained either. --- libavcodec/proresdec2.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c index 91c689d9ef..e3cef402d7 100644 --- a/libavcodec/proresdec2.c +++ b/libavcodec/proresdec2.c @@ -152,7 +152,9 @@ static av_cold void init_vlcs(void) switch_val = (switch_bits+1) << rice_order; // Values are actually transformed, but this is more a wrapping -for (ac = 0; ac <1< max_bits) max_bits = bits; -ac_bits [ac] = bits; -ac_codes[ac] = code; +ac_bits [ac+1] = bits; +ac_codes[ac+1] = code; } ff_free_vlc(ac_vlc+i); @@ -609,7 +611,6 @@ static av_always_inline int decode_ac_coeffs(AVCodecContext *avctx, GetBitContex } level = get_vlc2(gb, tbl->table, PRORES_LEV_BITS, 3); -level += 1; i = pos >> log2_block_count; -- 2.42.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/7] proresdec2: use VLC for small runs and levels
Basically, the catch-all codebook is for on average long codewords,
and with a distribution such that the 3-step VLC reading is not
efficient. Furthermore, the complete unrolling make the actual code
smaller than the macro, and as the maximum codelength is smaller,
smaller amounts of bits, optimized for run and for level, can be read.
---
libavcodec/proresdec2.c | 53 +++--
1 file changed, 24 insertions(+), 29 deletions(-)
diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index e3cef402d7..02e1d82d00 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -132,7 +132,7 @@ static void unpack_alpha_12(GetBitContext *gb, uint16_t
*dst, int num_coeffs,
#define AC_BITS 12
#define PRORES_LEV_BITS 9
-static const uint8_t ac_info[] = { 0x04, 0x0A, 0x05, 0x06, 0x28, 0x4C };
+static const uint8_t ac_info[] = { 0x04, 0x0A, 0x05, 0x06, 0x28, 0x29 };
static VLC ac_vlc[6];
static av_cold void init_vlcs(void)
@@ -152,9 +152,7 @@ static av_cold void init_vlcs(void)
switch_val = (switch_bits+1) << rice_order;
// Values are actually transformed, but this is more a wrapping
-ac_codes[0] = 0;
-ac_bits[0] = 0;
-for (ac = 0; ac < (1< max_bits) max_bits = bits;
-ac_bits [ac+1] = bits;
-ac_codes[ac+1] = code;
+ac_bits [ac] = bits;
+ac_codes[ac] = code;
}
ff_free_vlc(ac_vlc+i);
@@ -507,12 +505,9 @@ static int decode_picture_header(AVCodecContext *avctx,
const uint8_t *buf, cons
bits = exp_order - switch_bits + (q<<1);\
val = READ_BITS(gb, bits) - (1 << exp_order) + \
((switch_bits + 1) << rice_order); \
-} else if (rice_order) {\
-skip_remaining(gb, q+1);\
-val = (q << rice_order) + get_bits(gb, rice_order); \
} else {\
-val = q;\
skip_remaining(gb, q+1);\
+val = rice_order ? (q << rice_order) + get_bits(gb, rice_order) :
q;\
} \
} while (0)
@@ -527,12 +522,10 @@ static int decode_picture_header(AVCodecContext *avctx,
const uint8_t *buf, cons
if (q > switch_bits) { /* exp golomb */ \
bits = (q<<1) + (int)diff; \
val = READ_BITS(gb, bits) + (int)offset;\
-} else if (rice_order) {\
-skip_remaining(gb, q+1);\
-val = (q << rice_order) + get_bits(gb, rice_order); \
} else {\
-val = q;\
skip_remaining(gb, q+1);\
+val = rice_order ? (q << rice_order) + show_bits(gb, rice_order) :
q; \
+skip_remaining(gb, rice_order); \
} \
} while (0)
@@ -571,14 +564,6 @@ static av_always_inline int decode_dc_coeffs(GetBitContext
*gb, int16_t *out,
return 0;
}
-// adaptive codebook switching lut according to previous run values
-static const char run_to_cb[16][4] = {
-{ 2, 0, -1, 1 }, { 2, 0, -1, 1 }, { 1, 0, 0, 0 }, { 1, 0, 0, 0 }, {
0, 0, 1, -1 },
-{ 1, 1, 1, 0 }, { 1, 1, 1, 0 }, { 1, 1, 1, 0 }, { 1, 1, 1, 0 },
-{ 0, 1, 2, -2 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 }, {
0, 1, 2, -2 }, { 0, 1, 2, -2 },
-{ 0, 2, 3, -4 }
-};
-
static av_always_inline int decode_ac_coeffs(AVCodecContext *avctx,
GetBitContext *gb,
int16_t *out, int
blocks_per_slice)
{
@@ -595,22 +580,32 @@ static av_always_inline int
decode_ac_coeffs(AVCodecContext *avctx, GetBitContex
block_mask = blocks_per_slice - 1;
for (pos = block_mask;;) {
-static const uint8_t ctx_to_tbl[] = { 0, 1, 2, 3, 0, 4, 4, 4, 4, 5 };
-const VLC* tbl = ac_vlc + ctx_to_tbl[FFMIN(level, 9)];
-unsigned int runcb = FFMIN(run, 15);
bits_rem = get_bits_left(gb);
-if (!bits_rem || (bits_rem < 16 && !show_bits(gb, bits_rem)))
+if (!bits_rem || (bits_rem < 14 && !show_bits(gb, bits_rem)))
break;
-DECODE_CODEWORD2(run, run_to_cb[runcb][0], run_to_cb[runcb][1],
- run_to_cb[runcb][2], run_to_cb[runcb][3]);
+if (run < 15) {
+static const uint8_t ctx_to_tbl[] = { 3, 3, 2, 2, 0, 5, 5, 5, 5,
4, 4, 4, 4,
[FFmpeg-devel] [PATCH 6/7] proresdec2: remove a useless DC codebook entry
---
libavcodec/proresdec2.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index 02e1d82d00..b20021c622 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -534,9 +534,9 @@ static int decode_picture_header(AVCodecContext *avctx,
const uint8_t *buf, cons
#define FIRST_DC_CB 0xB8
-static const char dc_codebook[7][4] = {
+static const char dc_codebook[6][4] = {
{ 0, 0, 1, -1 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 },
-{ 1, 2, 2, 0 }, { 1, 2, 2, 0 }, { 0, 3, 4, -8 }, { 0, 3, 4, -8 }
+{ 1, 2, 2, 0 }, { 1, 2, 2, 0 }, { 0, 3, 4, -8 }
};
static av_always_inline int decode_dc_coeffs(GetBitContext *gb, int16_t *out,
@@ -553,7 +553,7 @@ static av_always_inline int decode_dc_coeffs(GetBitContext
*gb, int16_t *out,
code = 5;
sign = 0;
for (i = 1; i < blocks_per_slice; i++, out += 64) {
-unsigned int dccb = FFMIN(code, 6U);
+unsigned int dccb = FFMIN(code, 5U);
DECODE_CODEWORD2(code, dc_codebook[dccb][0], dc_codebook[dccb][1],
dc_codebook[dccb][2], dc_codebook[dccb][3]);
if(code) sign ^= -(code & 1);
--
2.42.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 7/7] prores: use VLC LUTs
One indirection less, around 1% speedup.
---
libavcodec/proresdec2.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index b20021c622..85f81d92d3 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -561,12 +561,18 @@ static av_always_inline int
decode_dc_coeffs(GetBitContext *gb, int16_t *out,
prev_dc += (((code + 1) >> 1) ^ sign) - sign;
out[0] = prev_dc;
}
-return 0;
+return 0;
}
+#include "libavutil/timer.h"
+
+
static av_always_inline int decode_ac_coeffs(AVCodecContext *avctx,
GetBitContext *gb,
int16_t *out, int
blocks_per_slice)
{
+ static VLC* lvl_vlc[9] = { &ac_vlc[0], &ac_vlc[1], &ac_vlc[2],
&ac_vlc[3], &ac_vlc[0], &ac_vlc[4], &ac_vlc[4], &ac_vlc[4], &ac_vlc[4], };
+ static VLC* run_vlc[15] = { &ac_vlc[3], &ac_vlc[3], &ac_vlc[2],
&ac_vlc[2], &ac_vlc[0], &ac_vlc[5], &ac_vlc[5], &ac_vlc[5], &ac_vlc[5],
+ &ac_vlc[4], &ac_vlc[4], &ac_vlc[4],
&ac_vlc[4], &ac_vlc[4], &ac_vlc[4], };
const ProresContext *ctx = avctx->priv_data;
int block_mask, sign;
unsigned pos, run, level;
@@ -585,9 +591,7 @@ static av_always_inline int decode_ac_coeffs(AVCodecContext
*avctx, GetBitContex
break;
if (run < 15) {
-static const uint8_t ctx_to_tbl[] = { 3, 3, 2, 2, 0, 5, 5, 5, 5,
4, 4, 4, 4, 4, 4 };
-const VLC* tbl = ac_vlc + ctx_to_tbl[run];
-run = get_vlc2(gb, tbl->table, PRORES_LEV_BITS, 3);
+run = get_vlc2(gb, run_vlc[run]->table, PRORES_LEV_BITS, 3);
} else {
unsigned int bits = 21 - 2*av_log2(show_bits(gb, 10));
run = READ_BITS(gb, bits) - 4; // up to 17 bits
@@ -599,9 +603,7 @@ static av_always_inline int decode_ac_coeffs(AVCodecContext
*avctx, GetBitContex
}
if (level < 9) {
-static const uint8_t ctx_to_tbl[] = { 0, 1, 2, 3, 0, 4, 4, 4, 4 };
-const VLC* tbl = ac_vlc + ctx_to_tbl[level];
-level = 1+get_vlc2(gb, tbl->table, PRORES_LEV_BITS, 3);
+level = 1+get_vlc2(gb, lvl_vlc[level]->table, PRORES_LEV_BITS, 3);
} else {
unsigned int bits = 25 - 2*av_log2(show_bits(gb, 12));
level = READ_BITS(gb, bits) - 4 + 1; // up to 21 bits
--
2.42.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 1/7] proresdec2: port and fix for cached reader
Le ven. 8 sept. 2023 à 10:15, Christophe Gisquet a écrit : > > Summary of changes git send-email --cover-letter apparently didn't let me edit one, so here goes. This patchset requires my previous one improving the cached bitstream reader, and serves as its justification. It, basically, moves to using VLC wherever possible, and in particular when codewords are sufficiently short/there's some kind of well-behaved laplacian distribution for codewords that make VLCs efficient. Total speedup is around 40% here. -- Christophe ___ 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/7] proresdec2: port and fix for cached reader
Christophe Gisquet: > Le ven. 8 sept. 2023 à 10:15, Christophe Gisquet > a écrit : >> >> Summary of changes > > git send-email --cover-letter apparently didn't let me edit one, so here goes. > Use --compose. > This patchset requires my previous one improving the cached bitstream > reader, and serves as its justification. It, basically, moves to using > VLC wherever possible, and in particular when codewords are > sufficiently short/there's some kind of well-behaved laplacian > distribution for codewords that make VLCs efficient. > > Total speedup is around 40% here. > ___ 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/7] proresdec2: port and fix for cached reader
Andreas Rheinhardt: > Christophe Gisquet: >> Le ven. 8 sept. 2023 à 10:15, Christophe Gisquet >> a écrit : >>> >>> Summary of changes >> >> git send-email --cover-letter apparently didn't let me edit one, so here >> goes. >> > > Use --compose. Or even better: --cover-letter --annotate That way you get a default cover-letter to annotate > >> This patchset requires my previous one improving the cached bitstream >> reader, and serves as its justification. It, basically, moves to using >> VLC wherever possible, and in particular when codewords are >> sufficiently short/there's some kind of well-behaved laplacian >> distribution for codewords that make VLCs efficient. >> >> Total speedup is around 40% here. >> ___ 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/7] proresdec2: port and fix for cached reader
Christophe Gisquet:
> Summary of changes
> - move back to regular, non-macro, get_bits API
> - reduce the lookup to switch the coding method
> - shorter reads wherever possible, in particular for the end of bitstream
> (16 bits instead of 32, as per the above)
>
> There are cases that really need longer lengths (larger EG codes) of up
> to 27 bits.
>
> Win64: 6.10 -> 4.87 (~20% speedup)
>
> Reference for an hypothetical 32bits version of the cached reader:
> Win32: 11.4 -> 9.8 (14%, because iDCT is not SIMDed)
> ---
The commit message claims to fix something; what does it fix?
Also, changing to the non-macro API should be done in a separate commit
to the one changing the type of bitstream reader.
Furthermore, you should also provide information about the code size
impact when switching the type of reader.
> libavcodec/proresdec2.c | 53 ++---
> 1 file changed, 23 insertions(+), 30 deletions(-)
>
> diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
> index 9297860946..6e243cfc17 100644
> --- a/libavcodec/proresdec2.c
> +++ b/libavcodec/proresdec2.c
> @@ -24,9 +24,7 @@
> * Known FOURCCs: 'apch' (HQ), 'apcn' (SD), 'apcs' (LT), 'apco' (Proxy),
> 'ap4h' (), 'ap4x' ( XQ)
> */
>
> -//#define DEBUG
> -
> -#define LONG_BITSTREAM_READER
> +#define CACHED_BITSTREAM_READER 1
>
> #include "config_components.h"
>
> @@ -422,35 +420,37 @@ static int decode_picture_header(AVCodecContext *avctx,
> const uint8_t *buf, cons
> return pic_data_size;
> }
>
> -#define DECODE_CODEWORD(val, codebook, SKIP)\
> +/* bitstream_read may fail on 32bits ARCHS for >24 bits, so use long version
> there */
> +#if 0 //BITSTREAM_BITS == 32
> +# define READ_BITS get_bits_long
> +#else
> +# define READ_BITS get_bits
> +#endif
> +
> +#define DECODE_CODEWORD(val, codebook) \
> do {\
> unsigned int rice_order, exp_order, switch_bits;\
> unsigned int q, buf, bits; \
> \
> -UPDATE_CACHE(re, gb); \
> -buf = GET_CACHE(re, gb);\
> +buf = show_bits(gb, 14);\
> \
> /* number of bits to switch between rice and exp golomb */ \
> switch_bits = codebook & 3;\
> rice_order = codebook >> 5; \
> exp_order = (codebook >> 2) & 7; \
> \
> -q = 31 - av_log2(buf); \
> +q = 13 - av_log2(buf); \
> \
> if (q > switch_bits) { /* exp golomb */ \
> bits = exp_order - switch_bits + (q<<1);\
> -if (bits > FFMIN(MIN_CACHE_BITS, 31)) \
> -return AVERROR_INVALIDDATA; \
> -val = SHOW_UBITS(re, gb, bits) - (1 << exp_order) + \
> +val = READ_BITS(gb, bits) - (1 << exp_order) + \
> ((switch_bits + 1) << rice_order); \
> -SKIP(re, gb, bits); \
> } else if (rice_order) {\
> -SKIP_BITS(re, gb, q+1); \
> -val = (q << rice_order) + SHOW_UBITS(re, gb, rice_order); \
> -SKIP(re, gb, rice_order); \
> +skip_remaining(gb, q+1);\
> +val = (q << rice_order) + get_bits(gb, rice_order); \
> } else {\
> val = q;\
> -SKIP(re, gb, q+1); \
> +skip_remaining(gb, q+1);\
> } \
> } while (0)
>
> @@ -466,9 +466,7 @@ static av_always_inline int
> decode_dc_coeffs(GetBitContext *gb, int16_t *out,
> int16_t prev_dc;
> int code, i, sign;
>
> -OPEN_READER(re, gb);
> -
> -DECODE_CODEWORD(code, FIRST_DC_CB, LAST_SKIP_BITS);
> +DECODE_CODEWORD(code, FIRST_DC_CB);
> prev_dc = TOSIGNED(code);
> out[0] = prev_dc;
>
> @@ -477,13 +
Re: [FFmpeg-devel] [PATCH 2/7] proresdec2: store precomputed EC parameters
Christophe Gisquet:
> Having the various orders and offsets stored in a codebook is compact
> but causes additional computations. Using instead a table for the
> precomputed results achieve some speedups at the cost of ~132 bytes.
>
> Around 5% speedup.
> ---
> libavcodec/proresdec2.c | 54 +++--
> 1 file changed, 47 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
> index 6e243cfc17..65e8b01755 100644
> --- a/libavcodec/proresdec2.c
> +++ b/libavcodec/proresdec2.c
> @@ -427,6 +427,7 @@ static int decode_picture_header(AVCodecContext *avctx,
> const uint8_t *buf, cons
> # define READ_BITS get_bits
> #endif
>
> +/* Kept for reference and because clearer for first DC */
> #define DECODE_CODEWORD(val, codebook) \
> do {\
> unsigned int rice_order, exp_order, switch_bits;\
> @@ -454,18 +455,41 @@ static int decode_picture_header(AVCodecContext *avctx,
> const uint8_t *buf, cons
> } \
> } while (0)
>
> +/* number of bits to switch between rice and exp golomb */
> +#define DECODE_CODEWORD2(val, switch_bits, rice_order, diff, offset)\
> +do {\
> +unsigned int q, buf, bits; \
> +\
> +buf = show_bits(gb, 14);\
> +q = 13 - av_log2(buf); \
> +\
> +if (q > switch_bits) { /* exp golomb */ \
> +bits = (q<<1) + (int)diff; \
> +val = READ_BITS(gb, bits) + (int)offset;\
> +} else if (rice_order) {\
> +skip_remaining(gb, q+1);\
> +val = (q << rice_order) + get_bits(gb, rice_order); \
> +} else {\
> +val = q;\
> +skip_remaining(gb, q+1);\
> +} \
> +} while (0)
> +
> +
> #define TOSIGNED(x) (((x) >> 1) ^ (-((x) & 1)))
>
> #define FIRST_DC_CB 0xB8
>
> -static const uint8_t dc_codebook[7] = { 0x04, 0x28, 0x28, 0x4D, 0x4D, 0x70,
> 0x70};
> +static const char dc_codebook[7][4] = {
> +{ 0, 0, 1, -1 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 },
> +{ 1, 2, 2, 0 }, { 1, 2, 2, 0 }, { 0, 3, 4, -8 }, { 0, 3, 4, -8 }
> +};
>
> static av_always_inline int decode_dc_coeffs(GetBitContext *gb, int16_t *out,
>int blocks_per_slice)
> {
> int16_t prev_dc;
> int code, i, sign;
> -
> DECODE_CODEWORD(code, FIRST_DC_CB);
> prev_dc = TOSIGNED(code);
> out[0] = prev_dc;
> @@ -475,7 +499,9 @@ static av_always_inline int
> decode_dc_coeffs(GetBitContext *gb, int16_t *out,
> code = 5;
> sign = 0;
> for (i = 1; i < blocks_per_slice; i++, out += 64) {
> -DECODE_CODEWORD(code, dc_codebook[FFMIN(code, 6U)]);
> +unsigned int dccb = FFMIN(code, 6U);
> +DECODE_CODEWORD2(code, dc_codebook[dccb][0], dc_codebook[dccb][1],
> + dc_codebook[dccb][2], dc_codebook[dccb][3]);
> if(code) sign ^= -(code & 1);
> else sign = 0;
> prev_dc += (((code + 1) >> 1) ^ sign) - sign;
> @@ -485,8 +511,18 @@ static av_always_inline int
> decode_dc_coeffs(GetBitContext *gb, int16_t *out,
> }
>
> // adaptive codebook switching lut according to previous run/level values
> -static const uint8_t run_to_cb[16] = { 0x06, 0x06, 0x05, 0x05, 0x04, 0x29,
> 0x29, 0x29, 0x29, 0x28, 0x28, 0x28, 0x28, 0x28, 0x28, 0x4C };
> -static const uint8_t lev_to_cb[10] = { 0x04, 0x0A, 0x05, 0x06, 0x04, 0x28,
> 0x28, 0x28, 0x28, 0x4C };
> +static const char run_to_cb[16][4] = {
> +{ 2, 0, -1, 1 }, { 2, 0, -1, 1 }, { 1, 0, 0, 0 }, { 1, 0, 0, 0 }, {
> 0, 0, 1, -1 },
> +{ 1, 1, 1, 0 }, { 1, 1, 1, 0 }, { 1, 1, 1, 0 }, { 1, 1, 1, 0 },
> +{ 0, 1, 2, -2 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 }, {
> 0, 1, 2, -2 }, { 0, 1, 2, -2 },
> +{ 0, 2, 3, -4 }
> +};
> +
> +static const char lev_to_cb[10][4] = {
You seem to require signed chars here, but this is not a given on many
platforms. Better use int8_t.
> +{ 0, 0, 1, -1 }, { 2, 0, 0, -1 }, { 1, 0, 0, 0 }, { 2, 0, -1, 1 }, {
> 0, 0, 1, -1 },
> +{ 0, 1, 2, -2 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 }
Re: [FFmpeg-devel] [PATCH 3/7] proresdec2: use VLC for level instead of EC switch
Christophe Gisquet:
> x86/x64: 61/52 -> 55/46
> Around 7-10% speedup.
>
> Run and DC do not lend themselves to such changes, likely because
> their distribution is less skewed, and need larger average vlc read
> iterations.
> ---
> libavcodec/proresdec.h | 1 +
> libavcodec/proresdec2.c | 77 ++---
> 2 files changed, 66 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/proresdec.h b/libavcodec/proresdec.h
> index 1e48752e6f..7ebacaeb21 100644
> --- a/libavcodec/proresdec.h
> +++ b/libavcodec/proresdec.h
> @@ -22,6 +22,7 @@
> #ifndef AVCODEC_PRORESDEC_H
> #define AVCODEC_PRORESDEC_H
>
> +#define CACHED_BITSTREAM_READER 1
This should be in the commit switching to the cached bitstream reader.
> #include "get_bits.h"
> #include "blockdsp.h"
> #include "proresdsp.h"
> diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
> index 65e8b01755..91c689d9ef 100644
> --- a/libavcodec/proresdec2.c
> +++ b/libavcodec/proresdec2.c
> @@ -24,17 +24,17 @@
> * Known FOURCCs: 'apch' (HQ), 'apcn' (SD), 'apcs' (LT), 'apco' (Proxy),
> 'ap4h' (), 'ap4x' ( XQ)
> */
>
> -#define CACHED_BITSTREAM_READER 1
> +//#define DEBUG
>
> #include "config_components.h"
>
> #include "libavutil/internal.h"
> #include "libavutil/mem_internal.h"
> +#include "libavutil/thread.h"
>
> #include "avcodec.h"
> #include "codec_internal.h"
> #include "decode.h"
> -#include "get_bits.h"
> #include "hwaccel_internal.h"
> #include "hwconfig.h"
> #include "idctdsp.h"
> @@ -129,8 +129,64 @@ static void unpack_alpha_12(GetBitContext *gb, uint16_t
> *dst, int num_coeffs,
> }
> }
>
> +#define AC_BITS 12
> +#define PRORES_LEV_BITS 9
> +
> +static const uint8_t ac_info[] = { 0x04, 0x0A, 0x05, 0x06, 0x28, 0x4C };
> +static VLC ac_vlc[6];
> +
> +static av_cold void init_vlcs(void)
> +{
> +int i;
> +for (i = 0; i < sizeof(ac_info); i++) {
FF_ARRAY_ELEMS() is cleaner; also we support and prefer declarations
inside for-loops: for (int i = 0;
> +uint32_t ac_codes[1< +uint8_t ac_bits[1< +unsigned int rice_order, exp_order, switch_bits, switch_val;
> +int ac, max_bits = 0, codebook = ac_info[i];
> +
> +/* number of prefix bits to switch between Rice and expGolomb */
> +switch_bits = (codebook & 3);
> +rice_order = codebook >> 5; /* rice code order */
> +exp_order = (codebook >> 2) & 7; /* exp golomb code order */
> +
> +switch_val = (switch_bits+1) << rice_order;
> +
> +// Values are actually transformed, but this is more a wrapping
> +for (ac = 0; ac <1< +int exponent, bits, val = ac;
> +unsigned int code;
> +
> +if (val >= switch_val) {
> +val += (1 << exp_order) - switch_val;
> +exponent = av_log2(val);
> +bits = exponent+1+switch_bits-exp_order/*0*/ +
> exponent+1/*val*/;
> +code = val;
> +} else if (rice_order) {
> +bits = (val >> rice_order)/*0*/ + 1/*1*/ + rice_order/*val*/;
> +code = (1 << rice_order) | val;
> +} else {
> +bits = val/*0*/ + 1/*1*/;
> +code = 1;
> +}
> +if (bits > max_bits) max_bits = bits;
> +ac_bits [ac] = bits;
> +ac_codes[ac] = code;
> +}
> +
> +ff_free_vlc(ac_vlc+i);
This is unnecessary, as the VLC is initially blank and is not
initialized multiple times.
> +
> +if (init_vlc(ac_vlc+i, PRORES_LEV_BITS, 1< + ac_bits, 1, 1, ac_codes, 4, 4, 0) < 0) {
> +av_log(NULL, AV_LOG_ERROR, "Error for %d(0x%02X), max bits %d\n",
> + i, codebook, max_bits);
> +break; //return AVERROR_BUG;
This is not how you initialize a static table (you miss the
INIT_VLC_USE_NEW_STATIC flag and don't set the static store buffer).
Search for INIT_VLC_STATIC_OVERLONG for an idea of how to do it.
> +}
> +}
> +}
> +
> static av_cold int decode_init(AVCodecContext *avctx)
> {
> +static AVOnce init_static_once = AV_ONCE_INIT;
> int ret = 0;
> ProresContext *ctx = avctx->priv_data;
> uint8_t idct_permutation[64];
> @@ -184,6 +240,9 @@ static av_cold int decode_init(AVCodecContext *avctx)
>
> ctx->pix_fmt = AV_PIX_FMT_NONE;
>
> +// init dc_tables
> +ff_thread_once(&init_static_once, init_vlcs);
> +
> if (avctx->bits_per_raw_sample == 10){
> ctx->unpack_alpha = unpack_alpha_10;
> } else if (avctx->bits_per_raw_sample == 12){
> @@ -510,7 +569,7 @@ static av_always_inline int
> decode_dc_coeffs(GetBitContext *gb, int16_t *out,
> return 0;
> }
>
> -// adaptive codebook switching lut according to previous run/level values
> +// adaptive codebook switching lut according to previous run values
> static const char run_to_cb[16][4] = {
> { 2, 0, -1, 1 }, { 2, 0, -1, 1 }, {
Re: [FFmpeg-devel] [PATCH 6/7] proresdec2: remove a useless DC codebook entry
Christophe Gisquet:
> ---
> libavcodec/proresdec2.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
> index 02e1d82d00..b20021c622 100644
> --- a/libavcodec/proresdec2.c
> +++ b/libavcodec/proresdec2.c
> @@ -534,9 +534,9 @@ static int decode_picture_header(AVCodecContext *avctx,
> const uint8_t *buf, cons
>
> #define FIRST_DC_CB 0xB8
>
> -static const char dc_codebook[7][4] = {
> +static const char dc_codebook[6][4] = {
You would not need this change if you omitted the length.
> { 0, 0, 1, -1 }, { 0, 1, 2, -2 }, { 0, 1, 2, -2 },
> -{ 1, 2, 2, 0 }, { 1, 2, 2, 0 }, { 0, 3, 4, -8 }, { 0, 3, 4, -8 }
> +{ 1, 2, 2, 0 }, { 1, 2, 2, 0 }, { 0, 3, 4, -8 }
> };
>
> static av_always_inline int decode_dc_coeffs(GetBitContext *gb, int16_t *out,
> @@ -553,7 +553,7 @@ static av_always_inline int
> decode_dc_coeffs(GetBitContext *gb, int16_t *out,
> code = 5;
> sign = 0;
> for (i = 1; i < blocks_per_slice; i++, out += 64) {
> -unsigned int dccb = FFMIN(code, 6U);
> +unsigned int dccb = FFMIN(code, 5U);
You wouldn't need this change if you used FF_ARRAY_ELEMS(dc_codebook) -
1 here.
Btw: Why is this codebook entry useless? Can code never be 6?
> DECODE_CODEWORD2(code, dc_codebook[dccb][0], dc_codebook[dccb][1],
> dc_codebook[dccb][2], dc_codebook[dccb][3]);
> if(code) sign ^= -(code & 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 7/7] prores: use VLC LUTs
Christophe Gisquet:
> One indirection less, around 1% speedup.
> ---
> libavcodec/proresdec2.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
> index b20021c622..85f81d92d3 100644
> --- a/libavcodec/proresdec2.c
> +++ b/libavcodec/proresdec2.c
> @@ -561,12 +561,18 @@ static av_always_inline int
> decode_dc_coeffs(GetBitContext *gb, int16_t *out,
> prev_dc += (((code + 1) >> 1) ^ sign) - sign;
> out[0] = prev_dc;
> }
> -return 0;
> +return 0;
You are adding trailing whitespace.
> }
>
> +#include "libavutil/timer.h"
You really need to look over your patches once more before you send
them. Both of these changes are obviously not ok to commit.
> +
> +
> static av_always_inline int decode_ac_coeffs(AVCodecContext *avctx,
> GetBitContext *gb,
> int16_t *out, int
> blocks_per_slice)
> {
> + static VLC* lvl_vlc[9] = { &ac_vlc[0], &ac_vlc[1], &ac_vlc[2],
> &ac_vlc[3], &ac_vlc[0], &ac_vlc[4], &ac_vlc[4], &ac_vlc[4], &ac_vlc[4], };
> + static VLC* run_vlc[15] = { &ac_vlc[3], &ac_vlc[3], &ac_vlc[2],
> &ac_vlc[2], &ac_vlc[0], &ac_vlc[5], &ac_vlc[5], &ac_vlc[5], &ac_vlc[5],
> + &ac_vlc[4], &ac_vlc[4], &ac_vlc[4],
> &ac_vlc[4], &ac_vlc[4], &ac_vlc[4], };
This still incurs an unnecessary indirection. The LUT should not point
to the VLC's, but rather to the VLC tables (as this is the only thing
needed from them lateron given that the number of bits is a compile-time
constant. The LUT should be initialized when the VLCs are initialized.
In fact, this is so common that I always pondered adding an explicit
function for it. Will probably do so soon.
(Apart from that: This could be "static const VLC *const run_vlc[15]".)
> const ProresContext *ctx = avctx->priv_data;
> int block_mask, sign;
> unsigned pos, run, level;
> @@ -585,9 +591,7 @@ static av_always_inline int
> decode_ac_coeffs(AVCodecContext *avctx, GetBitContex
> break;
>
> if (run < 15) {
> -static const uint8_t ctx_to_tbl[] = { 3, 3, 2, 2, 0, 5, 5, 5, 5,
> 4, 4, 4, 4, 4, 4 };
> -const VLC* tbl = ac_vlc + ctx_to_tbl[run];
> -run = get_vlc2(gb, tbl->table, PRORES_LEV_BITS, 3);
> +run = get_vlc2(gb, run_vlc[run]->table, PRORES_LEV_BITS, 3);
> } else {
> unsigned int bits = 21 - 2*av_log2(show_bits(gb, 10));
> run = READ_BITS(gb, bits) - 4; // up to 17 bits
> @@ -599,9 +603,7 @@ static av_always_inline int
> decode_ac_coeffs(AVCodecContext *avctx, GetBitContex
> }
>
> if (level < 9) {
> -static const uint8_t ctx_to_tbl[] = { 0, 1, 2, 3, 0, 4, 4, 4, 4
> };
> -const VLC* tbl = ac_vlc + ctx_to_tbl[level];
> -level = 1+get_vlc2(gb, tbl->table, PRORES_LEV_BITS, 3);
> +level = 1+get_vlc2(gb, lvl_vlc[level]->table, PRORES_LEV_BITS,
> 3);
Seems like these VLCs should be offset by 1 to avoid the "1+".
> } else {
> unsigned int bits = 25 - 2*av_log2(show_bits(gb, 12));
> level = READ_BITS(gb, bits) - 4 + 1; // up to 21 bits
___
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 3/7] proresdec2: use VLC for level instead of EC switch
Andreas Rheinhardt:
> Christophe Gisquet:
>> x86/x64: 61/52 -> 55/46
>> Around 7-10% speedup.
>>
>> Run and DC do not lend themselves to such changes, likely because
>> their distribution is less skewed, and need larger average vlc read
>> iterations.
>> ---
>> libavcodec/proresdec.h | 1 +
>> libavcodec/proresdec2.c | 77 ++---
>> 2 files changed, 66 insertions(+), 12 deletions(-)
>>
>> diff --git a/libavcodec/proresdec.h b/libavcodec/proresdec.h
>> index 1e48752e6f..7ebacaeb21 100644
>> --- a/libavcodec/proresdec.h
>> +++ b/libavcodec/proresdec.h
>> @@ -22,6 +22,7 @@
>> #ifndef AVCODEC_PRORESDEC_H
>> #define AVCODEC_PRORESDEC_H
>>
>> +#define CACHED_BITSTREAM_READER 1
>
> This should be in the commit switching to the cached bitstream reader.
Correction: This header is included in videotoolbox.c and there is other
stuff that also includes get_bits.h included in said file (and currently
gets included before proresdec.h). This means that proresdec2.c and
videotoolbox.c will have different opinions on what a GetBitContext is:
It will be the non-cached one in videotoolbox.c and the cached one in
proresdec2.c. This will work in practice, because ProresContext does not
need the complete GetBitContext type at all (it does not contain a
GetBitContext at all), so offsets are not affected. But it is
nevertheless undefined behaviour and could become dangerous when using LTO.
So you should switch the type of the pointer to BitstreamContextBE* in
proresdec2.h. Furthermore, you can either include bitstream.h in
proresdec.h or (IMO better) use a forward declaration and struct
BitstreamContextBE* in the function pointer without including get_bits.h
in the header at all.
>
>> #include "get_bits.h"
>> #include "blockdsp.h"
>> #include "proresdsp.h"
>> diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
>> index 65e8b01755..91c689d9ef 100644
>> --- a/libavcodec/proresdec2.c
>> +++ b/libavcodec/proresdec2.c
>> @@ -24,17 +24,17 @@
>> * Known FOURCCs: 'apch' (HQ), 'apcn' (SD), 'apcs' (LT), 'apco' (Proxy),
>> 'ap4h' (), 'ap4x' ( XQ)
>> */
>>
>> -#define CACHED_BITSTREAM_READER 1
>> +//#define DEBUG
>>
>> #include "config_components.h"
>>
>> #include "libavutil/internal.h"
>> #include "libavutil/mem_internal.h"
>> +#include "libavutil/thread.h"
>>
>> #include "avcodec.h"
>> #include "codec_internal.h"
>> #include "decode.h"
>> -#include "get_bits.h"
>> #include "hwaccel_internal.h"
>> #include "hwconfig.h"
>> #include "idctdsp.h"
>> @@ -129,8 +129,64 @@ static void unpack_alpha_12(GetBitContext *gb, uint16_t
>> *dst, int num_coeffs,
>> }
>> }
>>
>> +#define AC_BITS 12
>> +#define PRORES_LEV_BITS 9
>> +
>> +static const uint8_t ac_info[] = { 0x04, 0x0A, 0x05, 0x06, 0x28, 0x4C };
>> +static VLC ac_vlc[6];
>> +
>> +static av_cold void init_vlcs(void)
>> +{
>> +int i;
>> +for (i = 0; i < sizeof(ac_info); i++) {
>
> FF_ARRAY_ELEMS() is cleaner; also we support and prefer declarations
> inside for-loops: for (int i = 0;
>
>> +uint32_t ac_codes[1<> +uint8_t ac_bits[1<> +unsigned int rice_order, exp_order, switch_bits, switch_val;
>> +int ac, max_bits = 0, codebook = ac_info[i];
>> +
>> +/* number of prefix bits to switch between Rice and expGolomb */
>> +switch_bits = (codebook & 3);
>> +rice_order = codebook >> 5; /* rice code order */
>> +exp_order = (codebook >> 2) & 7; /* exp golomb code order */
>> +
>> +switch_val = (switch_bits+1) << rice_order;
>> +
>> +// Values are actually transformed, but this is more a wrapping
>> +for (ac = 0; ac <1<> +int exponent, bits, val = ac;
>> +unsigned int code;
>> +
>> +if (val >= switch_val) {
>> +val += (1 << exp_order) - switch_val;
>> +exponent = av_log2(val);
>> +bits = exponent+1+switch_bits-exp_order/*0*/ +
>> exponent+1/*val*/;
>> +code = val;
>> +} else if (rice_order) {
>> +bits = (val >> rice_order)/*0*/ + 1/*1*/ +
>> rice_order/*val*/;
>> +code = (1 << rice_order) | val;
>> +} else {
>> +bits = val/*0*/ + 1/*1*/;
>> +code = 1;
>> +}
>> +if (bits > max_bits) max_bits = bits;
>> +ac_bits [ac] = bits;
>> +ac_codes[ac] = code;
>> +}
>> +
>> +ff_free_vlc(ac_vlc+i);
>
> This is unnecessary, as the VLC is initially blank and is not
> initialized multiple times.
>
>> +
>> +if (init_vlc(ac_vlc+i, PRORES_LEV_BITS, 1<> + ac_bits, 1, 1, ac_codes, 4, 4, 0) < 0) {
>> +av_log(NULL, AV_LOG_ERROR, "Error for %d(0x%02X), max bits
>> %d\n",
>> + i, codebook, max_bits);
>> +break; //return AVERROR_BUG;
>
> This is not how you initialize a static table (you miss the
> INIT_VL
Re: [FFmpeg-devel] [PATCH 7/7] prores: use VLC LUTs
Le ven. 8 sept. 2023 à 11:19, Andreas Rheinhardt a écrit : > > -return 0; > > +return 0; > > You are adding trailing whitespace. Sorry, will fix. I had to do some of this work on a misconfigured machine. > > +#include "libavutil/timer.h" > > You really need to look over your patches once more before you send > them. Both of these changes are obviously not ok to commit. I know the drill. Again, trying my best to help moving a situation that had been rotting for 6 years. > This still incurs an unnecessary indirection. The LUT should not point > to the VLC's, but rather to the VLC tables (as this is the only thing > needed from them lateron given that the number of bits is a compile-time > constant. The LUT should be initialized when the VLCs are initialized. You're right, and by the same logic from my comment, that should save things further. > Seems like these VLCs should be offset by 1 to avoid the "1+". That's what I did in a previous commit, but that was before I could share the tables. I didn't consider creating 5 more tables for this beneficial. -- Christophe ___ 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 8/8] avfilter/dnn_backend_openvino: fix wild pointer on error path
> -Original Message- > From: ffmpeg-devel On Behalf Of > Zhao Zhili > Sent: Saturday, September 2, 2023 4:24 PM > To: ffmpeg-devel@ffmpeg.org > Cc: Zhao Zhili > Subject: [FFmpeg-devel] [PATCH v2 8/8] avfilter/dnn_backend_openvino: fix > wild pointer on error path > > From: Zhao Zhili > > When > ov_model_const_input_by_name/ov_model_const_output_by_name > failed, input_port/output_port can be wild pointer. > > Signed-off-by: Zhao Zhili > --- > libavfilter/dnn/dnn_backend_openvino.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > The patch set looks good to me, 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 v3] avcodec/av1dec: export pixel format even if no hardware decoder is present
On 9/7/2023 9:49 PM, James Almer wrote: And remove the AVOID_PROBING flag, given it's the last av1 decoder to be tested either way. This fixes a regression introduced in 1652f2492f88434010053289d946dab6a57e4d58, where even if forcing the native av1 decoder, if another decoder was present, like libdav1d or libaom-av1, they'd be used for probing and some fate tests would have different results. Signed-off-by: James Almer --- libavcodec/av1dec.c | 41 - tests/fate-run.sh | 11 + tests/fate/flvenc.mak | 4 ++-- tests/fate/lavf-container.mak | 8 +++ tests/fate/mpegps.mak | 2 +- tests/ref/fate/av1-annexb-demux | 2 +- tests/ref/lavf-fate/av1.mkv | 4 ++-- tests/ref/lavf-fate/av1.mp4 | 4 ++-- 8 files changed, 43 insertions(+), 33 deletions(-) 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".
[FFmpeg-devel] [PATCH] lavc/libaribcaption.c: add -replace_fullwidth_japanese option
This patch add `-replace_fullwidth_japanese` option
introduced in latest (1.0.1) libaribcaption.
---
doc/decoders.texi | 6 ++
libavcodec/libaribcaption.c | 11 +++
2 files changed, 17 insertions(+)
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 09b8314dd2..ee4cc6121e 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -433,6 +433,12 @@ alphanumerics with halfwidth alphanumerics.
The default is @var{true}.
+@item -replace_fullwidth_japanese @var{boolean}
+Specify whether to replace some MSZ (Middle Size, half width) fullwidth
+japanese special characters with halfwidth ones.
+
+The default is @var{true}.
+
@item -force_outline_text @var{boolean}
Specify whether always render outline text for all characters regardless of
the indication by charactor style.
diff --git a/libavcodec/libaribcaption.c b/libavcodec/libaribcaption.c
index 8a8c8f8cfd..3ec35b9ba1 100644
--- a/libavcodec/libaribcaption.c
+++ b/libavcodec/libaribcaption.c
@@ -71,6 +71,9 @@ typedef struct ARIBCaptionContext {
bool ass_single_rect;
char *font;
bool replace_fullwidth_ascii;
+#if defined(ARIBCC_VERSION)
+bool replace_fullwidth_japanese;
+#endif
bool force_stroke_text;
bool ignore_background;
bool ignore_ruby;
@@ -1005,6 +1008,10 @@ static int aribcaption_init(AVCodecContext *avctx)
}
aribcc_decoder_set_replace_msz_fullwidth_ascii(ctx->decoder,
ctx->replace_fullwidth_ascii);
+#if defined(ARIBCC_VERSION)
+aribcc_decoder_set_replace_msz_fullwidth_japanese(ctx->decoder,
+
ctx->replace_fullwidth_japanese);
+#endif
/* Similar behavior as ffmpeg tool to set canvas size */
if (ctx->canvas_width > 0 && ctx->canvas_height > 0 &&
@@ -1134,6 +1141,10 @@ static const AVOption options[] = {
OFFSET(font), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, SD },
{ "replace_fullwidth_ascii", "replace MSZ fullwidth alphanumerics with
halfwidth alphanumerics [ass, bitmap]",
OFFSET(replace_fullwidth_ascii), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1,
SD },
+#if defined(ARIBCC_VERSION)
+{ "replace_fullwidth_japanese", "replace MSZ fullwidth Japanese with
halfwidth [ass, bitmap]",
+ OFFSET(replace_fullwidth_japanese), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0,
1, SD },
+#endif
{ "force_outline_text", "always render characters with outline [(ass),
bitmap]",
OFFSET(force_stroke_text), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, SD },
{ "ignore_background", "ignore rendering caption background [(ass),
bitmap]",
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
On Thu, Aug 17, 2023 at 07:42:17PM +0200, Jean-Baptiste Kempf wrote: [...] > Propose a talk, from 5min to 30min. As i will not be at the conference, here are some quick words In the past, most developers in FFmpeg where primarly FFmpeg developers. But as FFmpeg is used by almost everyone now, that has changed and many developers in FFmpeg today are primarly developer of 3rd party projects using FFmpeg. Should decissions in FFmpeg be made to maximize benefit / be optimal for FFmpeg ? There has been a marked shift of project goals over the years. While long ago FFmpeg was "all of multimedia". With time the scope of the project has shrunk. FFserver was removed not improved, not replaced. the video encoder core we had, which encoded from mpeg1 to mpeg4, msmpeg*, rv* and others and at the time was the best encoder available (not anymore now, no) but after mpeg4-asp, modern video encoders where no longer added to ffmpeg. In one case a advanced encoder for a fringe format was rejected. AI based filters are neglegted at a time everything is shifting to neural networks and AI. Clientside / "in browser" also has become very important but is absent from our documentation, our fate tests, and so on Whats the scope of FFmpeg ? And is this direction that is taken optimal for FFmpeg, and what people want ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. 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 01/12] avradio/avformat/sdrdemux: Move agc_gain into local variable
On Mon, Jul 31, 2023 at 12:11:20AM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavformat/sdr.h | 1 - > libavformat/sdrdemux.c | 7 --- > 2 files changed, 4 insertions(+), 4 deletions(-) I will apply this patchset (of mostly bugfixes) in a few days unless there are technical objections [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. 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] fate/mpegps: Fix argument order
Regression since fb548fba04193a418f118d21b261ba05db4f480b. Signed-off-by: Andreas Rheinhardt --- tests/fate/mpegps.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/fate/mpegps.mak b/tests/fate/mpegps.mak index 807da1f713..ae301fd5e1 100644 --- a/tests/fate/mpegps.mak +++ b/tests/fate/mpegps.mak @@ -1,7 +1,7 @@ # This tests that a 16-bit pcm_dvd stream is correctly remuxed in mpegps FATE_MPEGPS-$(call DEMMUX, MPEGPS, MPEG1SYSTEM) += fate-mpegps-remuxed-pcm-demux fate-mpegps-remuxed-pcm-demux: $(SAMPLES)/mpegps/pcm_aud.mpg -fate-mpegps-remuxed-pcm-demux: CMD = stream_remux "mpeg" "$(TARGET_SAMPLES)/mpegps/pcm_aud.mpg" "mpeg" "" "-map 0:a:0" "-codec copy" +fate-mpegps-remuxed-pcm-demux: CMD = stream_remux "mpeg" "$(TARGET_SAMPLES)/mpegps/pcm_aud.mpg" "" "mpeg" "-map 0:a:0" "-codec copy" FATE_SAMPLES_FFMPEG += $(FATE_MPEGPS-yes) fate-mpegps: $(FATE_MPEGPS-yes) -- 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] fate/mpegps: Fix argument order
Andreas Rheinhardt: > Regression since fb548fba04193a418f118d21b261ba05db4f480b. > > Signed-off-by: Andreas Rheinhardt > --- > tests/fate/mpegps.mak | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/fate/mpegps.mak b/tests/fate/mpegps.mak > index 807da1f713..ae301fd5e1 100644 > --- a/tests/fate/mpegps.mak > +++ b/tests/fate/mpegps.mak > @@ -1,7 +1,7 @@ > # This tests that a 16-bit pcm_dvd stream is correctly remuxed in mpegps > FATE_MPEGPS-$(call DEMMUX, MPEGPS, MPEG1SYSTEM) += > fate-mpegps-remuxed-pcm-demux > fate-mpegps-remuxed-pcm-demux: $(SAMPLES)/mpegps/pcm_aud.mpg > -fate-mpegps-remuxed-pcm-demux: CMD = stream_remux "mpeg" > "$(TARGET_SAMPLES)/mpegps/pcm_aud.mpg" "mpeg" "" "-map 0:a:0" "-codec copy" > +fate-mpegps-remuxed-pcm-demux: CMD = stream_remux "mpeg" > "$(TARGET_SAMPLES)/mpegps/pcm_aud.mpg" "" "mpeg" "-map 0:a:0" "-codec copy" > > FATE_SAMPLES_FFMPEG += $(FATE_MPEGPS-yes) > fate-mpegps: $(FATE_MPEGPS-yes) I'll apply this triviality to make fate green/great again. - 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] [PATCH 1/7] avcodec/proresdec: Include required headers directly
Do not rely on an indirect inclusion of avcodec.h in proresdsp.h.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/proresdec.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/proresdec.h b/libavcodec/proresdec.h
index 1e48752e6f..230fca41f2 100644
--- a/libavcodec/proresdec.h
+++ b/libavcodec/proresdec.h
@@ -22,10 +22,15 @@
#ifndef AVCODEC_PRORESDEC_H
#define AVCODEC_PRORESDEC_H
+#include
+
#include "get_bits.h"
#include "blockdsp.h"
#include "proresdsp.h"
+#include "libavutil/frame.h"
+#include "libavutil/pixfmt.h"
+
typedef struct {
const uint8_t *data;
unsigned mb_x;
--
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".
[FFmpeg-devel] [PATCH 2/7] avcodec/proresdsp: Pass necessary parameter directly
Only avctx->bits_per_raw_sample is used.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/proresdec2.c | 2 +-
libavcodec/proresdsp.c | 8
libavcodec/proresdsp.h | 5 ++---
libavcodec/x86/proresdsp_init.c | 4 ++--
4 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index 9297860946..2219971b85 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -172,7 +172,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
}
ff_blockdsp_init(&ctx->bdsp);
-ret = ff_proresdsp_init(&ctx->prodsp, avctx);
+ret = ff_proresdsp_init(&ctx->prodsp, avctx->bits_per_raw_sample);
if (ret < 0) {
av_log(avctx, AV_LOG_ERROR, "Fail to init proresdsp for bits per raw
sample %d\n", avctx->bits_per_raw_sample);
return ret;
diff --git a/libavcodec/proresdsp.c b/libavcodec/proresdsp.c
index 6ed01179fe..bc253e55f7 100644
--- a/libavcodec/proresdsp.c
+++ b/libavcodec/proresdsp.c
@@ -76,12 +76,12 @@ static void prores_idct_put_12_c(uint16_t *out, ptrdiff_t
linesize, int16_t *blo
put_pixels_12(out, linesize >> 1, block);
}
-av_cold int ff_proresdsp_init(ProresDSPContext *dsp, AVCodecContext *avctx)
+av_cold int ff_proresdsp_init(ProresDSPContext *dsp, int bits_per_raw_sample)
{
-if (avctx->bits_per_raw_sample == 10) {
+if (bits_per_raw_sample == 10) {
dsp->idct_put = prores_idct_put_10_c;
dsp->idct_permutation_type = FF_IDCT_PERM_NONE;
-} else if (avctx->bits_per_raw_sample == 12) {
+} else if (bits_per_raw_sample == 12) {
dsp->idct_put = prores_idct_put_12_c;
dsp->idct_permutation_type = FF_IDCT_PERM_NONE;
} else {
@@ -89,7 +89,7 @@ av_cold int ff_proresdsp_init(ProresDSPContext *dsp,
AVCodecContext *avctx)
}
#if ARCH_X86
-ff_proresdsp_init_x86(dsp, avctx);
+ff_proresdsp_init_x86(dsp, bits_per_raw_sample);
#endif
ff_init_scantable_permutation(dsp->idct_permutation,
diff --git a/libavcodec/proresdsp.h b/libavcodec/proresdsp.h
index 37ba76b8e4..966ba3d797 100644
--- a/libavcodec/proresdsp.h
+++ b/libavcodec/proresdsp.h
@@ -25,7 +25,6 @@
#include
#include
-#include "avcodec.h"
typedef struct ProresDSPContext {
int idct_permutation_type;
@@ -33,8 +32,8 @@ typedef struct ProresDSPContext {
void (*idct_put)(uint16_t *out, ptrdiff_t linesize, int16_t *block, const
int16_t *qmat);
} ProresDSPContext;
-int ff_proresdsp_init(ProresDSPContext *dsp, AVCodecContext *avctx);
+int ff_proresdsp_init(ProresDSPContext *dsp, int bits_per_raw_sample);
-void ff_proresdsp_init_x86(ProresDSPContext *dsp, AVCodecContext *avctx);
+void ff_proresdsp_init_x86(ProresDSPContext *dsp, int bits_per_raw_sample);
#endif /* AVCODEC_PRORESDSP_H */
diff --git a/libavcodec/x86/proresdsp_init.c b/libavcodec/x86/proresdsp_init.c
index bde79ab8c0..f7abbfa692 100644
--- a/libavcodec/x86/proresdsp_init.c
+++ b/libavcodec/x86/proresdsp_init.c
@@ -30,12 +30,12 @@ void ff_prores_idct_put_10_sse2(uint16_t *dst, ptrdiff_t
linesize,
void ff_prores_idct_put_10_avx (uint16_t *dst, ptrdiff_t linesize,
int16_t *block, const int16_t *qmat);
-av_cold void ff_proresdsp_init_x86(ProresDSPContext *dsp, AVCodecContext
*avctx)
+av_cold void ff_proresdsp_init_x86(ProresDSPContext *dsp, int
bits_per_raw_sample)
{
#if ARCH_X86_64
int cpu_flags = av_get_cpu_flags();
-if (avctx->bits_per_raw_sample == 10){
+if (bits_per_raw_sample == 10) {
if (EXTERNAL_SSE2(cpu_flags)) {
dsp->idct_permutation_type = FF_IDCT_PERM_TRANSPOSE;
dsp->idct_put = ff_prores_idct_put_10_sse2;
--
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".
[FFmpeg-devel] [PATCH 3/7] avcodec/idctdsp: Avoid inclusion of avcodec.h
Not every user of idctdsp.h wants to initialize an IDCTDSPContext;
e.g. the proresdsp only uses ff_init_scantable_permutation()
and the IDCT permutation enum; similarly for cavsdsp and wmv2dsp.
Using a forward declaration here avoids an avcodec.h dependency
in the relevant files.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/alpha/idctdsp_alpha.c | 1 +
libavcodec/idctdsp.h | 21 +++--
libavcodec/ppc/idctdsp.c | 1 +
libavcodec/rtjpeg.c | 2 +-
libavcodec/rtjpeg.h | 4 +++-
tests/checkasm/idctdsp.c | 1 +
6 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/libavcodec/alpha/idctdsp_alpha.c b/libavcodec/alpha/idctdsp_alpha.c
index bd43842535..ff770c15fd 100644
--- a/libavcodec/alpha/idctdsp_alpha.c
+++ b/libavcodec/alpha/idctdsp_alpha.c
@@ -19,6 +19,7 @@
*/
#include "libavutil/attributes.h"
+#include "libavcodec/avcodec.h"
#include "libavcodec/idctdsp.h"
#include "idctdsp_alpha.h"
#include "asm.h"
diff --git a/libavcodec/idctdsp.h b/libavcodec/idctdsp.h
index 7224463349..c840a5186f 100644
--- a/libavcodec/idctdsp.h
+++ b/libavcodec/idctdsp.h
@@ -19,11 +19,12 @@
#ifndef AVCODEC_IDCTDSP_H
#define AVCODEC_IDCTDSP_H
+#include
#include
#include "config.h"
-#include "avcodec.h"
+struct AVCodecContext;
enum idct_permutation_type {
FF_IDCT_PERM_NONE,
@@ -95,23 +96,23 @@ void ff_put_pixels_clamped_c(const int16_t *block, uint8_t
*av_restrict pixels,
void ff_add_pixels_clamped_c(const int16_t *block, uint8_t *av_restrict pixels,
ptrdiff_t line_size);
-void ff_idctdsp_init(IDCTDSPContext *c, AVCodecContext *avctx);
+void ff_idctdsp_init(IDCTDSPContext *c, struct AVCodecContext *avctx);
-void ff_idctdsp_init_aarch64(IDCTDSPContext *c, AVCodecContext *avctx,
+void ff_idctdsp_init_aarch64(IDCTDSPContext *c, struct AVCodecContext *avctx,
unsigned high_bit_depth);
-void ff_idctdsp_init_alpha(IDCTDSPContext *c, AVCodecContext *avctx,
+void ff_idctdsp_init_alpha(IDCTDSPContext *c, struct AVCodecContext *avctx,
unsigned high_bit_depth);
-void ff_idctdsp_init_arm(IDCTDSPContext *c, AVCodecContext *avctx,
+void ff_idctdsp_init_arm(IDCTDSPContext *c, struct AVCodecContext *avctx,
unsigned high_bit_depth);
-void ff_idctdsp_init_ppc(IDCTDSPContext *c, AVCodecContext *avctx,
+void ff_idctdsp_init_ppc(IDCTDSPContext *c, struct AVCodecContext *avctx,
unsigned high_bit_depth);
-void ff_idctdsp_init_riscv(IDCTDSPContext *c, AVCodecContext *avctx,
+void ff_idctdsp_init_riscv(IDCTDSPContext *c, struct AVCodecContext *avctx,
unsigned high_bit_depth);
-void ff_idctdsp_init_x86(IDCTDSPContext *c, AVCodecContext *avctx,
+void ff_idctdsp_init_x86(IDCTDSPContext *c, struct AVCodecContext *avctx,
unsigned high_bit_depth);
-void ff_idctdsp_init_mips(IDCTDSPContext *c, AVCodecContext *avctx,
+void ff_idctdsp_init_mips(IDCTDSPContext *c, struct AVCodecContext *avctx,
unsigned high_bit_depth);
-void ff_idctdsp_init_loongarch(IDCTDSPContext *c, AVCodecContext *avctx,
+void ff_idctdsp_init_loongarch(IDCTDSPContext *c, struct AVCodecContext *avctx,
unsigned high_bit_depth);
#endif /* AVCODEC_IDCTDSP_H */
diff --git a/libavcodec/ppc/idctdsp.c b/libavcodec/ppc/idctdsp.c
index 29f625a01c..a7acbc5ead 100644
--- a/libavcodec/ppc/idctdsp.c
+++ b/libavcodec/ppc/idctdsp.c
@@ -40,6 +40,7 @@
#include "libavutil/ppc/cpu.h"
#include "libavutil/ppc/util_altivec.h"
+#include "libavcodec/avcodec.h"
#include "libavcodec/idctdsp.h"
#if HAVE_ALTIVEC
diff --git a/libavcodec/rtjpeg.c b/libavcodec/rtjpeg.c
index 8e02bce2e8..734e3875da 100644
--- a/libavcodec/rtjpeg.c
+++ b/libavcodec/rtjpeg.c
@@ -167,7 +167,7 @@ void ff_rtjpeg_decode_init(RTJpegContext *c, int width, int
height,
c->h = height;
}
-void ff_rtjpeg_init(RTJpegContext *c, AVCodecContext *avctx)
+void ff_rtjpeg_init(RTJpegContext *c, struct AVCodecContext *avctx)
{
int i;
diff --git a/libavcodec/rtjpeg.h b/libavcodec/rtjpeg.h
index d4dc074408..14befb5489 100644
--- a/libavcodec/rtjpeg.h
+++ b/libavcodec/rtjpeg.h
@@ -24,6 +24,7 @@
#include
+#include "libavutil/frame.h"
#include "libavutil/mem_internal.h"
#include "idctdsp.h"
@@ -39,7 +40,8 @@ typedef struct RTJpegContext {
DECLARE_ALIGNED(16, int16_t, block)[64];
} RTJpegContext;
-void ff_rtjpeg_init(RTJpegContext *c, AVCodecContext *avctx);
+struct AVCodecContext;
+void ff_rtjpeg_init(RTJpegContext *c, struct AVCodecContext *avctx);
void ff_rtjpeg_decode_init(RTJpegContext *c, int width, int height,
const uint32_t *lquant, const uint32_t *cquant);
diff --git a/tests/checkasm/idctdsp.c b/tests/checkasm/idctdsp.c
index c06e607d99..05aeddea45 100644
--- a/tests/checkasm/idctdsp.c
+++ b/tests/checkasm/idctdsp.c
@@ -2
[FFmpeg-devel] [PATCH 4/7] avcodec/vlc: Add documentation for ff_init_vlc_sparse()
Mostly taken from the documentation for ff_init_vlc_from_lengths();
also remove the documentation in vlc.c.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vlc.c | 23 ---
libavcodec/vlc.h | 29 +
2 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/libavcodec/vlc.c b/libavcodec/vlc.c
index 9656a9472c..1740b2f80f 100644
--- a/libavcodec/vlc.c
+++ b/libavcodec/vlc.c
@@ -247,29 +247,6 @@ static int vlc_common_end(VLC *vlc, int nb_bits, int
nb_codes, VLCcode *codes,
return 0;
}
-/* Build VLC decoding tables suitable for use with get_vlc().
-
- 'nb_bits' sets the decoding table size (2^nb_bits) entries. The
- bigger it is, the faster is the decoding. But it should not be too
- big to save memory and L1 cache. '9' is a good compromise.
-
- 'nb_codes' : number of vlcs codes
-
- 'bits' : table which gives the size (in bits) of each vlc code.
-
- 'codes' : table which gives the bit pattern of of each vlc code.
-
- 'symbols' : table which gives the values to be returned from get_vlc().
-
- 'xxx_wrap' : give the number of bytes between each entry of the
- 'bits' or 'codes' tables.
-
- 'xxx_size' : gives the number of bytes of each entry of the 'bits'
- or 'codes' tables. Currently 1,2 and 4 are supported.
-
- 'wrap' and 'size' make it possible to use any memory configuration and types
- (byte/word/long) to store the 'bits', 'codes', and 'symbols' tables.
-*/
int ff_init_vlc_sparse(VLC *vlc, int nb_bits, int nb_codes,
const void *bits, int bits_wrap, int bits_size,
const void *codes, int codes_wrap, int codes_size,
diff --git a/libavcodec/vlc.h b/libavcodec/vlc.h
index 46063862f6..8f2f478f9b 100644
--- a/libavcodec/vlc.h
+++ b/libavcodec/vlc.h
@@ -62,6 +62,35 @@ typedef struct RL_VLC_ELEM {
codes, codes_wrap, codes_size, \
NULL, 0, 0, flags)
+/**
+ * Build VLC decoding tables suitable for use with get_vlc2().
+ *
+ * @param[in,out] vlc The VLC to be initialized; table and table_allocated
+ * must have been set when initializing a static VLC,
+ * otherwise this will be treated as uninitialized.
+ * @param[in] nb_bits The number of bits to use for the VLC table;
+ * higher values take up more memory and cache, but
+ * allow to read codes with fewer reads.
+ * Corresponds to the `bits` parameter of get_vlc2().
+ * @param[in] nb_codes The number of provided bits, codes and (if supplied)
+ * symbol entries.
+ * @param[in] bits The lengths (in bits) of the codes. Entries > 0
+ * correspond to valid codes; entries == 0 will be
skipped.
+ * @param[in] bits_wrapStride (in bytes) of the bits table.
+ * @param[in] codes_size Size of the bits. 1, 2 and 4 are supported.
+ * @param[in] codesTable which gives the bit pattern of of each vlc
code.
+ * @param[in] codes_wrap Stride (in bytes) of the codes table.
+ * @param[in] codes_size Size of the codes. 1, 2 and 4 are supported.
+ * @param[in] symbols The symbols, i.e. what is returned from get_vlc2()
+ * when the corresponding code is encountered.
+ * May be NULL, then 0, 1, 2, 3, 4,... will be used.
+ * @param[in] symbols_wrap Stride (in bytes) of the symbols table.
+ * @param[in] symbols_size Size of the symbols. 1 and 2 are supported.
+ * @param[in] flagsA combination of the INIT_VLC_* flags.
+ *
+ * 'wrap' and 'size' make it possible to use any memory configuration and types
+ * (byte/word/int) to store the 'bits', 'codes', and 'symbols' tables.
+ */
int ff_init_vlc_sparse(VLC *vlc, int nb_bits, int nb_codes,
const void *bits, int bits_wrap, int bits_size,
const void *codes, int codes_wrap, int codes_size,
--
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".
[FFmpeg-devel] [PATCH 5/7] tools/patcheck: Remove test for ancient INIT_VLC_USE_STATIC
The flag has been removed long ago.
Signed-off-by: Andreas Rheinhardt
---
tools/patcheck | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/patcheck b/tools/patcheck
index fe52938f29..76ca408b03 100755
--- a/tools/patcheck
+++ b/tools/patcheck
@@ -51,7 +51,6 @@ hiegrep2 '\b_[a-zA-Z0-9_]{1,}'
'__(asm|attribute)([^a-zA-Z0-9]|$)' 'reserved ide
hiegrep '//[-/<\* ]*$''empty comment' $*
hiegrep '/\*[-<\* ]*\*/' 'empty comment' $*
hiegrep '(static|inline|const) *\1[^_a-zA-Z]' 'duplicate word' $*
-hiegrep 'INIT_VLC_USE_STATIC' 'forbidden ancient vlc type' $*
hiegrep '=[-+\*\&] ' 'looks like compound assignment' $*
hiegrep2 '/\*\* *[a-zA-Z0-9].*' '\*/' 'Inconsistently formatted doxygen
comment' $*
hiegrep '; */\*\*[^<]' 'Misformatted doxygen comment' $*
--
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".
[FFmpeg-devel] [PATCH 7/7] avcodec/truemotion2: Don't check before freeing VLC
ff_vlc_free() is of course compatible with freeing
a blank VLC.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/truemotion2.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/truemotion2.c b/libavcodec/truemotion2.c
index 5527fed958..366d8aefc1 100644
--- a/libavcodec/truemotion2.c
+++ b/libavcodec/truemotion2.c
@@ -222,8 +222,7 @@ out:
static void tm2_free_codes(TM2Codes *code)
{
av_free(code->recode);
-if (code->vlc.table)
-ff_vlc_free(&code->vlc);
+ff_vlc_free(&code->vlc);
}
static inline int tm2_get_token(GetBitContext *gb, TM2Codes *code)
--
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".
[FFmpeg-devel] [PATCH 6/7] avcodec/vlc: Use proper namespace
Therefore use a proper prefix for this API, e.g.
ff_init_vlc_sparse -> ff_vlc_init_sparse
ff_free_vlc-> ff_vlc_free
INIT_VLC_LE-> VLC_INIT_LE
INIT_VLC_USE_NEW_STATIC -> VLC_INIT_USE_STATIC
(The ancient INIT_VLC_USE_STATIC has been removed
in 595324e143b57a52e2329eb47b84395c70f93087, so that
the NEW has been dropped.)
Finally, reorder the flags and change their values
accordingly.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/4xm.c | 10 ++---
libavcodec/aacdec_template.c | 6 +--
libavcodec/aacps_common.c| 2 +-
libavcodec/aacsbr.h | 2 +-
libavcodec/agm.c | 8 ++--
libavcodec/asvdec.c | 10 ++---
libavcodec/atrac3.c | 4 +-
libavcodec/atrac3plus.c | 4 +-
libavcodec/atrac9dec.c | 4 +-
libavcodec/bink.c| 4 +-
libavcodec/bitstream_template.h | 2 +-
libavcodec/cfhddata.c| 4 +-
libavcodec/clearvideo.c | 12 +++---
libavcodec/cllc.c| 14 +++
libavcodec/cook.c| 8 ++--
libavcodec/dcahuff.c | 8 ++--
libavcodec/dnxhddec.c| 20 -
libavcodec/dvdec.c | 4 +-
libavcodec/exr.c | 6 +--
libavcodec/faxcompr.c| 6 +--
libavcodec/fraps.c | 4 +-
libavcodec/g2meet.c | 4 +-
libavcodec/get_bits.h| 2 +-
libavcodec/h261dec.c | 8 ++--
libavcodec/h264_cavlc.c | 32 +++
libavcodec/hq_hqa.c | 4 +-
libavcodec/hq_hqadata.c | 4 +-
libavcodec/hqx.c | 4 +-
libavcodec/hqxvlc.c | 4 +-
libavcodec/huffman.c | 2 +-
libavcodec/huffyuvdec.c | 18
libavcodec/imc.c | 4 +-
libavcodec/imm4.c| 8 ++--
libavcodec/indeo2.c | 4 +-
libavcodec/intrax8.c | 4 +-
libavcodec/ituh263dec.c | 14 +++
libavcodec/ivi.c | 12 +++---
libavcodec/jpegxl_parser.c | 16
libavcodec/magicyuv.c| 10 ++---
libavcodec/mimic.c | 2 +-
libavcodec/mjpegdec.c| 8 ++--
libavcodec/mjpegdec_common.c | 2 +-
libavcodec/mlpdec.c | 4 +-
libavcodec/mobiclip.c| 8 ++--
libavcodec/motionpixels.c| 4 +-
libavcodec/mpc7.c| 10 ++---
libavcodec/mpc8.c| 4 +-
libavcodec/mpeg12.c | 16
libavcodec/mpeg4videodec.c | 18
libavcodec/mpegaudiodec_common.c | 8 ++--
libavcodec/msmpeg4_vc1_data.c| 10 ++---
libavcodec/msmpeg4dec.c | 22 +-
libavcodec/mss2.c| 4 +-
libavcodec/mss4.c| 4 +-
libavcodec/mv30.c| 2 +-
libavcodec/mvha.c| 6 +--
libavcodec/on2avc.c | 8 ++--
libavcodec/photocd.c | 6 +--
libavcodec/qdm2_tablegen.h | 4 +-
libavcodec/qdmc.c| 4 +-
libavcodec/ralf.c| 14 +++
libavcodec/rl.c | 4 +-
libavcodec/rl.h | 2 +-
libavcodec/rv10.c| 4 +-
libavcodec/rv34.c| 4 +-
libavcodec/rv40.c| 8 ++--
libavcodec/sheervideo.c | 8 ++--
libavcodec/smacker.c | 12 +++---
libavcodec/speedhqdec.c | 14 +++
libavcodec/svq1dec.c | 16
libavcodec/truemotion2.c | 4 +-
libavcodec/tscc2.c | 4 +-
libavcodec/utvideodec.c | 18
libavcodec/vc1dec.c | 66 +++---
libavcodec/vlc.c | 32 +++
libavcodec/vlc.h | 70
libavcodec/vorbisdec.c | 6 +--
libavcodec/vp3.c | 30 +++---
libavcodec/vp6.c | 8 ++--
libavcodec/vqcdec.c | 2 +-
libavcodec/webp.c| 8 ++--
libavcodec/wma.c | 8 ++--
libavcodec/wmadec.c | 4 +-
libavcodec/wmaprodec.c | 14 +++
libavcodec/wmavoice.c| 2 +-
libavcodec/wnv1.c| 4 +-
libavcodec/ylc.c | 6 +--
87 files changed, 412 insertions(+), 410 deletions(-)
diff --git a/libavcodec/4xm.c b/libavcodec/4xm.c
index 411e50da7c..c3e3a45df5 100644
--- a/libavcodec/4xm.c
+++ b/libavcodec/4xm.c
@@ -257,10 +257,10 @@ static av_cold void init_vlcs(void)
for (j = 0; j < 4; j++) {
block_type_vlc[i][j].table = table[i][j];
block_type_vlc[i][j].table_allocated = 32;
-init_vlc(&block_type_vlc[i][j], BLOCK_TYPE_VLC_BITS, 7,
+vlc_init(&block_type_vlc[i][j], BLOCK_TYPE_VLC_BITS, 7,
&block_type_tab[i][j][0][1], 2, 1,
&block_type_tab[i][j][0][0], 2, 1,
-
Re: [FFmpeg-devel] VDD conference invitation - Dublin 22-24 Sept 2023
On 9/8/2023 2:09 PM, Michael Niedermayer wrote: > Whats the scope of FFmpeg ? > And is this direction that is taken optimal for FFmpeg, and what people want ? Not that I don't think this is an issue worth discussing (it is), but I thought it was important to note that most/many of the people who hold strong opinions on this are also people who will not meet IRL, or on calls, or even IRC for some. So, any in person discussion will be biased in on direction. I do not have an easy solution, but I thought it was important to note. - Derek ___ 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] VDD conference invitation - Dublin 22-24 Sept 2023
On 9/8/2023 10:09 AM, Michael Niedermayer wrote: There has been a marked shift of project goals over the years. While long ago FFmpeg was "all of multimedia". With time the scope of the project has shrunk. FFserver was removed not improved, not replaced. the video encoder core we had, which encoded from mpeg1 to mpeg4, msmpeg*, rv* and others and at the time was the best encoder available (not anymore now, no) but after mpeg4-asp, modern video encoders where no longer added to ffmpeg. In one case a advanced encoder for a fringe format was rejected Which encoder was this? Also, people not submitting encoders is beyond our power and has been the case for more than a decade. All important video codecs past mpeg2 (H.264/5, VP8/9, AV1, etc) have never gotten an encoder in lavc. What i would worry the most about is decoders being written in external libs and glued into lavc. Fortunately VVC is not going that way, but others have and still are. AI based filters are neglegted at a time everything is shifting to neural networks and AI. Clientside / "in browser" also has become very important but is absent from our documentation, our fate tests, and so on If there's something that's 100% corporate interest and not a project from multimedia hobbyists, it's AI. ___ 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] VDD conference invitation - Dublin 22-24 Sept 2023
Hi, On Fri, Sep 8, 2023 at 9:10 AM Michael Niedermayer wrote: > On Thu, Aug 17, 2023 at 07:42:17PM +0200, Jean-Baptiste Kempf wrote: > [...] > > Propose a talk, from 5min to 30min. > > As i will not be at the conference, here are some quick words > I really think you should reconsider this position. It would be extremely valuable if you could attend, even just for one day or part of a day. We are not scary or creepy and will not do bad things to you (or anyone). Please join us. You can skip dinner/drinks if that's not your thing. But please attend the technical discussion. Ronald ___ 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] VDD conference invitation - Dublin 22-24 Sept 2023
Le perjantaina 8. syyskuuta 2023, 16.09.49 EEST Michael Niedermayer a écrit : > In the past, most developers in FFmpeg where primarly FFmpeg developers. But > as FFmpeg is used by almost everyone now, that has changed and many > developers in FFmpeg today are primarly developer of 3rd party projects > using FFmpeg. What does that even mean, really? FFmpeg is and has practically always been first and foremost a library. It is only natural that people involved will also be involved with one or several reverse dependencies. Already twenty years ago, the FFmpeg developer body was supposedly heavily overlapping with MPlayer's... I would understand that sort of argument for projects that are mostly ad-hoc programs, and also happen to provide libraries, such as LLVM (incl. Clang) or VLC but FFmpeg, not so much. Also FWIW, while I have probably contributed to FFmpeg more in the past 12 months than in the 19 years prior, my first patch merged in FFmpeg goes way back over 10 years ago. And conversely, while I am often associated with VLC, the reality is that I have barely written any merged code in VLC in the past couple years. > Should decissions in FFmpeg be made to maximize benefit / be optimal for > FFmpeg ? How do you define benefit for FFmpeg? This is real life, not an RPG. We can't simply do linear optimisation to find out what the right choices are. With that said, everybody will agree with that vague phrasing to maximise benefit to FFmpeg, and yet nobody will agree what that means and this won't change anything. You really need to make more concrete suggestions on this particular point (and the rest of the email touches different issues, IMO). > There has been a marked shift of project goals over the years. While long > ago FFmpeg was "all of multimedia". With time the scope of the project has > shrunk. AFAICT it is rather that FFmpeg failed to capture the bits of multimedia that its reverse dependencies had already implemented decently well first - audio and video outputs, and user interfaces, being the obvious elephants in the room. I don't think FFmpeg should waste time trying to reinvent SDL and Placebo at this point, even less a web browser. Also FFmpeg *did* expand into filtering with some success. And now would probably be a good time to expand into WASM platform support (especially SIMD). > FFserver was removed not improved, not replaced. > the video encoder core we had, which encoded from mpeg1 to mpeg4, msmpeg*, > rv* and others and at the time was the best encoder available (not anymore > now, no) but after mpeg4-asp, modern video encoders where no longer added > to ffmpeg. In one case a advanced encoder for a fringe format was rejected. > AI based filters are neglegted at a time everything is shifting to neural > networks and AI. Clientside / "in browser" also has become very important > but is absent from our documentation, our fate tests, and so on This is more of a question of whether FFmpeg should have subpar implementations vs no implementations. But as much as many (including myself) will agree that it is better to implement stuff in FFmpeg than add new dependencies to it. Yet it's all cheap talk unless somebody actually does the work. As a counter example, I certainly won't be implementing EVC or VVC in FFmpeg myself, and even the HEVC implementation leaves to be desired according to many. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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] VDD conference invitation - Dublin 22-24 Sept 2023
> On Sep 8, 2023, at 6:09 AM, Michael Niedermayer > wrote: > > modern video encoders where no longer added to ffmpeg Writing a good modern video encoder is a massive undertaking, and i think it's likely that encoders are going to be mostly integrated via libraries. Along those lines though, one pattern that's becoming more popular particularly recently integrated encoder libraries is to move options into an opaque key-value string that's passed to the encoder library. For example svtav1-params. This makes sense because the parameters are frequently changing with new versions and it's hard to keep that in sync. However it gives up the self-documentation when running ffmpeg -h encoder=libsvtav1 for example. It would be nice if there were some facilities for encoders to expose their parameters to ffmpeg including min/max or value list, the default value and a description such that running -h can show a useful help message. This would also allow ffmpeg to validate the parameters and possibly expose the options as proper -flags rather than requiring jamming them through a string blob. - Cosmin ___ 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] VDD conference invitation - Dublin 22-24 Sept 2023
On Fri, 8 Sept 2023 at 18:39, Cosmin Stejerean via ffmpeg-devel < ffmpeg-devel@ffmpeg.org> wrote: > > > > On Sep 8, 2023, at 6:09 AM, Michael Niedermayer > wrote: > > > > modern video encoders where no longer added to ffmpeg > > Writing a good modern video encoder is a massive undertaking, and i think > it's likely that encoders are going to be mostly integrated via libraries. > I agree the speed of iteration needed in developing a modern video encoder does not lend itself to 1) the FFmpeg development process on a mailing list and 2) rapid iteration whilst fitting into FFmpeg libs (e.g threading) I will deliberately avoid commenting on the other points. 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 7/7] avcodec/truemotion2: Don't check before freeing VLC
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] VDD conference invitation - Dublin 22-24 Sept 2023
On Fri, Sep 08, 2023 at 12:19:45PM -0300, James Almer wrote: > On 9/8/2023 10:09 AM, Michael Niedermayer wrote: > > There has been a marked shift of project goals over the years. While long > > ago FFmpeg > > was "all of multimedia". With time the scope of the project has shrunk. > > FFserver was removed not improved, not replaced. > > the video encoder core we had, which encoded from mpeg1 to mpeg4, msmpeg*, > > rv* and others > > and at the time was the best encoder available (not anymore now, no) but > > after mpeg4-asp, > > modern video encoders where no longer added to ffmpeg. In one case a > > advanced encoder for a fringe > > format was rejected > > Which encoder was this? I would have said it, if i remembered it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates 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 v2 1/2] configure: don't force specific C++ standard library linking
On Fri, 8 Sept 2023 at 00:11, Kieran Kunhya wrote: > > On Thu, 7 Sept 2023 at 22:39, Kacper Michajlow wrote: > > > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis > > wrote: > > > > > > On 9/6/2023 6:31 PM, Kacper Michajlow wrote: > > > > What would be a downside of preferring CXX always if it exists? > > > > > > FFmpeg runs in a multitude of environments with a multitude of > > portability > > > requirements. Needlessly linking a C++ runtime is not OK. > > > > This does not answer my question. Let me rephrase. Do we know the case > > where using C++ compiler driver rather than C would degrade the > > quality of the resulting build? > > > > The machine that ffmpeg is being compiled on is not necessarily the one > that ffmpeg is going to be run on. Not sure how this is relevant to the discussion? - Kacper ___ 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] configure: don't force specific C++ standard library linking
On Fri, 8 Sept 2023 at 19:42, Kacper Michajlow wrote: > On Fri, 8 Sept 2023 at 00:11, Kieran Kunhya wrote: > > > > On Thu, 7 Sept 2023 at 22:39, Kacper Michajlow > wrote: > > > > > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis > > > wrote: > > > > > > > > On 9/6/2023 6:31 PM, Kacper Michajlow wrote: > > > > > What would be a downside of preferring CXX always if it exists? > > > > > > > > FFmpeg runs in a multitude of environments with a multitude of > > > portability > > > > requirements. Needlessly linking a C++ runtime is not OK. > > > > > > This does not answer my question. Let me rephrase. Do we know the case > > > where using C++ compiler driver rather than C would degrade the > > > quality of the resulting build? > > > > > > > The machine that ffmpeg is being compiled on is not necessarily the one > > that ffmpeg is going to be run on. > > Not sure how this is relevant to the discussion? > > > > > What would be a downside of preferring CXX always if it exists? Because it forces a dependency on libstdc++ even if another machine does not have it. 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 v2 1/2] configure: don't force specific C++ standard library linking
On Fri, 8 Sept 2023 at 01:35, Timo Rothenpieler via ffmpeg-devel wrote: > > On 07.09.2023 23:38, Kacper Michajlow wrote: > > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis > > wrote: > >> > >> On 9/6/2023 6:31 PM, Kacper Michajlow wrote: > >>> What would be a downside of preferring CXX always if it exists? > >> > >> FFmpeg runs in a multitude of environments with a multitude of portability > >> requirements. Needlessly linking a C++ runtime is not OK. > > > > This does not answer my question. Let me rephrase. Do we know the case > > where using C++ compiler driver rather than C would degrade the > > quality of the resulting build? > > > > Using C++ driver would indeed append the (correct) runtime library to > > the linker command, but if nothing references any symbols from it it > > would not be linked. It is also why the current way of forcing > > `lstdc++` kinda works, because it is silently ignored when not needed. > > > > Implementing logic to use C++ only when necessary is possible, but I'm > > not a big fan of such automation. And in practice not sure how well it > > would work, because it would require trying to link twice every > > dependency in configure. > > > > Also the fact that "FFmpeg runs in a multitude of environment" is > > precisely why I really don't like the current unconditional including > > `-lstdc++`. > > Couldn't you just check if stdc++ is in the ldflags/extralibs, and if > so, remove it, and use g++ to link? Well, I'm lost now. Are you suggesting building on top of existing hacks is a better solution than the proposed patch? I refuse supporting any kind of random `-lstdc++` adding in configure and then removing it in the end. - Kacper ___ 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] configure: don't force specific C++ standard library linking
On 08.09.2023 20:55, Kacper Michajlow wrote: On Fri, 8 Sept 2023 at 01:35, Timo Rothenpieler via ffmpeg-devel wrote: On 07.09.2023 23:38, Kacper Michajlow wrote: On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis wrote: On 9/6/2023 6:31 PM, Kacper Michajlow wrote: What would be a downside of preferring CXX always if it exists? FFmpeg runs in a multitude of environments with a multitude of portability requirements. Needlessly linking a C++ runtime is not OK. This does not answer my question. Let me rephrase. Do we know the case where using C++ compiler driver rather than C would degrade the quality of the resulting build? Using C++ driver would indeed append the (correct) runtime library to the linker command, but if nothing references any symbols from it it would not be linked. It is also why the current way of forcing `lstdc++` kinda works, because it is silently ignored when not needed. Implementing logic to use C++ only when necessary is possible, but I'm not a big fan of such automation. And in practice not sure how well it would work, because it would require trying to link twice every dependency in configure. Also the fact that "FFmpeg runs in a multitude of environment" is precisely why I really don't like the current unconditional including `-lstdc++`. Couldn't you just check if stdc++ is in the ldflags/extralibs, and if so, remove it, and use g++ to link? Well, I'm lost now. Are you suggesting building on top of existing hacks is a better solution than the proposed patch? The proposed patch looks like a near unmaintainable hack to me as it is. Anything that's less brittle is highly preferred. There is no good solution here, but I'm very much against any solution that has high potential for random breakages and hard to predict side-effects. I refuse supporting any kind of random `-lstdc++` adding in configure and then removing it in the end. - Kacper ___ 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] configure: don't force specific C++ standard library linking
On Fri, 8 Sept 2023 at 20:46, Kieran Kunhya wrote: > > On Fri, 8 Sept 2023 at 19:42, Kacper Michajlow wrote: > > > On Fri, 8 Sept 2023 at 00:11, Kieran Kunhya wrote: > > > > > > On Thu, 7 Sept 2023 at 22:39, Kacper Michajlow > > wrote: > > > > > > > On Thu, 7 Sept 2023 at 15:12, Derek Buitenhuis > > > > wrote: > > > > > > > > > > On 9/6/2023 6:31 PM, Kacper Michajlow wrote: > > > > > > What would be a downside of preferring CXX always if it exists? > > > > > > > > > > FFmpeg runs in a multitude of environments with a multitude of > > > > portability > > > > > requirements. Needlessly linking a C++ runtime is not OK. > > > > > > > > This does not answer my question. Let me rephrase. Do we know the case > > > > where using C++ compiler driver rather than C would degrade the > > > > quality of the resulting build? > > > > > > > > > > The machine that ffmpeg is being compiled on is not necessarily the one > > > that ffmpeg is going to be run on. > > > > Not sure how this is relevant to the discussion? > > > > > > > > What would be a downside of preferring CXX always if it exists? > > Because it forces a dependency on libstdc++ even if another machine does > not have it. On all "affected" platforms, configure already adds -Wl,--as-needed, so the resulting library has exactly the same dependencies. Unless something references symbols from stdlib, but then it would just not link with clang anyway. ~ clang++ m.o -Wl,--as-needed && ldd a.out linux-vdso.so.1 (0x7ffeeb912000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f64050a7000) /lib64/ld-linux-x86-64.so.2 (0x7f64052ad000) ~ clang m.o -Wl,--as-needed && ldd a.out linux-vdso.so.1 (0x7ffe1fb36000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f5e7a3c2000) /lib64/ld-linux-x86-64.so.2 (0x7f5e7a5c8000) - Kacper ___ 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 01/21] avformat/avio: Don't use incompatible function pointer type for call
On Thu, 7 Sep 2023, Andreas Rheinhardt wrote:
It is undefined behaviour even in cases where it works
(it works because it is only a const uint8_t* vs. uint8_t* difference).
Signed-off-by: Andreas Rheinhardt
---
libavformat/avio.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/libavformat/avio.c b/libavformat/avio.c
index ab1c19a58d..d53da5cb0c 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -354,10 +354,15 @@ fail:
}
static inline int retry_transfer_wrapper(URLContext *h, uint8_t *buf,
+ const uint8_t *cbuf,
int size, int size_min,
- int (*transfer_func)(URLContext *h,
- uint8_t *buf,
- int size))
+ int (*read_func)(URLContext *h,
+ uint8_t *buf,
+ int size),
+ int (*write_func)(URLContext *h,
+ const uint8_t *buf,
+ int size),
+ int read)
These extra parameters are very ugly, can't we think of another way to
properly support this?
One idea is putting retry_transfer_wrapper in a template file and include
it twice with proper defines-s for the read and write flavours.
Regards,
Marton
{
int ret, len;
int fast_retries = 5;
@@ -367,7 +372,8 @@ static inline int retry_transfer_wrapper(URLContext *h,
uint8_t *buf,
while (len < size_min) {
if (ff_check_interrupt(&h->interrupt_callback))
return AVERROR_EXIT;
-ret = transfer_func(h, buf + len, size - len);
+ret = read ? read_func (h, buf + len, size - len)
+ : write_func(h, cbuf + len, size - len);
if (ret == AVERROR(EINTR))
continue;
if (h->flags & AVIO_FLAG_NONBLOCK)
@@ -402,14 +408,16 @@ int ffurl_read(URLContext *h, unsigned char *buf, int
size)
{
if (!(h->flags & AVIO_FLAG_READ))
return AVERROR(EIO);
-return retry_transfer_wrapper(h, buf, size, 1, h->prot->url_read);
+return retry_transfer_wrapper(h, buf, NULL, size, 1,
+ h->prot->url_read, NULL, 1);
}
int ffurl_read_complete(URLContext *h, unsigned char *buf, int size)
{
if (!(h->flags & AVIO_FLAG_READ))
return AVERROR(EIO);
-return retry_transfer_wrapper(h, buf, size, size, h->prot->url_read);
+return retry_transfer_wrapper(h, buf, NULL, size, size,
+ h->prot->url_read, NULL, 1);
}
int ffurl_write(URLContext *h, const unsigned char *buf, int size)
@@ -420,9 +428,8 @@ int ffurl_write(URLContext *h, const unsigned char *buf,
int size)
if (h->max_packet_size && size > h->max_packet_size)
return AVERROR(EIO);
-return retry_transfer_wrapper(h, (unsigned char *)buf, size, size,
- (int (*)(struct URLContext *, uint8_t *,
int))
- h->prot->url_write);
+return retry_transfer_wrapper(h, NULL, buf, size, size,
+ NULL, h->prot->url_write, 0);
}
int64_t ffurl_seek(URLContext *h, int64_t pos, int whence)
--
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".
___
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/7] proresdec2: port and fix for cached reader
On Fri, Sep 08, 2023 at 10:15:02AM +0200, Christophe Gisquet wrote: > Summary of changes > - move back to regular, non-macro, get_bits API > - reduce the lookup to switch the coding method > - shorter reads wherever possible, in particular for the end of bitstream > (16 bits instead of 32, as per the above) > > There are cases that really need longer lengths (larger EG codes) of up > to 27 bits. > > Win64: 6.10 -> 4.87 (~20% speedup) > > Reference for an hypothetical 32bits version of the cached reader: > Win32: 11.4 -> 9.8 (14%, because iDCT is not SIMDed) > --- > libavcodec/proresdec2.c | 53 ++--- > 1 file changed, 23 insertions(+), 30 deletions(-) causes assertion failure: Assertion n <= 32 failed at libavcodec/bitstream_template.h:338/0 Thread 36 "read_thread" received signal SIGABRT, Aborted. [Switching to Thread 0x7fff56ffd700 (LWP 12751)] __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x7fffefd097f1 in __GI_abort () at abort.c:79 #2 0x56035277 in bits_peek_be (bc=0x7fff56ffb270, n=4294967295) at libavcodec/bitstream_template.h:338 #3 0x56036b35 in decode_ac_coeffs (avctx=0x7fff28002680, gb=0x7fff56ffb270, out=0x7fff56ffb2a0, blocks_per_slice=32) at libavcodec/proresdec2.c:590 #4 0x5603715c in decode_slice_chroma (avctx=0x7fff28002680, slice=0x7fff28055c20, dst=0x7fff9450b940, dst_stride=7680, buf=0x7fff2803d072 "#\a`\002g\240", , buf_size=43, qmat=0x7fff56ffc450, log2_blocks_per_mb=2) at libavcodec/proresdec2.c:674 #5 0x56037ae2 in decode_slice_thread (avctx=0x7fff28002680, arg=0x0, jobnr=145, threadnr=0) at libavcodec/proresdec2.c:807 #6 0x55c815a0 in avcodec_default_execute2 (c=0x7fff28002680, func=0x56037465 , arg=0x0, ret=0x0, count=510) at libavcodec/avcodec.c:74 #7 0x56037d1e in decode_picture (avctx=0x7fff28002680) at libavcodec/proresdec2.c:846 #8 0x56037fda in decode_frame (avctx=0x7fff28002680, frame=0x7fff28007440, got_frame=0x7fff56ffc5f0, avpkt=0x7fff28007dc0) at libavcodec/proresdec2.c:912 #9 0x55d732ec in decode_simple_internal (avctx=0x7fff28002680, frame=0x7fff28007440, discarded_samples=0x7fff56ffc650) at libavcodec/decode.c:433 #10 0x55d73843 in decode_simple_receive_frame (avctx=0x7fff28002680, frame=0x7fff28007440) at libavcodec/decode.c:607 #11 0x55d739b3 in decode_receive_frame_internal (avctx=0x7fff28002680, frame=0x7fff28007440) at libavcodec/decode.c:635 #12 0x55d73d78 in avcodec_send_packet (avctx=0x7fff28002680, avpkt=0x7fff28007208) at libavcodec/decode.c:732 #13 0x55a6ef78 in try_decode_frame (s=0x7fff28000c80, st=0x7fff28002240, pkt=0x7fff28007208, options=0x7fff280071c0) at libavformat/demux.c:2075 #14 0x55a71d92 in avformat_find_stream_info (ic=0x7fff28000c80, options=0x7fff280071c0) at libavformat/demux.c:2771 #15 0x55699823 in read_thread (arg=0x7fffd45ca040) at fftools/ffplay.c:2806 #16 0x75deed6c in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 #17 0x75e640f9 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 #18 0x700c16db in start_thread (arg=0x7fff56ffd700) at pthread_create.c:463 #19 0x7fffefdea61f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership. - Colin Powell 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 01/21] avformat/avio: Don't use incompatible function pointer type for call
tor 2023-09-07 klockan 02:23 +0200 skrev Andreas Rheinhardt: > It is undefined behaviour even in cases where it works > (it works because it is only a const uint8_t* vs. uint8_t* > difference). > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/avio.c | 25 - > 1 file changed, 16 insertions(+), 9 deletions(-) Looks OK. It's probably possible to get around the need for cbuf by casting to/from uintptr_t, but using cbuf is more type safe /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/21] avformat/avio: Don't use incompatible function pointer type for call
fre 2023-09-08 klockan 22:38 +0200 skrev Marton Balint: > > > On Thu, 7 Sep 2023, Andreas Rheinhardt wrote: > > > It is undefined behaviour even in cases where it works > > (it works because it is only a const uint8_t* vs. uint8_t* > > difference). > > > > Signed-off-by: Andreas Rheinhardt > > --- > > libavformat/avio.c | 25 - > > 1 file changed, 16 insertions(+), 9 deletions(-) > > > > diff --git a/libavformat/avio.c b/libavformat/avio.c > > index ab1c19a58d..d53da5cb0c 100644 > > --- a/libavformat/avio.c > > +++ b/libavformat/avio.c > > @@ -354,10 +354,15 @@ fail: > > } > > > > static inline int retry_transfer_wrapper(URLContext *h, uint8_t > > *buf, > > + const uint8_t *cbuf, > > int size, int size_min, > > - int > > (*transfer_func)(URLContext *h, > > - > > uint8_t *buf, > > - int > > size)) > > + int > > (*read_func)(URLContext *h, > > + uint8_t > > *buf, > > + int > > size), > > + int > > (*write_func)(URLContext *h, > > + const > > uint8_t *buf, > > + int > > size), > > + int read) > > These extra parameters are very ugly, can't we think of another way > to > properly support this? > > One idea is putting retry_transfer_wrapper in a template file and > include > it twice with proper defines-s for the read and write flavours. Seems like a lot of work for a function that's internal to avio.c /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 02/21] avformat/internal: Avoid casting const away
tor 2023-09-07 klockan 02:32 +0200 skrev Andreas Rheinhardt: > Fixes many warnings when using -Wcast-qual. > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/internal.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Looks fine /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 03/21] avformat/aviobuf: Don't use incompatible function pointer type for call
tor 2023-09-07 klockan 02:32 +0200 skrev Andreas Rheinhardt: > It is undefined behaviour even in cases where it works > (it works because both are pointers). Instead change > the functions involved to use the type expected by the AVIO-API > and add inline wrappers for our internal callers. > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/avio.c | 15 +++ > libavformat/aviobuf.c | 6 ++ > libavformat/url.h | 20 > 3 files changed, 29 insertions(+), 12 deletions(-) Should be OK. No version bump necessary since it's an internal API, right? And only within lavf as well /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
