[FFmpeg-devel] [PATCH] avcodec/hevcdsp: Offset ff_hevc_.pel_filters to simplify addressing

2024-02-11 Thread Andreas Rheinhardt
Besides simplifying address computations (it saves 432B of .text
in hevcdsp.o alone here) it also fixes undefined behaviour that
occurs if mx or my are 0 (happens when the filters are unused)
because they lead to an array index of -1 in the old code.
This happens in the checkasm-hevc_pel FATE-test.

Signed-off-by: Andreas Rheinhardt 
---
The loongarch and mips parts of this are untested. Luckily we have a
loongarch patchwork runner...

 libavcodec/hevcdsp.c|   6 +-
 libavcodec/hevcdsp.h|   5 +-
 libavcodec/hevcdsp_template.c   |  38 ++--
 libavcodec/loongarch/hevc_mc.S  | 224 +---
 libavcodec/loongarch/hevc_mc_bi_lsx.c   |   6 +-
 libavcodec/loongarch/hevc_mc_uni_lsx.c  |   6 +-
 libavcodec/loongarch/hevc_mc_uniw_lsx.c |   4 +-
 libavcodec/loongarch/hevcdsp_lsx.c  |   6 +-
 libavcodec/mips/hevc_mc_bi_msa.c|   6 +-
 libavcodec/mips/hevc_mc_biw_msa.c   |   6 +-
 libavcodec/mips/hevc_mc_uni_msa.c   |   6 +-
 libavcodec/mips/hevc_mc_uniw_msa.c  |   6 +-
 libavcodec/mips/hevcdsp_mmi.c   |  20 +--
 libavcodec/mips/hevcdsp_msa.c   |   6 +-
 libavcodec/x86/hevcdsp_init.c   |   4 +-
 15 files changed, 112 insertions(+), 237 deletions(-)

diff --git a/libavcodec/hevcdsp.c b/libavcodec/hevcdsp.c
index 2ca551df1d..630fdc012e 100644
--- a/libavcodec/hevcdsp.c
+++ b/libavcodec/hevcdsp.c
@@ -91,7 +91,8 @@ static const int8_t transform[32][32] = {
   90, -90,  88, -85,  82, -78,  73, -67,  61, -54,  46, -38,  31, -22,  
13,  -4 },
 };
 
-DECLARE_ALIGNED(16, const int8_t, ff_hevc_epel_filters)[7][4] = {
+DECLARE_ALIGNED(16, const int8_t, ff_hevc_epel_filters)[8][4] = {
+{  0 },
 { -2, 58, 10, -2},
 { -4, 54, 16, -2},
 { -6, 46, 28, -4},
@@ -101,7 +102,8 @@ DECLARE_ALIGNED(16, const int8_t, 
ff_hevc_epel_filters)[7][4] = {
 { -2, 10, 58, -2},
 };
 
-DECLARE_ALIGNED(16, const int8_t, ff_hevc_qpel_filters)[3][16] = {
+DECLARE_ALIGNED(16, const int8_t, ff_hevc_qpel_filters)[4][16] = {
+{ 0 },
 { -1,  4,-10, 58, 17, -5,  1,  0, -1,  4,-10, 58, 17, -5,  1,  0},
 { -1,  4,-11, 40, 40,-11,  4, -1, -1,  4,-11, 40, 40,-11,  4, -1},
 {  0,  1, -5, 17, 58,-10,  4, -1,  0,  1, -5, 17, 58,-10,  4, -1}
diff --git a/libavcodec/hevcdsp.h b/libavcodec/hevcdsp.h
index 1b9c5bb6bc..a5933dcac4 100644
--- a/libavcodec/hevcdsp.h
+++ b/libavcodec/hevcdsp.h
@@ -126,8 +126,9 @@ typedef struct HEVCDSPContext {
 
 void ff_hevc_dsp_init(HEVCDSPContext *hpc, int bit_depth);
 
-extern const int8_t ff_hevc_epel_filters[7][4];
-extern const int8_t ff_hevc_qpel_filters[3][16];
+/** ff_hevc_.pel_filters[0] are dummies to simplify array addressing */
+extern const int8_t ff_hevc_epel_filters[8][4];
+extern const int8_t ff_hevc_qpel_filters[4][16];
 
 void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c, const int bit_depth);
 void ff_hevc_dsp_init_arm(HEVCDSPContext *c, const int bit_depth);
diff --git a/libavcodec/hevcdsp_template.c b/libavcodec/hevcdsp_template.c
index 9b48bdf08e..121c44c401 100644
--- a/libavcodec/hevcdsp_template.c
+++ b/libavcodec/hevcdsp_template.c
@@ -301,9 +301,9 @@ IDCT_DC(32)
 //
 

 #define ff_hevc_pel_filters ff_hevc_qpel_filters
-#define DECL_HV_FILTER(f)  \
-const uint8_t *hf = ff_hevc_ ## f ## _filters[mx - 1]; \
-const uint8_t *vf = ff_hevc_ ## f ## _filters[my - 1];
+#define DECL_HV_FILTER(f)  \
+const uint8_t *hf = ff_hevc_ ## f ## _filters[mx]; \
+const uint8_t *vf = ff_hevc_ ## f ## _filters[my];
 
 #define FW_PUT(p, f, t)
   \
 static void FUNC(put_hevc_## f)(int16_t *dst, const uint8_t *src, ptrdiff_t 
srcstride, int height,\
@@ -421,7 +421,7 @@ static void FUNC(put_hevc_qpel_bi_h)(uint8_t *_dst, 
ptrdiff_t _dststride, const
 pixel *dst  = (pixel *)_dst;
 ptrdiff_t dststride = _dststride / sizeof(pixel);
 
-const int8_t *filter= ff_hevc_qpel_filters[mx - 1];
+const int8_t *filter= ff_hevc_qpel_filters[mx];
 
 int shift = 14  + 1 - BIT_DEPTH;
 #if BIT_DEPTH < 14
@@ -449,7 +449,7 @@ static void FUNC(put_hevc_qpel_bi_v)(uint8_t *_dst, 
ptrdiff_t _dststride,
 pixel *dst  = (pixel *)_dst;
 ptrdiff_t dststride = _dststride / sizeof(pixel);
 
-const int8_t *filter= ff_hevc_qpel_filters[my - 1];
+const int8_t *filter= ff_hevc_qpel_filters[my];
 
 int shift = 14 + 1 - BIT_DEPTH;
 #if BIT_DEPTH < 14
@@ -487,7 +487,7 @@ static void FUNC(put_hevc_qpel_bi_hv)(uint8_t *_dst, 
ptrdiff_t _dststride,
 #endif
 
 src   -= QPEL_EXTRA_BEFORE * srcstride;
-filter = ff_hevc_qpel_filters[mx - 1];
+filter = ff_hevc_qpel_filters[mx];
 for (y = 0; y < height + QPEL_EXTRA; y++) {
 for (x = 0; x < width; x++)
 tmp[x] = QPEL_FILTER(src, 1) >> (BIT_D

Re: [FFmpeg-devel] [PATCH] avcodec/hevcdec: fix out of bounds index -1 for inter prediction

2024-02-11 Thread Andreas Rheinhardt
Nuo Mi:
> It's a false positive. We use -1 to index an array, but it's not actually 
> used.
> This patch will make the "GCC UndefinedBehaviorSanitizer" happy.
> 
> Found by: checkasm-hevc_pel in 
> https://fate.ffmpeg.org/report.cgi?time=20240211011905&slot=x86_64-archlinux-gcc-ubsan
> Reported-by: James Almer 
> ---
>  libavcodec/hevcdsp_template.c | 6 +++---
>  libavcodec/x86/hevcdsp_init.c | 6 +++---
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/libavcodec/hevcdsp_template.c b/libavcodec/hevcdsp_template.c
> index 9b48bdf08e..a4b8901e5d 100644
> --- a/libavcodec/hevcdsp_template.c
> +++ b/libavcodec/hevcdsp_template.c
> @@ -301,9 +301,9 @@ IDCT_DC(32)
>  //
>  
> 
>  #define ff_hevc_pel_filters ff_hevc_qpel_filters
> -#define DECL_HV_FILTER(f)  \
> -const uint8_t *hf = ff_hevc_ ## f ## _filters[mx - 1]; \
> -const uint8_t *vf = ff_hevc_ ## f ## _filters[my - 1];
> +#define DECL_HV_FILTER(f)   \
> +const uint8_t *hf = mx ? ff_hevc_ ## f ## _filters[mx - 1] : NULL;  \
> +const uint8_t *vf = my ? ff_hevc_ ## f ## _filters[my - 1] : NULL;
>  
>  #define FW_PUT(p, f, t)  
>  \
>  static void FUNC(put_hevc_## f)(int16_t *dst, const uint8_t *src, ptrdiff_t 
> srcstride, int height,\
> diff --git a/libavcodec/x86/hevcdsp_init.c b/libavcodec/x86/hevcdsp_init.c
> index 31e81eb11f..e0f65177c4 100644
> --- a/libavcodec/x86/hevcdsp_init.c
> +++ b/libavcodec/x86/hevcdsp_init.c
> @@ -87,9 +87,9 @@ IDCT_FUNCS(avx)
>  
>  
>  #define ff_hevc_pel_filters ff_hevc_qpel_filters
> -#define DECL_HV_FILTER(f)  \
> -const uint8_t *hf = ff_hevc_ ## f ## _filters[mx - 1]; \
> -const uint8_t *vf = ff_hevc_ ## f ## _filters[my - 1];
> +#define DECL_HV_FILTER(f)   \
> +const uint8_t *hf = mx ? ff_hevc_ ## f ## _filters[mx - 1] : NULL;  \
> +const uint8_t *vf = my ? ff_hevc_ ## f ## _filters[my - 1] : NULL;  \

Spurious addition of trailing '\'.

>  
>  #define FW_PUT(p, a, b, depth, opt) \
>  void ff_hevc_put_hevc_ ## a ## _ ## depth ## _##opt(int16_t *dst, const 
> uint8_t *src, ptrdiff_t srcstride,   \

I have just sent an alternative solution for this that avoids all these
branches (which the compiler will not be able to eliminate).
Unfortunately I can't test mips and loongarch myself; there is a
fate-runner for the latter, but nothing for the former. So hopefully
someone can test mips.

- Andreas

PS: The aarch64 code (hevcdsp_[eq]pel_neon.S) already offsets its
filters via dummy arrays. I wonder whether it could now reuse the
ordinary ones.

___
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 3/3] lavc/dxv: remove ctx fields that can be derived from texdsp ctxs

2024-02-11 Thread Andreas Rheinhardt
Connor Worley:
> Signed-off-by: Connor Worley 
> ---
>  libavcodec/dxv.c | 53 
>  1 file changed, 9 insertions(+), 44 deletions(-)
> 
> diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
> index cd78de3e0d..82c493f1de 100644
> --- a/libavcodec/dxv.c
> +++ b/libavcodec/dxv.c
> @@ -39,20 +39,12 @@ typedef struct DXVContext {
>  
>  uint8_t *tex_data;   // Compressed texture
>  uint8_t *ctex_data;  // Compressed chroma texture
> -int tex_rat; // Compression ratio
> -int tex_step;// Distance between blocks
> -int ctex_step;   // Distance between blocks
> +
>  int64_t tex_size;// Texture size
>  int64_t ctex_size;   // Chroma texture size
>  
>  uint8_t *op_data[4]; // Opcodes
>  int64_t op_size[4];  // Opcodes size
> -
> -int texture_block_w;
> -int texture_block_h;
> -
> -int ctexture_block_w;
> -int ctexture_block_h;
>  } DXVContext;
>  
>  /* This scheme addresses already decoded elements depending on 2-bit status:
> @@ -865,9 +857,6 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame 
> *frame,
>  cavctx.coded_height = avctx->coded_height / 2;
>  cavctx.coded_width  = avctx->coded_width  / 2;
>  
> -ctx->texture_block_h = 4;
> -ctx->texture_block_w = 4;
> -
>  avctx->pix_fmt = AV_PIX_FMT_RGBA;
>  avctx->colorspace = AVCOL_SPC_RGB;
>  
> @@ -878,8 +867,6 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame 
> *frame,
>  texdsp_ctx.tex_funct = ctx->texdsp.dxt1_block;
>  texdsp_ctx.tex_ratio = 8;
>  texdsp_ctx.raw_ratio = 16;
> -ctx->tex_rat   = 8;
> -ctx->tex_step  = 8;
>  msgcomp = "DXTR1";
>  msgtext = "DXT1";
>  break;
> @@ -889,8 +876,6 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame 
> *frame,
>  texdsp_ctx.tex_funct = ctx->texdsp.dxt4_block;
>  texdsp_ctx.tex_ratio = 16;
>  texdsp_ctx.raw_ratio = 16;
> -ctx->tex_rat   = 4;
> -ctx->tex_step  = 16;
>  msgcomp = "DXTR5";
>  msgtext = "DXT5";
>  break;
> @@ -902,16 +887,8 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame 
> *frame,
>  ctexdsp_ctx.tex_funct = ctx->texdsp.rgtc1u_gray_block;
>  ctexdsp_ctx.tex_ratio = 16;
>  ctexdsp_ctx.raw_ratio = 4;
> -ctx->tex_rat   = 8;
> -ctx->tex_step  = 32;
> -ctx->ctex_step = 16;
>  msgcomp = "YOCOCG6";
>  msgtext = "YCG6";
> -ctx->ctex_size = avctx->coded_width * avctx->coded_height / 4;
> -ctx->texture_block_h = 4;
> -ctx->texture_block_w = 16;
> -ctx->ctexture_block_h = 4;
> -ctx->ctexture_block_w = 4;
>  avctx->pix_fmt = AV_PIX_FMT_YUV420P;
>  avctx->colorspace = AVCOL_SPC_YCOCG;
>  break;
> @@ -923,16 +900,8 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame 
> *frame,
>  ctexdsp_ctx.tex_funct = ctx->texdsp.rgtc1u_gray_block;
>  ctexdsp_ctx.tex_ratio = 16;
>  ctexdsp_ctx.raw_ratio = 4;
> -ctx->tex_rat   = 4;
> -ctx->tex_step  = 64;
> -ctx->ctex_step = 16;
>  msgcomp = "YAOCOCG10";
>  msgtext = "YG10";
> -ctx->ctex_size = avctx->coded_width * avctx->coded_height / 4;
> -ctx->texture_block_h = 4;
> -ctx->texture_block_w = 16;
> -ctx->ctexture_block_h = 4;
> -ctx->ctexture_block_w = 4;
>  avctx->pix_fmt = AV_PIX_FMT_YUVA420P;
>  avctx->colorspace = AVCOL_SPC_YCOCG;
>  break;
> @@ -957,7 +926,6 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame 
> *frame,
>  texdsp_ctx.tex_funct = ctx->texdsp.dxt5_block;
>  texdsp_ctx.tex_ratio = 16;
>  texdsp_ctx.raw_ratio = 16;
> -ctx->tex_step  = 16;
>  } else if (old_type & 0x20 || version_major == 1) {
>  tag = DXV_FMT_DXT1;
>  msgtext = "DXT1";
> @@ -965,12 +933,10 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame 
> *frame,
>  texdsp_ctx.tex_funct = ctx->texdsp.dxt1_block;
>  texdsp_ctx.tex_ratio = 8;
>  texdsp_ctx.raw_ratio = 16;
> -ctx->tex_step  = 8;
>  } else {
>  av_log(avctx, AV_LOG_ERROR, "Unsupported header 
> (0x%08"PRIX32")\n.", tag);
>  return AVERROR_INVALIDDATA;
>  }
> -ctx->tex_rat = 1;
>  break;
>  }
>  
> @@ -986,7 +952,6 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame 
> *frame,
>  /* Encoder copies texture data when compression is not advantageous. 
> */
>  if (bytestream2_get_byte(gbc)) {
>  msgcomp = "RAW";
> -ctx->tex_rat = 1;
>  decompress_tex = dxv_decompress_raw;
>  }
>  
> @@ -1004,14 +969,20 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame 
> *frame,
>  return AVERROR_INVALIDDATA;
>  }
>  
> -ctx->tex_size = avctx->coded_

[FFmpeg-devel] [PATCH] avformat/avformat: Remove reference to removed setter

2024-02-11 Thread Andreas Rheinhardt
Removed in 704017d91ec8fbade0de072d222018c1a6013b70.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/avformat.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 5d0fe82250..1e98970b89 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1688,7 +1688,7 @@ typedef struct AVFormatContext {
 /**
  * Number of bytes to be written as padding in a metadata header.
  * Demuxing: Unused.
- * Muxing: Set by user via av_format_set_metadata_header_padding.
+ * Muxing: Set by user.
  */
 int metadata_header_padding;
 
-- 
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] lavc/libopenh264: Check for noopenh264

2024-02-11 Thread Andreas Rheinhardt
Akihiko Odaki:
> noopenh264 is a "fake implementation of the OpenH264 library we can link
> from regardless of the actual library being available":
> https://gitlab.com/freedesktop-sdk/noopenh264
> 
> A distributor may wish to link against openh264/noopenh264 and let
> the decoder and encoder work only if the actual library is available.
> 
> On the other hand, an application may want to know if the decoder or
> encoder is available beforehand so that it can determine what format to
> download for decoding, or what format to advertise for the peer
> receiving the encoded video.
> 
> Check the availability of the actual library at runtime initialization
> and do not expose the encoder and decoder if they are not available.
> 
> Signed-off-by: Akihiko Odaki 
> ---
>  libavcodec/codec_internal.h |  2 ++
>  libavcodec/libopenh264dec.c | 36 +++
>  libavcodec/libopenh264enc.c | 46 
> -
>  libavcodec/tests/avcodec.c  |  2 ++
>  4 files changed, 57 insertions(+), 29 deletions(-)
> 
> diff --git a/libavcodec/codec_internal.h b/libavcodec/codec_internal.h
> index 130a7dc3cd..635af644fa 100644
> --- a/libavcodec/codec_internal.h
> +++ b/libavcodec/codec_internal.h
> @@ -122,6 +122,8 @@ enum FFCodecType {
>  /* The codec is an encoder using the receive_packet callback;
>   * audio and video codecs only. */
>  FF_CODEC_CB_TYPE_RECEIVE_PACKET,
> +/* The codec is not available. */
> +FF_CODEC_CB_TYPE_NONE,
>  };
>  
>  typedef struct FFCodec {
> diff --git a/libavcodec/libopenh264dec.c b/libavcodec/libopenh264dec.c
> index b6a9bba2dc..f5544142aa 100644
> --- a/libavcodec/libopenh264dec.c
> +++ b/libavcodec/libopenh264dec.c
> @@ -48,6 +48,17 @@ static av_cold int svc_decode_close(AVCodecContext *avctx)
>  return 0;
>  }
>  
> +static av_cold void svc_decode_init_static_data(FFCodec *codec)
> +{
> +ISVCDecoder *decoder;
> +
> +if (WelsCreateDecoder(&decoder)) {
> +codec->cb_type = FF_CODEC_CB_TYPE_NONE;
> +} else {
> +WelsDestroyDecoder(decoder);
> +}
> +}
> +
>  static av_cold int svc_decode_init(AVCodecContext *avctx)
>  {
>  SVCContext *s = avctx->priv_data;
> @@ -153,18 +164,19 @@ static int svc_decode_frame(AVCodecContext *avctx, 
> AVFrame *avframe,
>  return avpkt->size;
>  }
>  
> -const FFCodec ff_libopenh264_decoder = {
> -.p.name = "libopenh264",
> +FFCodec ff_libopenh264_decoder = {
> +.p.name   = "libopenh264",
>  CODEC_LONG_NAME("OpenH264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10"),
> -.p.type = AVMEDIA_TYPE_VIDEO,
> -.p.id   = AV_CODEC_ID_H264,
> -.priv_data_size = sizeof(SVCContext),
> -.init   = svc_decode_init,
> +.p.type   = AVMEDIA_TYPE_VIDEO,
> +.p.id = AV_CODEC_ID_H264,
> +.priv_data_size   = sizeof(SVCContext),
> +.init_static_data = svc_decode_init_static_data,
> +.init = svc_decode_init,
>  FF_CODEC_DECODE_CB(svc_decode_frame),
> -.close  = svc_decode_close,
> -.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_DR1,
> -.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS |
> -  FF_CODEC_CAP_INIT_CLEANUP,
> -.bsfs   = "h264_mp4toannexb",
> -.p.wrapper_name = "libopenh264",
> +.close= svc_decode_close,
> +.p.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_DR1,
> +.caps_internal= FF_CODEC_CAP_SETS_PKT_DTS |
> +FF_CODEC_CAP_INIT_CLEANUP,
> +.bsfs = "h264_mp4toannexb",
> +.p.wrapper_name   = "libopenh264",
>  };
> diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
> index 6f231d22b2..1963f2cf5c 100644
> --- a/libavcodec/libopenh264enc.c
> +++ b/libavcodec/libopenh264enc.c
> @@ -106,6 +106,17 @@ static av_cold int svc_encode_close(AVCodecContext 
> *avctx)
>  return 0;
>  }
>  
> +static av_cold void svc_encode_init_static_data(FFCodec *codec)
> +{
> +ISVCEncoder *encoder;
> +
> +if (WelsCreateSVCEncoder(&encoder)) {
> +codec->cb_type = FF_CODEC_CB_TYPE_NONE;
> +} else {
> +WelsDestroySVCEncoder(encoder);
> +}
> +}
> +
>  static av_cold int svc_encode_init(AVCodecContext *avctx)
>  {
>  SVCContext *s = avctx->priv_data;
> @@ -429,23 +440,24 @@ static const FFCodecDefault svc_enc_defaults[] = {
>  { NULL },
>  };
>  
> -const FFCodec ff_libopenh264_encoder = {
> -.p.name = "libopenh264",
> +FFCodec ff_libopenh264_encoder = {
> +.p.name   = "libopenh264",
>  CODEC_LONG_NAME("OpenH264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10"),
> -.p.type = AVMEDIA_TYPE_VIDEO,
> -.p.id   = AV_CODEC_ID_H264,
> -.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_OTHER_THREADS |
> -  AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
> -.priv_data_size = sizeof(SVCContext),
> -.init   = svc_encode_init,
> 

[FFmpeg-devel] [PATCH] avcodec/cri, tdsc, tiff: Don't forward AVCodecContext.dct_algo

2024-02-11 Thread Andreas Rheinhardt
It is unused for decoders.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/cri.c  | 1 -
 libavcodec/tdsc.c | 1 -
 libavcodec/tiff.c | 1 -
 3 files changed, 3 deletions(-)

diff --git a/libavcodec/cri.c b/libavcodec/cri.c
index 0380a0c665..c4eb468610 100644
--- a/libavcodec/cri.c
+++ b/libavcodec/cri.c
@@ -70,7 +70,6 @@ static av_cold int cri_decode_init(AVCodecContext *avctx)
 return AVERROR(ENOMEM);
 s->jpeg_avctx->flags = avctx->flags;
 s->jpeg_avctx->flags2 = avctx->flags2;
-s->jpeg_avctx->dct_algo = avctx->dct_algo;
 s->jpeg_avctx->idct_algo = avctx->idct_algo;
 ret = avcodec_open2(s->jpeg_avctx, codec, NULL);
 if (ret < 0)
diff --git a/libavcodec/tdsc.c b/libavcodec/tdsc.c
index 739738d9b1..624e219cb4 100644
--- a/libavcodec/tdsc.c
+++ b/libavcodec/tdsc.c
@@ -127,7 +127,6 @@ static av_cold int tdsc_init(AVCodecContext *avctx)
 return AVERROR(ENOMEM);
 ctx->jpeg_avctx->flags = avctx->flags;
 ctx->jpeg_avctx->flags2 = avctx->flags2;
-ctx->jpeg_avctx->dct_algo = avctx->dct_algo;
 ctx->jpeg_avctx->idct_algo = avctx->idct_algo;
 ret = avcodec_open2(ctx->jpeg_avctx, codec, NULL);
 if (ret < 0)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index adb49e4525..7687dfd0d6 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -2416,7 +2416,6 @@ static av_cold int tiff_init(AVCodecContext *avctx)
 return AVERROR(ENOMEM);
 s->avctx_mjpeg->flags = avctx->flags;
 s->avctx_mjpeg->flags2 = avctx->flags2;
-s->avctx_mjpeg->dct_algo = avctx->dct_algo;
 s->avctx_mjpeg->idct_algo = avctx->idct_algo;
 s->avctx_mjpeg->max_pixels = avctx->max_pixels;
 ret = avcodec_open2(s->avctx_mjpeg, codec, NULL);
-- 
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] avcodec/hevcdec: fix out of bounds index -1 for inter prediction

2024-02-11 Thread Nuo Mi
On Sun, Feb 11, 2024 at 5:00 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Nuo Mi:
> > It's a false positive. We use -1 to index an array, but it's not
> actually used.
> > This patch will make the "GCC UndefinedBehaviorSanitizer" happy.
> >
> > Found by: checkasm-hevc_pel in
> https://fate.ffmpeg.org/report.cgi?time=20240211011905&slot=x86_64-archlinux-gcc-ubsan
> > Reported-by: James Almer 
> > ---
> >  libavcodec/hevcdsp_template.c | 6 +++---
> >  libavcodec/x86/hevcdsp_init.c | 6 +++---
> >  2 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavcodec/hevcdsp_template.c
> b/libavcodec/hevcdsp_template.c
> > index 9b48bdf08e..a4b8901e5d 100644
> > --- a/libavcodec/hevcdsp_template.c
> > +++ b/libavcodec/hevcdsp_template.c
> > @@ -301,9 +301,9 @@ IDCT_DC(32)
> >  //
> >
> 
> >  #define ff_hevc_pel_filters ff_hevc_qpel_filters
> > -#define DECL_HV_FILTER(f)  \
> > -const uint8_t *hf = ff_hevc_ ## f ## _filters[mx - 1]; \
> > -const uint8_t *vf = ff_hevc_ ## f ## _filters[my - 1];
> > +#define DECL_HV_FILTER(f)
>  \
> > +const uint8_t *hf = mx ? ff_hevc_ ## f ## _filters[mx - 1] : NULL;
> \
> > +const uint8_t *vf = my ? ff_hevc_ ## f ## _filters[my - 1] : NULL;
> >
> >  #define FW_PUT(p, f, t)
>\
> >  static void FUNC(put_hevc_## f)(int16_t *dst, const uint8_t *src,
> ptrdiff_t srcstride, int height,\
> > diff --git a/libavcodec/x86/hevcdsp_init.c
> b/libavcodec/x86/hevcdsp_init.c
> > index 31e81eb11f..e0f65177c4 100644
> > --- a/libavcodec/x86/hevcdsp_init.c
> > +++ b/libavcodec/x86/hevcdsp_init.c
> > @@ -87,9 +87,9 @@ IDCT_FUNCS(avx)
> >
> >
> >  #define ff_hevc_pel_filters ff_hevc_qpel_filters
> > -#define DECL_HV_FILTER(f)  \
> > -const uint8_t *hf = ff_hevc_ ## f ## _filters[mx - 1]; \
> > -const uint8_t *vf = ff_hevc_ ## f ## _filters[my - 1];
> > +#define DECL_HV_FILTER(f)
>  \
> > +const uint8_t *hf = mx ? ff_hevc_ ## f ## _filters[mx - 1] : NULL;
> \
> > +const uint8_t *vf = my ? ff_hevc_ ## f ## _filters[my - 1] : NULL;
> \
>
> Spurious addition of trailing '\'.

oh, you are so careful

>


> >
> >  #define FW_PUT(p, a, b, depth, opt) \
> >  void ff_hevc_put_hevc_ ## a ## _ ## depth ## _##opt(int16_t *dst, const
> uint8_t *src, ptrdiff_t srcstride,   \
>
> I have just sent an alternative solution for this that avoids all these
> branches (which the compiler will not be able to eliminate).
>
Think about it for about 3 seconds, then give up :)
👍

> Unfortunately I can't test mips and loongarch myself; there is a
> fate-runner for the latter, but nothing for the former. So hopefully
> someone can test mips.
>

> - Andreas
>
> PS: The aarch64 code (hevcdsp_[eq]pel_neon.S) already offsets its
> filters via dummy arrays. I wonder whether it could now reuse the
> ordinary ones.
>
> ___
> 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] avcodec/hevcdsp: Offset ff_hevc_.pel_filters to simplify addressing

2024-02-11 Thread Nuo Mi
On Sun, Feb 11, 2024 at 4:21 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Besides simplifying address computations (it saves 432B of .text
> in hevcdsp.o alone here) it also fixes undefined behaviour that
> occurs if mx or my are 0 (happens when the filters are unused)
> because they lead to an array index of -1 in the old code.
> This happens in the checkasm-hevc_pel FATE-test.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
> The loongarch and mips parts of this are untested. Luckily we have a
> loongarch patchwork runner...
>
>  libavcodec/hevcdsp.c|   6 +-
>  libavcodec/hevcdsp.h|   5 +-
>  libavcodec/hevcdsp_template.c   |  38 ++--
>  libavcodec/loongarch/hevc_mc.S  | 224 +---
>  libavcodec/loongarch/hevc_mc_bi_lsx.c   |   6 +-
>  libavcodec/loongarch/hevc_mc_uni_lsx.c  |   6 +-
>  libavcodec/loongarch/hevc_mc_uniw_lsx.c |   4 +-
>  libavcodec/loongarch/hevcdsp_lsx.c  |   6 +-
>  libavcodec/mips/hevc_mc_bi_msa.c|   6 +-
>  libavcodec/mips/hevc_mc_biw_msa.c   |   6 +-
>  libavcodec/mips/hevc_mc_uni_msa.c   |   6 +-
>  libavcodec/mips/hevc_mc_uniw_msa.c  |   6 +-
>  libavcodec/mips/hevcdsp_mmi.c   |  20 +--
>  libavcodec/mips/hevcdsp_msa.c   |   6 +-
>  libavcodec/x86/hevcdsp_init.c   |   4 +-
>  15 files changed, 112 insertions(+), 237 deletions(-)
>
> diff --git a/libavcodec/hevcdsp.c b/libavcodec/hevcdsp.c
> index 2ca551df1d..630fdc012e 100644
> --- a/libavcodec/hevcdsp.c
> +++ b/libavcodec/hevcdsp.c
> @@ -91,7 +91,8 @@ static const int8_t transform[32][32] = {
>90, -90,  88, -85,  82, -78,  73, -67,  61, -54,  46, -38,  31,
> -22,  13,  -4 },
>  };
>
> -DECLARE_ALIGNED(16, const int8_t, ff_hevc_epel_filters)[7][4] = {
> +DECLARE_ALIGNED(16, const int8_t, ff_hevc_epel_filters)[8][4] = {
> +{  0 },
>  { -2, 58, 10, -2},
>  { -4, 54, 16, -2},
>  { -6, 46, 28, -4},
> @@ -101,7 +102,8 @@ DECLARE_ALIGNED(16, const int8_t,
> ff_hevc_epel_filters)[7][4] = {
>  { -2, 10, 58, -2},
>  };
>
> -DECLARE_ALIGNED(16, const int8_t, ff_hevc_qpel_filters)[3][16] = {
> +DECLARE_ALIGNED(16, const int8_t, ff_hevc_qpel_filters)[4][16] = {
>
Do you know why this is [4][16]? [4][8] should suffice.
If some architecture requires 16, we might need to update
VVC_INTER_LUMA_TAPS to 16 in the future.
Thank you

> +{ 0 },
>  { -1,  4,-10, 58, 17, -5,  1,  0, -1,  4,-10, 58, 17, -5,  1,  0},
>  { -1,  4,-11, 40, 40,-11,  4, -1, -1,  4,-11, 40, 40,-11,  4, -1},
>  {  0,  1, -5, 17, 58,-10,  4, -1,  0,  1, -5, 17, 58,-10,  4, -1}
> diff --git a/libavcodec/hevcdsp.h b/libavcodec/hevcdsp.h
> index 1b9c5bb6bc..a5933dcac4 100644
>
> --
> 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".


[FFmpeg-devel] [PATCH] lavc/dxv: assume DXV2 files use premultiplied alpha

2024-02-11 Thread Connor Worley
I generated a DXV2 file with an interesting alpha channel using
Adobe Media Encoder 2015 and compared decoding it using Resolume Alley
and ffmpeg. Similarly to DXV3 files, Alley expects premultiplied alpha
and ffmpeg matches its decoding more closely when it does the same.

Reference file: https://connorworley.com/dxv2-dxt5.mov

Existing FATE tests for DXV2 files do not cover this change.

Signed-off-by: Connor Worley 
---
 libavcodec/dxv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
index 82c493f1de..2eca14c129 100644
--- a/libavcodec/dxv.c
+++ b/libavcodec/dxv.c
@@ -923,7 +923,7 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame *frame,
 tag = DXV_FMT_DXT5;
 msgtext = "DXT5";
 
-texdsp_ctx.tex_funct = ctx->texdsp.dxt5_block;
+texdsp_ctx.tex_funct = ctx->texdsp.dxt4_block;
 texdsp_ctx.tex_ratio = 16;
 texdsp_ctx.raw_ratio = 16;
 } else if (old_type & 0x20 || version_major == 1) {
-- 
2.43.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] avcodec/hevcdsp: Offset ff_hevc_.pel_filters to simplify addressing

2024-02-11 Thread Nuo Mi
On Sun, Feb 11, 2024 at 4:21 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Besides simplifying address computations (it saves 432B of .text
> in hevcdsp.o alone here) it also fixes undefined behaviour that
>
We can save more if we change
void (*put_hevc_epel[10][2][2])(int16_t *dst, const uint8_t *src, ptrdiff_t
srcstride, int height, intptr_t mx, intptr_t my, int width);
to
void (*put_hevc_epel[10][2][2])(int16_t *dst, const uint8_t *src, ptrdiff_t
srcstride, int height, const int8_t *hf, const int8_t *vf, int width);
But it may need a lot of work.

occurs if mx or my are 0 (happens when the filters are unused)
> because they lead to an array index of -1 in the old code.
> This happens in the checkasm-hevc_pel FATE-test.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
> The loongarch and mips parts of this are untested. Luckily we have a
> loongarch patchwork runner...
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v3 2/2] lavc/vulkan_av1: port to the new stable API

2024-02-11 Thread Mark Thompson

On 10/02/2024 22:39, Lynne wrote:

Most of this patch was written by Dave Airlie ,
with some additions by me.
 > From be1b73147c92a8f74e5cdf30e5325382a6f77799 Mon Sep 17 00:00:00 2001

> From: Lynne 
> Date: Fri, 19 Jan 2024 10:49:02 +1000
> Subject: [PATCH v3 2/2] lavc/vulkan_av1: port to the new stable API
>
> Most of this patch was written by Dave Airlie ,
> with some additions by me.
> ---
>  libavcodec/Makefile   |   3 +-
>  libavcodec/vulkan_av1.c   | 462 ++
>  libavcodec/vulkan_decode.c|  24 +-
>  libavcodec/vulkan_decode.h|   2 +-
>  libavcodec/vulkan_video.c |  33 +-
>  libavcodec/vulkan_video.h |   3 +-
>  libavcodec/vulkan_video_codec_av1std.h| 403 ---
>  libavcodec/vulkan_video_codec_av1std_decode.h |  36 --
>  libavutil/hwcontext_vulkan.c  |   2 +-
>  libavutil/vulkan_functions.h  |   2 +-
>  libavutil/vulkan_loader.h |   2 +-
>  11 files changed, 303 insertions(+), 669 deletions(-)
>  delete mode 100644 libavcodec/vulkan_video_codec_av1std.h
>  delete mode 100644 libavcodec/vulkan_video_codec_av1std_decode.h

You need something in configure to detect whether the AV1 header is available 
so it can build.  (Currently this passes configure and errors out at build time 
for me with 1.3.275 headers.)

> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 470d7cb9b1..581415f3b7 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -1262,7 +1262,6 @@ SKIPHEADERS+= %_tablegen.h  
\
>aacenc_quantization.h \
>aacenc_quantization_misc.h\
>bitstream_template.h  \
> -  vulkan_video_codec_av1std.h   \
>$(ARCH)/vpx_arith.h  \
>
>  SKIPHEADERS-$(CONFIG_AMF)  += amfenc.h
> @@ -1285,7 +1284,7 @@ SKIPHEADERS-$(CONFIG_XVMC) += xvmc.h
>  SKIPHEADERS-$(CONFIG_VAAPI)+= vaapi_decode.h vaapi_hevc.h 
vaapi_encode.h
>  SKIPHEADERS-$(CONFIG_VDPAU)+= vdpau.h vdpau_internal.h
>  SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += videotoolbox.h vt_internal.h
> -SKIPHEADERS-$(CONFIG_VULKAN)   += vulkan.h vulkan_video.h 
vulkan_decode.h vulkan_video_codec_av1std_decode.h
> +SKIPHEADERS-$(CONFIG_VULKAN)   += vulkan.h vulkan_video.h 
vulkan_decode.h
>  SKIPHEADERS-$(CONFIG_V4L2_M2M) += v4l2_buffers.h v4l2_context.h 
v4l2_m2m.h
>  SKIPHEADERS-$(CONFIG_ZLIB) += zlib_wrapper.h
>
> diff --git a/libavcodec/vulkan_av1.c b/libavcodec/vulkan_av1.c
> index 9730e4b08d..3dcad57f21 100644
> --- a/libavcodec/vulkan_av1.c
> +++ b/libavcodec/vulkan_av1.c
> @@ -35,18 +35,33 @@ typedef struct AV1VulkanDecodePicture {
>   *Can be removed once no longer needed, and threading can be enabled. */
>  FFVulkanDecodeContext  *dec;
>
> -StdVideoAV1MESATiletiles[MAX_TILES];
> -StdVideoAV1MESATileListtile_list;
> -const uint32_t*tile_offsets;
> +uint32_t tile_count;
> +uint32_t tile_offsets_s[MAX_TILES];
> +uint32_t tile_sizes[MAX_TILES];

I don't see any check before writing things to this array.  What happens if you 
get a non-conforming stream with more than 256 tiles?

> +const uint32_t *tile_offsets;
>
>  /* Current picture */
> -VkVideoDecodeAV1DpbSlotInfoMESAvkav1_ref;
> -StdVideoAV1MESAFrameHeader av1_frame_header;
> -VkVideoDecodeAV1PictureInfoMESAav1_pic_info;
> +StdVideoDecodeAV1ReferenceInfo std_ref;
> +VkVideoDecodeAV1DpbSlotInfoKHR vkav1_ref;
> +uint16_t width_in_sbs_minus1[64];
> +uint16_t height_in_sbs_minus1[64];
> +uint16_t mi_col_starts[64];
> +uint16_t mi_row_starts[64];
> +StdVideoAV1TileInfo tile_info;
> +StdVideoAV1Quantization quantization;
> +StdVideoAV1Segmentation segmentation;
> +StdVideoAV1LoopFilter loop_filter;
> +StdVideoAV1CDEF cdef;
> +StdVideoAV1LoopRestoration loop_restoration;
> +StdVideoAV1GlobalMotion global_motion;
> +StdVideoAV1FilmGrain film_grain;
> +StdVideoDecodeAV1PictureInfostd_pic_info;
> +VkVideoDecodeAV1PictureInfoKHR av1_pic_info;
>
>  /* Picture refs */
>  const AV1Frame *ref_src   [AV1_NUM_REF_FRAMES];
> -VkVideoDecodeAV1DpbSlotInfoMESA vkav1_refs[AV1_NUM_REF_FRAMES];
> +StdVideoDecodeAV1ReferenceInfo std_ref_info[AV1_NUM_REF_FRAMES];
> +VkVideoDecodeAV1DpbSlotInfoKHR vkav1_refs[AV1_NUM_REF_FRAMES];
>
>  uint8_t frame_id_set;
>  uint8_t frame_id;
> @@ -55,44 +70,65 @@ typedef struct AV1VulkanDecodePicture {
>  static int vk_av1_fill_pict(AVCodecContext *avctx, const

Re: [FFmpeg-devel] [PATCH v2 3/3] lavc/dxv: remove ctx fields that can be derived from texdsp ctxs

2024-02-11 Thread Connor Worley
On Sun, Feb 11, 2024 at 1:03 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Connor Worley:
> > -{
> > -int w_block = avctx->coded_width / ctx->texture_block_w;
> > -int h_block = avctx->coded_height / ctx->texture_block_h;
> > -if (w_block * h_block * ctx->tex_step > ctx->tex_size * 8LL)
> > -return AVERROR_INVALIDDATA;
> > -}
>
> You removed this check without replacement. It presumably fixed a bug.
> Did you test whether you reopened said bug?
> (I think I already asked this in an earlier iteration of this patchset.)
>
> - Andreas
>

My change redefines tex_size to be equal to or less than the left-hand-side
of that if statement, making it redundant AFAICT.
I do see the check was added to fix
10979/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_fuzzer-6178582203203584,
but I'm not familiar with the fuzzing system. If there's a way to replay
the bad input, I'd be curious to try.

-- 
Connor Worley
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [RFC] Vote STF/SPI 2024-02

2024-02-11 Thread Michael Niedermayer
On Sun, Feb 04, 2024 at 01:42:31AM +0100, Michael Niedermayer wrote:
> On Sat, Feb 03, 2024 at 04:37:54AM +0100, Michael Niedermayer wrote:
> > On Thu, Feb 01, 2024 at 05:29:26AM +0100, Michael Niedermayer wrote:
> > > Hi all
> > > 
> > > To do the STF/SPI thing properly, and make sure we do what the Community 
> > > wants.
> > > We should do this vote: (unless lots of people reply and say we should 
> > > skip the vote)
> > > (i am also CCing jonatan to make sure the option in the vote actually ask 
> > > the GA the
> > >  right question)
> > > 
> > > The vote description will be as follows:
> > > The STF/SPI has suggested us to submit an Application / Scope of work 
> > > before their february meeting.
> > > There are about 2 weeks left.
> > > The minimum grant is 150 000 €
> > > The next STF meeting is expected to be in may. If we submit in february 
> > > and are not selected
> > > we can probably try again in may. Which would increase our chances
> > > If we do not submit in february we can probably submit in may.
> > > There is no guarantee that money will be available in may, for example 
> > > between october 2023
> > > and february 2024 no funds where available AFAIK.
> > > Wiki page is here: 
> > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
> > > 
> > > 
> > > Option A. The Application and Scope of Work from the WIKI shall be 
> > > submitted to STF/SPI before the february 2024 meeting, disagreements in 
> > > it shall be decided by the TC. To achieve continuity, submission shall be 
> > > done by the same person as previous if possible.
> > > 
> > > Option B. No Application and Scope of Work shall be submitted in february 
> > > 2024
> > > 
> > > 
> > > This is a RFC, so if you see errors in it please suggest changes
> > 
> > I intend to start the vote in teh next 24h or so.
> 
> Vote started, you should have received a mail if you are in the GA
> and you should not have received a mail if you are not in the GA
> 50 mails where sent and there are 50 in the script output.
> I hope that no messup happened in this vote
> 
> Please Vote!

As the specified end date of 2024-02-11 has come, and we are over high noon, the
contestants are standing in front of each other, tense with their hands over 
their
pistols, who will walk away today and who will not.

The winner is miss february, she drew her gun first, shot and hit
"The Application and Scope of Work from the WIKI shall be submitted to 
STF/SPI before the february 2024 meeting, disagreements in it shall be decided 
by the TC. To achieve continuity, submission shall be done by the same person 
as previous, if possible." Won

Miss may lost this round, she recieves a free hankachief to wipe the water from 
miss february water pistol off
"No Application and Scope of Work shall be submitted in february 2024", Lost


The CSV file with details is attached

Announced end of poll: 2024-02-11
Actual time poll closed: 2/11/2024, 1:27:15 PM
Private poll (50 authorized voters)
Actual votes cast: 23

I wish all contestants good luck and please soon come and play again!

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
The Application and Scope of Work from the WIKI shall be submitted to STF/SPI before the february 2024 meeting, disagreements in it shall be decided by the TC. To achieve continuity, submission shall be done by the same person as previous, if possible.,No Application and Scope of Work shall be submitted in february 2024
1,2
1,2
1,2
1,2
1,2
2,1
2,1
1,2
2,1
1,2
1,2
1,2
1,2
1,2
2,1
1,2
1,2
1,2
1,2
1,2
1,2
1,2
2,1


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 3/3] lavc/dxv: remove ctx fields that can be derived from texdsp ctxs

2024-02-11 Thread Connor Worley
"or less than" is wrong -- rather tex_step seems to have been larger than
necessary in some cases. With the minimal tex_step in those cases, the new
tex_size should be equal to the LHS.
___
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] avutil/mem: limit alignment to maximum simd align

2024-02-11 Thread Andreas Rheinhardt
Timo Rothenpieler:
> FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
> which then end up heap-allocated.
> By declaring any variable in a struct, or tree of structs, to be 32 byte
> aligned, it allows the compiler to safely assume the entire struct
> itself is also 32 byte aligned.
> 
> This might make the compiler emit code which straight up crashes or
> misbehaves in other ways, and at least in one instances is now
> documented to actually do (see ticket 10549 on trac).
> The issue there is that an unrelated variable in SingleChannelElement is
> declared to have an alignment of 32 bytes. So if the compiler does a copy
> in decode_cpe() with avx instructions, but ffmpeg is built with
> --disable-avx, this results in a crash, since the memory is only 16 byte
> aligned.
> 
> Mind you, even if the compiler does not emit avx instructions, the code
> is still invalid and could misbehave. It just happens not to. Declaring
> any variable in a struct with a 32 byte alignment promises 32 byte
> alignment of the whole struct to the compiler.
> 
> This patch limits the maximum alignment to the maximum possible simd
> alignment according to configure.
> While not perfect, it at the very least gets rid of a lot of UB, by
> matching up the maximum DECLARE_ALIGNED value with the alignment of heap
> allocations done by lavu.
> ---
>  libavutil/mem.c  |  8 +++-
>  libavutil/mem_internal.h | 14 --
>  2 files changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/libavutil/mem.c b/libavutil/mem.c
> index 36b8940a0c..b5bcaab164 100644
> --- a/libavutil/mem.c
> +++ b/libavutil/mem.c
> @@ -62,7 +62,13 @@ void  free(void *ptr);
>  
>  #endif /* MALLOC_PREFIX */
>  
> -#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16))
> +#if defined(_MSC_VER)
> +/* MSVC does not support conditionally limiting alignment.
> +   Set minimum value here to maximum used throughout the codebase. */
> +#define ALIGN (HAVE_SIMD_ALIGN_64 ? 64 : 32)
> +#else
> +#define ALIGN (HAVE_SIMD_ALIGN_64 ? 64 : (HAVE_SIMD_ALIGN_32 ? 32 : 16))
> +#endif
>  
>  /* NOTE: if you want to override these functions with your own
>   * implementations (not recommended) you have to link libav* as
> diff --git a/libavutil/mem_internal.h b/libavutil/mem_internal.h
> index 2448c606f1..e2911b5610 100644
> --- a/libavutil/mem_internal.h
> +++ b/libavutil/mem_internal.h
> @@ -75,18 +75,20 @@
>   * @param v Name of the variable
>   */
>  
> +#define MAX_ALIGNMENT (HAVE_SIMD_ALIGN_64 ? 64 : (HAVE_SIMD_ALIGN_32 ? 32 : 
> 16))
> +
>  #if defined(__INTEL_COMPILER) && __INTEL_COMPILER < 1110 || 
> defined(__SUNPRO_C)
> -#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
> -#define DECLARE_ASM_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
> -#define DECLARE_ASM_CONST(n,t,v)const t __attribute__ ((aligned 
> (n))) v
> +#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
> MAX_ALIGNMENT v
> +#define DECLARE_ASM_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
> MAX_ALIGNMENT v
> +#define DECLARE_ASM_CONST(n,t,v)const t __attribute__ ((aligned 
> (FFMIN(n, MAX_ALIGNMENT v
>  #elif defined(__DJGPP__)
>  #define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
> 16 v
>  #define DECLARE_ASM_ALIGNED(n,t,v)  t av_used __attribute__ ((aligned 
> (FFMIN(n, 16 v
>  #define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__ 
> ((aligned (FFMIN(n, 16 v
>  #elif defined(__GNUC__) || defined(__clang__)
> -#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
> -#define DECLARE_ASM_ALIGNED(n,t,v)  t av_used __attribute__ ((aligned 
> (n))) v
> -#define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__ 
> ((aligned (n))) v
> +#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
> MAX_ALIGNMENT v
> +#define DECLARE_ASM_ALIGNED(n,t,v)  t av_used __attribute__ ((aligned 
> (FFMIN(n, MAX_ALIGNMENT v
> +#define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__ 
> ((aligned (FFMIN(n, MAX_ALIGNMENT v
>  #elif defined(_MSC_VER)
>  #define DECLARE_ALIGNED(n,t,v)  __declspec(align(n)) t v
>  #define DECLARE_ASM_ALIGNED(n,t,v)  __declspec(align(n)) t v

We use alignment for three different usecases: a) Variables on the
stack; b) variables in structs and c) static data. If we limit
alignment, we should only limit it for b). But unfortunately they use
the same macro as c), so someone would need to untangle this by adding
new macros. In the meantime, your original patch seems like the way to go.

- Andreas

One can probably make MSVC happy by avoiding FFMIN like this:
#if HAVE_SIMD_ALIGN_32
#define ALIGN_32 32
#else
#define ALIGN_32 16
#endif
#define DECLARE_VAR_ALIGNED_32(t, v) DECLARE_ALIGNED(ALIGN_32, t, v)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

[FFmpeg-devel] [PATCH] avfilter/vf_(bwdif|yadif)_cuda: Remove unused variables

2024-02-11 Thread Andreas Rheinhardt
Forgotten in 268062fa15e1c05310f9c3977e0b95ac07eca274.

Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/vf_bwdif_cuda.c | 1 -
 libavfilter/vf_yadif_cuda.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/libavfilter/vf_bwdif_cuda.c b/libavfilter/vf_bwdif_cuda.c
index 7585d1fe25..8c37dc8800 100644
--- a/libavfilter/vf_bwdif_cuda.c
+++ b/libavfilter/vf_bwdif_cuda.c
@@ -199,7 +199,6 @@ static av_cold void deint_cuda_uninit(AVFilterContext *ctx)
 {
 CUcontext dummy;
 DeintCUDAContext *s = ctx->priv;
-YADIFContext *y = &s->yadif;
 
 if (s->hwctx && s->cu_module) {
 CudaFunctions *cu = s->hwctx->internal->cuda_dl;
diff --git a/libavfilter/vf_yadif_cuda.c b/libavfilter/vf_yadif_cuda.c
index 17389f092f..79080e71c2 100644
--- a/libavfilter/vf_yadif_cuda.c
+++ b/libavfilter/vf_yadif_cuda.c
@@ -191,7 +191,6 @@ static av_cold void deint_cuda_uninit(AVFilterContext *ctx)
 {
 CUcontext dummy;
 DeintCUDAContext *s = ctx->priv;
-YADIFContext *y = &s->yadif;
 
 if (s->hwctx && s->cu_module) {
 CudaFunctions *cu = s->hwctx->internal->cuda_dl;
-- 
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 v2] avutil/mem: limit alignment to maximum simd align

2024-02-11 Thread Sam James


Timo Rothenpieler  writes:

> On 13.01.2024 16:46, Timo Rothenpieler wrote:
>> FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
>> which then end up heap-allocated.
>> By declaring any variable in a struct, or tree of structs, to be 32 byte
>> aligned, it allows the compiler to safely assume the entire struct
>> itself is also 32 byte aligned.
>> This might make the compiler emit code which straight up crashes or
>> misbehaves in other ways, and at least in one instances is now
>> documented to actually do (see ticket 10549 on trac).
>> The issue there is that an unrelated variable in SingleChannelElement is
>> declared to have an alignment of 32 bytes. So if the compiler does a copy
>> in decode_cpe() with avx instructions, but ffmpeg is built with
>> --disable-avx, this results in a crash, since the memory is only 16 byte
>> aligned.
>> Mind you, even if the compiler does not emit avx instructions, the
>> code
>> is still invalid and could misbehave. It just happens not to. Declaring
>> any variable in a struct with a 32 byte alignment promises 32 byte
>> alignment of the whole struct to the compiler.
>> This patch limits the maximum alignment to the maximum possible simd
>> alignment according to configure.
>> While not perfect, it at the very least gets rid of a lot of UB, by
>> matching up the maximum DECLARE_ALIGNED value with the alignment of heap
>> allocations done by lavu.
>> ---
>>   libavutil/mem.c  |  8 +++-
>>   libavutil/mem_internal.h | 14 --
>>   2 files changed, 15 insertions(+), 7 deletions(-)
>> diff --git a/libavutil/mem.c b/libavutil/mem.c
>> index 36b8940a0c..b5bcaab164 100644
>> --- a/libavutil/mem.c
>> +++ b/libavutil/mem.c
>> @@ -62,7 +62,13 @@ void  free(void *ptr);
>> #endif /* MALLOC_PREFIX */
>>   -#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16))
>> +#if defined(_MSC_VER)
>> +/* MSVC does not support conditionally limiting alignment.
>> +   Set minimum value here to maximum used throughout the codebase. */
>> +#define ALIGN (HAVE_SIMD_ALIGN_64 ? 64 : 32)
>> +#else
>> +#define ALIGN (HAVE_SIMD_ALIGN_64 ? 64 : (HAVE_SIMD_ALIGN_32 ? 32 : 16))
>> +#endif
>> /* NOTE: if you want to override these functions with your own
>>* implementations (not recommended) you have to link libav* as
>> diff --git a/libavutil/mem_internal.h b/libavutil/mem_internal.h
>> index 2448c606f1..e2911b5610 100644
>> --- a/libavutil/mem_internal.h
>> +++ b/libavutil/mem_internal.h
>> @@ -75,18 +75,20 @@
>>* @param v Name of the variable
>>*/
>>   +#define MAX_ALIGNMENT (HAVE_SIMD_ALIGN_64 ? 64 :
>> (HAVE_SIMD_ALIGN_32 ? 32 : 16))
>> +
>>   #if defined(__INTEL_COMPILER) && __INTEL_COMPILER < 1110 || 
>> defined(__SUNPRO_C)
>> -#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
>> -#define DECLARE_ASM_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
>> -#define DECLARE_ASM_CONST(n,t,v)const t __attribute__ ((aligned 
>> (n))) v
>> +#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
>> MAX_ALIGNMENT v
>> +#define DECLARE_ASM_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
>> MAX_ALIGNMENT v
>> +#define DECLARE_ASM_CONST(n,t,v)const t __attribute__ ((aligned 
>> (FFMIN(n, MAX_ALIGNMENT v
>>   #elif defined(__DJGPP__)
>>   #define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned 
>> (FFMIN(n, 16 v
>>   #define DECLARE_ASM_ALIGNED(n,t,v)  t av_used __attribute__ ((aligned 
>> (FFMIN(n, 16 v
>>   #define DECLARE_ASM_CONST(n,t,v)static const t av_used 
>> __attribute__ ((aligned (FFMIN(n, 16 v
>>   #elif defined(__GNUC__) || defined(__clang__)
>> -#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
>> -#define DECLARE_ASM_ALIGNED(n,t,v)  t av_used __attribute__ ((aligned 
>> (n))) v
>> -#define DECLARE_ASM_CONST(n,t,v)static const t av_used 
>> __attribute__ ((aligned (n))) v
>> +#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
>> MAX_ALIGNMENT v
>> +#define DECLARE_ASM_ALIGNED(n,t,v)  t av_used __attribute__ ((aligned 
>> (FFMIN(n, MAX_ALIGNMENT v
>> +#define DECLARE_ASM_CONST(n,t,v)static const t av_used 
>> __attribute__ ((aligned (FFMIN(n, MAX_ALIGNMENT v
>>   #elif defined(_MSC_VER)
>>   #define DECLARE_ALIGNED(n,t,v)  __declspec(align(n)) t v
>>   #define DECLARE_ASM_ALIGNED(n,t,v)  __declspec(align(n)) t v
>
> ping
>
> We really should fix this before 7.0 (and probably also backport it,
> since UB is UB).
>
> I'm fine with whatever approach, as long as the UB is gone.

Yes please, we keep getting users hitting this.

(There's a packaging improvement we can make which Timo has suggested
and I need to implement, but the issue is there nonetheless.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link

Re: [FFmpeg-devel] [PATCH v2] avutil/mem: limit alignment to maximum simd align

2024-02-11 Thread Rémi Denis-Courmont
Le perjantaina 9. helmikuuta 2024, 21.22.17 EET Timo Rothenpieler a écrit :
> On 13.01.2024 16:46, Timo Rothenpieler wrote:
> > FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
> > which then end up heap-allocated.
> > By declaring any variable in a struct, or tree of structs, to be 32 byte
> > aligned, it allows the compiler to safely assume the entire struct
> > itself is also 32 byte aligned.
> > 
> > This might make the compiler emit code which straight up crashes or
> > misbehaves in other ways, and at least in one instances is now
> > documented to actually do (see ticket 10549 on trac).
> > The issue there is that an unrelated variable in SingleChannelElement is
> > declared to have an alignment of 32 bytes. So if the compiler does a copy
> > in decode_cpe() with avx instructions, but ffmpeg is built with
> > --disable-avx, this results in a crash, since the memory is only 16 byte
> > aligned.
> > 
> > Mind you, even if the compiler does not emit avx instructions, the code
> > is still invalid and could misbehave. It just happens not to. Declaring
> > any variable in a struct with a 32 byte alignment promises 32 byte
> > alignment of the whole struct to the compiler.
> > 
> > This patch limits the maximum alignment to the maximum possible simd
> > alignment according to configure.
> > While not perfect, it at the very least gets rid of a lot of UB, by
> > matching up the maximum DECLARE_ALIGNED value with the alignment of heap
> > allocations done by lavu.
> > ---
> > 
> >   libavutil/mem.c  |  8 +++-
> >   libavutil/mem_internal.h | 14 --
> >   2 files changed, 15 insertions(+), 7 deletions(-)
> > 
> > diff --git a/libavutil/mem.c b/libavutil/mem.c
> > index 36b8940a0c..b5bcaab164 100644
> > --- a/libavutil/mem.c
> > +++ b/libavutil/mem.c
> > @@ -62,7 +62,13 @@ void  free(void *ptr);
> > 
> >   #endif /* MALLOC_PREFIX */
> > 
> > -#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16))
> > +#if defined(_MSC_VER)
> > +/* MSVC does not support conditionally limiting alignment.
> > +   Set minimum value here to maximum used throughout the codebase. */
> > +#define ALIGN (HAVE_SIMD_ALIGN_64 ? 64 : 32)

Not that I care whatsoever, but are we assuming that MSVC supports only x86? 
Otherwise, this conditional definition does not make much sense and seems very 
sketchy. In fact, I don't see the point in making this distinction at all 
(*unlike* below).

-- 
レミ・デニ-クールモン
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] [PATCH v2 1/2] avcodec/vvc_mp4toannexb: check bytes left for nalu_len

2024-02-11 Thread Nuo Mi
On Sat, Feb 10, 2024 at 6:57 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Nuo Mi:
> > On Fri, Feb 9, 2024 at 7:40 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Nuo Mi:
> >>> Fixes: fuzzer timeout
> >>> Fixes:
> >>
> 65253/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_MP4TOANNEXB_fuzzer-4972412487467008
> >>>
> >>> Found-by: continuous fuzzing process
> >> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >>> Signed-off-by: Michael Niedermayer 
> >>> Signed-off-by: Andreas Rheinhardt 
> >>> ---
> >>>  libavcodec/bsf/vvc_mp4toannexb.c | 7 ---
> >>>  1 file changed, 4 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/libavcodec/bsf/vvc_mp4toannexb.c
> >> b/libavcodec/bsf/vvc_mp4toannexb.c
> >>> index 25c3726918..36bdae8f49 100644
> >>> --- a/libavcodec/bsf/vvc_mp4toannexb.c
> >>> +++ b/libavcodec/bsf/vvc_mp4toannexb.c
> >>> @@ -155,10 +155,11 @@ static int vvc_extradata_to_annexb(AVBSFContext
> >> *ctx)
> >>>  }
> >>>
> >>>  for (j = 0; j < cnt; j++) {
> >>> -int nalu_len = bytestream2_get_be16(&gb);
> >>> +const int nalu_len = bytestream2_get_be16(&gb);
> >>>
> >>> -if (4 + AV_INPUT_BUFFER_PADDING_SIZE + nalu_len >
> >>> -SIZE_MAX - new_extradata_size) {
> >>> +if (!nalu_len ||
> >>> +nalu_len > bytestream2_get_bytes_left(&gb) ||
> >>> +4 + AV_INPUT_BUFFER_PADDING_SIZE + nalu_len > SIZE_MAX
> >> - new_extradata_size) {
> >>>  ret = AVERROR_INVALIDDATA;
> >>>  goto fail;
> >>>  }
> >>
> >> What about growing the packet?
> >>
> > Hi Andreas,
> > Do you mean growing the packet only once for all nalus?
> > However, this would change the original behavior and result in more
> > duplicate code between the HEVC and VVC implementations.
> > I can do it, but I'll refactor duplications to h2656_mp4toannexb.c first.
> > Do you think that's okay?
> > Thank you
> >
>
> I meant a simple check before growing the packet to ensure that there is
> enough input left as the header claims there to be. Your original patch
> added such a check, so I presumed that there is none. But there is one
> (both here and in hevc_mp4toannexb). So my above point is moot.

Thank you for the explanation.  Your suggestion for the original patch is
pretty good.  Thank you
Applied.

>


> - Andreas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v3 2/2] lavc/vulkan_av1: port to the new stable API

2024-02-11 Thread Lynne
Feb 11, 2024, 12:58 by s...@jkqxz.net:

> On 10/02/2024 22:39, Lynne wrote:
>
>>  11 files changed, 303 insertions(+), 669 deletions(-)
>>  delete mode 100644 libavcodec/vulkan_video_codec_av1std.h
>>  delete mode 100644 libavcodec/vulkan_video_codec_av1std_decode.h
>>
>
> You need something in configure to detect whether the AV1 header is available 
> so it can build.  (Currently this passes configure and errors out at build 
> time for me with 1.3.275 headers.)
>

This affects multiple files, and it's a bit too much to add an ifdef,
so I've added a version check (1.3.277).


>> -StdVideoAV1MESATiletiles[MAX_TILES];
>> -StdVideoAV1MESATileListtile_list;
>> -const uint32_t*tile_offsets;
>> +uint32_t tile_count;
>> +uint32_t tile_offsets_s[MAX_TILES];
>> +uint32_t tile_sizes[MAX_TILES];
>>
>
> I don't see any check before writing things to this array.  What happens if 
> you get a non-conforming stream with more than 256 tiles?
>

Fixed, added a check in vk_av1_decode_slice().


>> +
>> +for (int i = 0; i < AV1_TOTAL_REFS_PER_FRAME; i++) {
>> +vkav1_std_ref->SavedOrderHints[i] = cbs_ctx->order_hints[i];
>>
>
> "SavedOrderHints is interpreted as defined in section 7.20 of the AV1 
> Specification."
>
> This doesn't look right for frames in the DPB.  SavedOrderHints in 7.20 is a 
> two-dimensional array containing OrderHints when that frame was decoded, not 
> the reference order hints of the current frame.
>

SavedOrderHints is a stack that is simply pushed at the time of decoding,
isn't it?
I think this is correct, as these are derived from the bitstream values before
decoding.


>> +vkav1_std_ref->RefFrameSignBias |= cbs_ctx->ref_frame_sign_bias[i] 
>> << i;
>> +}
>> +
>> +*vkav1_ref = (VkVideoDecodeAV1DpbSlotInfoKHR) {
>> +.sType = VK_STRUCTURE_TYPE_VIDEO_DECODE_AV1_DPB_SLOT_INFO_KHR,
>> +.pStdReferenceInfo = vkav1_std_ref,
>>  };
>>
>>  for (unsigned i = 0; i < 7; i++) {
>>  const int idx = pic->raw_frame_header->ref_frame_idx[i];
>> -vkav1_ref->ref_order_hint[i] = 
>> pic->raw_frame_header->ref_order_hint[idx];
>> +vkav1_std_ref->SavedOrderHints[i] = 
>> pic->raw_frame_header->ref_order_hint[idx];
>>
>
> Is this overwriting some of the above?
>

Yes, removed.


>> +for (int i = 0; i < STD_VIDEO_AV1_MAX_SEGMENTS; i++) {
>> +for (int j = 0; j < STD_VIDEO_AV1_SEG_LVL_MAX; j++) {
>> +ap->segmentation.FeatureEnabled[i] |= 
>> frame_header->feature_enabled[i][j] << j;
>>
>
> "the elements of FeatureEnabled are bitmasks where bit index i of element j 
> corresponds to FeatureEnabled[i][j] as defined in section 6.8.13 of the AV1 
> Specification"
>
> This looks like you have i and j swapped?
>

The header define it as:
uint8_t FeatureEnabled[STD_VIDEO_AV1_MAX_SEGMENTS];
We define it as:
uint8_t feature_enabled[AV1_MAX_SEGMENTS][AV1_SEG_LVL_MAX];

So FeatureEnabled[i] |= feature_enabled[i][j] << j;
should be correct.


>> +ap->segmentation.FeatureData[i][j] = 
>> frame_header->feature_value[i][j];
>> +}
>> +}
>> +
>> +ap->loop_filter = (StdVideoAV1LoopFilter) {
>> +.flags = (StdVideoAV1LoopFilterFlags) {
>> +.loop_filter_delta_enabled = 
>> frame_header->loop_filter_delta_enabled,
>> +.loop_filter_delta_update = 
>> frame_header->loop_filter_delta_update,
>> +},
>> +.loop_filter_sharpness = frame_header->loop_filter_sharpness,
>> +};
>> +
>> +for (int i = 0; i < STD_VIDEO_AV1_MAX_LOOP_FILTER_STRENGTHS; i++)
>> +ap->loop_filter.loop_filter_level[i] = 
>> frame_header->loop_filter_level[i];
>> +for (int i = 0; i < STD_VIDEO_AV1_LOOP_FILTER_ADJUSTMENTS; i++)
>> +ap->loop_filter.loop_filter_mode_deltas[i] = 
>> frame_header->loop_filter_mode_deltas[i];
>> +
>> +ap->cdef = (StdVideoAV1CDEF) {
>> +.cdef_damping_minus_3 = frame_header->cdef_damping_minus_3,
>> +.cdef_bits = frame_header->cdef_bits,
>> +};
>> +
>> +uses_lr = frame_header->lr_type[0] || frame_header->lr_type[1] || 
>> frame_header->lr_type[2],
>> +ap->loop_restoration = (StdVideoAV1LoopRestoration) {
>> +.FrameRestorationType[0] = remap_lr_type[frame_header->lr_type[0]],
>> +.FrameRestorationType[1] = remap_lr_type[frame_header->lr_type[1]],
>> +.FrameRestorationType[2] = remap_lr_type[frame_header->lr_type[2]],
>> +.LoopRestorationSize[0] = 1 + frame_header->lr_unit_shift,
>> +.LoopRestorationSize[1] = 1 + frame_header->lr_unit_shift - 
>> frame_header->lr_uv_shift,
>> +.LoopRestorationSize[2] = 1 + frame_header->lr_unit_shift - 
>> frame_header->lr_uv_shift,
>>
>
> The standard has:
>
> LoopRestorationSize[ 0 ] = RESTORATION_TILESIZE_MAX >> (2 - lr_unit_shift)
> LoopRestorationSize[ 1 ] = LoopRestorationSize[ 0 ] >> lr_uv_shift
> LoopRestorationSize[ 2 ] = LoopRestorationSize[ 0 ] >> lr_uv_shift
>
> The values here look like log2 

[FFmpeg-devel] [PATCH v4 1/2] lavc/cbs_av1: fill in ref_frame_sign_bias and order_hints

2024-02-11 Thread Lynne
Needed for Vulkan AV1.

>From 67beae754b839398287499d51134cc40d7cf8ad4 Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Fri, 2 Feb 2024 03:54:06 +0100
Subject: [PATCH v4 1/2] lavc/cbs_av1: fill in ref_frame_sign_bias and
 order_hints

Needed for Vulkan AV1.
---
 libavcodec/cbs_av1.h |  2 ++
 libavcodec/cbs_av1_syntax_template.c | 11 +++
 2 files changed, 13 insertions(+)

diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
index a5402f069d..0ed49e03ca 100644
--- a/libavcodec/cbs_av1.h
+++ b/libavcodec/cbs_av1.h
@@ -465,6 +465,8 @@ typedef struct CodedBitstreamAV1Context {
 int tile_num;
 
 AV1ReferenceFrameState ref[AV1_NUM_REF_FRAMES];
+uint8_t ref_frame_sign_bias[AV1_TOTAL_REFS_PER_FRAME];
+uint8_t order_hints[AV1_TOTAL_REFS_PER_FRAME];
 
 // AVOptions
 int operating_point;
diff --git a/libavcodec/cbs_av1_syntax_template.c b/libavcodec/cbs_av1_syntax_template.c
index 3be1f2d30f..20eed7ff9e 100644
--- a/libavcodec/cbs_av1_syntax_template.c
+++ b/libavcodec/cbs_av1_syntax_template.c
@@ -1572,6 +1572,17 @@ static int FUNC(uncompressed_header)(CodedBitstreamContext *ctx, RWContext *rw,
 }
 
 if (!frame_is_intra) {
+for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
+uint8_t ref_frame = AV1_REF_FRAME_LAST + i;
+if (seq->enable_order_hint) {
+uint8_t hint = current->ref_order_hint[current->ref_frame_idx[i]];
+uint8_t sign_bias = cbs_av1_get_relative_dist(seq, hint, priv->order_hint) > 0;
+priv->order_hints[ref_frame] = hint;
+priv->ref_frame_sign_bias[ref_frame] = sign_bias;
+} else {
+priv->ref_frame_sign_bias[ref_frame] = 0;
+}
+}
 // Derive reference frame sign biases.
 }
 
-- 
2.43.0.381.gb435a96ce8

___
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 v4 2/2] lavc/vulkan_av1: port to the new stable API

2024-02-11 Thread Lynne
Most of this patch was written by Dave Airlie ,
with some additions by me.

>From 4a0c01046e36cff48100d09565f5ef8d8185907a Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Fri, 19 Jan 2024 10:49:02 +1000
Subject: [PATCH v4 2/2] lavc/vulkan_av1: port to the new stable API

Most of this patch was written by Dave Airlie ,
with some additions by me.
---
 configure |   4 +-
 libavcodec/Makefile   |   3 +-
 libavcodec/av1.h  |   2 +
 libavcodec/vulkan_av1.c   | 477 ++
 libavcodec/vulkan_decode.c|  24 +-
 libavcodec/vulkan_decode.h|   2 +-
 libavcodec/vulkan_video.c |   2 +-
 libavcodec/vulkan_video.h |   2 -
 libavcodec/vulkan_video_codec_av1std.h| 403 ---
 libavcodec/vulkan_video_codec_av1std_decode.h |  36 --
 libavutil/hwcontext_vulkan.c  |   2 +-
 libavutil/vulkan_functions.h  |   2 +-
 libavutil/vulkan_loader.h |   2 +-
 13 files changed, 277 insertions(+), 684 deletions(-)
 delete mode 100644 libavcodec/vulkan_video_codec_av1std.h
 delete mode 100644 libavcodec/vulkan_video_codec_av1std_decode.h

diff --git a/configure b/configure
index f72533b7d2..9a3a451115 100755
--- a/configure
+++ b/configure
@@ -7225,8 +7225,8 @@ enabled crystalhd && check_lib crystalhd "stdint.h libcrystalhd/libcrystalhd_if.
  "in maintaining it."
 
 if enabled vulkan; then
-check_pkg_config_header_only vulkan "vulkan >= 1.3.255" "vulkan/vulkan.h" "defined VK_VERSION_1_3" ||
-check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 255)"
+check_pkg_config_header_only vulkan "vulkan >= 1.3.277" "vulkan/vulkan.h" "defined VK_VERSION_1_3" ||
+check_cpp_condition vulkan "vulkan/vulkan.h" "defined(VK_VERSION_1_4) || (defined(VK_VERSION_1_3) && VK_HEADER_VERSION >= 277)"
 fi
 
 if disabled vulkan; then
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 470d7cb9b1..581415f3b7 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1262,7 +1262,6 @@ SKIPHEADERS+= %_tablegen.h  \
   aacenc_quantization.h \
   aacenc_quantization_misc.h\
   bitstream_template.h  \
-  vulkan_video_codec_av1std.h   \
   $(ARCH)/vpx_arith.h  \
 
 SKIPHEADERS-$(CONFIG_AMF)  += amfenc.h
@@ -1285,7 +1284,7 @@ SKIPHEADERS-$(CONFIG_XVMC) += xvmc.h
 SKIPHEADERS-$(CONFIG_VAAPI)+= vaapi_decode.h vaapi_hevc.h vaapi_encode.h
 SKIPHEADERS-$(CONFIG_VDPAU)+= vdpau.h vdpau_internal.h
 SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += videotoolbox.h vt_internal.h
-SKIPHEADERS-$(CONFIG_VULKAN)   += vulkan.h vulkan_video.h vulkan_decode.h vulkan_video_codec_av1std_decode.h
+SKIPHEADERS-$(CONFIG_VULKAN)   += vulkan.h vulkan_video.h vulkan_decode.h
 SKIPHEADERS-$(CONFIG_V4L2_M2M) += v4l2_buffers.h v4l2_context.h v4l2_m2m.h
 SKIPHEADERS-$(CONFIG_ZLIB) += zlib_wrapper.h
 
diff --git a/libavcodec/av1.h b/libavcodec/av1.h
index 8704bc41c1..18d5fa9e7f 100644
--- a/libavcodec/av1.h
+++ b/libavcodec/av1.h
@@ -121,6 +121,8 @@ enum {
 AV1_DIV_LUT_NUM   = 257,
 
 AV1_MAX_LOOP_FILTER = 63,
+
+AV1_RESTORATION_TILESIZE_MAX = 256,
 };
 
 
diff --git a/libavcodec/vulkan_av1.c b/libavcodec/vulkan_av1.c
index 9730e4b08d..641ee3e4bf 100644
--- a/libavcodec/vulkan_av1.c
+++ b/libavcodec/vulkan_av1.c
@@ -31,22 +31,36 @@ const VkExtensionProperties ff_vk_dec_av1_ext = {
 typedef struct AV1VulkanDecodePicture {
 FFVulkanDecodePicture   vp;
 
-/* Workaround for a spec issue.
- *Can be removed once no longer needed, and threading can be enabled. */
+/* TODO: investigate if this can be removed to make decoding completely
+ * independent. */
 FFVulkanDecodeContext  *dec;
 
-StdVideoAV1MESATiletiles[MAX_TILES];
-StdVideoAV1MESATileListtile_list;
-const uint32_t*tile_offsets;
+uint32_t tile_count;
+uint32_t tile_sizes[MAX_TILES];
+const uint32_t *tile_offsets;
 
 /* Current picture */
-VkVideoDecodeAV1DpbSlotInfoMESAvkav1_ref;
-StdVideoAV1MESAFrameHeader av1_frame_header;
-VkVideoDecodeAV1PictureInfoMESAav1_pic_info;
+StdVideoDecodeAV1ReferenceInfo std_ref;
+VkVideoDecodeAV1DpbSlotInfoKHR vkav1_ref;
+uint16_t width_in_sbs_minus1[64];
+uint16_t height_in_sbs_minus1[64];
+uint16_t mi_col_starts[64];
+uint16_t mi_row_starts[64];
+StdVideoAV1TileInfo tile_info;
+StdVideoAV1Quantization quantization;
+StdV

Re: [FFmpeg-devel] [PATCH v2] avutil/mem: limit alignment to maximum simd align

2024-02-11 Thread Timo Rothenpieler

On 11.02.2024 15:22, Rémi Denis-Courmont wrote:

Le perjantaina 9. helmikuuta 2024, 21.22.17 EET Timo Rothenpieler a écrit :

On 13.01.2024 16:46, Timo Rothenpieler wrote:

FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself is also 32 byte aligned.

This might make the compiler emit code which straight up crashes or
misbehaves in other ways, and at least in one instances is now
documented to actually do (see ticket 10549 on trac).
The issue there is that an unrelated variable in SingleChannelElement is
declared to have an alignment of 32 bytes. So if the compiler does a copy
in decode_cpe() with avx instructions, but ffmpeg is built with
--disable-avx, this results in a crash, since the memory is only 16 byte
aligned.

Mind you, even if the compiler does not emit avx instructions, the code
is still invalid and could misbehave. It just happens not to. Declaring
any variable in a struct with a 32 byte alignment promises 32 byte
alignment of the whole struct to the compiler.

This patch limits the maximum alignment to the maximum possible simd
alignment according to configure.
While not perfect, it at the very least gets rid of a lot of UB, by
matching up the maximum DECLARE_ALIGNED value with the alignment of heap
allocations done by lavu.
---

   libavutil/mem.c  |  8 +++-
   libavutil/mem_internal.h | 14 --
   2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/libavutil/mem.c b/libavutil/mem.c
index 36b8940a0c..b5bcaab164 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -62,7 +62,13 @@ void  free(void *ptr);

   #endif /* MALLOC_PREFIX */

-#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16))
+#if defined(_MSC_VER)
+/* MSVC does not support conditionally limiting alignment.
+   Set minimum value here to maximum used throughout the codebase. */
+#define ALIGN (HAVE_SIMD_ALIGN_64 ? 64 : 32)


Not that I care whatsoever, but are we assuming that MSVC supports only x86?
Otherwise, this conditional definition does not make much sense and seems very
sketchy. In fact, I don't see the point in making this distinction at all
(*unlike* below).



MSVC straight up _does not support_ putting conditionals into its 
alignment macros.

It initially had the same treatment, but failed with compile errors.
___
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] avutil/mem: limit alignment to maximum simd align

2024-02-11 Thread Timo Rothenpieler

On 11.02.2024 15:00, Andreas Rheinhardt wrote:

Timo Rothenpieler:

FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself is also 32 byte aligned.

This might make the compiler emit code which straight up crashes or
misbehaves in other ways, and at least in one instances is now
documented to actually do (see ticket 10549 on trac).
The issue there is that an unrelated variable in SingleChannelElement is
declared to have an alignment of 32 bytes. So if the compiler does a copy
in decode_cpe() with avx instructions, but ffmpeg is built with
--disable-avx, this results in a crash, since the memory is only 16 byte
aligned.

Mind you, even if the compiler does not emit avx instructions, the code
is still invalid and could misbehave. It just happens not to. Declaring
any variable in a struct with a 32 byte alignment promises 32 byte
alignment of the whole struct to the compiler.

This patch limits the maximum alignment to the maximum possible simd
alignment according to configure.
While not perfect, it at the very least gets rid of a lot of UB, by
matching up the maximum DECLARE_ALIGNED value with the alignment of heap
allocations done by lavu.
---
  libavutil/mem.c  |  8 +++-
  libavutil/mem_internal.h | 14 --
  2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/libavutil/mem.c b/libavutil/mem.c
index 36b8940a0c..b5bcaab164 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -62,7 +62,13 @@ void  free(void *ptr);
  
  #endif /* MALLOC_PREFIX */
  
-#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16))

+#if defined(_MSC_VER)
+/* MSVC does not support conditionally limiting alignment.
+   Set minimum value here to maximum used throughout the codebase. */
+#define ALIGN (HAVE_SIMD_ALIGN_64 ? 64 : 32)
+#else
+#define ALIGN (HAVE_SIMD_ALIGN_64 ? 64 : (HAVE_SIMD_ALIGN_32 ? 32 : 16))
+#endif
  
  /* NOTE: if you want to override these functions with your own

   * implementations (not recommended) you have to link libav* as
diff --git a/libavutil/mem_internal.h b/libavutil/mem_internal.h
index 2448c606f1..e2911b5610 100644
--- a/libavutil/mem_internal.h
+++ b/libavutil/mem_internal.h
@@ -75,18 +75,20 @@
   * @param v Name of the variable
   */
  
+#define MAX_ALIGNMENT (HAVE_SIMD_ALIGN_64 ? 64 : (HAVE_SIMD_ALIGN_32 ? 32 : 16))

+
  #if defined(__INTEL_COMPILER) && __INTEL_COMPILER < 1110 || 
defined(__SUNPRO_C)
-#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
-#define DECLARE_ASM_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
-#define DECLARE_ASM_CONST(n,t,v)const t __attribute__ ((aligned (n))) v
+#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
MAX_ALIGNMENT v
+#define DECLARE_ASM_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
MAX_ALIGNMENT v
+#define DECLARE_ASM_CONST(n,t,v)const t __attribute__ ((aligned 
(FFMIN(n, MAX_ALIGNMENT v
  #elif defined(__DJGPP__)
  #define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
16 v
  #define DECLARE_ASM_ALIGNED(n,t,v)  t av_used __attribute__ ((aligned 
(FFMIN(n, 16 v
  #define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__ 
((aligned (FFMIN(n, 16 v
  #elif defined(__GNUC__) || defined(__clang__)
-#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
-#define DECLARE_ASM_ALIGNED(n,t,v)  t av_used __attribute__ ((aligned 
(n))) v
-#define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__ 
((aligned (n))) v
+#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
MAX_ALIGNMENT v
+#define DECLARE_ASM_ALIGNED(n,t,v)  t av_used __attribute__ ((aligned 
(FFMIN(n, MAX_ALIGNMENT v
+#define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__ 
((aligned (FFMIN(n, MAX_ALIGNMENT v
  #elif defined(_MSC_VER)
  #define DECLARE_ALIGNED(n,t,v)  __declspec(align(n)) t v
  #define DECLARE_ASM_ALIGNED(n,t,v)  __declspec(align(n)) t v


We use alignment for three different usecases: a) Variables on the
stack; b) variables in structs and c) static data. If we limit
alignment, we should only limit it for b). But unfortunately they use
the same macro as c), so someone would need to untangle this by adding
new macros. In the meantime, your original patch seems like the way to go.


Is it really such an issue to limit the alignment to less than some of 
those request, if there are no SIMD instructions would would ever need a 
higher alignment on that platform?


I can't think of many situations where you'd need alignment other than 
SIMD, outside of crazy page alignment stuff, for which 32/64 bytes are 
far from enough anyway.



If there's no further objections, I'll push a simple bump to 32 bytes, 
as pe

[FFmpeg-devel] [PATCH] avutil/hwcontext_opencl: Use proper OpenCLFramesContext

2024-02-11 Thread Andreas Rheinhardt
The currently used pointer when unmapping DXVA2 and D3D11
actually points to an OpenCLDeviceContext.

Signed-off-by: Andreas Rheinhardt 
---
Untested. Both of these structures have command queues at the start
which is probably why this seems to work.

 libavutil/hwcontext_opencl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index 247834aaf6..c1764ed098 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -2346,7 +2346,7 @@ static void opencl_unmap_from_dxva2(AVHWFramesContext 
*dst_fc,
 {
 AVOpenCLFrameDescriptor*desc = hwmap->priv;
 OpenCLDeviceContext *device_priv = dst_fc->device_ctx->internal->priv;
-OpenCLFramesContext *frames_priv = dst_fc->device_ctx->internal->priv;
+OpenCLFramesContext *frames_priv = dst_fc->internal->priv;
 cl_event event;
 cl_int cle;
 
@@ -2511,7 +2511,7 @@ static void opencl_unmap_from_d3d11(AVHWFramesContext 
*dst_fc,
 {
 AVOpenCLFrameDescriptor*desc = hwmap->priv;
 OpenCLDeviceContext *device_priv = dst_fc->device_ctx->internal->priv;
-OpenCLFramesContext *frames_priv = dst_fc->device_ctx->internal->priv;
+OpenCLFramesContext *frames_priv = dst_fc->internal->priv;
 cl_event event;
 cl_int cle;
 
-- 
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 v2 0/1] avcodec/libjxlenc: add option to disable xyb encoding

2024-02-11 Thread Leo Izen
Changes since v1:
- bump micro version, per policy
- rebase onto master

Leo Izen (1):
  avcodec/libjxlenc: add option to disable xyb encoding

 libavcodec/libjxlenc.c | 5 -
 libavcodec/version.h   | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH v2 1/1] avcodec/libjxlenc: add option to disable xyb encoding

2024-02-11 Thread Leo Izen
Add an AVOption to the libjxl encoder wrapper, which exposes the flag
uses_original_profile in libjxl. For highly unusual ICC profiles where
the target needs to stay in the original space, this can be useful.

Signed-off-by: Leo Izen 
---
 libavcodec/libjxlenc.c | 5 -
 libavcodec/version.h   | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index 5f5f9751dc..3f2c74097d 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -52,6 +52,7 @@ typedef struct LibJxlEncodeContext {
 int effort;
 float distance;
 int modular;
+int xyb;
 uint8_t *buffer;
 size_t buffer_size;
 } LibJxlEncodeContext;
@@ -303,7 +304,7 @@ static int libjxl_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt, const AVFra
 av_log(avctx, AV_LOG_WARNING, "Unknown color range, assuming full 
(pc)\n");
 
 /* bitexact lossless requires there to be no XYB transform */
-info.uses_original_profile = ctx->distance == 0.0;
+info.uses_original_profile = ctx->distance == 0.0 || !ctx->xyb;
 info.orientation = frame->linesize[0] >= 0 ? JXL_ORIENT_IDENTITY : 
JXL_ORIENT_FLIP_VERTICAL;
 
 if (JxlEncoderSetBasicInfo(ctx->encoder, &info) != JXL_ENC_SUCCESS) {
@@ -474,6 +475,8 @@ static const AVOption libjxl_encode_options[] = {
 { "distance",  "Maximum Butteraugli distance (quality setting, "
 "lower = better, zero = lossless, default 1.0)",   
OFFSET(distance),   AV_OPT_TYPE_FLOAT,  { .dbl = -1.0 }, -1.0,  15.0, VE },
 { "modular",   "Force modular mode",   
OFFSET(modular),AV_OPT_TYPE_INT,{ .i64 =0 },0, 1, VE },
+{ "xyb",   "Use XYB-encoding for lossy images",
OFFSET(xyb),
+AV_OPT_TYPE_INT,   { .i64 =1 },0, 1, VE },
 { NULL },
 };
 
diff --git a/libavcodec/version.h b/libavcodec/version.h
index f2f14eaed1..ecdbc51c74 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -30,7 +30,7 @@
 #include "version_major.h"
 
 #define LIBAVCODEC_VERSION_MINOR  39
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v2 3/3] lavc/dxv: remove ctx fields that can be derived from texdsp ctxs

2024-02-11 Thread James Almer

On 2/11/2024 9:41 AM, Connor Worley wrote:

"or less than" is wrong -- rather tex_step seems to have been larger than
necessary in some cases. With the minimal tex_step in those cases, the new
tex_size should be equal to the LHS.


This set broke fate when using slice threading: 
https://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-threads-misc&time=20240211015448

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH] avutil/mem: limit alignment to maximum simd align

2024-02-11 Thread Timo Rothenpieler
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself is also 32 byte aligned.

This might make the compiler emit code which straight up crashes or
misbehaves in other ways, and at least in one instances is now
documented to actually do (see ticket 10549 on trac).
The issue there is that an unrelated variable in SingleChannelElement is
declared to have an alignment of 32 bytes. So if the compiler does a copy
in decode_cpe() with avx instructions, but ffmpeg is built with
--disable-avx, this results in a crash, since the memory is only 16 byte
aligned.

Mind you, even if the compiler does not emit avx instructions, the code
is still invalid and could misbehave. It just happens not to. Declaring
any variable in a struct with a 32 byte alignment promises 32 byte
alignment of the whole struct to the compiler.

This patch limits the maximum alignment to the maximum possible simd
alignment according to configure.
While not perfect, it at the very least gets rid of a lot of UB, by
matching up the maximum DECLARE_ALIGNED value with the alignment of heap
allocations done by lavu.
---
 libavutil/mem.c  |  2 +-
 libavutil/mem_internal.h | 33 -
 2 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/libavutil/mem.c b/libavutil/mem.c
index 36b8940a0c..62163b4cb3 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -62,7 +62,7 @@ void  free(void *ptr);
 
 #endif /* MALLOC_PREFIX */
 
-#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16))
+#define ALIGN (HAVE_SIMD_ALIGN_64 ? 64 : (HAVE_SIMD_ALIGN_32 ? 32 : 16))
 
 /* NOTE: if you want to override these functions with your own
  * implementations (not recommended) you have to link libav* as
diff --git a/libavutil/mem_internal.h b/libavutil/mem_internal.h
index 2448c606f1..b1d89a0605 100644
--- a/libavutil/mem_internal.h
+++ b/libavutil/mem_internal.h
@@ -76,27 +76,50 @@
  */
 
 #if defined(__INTEL_COMPILER) && __INTEL_COMPILER < 1110 || defined(__SUNPRO_C)
-#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
+#define DECLARE_ALIGNED_T(n,t,v)t __attribute__ ((aligned (n))) v
 #define DECLARE_ASM_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
 #define DECLARE_ASM_CONST(n,t,v)const t __attribute__ ((aligned (n))) v
 #elif defined(__DJGPP__)
-#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
16 v
+#define DECLARE_ALIGNED_T(n,t,v)t __attribute__ ((aligned (FFMIN(n, 
16 v
 #define DECLARE_ASM_ALIGNED(n,t,v)  t av_used __attribute__ ((aligned 
(FFMIN(n, 16 v
 #define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__ 
((aligned (FFMIN(n, 16 v
 #elif defined(__GNUC__) || defined(__clang__)
-#define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
+#define DECLARE_ALIGNED_T(n,t,v)t __attribute__ ((aligned (n))) v
 #define DECLARE_ASM_ALIGNED(n,t,v)  t av_used __attribute__ ((aligned 
(n))) v
 #define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__ 
((aligned (n))) v
 #elif defined(_MSC_VER)
-#define DECLARE_ALIGNED(n,t,v)  __declspec(align(n)) t v
+#define DECLARE_ALIGNED_T(n,t,v)__declspec(align(n)) t v
 #define DECLARE_ASM_ALIGNED(n,t,v)  __declspec(align(n)) t v
 #define DECLARE_ASM_CONST(n,t,v)__declspec(align(n)) static const t v
 #else
-#define DECLARE_ALIGNED(n,t,v)  t v
+#define DECLARE_ALIGNED_T(n,t,v)t v
 #define DECLARE_ASM_ALIGNED(n,t,v)  t v
 #define DECLARE_ASM_CONST(n,t,v)static const t v
 #endif
 
+#if HAVE_SIMD_ALIGN_64
+#define ALIGN_64 64
+#define ALIGN_32 32
+#elif HAVE_SIMD_ALIGN_32
+#define ALIGN_64 32
+#define ALIGN_32 32
+#else
+#define ALIGN_64 16
+#define ALIGN_32 16
+#endif
+
+#define DECLARE_ALIGNED(n,t,v) DECLARE_ALIGNED_V(n,t,v)
+
+// Macro needs to be double-wrapped in order to expand
+// possible other macros being passed for n.
+#define DECLARE_ALIGNED_V(n,t,v) DECLARE_ALIGNED_##n(t,v)
+
+#define DECLARE_ALIGNED_4(t,v)  DECLARE_ALIGNED_T(   4, t, v)
+#define DECLARE_ALIGNED_8(t,v)  DECLARE_ALIGNED_T(   8, t, v)
+#define DECLARE_ALIGNED_16(t,v) DECLARE_ALIGNED_T(  16, t, v)
+#define DECLARE_ALIGNED_32(t,v) DECLARE_ALIGNED_T(ALIGN_32, t, v)
+#define DECLARE_ALIGNED_64(t,v) DECLARE_ALIGNED_T(ALIGN_64, t, v)
+
 // Some broken preprocessors need a second expansion
 // to be forced to tokenize __VA_ARGS__
 #define E1(x) 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 v13 1/2] libavformat: add DVD-Video demuxer, powered by libdvdnav and libdvdread

2024-02-11 Thread Marth64
No critical changes since v12.
- Removes unused context variable
- Removes unnecessary if statement
- Whitespace cleanup
- Rebase with master

Signed-off-by: Marth64 
---
 Changelog |2 +
 configure |8 +
 doc/demuxers.texi |  130 
 libavformat/Makefile  |1 +
 libavformat/allformats.c  |1 +
 libavformat/dvdvideodec.c | 1418 +
 6 files changed, 1560 insertions(+)
 create mode 100644 libavformat/dvdvideodec.c

diff --git a/Changelog b/Changelog
index c5fb21d198..88653bc6d3 100644
--- a/Changelog
+++ b/Changelog
@@ -24,6 +24,8 @@ version :
 - ffmpeg CLI options may now be used as -/opt , which is equivalent
   to -opt >
 - showinfo bitstream filter
+- DVD-Video demuxer, powered by libdvdnav and libdvdread
+
 
 version 6.1:
 - libaribcaption decoder
diff --git a/configure b/configure
index f72533b7d2..831b9f6cb6 100755
--- a/configure
+++ b/configure
@@ -227,6 +227,8 @@ External library support:
   --enable-libdavs2enable AVS2 decoding via libdavs2 [no]
   --enable-libdc1394   enable IIDC-1394 grabbing using libdc1394
and libraw1394 [no]
+  --enable-libdvdnav   enable libdvdnav, needed for DVD demuxing [no]
+  --enable-libdvdread  enable libdvdread, needed for DVD demuxing [no]
   --enable-libfdk-aac  enable AAC de/encoding via libfdk-aac [no]
   --enable-libfliteenable flite (voice synthesis) support via libflite 
[no]
   --enable-libfontconfig   enable libfontconfig, useful for drawtext filter 
[no]
@@ -1806,6 +1808,8 @@ EXTERNAL_LIBRARY_GPL_LIST="
 frei0r
 libcdio
 libdavs2
+libdvdnav
+libdvdread
 librubberband
 libvidstab
 libx264
@@ -3523,6 +3527,8 @@ dts_demuxer_select="dca_parser"
 dtshd_demuxer_select="dca_parser"
 dv_demuxer_select="dvprofile"
 dv_muxer_select="dvprofile"
+dvdvideo_demuxer_select="mpegps_demuxer"
+dvdvideo_demuxer_deps="libdvdnav libdvdread"
 dxa_demuxer_select="riffdec"
 eac3_demuxer_select="ac3_parser"
 evc_demuxer_select="evc_frame_merge_bsf evc_parser"
@@ -6771,6 +6777,8 @@ enabled libdav1d  && require_pkg_config libdav1d 
"dav1d >= 0.5.0" "dav1d
 enabled libdavs2  && require_pkg_config libdavs2 "davs2 >= 1.6.0" 
davs2.h davs2_decoder_open
 enabled libdc1394 && require_pkg_config libdc1394 libdc1394-2 
dc1394/dc1394.h dc1394_new
 enabled libdrm&& check_pkg_config libdrm libdrm xf86drm.h 
drmGetVersion
+enabled libdvdnav && require_pkg_config libdvdnav "dvdnav >= 6.1.1" 
dvdnav/dvdnav.h dvdnav_open2
+enabled libdvdread&& require_pkg_config libdvdread "dvdread >= 6.1.2" 
dvdread/dvd_reader.h DVDOpen2 -ldvdread
 enabled libfdk_aac&& { check_pkg_config libfdk_aac fdk-aac 
"fdk-aac/aacenc_lib.h" aacEncOpen ||
{ require libfdk_aac fdk-aac/aacenc_lib.h 
aacEncOpen -lfdk-aac &&
  warn "using libfdk without pkg-config"; } }
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e4c5b560a6..062ea2ea42 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -285,6 +285,136 @@ This demuxer accepts the following option:
 
 @end table
 
+@section dvdvideo
+
+DVD-Video demuxer, powered by libdvdnav and libdvdread.
+
+Can directly ingest DVD titles, specifically sequential PGCs,
+into a conversion pipeline. Menus and seeking are not supported at this time.
+
+Block devices (DVD drives), ISO files, and directory structures are accepted.
+Activate with @code{-f dvdvideo} in front of one of these inputs.
+
+Underlying playback is handled by libdvdnav, and structure parsing by 
libdvdread.
+FFmpeg must be built with GPL library support available as well as the
+configure switches @code{--enable-libdvdnav} and @code{--enable-libdvdread}.
+
+You will need to provide either the desired "title number" or exact PGC/PG 
coordinates.
+Many open-source DVD players and tools can aid in providing this information.
+If not specified, the demuxer will default to title 1 which works for many 
discs.
+However, due to the flexibility of the format, it is recommended to check 
manually.
+There are many discs that are authored strangely or with invalid headers.
+
+If the input is a real DVD drive, please note that there are some drives which 
may
+silently fail on reading bad sectors from the disc, returning random bits 
instead
+which is effectively corrupt data. This is especially prominent on aging or 
rotting discs.
+A second pass and integrity checks would be needed to detect the corruption.
+This is not an FFmpeg issue.
+
+@subsection Background
+
+DVD-Video is not a directly accessible, linear container format in the
+traditional sense. Instead, it allows for complex and programmatic playback of
+carefully muxed MPEG-PS streams that are stored in headerless VOB files.
+To the end-user, these streams are known simply as "titles", but the actual
+logical playback sequence is defined by one or more "P

[FFmpeg-devel] [PATCH v13 2/2] libavformat/dvdvideo: add CLUT utilities and enable subtitle palette support

2024-02-11 Thread Marth64
Signed-off-by: Marth64 
---
 doc/demuxers.texi |  5 +++
 libavformat/Makefile  |  2 +-
 libavformat/dvdclut.c | 76 +++
 libavformat/dvdclut.h | 37 +++
 libavformat/dvdvideodec.c | 14 
 5 files changed, 133 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/dvdclut.c
 create mode 100644 libavformat/dvdclut.h

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 062ea2ea42..d3c7675631 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -391,6 +391,11 @@ often with junk data intended for controlling a real DVD 
player's
 buffering speed and with no other material data value.
 Default is 1, true.
 
+@item clut_rgb @var{bool}
+Output subtitle palettes (CLUTs) as RGB, required for Matroska.
+Disable to output the palette in its original YUV colorspace.
+Default is 1, true.
+
 @end table
 
 @subsection Examples
diff --git a/libavformat/Makefile b/libavformat/Makefile
index df69734877..8f17e43e49 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -192,7 +192,7 @@ OBJS-$(CONFIG_DTS_MUXER) += rawenc.o
 OBJS-$(CONFIG_DV_MUXER)  += dvenc.o
 OBJS-$(CONFIG_DVBSUB_DEMUXER)+= dvbsub.o rawdec.o
 OBJS-$(CONFIG_DVBTXT_DEMUXER)+= dvbtxt.o rawdec.o
-OBJS-$(CONFIG_DVDVIDEO_DEMUXER)  += dvdvideodec.o
+OBJS-$(CONFIG_DVDVIDEO_DEMUXER)  += dvdvideodec.o dvdclut.o
 OBJS-$(CONFIG_DXA_DEMUXER)   += dxa.o
 OBJS-$(CONFIG_EA_CDATA_DEMUXER)  += eacdata.o
 OBJS-$(CONFIG_EA_DEMUXER)+= electronicarts.o
diff --git a/libavformat/dvdclut.c b/libavformat/dvdclut.c
new file mode 100644
index 00..2125e91541
--- /dev/null
+++ b/libavformat/dvdclut.c
@@ -0,0 +1,76 @@
+/*
+ * DVD-Video subpicture CLUT (Color Lookup Table) utilities
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/bprint.h"
+#include "libavutil/colorspace.h"
+#include "libavutil/common.h"
+
+#include "dvdclut.h"
+#include "internal.h"
+
+int ff_dvdclut_palette_extradata_cat(const uint32_t *clut,
+ const size_t clut_size,
+ AVCodecParameters *par)
+{
+int ret = 0;
+AVBPrint bp;
+
+if (clut_size != FF_DVDCLUT_CLUT_SIZE)
+return AVERROR(EINVAL);
+
+av_bprint_init(&bp, 0, FF_DVDCLUT_EXTRADATA_SIZE);
+
+av_bprintf(&bp, "palette: ");
+
+for (int i = 0; i < FF_DVDCLUT_CLUT_LEN; i++)
+av_bprintf(&bp, "%06"PRIx32"%s", clut[i],
+   i != (FF_DVDCLUT_CLUT_LEN - 1) ? ", " : "");
+
+av_bprintf(&bp, "\n");
+
+return ff_bprint_to_codecpar_extradata(par, &bp);
+}
+
+int ff_dvdclut_yuv_to_rgb(uint32_t *clut, const size_t clut_size)
+{
+int y, cb, cr;
+uint8_t r, g, b;
+int r_add, g_add, b_add;
+
+if (clut_size != FF_DVDCLUT_CLUT_SIZE)
+return AVERROR(EINVAL);
+
+for (int i = 0; i < FF_DVDCLUT_CLUT_LEN; i++) {
+y  = (clut[i] >> 16) & 0xFF;
+cr = (clut[i] >> 8)  & 0xFF;
+cb = clut[i] & 0xFF;
+
+YUV_TO_RGB1_CCIR(cb, cr);
+
+y = (y - 16) * FIX(255.0 / 219.0);
+r = av_clip_uint8((y + r_add - 1024) >> SCALEBITS);
+g = av_clip_uint8((y + g_add - 1024) >> SCALEBITS);
+b = av_clip_uint8((y + b_add - 1024) >> SCALEBITS);
+
+clut[i] = (r << 16) | (g << 8) | b;
+}
+
+return 0;
+}
diff --git a/libavformat/dvdclut.h b/libavformat/dvdclut.h
new file mode 100644
index 00..41cea7e2c9
--- /dev/null
+++ b/libavformat/dvdclut.h
@@ -0,0 +1,37 @@
+/*
+ * DVD-Video subpicture CLUT (Color Lookup Table) utilities
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU 

[FFmpeg-devel] [PATCH 1/4 v10] avformat: add a Tile Grid stream group type

2024-02-11 Thread James Almer
This will be used to support tiled image formats like HEIF.

Signed-off-by: James Almer 
---
There can be more tiles than streams in the group now, which makes it possible
to parse C021.heic

 libavformat/avformat.c |   5 ++
 libavformat/avformat.h | 147 +
 libavformat/dump.c |  29 
 libavformat/options.c  |  34 ++
 4 files changed, 215 insertions(+)

diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index ca31d3dc56..f53ba4ce58 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -99,6 +99,11 @@ void ff_free_stream_group(AVStreamGroup **pstg)
 av_iamf_mix_presentation_free(&stg->params.iamf_mix_presentation);
 break;
 }
+case AV_STREAM_GROUP_PARAMS_TILE_GRID:
+av_opt_free(stg->params.tile_grid);
+av_freep(&stg->params.tile_grid->offsets);
+av_freep(&stg->params.tile_grid);
+break;
 default:
 break;
 }
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 5d0fe82250..92751e5aee 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1018,10 +1018,156 @@ typedef struct AVStream {
 int pts_wrap_bits;
 } AVStream;
 
+/**
+ * AVStreamGroupTileGrid holds information on how to combine several
+ * independent images on a single canvas for presentation.
+ *
+ * The following is an example of a simple grid with 3 rows and 4 columns:
+ *
+ * +---+---+---+---+
+ * | 0 | 1 | 2 | 3 |
+ * +---+---+---+---+
+ * | 4 | 5 | 6 | 7 |
+ * +---+---+---+---+
+ * | 8 | 9 |10 |11 |
+ * +---+---+---+---+
+ *
+ * Assuming all tiles have a dimension of 512x512, the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the first @ref AVStreamGroup.streams "stream" in the group is "0,0", the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the second @ref AVStreamGroup.streams "stream" in the group is "512,0", the
+ * @ref AVStreamGroupTileGrid.offsets "offset" of the topleft pixel of
+ * the fifth @ref AVStreamGroup.streams "stream" in the group is "0,512", the
+ * @ref AVStreamGroupTileGrid.offsets "offset", of the topleft pixel of
+ * the sixth @ref AVStreamGroup.streams "stream" in the group is "512,512",
+ * etc.
+ *
+ * The following is an example of a canvas with overlaping tiles:
+ *
+ * +---+
+ * |*  |
+ * |* 0#   |
+ * |***# 1 #   |
+ * |   #   |
+ * |   |
+ * |   |
+ * |   |
+ * +---+
+ *
+ * Assuming a canvas with size 2048x2048 and both tiles with a dimension of
+ * 512x512, a possible @ref AVStreamGroupTileGrid.offsets "offset" for the
+ * topleft pixel of the first @ref AVStreamGroup.streams "stream" in the group
+ * would be 256x256, and the @ref AVStreamGroupTileGrid.offsets "offset" for
+ * the topleft pixel of the second @ref AVStreamGroup.streams "stream" in the
+ * group would be 512x512.
+ *
+ * sizeof(AVStreamGroupTileGrid) is not a part of the ABI and may only be
+ * allocated by avformat_stream_group_create().
+ */
+typedef struct AVStreamGroupTileGrid {
+const AVClass *av_class;
+
+/**
+ * Amount of tiles in the grid.
+ *
+ * Must be > 0.
+ */
+unsigned int nb_tiles;
+
+/**
+ * Width of the canvas.
+ *
+ * Must be > 0.
+ */
+int coded_width;
+/**
+ * Width of the canvas.
+ *
+ * Must be > 0.
+ */
+int coded_height;
+
+/**
+ * An @ref nb_tiles sized array of offsets in pixels from the topleft edge
+ * of the canvas, indicating where each stream should be placed.
+ * It must be allocated with the av_malloc() family of functions.
+ *
+ * - demuxing: set by libavformat, must not be modified by the caller.
+ * - muxing: set by the caller before avformat_write_header().
+ *
+ * Freed by libavformat in avformat_free_context().
+ */
+struct {
+/**
+ * Index of the stream in the group this tile references.
+ *
+ * Must be < @ref AVStreamGroup.nb_streams "nb_streams".
+ */
+unsigned int idx;
+/**
+ * Offset in pixels from the left edge of the canvas where the tile
+ * should be placed.
+ */
+int horizontal;
+/**
+ * Offset in pixels from the top edge of the canvas where the tile
+ * should be placed.
+ */
+int vertical;
+} *offsets;
+
+/**
+ * The pixel value per channel in RGBA format used if no pixel of any tile
+ * is located at a particular pixel location.
+ *
+ * @see av_image_fill_color().
+ * @see av_parse_color().
+ */
+uint8_t background[4];
+
+/**
+ * Offset in pixels from the left edge of the canvas where the actual image
+ * meant for presentation starts.
+ *
+ * This field must be >= 0 and < @ref coded_width.
+ */
+int horizontal_offset;
+/**
+ * Offset in pixels from th

[FFmpeg-devel] [PATCH 2/4 v8] avformat/mov: add support for tile HEIF still images

2024-02-11 Thread James Almer
Export tiles as streams, and the grid information as a Stream Group of type
TILE_GRID.
This also enables exporting other stream items like thumbnails, which may be
present in non tiled HEIF images too.

Based on a patch by Swaraj Hota

Signed-off-by: James Almer 
---
 libavformat/avformat.c |   8 +
 libavformat/avformat.h |   6 +
 libavformat/dump.c |   2 +
 libavformat/internal.h |   5 +
 libavformat/isom.h |  16 +-
 libavformat/mov.c  | 492 +
 6 files changed, 484 insertions(+), 45 deletions(-)

diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index f53ba4ce58..eb898223d2 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -119,6 +119,14 @@ void ff_remove_stream(AVFormatContext *s, AVStream *st)
 ff_free_stream(&s->streams[ --s->nb_streams ]);
 }
 
+void ff_remove_stream_group(AVFormatContext *s, AVStreamGroup *stg)
+{
+av_assert0(s->nb_stream_groups > 0);
+av_assert0(s->stream_groups[ s->nb_stream_groups - 1 ] == stg);
+
+ff_free_stream_group(&s->stream_groups[ --s->nb_stream_groups ]);
+}
+
 /* XXX: suppress the packet queue */
 void ff_flush_packet_queue(AVFormatContext *s)
 {
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 92751e5aee..27b052bad5 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -811,6 +811,12 @@ typedef struct AVIndexEntry {
  * The video stream contains still images.
  */
 #define AV_DISPOSITION_STILL_IMAGE  (1 << 20)
+/**
+ * The video stream is intended to be merged with another stream before
+ * presentation.
+ * Used for example to signal the stream contains a tile from a HEIF grid.
+ */
+#define AV_DISPOSITION_TILE (1 << 21)
 
 /**
  * @return The AV_DISPOSITION_* flag corresponding to disp or a negative error
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 756db8c87e..6123ca58a5 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -657,6 +657,8 @@ static void dump_stream_format(const AVFormatContext *ic, 
int i,
 av_log(NULL, log_level, " (still image)");
 if (st->disposition & AV_DISPOSITION_NON_DIEGETIC)
 av_log(NULL, log_level, " (non-diegetic)");
+if (st->disposition & AV_DISPOSITION_TILE)
+av_log(NULL, log_level, " (tile)");
 av_log(NULL, log_level, "\n");
 
 dump_metadata(NULL, st->metadata, extra_indent, log_level);
diff --git a/libavformat/internal.h b/libavformat/internal.h
index c66f959e9f..5603ca1ab5 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -637,6 +637,11 @@ void ff_remove_stream(AVFormatContext *s, AVStream *st);
  * is not yet attached to an AVFormatContext.
  */
 void ff_free_stream_group(AVStreamGroup **pstg);
+/**
+ * Remove a stream group from its AVFormatContext and free it.
+ * The stream group must be the last stream group of the AVFormatContext.
+ */
+void ff_remove_stream_group(AVFormatContext *s, AVStreamGroup *stg);
 
 unsigned int ff_codec_get_tag(const AVCodecTag *tags, enum AVCodecID id);
 
diff --git a/libavformat/isom.h b/libavformat/isom.h
index a4cca4c798..d96722fe79 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -267,15 +267,25 @@ typedef struct MOVStreamContext {
 
 typedef struct HEIFItem {
 AVStream *st;
+char *name;
 int item_id;
 int64_t extent_length;
 int64_t extent_offset;
-int64_t size;
+int tile_rows;
+int tile_cols;
 int width;
 int height;
 int type;
+int is_idat_relative;
 } HEIFItem;
 
+typedef struct HEIFGrid {
+HEIFItem *item;
+unsigned int *tile_idx_list;
+int16_t *tile_id_list;
+int nb_tiles;
+} HEIFGrid;
+
 typedef struct MOVContext {
 const AVClass *class; ///< class for private options
 AVFormatContext *fc;
@@ -339,6 +349,10 @@ typedef struct MOVContext {
 int cur_item_id;
 HEIFItem *heif_item;
 int nb_heif_item;
+HEIFGrid *heif_grid;
+int nb_heif_grid;
+int thmb_item_id;
+int64_t idat_offset;
 int interleaved_read;
 } MOVContext;
 
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 42b0135987..23343c7ae2 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -185,6 +185,30 @@ static int mov_read_mac_string(MOVContext *c, AVIOContext 
*pb, int len,
 return p - dst;
 }
 
+static AVStream *get_curr_st(MOVContext *c)
+{
+AVStream *st = NULL;
+
+if (c->fc->nb_streams < 1)
+return NULL;
+
+for (int i = 0; i < c->nb_heif_item; i++) {
+HEIFItem *item = &c->heif_item[i];
+
+if (!item->st)
+continue;
+if (item->st->id != c->cur_item_id)
+continue;
+
+st = item->st;
+break;
+}
+if (!st)
+st = c->fc->streams[c->fc->nb_streams-1];
+
+return st;
+}
+
 static int mov_read_covr(MOVContext *c, AVIOContext *pb, int type, int len)
 {
 AVStream *st;
@@ -1767,9 +1791,9 @@ static int mov_read_colr(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 uint16_t color_primaries, 

[FFmpeg-devel] [PATCH 3/4 v7] fate/mov: test remuxing all stream heif items

2024-02-11 Thread James Almer
Signed-off-by: James Almer 
---
 tests/fate/mov.mak   | 2 +-
 tests/ref/fate/mov-heic-demux-still-image-multiple-items | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 4850c8aa94..1be7a0d15a 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -161,7 +161,7 @@ fate-mov-heic-demux-still-image-1-item: CMD = framemd5 -i 
$(TARGET_SAMPLES)/heif
 
 FATE_MOV_FFMPEG-$(call FRAMEMD5, MOV, HEVC, HEVC_PARSER) \
+= fate-mov-heic-demux-still-image-multiple-items
-fate-mov-heic-demux-still-image-multiple-items: CMD = framemd5 -i 
$(TARGET_SAMPLES)/heif-conformance/C003.heic -c:v copy
+fate-mov-heic-demux-still-image-multiple-items: CMD = framemd5 -i 
$(TARGET_SAMPLES)/heif-conformance/C003.heic -c:v copy -map 0
 
 # Resulting remux should have:
 # 1. first audio stream with AV_DISPOSITION_HEARING_IMPAIRED
diff --git a/tests/ref/fate/mov-heic-demux-still-image-multiple-items 
b/tests/ref/fate/mov-heic-demux-still-image-multiple-items
index c850c1ff9c..753cef267a 100644
--- a/tests/ref/fate/mov-heic-demux-still-image-multiple-items
+++ b/tests/ref/fate/mov-heic-demux-still-image-multiple-items
@@ -2,10 +2,17 @@
 #version: 2
 #hash: MD5
 #extradata 0, 100, 5444bf01e03182c73ae957179d560f4d
+#extradata 1, 100, 5444bf01e03182c73ae957179d560f4d
 #tb 0: 1/1
 #media_type 0: video
 #codec_id 0: hevc
 #dimensions 0: 1280x720
 #sar 0: 0/1
+#tb 1: 1/1
+#media_type 1: video
+#codec_id 1: hevc
+#dimensions 1: 1280x720
+#sar 1: 0/1
 #stream#, dts,pts, duration, size, hash
 0,  0,  0,1,   111554, 03ceabfab39afd2e2e796b9362111f32
+1,  0,  0,1,   112393, daa001d351c088a5bc328459e2501c95
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 4/4 v2] fate/mov: add tests for HEIF samples with derived images

2024-02-11 Thread James Almer
Signed-off-by: James Almer 
---
 tests/fate/mov.mak|  8 +
 .../ref/fate/mov-heic-demux-still-image-grid  | 32 +++
 .../ref/fate/mov-heic-demux-still-image-iovl  | 18 +++
 3 files changed, 58 insertions(+)
 create mode 100644 tests/ref/fate/mov-heic-demux-still-image-grid
 create mode 100644 tests/ref/fate/mov-heic-demux-still-image-iovl

diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
index 1be7a0d15a..a8206a1b58 100644
--- a/tests/fate/mov.mak
+++ b/tests/fate/mov.mak
@@ -163,6 +163,14 @@ FATE_MOV_FFMPEG-$(call FRAMEMD5, MOV, HEVC, HEVC_PARSER) \
+= fate-mov-heic-demux-still-image-multiple-items
 fate-mov-heic-demux-still-image-multiple-items: CMD = framemd5 -i 
$(TARGET_SAMPLES)/heif-conformance/C003.heic -c:v copy -map 0
 
+FATE_MOV_FFMPEG-$(call FRAMEMD5, MOV, HEVC, HEVC_PARSER) \
+   += fate-mov-heic-demux-still-image-grid
+fate-mov-heic-demux-still-image-grid: CMD = framemd5 -i 
$(TARGET_SAMPLES)/heif-conformance/C007.heic -c:v copy -map 0:g:0
+
+FATE_MOV_FFMPEG-$(call FRAMEMD5, MOV, HEVC, HEVC_PARSER) \
+   += fate-mov-heic-demux-still-image-iovl
+fate-mov-heic-demux-still-image-iovl: CMD = framemd5 -i 
$(TARGET_SAMPLES)/heif-conformance/C015.heic -c:v copy -map 0:g:0
+
 # Resulting remux should have:
 # 1. first audio stream with AV_DISPOSITION_HEARING_IMPAIRED
 # 2. second audio stream with AV_DISPOSITION_VISUAL_IMPAIRED | DESCRIPTIONS
diff --git a/tests/ref/fate/mov-heic-demux-still-image-grid 
b/tests/ref/fate/mov-heic-demux-still-image-grid
new file mode 100644
index 00..6fde8fff28
--- /dev/null
+++ b/tests/ref/fate/mov-heic-demux-still-image-grid
@@ -0,0 +1,32 @@
+#format: frame checksums
+#version: 2
+#hash: MD5
+#extradata 0, 100, 5444bf01e03182c73ae957179d560f4d
+#extradata 1, 100, 5444bf01e03182c73ae957179d560f4d
+#extradata 2, 100, 5444bf01e03182c73ae957179d560f4d
+#extradata 3, 100, 5444bf01e03182c73ae957179d560f4d
+#tb 0: 1/1
+#media_type 0: video
+#codec_id 0: hevc
+#dimensions 0: 1280x720
+#sar 0: 0/1
+#tb 1: 1/1
+#media_type 1: video
+#codec_id 1: hevc
+#dimensions 1: 1280x720
+#sar 1: 0/1
+#tb 2: 1/1
+#media_type 2: video
+#codec_id 2: hevc
+#dimensions 2: 1280x720
+#sar 2: 0/1
+#tb 3: 1/1
+#media_type 3: video
+#codec_id 3: hevc
+#dimensions 3: 1280x720
+#sar 3: 0/1
+#stream#, dts,pts, duration, size, hash
+0,  0,  0,1,   111554, 03ceabfab39afd2e2e796b9362111f32
+1,  0,  0,1,   111481, e5db978adbe4de7ee50fe73abc39fcfa
+2,  0,  0,1,   111451, 08700213113cadbb6628ecb8253c1c2a
+3,  0,  0,1,   111353, 5de942e14c848e5e22fad5d88fb13776
diff --git a/tests/ref/fate/mov-heic-demux-still-image-iovl 
b/tests/ref/fate/mov-heic-demux-still-image-iovl
new file mode 100644
index 00..753cef267a
--- /dev/null
+++ b/tests/ref/fate/mov-heic-demux-still-image-iovl
@@ -0,0 +1,18 @@
+#format: frame checksums
+#version: 2
+#hash: MD5
+#extradata 0, 100, 5444bf01e03182c73ae957179d560f4d
+#extradata 1, 100, 5444bf01e03182c73ae957179d560f4d
+#tb 0: 1/1
+#media_type 0: video
+#codec_id 0: hevc
+#dimensions 0: 1280x720
+#sar 0: 0/1
+#tb 1: 1/1
+#media_type 1: video
+#codec_id 1: hevc
+#dimensions 1: 1280x720
+#sar 1: 0/1
+#stream#, dts,pts, duration, size, hash
+0,  0,  0,1,   111554, 03ceabfab39afd2e2e796b9362111f32
+1,  0,  0,1,   112393, daa001d351c088a5bc328459e2501c95
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] Fw: GSoC Org Apps - review yours ASAP for common issues

2024-02-11 Thread Michael Niedermayer
Hi all

just got this today, and to avoid anyone being upset of not knowing
about something again.

I dont know if this applies to us but posting it here
Also iam not doing gsoc admin (iam just really the last resort backup
i dont have time for gsoc) but it seemes
someone fillled everything out already i saw some "100%"
in the brief moments between "Something went wrong." and "400 errors"

thx

- Forwarded message from summerofcode-nore...@google.com -

Date: Sun, 11 Feb 2024 10:36:02 -0800
From: summerofcode-nore...@google.com
To: mich...@niedermayer.cc
Subject: GSoC Org Apps - review yours ASAP for common issues

Google Summer of Code


We are sending this email to all Org Admins of Orgs that applied to GSoC 2024.

This year we have noticed a large number of org apps are missing required 
information or having issues with project sizes. Please review your org app for 
these common mistakes that could result in your org app being rejected.


Project sizes need to be scoped to 90, 175 or 350 hours (you can not have a 
project that is 200 hours, or some other random number of hours).
Make sure your Project Ideas list is public so GSoC Google reviewers can access 
it.
Make sure your Project Ideas include the ALL of the required information below:

a) a project title/description b) more detailed description of the project (2-5 
sentences) c) expected outcomes d) skills required/preferred e) possible 
mentors f) expected size of project (90, 175 or 350 hour – yes, 3 options 
starting in 2024). And if possible, an easy, intermediate or hard/difficult 
rating of each project. This helps the more inexperienced folks not get 
overwhelmed and they can focus on reviewing easy project ideas.

You should already have your ideas list mostly complete. While it is okay to 
continue to add Project Ideas you should not have an empty project ideas list 
as Google Admins are reviewing these applications (and have been for the last 
5+ days) and we need to see ideas posted to be able to consider your 
application.

Thanks, we look forward to sending out the notifications of project acceptance 
Tuesday, February 20th. This is 1 day before we announce the accepted orgs 
publicly to give orgs a chance to organize their mentors before the GSoC 
contributors start actively reaching out to orgs.

Best,
Stephanie Taylor
GSoC Program Lead

https://summerofcode.withgoogle.com

For any questions, please contact gsoc-supp...@google.com. Replies to this 
message go to an unmonitored mailbox.

© 2024 Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA

- End forwarded message -

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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] fate-suite.ffmpeg.org is very slow

2024-02-11 Thread Kieran Kunhya
Hello,

I would like to know if fate-suite.ffmpeg.org is very slow to sync for
anyone else?

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] all: use designated initializers for AVOption.unit

2024-02-11 Thread Michael Niedermayer
On Sun, Feb 11, 2024 at 06:08:28PM +0100, Anton Khirnov wrote:
> Makes it robust against adding fields before it, which will be useful in
> following commits.
> 
> Majority of the patch generated by the following Coccinelle script:
> 
> @@
> typedef AVOption;
> identifier arr_name;
> initializer list il;
> initializer list[8] il1;
> expression tail;
> @@
> AVOption arr_name[] = { il, { il1,
> - tail
> + .unit = tail
> }, ...  };
> 
> with some manual changes, as the script:
> * has trouble with options defined inside macros
> * sometimes does not handle options under an #else branch
> * sometimes swallows whitespace
> ---
>  fftools/ffmpeg_mux_init.c  |   2 +-
>  libavcodec/aacdec_template.c   |  16 +-
>  libavcodec/aacenc.c|   8 +-
>  libavcodec/ac3dec_float.c  |   2 +-
>  libavcodec/ac3enc.c|  58 +--
>  libavcodec/amfenc_av1.c| 154 
>  libavcodec/amfenc_h264.c   | 150 +++
>  libavcodec/amfenc_hevc.c   | 136 +++
>  libavcodec/apedec.c|   4 +-
>  libavcodec/audiotoolboxenc.c   |  12 +-
>  libavcodec/avdct.c |  44 +--
>  libavcodec/bsf/av1_metadata.c  |   4 +-
>  libavcodec/bsf/dump_extradata.c|   2 +-
>  libavcodec/bsf/dv_error_marker.c   |  38 +-
>  libavcodec/bsf/filter_units.c  |  20 +-
>  libavcodec/bsf/h264_metadata.c |   4 +-
>  libavcodec/bsf/h265_metadata.c |   2 +-
>  libavcodec/bsf/hapqa_extract.c |   6 +-
>  libavcodec/bsf/prores_metadata.c   |  42 +-
>  libavcodec/bsf/remove_extradata.c  |   2 +-
>  libavcodec/bsf/vp9_metadata.c  |   4 +-
>  libavcodec/cbs_bsf.h   |   4 +-
>  libavcodec/ccaption_dec.c  |   8 +-
>  libavcodec/cfhdenc.c   |  28 +-
>  libavcodec/cuviddec.c  |   8 +-
>  libavcodec/dcadec.c|   6 +-
>  libavcodec/dnxhdenc.c  |  14 +-
>  libavcodec/dolby_e.c   |   8 +-
>  libavcodec/dxvenc.c|   4 +-
>  libavcodec/exr.c   |  34 +-
>  libavcodec/exrenc.c|  16 +-
>  libavcodec/ffv1enc.c   |  10 +-
>  libavcodec/flacenc.c   |  36 +-
>  libavcodec/gif.c   |   6 +-
>  libavcodec/hapenc.c|  14 +-
>  libavcodec/huffyuvenc.c|   8 +-
>  libavcodec/j2kenc.c|  24 +-
>  libavcodec/jpeglsenc.c |   8 +-
>  libavcodec/libaomenc.c |  28 +-
>  libavcodec/libaribb24.c|   6 +-
>  libavcodec/libaribcaption.c|   4 +-
>  libavcodec/libfdk-aacdec.c |  20 +-
>  libavcodec/libfdk-aacenc.c |  10 +-
>  libavcodec/libopenh264enc.c|  28 +-
>  libavcodec/libopenjpegenc.c|  36 +-
>  libavcodec/libopusenc.c|  18 +-
>  libavcodec/libsvtav1.c |  14 +-
>  libavcodec/libtwolame.c|  12 +-
>  libavcodec/libvpxenc.c |  60 +--
>  libavcodec/libwebpenc_common.c |  16 +-
>  libavcodec/libx264.c   |  70 ++--
>  libavcodec/libxavs.c   |  22 +-
>  libavcodec/libxeve.c   |  34 +-
>  libavcodec/libxvid.c   |   8 +-
>  libavcodec/libzvbi-teletextdec.c   |   8 +-
>  libavcodec/ljpegenc.c  |   8 +-
>  libavcodec/magicyuvenc.c   |   8 +-
>  libavcodec/mediacodecenc.c | 226 +--
>  libavcodec/mfenc.c |  34 +-
>  libavcodec/mjpegenc.c  |   6 +-
>  libavcodec/mlpenc.c|  12 +-
>  libavcodec/mpeg12enc.c |  24 +-
>  libavcodec/mpegvideoenc.h  |  54 +--
>  libavcodec/nvenc_av1.c | 142 +++
>  libavcodec/nvenc_h264.c| 208 +-
>  libavcodec/nvenc_hevc.c| 182 -
>  libavcodec/omx.c   |   8 +-
>  libavcodec/options.c   |   2 +-
>  libavcodec/options_table.h | 526 -
>  libavcodec/opusenc.c   |   4 +-
>  libavcodec/pngenc.c|  14 +-
>  libavcodec/profiles.h  |   2 +-
>  libavcodec/proresenc_kostya.c  |  30 +-
>  libavcodec/qsvdec.c|  24 +-
>  libavcodec/qsvenc.h|  54 +--
>  libavcodec/qsvenc_av1.c|   6 +-
>  libavcodec/qsvenc_h264.c   |  38 +-
>  libavcodec/qsvenc_hevc.c   |  42 +-
>  libavcodec/qsvenc_mpeg2.c  |  10 +-
>  libavcodec/qsvenc_vp9.c|  12 +-
>  libavcodec/s302m.c |  10 +-
>  libavcodec/snowenc.c   |  16 +-
>  libavcodec/svq1enc.c   |   8 +-
>  libavcodec/tiffenc.c   |  10 +-
>  libavco

Re: [FFmpeg-devel] [PATCH 2/4 v8] avformat/mov: add support for tile HEIF still images

2024-02-11 Thread Michael Niedermayer
On Sun, Feb 11, 2024 at 03:56:59PM -0300, James Almer wrote:
> Export tiles as streams, and the grid information as a Stream Group of type
> TILE_GRID.
> This also enables exporting other stream items like thumbnails, which may be
> present in non tiled HEIF images too.
> 
> Based on a patch by Swaraj Hota
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/avformat.c |   8 +
>  libavformat/avformat.h |   6 +
>  libavformat/dump.c |   2 +
>  libavformat/internal.h |   5 +
>  libavformat/isom.h |  16 +-
>  libavformat/mov.c  | 492 +
>  6 files changed, 484 insertions(+), 45 deletions(-)

git dislikes this:

git am -3

Applying: avformat/mov: add support for tile HEIF still images
error: sha1 information is lacking or useless (libavformat/avformat.c).
error: could not build fake ancestor
Patch failed at 0001 avformat/mov: add support for tile HEIF still images
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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] avfilter/vf_setparams: use YUV colorspace negotiation API

2024-02-11 Thread Niklas Haas
On Sat, 10 Feb 2024 11:56:29 +0100 Niklas Haas  wrote:
> From: Niklas Haas 
> 
> When this filter overrides frame properties, the outgoing frames have
> a different YUV colorspace than the incoming ones. This requires
> signalling the new colorspace on the outlink, and in particular, making
> sure it's *not* set to a common ref with the input - otherwise the point
> of this filter would be destroyed.
> 
> Untouched fields will continue being passed through, so we don't need to
> do anything there.
> ---
>  libavfilter/vf_setparams.c | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/libavfilter/vf_setparams.c b/libavfilter/vf_setparams.c
> index ae4c937518..a33c35a942 100644
> --- a/libavfilter/vf_setparams.c
> +++ b/libavfilter/vf_setparams.c
> @@ -23,6 +23,7 @@
>  #include "libavutil/pixfmt.h"
>  #include "libavutil/opt.h"
>  #include "avfilter.h"
> +#include "formats.h"
>  #include "internal.h"
>  #include "video.h"
>  
> @@ -120,6 +121,29 @@ static const AVOption setparams_options[] = {
>  
>  AVFILTER_DEFINE_CLASS(setparams);
>  
> +static int query_formats(AVFilterContext *ctx)
> +{
> +SetParamsContext *s = ctx->priv;
> +AVFilterLink *outlink = ctx->outputs[0];
> +int ret;
> +
> +if (s->colorspace >= 0) {
> +ret = ff_formats_ref(ff_make_formats_list_singleton(s->colorspace),
> + &outlink->incfg.color_spaces);
> +if (ret < 0)
> +return ret;
> +}
> +
> +if (s->color_range >= 0) {
> +ret = ff_formats_ref(ff_make_formats_list_singleton(s->color_range),
> + &outlink->incfg.color_ranges);
> +if (ret < 0)
> +return ret;
> +}
> +
> +return 0;
> +}
> +
>  static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
>  {
>  AVFilterContext *ctx = inlink->dst;
> @@ -177,6 +201,7 @@ const AVFilter ff_vf_setparams = {
>  .flags   = AVFILTER_FLAG_METADATA_ONLY,
>  FILTER_INPUTS(inputs),
>  FILTER_OUTPUTS(ff_video_default_filterpad),
> +FILTER_QUERY_FUNC(query_formats),
>  };
>  
>  #if CONFIG_SETRANGE_FILTER
> @@ -217,6 +242,7 @@ const AVFilter ff_vf_setrange = {
>  .flags   = AVFILTER_FLAG_METADATA_ONLY,
>  FILTER_INPUTS(inputs),
>  FILTER_OUTPUTS(ff_video_default_filterpad),
> +FILTER_QUERY_FUNC(query_formats),
>  };
>  #endif /* CONFIG_SETRANGE_FILTER */

Will merge rather soon without objection, as this prevents vf_setparams
from working correctly.
___
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] vp6dsp: Remove MMX code

2024-02-11 Thread Kieran Kunhya
$subj


0001-vp6dsp-Remove-MMX-code.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/2] avfilter/buffersrc: promote unspecified color metadata

2024-02-11 Thread Niklas Haas
Ping, last call for objections.
___
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] h264_intrapred: Remove ff_pred16x16_horizontal_8_mmxext

2024-02-11 Thread Kieran Kunhya
$subj


0001-h264_intrapred-Remove-ff_pred16x16_horizontal_8_mmxe.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 2/4 v8] avformat/mov: add support for tile HEIF still images

2024-02-11 Thread James Almer

On 2/11/2024 5:41 PM, Michael Niedermayer wrote:

On Sun, Feb 11, 2024 at 03:56:59PM -0300, James Almer wrote:

Export tiles as streams, and the grid information as a Stream Group of type
TILE_GRID.
This also enables exporting other stream items like thumbnails, which may be
present in non tiled HEIF images too.

Based on a patch by Swaraj Hota

Signed-off-by: James Almer 
---
  libavformat/avformat.c |   8 +
  libavformat/avformat.h |   6 +
  libavformat/dump.c |   2 +
  libavformat/internal.h |   5 +
  libavformat/isom.h |  16 +-
  libavformat/mov.c  | 492 +
  6 files changed, 484 insertions(+), 45 deletions(-)


git dislikes this:

git am -3

Applying: avformat/mov: add support for tile HEIF still images
error: sha1 information is lacking or useless (libavformat/avformat.c).
error: could not build fake ancestor
Patch failed at 0001 avformat/mov: add support for tile HEIF still images
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


I can't reproduce this. Tried to apply the patches as sent to the ml and 
they still apply.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 2/4 v8] avformat/mov: add support for tile HEIF still images

2024-02-11 Thread James Almer

On 2/11/2024 6:08 PM, James Almer wrote:

On 2/11/2024 5:41 PM, Michael Niedermayer wrote:

On Sun, Feb 11, 2024 at 03:56:59PM -0300, James Almer wrote:
Export tiles as streams, and the grid information as a Stream Group 
of type

TILE_GRID.
This also enables exporting other stream items like thumbnails, which 
may be

present in non tiled HEIF images too.

Based on a patch by Swaraj Hota

Signed-off-by: James Almer 
---
  libavformat/avformat.c |   8 +
  libavformat/avformat.h |   6 +
  libavformat/dump.c |   2 +
  libavformat/internal.h |   5 +
  libavformat/isom.h |  16 +-
  libavformat/mov.c  | 492 +
  6 files changed, 484 insertions(+), 45 deletions(-)


git dislikes this:

git am -3

Applying: avformat/mov: add support for tile HEIF still images
error: sha1 information is lacking or useless (libavformat/avformat.c).
error: could not build fake ancestor
Patch failed at 0001 avformat/mov: add support for tile HEIF still images
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


I can't reproduce this. Tried to apply the patches as sent to the ml and 
they still apply.


https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=10765 shows no 
issues.
I also pushed it to https://github.com/jamrial/FFmpeg/commits/heif_new/ 
so you can test it.

___
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] h264_intrapred: Remove ff_pred16x16_horizontal_8_mmxext

2024-02-11 Thread Kieran Kunhya
$subj, now with forward declaration also removed.


0001-h264_intrapred-Remove-ff_pred16x16_horizontal_8_mmxe.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] h264_intrapred: Remove ff_pred16x16_horizontal_8_mmxext

2024-02-11 Thread James Almer

On 2/11/2024 6:24 PM, Kieran Kunhya wrote:

$subj, now with forward declaration also removed.


This function is trivial to convert to SSE2, so better do that than 
removing it. Attached.
If other functions are harder to port to SSE2, then sure, they can be 
removed.From fdf1db323c1209fcb927f7df0d041d78f6214bf7 Mon Sep 17 00:00:00 2001
From: James Almer 
Date: Sun, 11 Feb 2024 18:35:31 -0300
Subject: [PATCH] x86/h264_intrapred: convert ff_pred16x16_horizontal_8_mmxext
 to sse2

Signed-off-by: James Almer 
---
 libavcodec/x86/h264_intrapred.asm| 4 +---
 libavcodec/x86/h264_intrapred_init.c | 4 ++--
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/libavcodec/x86/h264_intrapred.asm 
b/libavcodec/x86/h264_intrapred.asm
index 8a38ba2bb5..49a63f900e 100644
--- a/libavcodec/x86/h264_intrapred.asm
+++ b/libavcodec/x86/h264_intrapred.asm
@@ -86,8 +86,6 @@ cglobal pred16x16_horizontal_8, 2,3
 punpcklbw m1, m1
 SPLATWm0, m0, 3
 SPLATWm1, m1, 3
-mova [r0+r1*0+8], m0
-mova [r0+r1*1+8], m1
 %endif
 
 mova [r0+r1*0], m0
@@ -98,7 +96,7 @@ cglobal pred16x16_horizontal_8, 2,3
 RET
 %endmacro
 
-INIT_MMX mmxext
+INIT_XMM sse2
 PRED16x16_H
 INIT_XMM ssse3
 PRED16x16_H
diff --git a/libavcodec/x86/h264_intrapred_init.c 
b/libavcodec/x86/h264_intrapred_init.c
index ee46927a24..06cb0ea8fe 100644
--- a/libavcodec/x86/h264_intrapred_init.c
+++ b/libavcodec/x86/h264_intrapred_init.c
@@ -100,7 +100,7 @@ PRED16x16(horizontal, 10, sse2)
 
 /* 8-bit versions */
 PRED16x16(vertical, 8, sse)
-PRED16x16(horizontal, 8, mmxext)
+PRED16x16(horizontal, 8, sse2)
 PRED16x16(horizontal, 8, ssse3)
 PRED16x16(dc, 8, sse2)
 PRED16x16(dc, 8, ssse3)
@@ -170,7 +170,6 @@ av_cold void ff_h264_pred_init_x86(H264PredContext *h, int 
codec_id,
 }
 
 if (EXTERNAL_MMXEXT(cpu_flags)) {
-h->pred16x16[HOR_PRED8x8] = 
ff_pred16x16_horizontal_8_mmxext;
 if (chroma_format_idc <= 1)
 h->pred8x8[HOR_PRED8x8  ] = 
ff_pred8x8_horizontal_8_mmxext;
 h->pred8x8l [TOP_DC_PRED] = 
ff_pred8x8l_top_dc_8_mmxext;
@@ -210,6 +209,7 @@ av_cold void ff_h264_pred_init_x86(H264PredContext *h, int 
codec_id,
 }
 
 if (EXTERNAL_SSE2(cpu_flags)) {
+h->pred16x16[HOR_PRED8x8  ] = 
ff_pred16x16_horizontal_8_sse2;
 h->pred16x16[DC_PRED8x8   ] = ff_pred16x16_dc_8_sse2;
 h->pred8x8l [DIAG_DOWN_LEFT_PRED  ] = ff_pred8x8l_down_left_8_sse2;
 h->pred8x8l [DIAG_DOWN_RIGHT_PRED ] = 
ff_pred8x8l_down_right_8_sse2;
-- 
2.43.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] avcodec/hevcdsp: Offset ff_hevc_.pel_filters to simplify addressing

2024-02-11 Thread Christophe Gisquet
Le dim. 11 févr. 2024 à 12:37, Nuo Mi  a écrit :
> > -DECLARE_ALIGNED(16, const int8_t, ff_hevc_qpel_filters)[3][16] = {
> > +DECLARE_ALIGNED(16, const int8_t, ff_hevc_qpel_filters)[4][16] = {
> >
> Do you know why this is [4][16]? [4][8] should suffice.

Probably so that all coefficient banks are aligned. Another use for it
is you can directly use the address in some instruction instead of
using/wasting a reg for holding the data.

-- 
Christophe Gisquet
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 2/4 v8] avformat/mov: add support for tile HEIF still images

2024-02-11 Thread Michael Niedermayer
On Sun, Feb 11, 2024 at 06:10:06PM -0300, James Almer wrote:
> On 2/11/2024 6:08 PM, James Almer wrote:
> > On 2/11/2024 5:41 PM, Michael Niedermayer wrote:
> > > On Sun, Feb 11, 2024 at 03:56:59PM -0300, James Almer wrote:
> > > > Export tiles as streams, and the grid information as a Stream
> > > > Group of type
> > > > TILE_GRID.
> > > > This also enables exporting other stream items like thumbnails,
> > > > which may be
> > > > present in non tiled HEIF images too.
> > > > 
> > > > Based on a patch by Swaraj Hota
> > > > 
> > > > Signed-off-by: James Almer 
> > > > ---
> > > >   libavformat/avformat.c |   8 +
> > > >   libavformat/avformat.h |   6 +
> > > >   libavformat/dump.c |   2 +
> > > >   libavformat/internal.h |   5 +
> > > >   libavformat/isom.h |  16 +-
> > > >   libavformat/mov.c  | 492 +
> > > >   6 files changed, 484 insertions(+), 45 deletions(-)
> > > 
> > > git dislikes this:
> > > 
> > > git am -3
> > > 
> > > Applying: avformat/mov: add support for tile HEIF still images
> > > error: sha1 information is lacking or useless (libavformat/avformat.c).
> > > error: could not build fake ancestor
> > > Patch failed at 0001 avformat/mov: add support for tile HEIF still images
> > > Use 'git am --show-current-patch' to see the failed patch
> > > When you have resolved this problem, run "git am --continue".
> > > If you prefer to skip this patch, run "git am --skip" instead.
> > > To restore the original branch and stop patching, run "git am --abort".
> > 
> > I can't reproduce this. Tried to apply the patches as sent to the ml and
> > they still apply.
> 
> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=10765 shows no
> issues.
> I also pushed it to https://github.com/jamrial/FFmpeg/commits/heif_new/ so
> you can test it.

It seems this was caused by prior applied patches

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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] h264_intrapred: Remove ff_pred16x16_horizontal_8_mmxext

2024-02-11 Thread Kieran Kunhya
On Sun, 11 Feb 2024 at 21:36, James Almer  wrote:

> On 2/11/2024 6:24 PM, Kieran Kunhya wrote:
> > $subj, now with forward declaration also removed.
>
> This function is trivial to convert to SSE2, so better do that than
> removing it. Attached.
> If other functions are harder to port to SSE2, then sure, they can be
> removed.___
>
>
Thanks, applied. One down, couple dozen to go.

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] h264_intrapred: Remove ff_pred16x16_horizontal_8_mmxext

2024-02-11 Thread Andreas Rheinhardt
James Almer:
> On 2/11/2024 6:24 PM, Kieran Kunhya wrote:
>> $subj, now with forward declaration also removed.
> 
> This function is trivial to convert to SSE2, so better do that than
> removing it. Attached.
> If other functions are harder to port to SSE2, then sure, they can be
> removed.
> 

Benchmarks?

- Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v2 4/5] avutil/channel_layout: add av_channel_layout_retype()

2024-02-11 Thread Marton Balint




On Fri, 9 Feb 2024, Anton Khirnov wrote:


Quoting Marton Balint (2024-02-04 20:28:11)

+/**
+ * Change the AVChannelOrder of a channel layout.
+ *
+ * Change of AVChannelOrder can be either lossless or lossy. In case of a
+ * lossless conversion all the channel designations and the associated channel
+ * names (if any) are kept. On a lossy conversion the channel names and channel
+ * designations might be lost depending on the capabilities of the desired
+ * AVChannelOrder. Note that some conversions are simply not possible in which
+ * case this function returns AVERROR(ENOSYS).
+ *
+ * The following conversions are supported:
+ *
+ * Any   -> Custom : Always possible, always lossless.
+ * Any   -> Unspecified: Always possible, lossless if channel designations
+ *   are all unknown and channel names are not used, lossy otherwise.
+ * Custom-> Ambisonic  : Possible if it contains ambisonic channels with
+ *   optional non-diegetic channels in the end. Lossy if the channels have
+ *   custom names, lossless otherwise.
+ * Custom-> Native : Possible if it contains native channels in native
+ * order. Lossy if the channels have custom names, lossless otherwise.
+ *
+ * On error this function keeps the original channel layout untouched.
+ *
+ * @param channel_layout channel layout which will be changed
+ * @param order the desired channel layout order
+ * @param flags a combination of AV_CHANNEL_LAYOUT_RETYPE_FLAG_* constants
+ * @return 0 if the conversion was successful and lossless or if the channel
+ *   layout was already in the desired order
+ * 1 if the conversion was successful but lossy


You could say 'positive number' instead of 1, which leaves us wiggle
room to use other numbers in the future in a backwards compatible way.

Looks ok otherwise.


Ok, thanks, will apply the series with that change.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] h264_intrapred: Remove ff_pred16x16_horizontal_8_mmxext

2024-02-11 Thread Kieran Kunhya
On Sun, 11 Feb 2024 at 22:33, Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> James Almer:
> > On 2/11/2024 6:24 PM, Kieran Kunhya wrote:
> >> $subj, now with forward declaration also removed.
> >
> > This function is trivial to convert to SSE2, so better do that than
> > removing it. Attached.
> > If other functions are harder to port to SSE2, then sure, they can be
> > removed.
> >
>
> Benchmarks?
>
> - Andreas
>

For me on Haswell x64:

pred16x16_horizontal_8_c: 41.5
pred16x16_horizontal_8_sse2: 32.5
pred16x16_horizontal_8_ssse3: 9.0

pred16x16_horizontal_8_c: 43.5
pred16x16_horizontal_8_mmxext: 20.7
pred16x16_horizontal_8_ssse3: 12.2

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] h264_intrapred: Remove ff_pred16x16_horizontal_8_mmxext

2024-02-11 Thread James Almer

On 2/11/2024 7:34 PM, Andreas Rheinhardt wrote:

James Almer:

On 2/11/2024 6:24 PM, Kieran Kunhya wrote:

$subj, now with forward declaration also removed.


This function is trivial to convert to SSE2, so better do that than
removing it. Attached.
If other functions are harder to port to SSE2, then sure, they can be
removed.



Benchmarks?

- Andreas


On an Alder Lake i get

pred16x16_horizontal_8_c: 26.5

pred16x16_horizontal_8_mmxext: 24.8
pred16x16_horizontal_8_sse2: 20.0

pred16x16_horizontal_8_ssse3: 12.5
___
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] x86/h264_pred: Convert ff_pred8x8_vertical_8_mmx to ff_pred8x8_vertical_8_sse2

2024-02-11 Thread Kieran Kunhya
$subj


0001-x86-h264_pred-Convert-ff_pred8x8_vertical_8_mmx-to-f.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v2 4/5] avutil/channel_layout: add av_channel_layout_retype()

2024-02-11 Thread James Almer

On 2/4/2024 4:28 PM, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
  doc/APIchanges |   3 ++
  libavutil/channel_layout.c | 106 +
  libavutil/channel_layout.h |  40 ++
  libavutil/version.h|   2 +-
  4 files changed, 150 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index cdb9b6a458..221fea30c2 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
  
  API changes, most recent first:
  
+2024-02-xx - xx - lavu 58.38.100 - channel_layout.h

+  Add av_channel_layout_retype().


Can you please add tests for it in tests/channel_layout.c?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 2/2] avfilter/signature_lookup: Do not dereference NULL pointers after malloc failure

2024-02-11 Thread Michael Niedermayer
On Mon, Feb 05, 2024 at 12:44:59PM +0100, Michael Niedermayer wrote:
> Fixes: CID 1403229 Dereference after null check
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavfilter/signature_lookup.c | 6 ++
>  1 file changed, 6 insertions(+)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH v2 3/3] lavc/dxv: remove ctx fields that can be derived from texdsp ctxs

2024-02-11 Thread Connor Worley
On Sun, Feb 11, 2024 at 9:41 AM James Almer  wrote:

> On 2/11/2024 9:41 AM, Connor Worley wrote:
> > "or less than" is wrong -- rather tex_step seems to have been larger than
> > necessary in some cases. With the minimal tex_step in those cases, the
> new
> > tex_size should be equal to the LHS.
>
> This set broke fate when using slice threading:
>
> https://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-threads-misc&time=20240211015448


Thanks, I will investigate.

-- 
Connor Worley
___
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 4/5] avutil/channel_layout: add av_channel_layout_retype()

2024-02-11 Thread Marton Balint




On Sun, 11 Feb 2024, James Almer wrote:


On 2/4/2024 4:28 PM, Marton Balint wrote:

 Signed-off-by: Marton Balint 
 ---
   doc/APIchanges |   3 ++
   libavutil/channel_layout.c | 106 +
   libavutil/channel_layout.h |  40 ++
   libavutil/version.h|   2 +-
   4 files changed, 150 insertions(+), 1 deletion(-)

 diff --git a/doc/APIchanges b/doc/APIchanges
 index cdb9b6a458..221fea30c2 100644
 --- a/doc/APIchanges
 +++ b/doc/APIchanges
 @@ -2,6 +2,9 @@ The last version increases of all libraries were on
 2023-02-09

   API changes, most recent first:

 +2024-02-xx - xx - lavu 58.38.100 - channel_layout.h
 +  Add av_channel_layout_retype().


Can you please add tests for it in tests/channel_layout.c?


Yes, will send a follow up series with tests once this series is merged.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/ac3enc_template: add fbw_channels assert

2024-02-11 Thread Michael Niedermayer
On Mon, Feb 05, 2024 at 03:58:22AM +0100, Michael Niedermayer wrote:
> fbw_channels must be > 0 as teh code is only run if cpl_enabled is set and 
> that requires mode >= AC3_CHMODE_STEREO
> 
> CID 718138 Uninitialized scalar variable
>   assumes this assert to be false
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/ac3enc_template.c | 2 ++
>  1 file changed, 2 insertions(+)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- 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] avcodec/indeo3: Round dimensions up in allocate_frame_buffers()

2024-02-11 Thread Michael Niedermayer
On Sat, Feb 03, 2024 at 08:29:31PM +0100, Michael Niedermayer wrote:
> Fixes: Ticket6581
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/indeo3.c | 3 +++
>  1 file changed, 3 insertions(+)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH 01/23] avutil/hwcontext_opencl: Use proper OpenCLFramesContext

2024-02-11 Thread Andreas Rheinhardt
The currently used pointer when unmapping DXVA2 and D3D11
actually points to an OpenCLDeviceContext.

Signed-off-by: Andreas Rheinhardt 
---
1. I'd appreciate testing of this.
2. Most of the patches in this patchset can be applied immediately;
only those two patches that remove AVHWDeviceInternal and
AVHWFramesInternal need to be applied at the bump.

 libavutil/hwcontext_opencl.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index 247834aaf6..c1764ed098 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -2346,7 +2346,7 @@ static void opencl_unmap_from_dxva2(AVHWFramesContext 
*dst_fc,
 {
 AVOpenCLFrameDescriptor*desc = hwmap->priv;
 OpenCLDeviceContext *device_priv = dst_fc->device_ctx->internal->priv;
-OpenCLFramesContext *frames_priv = dst_fc->device_ctx->internal->priv;
+OpenCLFramesContext *frames_priv = dst_fc->internal->priv;
 cl_event event;
 cl_int cle;
 
@@ -2511,7 +2511,7 @@ static void opencl_unmap_from_d3d11(AVHWFramesContext 
*dst_fc,
 {
 AVOpenCLFrameDescriptor*desc = hwmap->priv;
 OpenCLDeviceContext *device_priv = dst_fc->device_ctx->internal->priv;
-OpenCLFramesContext *frames_priv = dst_fc->device_ctx->internal->priv;
+OpenCLFramesContext *frames_priv = dst_fc->internal->priv;
 cl_event event;
 cl_int cle;
 
-- 
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 02/23] avutil/hwcontext: Don't check before av_buffer_unref()

2024-02-11 Thread Andreas Rheinhardt
av_buffer_unref() can handle AVBufferRef** that point
to a NULL AVBufferRef*.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index e23bad230f..63fc1a6a22 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -297,8 +297,7 @@ AVBufferRef *av_hwframe_ctx_alloc(AVBufferRef 
*device_ref_in)
 return buf;
 
 fail:
-if (device_ref)
-av_buffer_unref(&device_ref);
+av_buffer_unref(&device_ref);
 if (ctx->internal)
 av_freep(&ctx->internal->priv);
 av_freep(&ctx->internal);
-- 
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 03/23] avutil/hwcontext_vaapi: Allocate public and priv device hwctx together

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to VAAPIDeviceContext as one no longer has to
go through AVHWDeviceInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_vaapi.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 29fc8bd648..7019769f24 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -75,6 +75,11 @@ typedef struct VAAPISurfaceFormat {
 } VAAPISurfaceFormat;
 
 typedef struct VAAPIDeviceContext {
+/**
+ * The public AVVAAPIDeviceContext. See hwcontext_vaapi.h for it.
+ */
+AVVAAPIDeviceContext p;
+
 // Surface formats which can be used with this device.
 VAAPISurfaceFormat *formats;
 int  nb_formats;
@@ -207,7 +212,7 @@ static int vaapi_get_image_format(AVHWDeviceContext *hwdev,
   enum AVPixelFormat pix_fmt,
   VAImageFormat **image_format)
 {
-VAAPIDeviceContext *ctx = hwdev->internal->priv;
+VAAPIDeviceContext *ctx = hwdev->hwctx;
 int i;
 
 for (i = 0; i < ctx->nb_formats; i++) {
@@ -224,9 +229,9 @@ static int vaapi_frames_get_constraints(AVHWDeviceContext 
*hwdev,
 const void *hwconfig,
 AVHWFramesConstraints *constraints)
 {
-AVVAAPIDeviceContext *hwctx = hwdev->hwctx;
+VAAPIDeviceContext *ctx = hwdev->hwctx;
+AVVAAPIDeviceContext *hwctx = &ctx->p;
 const AVVAAPIHWConfig *config = hwconfig;
-VAAPIDeviceContext *ctx = hwdev->internal->priv;
 VASurfaceAttrib *attr_list = NULL;
 VAStatus vas;
 enum AVPixelFormat pix_fmt;
@@ -384,8 +389,8 @@ static const struct {
 
 static int vaapi_device_init(AVHWDeviceContext *hwdev)
 {
-VAAPIDeviceContext *ctx = hwdev->internal->priv;
-AVVAAPIDeviceContext *hwctx = hwdev->hwctx;
+VAAPIDeviceContext *ctx = hwdev->hwctx;
+AVVAAPIDeviceContext *hwctx = &ctx->p;
 VAImageFormat *image_list = NULL;
 VAStatus vas;
 const char *vendor_string;
@@ -474,7 +479,7 @@ fail:
 
 static void vaapi_device_uninit(AVHWDeviceContext *hwdev)
 {
-VAAPIDeviceContext *ctx = hwdev->internal->priv;
+VAAPIDeviceContext *ctx = hwdev->hwctx;
 
 av_freep(&ctx->formats);
 }
@@ -718,7 +723,7 @@ static int vaapi_transfer_get_formats(AVHWFramesContext 
*hwfc,
   enum AVHWFrameTransferDirection dir,
   enum AVPixelFormat **formats)
 {
-VAAPIDeviceContext *ctx = hwfc->device_ctx->internal->priv;
+VAAPIDeviceContext *ctx = hwfc->device_ctx->hwctx;
 enum AVPixelFormat *pix_fmts;
 int i, k, sw_format_available;
 
@@ -2007,8 +2012,7 @@ const HWContextType ff_hwcontext_type_vaapi = {
 .type   = AV_HWDEVICE_TYPE_VAAPI,
 .name   = "VAAPI",
 
-.device_hwctx_size  = sizeof(AVVAAPIDeviceContext),
-.device_priv_size   = sizeof(VAAPIDeviceContext),
+.device_hwctx_size  = sizeof(VAAPIDeviceContext),
 .device_hwconfig_size   = sizeof(AVVAAPIHWConfig),
 .frames_hwctx_size  = sizeof(AVVAAPIFramesContext),
 .frames_priv_size   = sizeof(VAAPIFramesContext),
-- 
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 04/23] avutil/hwcontext_vulkan: Allocate public and priv device hwctx together

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to VulkanDevicePriv as one no longer has to
go through AVHWDeviceInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_vulkan.c | 109 ++-
 1 file changed, 56 insertions(+), 53 deletions(-)

diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index a84713e621..3d591dedf9 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -81,6 +81,11 @@ typedef struct VulkanQueueCtx {
 } VulkanQueueCtx;
 
 typedef struct VulkanDevicePriv {
+/**
+ * The public AVVulkanDeviceContext. See hwcontext_vulkan.h for it.
+ */
+AVVulkanDeviceContext p;
+
 /* Vulkan library and loader functions */
 void *libvulkan;
 
@@ -288,8 +293,8 @@ static int vkfmt_from_pixfmt2(AVHWDeviceContext *dev_ctx, 
enum AVPixelFormat p,
   VkImageUsageFlags *supported_usage,  /* Output 
supported usage */
   int disable_multiplane, int need_storage)
 {
-AVVulkanDeviceContext *hwctx = dev_ctx->hwctx;
-VulkanDevicePriv *priv = dev_ctx->internal->priv;
+VulkanDevicePriv *priv = dev_ctx->hwctx;
+AVVulkanDeviceContext *hwctx = &priv->p;
 FFVulkanFunctions *vk = &priv->vkctx.vkfn;
 
 const VkFormatFeatureFlagBits2 basic_flags = 
VK_FORMAT_FEATURE_2_SAMPLED_IMAGE_BIT |
@@ -369,8 +374,8 @@ static int vkfmt_from_pixfmt2(AVHWDeviceContext *dev_ctx, 
enum AVPixelFormat p,
 
 static int load_libvulkan(AVHWDeviceContext *ctx)
 {
-AVVulkanDeviceContext *hwctx = ctx->hwctx;
-VulkanDevicePriv *p = ctx->internal->priv;
+VulkanDevicePriv *p = ctx->hwctx;
+AVVulkanDeviceContext *hwctx = &p->p;
 
 static const char *lib_names[] = {
 #if defined(_WIN32)
@@ -488,9 +493,9 @@ static int check_extensions(AVHWDeviceContext *ctx, int 
dev, AVDictionary *opts,
 {
 const char *tstr;
 const char **extension_names = NULL;
-VulkanDevicePriv *p = ctx->internal->priv;
+VulkanDevicePriv *p = ctx->hwctx;
+AVVulkanDeviceContext *hwctx = &p->p;
 FFVulkanFunctions *vk = &p->vkctx.vkfn;
-AVVulkanDeviceContext *hwctx = ctx->hwctx;
 int err = 0, found, extensions_found = 0;
 
 const char *mod;
@@ -619,7 +624,7 @@ static int check_validation_layers(AVHWDeviceContext *ctx, 
AVDictionary *opts,
 static const char default_layer[] = { "VK_LAYER_KHRONOS_validation" };
 
 int found = 0, err = 0;
-VulkanDevicePriv *priv = ctx->internal->priv;
+VulkanDevicePriv *priv = ctx->hwctx;
 FFVulkanFunctions *vk = &priv->vkctx.vkfn;
 
 uint32_t sup_layer_count;
@@ -726,9 +731,9 @@ static int create_instance(AVHWDeviceContext *ctx, 
AVDictionary *opts)
 {
 int err = 0, debug_mode = 0;
 VkResult ret;
-VulkanDevicePriv *p = ctx->internal->priv;
+VulkanDevicePriv *p = ctx->hwctx;
+AVVulkanDeviceContext *hwctx = &p->p;
 FFVulkanFunctions *vk = &p->vkctx.vkfn;
-AVVulkanDeviceContext *hwctx = ctx->hwctx;
 VkApplicationInfo application_info = {
 .sType  = VK_STRUCTURE_TYPE_APPLICATION_INFO,
 .pApplicationName   = "ffmpeg",
@@ -866,13 +871,13 @@ static int find_device(AVHWDeviceContext *ctx, 
VulkanDeviceSelection *select)
 int err = 0, choice = -1;
 uint32_t num;
 VkResult ret;
-VulkanDevicePriv *p = ctx->internal->priv;
+VulkanDevicePriv *p = ctx->hwctx;
+AVVulkanDeviceContext *hwctx = &p->p;
 FFVulkanFunctions *vk = &p->vkctx.vkfn;
 VkPhysicalDevice *devices = NULL;
 VkPhysicalDeviceIDProperties *idp = NULL;
 VkPhysicalDeviceProperties2 *prop = NULL;
 VkPhysicalDeviceDrmPropertiesEXT *drm_prop = NULL;
-AVVulkanDeviceContext *hwctx = ctx->hwctx;
 
 ret = vk->EnumeratePhysicalDevices(hwctx->inst, &num, NULL);
 if (ret != VK_SUCCESS || !num) {
@@ -1046,9 +1051,9 @@ static int setup_queue_families(AVHWDeviceContext *ctx, 
VkDeviceCreateInfo *cd)
 uint32_t num;
 float *weights;
 VkQueueFamilyProperties *qf = NULL;
-VulkanDevicePriv *p = ctx->internal->priv;
+VulkanDevicePriv *p = ctx->hwctx;
+AVVulkanDeviceContext *hwctx = &p->p;
 FFVulkanFunctions *vk = &p->vkctx.vkfn;
-AVVulkanDeviceContext *hwctx = ctx->hwctx;
 int graph_index, comp_index, tx_index, enc_index, dec_index;
 
 /* First get the number of queue families */
@@ -1182,9 +1187,9 @@ static int setup_queue_families(AVHWDeviceContext *ctx, 
VkDeviceCreateInfo *cd)
  */
 static void vulkan_device_free(AVHWDeviceContext *ctx)
 {
-VulkanDevicePriv *p = ctx->internal->priv;
+VulkanDevicePriv *p = ctx->hwctx;
+AVVulkanDeviceContext *hwctx = &p->p;
 FFVulkanFunctions *vk = &p->vkctx.vkfn;
-AVVulkanDeviceContext *hwctx = ctx->hwctx;
 
 if (hwctx->act_dev)
 vk->DestroyDevice(hwctx->act_dev, hwctx->alloc);
@@ -1205,7 +1210,7 @@ static void vulkan_device_free(AVHWDeviceContext *ctx)
 
 stat

[FFmpeg-devel] [PATCH 05/23] avutil/hwcontext_qsv: Allocate public and priv device hwctx together

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to QSVDeviceContext as one no longer has to
go through AVHWDeviceInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_qsv.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index a67552b5ac..99d974f25f 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -70,6 +70,11 @@ typedef struct QSVDevicePriv {
 } QSVDevicePriv;
 
 typedef struct QSVDeviceContext {
+/**
+ * The public AVQSVDeviceContext. See hwcontext_qsv.h for it.
+ */
+AVQSVDeviceContext p;
+
 mfxHDL  handle;
 mfxHandleType   handle_type;
 mfxVersion  ver;
@@ -268,8 +273,8 @@ static int qsv_fill_border(AVFrame *dst, const AVFrame *src)
 
 static int qsv_device_init(AVHWDeviceContext *ctx)
 {
-AVQSVDeviceContext *hwctx = ctx->hwctx;
-QSVDeviceContext   *s = ctx->internal->priv;
+QSVDeviceContext   *s = ctx->hwctx;
+AVQSVDeviceContext *hwctx = &s->p;
 int   hw_handle_supported = 0;
 mfxHandleType handle_type;
 enum AVHWDeviceType device_type;
@@ -378,7 +383,7 @@ static int qsv_init_child_ctx(AVHWFramesContext *ctx)
 {
 AVQSVFramesContext *hwctx = ctx->hwctx;
 QSVFramesContext   *s = ctx->internal->priv;
-QSVDeviceContext *device_priv = ctx->device_ctx->internal->priv;
+QSVDeviceContext *device_priv = ctx->device_ctx->hwctx;
 
 AVBufferRef *child_device_ref = NULL;
 AVBufferRef *child_frames_ref = NULL;
@@ -1108,7 +1113,8 @@ static int qsv_init_internal_session(AVHWFramesContext 
*ctx,
  mfxSession *session, int upload)
 {
 AVQSVFramesContext *frames_hwctx = ctx->hwctx;
-QSVDeviceContext   *device_priv  = ctx->device_ctx->internal->priv;
+QSVDeviceContext   *device_priv  = ctx->device_ctx->hwctx;
+AVQSVDeviceContext *hwctx= &device_priv->p;
 int opaque = 0;
 
 mfxFrameAllocator frame_allocator = {
@@ -1123,7 +1129,6 @@ static int qsv_init_internal_session(AVHWFramesContext 
*ctx,
 mfxVideoParam par;
 mfxStatus err;
 int   ret = AVERROR_UNKNOWN;
-AVQSVDeviceContext *hwctx = ctx->device_ctx->hwctx;
 /* hwctx->loader is non-NULL for oneVPL user and NULL for non-oneVPL user 
*/
 void **loader = &hwctx->loader;
 
@@ -2246,8 +2251,7 @@ const HWContextType ff_hwcontext_type_qsv = {
 .type   = AV_HWDEVICE_TYPE_QSV,
 .name   = "QSV",
 
-.device_hwctx_size  = sizeof(AVQSVDeviceContext),
-.device_priv_size   = sizeof(QSVDeviceContext),
+.device_hwctx_size  = sizeof(QSVDeviceContext),
 .frames_hwctx_size  = sizeof(AVQSVFramesContext),
 .frames_priv_size   = sizeof(QSVFramesContext),
 
-- 
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 06/23] avutil/hwcontext_vdpau: Allocate public and priv device hwctx together

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to VDPAUDeviceContext as one no longer has to
go through AVHWDeviceInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_vdpau.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/libavutil/hwcontext_vdpau.c b/libavutil/hwcontext_vdpau.c
index 5b78e95529..016300db1e 100644
--- a/libavutil/hwcontext_vdpau.c
+++ b/libavutil/hwcontext_vdpau.c
@@ -83,6 +83,11 @@ static const struct {
 };
 
 typedef struct VDPAUDeviceContext {
+/**
+ * The public AVVDPAUDeviceContext. See hwcontext_vdpau.h for it.
+ */
+AVVDPAUDeviceContext p;
+
 VdpVideoSurfaceQueryGetPutBitsYCbCrCapabilities *get_transfer_caps;
 VdpVideoSurfaceGetBitsYCbCr *get_data;
 VdpVideoSurfacePutBitsYCbCr *put_data;
@@ -115,8 +120,8 @@ static int count_pixfmts(const VDPAUPixFmtMap *map)
 
 static int vdpau_init_pixmfts(AVHWDeviceContext *ctx)
 {
-AVVDPAUDeviceContext *hwctx = ctx->hwctx;
-VDPAUDeviceContext*priv = ctx->internal->priv;
+VDPAUDeviceContext*priv = ctx->hwctx;
+AVVDPAUDeviceContext *hwctx = &priv->p;
 int i;
 
 for (i = 0; i < FF_ARRAY_ELEMS(priv->pix_fmts); i++) {
@@ -157,8 +162,8 @@ do {
 
 static int vdpau_device_init(AVHWDeviceContext *ctx)
 {
-AVVDPAUDeviceContext *hwctx = ctx->hwctx;
-VDPAUDeviceContext   *priv  = ctx->internal->priv;
+VDPAUDeviceContext*priv = ctx->hwctx;
+AVVDPAUDeviceContext *hwctx = &priv->p;
 VdpStatus err;
 int   ret;
 
@@ -180,7 +185,7 @@ static int vdpau_device_init(AVHWDeviceContext *ctx)
 
 static void vdpau_device_uninit(AVHWDeviceContext *ctx)
 {
-VDPAUDeviceContext *priv = ctx->internal->priv;
+VDPAUDeviceContext *priv = ctx->hwctx;
 int i;
 
 for (i = 0; i < FF_ARRAY_ELEMS(priv->pix_fmts); i++)
@@ -191,7 +196,7 @@ static int vdpau_frames_get_constraints(AVHWDeviceContext 
*ctx,
 const void *hwconfig,
 AVHWFramesConstraints *constraints)
 {
-VDPAUDeviceContext   *priv  = ctx->internal->priv;
+VDPAUDeviceContext *priv  = ctx->hwctx;
 int nb_sw_formats = 0;
 int i;
 
@@ -219,7 +224,7 @@ static int vdpau_frames_get_constraints(AVHWDeviceContext 
*ctx,
 static void vdpau_buffer_free(void *opaque, uint8_t *data)
 {
 AVHWFramesContext  *ctx = opaque;
-VDPAUDeviceContext *device_priv = ctx->device_ctx->internal->priv;
+VDPAUDeviceContext *device_priv = ctx->device_ctx->hwctx;
 VdpVideoSurfacesurf = (VdpVideoSurface)(uintptr_t)data;
 
 device_priv->surf_destroy(surf);
@@ -229,8 +234,8 @@ static AVBufferRef *vdpau_pool_alloc(void *opaque, size_t 
size)
 {
 AVHWFramesContext *ctx = opaque;
 VDPAUFramesContext   *priv = ctx->internal->priv;
-AVVDPAUDeviceContext *device_hwctx = ctx->device_ctx->hwctx;
-VDPAUDeviceContext*device_priv = ctx->device_ctx->internal->priv;
+VDPAUDeviceContext*device_priv = ctx->device_ctx->hwctx;
+AVVDPAUDeviceContext *device_hwctx = &device_priv->p;
 
 AVBufferRef *ret;
 VdpVideoSurface surf;
@@ -255,7 +260,7 @@ static AVBufferRef *vdpau_pool_alloc(void *opaque, size_t 
size)
 
 static int vdpau_frames_init(AVHWFramesContext *ctx)
 {
-VDPAUDeviceContext *device_priv = ctx->device_ctx->internal->priv;
+VDPAUDeviceContext *device_priv = ctx->device_ctx->hwctx;
 VDPAUFramesContext*priv = ctx->internal->priv;
 
 int i;
@@ -508,8 +513,7 @@ const HWContextType ff_hwcontext_type_vdpau = {
 .type = AV_HWDEVICE_TYPE_VDPAU,
 .name = "VDPAU",
 
-.device_hwctx_size= sizeof(AVVDPAUDeviceContext),
-.device_priv_size = sizeof(VDPAUDeviceContext),
+.device_hwctx_size= sizeof(VDPAUDeviceContext),
 .frames_priv_size = sizeof(VDPAUFramesContext),
 
 #if HAVE_VDPAU_X11
-- 
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 08/23] avutil/hwcontext_d3d12va: Allocate pub and priv device hwctx together

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to D3D12VADevicePriv as one no longer has to
go through AVHWDeviceInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_d3d12va.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/libavutil/hwcontext_d3d12va.c b/libavutil/hwcontext_d3d12va.c
index 3acd5ac43a..6b4cd22899 100644
--- a/libavutil/hwcontext_d3d12va.c
+++ b/libavutil/hwcontext_d3d12va.c
@@ -46,6 +46,10 @@ typedef struct D3D12VAFramesContext {
 } D3D12VAFramesContext;
 
 typedef struct D3D12VADevicePriv {
+/**
+ * The public AVD3D12VADeviceContext. See hwcontext_d3d12va.h for it.
+ */
+AVD3D12VADeviceContext p;
 HANDLEd3d12lib;
 HANDLEdxgilib;
 PFN_CREATE_DXGI_FACTORY2  create_dxgi_factory2;
@@ -526,7 +530,7 @@ fail:
 
 static int d3d12va_load_functions(AVHWDeviceContext *hwdev)
 {
-D3D12VADevicePriv *priv = hwdev->internal->priv;
+D3D12VADevicePriv *priv = hwdev->hwctx;
 
 #if !HAVE_UWP
 priv->d3d12lib = dlopen("d3d12.dll", 0);
@@ -558,8 +562,8 @@ fail:
 
 static void d3d12va_device_free(AVHWDeviceContext *hwdev)
 {
-AVD3D12VADeviceContext *ctx  = hwdev->hwctx;
-D3D12VADevicePriv  *priv = hwdev->internal->priv;
+D3D12VADevicePriv  *priv = hwdev->hwctx;
+AVD3D12VADeviceContext *ctx  = &priv->p;
 
 D3D12_OBJECT_RELEASE(ctx->device);
 
@@ -609,8 +613,8 @@ static void d3d12va_device_uninit(AVHWDeviceContext *hwdev)
 static int d3d12va_device_create(AVHWDeviceContext *hwdev, const char *device,
  AVDictionary *opts, int flags)
 {
-AVD3D12VADeviceContext *ctx  = hwdev->hwctx;
-D3D12VADevicePriv  *priv = hwdev->internal->priv;
+D3D12VADevicePriv  *priv = hwdev->hwctx;
+AVD3D12VADeviceContext *ctx  = &priv->p;
 
 HRESULT hr;
 UINT create_flags = 0;
@@ -670,8 +674,7 @@ const HWContextType ff_hwcontext_type_d3d12va = {
 .type   = AV_HWDEVICE_TYPE_D3D12VA,
 .name   = "D3D12VA",
 
-.device_hwctx_size  = sizeof(AVD3D12VADeviceContext),
-.device_priv_size   = sizeof(D3D12VADevicePriv),
+.device_hwctx_size  = sizeof(D3D12VADevicePriv),
 .frames_hwctx_size  = sizeof(AVD3D12VAFramesContext),
 .frames_priv_size   = sizeof(D3D12VAFramesContext),
 
-- 
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 09/23] avutil/hwcontext: Remove unused AVHWDeviceInternal.priv

2024-02-11 Thread Andreas Rheinhardt
It is no longer used by any hwcontext, as they all allocate
their private data together with their public data and access
it via AVHWDeviceContext.hwctx.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext.c  | 9 -
 libavutil/hwcontext_internal.h | 6 --
 2 files changed, 15 deletions(-)

diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 63fc1a6a22..02e9668c31 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -139,7 +139,6 @@ static void hwdevice_ctx_free(void *opaque, uint8_t *data)
 av_buffer_unref(&ctx->internal->source_device);
 
 av_freep(&ctx->hwctx);
-av_freep(&ctx->internal->priv);
 av_freep(&ctx->internal);
 av_freep(&ctx);
 }
@@ -168,12 +167,6 @@ AVBufferRef *av_hwdevice_ctx_alloc(enum AVHWDeviceType 
type)
 if (!ctx->internal)
 goto fail;
 
-if (hw_type->device_priv_size) {
-ctx->internal->priv = av_mallocz(hw_type->device_priv_size);
-if (!ctx->internal->priv)
-goto fail;
-}
-
 if (hw_type->device_hwctx_size) {
 ctx->hwctx = av_mallocz(hw_type->device_hwctx_size);
 if (!ctx->hwctx)
@@ -194,8 +187,6 @@ AVBufferRef *av_hwdevice_ctx_alloc(enum AVHWDeviceType type)
 return buf;
 
 fail:
-if (ctx->internal)
-av_freep(&ctx->internal->priv);
 av_freep(&ctx->internal);
 av_freep(&ctx->hwctx);
 av_freep(&ctx);
diff --git a/libavutil/hwcontext_internal.h b/libavutil/hwcontext_internal.h
index 4df516ee6a..374c6dde2f 100644
--- a/libavutil/hwcontext_internal.h
+++ b/libavutil/hwcontext_internal.h
@@ -41,11 +41,6 @@ typedef struct HWContextType {
  * i.e. AVHWDeviceContext.hwctx
  */
 size_t device_hwctx_size;
-/**
- * size of the private data, i.e.
- * AVHWDeviceInternal.priv
- */
-size_t device_priv_size;
 
 /**
  * Size of the hardware-specific device configuration.
@@ -102,7 +97,6 @@ typedef struct HWContextType {
 
 struct AVHWDeviceInternal {
 const HWContextType *hw_type;
-void*priv;
 
 /**
  * For a derived device, a reference to the original device
-- 
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 10/23] avutil/hwcontext: Allocate AVHWDevCtx jointly with its internals

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of these structures coincide.
It has the advantage of allowing to remove the AVHWDeviceInternal
from the public header; given that AVHWDeviceInternal.priv is no more,
all accesses to it happen in hwcontext.c, so that this commit moves
the joint structure there.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext.c  | 102 ++---
 libavutil/hwcontext.h  |   8 ---
 libavutil/hwcontext_internal.h |  10 
 3 files changed, 57 insertions(+), 63 deletions(-)

diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 02e9668c31..c962c19f3e 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -84,6 +84,21 @@ static const char *const hw_type_names[] = {
 [AV_HWDEVICE_TYPE_VULKAN] = "vulkan",
 };
 
+typedef struct FFHWDeviceContext {
+/**
+ * The public AVHWDeviceContext. See hwcontext.h for it.
+ */
+AVHWDeviceContext p;
+
+const HWContextType *hw_type;
+
+/**
+ * For a derived device, a reference to the original device
+ * context it was derived from.
+ */
+AVBufferRef *source_device;
+} FFHWDeviceContext;
+
 enum AVHWDeviceType av_hwdevice_find_type_by_name(const char *name)
 {
 int type;
@@ -126,25 +141,26 @@ static const AVClass hwdevice_ctx_class = {
 
 static void hwdevice_ctx_free(void *opaque, uint8_t *data)
 {
-AVHWDeviceContext *ctx = (AVHWDeviceContext*)data;
+FFHWDeviceContext *ctxi = (FFHWDeviceContext*)data;
+AVHWDeviceContext *ctx  = &ctxi->p;
 
 /* uninit might still want access the hw context and the user
  * free() callback might destroy it, so uninit has to be called first */
-if (ctx->internal->hw_type->device_uninit)
-ctx->internal->hw_type->device_uninit(ctx);
+if (ctxi->hw_type->device_uninit)
+ctxi->hw_type->device_uninit(ctx);
 
 if (ctx->free)
 ctx->free(ctx);
 
-av_buffer_unref(&ctx->internal->source_device);
+av_buffer_unref(&ctxi->source_device);
 
 av_freep(&ctx->hwctx);
-av_freep(&ctx->internal);
 av_freep(&ctx);
 }
 
 AVBufferRef *av_hwdevice_ctx_alloc(enum AVHWDeviceType type)
 {
+FFHWDeviceContext *ctxi;
 AVHWDeviceContext *ctx;
 AVBufferRef *buf;
 const HWContextType *hw_type = NULL;
@@ -159,13 +175,10 @@ AVBufferRef *av_hwdevice_ctx_alloc(enum AVHWDeviceType 
type)
 if (!hw_type)
 return NULL;
 
-ctx = av_mallocz(sizeof(*ctx));
-if (!ctx)
+ctxi = av_mallocz(sizeof(*ctxi));
+if (!ctxi)
 return NULL;
-
-ctx->internal = av_mallocz(sizeof(*ctx->internal));
-if (!ctx->internal)
-goto fail;
+ctx = &ctxi->p;
 
 if (hw_type->device_hwctx_size) {
 ctx->hwctx = av_mallocz(hw_type->device_hwctx_size);
@@ -182,12 +195,11 @@ AVBufferRef *av_hwdevice_ctx_alloc(enum AVHWDeviceType 
type)
 ctx->type = type;
 ctx->av_class = &hwdevice_ctx_class;
 
-ctx->internal->hw_type = hw_type;
+ctxi->hw_type = hw_type;
 
 return buf;
 
 fail:
-av_freep(&ctx->internal);
 av_freep(&ctx->hwctx);
 av_freep(&ctx);
 return NULL;
@@ -195,19 +207,20 @@ fail:
 
 int av_hwdevice_ctx_init(AVBufferRef *ref)
 {
-AVHWDeviceContext *ctx = (AVHWDeviceContext*)ref->data;
+FFHWDeviceContext *ctxi = (FFHWDeviceContext*)ref->data;
+AVHWDeviceContext *ctx  = &ctxi->p;
 int ret;
 
-if (ctx->internal->hw_type->device_init) {
-ret = ctx->internal->hw_type->device_init(ctx);
+if (ctxi->hw_type->device_init) {
+ret = ctxi->hw_type->device_init(ctx);
 if (ret < 0)
 goto fail;
 }
 
 return 0;
 fail:
-if (ctx->internal->hw_type->device_uninit)
-ctx->internal->hw_type->device_uninit(ctx);
+if (ctxi->hw_type->device_uninit)
+ctxi->hw_type->device_uninit(ctx);
 return ret;
 }
 
@@ -242,8 +255,8 @@ static void hwframe_ctx_free(void *opaque, uint8_t *data)
 
 AVBufferRef *av_hwframe_ctx_alloc(AVBufferRef *device_ref_in)
 {
-AVHWDeviceContext *device_ctx = (AVHWDeviceContext*)device_ref_in->data;
-const HWContextType  *hw_type = device_ctx->internal->hw_type;
+FFHWDeviceContext *device_ctx = (FFHWDeviceContext*)device_ref_in->data;
+const HWContextType  *hw_type = device_ctx->hw_type;
 AVHWFramesContext *ctx;
 AVBufferRef *buf, *device_ref = NULL;
 
@@ -279,7 +292,7 @@ AVBufferRef *av_hwframe_ctx_alloc(AVBufferRef 
*device_ref_in)
 
 ctx->av_class   = &hwframe_ctx_class;
 ctx->device_ref = device_ref;
-ctx->device_ctx = device_ctx;
+ctx->device_ctx = &device_ctx->p;
 ctx->format = AV_PIX_FMT_NONE;
 ctx->sw_format  = AV_PIX_FMT_NONE;
 
@@ -563,8 +576,8 @@ int av_hwframe_get_buffer(AVBufferRef *hwframe_ref, AVFrame 
*frame, int flags)
 
 void *av_hwdevice_hwconfig_alloc(AVBufferRef *ref)
 {
-AVHWDeviceContext *ctx = (AVHWDeviceContext*)ref->data;
-const HWContextType  *hw_type = ctx->internal->hw_type;
+FFHWDeviceContext *ctx = (FFHWD

[FFmpeg-devel] [PATCH 11/23] avutil/hwcontext_vaapi: Allocate pub and priv frames hwctx together

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to VAAPIFramesContext as one no longer has to
go through AVHWFramesInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_vaapi.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 7019769f24..2c75f5f5b1 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -86,6 +86,11 @@ typedef struct VAAPIDeviceContext {
 } VAAPIDeviceContext;
 
 typedef struct VAAPIFramesContext {
+/**
+ * The public AVVAAPIFramesContext. See hwcontext_vaapi.h for it.
+ */
+AVVAAPIFramesContext p;
+
 // Surface attributes set at create time.
 VASurfaceAttrib *attributes;
 int   nb_attributes;
@@ -503,9 +508,9 @@ static void vaapi_buffer_free(void *opaque, uint8_t *data)
 static AVBufferRef *vaapi_pool_alloc(void *opaque, size_t size)
 {
 AVHWFramesContext *hwfc = opaque;
-VAAPIFramesContext *ctx = hwfc->internal->priv;
+VAAPIFramesContext *ctx = hwfc->hwctx;
+AVVAAPIFramesContext  *avfc = &ctx->p;
 AVVAAPIDeviceContext *hwctx = hwfc->device_ctx->hwctx;
-AVVAAPIFramesContext  *avfc = hwfc->hwctx;
 VASurfaceID surface_id;
 VAStatus vas;
 AVBufferRef *ref;
@@ -546,8 +551,8 @@ static AVBufferRef *vaapi_pool_alloc(void *opaque, size_t 
size)
 
 static int vaapi_frames_init(AVHWFramesContext *hwfc)
 {
-AVVAAPIFramesContext  *avfc = hwfc->hwctx;
-VAAPIFramesContext *ctx = hwfc->internal->priv;
+VAAPIFramesContext *ctx = hwfc->hwctx;
+AVVAAPIFramesContext  *avfc = &ctx->p;
 AVVAAPIDeviceContext *hwctx = hwfc->device_ctx->hwctx;
 const VAAPIFormatDescriptor *desc;
 VAImageFormat *expected_format;
@@ -698,8 +703,8 @@ fail:
 
 static void vaapi_frames_uninit(AVHWFramesContext *hwfc)
 {
-AVVAAPIFramesContext *avfc = hwfc->hwctx;
-VAAPIFramesContext*ctx = hwfc->internal->priv;
+VAAPIFramesContext*ctx = hwfc->hwctx;
+AVVAAPIFramesContext *avfc = &ctx->p;
 
 av_freep(&avfc->surface_ids);
 av_freep(&ctx->attributes);
@@ -796,7 +801,7 @@ static int vaapi_map_frame(AVHWFramesContext *hwfc,
AVFrame *dst, const AVFrame *src, int flags)
 {
 AVVAAPIDeviceContext *hwctx = hwfc->device_ctx->hwctx;
-VAAPIFramesContext *ctx = hwfc->internal->priv;
+VAAPIFramesContext *ctx = hwfc->hwctx;
 VASurfaceID surface_id;
 const VAAPIFormatDescriptor *desc;
 VAImageFormat *image_format;
@@ -1075,7 +1080,7 @@ static int vaapi_map_from_drm(AVHWFramesContext *src_fc, 
AVFrame *dst,
   const AVFrame *src, int flags)
 {
 #if VA_CHECK_VERSION(1, 1, 0)
-VAAPIFramesContext *src_vafc = src_fc->internal->priv;
+VAAPIFramesContext*src_vafc = src_fc->hwctx;
 int use_prime2;
 #else
 int k;
@@ -2014,8 +2019,7 @@ const HWContextType ff_hwcontext_type_vaapi = {
 
 .device_hwctx_size  = sizeof(VAAPIDeviceContext),
 .device_hwconfig_size   = sizeof(AVVAAPIHWConfig),
-.frames_hwctx_size  = sizeof(AVVAAPIFramesContext),
-.frames_priv_size   = sizeof(VAAPIFramesContext),
+.frames_hwctx_size  = sizeof(VAAPIFramesContext),
 
 .device_create  = &vaapi_device_create,
 .device_derive  = &vaapi_device_derive,
-- 
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 12/23] avutil/hwcontext_vulkan: Allocate pub and priv frames hwctx together

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to VulkanFramesPriv as one no longer has to
go through AVHWFramesInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_vulkan.c | 30 +-
 1 file changed, 17 insertions(+), 13 deletions(-)

diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index 3d591dedf9..449a6a2fef 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -129,6 +129,11 @@ typedef struct VulkanDevicePriv {
 } VulkanDevicePriv;
 
 typedef struct VulkanFramesPriv {
+/**
+ * The public AVVulkanFramesContext. See hwcontext_vulkan.h for it.
+ */
+AVVulkanFramesContext p;
+
 /* Image conversions */
 FFVkExecPool compute_exec;
 
@@ -2191,9 +2196,9 @@ static AVBufferRef *vulkan_pool_alloc(void *opaque, 
size_t size)
 AVVkFrame *f;
 AVBufferRef *avbuf = NULL;
 AVHWFramesContext *hwfc = opaque;
-AVVulkanFramesContext *hwctx = hwfc->hwctx;
 VulkanDevicePriv *p = hwfc->device_ctx->hwctx;
-VulkanFramesPriv *fp = hwfc->internal->priv;
+VulkanFramesPriv *fp = hwfc->hwctx;
+AVVulkanFramesContext *hwctx = &fp->p;
 VkExternalMemoryHandleTypeFlags e = 0x0;
 VkExportMemoryAllocateInfo eminfo[AV_NUM_DATA_POINTERS];
 
@@ -2264,7 +2269,7 @@ static void unlock_frame(AVHWFramesContext *fc, AVVkFrame 
*vkf)
 static void vulkan_frames_uninit(AVHWFramesContext *hwfc)
 {
 VulkanDevicePriv *p = hwfc->device_ctx->hwctx;
-VulkanFramesPriv *fp = hwfc->internal->priv;
+VulkanFramesPriv *fp = hwfc->hwctx;
 
 if (fp->modifier_info) {
 if (fp->modifier_info->pDrmFormatModifiers)
@@ -2281,8 +2286,8 @@ static int vulkan_frames_init(AVHWFramesContext *hwfc)
 {
 int err;
 AVVkFrame *f;
-AVVulkanFramesContext *hwctx = hwfc->hwctx;
-VulkanFramesPriv *fp = hwfc->internal->priv;
+VulkanFramesPriv *fp = hwfc->hwctx;
+AVVulkanFramesContext *hwctx = &fp->p;
 VulkanDevicePriv *p = hwfc->device_ctx->hwctx;
 VkImageUsageFlagBits supported_usage;
 const struct FFVkFormatEntry *fmt;
@@ -2493,7 +2498,7 @@ static int 
vulkan_map_from_drm_frame_desc(AVHWFramesContext *hwfc, AVVkFrame **f
 VulkanDevicePriv *p = ctx->hwctx;
 AVVulkanDeviceContext *hwctx = &p->p;
 FFVulkanFunctions *vk = &p->vkctx.vkfn;
-VulkanFramesPriv *fp = hwfc->internal->priv;
+VulkanFramesPriv *fp = hwfc->hwctx;
 const AVDRMFrameDescriptor *desc = (AVDRMFrameDescriptor *)src->data[0];
 VkBindImageMemoryInfo bind_info[AV_DRM_MAX_PLANES];
 VkBindImagePlaneMemoryInfo plane_info[AV_DRM_MAX_PLANES];
@@ -3004,7 +3009,7 @@ static int 
vulkan_transfer_data_from_cuda(AVHWFramesContext *hwfc,
 CUcontext dummy;
 AVVkFrame *dst_f;
 AVVkFrameInternal *dst_int;
-VulkanFramesPriv *fp = hwfc->internal->priv;
+VulkanFramesPriv *fp = hwfc->hwctx;
 const int planes = av_pix_fmt_count_planes(hwfc->sw_format);
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(hwfc->sw_format);
 
@@ -3146,8 +3151,8 @@ static int vulkan_map_to_drm(AVHWFramesContext *hwfc, 
AVFrame *dst,
 VulkanDevicePriv *p = hwfc->device_ctx->hwctx;
 AVVulkanDeviceContext *hwctx = &p->p;
 FFVulkanFunctions *vk = &p->vkctx.vkfn;
-VulkanFramesPriv *fp = hwfc->internal->priv;
-AVVulkanFramesContext *hwfctx = hwfc->hwctx;
+VulkanFramesPriv *fp = hwfc->hwctx;
+AVVulkanFramesContext *hwfctx = &fp->p;
 const int planes = av_pix_fmt_count_planes(hwfc->sw_format);
 VkImageDrmFormatModifierPropertiesEXT drm_mod = {
 .sType = VK_STRUCTURE_TYPE_IMAGE_DRM_FORMAT_MODIFIER_PROPERTIES_EXT,
@@ -3317,7 +3322,7 @@ static int transfer_image_buf(AVHWFramesContext *hwfc, 
AVFrame *f,
 {
 int err;
 AVVkFrame *frame = (AVVkFrame *)f->data[0];
-VulkanFramesPriv *fp = hwfc->internal->priv;
+VulkanFramesPriv *fp = hwfc->hwctx;
 VulkanDevicePriv *p = hwfc->device_ctx->hwctx;
 FFVulkanFunctions *vk = &p->vkctx.vkfn;
 VkImageMemoryBarrier2 img_bar[AV_NUM_DATA_POINTERS];
@@ -3580,7 +3585,7 @@ static int vulkan_transfer_data_to_cuda(AVHWFramesContext 
*hwfc, AVFrame *dst,
 CUcontext dummy;
 AVVkFrame *dst_f;
 AVVkFrameInternal *dst_int;
-VulkanFramesPriv *fp = hwfc->internal->priv;
+VulkanFramesPriv *fp = hwfc->hwctx;
 const int planes = av_pix_fmt_count_planes(hwfc->sw_format);
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(hwfc->sw_format);
 
@@ -3723,8 +3728,7 @@ const HWContextType ff_hwcontext_type_vulkan = {
 .name   = "Vulkan",
 
 .device_hwctx_size  = sizeof(VulkanDevicePriv),
-.frames_hwctx_size  = sizeof(AVVulkanFramesContext),
-.frames_priv_size   = sizeof(VulkanFramesPriv),
+.frames_hwctx_size  = sizeof(VulkanFramesPriv),
 
 .device_init= &vulkan_device_init,
 .device_uninit  = &vulkan_device_uninit,
-- 
2.34.1

_

[FFmpeg-devel] [PATCH 13/23] avutil/hwcontext_videotoolbox: Allocate pub and priv frames hwctx together

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to VTFramesContext as one no longer has to
go through AVHWFramesInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_videotoolbox.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/libavutil/hwcontext_videotoolbox.c 
b/libavutil/hwcontext_videotoolbox.c
index fe469dc161..823cf9a8ee 100644
--- a/libavutil/hwcontext_videotoolbox.c
+++ b/libavutil/hwcontext_videotoolbox.c
@@ -34,6 +34,10 @@
 #include "pixdesc.h"
 
 typedef struct VTFramesContext {
+/**
+ * The public AVVTFramesContext. See hwcontext_videotoolbox.h for it.
+ */
+AVVTFramesContext p;
 CVPixelBufferPoolRef pool;
 } VTFramesContext;
 
@@ -176,12 +180,12 @@ uint32_t av_map_videotoolbox_format_from_pixfmt2(enum 
AVPixelFormat pix_fmt, boo
 
 static int vt_pool_alloc(AVHWFramesContext *ctx)
 {
-VTFramesContext *fctx = ctx->internal->priv;
+VTFramesContext *fctx = ctx->hwctx;
+AVVTFramesContext *hw_ctx = &fctx->p;
 CVReturn err;
 CFNumberRef w, h, pixfmt;
 uint32_t cv_pixfmt;
 CFMutableDictionaryRef attributes, iosurface_properties;
-AVVTFramesContext *hw_ctx = ctx->hwctx;
 
 attributes = CFDictionaryCreateMutable(
 NULL,
@@ -237,7 +241,7 @@ static AVBufferRef *vt_pool_alloc_buffer(void *opaque, 
size_t size)
 AVBufferRef *buf;
 CVReturn err;
 AVHWFramesContext *ctx = opaque;
-VTFramesContext *fctx = ctx->internal->priv;
+VTFramesContext *fctx = ctx->hwctx;
 
 err = CVPixelBufferPoolCreatePixelBuffer(
 NULL,
@@ -260,7 +264,7 @@ static AVBufferRef *vt_pool_alloc_buffer(void *opaque, 
size_t size)
 
 static void vt_frames_uninit(AVHWFramesContext *ctx)
 {
-VTFramesContext *fctx = ctx->internal->priv;
+VTFramesContext *fctx = ctx->hwctx;
 if (fctx->pool) {
 CVPixelBufferPoolRelease(fctx->pool);
 fctx->pool = NULL;
@@ -763,10 +767,9 @@ const HWContextType ff_hwcontext_type_videotoolbox = {
 .type = AV_HWDEVICE_TYPE_VIDEOTOOLBOX,
 .name = "videotoolbox",
 
-.frames_priv_size = sizeof(VTFramesContext),
+.frames_hwctx_size= sizeof(VTFramesContext),
 
 .device_create= vt_device_create,
-.frames_hwctx_size= sizeof(AVVTFramesContext),
 .frames_init  = vt_frames_init,
 .frames_get_buffer= vt_get_buffer,
 .frames_get_constraints = vt_frames_get_constraints,
-- 
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 14/23] avutil/hwcontext_opencl: Allocate pub and priv frames hwctx together

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to OpenCLFramesContext as one no longer has to
go through AVHWFramesInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_opencl.c | 38 
 1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index 54c050ab40..c5af1aec74 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -138,6 +138,11 @@ typedef struct OpenCLDeviceContext {
 } OpenCLDeviceContext;
 
 typedef struct OpenCLFramesContext {
+/**
+ * The public AVOpenCLFramesContext. See hwcontext_opencl.h for it.
+ */
+AVOpenCLFramesContext p;
+
 // Command queue used for transfer/mapping operations on this frames
 // context.  If the user supplies one, this is a reference to it.
 // Otherwise, it is a reference to the default command queue for the
@@ -1689,9 +1694,9 @@ fail:
 
 static int opencl_frames_init_command_queue(AVHWFramesContext *hwfc)
 {
-AVOpenCLFramesContext *hwctx = hwfc->hwctx;
+OpenCLFramesContext*priv = hwfc->hwctx;
+AVOpenCLFramesContext *hwctx = &priv->p;
 OpenCLDeviceContext *devpriv = hwfc->device_ctx->hwctx;
-OpenCLFramesContext*priv = hwfc->internal->priv;
 cl_int cle;
 
 priv->command_queue = hwctx->command_queue ? hwctx->command_queue
@@ -1721,7 +1726,7 @@ static int opencl_frames_init(AVHWFramesContext *hwfc)
 
 static void opencl_frames_uninit(AVHWFramesContext *hwfc)
 {
-OpenCLFramesContext *priv = hwfc->internal->priv;
+OpenCLFramesContext *priv = hwfc->hwctx;
 cl_int cle;
 
 #if HAVE_OPENCL_DXVA2 || HAVE_OPENCL_D3D11
@@ -1815,7 +1820,7 @@ static int opencl_wait_events(AVHWFramesContext *hwfc,
 static int opencl_transfer_data_from(AVHWFramesContext *hwfc,
  AVFrame *dst, const AVFrame *src)
 {
-OpenCLFramesContext *priv = hwfc->internal->priv;
+OpenCLFramesContext *priv = hwfc->hwctx;
 cl_image_format image_format;
 cl_image_desc image_desc;
 cl_int cle;
@@ -1870,7 +1875,7 @@ static int opencl_transfer_data_from(AVHWFramesContext 
*hwfc,
 static int opencl_transfer_data_to(AVHWFramesContext *hwfc,
AVFrame *dst, const AVFrame *src)
 {
-OpenCLFramesContext *priv = hwfc->internal->priv;
+OpenCLFramesContext *priv = hwfc->hwctx;
 cl_image_format image_format;
 cl_image_desc image_desc;
 cl_int cle;
@@ -1932,7 +1937,7 @@ typedef struct OpenCLMapping {
 static void opencl_unmap_frame(AVHWFramesContext *hwfc,
HWMapDescriptor *hwmap)
 {
-OpenCLFramesContext *priv = hwfc->internal->priv;
+OpenCLFramesContext *priv = hwfc->hwctx;
 OpenCLMapping *map = hwmap->priv;
 cl_event events[AV_NUM_DATA_POINTERS];
 int p, e;
@@ -1961,7 +1966,7 @@ static void opencl_unmap_frame(AVHWFramesContext *hwfc,
 static int opencl_map_frame(AVHWFramesContext *hwfc, AVFrame *dst,
 const AVFrame *src, int flags)
 {
-OpenCLFramesContext *priv = hwfc->internal->priv;
+OpenCLFramesContext *priv = hwfc->hwctx;
 cl_map_flags map_flags;
 cl_image_format image_format;
 cl_image_desc image_desc;
@@ -2217,7 +,7 @@ static void opencl_unmap_from_qsv(AVHWFramesContext 
*dst_fc,
 {
 AVOpenCLFrameDescriptor*desc = hwmap->priv;
 OpenCLDeviceContext *device_priv = dst_fc->device_ctx->hwctx;
-OpenCLFramesContext *frames_priv = dst_fc->internal->priv;
+OpenCLFramesContext *frames_priv = dst_fc->hwctx;
 cl_event event;
 cl_int cle;
 int p;
@@ -2253,7 +2258,7 @@ static int opencl_map_from_qsv(AVHWFramesContext *dst_fc, 
AVFrame *dst,
 (AVHWFramesContext*)src->hw_frames_ctx->data;
 OpenCLDeviceContext *device_priv = dst_fc->device_ctx->hwctx;
 AVOpenCLDeviceContext   *dst_dev = &device_priv->p;
-OpenCLFramesContext *frames_priv = dst_fc->internal->priv;
+OpenCLFramesContext *frames_priv = dst_fc->hwctx;
 AVOpenCLFrameDescriptor *desc;
 VASurfaceID va_surface;
 cl_mem_flags cl_flags;
@@ -2351,7 +2356,7 @@ static void opencl_unmap_from_dxva2(AVHWFramesContext 
*dst_fc,
 {
 AVOpenCLFrameDescriptor*desc = hwmap->priv;
 OpenCLDeviceContext *device_priv = dst_fc->device_ctx->hwctx;
-OpenCLFramesContext *frames_priv = dst_fc->internal->priv;
+OpenCLFramesContext *frames_priv = dst_fc->hwctx;
 cl_event event;
 cl_int cle;
 
@@ -2376,7 +2381,7 @@ static int opencl_map_from_dxva2(AVHWFramesContext 
*dst_fc, AVFrame *dst,
 (AVHWFramesContext*)src->hw_frames_ctx->data;
 AVDXVA2FramesContext  *src_hwctx = src_fc->hwctx;
 OpenCLDeviceContext *device_priv = dst_fc->device_ctx->hwctx;
-OpenCLFramesContext *frames_priv = dst_fc->internal->priv;
+OpenCLFramesContext *frames_priv = dst_fc->hwctx;
 AVOpenCLFrameDescriptor

[FFmpeg-devel] [PATCH 15/23] avutil/hwcontext_qsv: Allocate pub and priv frames hwctx together

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to QSVFramesContext as one no longer has to
go through AVHWFramesInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_qsv.c | 46 +--
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 99d974f25f..f524a663b1 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -85,6 +85,11 @@ typedef struct QSVDeviceContext {
 } QSVDeviceContext;
 
 typedef struct QSVFramesContext {
+/**
+ * The public AVQSVFramesContext. See hwcontext_qsv.h for it.
+ */
+AVQSVFramesContext p;
+
 mfxSession session_download;
 atomic_int session_download_init;
 mfxSession session_upload;
@@ -329,7 +334,7 @@ static int qsv_device_init(AVHWDeviceContext *ctx)
 
 static void qsv_frames_uninit(AVHWFramesContext *ctx)
 {
-QSVFramesContext *s = ctx->internal->priv;
+QSVFramesContext *s = ctx->hwctx;
 
 if (s->session_download) {
 MFXVideoVPP_Close(s->session_download);
@@ -367,8 +372,8 @@ static void qsv_pool_release_dummy(void *opaque, uint8_t 
*data)
 static AVBufferRef *qsv_pool_alloc(void *opaque, size_t size)
 {
 AVHWFramesContext*ctx = (AVHWFramesContext*)opaque;
-QSVFramesContext   *s = ctx->internal->priv;
-AVQSVFramesContext *hwctx = ctx->hwctx;
+QSVFramesContext   *s = ctx->hwctx;
+AVQSVFramesContext *hwctx = &s->p;
 
 if (s->nb_surfaces_used < hwctx->nb_surfaces) {
 s->nb_surfaces_used++;
@@ -381,9 +386,9 @@ static AVBufferRef *qsv_pool_alloc(void *opaque, size_t 
size)
 
 static int qsv_init_child_ctx(AVHWFramesContext *ctx)
 {
-AVQSVFramesContext *hwctx = ctx->hwctx;
-QSVFramesContext   *s = ctx->internal->priv;
 QSVDeviceContext *device_priv = ctx->device_ctx->hwctx;
+QSVFramesContext   *s = ctx->hwctx;
+AVQSVFramesContext *hwctx = &s->p;
 
 AVBufferRef *child_device_ref = NULL;
 AVBufferRef *child_frames_ref = NULL;
@@ -562,8 +567,8 @@ static int qsv_init_surface(AVHWFramesContext *ctx, 
mfxFrameSurface1 *surf)
 
 static int qsv_init_pool(AVHWFramesContext *ctx, uint32_t fourcc)
 {
-QSVFramesContext  *s = ctx->internal->priv;
-AVQSVFramesContext *frames_hwctx = ctx->hwctx;
+QSVFramesContext  *s = ctx->hwctx;
+AVQSVFramesContext *frames_hwctx = &s->p;
 
 int i, ret = 0;
 
@@ -615,8 +620,8 @@ static mfxStatus frame_alloc(mfxHDL pthis, 
mfxFrameAllocRequest *req,
  mfxFrameAllocResponse *resp)
 {
 AVHWFramesContext*ctx = pthis;
-QSVFramesContext   *s = ctx->internal->priv;
-AVQSVFramesContext *hwctx = ctx->hwctx;
+QSVFramesContext   *s = ctx->hwctx;
+AVQSVFramesContext *hwctx = &s->p;
 mfxFrameInfo *i  = &req->Info;
 mfxFrameInfo *i1 = &hwctx->surfaces[0].Info;
 
@@ -1133,7 +1138,7 @@ static int qsv_init_internal_session(AVHWFramesContext 
*ctx,
 void **loader = &hwctx->loader;
 
 #if QSV_HAVE_OPAQUE
-QSVFramesContext  *s = ctx->internal->priv;
+QSVFramesContext  *s = ctx->hwctx;
 opaque = !!(frames_hwctx->frame_type & MFX_MEMTYPE_OPAQUE_FRAME);
 #endif
 
@@ -1210,8 +1215,8 @@ fail:
 
 static int qsv_frames_init(AVHWFramesContext *ctx)
 {
-QSVFramesContext  *s = ctx->internal->priv;
-AVQSVFramesContext *frames_hwctx = ctx->hwctx;
+QSVFramesContext  *s = ctx->hwctx;
+AVQSVFramesContext *frames_hwctx = &s->p;
 
 int opaque = 0;
 
@@ -1387,7 +1392,7 @@ static int qsv_frames_derive_from(AVHWFramesContext 
*dst_ctx,
 static int qsv_map_from(AVHWFramesContext *ctx,
 AVFrame *dst, const AVFrame *src, int flags)
 {
-QSVFramesContext *s = ctx->internal->priv;
+QSVFramesContext *s = ctx->hwctx;
 mfxFrameSurface1 *surf = (mfxFrameSurface1*)src->data[3];
 AVHWFramesContext *child_frames_ctx;
 const AVPixFmtDescriptor *desc;
@@ -1490,7 +1495,7 @@ fail:
 static int qsv_transfer_data_child(AVHWFramesContext *ctx, AVFrame *dst,
const AVFrame *src)
 {
-QSVFramesContext *s = ctx->internal->priv;
+QSVFramesContext *s = ctx->hwctx;
 AVHWFramesContext *child_frames_ctx = 
(AVHWFramesContext*)s->child_frames_ref->data;
 int download = !!src->hw_frames_ctx;
 mfxFrameSurface1 *surf = (mfxFrameSurface1*)(download ? src->data[3] : 
dst->data[3]);
@@ -1592,7 +1597,7 @@ static int map_frame_to_surface(const AVFrame *frame, 
mfxFrameSurface1 *surface)
 
 static int qsv_internal_session_check_init(AVHWFramesContext *ctx, int upload)
 {
-QSVFramesContext *s = ctx->internal->priv;
+QSVFramesContext *s = ctx->hwctx;
 atomic_int *inited  = upload ? &s->session_upload_init : 
&s->session_download_init;
 mfxSession *session = upload ? &s->se

[FFmpeg-devel] [PATCH 16/23] avutil/hwcontext_dxva2: Allocate pub and priv frames hwctx together

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to DXVA2FramesContext as one no longer has to
go through AVHWFramesInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_dxva2.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/libavutil/hwcontext_dxva2.c b/libavutil/hwcontext_dxva2.c
index 2c11f151ff..0922776342 100644
--- a/libavutil/hwcontext_dxva2.c
+++ b/libavutil/hwcontext_dxva2.c
@@ -57,6 +57,11 @@ typedef struct DXVA2Mapping {
 } DXVA2Mapping;
 
 typedef struct DXVA2FramesContext {
+/**
+ * The public AVDXVA2FramesContext. See hwcontext_dxva2.h for it.
+ */
+AVDXVA2FramesContext p;
+
 IDirect3DSurface9 **surfaces_internal;
 int  nb_surfaces_used;
 
@@ -99,8 +104,8 @@ DEFINE_GUID(video_processor_service, 0xfc51a552, 0xd5e7, 
0x11d9, 0xaf, 0x55, 0x0
 static void dxva2_frames_uninit(AVHWFramesContext *ctx)
 {
 AVDXVA2DeviceContext *device_hwctx = ctx->device_ctx->hwctx;
-AVDXVA2FramesContext *frames_hwctx = ctx->hwctx;
-DXVA2FramesContext *s = ctx->internal->priv;
+DXVA2FramesContext  *s = ctx->hwctx;
+AVDXVA2FramesContext *frames_hwctx = &s->p;
 int i;
 
 if (frames_hwctx->decoder_to_release)
@@ -135,8 +140,8 @@ static void dxva2_pool_release_dummy(void *opaque, uint8_t 
*data)
 static AVBufferRef *dxva2_pool_alloc(void *opaque, size_t size)
 {
 AVHWFramesContext  *ctx = (AVHWFramesContext*)opaque;
-DXVA2FramesContext   *s = ctx->internal->priv;
-AVDXVA2FramesContext *hwctx = ctx->hwctx;
+DXVA2FramesContext   *s = ctx->hwctx;
+AVDXVA2FramesContext *hwctx = &s->p;
 
 if (s->nb_surfaces_used < hwctx->nb_surfaces) {
 s->nb_surfaces_used++;
@@ -149,9 +154,9 @@ static AVBufferRef *dxva2_pool_alloc(void *opaque, size_t 
size)
 
 static int dxva2_init_pool(AVHWFramesContext *ctx)
 {
-AVDXVA2FramesContext *frames_hwctx = ctx->hwctx;
 AVDXVA2DeviceContext *device_hwctx = ctx->device_ctx->hwctx;
-DXVA2FramesContext  *s = ctx->internal->priv;
+DXVA2FramesContext  *s = ctx->hwctx;
+AVDXVA2FramesContext *frames_hwctx = &s->p;
 int decode = (frames_hwctx->surface_type == 
DXVA2_VideoDecoderRenderTarget);
 
 int i;
@@ -216,8 +221,8 @@ static int dxva2_init_pool(AVHWFramesContext *ctx)
 
 static int dxva2_frames_init(AVHWFramesContext *ctx)
 {
-AVDXVA2FramesContext *hwctx = ctx->hwctx;
-DXVA2FramesContext   *s = ctx->internal->priv;
+DXVA2FramesContext   *s = ctx->hwctx;
+AVDXVA2FramesContext *hwctx = &s->p;
 int ret;
 
 if (hwctx->surface_type != DXVA2_VideoDecoderRenderTarget &&
@@ -586,8 +591,7 @@ const HWContextType ff_hwcontext_type_dxva2 = {
 .name = "DXVA2",
 
 .device_hwctx_size= sizeof(AVDXVA2DeviceContext),
-.frames_hwctx_size= sizeof(AVDXVA2FramesContext),
-.frames_priv_size = sizeof(DXVA2FramesContext),
+.frames_hwctx_size= sizeof(DXVA2FramesContext),
 
 .device_create= dxva2_device_create,
 .frames_init  = dxva2_frames_init,
-- 
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 17/23] avutil/hwcontext_d3d11va: Allocate pub and priv frames hwctx together

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to D3D11VAFramesContext as one no longer has to
go through AVHWFramesInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_d3d11va.c | 34 +++---
 1 file changed, 19 insertions(+), 15 deletions(-)

diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 2fd3561c88..19fcf37a84 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -72,6 +72,11 @@ static av_cold void load_functions(void)
 }
 
 typedef struct D3D11VAFramesContext {
+/**
+ * The public AVD3D11VAFramesContext. See hwcontext_d3d11va.h for it.
+ */
+AVD3D11VAFramesContext p;
+
 int nb_surfaces;
 int nb_surfaces_used;
 
@@ -113,8 +118,8 @@ static void d3d11va_default_unlock(void *ctx)
 
 static void d3d11va_frames_uninit(AVHWFramesContext *ctx)
 {
-AVD3D11VAFramesContext *frames_hwctx = ctx->hwctx;
-D3D11VAFramesContext *s = ctx->internal->priv;
+D3D11VAFramesContext *s = ctx->hwctx;
+AVD3D11VAFramesContext *frames_hwctx = &s->p;
 
 if (frames_hwctx->texture)
 ID3D11Texture2D_Release(frames_hwctx->texture);
@@ -169,8 +174,8 @@ static AVBufferRef *wrap_texture_buf(AVHWFramesContext 
*ctx, ID3D11Texture2D *te
 {
 AVBufferRef *buf;
 AVD3D11FrameDescriptor *desc = av_mallocz(sizeof(*desc));
-D3D11VAFramesContext  *s = ctx->internal->priv;
-AVD3D11VAFramesContext *frames_hwctx = ctx->hwctx;
+D3D11VAFramesContext  *s = ctx->hwctx;
+AVD3D11VAFramesContext *frames_hwctx = &s->p;
 if (!desc) {
 ID3D11Texture2D_Release(tex);
 return NULL;
@@ -206,8 +211,8 @@ static AVBufferRef *wrap_texture_buf(AVHWFramesContext 
*ctx, ID3D11Texture2D *te
 
 static AVBufferRef *d3d11va_alloc_single(AVHWFramesContext *ctx)
 {
-D3D11VAFramesContext   *s = ctx->internal->priv;
-AVD3D11VAFramesContext *hwctx = ctx->hwctx;
+D3D11VAFramesContext   *s = ctx->hwctx;
+AVD3D11VAFramesContext *hwctx = &s->p;
 AVD3D11VADeviceContext *device_hwctx = ctx->device_ctx->hwctx;
 HRESULT hr;
 ID3D11Texture2D *tex;
@@ -235,8 +240,8 @@ static AVBufferRef *d3d11va_alloc_single(AVHWFramesContext 
*ctx)
 static AVBufferRef *d3d11va_pool_alloc(void *opaque, size_t size)
 {
 AVHWFramesContext*ctx = (AVHWFramesContext*)opaque;
-D3D11VAFramesContext   *s = ctx->internal->priv;
-AVD3D11VAFramesContext *hwctx = ctx->hwctx;
+D3D11VAFramesContext   *s = ctx->hwctx;
+AVD3D11VAFramesContext *hwctx = &s->p;
 D3D11_TEXTURE2D_DESC  texDesc;
 
 if (!hwctx->texture)
@@ -255,9 +260,9 @@ static AVBufferRef *d3d11va_pool_alloc(void *opaque, size_t 
size)
 
 static int d3d11va_frames_init(AVHWFramesContext *ctx)
 {
-AVD3D11VAFramesContext *hwctx= ctx->hwctx;
 AVD3D11VADeviceContext *device_hwctx = ctx->device_ctx->hwctx;
-D3D11VAFramesContext  *s = ctx->internal->priv;
+D3D11VAFramesContext  *s = ctx->hwctx;
+AVD3D11VAFramesContext*hwctx = &s->p;
 
 int i;
 HRESULT hr;
@@ -345,7 +350,7 @@ static int d3d11va_transfer_get_formats(AVHWFramesContext 
*ctx,
 enum AVHWFrameTransferDirection dir,
 enum AVPixelFormat **formats)
 {
-D3D11VAFramesContext *s = ctx->internal->priv;
+D3D11VAFramesContext *s = ctx->hwctx;
 enum AVPixelFormat *fmts;
 
 fmts = av_malloc_array(2, sizeof(*fmts));
@@ -367,7 +372,7 @@ static int d3d11va_transfer_get_formats(AVHWFramesContext 
*ctx,
 static int d3d11va_create_staging_texture(AVHWFramesContext *ctx, DXGI_FORMAT 
format)
 {
 AVD3D11VADeviceContext *device_hwctx = ctx->device_ctx->hwctx;
-D3D11VAFramesContext  *s = ctx->internal->priv;
+D3D11VAFramesContext  *s = ctx->hwctx;
 HRESULT hr;
 D3D11_TEXTURE2D_DESC texDesc = {
 .Width  = ctx->width,
@@ -407,7 +412,7 @@ static int d3d11va_transfer_data(AVHWFramesContext *ctx, 
AVFrame *dst,
  const AVFrame *src)
 {
 AVD3D11VADeviceContext *device_hwctx = ctx->device_ctx->hwctx;
-D3D11VAFramesContext  *s = ctx->internal->priv;
+D3D11VAFramesContext  *s = ctx->hwctx;
 int download = src->format == AV_PIX_FMT_D3D11;
 const AVFrame *frame = download ? src : dst;
 const AVFrame *other = download ? dst : src;
@@ -696,8 +701,7 @@ const HWContextType ff_hwcontext_type_d3d11va = {
 .name = "D3D11VA",
 
 .device_hwctx_size= sizeof(AVD3D11VADeviceContext),
-.frames_hwctx_size= sizeof(AVD3D11VAFramesContext),
-.frames_priv_size = sizeof(D3D11VAFramesContext),
+.frames_hwctx_size= sizeof(D3D11VAFramesContext),
 
 .device_create= d3d11va_device_create,
 .device_init   

[FFmpeg-devel] [PATCH 18/23] avutil/hwcontext_d3d12va: Allocate pub and priv frames hwctx together

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to D3D12VAFramesContext as one no longer has to
go through AVHWFramesInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_d3d12va.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/libavutil/hwcontext_d3d12va.c b/libavutil/hwcontext_d3d12va.c
index 6b4cd22899..16c07868f3 100644
--- a/libavutil/hwcontext_d3d12va.c
+++ b/libavutil/hwcontext_d3d12va.c
@@ -36,6 +36,11 @@
 typedef HRESULT(WINAPI *PFN_CREATE_DXGI_FACTORY2)(UINT Flags, REFIID riid, 
void **ppFactory);
 
 typedef struct D3D12VAFramesContext {
+/**
+ * The public AVD3D12VAFramesContext. See hwcontext_d3d12va.h for it.
+ */
+AVD3D12VAFramesContext p;
+
 ID3D12Resource*staging_download_buffer;
 ID3D12Resource*staging_upload_buffer;
 ID3D12CommandQueue*command_queue;
@@ -101,7 +106,7 @@ static int 
d3d12va_create_staging_buffer_resource(AVHWFramesContext *ctx, D3D12_
   ID3D12Resource **ppResource, 
int download)
 {
 AVD3D12VADeviceContext *device_hwctx = ctx->device_ctx->hwctx;
-D3D12VAFramesContext   *s= ctx->internal->priv;
+D3D12VAFramesContext   *s= ctx->hwctx;
 D3D12_HEAP_PROPERTIES props = { .Type = download ? 
D3D12_HEAP_TYPE_READBACK : D3D12_HEAP_TYPE_UPLOAD };
 D3D12_RESOURCE_DESC desc = {
 .Dimension  = D3D12_RESOURCE_DIMENSION_BUFFER,
@@ -128,8 +133,8 @@ static int 
d3d12va_create_staging_buffer_resource(AVHWFramesContext *ctx, D3D12_
 static int d3d12va_create_helper_objects(AVHWFramesContext *ctx)
 {
 AVD3D12VADeviceContext *device_hwctx = ctx->device_ctx->hwctx;
-AVD3D12VAFramesContext *frames_hwctx = ctx->hwctx;
-D3D12VAFramesContext   *s= ctx->internal->priv;
+D3D12VAFramesContext   *s= ctx->hwctx;
+AVD3D12VAFramesContext *frames_hwctx = &s->p;
 
 D3D12_COMMAND_QUEUE_DESC queue_desc = {
 .Type = D3D12_COMMAND_LIST_TYPE_COPY,
@@ -168,7 +173,7 @@ fail:
 
 static void d3d12va_frames_uninit(AVHWFramesContext *ctx)
 {
-D3D12VAFramesContext *s = ctx->internal->priv;
+D3D12VAFramesContext *s = ctx->hwctx;
 
 D3D12_OBJECT_RELEASE(s->sync_ctx.fence);
 if (s->sync_ctx.event)
@@ -345,8 +350,8 @@ static int d3d12va_transfer_data(AVHWFramesContext *ctx, 
AVFrame *dst,
  const AVFrame *src)
 {
 AVD3D12VADeviceContext *hwctx= ctx->device_ctx->hwctx;
-AVD3D12VAFramesContext *frames_hwctx = ctx->hwctx;
-D3D12VAFramesContext   *s= ctx->internal->priv;
+D3D12VAFramesContext   *s= ctx->hwctx;
+AVD3D12VAFramesContext *frames_hwctx = &s->p;
 
 int ret;
 int download = src->format == AV_PIX_FMT_D3D12;
@@ -675,8 +680,7 @@ const HWContextType ff_hwcontext_type_d3d12va = {
 .name   = "D3D12VA",
 
 .device_hwctx_size  = sizeof(D3D12VADevicePriv),
-.frames_hwctx_size  = sizeof(AVD3D12VAFramesContext),
-.frames_priv_size   = sizeof(D3D12VAFramesContext),
+.frames_hwctx_size  = sizeof(D3D12VAFramesContext),
 
 .device_create  = d3d12va_device_create,
 .device_init= d3d12va_device_init,
-- 
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 19/23] avutil/hwcontext: Clarify documentation of AVHWFramesContext.hwctx

2024-02-11 Thread Andreas Rheinhardt
Correct the names of the format-specific headers (not hwframe_*.h)
and clarify that the user shall ignore this field if there is no
public context associated with it.
In particular, this allows to use this field for the private context
alone if there is no public context. This can't break conforming
API users, because they always have to live with the possibility
that a new public context has been introduced.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext.h | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index d91391294b..091bceb2f9 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -145,9 +145,12 @@ typedef struct AVHWFramesContext {
  * The format-specific data, allocated and freed automatically along with
  * this context.
  *
- * Should be cast by the user to the format-specific context defined in the
- * corresponding header (hwframe_*.h) and filled as described in the
- * documentation before calling av_hwframe_ctx_init().
+ * The user shall ignore this field if the corresponding format-specific
+ * header (hwcontext_*.h) does not define a context to be used as
+ * AVHWFramesContext.hwctx.
+ *
+ * Otherwise, it should be cast by the user to said context and filled
+ * as described in the documentation before calling av_hwframe_ctx_init().
  *
  * After any frames using this context are created, the contents of this
  * struct should not be modified by the caller.
-- 
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 20/23] avutil/hwcontext_vdpau: Don't use AVHWFramesInternal.priv

2024-02-11 Thread Andreas Rheinhardt
Use AVHWFramesContext.hwctx instead.
This simplifies access to VDPAUFramesContext as one no longer has
to go through AVHWFramesInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_vdpau.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavutil/hwcontext_vdpau.c b/libavutil/hwcontext_vdpau.c
index 016300db1e..0a1a33f8b1 100644
--- a/libavutil/hwcontext_vdpau.c
+++ b/libavutil/hwcontext_vdpau.c
@@ -233,7 +233,7 @@ static void vdpau_buffer_free(void *opaque, uint8_t *data)
 static AVBufferRef *vdpau_pool_alloc(void *opaque, size_t size)
 {
 AVHWFramesContext *ctx = opaque;
-VDPAUFramesContext   *priv = ctx->internal->priv;
+VDPAUFramesContext   *priv = ctx->hwctx;
 VDPAUDeviceContext*device_priv = ctx->device_ctx->hwctx;
 AVVDPAUDeviceContext *device_hwctx = &device_priv->p;
 
@@ -261,7 +261,7 @@ static AVBufferRef *vdpau_pool_alloc(void *opaque, size_t 
size)
 static int vdpau_frames_init(AVHWFramesContext *ctx)
 {
 VDPAUDeviceContext *device_priv = ctx->device_ctx->hwctx;
-VDPAUFramesContext*priv = ctx->internal->priv;
+VDPAUFramesContext*priv = ctx->hwctx;
 
 int i;
 
@@ -311,7 +311,7 @@ static int vdpau_transfer_get_formats(AVHWFramesContext 
*ctx,
   enum AVHWFrameTransferDirection dir,
   enum AVPixelFormat **formats)
 {
-VDPAUFramesContext *priv  = ctx->internal->priv;
+VDPAUFramesContext *priv  = ctx->hwctx;
 
 enum AVPixelFormat *fmts;
 
@@ -334,7 +334,7 @@ static int vdpau_transfer_get_formats(AVHWFramesContext 
*ctx,
 static int vdpau_transfer_data_from(AVHWFramesContext *ctx, AVFrame *dst,
 const AVFrame *src)
 {
-VDPAUFramesContext *priv = ctx->internal->priv;
+VDPAUFramesContext *priv = ctx->hwctx;
 VdpVideoSurface surf = (VdpVideoSurface)(uintptr_t)src->data[3];
 
 void *data[3];
@@ -392,7 +392,7 @@ static int vdpau_transfer_data_from(AVHWFramesContext *ctx, 
AVFrame *dst,
 static int vdpau_transfer_data_to(AVHWFramesContext *ctx, AVFrame *dst,
   const AVFrame *src)
 {
-VDPAUFramesContext *priv = ctx->internal->priv;
+VDPAUFramesContext *priv = ctx->hwctx;
 VdpVideoSurface surf = (VdpVideoSurface)(uintptr_t)dst->data[3];
 
 const void *data[3];
@@ -514,7 +514,7 @@ const HWContextType ff_hwcontext_type_vdpau = {
 .name = "VDPAU",
 
 .device_hwctx_size= sizeof(VDPAUDeviceContext),
-.frames_priv_size = sizeof(VDPAUFramesContext),
+.frames_hwctx_size= sizeof(VDPAUFramesContext),
 
 #if HAVE_VDPAU_X11
 .device_create= vdpau_device_create,
-- 
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 21/23] avutil/hwcontext_cuda: Don't use AVHWFramesInternal.priv

2024-02-11 Thread Andreas Rheinhardt
Use AVHWFramesContext.hwctx instead.
This simplifies accesses to VDPAUFramesContext as one no longer has
to go through AVHWFramesInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_cuda.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index 0312d3b9d7..1c61b36d69 100644
--- a/libavutil/hwcontext_cuda.c
+++ b/libavutil/hwcontext_cuda.c
@@ -130,7 +130,7 @@ static int cuda_frames_init(AVHWFramesContext *ctx)
 {
 AVHWDeviceContext *device_ctx = ctx->device_ctx;
 AVCUDADeviceContext*hwctx = device_ctx->hwctx;
-CUDAFramesContext   *priv = ctx->internal->priv;
+CUDAFramesContext   *priv = ctx->hwctx;
 CudaFunctions *cu = hwctx->internal->cuda_dl;
 int err, i;
 
@@ -175,7 +175,7 @@ static int cuda_frames_init(AVHWFramesContext *ctx)
 
 static int cuda_get_buffer(AVHWFramesContext *ctx, AVFrame *frame)
 {
-CUDAFramesContext *priv = ctx->internal->priv;
+CUDAFramesContext *priv = ctx->hwctx;
 int res;
 
 frame->buf[0] = av_buffer_pool_get(ctx->pool);
@@ -223,7 +223,7 @@ static int cuda_transfer_get_formats(AVHWFramesContext *ctx,
 static int cuda_transfer_data(AVHWFramesContext *ctx, AVFrame *dst,
  const AVFrame *src)
 {
-CUDAFramesContext   *priv = ctx->internal->priv;
+CUDAFramesContext   *priv = ctx->hwctx;
 AVHWDeviceContext *device_ctx = ctx->device_ctx;
 AVCUDADeviceContext*hwctx = device_ctx->hwctx;
 CudaFunctions *cu = hwctx->internal->cuda_dl;
@@ -563,7 +563,7 @@ const HWContextType ff_hwcontext_type_cuda = {
 .name = "CUDA",
 
 .device_hwctx_size= sizeof(AVCUDADeviceContext),
-.frames_priv_size = sizeof(CUDAFramesContext),
+.frames_hwctx_size= sizeof(CUDAFramesContext),
 
 .device_create= cuda_device_create,
 .device_derive= cuda_device_derive,
-- 
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 22/23] avutil/hwcontext_internal: Remove unused AVHWFramesInternal.priv

2024-02-11 Thread Andreas Rheinhardt
It is no longer used by any hwcontext, as they all allocate
their private data together with their public data and access
it via AVHWFramesContext.hwctx.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext.c  | 9 -
 libavutil/hwcontext_internal.h | 6 --
 2 files changed, 15 deletions(-)

diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index c962c19f3e..8ecefd2bc4 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -248,7 +248,6 @@ static void hwframe_ctx_free(void *opaque, uint8_t *data)
 av_buffer_unref(&ctx->device_ref);
 
 av_freep(&ctx->hwctx);
-av_freep(&ctx->internal->priv);
 av_freep(&ctx->internal);
 av_freep(&ctx);
 }
@@ -268,12 +267,6 @@ AVBufferRef *av_hwframe_ctx_alloc(AVBufferRef 
*device_ref_in)
 if (!ctx->internal)
 goto fail;
 
-if (hw_type->frames_priv_size) {
-ctx->internal->priv = av_mallocz(hw_type->frames_priv_size);
-if (!ctx->internal->priv)
-goto fail;
-}
-
 if (hw_type->frames_hwctx_size) {
 ctx->hwctx = av_mallocz(hw_type->frames_hwctx_size);
 if (!ctx->hwctx)
@@ -302,8 +295,6 @@ AVBufferRef *av_hwframe_ctx_alloc(AVBufferRef 
*device_ref_in)
 
 fail:
 av_buffer_unref(&device_ref);
-if (ctx->internal)
-av_freep(&ctx->internal->priv);
 av_freep(&ctx->internal);
 av_freep(&ctx->hwctx);
 av_freep(&ctx);
diff --git a/libavutil/hwcontext_internal.h b/libavutil/hwcontext_internal.h
index 3745867283..1476def1d7 100644
--- a/libavutil/hwcontext_internal.h
+++ b/libavutil/hwcontext_internal.h
@@ -53,11 +53,6 @@ typedef struct HWContextType {
  * i.e. AVHWFramesContext.hwctx
  */
 size_t frames_hwctx_size;
-/**
- * size of the private data, i.e.
- * AVHWFramesInternal.priv
- */
-size_t frames_priv_size;
 
 int  (*device_create)(AVHWDeviceContext *ctx, const char 
*device,
   AVDictionary *opts, int flags);
@@ -97,7 +92,6 @@ typedef struct HWContextType {
 
 struct AVHWFramesInternal {
 const HWContextType *hw_type;
-void*priv;
 
 AVBufferPool *pool_internal;
 
-- 
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 23/23] avutil/hwcontext: Allocate AVHWFramesCtx jointly with its internals

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of these structures coincide.
It has the advantage of allowing to remove AVHWFramesInternal
from the public header; given that AVHWFramesInternal.priv is no more,
most accesses to AVHWFramesInternal are no more; indeed, the only
field accessed of it outside of hwcontext.c is the internal frame pool,
making this commit very simple.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext.c  | 158 ++---
 libavutil/hwcontext.h  |   8 --
 libavutil/hwcontext_cuda.c |   5 +-
 libavutil/hwcontext_d3d11va.c  |   7 +-
 libavutil/hwcontext_d3d12va.c  |   4 +-
 libavutil/hwcontext_dxva2.c|   7 +-
 libavutil/hwcontext_internal.h |  14 ++-
 libavutil/hwcontext_opencl.c   |   4 +-
 libavutil/hwcontext_qsv.c  |   6 +-
 libavutil/hwcontext_vaapi.c|   6 +-
 libavutil/hwcontext_vdpau.c|   7 +-
 libavutil/hwcontext_videotoolbox.c |   4 +-
 libavutil/hwcontext_vulkan.c   |   8 +-
 13 files changed, 121 insertions(+), 117 deletions(-)

diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 8ecefd2bc4..a0192f4fa9 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -232,23 +232,23 @@ static const AVClass hwframe_ctx_class = {
 
 static void hwframe_ctx_free(void *opaque, uint8_t *data)
 {
-AVHWFramesContext *ctx = (AVHWFramesContext*)data;
+FFHWFramesContext *ctxi = (FFHWFramesContext*)data;
+AVHWFramesContext *ctx  = &ctxi->p;
 
-if (ctx->internal->pool_internal)
-av_buffer_pool_uninit(&ctx->internal->pool_internal);
+if (ctxi->pool_internal)
+av_buffer_pool_uninit(&ctxi->pool_internal);
 
-if (ctx->internal->hw_type->frames_uninit)
-ctx->internal->hw_type->frames_uninit(ctx);
+if (ctxi->hw_type->frames_uninit)
+ctxi->hw_type->frames_uninit(ctx);
 
 if (ctx->free)
 ctx->free(ctx);
 
-av_buffer_unref(&ctx->internal->source_frames);
+av_buffer_unref(&ctxi->source_frames);
 
 av_buffer_unref(&ctx->device_ref);
 
 av_freep(&ctx->hwctx);
-av_freep(&ctx->internal);
 av_freep(&ctx);
 }
 
@@ -256,16 +256,14 @@ AVBufferRef *av_hwframe_ctx_alloc(AVBufferRef 
*device_ref_in)
 {
 FFHWDeviceContext *device_ctx = (FFHWDeviceContext*)device_ref_in->data;
 const HWContextType  *hw_type = device_ctx->hw_type;
+FFHWFramesContext *ctxi;
 AVHWFramesContext *ctx;
 AVBufferRef *buf, *device_ref = NULL;
 
-ctx = av_mallocz(sizeof(*ctx));
-if (!ctx)
+ctxi = av_mallocz(sizeof(*ctxi));
+if (!ctxi)
 return NULL;
-
-ctx->internal = av_mallocz(sizeof(*ctx->internal));
-if (!ctx->internal)
-goto fail;
+ctx  = &ctxi->p;
 
 if (hw_type->frames_hwctx_size) {
 ctx->hwctx = av_mallocz(hw_type->frames_hwctx_size);
@@ -289,13 +287,12 @@ AVBufferRef *av_hwframe_ctx_alloc(AVBufferRef 
*device_ref_in)
 ctx->format = AV_PIX_FMT_NONE;
 ctx->sw_format  = AV_PIX_FMT_NONE;
 
-ctx->internal->hw_type = hw_type;
+ctxi->hw_type = hw_type;
 
 return buf;
 
 fail:
 av_buffer_unref(&device_ref);
-av_freep(&ctx->internal);
 av_freep(&ctx->hwctx);
 av_freep(&ctx);
 return NULL;
@@ -331,24 +328,25 @@ fail:
 
 int av_hwframe_ctx_init(AVBufferRef *ref)
 {
-AVHWFramesContext *ctx = (AVHWFramesContext*)ref->data;
+FFHWFramesContext *ctxi = (FFHWFramesContext*)ref->data;
+AVHWFramesContext *ctx  = &ctxi->p;
 const enum AVPixelFormat *pix_fmt;
 int ret;
 
-if (ctx->internal->source_frames) {
+if (ctxi->source_frames) {
 /* A derived frame context is already initialised. */
 return 0;
 }
 
 /* validate the pixel format */
-for (pix_fmt = ctx->internal->hw_type->pix_fmts; *pix_fmt != 
AV_PIX_FMT_NONE; pix_fmt++) {
+for (pix_fmt = ctxi->hw_type->pix_fmts; *pix_fmt != AV_PIX_FMT_NONE; 
pix_fmt++) {
 if (*pix_fmt == ctx->format)
 break;
 }
 if (*pix_fmt == AV_PIX_FMT_NONE) {
 av_log(ctx, AV_LOG_ERROR,
"The hardware pixel format '%s' is not supported by the device 
type '%s'\n",
-   av_get_pix_fmt_name(ctx->format), ctx->internal->hw_type->name);
+   av_get_pix_fmt_name(ctx->format), ctxi->hw_type->name);
 return AVERROR(ENOSYS);
 }
 
@@ -358,14 +356,14 @@ int av_hwframe_ctx_init(AVBufferRef *ref)
 return ret;
 
 /* format-specific init */
-if (ctx->internal->hw_type->frames_init) {
-ret = ctx->internal->hw_type->frames_init(ctx);
+if (ctxi->hw_type->frames_init) {
+ret = ctxi->hw_type->frames_init(ctx);
 if (ret < 0)
 goto fail;
 }
 
-if (ctx->internal->pool_internal && !ctx->pool)
-ctx->pool = ctx->internal->pool_internal;
+if (ctxi->pool_internal && !ctx->pool)
+ctx->pool = ctxi->pool_internal;
 
 /* preallocate the frames in the pool, if requested */
 if (ctx->initial_po

[FFmpeg-devel] [PATCH] lavc/texturedsp: require explicitly-set frame dimensions

2024-02-11 Thread Connor Worley
This change decouples the frame dimensions from avctx, which is useful
for DXV decoding, and fixes incorrect behavior in the existing
implementation.

Tested with `make fate THREADS=7` and
`make fate THREADS=7 THREAD_TYPE=slice`.

Signed-off-by: Connor Worley 
---
 libavcodec/dds.c |  3 +++
 libavcodec/dxv.c | 19 ++-
 libavcodec/dxvenc.c  |  3 +++
 libavcodec/hapdec.c  |  5 +
 libavcodec/hapenc.c  |  3 +++
 libavcodec/texturedsp.h  |  1 +
 libavcodec/texturedsp_template.c |  4 ++--
 libavcodec/vbndec.c  |  3 +++
 libavcodec/vbnenc.c  |  3 +++
 9 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/libavcodec/dds.c b/libavcodec/dds.c
index 67e2325a2a..83f51be802 100644
--- a/libavcodec/dds.c
+++ b/libavcodec/dds.c
@@ -339,6 +339,9 @@ static int parse_pixel_format(AVCodecContext *avctx)
 av_log(avctx, AV_LOG_ERROR, "Unsupported %s fourcc.\n", 
av_fourcc2str(fourcc));
 return AVERROR_INVALIDDATA;
 }
+
+ctx->dec.width  = avctx->coded_width;
+ctx->dec.height = avctx->coded_height;
 } else if (ctx->paletted) {
 if (bpp == 8) {
 avctx->pix_fmt = AV_PIX_FMT_PAL8;
diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c
index 2eca14c129..4eaa6dc224 100644
--- a/libavcodec/dxv.c
+++ b/libavcodec/dxv.c
@@ -843,7 +843,6 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame *frame,
 {
 DXVContext *ctx = avctx->priv_data;
 GetByteContext *gbc = &ctx->gbc;
-AVCodecContext cavctx = *avctx;
 TextureDSPThreadContext texdsp_ctx, ctexdsp_ctx;
 int (*decompress_tex)(AVCodecContext *avctx);
 const char *msgcomp, *msgtext;
@@ -854,9 +853,6 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame *frame,
 
 bytestream2_init(gbc, avpkt->data, avpkt->size);
 
-cavctx.coded_height = avctx->coded_height / 2;
-cavctx.coded_width  = avctx->coded_width  / 2;
-
 avctx->pix_fmt = AV_PIX_FMT_RGBA;
 avctx->colorspace = AVCOL_SPC_RGB;
 
@@ -943,7 +939,12 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame 
*frame,
 texdsp_ctx.slice_count  = av_clip(avctx->thread_count, 1,
   avctx->coded_height / TEXTURE_BLOCK_H);
 ctexdsp_ctx.slice_count = av_clip(avctx->thread_count, 1,
-  cavctx.coded_height / TEXTURE_BLOCK_H);
+  avctx->coded_height / 2 / 
TEXTURE_BLOCK_H);
+texdsp_ctx.width   = avctx->coded_width;
+texdsp_ctx.height  = avctx->coded_height;
+ctexdsp_ctx.width  = avctx->coded_width  / 2;
+ctexdsp_ctx.height = avctx->coded_height / 2;
+
 /* New header is 12 bytes long. */
 if (!old_type) {
 version_major = bytestream2_get_byte(gbc) - 1;
@@ -979,8 +980,8 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame *frame,
 if (avctx->pix_fmt != AV_PIX_FMT_RGBA) {
 int i;
 
-ctx->ctex_size = cavctx.coded_width  / ctexdsp_ctx.raw_ratio *
- cavctx.coded_height / TEXTURE_BLOCK_H *
+ctx->ctex_size = avctx->coded_width  / 2 / ctexdsp_ctx.raw_ratio *
+ avctx->coded_height / 2 / TEXTURE_BLOCK_H *
  ctexdsp_ctx.tex_ratio;
 
 ctx->op_size[0] = avctx->coded_width * avctx->coded_height / 16;
@@ -1022,13 +1023,13 @@ static int dxv_decode(AVCodecContext *avctx, AVFrame 
*frame,
 ctexdsp_ctx.tex_data.in= ctx->ctex_data;
 ctexdsp_ctx.frame_data.out = frame->data[2];
 ctexdsp_ctx.stride = frame->linesize[2];
-ret = ff_texturedsp_exec_decompress_threads(&cavctx, &ctexdsp_ctx);
+ret = ff_texturedsp_exec_decompress_threads(avctx, &ctexdsp_ctx);
 if (ret < 0)
 return ret;
 ctexdsp_ctx.tex_data.in= ctx->ctex_data + ctexdsp_ctx.tex_ratio / 
2;
 ctexdsp_ctx.frame_data.out = frame->data[1];
 ctexdsp_ctx.stride = frame->linesize[1];
-ret = ff_texturedsp_exec_decompress_threads(&cavctx, &ctexdsp_ctx);
+ret = ff_texturedsp_exec_decompress_threads(avctx, &ctexdsp_ctx);
 if (ret < 0)
 return ret;
 /* fallthrough */
diff --git a/libavcodec/dxvenc.c b/libavcodec/dxvenc.c
index bb2c2f8526..62ac812226 100644
--- a/libavcodec/dxvenc.c
+++ b/libavcodec/dxvenc.c
@@ -298,6 +298,9 @@ static av_cold int dxv_init(AVCodecContext *avctx)
 ctx->enc.tex_ratio;
 ctx->enc.slice_count = av_clip(avctx->thread_count, 1, avctx->height / 
TEXTURE_BLOCK_H);
 
+ctx->enc.width  = avctx->width;
+ctx->enc.height = avctx->height;
+
 ctx->tex_data = av_malloc(ctx->tex_size);
 if (!ctx->tex_data) {
 return AVERROR(ENOMEM);
diff --git a/libavcodec/hapdec.c b/libavcodec/hapdec.c
index 3a848e9f67..cca15afa15 100644
--- a/libavcodec/hapdec.c
+++ b/libavcodec/hapdec.c
@@ -399,6 +399,11 @@ static av_cold int hap_init(AVCodec

[FFmpeg-devel] [PATCH 07/23] avutil/hwcontext_opencl: Allocate pub and priv device hwctx together

2024-02-11 Thread Andreas Rheinhardt
This is possible because the lifetime of both coincide.
Besides reducing the number of allocations this also simplifies
access to OpenCLDeviceContext as one no longer has to
go through AVHWDeviceInternal.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_opencl.c | 50 +++-
 1 file changed, 27 insertions(+), 23 deletions(-)

diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index c1764ed098..54c050ab40 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -80,6 +80,11 @@ extern int ff_qsv_get_surface_base_handle(mfxFrameSurface1 
*surf,
 
 
 typedef struct OpenCLDeviceContext {
+/**
+ * The public AVOpenCLDeviceContext. See hwcontext_opencl.h for it.
+ */
+AVOpenCLDeviceContext p;
+
 // Default command queue to use for transfer/mapping operations on
 // the device.  If the user supplies one, this is a reference to it.
 // Otherwise, it is newly-created.
@@ -276,8 +281,8 @@ static int opencl_check_device_extension(cl_device_id 
device_id,
 static av_unused int opencl_check_extension(AVHWDeviceContext *hwdev,
 const char *name)
 {
-AVOpenCLDeviceContext *hwctx = hwdev->hwctx;
-OpenCLDeviceContext*priv = hwdev->internal->priv;
+OpenCLDeviceContext*priv = hwdev->hwctx;
+AVOpenCLDeviceContext *hwctx = &priv->p;
 
 if (opencl_check_platform_extension(priv->platform_id, name)) {
 av_log(hwdev, AV_LOG_DEBUG,
@@ -658,8 +663,8 @@ static int opencl_device_create(AVHWDeviceContext *hwdev, 
const char *device,
 
 static int opencl_device_init(AVHWDeviceContext *hwdev)
 {
-AVOpenCLDeviceContext *hwctx = hwdev->hwctx;
-OpenCLDeviceContext*priv = hwdev->internal->priv;
+OpenCLDeviceContext*priv = hwdev->hwctx;
+AVOpenCLDeviceContext *hwctx = &priv->p;
 cl_int cle;
 
 if (hwctx->command_queue) {
@@ -894,7 +899,7 @@ static int opencl_device_init(AVHWDeviceContext *hwdev)
 
 static void opencl_device_uninit(AVHWDeviceContext *hwdev)
 {
-OpenCLDeviceContext *priv = hwdev->internal->priv;
+OpenCLDeviceContext *priv = hwdev->hwctx;
 cl_int cle;
 
 if (priv->command_queue) {
@@ -1685,7 +1690,7 @@ fail:
 static int opencl_frames_init_command_queue(AVHWFramesContext *hwfc)
 {
 AVOpenCLFramesContext *hwctx = hwfc->hwctx;
-OpenCLDeviceContext *devpriv = hwfc->device_ctx->internal->priv;
+OpenCLDeviceContext *devpriv = hwfc->device_ctx->hwctx;
 OpenCLFramesContext*priv = hwfc->internal->priv;
 cl_int cle;
 
@@ -2079,8 +2084,8 @@ static int opencl_map_from_drm_beignet(AVHWFramesContext 
*dst_fc,
AVFrame *dst, const AVFrame *src,
int flags)
 {
-AVOpenCLDeviceContext *hwctx = dst_fc->device_ctx->hwctx;
-OpenCLDeviceContext*priv = dst_fc->device_ctx->internal->priv;
+OpenCLDeviceContext*priv = dst_fc->device_ctx->hwctx;
+AVOpenCLDeviceContext *hwctx = &priv->p;
 DRMBeignetToOpenCLMapping *mapping;
 const AVDRMFrameDescriptor *desc;
 cl_int cle;
@@ -2211,7 +2216,7 @@ static void opencl_unmap_from_qsv(AVHWFramesContext 
*dst_fc,
   HWMapDescriptor *hwmap)
 {
 AVOpenCLFrameDescriptor*desc = hwmap->priv;
-OpenCLDeviceContext *device_priv = dst_fc->device_ctx->internal->priv;
+OpenCLDeviceContext *device_priv = dst_fc->device_ctx->hwctx;
 OpenCLFramesContext *frames_priv = dst_fc->internal->priv;
 cl_event event;
 cl_int cle;
@@ -2246,8 +2251,8 @@ static int opencl_map_from_qsv(AVHWFramesContext *dst_fc, 
AVFrame *dst,
 {
 AVHWFramesContext *src_fc =
 (AVHWFramesContext*)src->hw_frames_ctx->data;
-AVOpenCLDeviceContext   *dst_dev = dst_fc->device_ctx->hwctx;
-OpenCLDeviceContext *device_priv = dst_fc->device_ctx->internal->priv;
+OpenCLDeviceContext *device_priv = dst_fc->device_ctx->hwctx;
+AVOpenCLDeviceContext   *dst_dev = &device_priv->p;
 OpenCLFramesContext *frames_priv = dst_fc->internal->priv;
 AVOpenCLFrameDescriptor *desc;
 VASurfaceID va_surface;
@@ -2345,7 +2350,7 @@ static void opencl_unmap_from_dxva2(AVHWFramesContext 
*dst_fc,
 HWMapDescriptor *hwmap)
 {
 AVOpenCLFrameDescriptor*desc = hwmap->priv;
-OpenCLDeviceContext *device_priv = dst_fc->device_ctx->internal->priv;
+OpenCLDeviceContext *device_priv = dst_fc->device_ctx->hwctx;
 OpenCLFramesContext *frames_priv = dst_fc->internal->priv;
 cl_event event;
 cl_int cle;
@@ -2370,7 +2375,7 @@ static int opencl_map_from_dxva2(AVHWFramesContext 
*dst_fc, AVFrame *dst,
 AVHWFramesContext *src_fc =
 (AVHWFramesContext*)src->hw_frames_ctx->data;
 AVDXVA2FramesContext  *src_hwctx = src_fc->hwctx;
-OpenCLDeviceContext *device_priv = dst_fc->device_ctx->internal->priv;
+OpenCLDeviceContext *device_priv = dst_fc->device_ctx-

Re: [FFmpeg-devel] [PATCH v2 3/3] lavc/dxv: remove ctx fields that can be derived from texdsp ctxs

2024-02-11 Thread Connor Worley
On Sun, Feb 11, 2024 at 9:41 AM James Almer  wrote:

> This set broke fate when using slice threading:
>
> https://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-threads-misc&time=20240211015448
>

https://ffmpeg.org//pipermail/ffmpeg-devel/2024-February/321317.html
contains a fix.

-- 
Connor Worley
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH] avformat/matroska: Add support for A_ATRAC/AT1

2024-02-11 Thread asivery via ffmpeg-devel
I apologize for not having responded earlier.
I've attached the updated patch.


>From 68c77320954e44a7f02e95537fc9a6436da7549c Mon Sep 17 00:00:00 2001
From: asivery 
Date: Sun, 11 Feb 2024 23:13:07 +0100
Subject: [PATCH] avformat/matroska: Add support for A_ATRAC/AT1

Signed-off-by: asivery 
---
 libavformat/matroska.c| 1 +
 libavformat/matroskadec.c | 8 
 libavformat/matroskaenc.c | 1 +
 3 files changed, 10 insertions(+)

diff --git a/libavformat/matroska.c b/libavformat/matroska.c
index 5878594e68..ae9ecc8207 100644
--- a/libavformat/matroska.c
+++ b/libavformat/matroska.c
@@ -53,6 +53,7 @@ const CodecTags ff_mkv_codec_tags[]={
 {"A_REAL/ATRC"  , AV_CODEC_ID_ATRAC3},
 {"A_REAL/COOK"  , AV_CODEC_ID_COOK},
 {"A_REAL/SIPR"  , AV_CODEC_ID_SIPR},
+{"A_ATRAC/AT1"  , AV_CODEC_ID_ATRAC1},
 {"A_TRUEHD" , AV_CODEC_ID_TRUEHD},
 {"A_TTA1"   , AV_CODEC_ID_TTA},
 {"A_VORBIS" , AV_CODEC_ID_VORBIS},
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 8f000f86be..1bb6e8605a 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2779,6 +2779,14 @@ static int mka_parse_audio_codec(MatroskaTrack *track, 
AVCodecParameters *par,
 return AVERROR(ENOMEM);
 break;
 }
+case AV_CODEC_ID_ATRAC1:
+/* ATRAC1 uses a constant frame size.
+ * Typical ATRAC1 streams are either mono or stereo.
+ * At most, ATRAC1 was used to store 8 channels of audio. */
+if (track->audio.channels > 8)
+return AVERROR_INVALIDDATA;
+par->block_align = track->audio.channels * 212;
+break;
 case AV_CODEC_ID_FLAC:
 if (track->codec_priv.size) {
 ret = matroska_parse_flac(s, track, extradata_offset);
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 1457a6890c..aa25657f8f 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -3483,6 +3483,7 @@ static const AVCodecTag additional_audio_tags[] = {
 { AV_CODEC_ID_QDM2,  0x },
 { AV_CODEC_ID_RA_144,0x },
 { AV_CODEC_ID_TRUEHD,0x },
+{ AV_CODEC_ID_ATRAC1,0x },
 { AV_CODEC_ID_NONE,  0x }
 };
 
-- 
2.34.1





On Friday, August 4th, 2023 at 7:30 PM, Andreas Rheinhardt 
 wrote:

> Andreas Rheinhardt:
> 
> > asivery:
> > 
> > > Signed-off-by: asivery asiv...@protonmail.com
> > > ---
> > > libavformat/matroska.c | 1 +
> > > libavformat/matroskadec.c | 2 ++
> > > 2 files changed, 3 insertions(+)
> > > 
> > > diff --git a/libavformat/matroska.c b/libavformat/matroska.c
> > > index 90d94b65bf..37305a523c 100644
> > > --- a/libavformat/matroska.c
> > > +++ b/libavformat/matroska.c
> > > @@ -55,6 +55,7 @@ const CodecTags ff_mkv_codec_tags[]={
> > > {"A_REAL/ATRC" , AV_CODEC_ID_ATRAC3},
> > > {"A_REAL/COOK" , AV_CODEC_ID_COOK},
> > > {"A_REAL/SIPR" , AV_CODEC_ID_SIPR},
> > > + {"A_ATRAC/AT1" , AV_CODEC_ID_ATRAC1},
> > > {"A_TRUEHD" , AV_CODEC_ID_TRUEHD},
> > > {"A_TTA1" , AV_CODEC_ID_TTA},
> > > {"A_VORBIS" , AV_CODEC_ID_VORBIS},
> > > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> > > index d582f566a2..0aa8e6f3b3 100644
> > > --- a/libavformat/matroskadec.c
> > > +++ b/libavformat/matroskadec.c
> > > @@ -2795,6 +2795,8 @@ static int matroska_parse_tracks(AVFormatContext s)
> > > track->audio.frame_size);
> > > if (!track->audio.buf)
> > > return AVERROR(ENOMEM);
> > > + } else if (codec_id == AV_CODEC_ID_ATRAC1) {
> > > + st->codecpar->block_align = track->audio.channels * 212; / Constant 
> > > ATRAC frame size */
> > > } else if (codec_id == AV_CODEC_ID_FLAC && track->codec_priv.size) {
> > > ret = matroska_parse_flac(s, track, &extradata_offset);
> > > if (ret < 0)
> > > --
> > > 2.34.1
> > 
> > This patch is broken. The indentation is off.
> > 
> > - Andreas
> 
> 
> Apart from this: The result of the multiplication may not fit into an
> int; looking at the other atrac1 code it seems that we only support mono
> and stereo files. Is this a limitation of FFmpeg or of the format?
> 
> - Andreas
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-devel] [PATCH v3 4/4] avocdec/ass: simplify linebreaks

2024-02-11 Thread Oneric
ff_ass_subtitle_header_* still used explicit CRLF linebreaks
eventhough they will get normalised to LF later since commit
7bf1b9b35769b37684dd2f18a54f01d852a540c8. Just directly use LF.
---
 libavcodec/ass.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/libavcodec/ass.c b/libavcodec/ass.c
index e7a1ac0eb5..927b801404 100644
--- a/libavcodec/ass.c
+++ b/libavcodec/ass.c
@@ -35,15 +35,15 @@ int ff_ass_subtitle_header_full(AVCodecContext *avctx,
 int border_style, int alignment)
 {
 avctx->subtitle_header = av_asprintf(
- "[Script Info]\r\n"
- "; Script generated by FFmpeg/Lavc%s\r\n"
- "ScriptType: v4.00+\r\n"
- "PlayResX: %d\r\n"
- "PlayResY: %d\r\n"
- "ScaledBorderAndShadow: yes\r\n"
- "YCbCr Matrix: None\r\n"
- "\r\n"
- "[V4+ Styles]\r\n"
+ "[Script Info]\n"
+ "; Script generated by FFmpeg/Lavc%s\n"
+ "ScriptType: v4.00+\n"
+ "PlayResX: %d\n"
+ "PlayResY: %d\n"
+ "ScaledBorderAndShadow: yes\n"
+ "YCbCr Matrix: None\n"
+ "\n"
+ "[V4+ Styles]\n"
 
  /* ASS (v4+) header */
  "Format: Name, "
@@ -54,7 +54,7 @@ int ff_ass_subtitle_header_full(AVCodecContext *avctx,
  "Spacing, Angle, "
  "BorderStyle, Outline, Shadow, "
  "Alignment, MarginL, MarginR, MarginV, "
- "Encoding\r\n"
+ "Encoding\n"
 
  "Style: "
  "Default," /* Name */
@@ -65,11 +65,11 @@ int ff_ass_subtitle_header_full(AVCodecContext *avctx,
  "0,0," /* Spacing, Angle */
  "%d,1,0,"  /* BorderStyle, Outline, Shadow */
  "%d,10,10,10," /* Alignment, Margin[LRV] */
- "1\r\n"/* Encoding */
+ "1\n"  /* Encoding */
 
- "\r\n"
- "[Events]\r\n"
- "Format: Layer, Start, End, Style, Name, MarginL, MarginR, 
MarginV, Effect, Text\r\n",
+ "\n"
+ "[Events]\n"
+ "Format: Layer, Start, End, Style, Name, MarginL, MarginR, 
MarginV, Effect, Text\n",
  !(avctx->flags & AV_CODEC_FLAG_BITEXACT) ? 
AV_STRINGIFY(LIBAVCODEC_VERSION) : "",
  play_res_x, play_res_y, font, font_size,
  primary_color, secondary_color, outline_color, back_color,
-- 
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".


[FFmpeg-devel] [PATCH v3 1/4] avcodec/webvttdec: honour bidi marks

2024-02-11 Thread Oneric
---
 libavcodec/webvttdec.c | 2 +-
 tests/ref/fate/sub-webvtt2 | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/webvttdec.c b/libavcodec/webvttdec.c
index 690f00dc47..990d150f16 100644
--- a/libavcodec/webvttdec.c
+++ b/libavcodec/webvttdec.c
@@ -39,7 +39,7 @@ static const struct {
 {"", "{\\u1}"}, {"", "{\\u0}"},
 {"{", "\\{"}, {"}", "\\}"}, // escape to avoid ASS markup conflicts
 {">", ">"}, {"<", "<"},
-{"‎", ""}, {"‏", ""}, // FIXME: properly honor bidi marks
+{"‎", "\xe2\x80\x8e"}, {"‏", "\xe2\x80\x8f"},
 {"&", "&"}, {" ", "\\h"},
 };
 
diff --git a/tests/ref/fate/sub-webvtt2 b/tests/ref/fate/sub-webvtt2
index 90f78d904b..2925d892a0 100644
--- a/tests/ref/fate/sub-webvtt2
+++ b/tests/ref/fate/sub-webvtt2
@@ -21,6 +21,6 @@ Dialogue: 0,0:00:12.50,0:00:32.50,Default,,0,0,0,,OK, let’s 
go.
 Dialogue: 0,0:00:38.00,0:00:43.00,Default,,0,0,0,,I want to 愛あい love 
you\NThat's not proper English!
 Dialogue: 0,0:00:43.00,0:00:46.00,Default,,0,0,0,,{\i1}キツネ{\i0}じゃない 
キツネじゃない\N乙女おとめは
 Dialogue: 0,0:00:50.00,0:00:55.00,Default,,0,0,0,,Some time ago in a rather 
distant place
-Dialogue: 0,0:00:55.00,0:01:00.00,Default,,0,0,0,,Descending: 
123456\NAscending: 123456
+Dialogue: 0,0:00:55.00,0:01:00.00,Default,,0,0,0,,Descending: 
‏123456‎\NAscending: 123456
 Dialogue: 0,0:01:00.00,0:01:05.00,Default,,0,0,0,,>> Never gonna give you up 
Never gonna let you down\NNever\hgonna\hrun\haround & desert\hyou
 Dialogue: 0,0:55:00.00,1:00:00.00,Default,,0,0,0,,Transcrit par Célestes™
-- 
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".


[FFmpeg-devel] [PATCH v3 3/4] avcodec/{ass, webvttdec}: more portable curly brace escapes

2024-02-11 Thread Oneric
Unlike what the old comment suggested, standard ASS has no character
escape mechanism, but a closing curly bracket doesn't even need one.

For manual authored sub files using a full-width variant of an apropiate
font and with scaling and psacing modifiers is a common workaround.
This is not an option here, but we can still make things much less bad.
Now the desired opening bracket still shows up in libass and
standard renders will merely display a backslash in its place
instead of stripping the following text like before.
---
 libavcodec/ass.c  | 12 
 libavcodec/webvttdec.c|  2 +-
 tests/ref/fate/sub-webvtt |  2 +-
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/libavcodec/ass.c b/libavcodec/ass.c
index a68d3568b4..e7a1ac0eb5 100644
--- a/libavcodec/ass.c
+++ b/libavcodec/ass.c
@@ -181,10 +181,14 @@ void ff_ass_bprint_text_event(AVBPrint *buf, const char 
*p, int size,
 if (linebreaks && strchr(linebreaks, *p)) {
 av_bprintf(buf, "\\N");
 
-/* standard ASS escaping so random characters don't get mis-interpreted
- * as ASS */
-} else if (!keep_ass_markup && strchr("{}", *p)) {
-av_bprintf(buf, "\\%c", *p);
+/* cancel curly brackets to avoid bogus override tag blocks
+ * hiding text. Standard ASS has no character escapes,
+ * though (only) libass provides \{ and \}.
+ * Unpaired closing brackets don't need escaping at all though and
+ * to make the situation less bad in standard ASS insert an empty block
+ */
+} else if (!keep_ass_markup && *p == '{') {
+av_bprintf(buf, "\\{{}");
 
 /* append word-joiner U+2060 as UTF-8 to break up sequences like \N */
 } else if (!keep_ass_markup && *p == '\\') {
diff --git a/libavcodec/webvttdec.c b/libavcodec/webvttdec.c
index 6e55bc5499..35bdbe805d 100644
--- a/libavcodec/webvttdec.c
+++ b/libavcodec/webvttdec.c
@@ -37,7 +37,7 @@ static const struct {
 {"", "{\\i1}"}, {"", "{\\i0}"},
 {"", "{\\b1}"}, {"", "{\\b0}"},
 {"", "{\\u1}"}, {"", "{\\u0}"},
-{"{", "\\{"}, {"}", "\\}"}, {"\\", "\\\xe2\x81\xa0"}, // escape to avoid 
ASS markup conflicts
+{"{", "\\{{}"}, {"\\", "\\\xe2\x81\xa0"}, // escape to avoid ASS markup 
conflicts
 {">", ">"}, {"<", "<"},
 {"‎", "\xe2\x80\x8e"}, {"‏", "\xe2\x80\x8f"},
 {"&", "&"}, {" ", "\\h"},
diff --git a/tests/ref/fate/sub-webvtt b/tests/ref/fate/sub-webvtt
index ea587b327c..fae50607fb 100644
--- a/tests/ref/fate/sub-webvtt
+++ b/tests/ref/fate/sub-webvtt
@@ -21,7 +21,7 @@ Dialogue: 0,0:00:22.00,0:00:24.00,Default,,0,0,0,,at the AMNH.
 Dialogue: 0,0:00:24.00,0:00:26.00,Default,,0,0,0,,Thank you for walking down 
here.
 Dialogue: 0,0:00:27.00,0:00:30.00,Default,,0,0,0,,And I want to do a follow-up 
on the last conversation we did.\Nmultiple lines\Nagain
 Dialogue: 0,0:00:30.00,0:00:31.50,Default,,0,0,0,,When we e-mailed—
-Dialogue: 0,0:00:30.50,0:00:32.50,Default,,0,0,0,,Didn't we {\b1}talk 
{\i1}about\N{\i0} enough{\b0} in that conversation? \{I'm not an ASS comment\}
+Dialogue: 0,0:00:30.50,0:00:32.50,Default,,0,0,0,,Didn't we {\b1}talk 
{\i1}about\N{\i0} enough{\b0} in that conversation? \{{}I'm not an ASS comment}
 Dialogue: 0,0:00:32.00,0:00:35.50,Default,,0,0,0,,No! No no no no; 'cos 'cos 
obviously 'cos
 Dialogue: 0,0:00:32.50,0:00:33.50,Default,,0,0,0,,{\i1}Laughs{\i0}
 Dialogue: 0,0:00:35.50,0:00:38.00,Default,,0,0,0,,You know I'm so excited my 
glasses are falling off here.
-- 
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".


[FFmpeg-devel] [PATCH v3 2/4] avcodec/{ass, webvttdec}: fix handling of backslashes

2024-02-11 Thread Oneric
Backslashes cannot be escaped by a backslash in any ASS renderer,
but unless followed by specific characters it is just printed out.
Insert a word-joiner character after a backslash to break up
active sequences without changing the visual output.
---
 libavcodec/ass.c   | 9 -
 libavcodec/webvttdec.c | 2 +-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/libavcodec/ass.c b/libavcodec/ass.c
index 5058dc8337..a68d3568b4 100644
--- a/libavcodec/ass.c
+++ b/libavcodec/ass.c
@@ -183,9 +183,16 @@ void ff_ass_bprint_text_event(AVBPrint *buf, const char 
*p, int size,
 
 /* standard ASS escaping so random characters don't get mis-interpreted
  * as ASS */
-} else if (!keep_ass_markup && strchr("{}\\", *p)) {
+} else if (!keep_ass_markup && strchr("{}", *p)) {
 av_bprintf(buf, "\\%c", *p);
 
+/* append word-joiner U+2060 as UTF-8 to break up sequences like \N */
+} else if (!keep_ass_markup && *p == '\\') {
+if (p_end - p <= 3 || strncmp(p + 1, "\xe2\x81\xa0", 3))
+av_bprintf(buf, "\\\xe2\x81\xa0");
+else
+av_bprintf(buf, "\\");
+
 /* some packets might end abruptly (no \0 at the end, like for example
  * in some cases of demuxing from a classic video container), some
  * might be terminated with \n or \r\n which we have to remove (for
diff --git a/libavcodec/webvttdec.c b/libavcodec/webvttdec.c
index 990d150f16..6e55bc5499 100644
--- a/libavcodec/webvttdec.c
+++ b/libavcodec/webvttdec.c
@@ -37,7 +37,7 @@ static const struct {
 {"", "{\\i1}"}, {"", "{\\i0}"},
 {"", "{\\b1}"}, {"", "{\\b0}"},
 {"", "{\\u1}"}, {"", "{\\u0}"},
-{"{", "\\{"}, {"}", "\\}"}, // escape to avoid ASS markup conflicts
+{"{", "\\{"}, {"}", "\\}"}, {"\\", "\\\xe2\x81\xa0"}, // escape to avoid 
ASS markup conflicts
 {">", ">"}, {"<", "<"},
 {"‎", "\xe2\x80\x8e"}, {"‏", "\xe2\x80\x8f"},
 {"&", "&"}, {" ", "\\h"},
-- 
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".


[FFmpeg-devel] [PATCH v3 0/4] Fix some active sequences in subtitles

2024-02-11 Thread Oneric
Changes from v2:
 - rebased ontop of the recently pushed eol normalisation.
   As a result no more CRLFs in here and Patchwork should be happy
 - added a fourth cosmetic commit adjusting
   explicit linebreaks to the new normalisation

Changes from v1:
 - ff_ass_bprint_text_event now only inserts a word-joiner
   if there isn’t already one anyway
 - added a third commit improving the handling of
   curly brackets for standard ASS renderers


Oneric (4):
  avcodec/webvttdec: honour bidi marks
  avcodec/{ass,webvttdec}: fix handling of backslashes
  avcodec/{ass,webvttdec}: more portable curly brace escapes
  avocdec/ass: simplify linebreaks

 libavcodec/ass.c   | 47 +++---
 libavcodec/webvttdec.c |  4 ++--
 tests/ref/fate/sub-webvtt  |  2 +-
 tests/ref/fate/sub-webvtt2 |  2 +-
 4 files changed, 33 insertions(+), 22 deletions(-)

-- 
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] [PATCH] all: use designated initializers for AVOption.unit

2024-02-11 Thread Anton Khirnov
Quoting Michael Niedermayer (2024-02-11 21:39:17)
> some of these have formatting issues:
> (havent really reviewd just saw when applying locally)

Yes, Coccinelle unfortunately does that, as mentioned in the commit
message.
I've fixed those I noticed, which was not all apparently.
Fixed the two you mention locally.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".