Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Nicolas George
> Sent: Mittwoch, 16. April 2025 07:15
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> softworkz . (HE12025-04-15):
> > which breaks all usages.
> 
> Please elaborate.
> 
> --
>   Nicolas George


Please show me widely used implementations which do not break.

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

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

Re: [FFmpeg-devel] [PATCH 01/12] fftools/textformat/avtextformat: Simplify avtext_print_rational()

[Andreas Rheinhardt]

softworkz .:
> 
> 
>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> Andreas Rheinhardt
>> Sent: Dienstag, 15. April 2025 03:00
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: [FFmpeg-devel] [PATCH 01/12] fftools/textformat/avtextformat:
>> Simplify avtext_print_rational()
>>
>> Patches attached.
>>
>> - Andreas
> 
> 
> Hi Andreas,
> 
> thanks a lot for working through this. I'll go over it tomorrow.
> 
> As to not waste your time, it's probably best when we get those 
> changes applied in a timely manner so that I can rebase the new
> patchset on top of it.
> 
> Since you're sending the patches as attachments:
> How do you want me to reply with code context? Whole files or 
> just snippets? And quoted? 
> 

Snippets is better. So is quoted.

- Andreas

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

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

[FFmpeg-devel] [PATCH] aarch64/h26x: optimize sao_band_filter

[Zhao Zhili]

From: Zhao Zhili 

int8_t[] is enough for offset_table of 8 bit streams.

On rpi5:
 Before   After
hevc_sao_band_8_8_c:  252.3 ( 1.00x) 252.3 ( 1.00x)
hevc_sao_band_8_8_neon:95.8 ( 2.63x)  61.0 ( 4.14x)
hevc_sao_band_16_8_c: 875.2 ( 1.00x) 864.9 ( 1.00x)
hevc_sao_band_16_8_neon:  317.5 ( 2.76x) 150.0 ( 5.76x)
hevc_sao_band_32_8_c:3853.5 ( 1.00x)3871.6 ( 1.00x)
hevc_sao_band_32_8_neon: 1222.3 ( 3.15x) 550.6 ( 7.03x)
hevc_sao_band_48_8_c:8203.6 ( 1.00x)8182.6 ( 1.00x)
hevc_sao_band_48_8_neon: 2685.7 ( 3.05x)1185.8 ( 6.90x)
hevc_sao_band_64_8_c:   14023.0 ( 1.00x)   14038.9 ( 1.00x)
hevc_sao_band_64_8_neon: 4783.2 ( 2.93x)2078.4 ( 6.75x)
---
 libavcodec/aarch64/h26x/dsp.h |  4 +
 libavcodec/aarch64/h26x/sao_neon.S| 93 ++-
 libavcodec/aarch64/hevcdsp_init_aarch64.c |  4 +-
 libavcodec/aarch64/vvc/dsp_init.c |  5 +-
 4 files changed, 65 insertions(+), 41 deletions(-)

diff --git a/libavcodec/aarch64/h26x/dsp.h b/libavcodec/aarch64/h26x/dsp.h
index 0fefb4d70f..6ea6a8d36a 100644
--- a/libavcodec/aarch64/h26x/dsp.h
+++ b/libavcodec/aarch64/h26x/dsp.h
@@ -28,6 +28,10 @@ void ff_h26x_sao_band_filter_8x8_8_neon(uint8_t *_dst, const 
uint8_t *_src,
 ptrdiff_t stride_dst, ptrdiff_t 
stride_src,
 const int16_t *sao_offset_val, int 
sao_left_class,
 int width, int height);
+void ff_h26x_sao_band_filter_16x16_8_neon(uint8_t *_dst, const uint8_t *_src,
+ptrdiff_t stride_dst, ptrdiff_t 
stride_src,
+const int16_t *sao_offset_val, int 
sao_left_class,
+int width, int height);
 void ff_hevc_sao_edge_filter_16x16_8_neon(uint8_t *dst, const uint8_t *src, 
ptrdiff_t stride_dst,
   const int16_t *sao_offset_val, int 
eo, int width, int height);
 void ff_hevc_sao_edge_filter_8x8_8_neon(uint8_t *dst, const uint8_t *src, 
ptrdiff_t stride_dst,
diff --git a/libavcodec/aarch64/h26x/sao_neon.S 
b/libavcodec/aarch64/h26x/sao_neon.S
index c43820135e..60c026fe95 100644
--- a/libavcodec/aarch64/h26x/sao_neon.S
+++ b/libavcodec/aarch64/h26x/sao_neon.S
@@ -35,48 +35,67 @@
 //  int16_t *sao_offset_val, int sao_left_class,
 //  int width, int height)
 function ff_h26x_sao_band_filter_8x8_8_neon, export=1
-stp xzr, xzr, [sp, #-64]!
+stp xzr, xzr, [sp, #-32]!
 stp xzr, xzr, [sp, #16]
-stp xzr, xzr, [sp, #32]
-stp xzr, xzr, [sp, #48]
 mov w8,  #4
-0:  ldrsh   x9, [x4,  x8, lsl #1]  // sao_offset_val[k+1]
-subsw8,  w8,  #1
-add w10, w8,  w5   // k + sao_left_class
+0:
+ldrsh   x9, [x4, x8, lsl #1]// sao_offset_val[k+1]
+subsw8, w8, #1
+add w10, w8, w5 // k + sao_left_class
 and w10, w10, #0x1F
-strhw9, [sp, x10, lsl #1]
+strbw9, [sp, x10]
 bne 0b
-add w6,  w6,  #7
-bic w6,  w6,  #7
-ld1 {v16.16b-v19.16b}, [sp], #64
-sub x2,  x2,  x6
-sub x3,  x3,  x6
-moviv20.8h,   #1
-1:  mov w8,  w6// beginning of line
-2:  // Simple layout for accessing 16bit values
-// with 8bit LUT.
-//
-//   00  01  02  03  04  05  06  07
-// +--->
-// |xDE#xAD|xCA#xFE|xBE#xEF|xFE#xED|
-// +--->
-//i-0 i-1 i-2 i-3
-ld1 {v2.8b}, [x1], #8  // dst[x] = 
av_clip_pixel(src[x] + offset_table[src[x] >> shift]);
-subsw8, w8,  #8
-uxtlv0.8h,  v2.8b  // load src[x]
-ushrv2.8h,  v0.8h, #3  // >> BIT_DEPTH - 3
-shl v1.8h,  v2.8h, #1  // low (x2, accessing short)
-add v3.8h,  v1.8h, v20.8h  // +1 access upper short
-sli v1.8h,  v3.8h, #8  // shift insert index to 
upper byte
-tbx v2.16b, {v16.16b-v19.16b}, v1.16b // table
-add v1.8h,  v0.8h, v2.8h   // src[x] + table
-sqxtun  v4.8b,  v1.8h  // clip + narrow
-st1 {v4.8b}, [x0], #8  // store
-// done 8 pixels
+ldp q16, q17, [sp], #32
+1:
+ld1 {v2.8b}, [x1], x3
+subs   

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat: add avformat_query_seekable

[Zhao Zhili]

> On Apr 15, 2025, at 18:39, Gyan Doshi  wrote:
> 
> Utility function to report seekability features for a given input.
> 
> Useful for ffprobe and to extend seek possibilities in fftools.
> ---
> v2:
>   made constants more descriptive
>   add exception for rtsp false negative seekability
> 
> doc/APIchanges |  3 +++
> libavformat/avformat.h | 22 ++
> libavformat/seek.c | 53 ++
> libavformat/version.h  |  2 +-
> 4 files changed, 79 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 65bf5a9419..879f56b572 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2025-03-28
> 
> API changes, most recent first:
> 
> +2025-04-xx - xx - lavf 62.1.100 - avformat.h
> +  Add avformat_query_seekable().
> +
> 2025-04-07 - 19e9a203b7 - lavu 60.01.100 - dict.h
>   Add AV_DICT_DEDUP.
> 
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 498c3020a5..f9da5e9e79 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -2338,6 +2338,28 @@ int av_seek_frame(AVFormatContext *s, int 
> stream_index, int64_t timestamp,
>  */
> int avformat_seek_file(AVFormatContext *s, int stream_index, int64_t min_ts, 
> int64_t ts, int64_t max_ts, int flags);
> 
> +#define AVSEEKABLE_IO_NORMAL   0x0001 ///< I/O is seekable like a 
> local file
> +#define AVSEEKABLE_IO_PROTOCOL 0x0002 ///< I/O seek is through 
> protocol request via avio_seek_time
> +#define AVSEEKABLE_VIA_DEMUXER 0x0004 ///< demuxer has a seek 
> function
> +#define AVSEEKABLE_VIA_PKTSCAN 0x0008 ///< seek is performed by 
> consuming and scanning packet timestamps
> +#define AVSEEKABLE_BY_TIME 0x0100 ///< seek target can be a 
> timestamp
> +#define AVSEEKABLE_BY_BYTE 0x0200 ///< seek target can be in 
> bytes
> +#define AVSEEKABLE_BY_FRAME0x0400 ///< seek target can be a 
> frame index
> +#define AVSEEKABLE_PROP_PTS0x0001 ///< seek target timestamp is 
> expected to be PTS
> +#define AVSEEKABLE_PROP_FAST   0x0002 ///< demuxer allows fast but 
> inaccurate seeking
> +#define AVSEEKABLE_PROP_FWDONLY0x0004 ///< set seek will be equal or 
> forward of specified seek point
> +
> +/**
> + * Report if and how a seek can be performed in a given input.
> + *
> + * @param smedia file handle
> + *
> + * @return 0 if no seek can be performed on input,
> + * -1 if the fmt ctx is NULL or is not an input
> + * else return AVSEEKABLE_ bitflags indicating seekability features.
> + */
> +int avformat_query_seekable(AVFormatContext *s);
> +
> /**
>  * Discard all internally buffered data. This can be useful when dealing with
>  * discontinuities in the byte stream. Generally works only with formats that
> diff --git a/libavformat/seek.c b/libavformat/seek.c
> index c0d94371e6..8be1bdec30 100644
> --- a/libavformat/seek.c
> +++ b/libavformat/seek.c
> @@ -712,6 +712,59 @@ int avformat_seek_file(AVFormatContext *s, int 
> stream_index, int64_t min_ts,
> return ret;
> }
> 
> +int avformat_query_seekable(AVFormatContext *s)
> +{
> +int ret = 0;
> +
> +if (!s || !s->iformat)
> +return -1;
> +
> +if ( strcmp(s->iformat->name, "rtsp") && (!(s->pb && s->pb->seekable) || 
> s->ctx_flags & AVFMTCTX_UNSEEKABLE) )
> +return 0;

dvdvideo is also seekable. How about check AVFMT_NOFILE flag and seek method in 
FFInputFormat.

For rtsp, I think there is no way to query whether it’s really seeable or not 
until try to do that, at least no such information is exported for now.

> +
> +if (s->pb->seekable & AVIO_SEEKABLE_NORMAL)
> +ret |= AVSEEKABLE_IO_NORMAL;
> +
> +if (s->pb->seekable & AVIO_SEEKABLE_TIME)
> +ret |= AVSEEKABLE_IO_PROTOCOL;
> +
> +if (ffifmt(s->iformat)->read_seek || ffifmt(s->iformat)->read_seek2)
> +ret |= AVSEEKABLE_VIA_DEMUXER;
> +
> +if (ffifmt(s->iformat)->read_timestamp && !(s->iformat->flags & 
> AVFMT_NOBINSEARCH))
> +ret |= AVSEEKABLE_VIA_PKTSCAN;
> +
> +if (!(s->iformat->flags & AVFMT_NOTIMESTAMPS))
> +ret |= AVSEEKABLE_BY_TIME;
> +
> +// TODO: incomplete, a few demuxers don't set flag but error out on byte 
> seek
> +if (!(s->iformat->flags & AVFMT_NO_BYTE_SEEK))
> +ret |= AVSEEKABLE_BY_BYTE;
> +
> +// TODO: no flag for frame seeking. Add flag and enable this check
> +if (s->iformat->flags & 0)
> +ret |= AVSEEKABLE_BY_FRAME;
> +
> +if (s->iformat->flags & AVFMT_SEEK_TO_PTS)
> +ret |= AVSEEKABLE_PROP_PTS;
> +
> +// TODO: flag exists but not added to the demuxers which support it
> +if (s->iformat->flags & AVFMT_FLAG_FAST_SEEK)
> +ret |= AVSEEKABLE_PROP_FAST;
> +
> +if (!(ret & AVSEEKABLE_VIA_DEMUXER) && ret & AVSEEKABLE_VIA_PKTSCAN)
> +ret |= AVSEEKABLE_PROP_FWDONLY;
> +
> +if ( !(ret

Re: [FFmpeg-devel] [PATCH 3/3] avcodec: add Blackmagic RAW decoder

[Lynne]

On 15/04/2025 12:04, Lynne wrote:

Most of the work was done by Paul B Mahol.
I cleaned the patch up, improved the code a bit, and added slice
threading.
---
  configure  |   1 +
  libavcodec/Makefile|   1 +
  libavcodec/allcodecs.c |   1 +
  libavcodec/braw.c  | 666 +
  4 files changed, 669 insertions(+)
  create mode 100755 libavcodec/braw.c


Output is kinda-bayer but apparently not.
Patch dropped.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavfi/src_movie: set pkt_timebase

[Nicolas George]

Nicolas George (HE12025-01-05):
> Fix “Could not update timestamps for skipped samples” warning
> and associated misfeature.
> 
> Signed-off-by: Nicolas George 
> ---
>  libavfilter/src_movie.c | 1 +
>  1 file changed, 1 insertion(+)

Pushed.

Regards,

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

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

Re: [FFmpeg-devel] [PATCH] libavcodec/riscv:add RVV optimized for idct_32x32_8:

[Rémi Denis-Courmont]

Hi,

Le tiistaina 15. huhtikuuta 2025, 10.34.24 Itä-Euroopan kesäaika 
daichengr...@iscas.ac.cn a écrit :
> From: daichengrong 
> 
>  riscv/hevcdsp_idct_rvv: Optimize idct_32x32_8
> 
>  On Banana PI F3:
> 
>  hevc_idct_32x32_8_c:119579.3 ( 1.00x)
>  hevc_idct_32x32_8_rvv_i64:   51254.4 ( 2.33x)
> 
> Signed-off-by: daichengrong 
> ---
>  libavcodec/riscv/Makefile   |1 +
>  libavcodec/riscv/hevcdsp_idct_rvv.S | 1042 +++
>  libavcodec/riscv/hevcdsp_init.c |   52 +-
>  3 files changed, 1075 insertions(+), 20 deletions(-)
>  create mode 100644 libavcodec/riscv/hevcdsp_idct_rvv.S
> 
> diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
> index a80d2fa2e7..dfc33afbee 100644
> --- a/libavcodec/riscv/Makefile
> +++ b/libavcodec/riscv/Makefile
> @@ -36,6 +36,7 @@ RVV-OBJS-$(CONFIG_H264DSP) += riscv/h264addpx_rvv.o
> riscv/h264dsp_rvv.o \ OBJS-$(CONFIG_H264QPEL) += riscv/h264qpel_init.o
>  RVV-OBJS-$(CONFIG_H264QPEL) += riscv/h264qpel_rvv.o
>  OBJS-$(CONFIG_HEVC_DECODER) += riscv/hevcdsp_init.o
> +OBJS-$(CONFIG_HEVC_DECODER) += riscv/hevcdsp_idct_rvv.o
>  RVV-OBJS-$(CONFIG_HEVC_DECODER)  += riscv/h26x/h2656_inter_rvv.o
>  OBJS-$(CONFIG_HUFFYUV_DECODER) += riscv/huffyuvdsp_init.o
>  RVV-OBJS-$(CONFIG_HUFFYUV_DECODER) += riscv/huffyuvdsp_rvv.o
> diff --git a/libavcodec/riscv/hevcdsp_idct_rvv.S
> b/libavcodec/riscv/hevcdsp_idct_rvv.S new file mode 100644
> index 00..f8dd2e5bf4
> --- /dev/null
> +++ b/libavcodec/riscv/hevcdsp_idct_rvv.S
> @@ -0,0 +1,1042 @@
> +/*
> + * Copyright (c) 2025 Institue of Software Chinese Academy of Sciences
> (ISCAS). + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA + */
> +
> +#include "libavutil/riscv/asm.S"
> +
> +const trans, align=4
> +.2byte  64, 83, 64, 36
> +.2byte  89, 75, 50, 18
> +.2byte  90, 87, 80, 70
> +.2byte  57, 43, 25, 9
> +.2byte  90, 90, 88, 85
> +.2byte  82, 78, 73, 67
> +.2byte  61, 54, 46, 38
> +.2byte  31, 22, 13, 4
> +endconst
> +
> +.macro sum_sub out, in, c, op, p
> +vsetivli t0, 4, e16, mf2, tu, ma

I tihnk that you don't need t0 here? Ditto below.

> +  .ifc \op, +
> +.ifc \p, 2
> +vslidedown.viv8, \in, 4
> +vwmacc.vx\out, \c, v8
> +.else
> +vwmacc.vx\out, \c, \in
> +.endif
> +  .else
> +.ifc \p, 2
> +neg  \c, \c
> +vslidedown.viv8, \in, 4
> +vwmacc.vx\out, \c, v8
> +neg  \c, \c
> +.else
> +neg  \c, \c
> +vwmacc.vx\out, \c, \in
> +neg  \c, \c

The typical problem with complex nested macros like this is, you easily end up 
assembling very inefficient code.

For instance, this keeps vainly flipping the sign of the same value over and 
over only to allow this macro to exist.

> +.endif
> +  .endif
> +.endm
> +
> +.macro add_member32 in, t0, index0, t1, index1, t2, index2, t3, index3,
> op0, op1, op2, op3, p
> +vsetivli t0, 1, e16, m1, tu, ma
> +vslidedown.viv12, \t0, \index0
> +vmv.x.s  s2, v12
> +vslidedown.viv12, \t1, \index1
> +vmv.x.s  s3, v12
> +vslidedown.viv12, \t2, \index2
> +vmv.x.s  s4, v12
> +vslidedown.viv12, \t3, \index3
> +vmv.x.s  s5, v12

This is a very inefficient way to extract 4 scalars out of a vector. I'm not 
familar with the overall specific algorithm, but I would expect that this can 
be avoided. At least, I have never seen need for such construct to implement a 
DCT. And we already have quite a few DCTs in the FFmpeg RISC-V port.

Admittedly for smaller matrices than 32x32. But typically larger matrices are 
not as big a deal with RVV as they are on Arm or x86. RVV requires spilling to 
the intermediate values from the first DCT dimension to memory, to transpose 
them before the second DCT dimension. That being the case, the penalty for not 
fitting the entire matrix in th

Re: [FFmpeg-devel] [PATCH 2/9] fftools/textformat: Quality improvements

[Andreas Rheinhardt]

softworkz .:
> 
> 
>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> Andreas Rheinhardt
>> Sent: Dienstag, 15. April 2025 03:06
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH 2/9] fftools/textformat: Quality
>> improvements
>>
>> softworkz:
>>> From: softworkz 
>>>
>>> Signed-off-by: softworkz 
>>> ---
>>>  fftools/textformat/avtextformat.c | 121 +++
>> ---
>>>  fftools/textformat/avtextformat.h |   6 +-
>>>  fftools/textformat/tf_default.c   |   8 +-
>>>  fftools/textformat/tf_ini.c   |   2 +-
>>>  fftools/textformat/tf_json.c  |   8 +-
>>>  fftools/textformat/tf_xml.c   |   3 -
>>>  fftools/textformat/tw_avio.c  |   9 ++-
>>>  7 files changed, 101 insertions(+), 56 deletions(-)
>>>
>>> diff --git a/fftools/textformat/avtextformat.c
>> b/fftools/textformat/avtextformat.c
>>> index 1ce51d11e2..406025d19d 100644
>>> --- a/fftools/textformat/avtextformat.c
>>> +++ b/fftools/textformat/avtextformat.c
>>> @@ -93,9 +93,8 @@ static const AVClass textcontext_class = {
>>>
>>>  static void bprint_bytes(AVBPrint *bp, const uint8_t *ubuf, size_t
>> ubuf_size)
>>>  {
>>> -int i;
>>>  av_bprintf(bp, "0X");
>>> -for (i = 0; i < ubuf_size; i++)
>>> +for (unsigned i = 0; i < ubuf_size; i++)
>>
>> Why not size_t?
> 
> Because it creates more warnings about narrowing conversions.
> 
> 
> 
>>>  av_bprintf(bp, "%02X", ubuf[i]);
>>>  }
>>>
>>> @@ -110,8 +109,6 @@ int avtext_context_close(AVTextFormatContext
>> **ptctx)
>>>
>>>  av_hash_freep(&tctx->hash);
>>>
>>> -av_hash_freep(&tctx->hash);
>>> -
>>>  if (tctx->formatter->uninit)
>>>  tctx->formatter->uninit(tctx);
>>>  for (i = 0; i < SECTION_MAX_NB_LEVELS; i++)
>>> @@ -141,12 +138,18 @@ int avtext_context_open(AVTextFormatContext
>> **ptctx,
>>>  AVTextFormatContext *tctx;
>>>  int i, ret = 0;
>>>
>>> -if (!(tctx = av_mallocz(sizeof(AVTextFormatContext {
>>> +if (!ptctx || !formatter)
>>> +return AVERROR(EINVAL);
>>
>> Can this happen?
> 
> see below
> 
>>> +
>>> +if (!formatter->priv_size && formatter->priv_class)
>>> +return AVERROR(EINVAL);
>>
>> Stuff like this should never happen and should not be checked (or
>> actually: the proper place to check stuff like this is in test tools
>> like lavc/tests/avcodec.c, but I don't think it is worth it for
>> fftools).
> 
> I probably overdid it a bit with checks, but the goal for this API 
> is still to become public at some point (like in avutil), so I 
> tried to move towards that direction already.
> 
> 
> 
> 
>>> +
>>> +if (!((tctx = av_mallocz(sizeof(AVTextFormatContext) {
>>>  ret = AVERROR(ENOMEM);
>>>  goto fail;
>>>  }
>>>
>>> -if (!(tctx->priv = av_mallocz(formatter->priv_size))) {
>>> +if (formatter->priv_size && !((tctx->priv =
>> av_mallocz(formatter->priv_size {
>>>  ret = AVERROR(ENOMEM);
>>>  goto fail;
>>>  }
>>> @@ -215,15 +218,15 @@ int avtext_context_open(AVTextFormatContext
>> **ptctx,
>>>
>>>  /* validate replace string */
>>>  {
>>> -const uint8_t *p = tctx->string_validation_replacement;
>>> -const uint8_t *endp = p + strlen(p);
>>> +const uint8_t *p = (uint8_t *)tctx-
>>> string_validation_replacement;
>>> +const uint8_t *endp = p + strlen((const char *)p);
>>>  while (*p) {
>>>  const uint8_t *p0 = p;
>>>  int32_t code;
>>>  ret = av_utf8_decode(&code, &p, endp, tctx-
>>> string_validation_utf8_flags);
>>>  if (ret < 0) {
>>>  AVBPrint bp;
>>> -av_bprint_init(&bp, 0, AV_BPRINT_SIZE_AUTOMATIC);
>>> +av_bprint_init(&bp, 0, AV_BPRINT_SIZE_UNLIMITED);
>>
>> This adds a memleak on data where it makes a difference.
> 
> Why? The string_validation_replacement string should be short enough
> to fit into the stack-allocated memory, no?
> 
> 
>>>  bprint_bytes(&bp, p0, p - p0),
>>>  av_log(tctx, AV_LOG_ERROR,
>>> "Invalid UTF8 sequence %s found in
>> string validation replace '%s'\n",
>>> @@ -259,6 +262,9 @@ static const char unit_bit_per_second_str[] =
>> "bit/s";
>>>
>>>  void avtext_print_section_header(AVTextFormatContext *tctx, const
>> void *data, int section_id)
>>>  {
>>> +if (!tctx || section_id < 0 || section_id >= tctx->nb_sections)
>>> +return;
>>
>> Can this happen?
> 
> For a public API - many things can happen...
> 
> 
>>>  tctx->level++;
>>>  av_assert0(tctx->level < SECTION_MAX_NB_LEVELS);
>>>
>>> @@ -272,6 +278,9 @@ void
>> avtext_print_section_header(AVTextFormatContext *tctx, const void
>> *data, in
>>>
>>>  void avtext_print_section_footer(AVTextFormatContext *tctx)
>>>  {
>>> +if (!tctx || tctx->level < 0 || tctx->level >=
>> SECTION_MAX_NB_LEVELS)
>>> +return;
>>
>> Can this happen?
> 
> Yes - when somewhere in FFmpeg some output

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat: add avformat_query_seekable

[Andreas Rheinhardt]

Gyan Doshi:
> Utility function to report seekability features for a given input.
> 
> Useful for ffprobe and to extend seek possibilities in fftools.
> ---
> v2:
>made constants more descriptive
>add exception for rtsp false negative seekability
> 
>  doc/APIchanges |  3 +++
>  libavformat/avformat.h | 22 ++
>  libavformat/seek.c | 53 ++
>  libavformat/version.h  |  2 +-
>  4 files changed, 79 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 65bf5a9419..879f56b572 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2025-03-28
>  
>  API changes, most recent first:
>  
> +2025-04-xx - xx - lavf 62.1.100 - avformat.h
> +  Add avformat_query_seekable().
> +
>  2025-04-07 - 19e9a203b7 - lavu 60.01.100 - dict.h
>Add AV_DICT_DEDUP.
>  
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 498c3020a5..f9da5e9e79 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -2338,6 +2338,28 @@ int av_seek_frame(AVFormatContext *s, int 
> stream_index, int64_t timestamp,
>   */
>  int avformat_seek_file(AVFormatContext *s, int stream_index, int64_t min_ts, 
> int64_t ts, int64_t max_ts, int flags);
>  
> +#define AVSEEKABLE_IO_NORMAL   0x0001 ///< I/O is seekable like a 
> local file
> +#define AVSEEKABLE_IO_PROTOCOL 0x0002 ///< I/O seek is through 
> protocol request via avio_seek_time
> +#define AVSEEKABLE_VIA_DEMUXER 0x0004 ///< demuxer has a seek 
> function
> +#define AVSEEKABLE_VIA_PKTSCAN 0x0008 ///< seek is performed by 
> consuming and scanning packet timestamps
> +#define AVSEEKABLE_BY_TIME 0x0100 ///< seek target can be a 
> timestamp
> +#define AVSEEKABLE_BY_BYTE 0x0200 ///< seek target can be in 
> bytes
> +#define AVSEEKABLE_BY_FRAME0x0400 ///< seek target can be a 
> frame index
> +#define AVSEEKABLE_PROP_PTS0x0001 ///< seek target timestamp is 
> expected to be PTS
> +#define AVSEEKABLE_PROP_FAST   0x0002 ///< demuxer allows fast but 
> inaccurate seeking
> +#define AVSEEKABLE_PROP_FWDONLY0x0004 ///< set seek will be equal or 
> forward of specified seek point
> +
> +/**
> + * Report if and how a seek can be performed in a given input.
> + *
> + * @param smedia file handle
> + *
> + * @return 0 if no seek can be performed on input,
> + * -1 if the fmt ctx is NULL or is not an input
> + * else return AVSEEKABLE_ bitflags indicating seekability features.
> + */
> +int avformat_query_seekable(AVFormatContext *s);
> +
>  /**
>   * Discard all internally buffered data. This can be useful when dealing with
>   * discontinuities in the byte stream. Generally works only with formats that
> diff --git a/libavformat/seek.c b/libavformat/seek.c
> index c0d94371e6..8be1bdec30 100644
> --- a/libavformat/seek.c
> +++ b/libavformat/seek.c
> @@ -712,6 +712,59 @@ int avformat_seek_file(AVFormatContext *s, int 
> stream_index, int64_t min_ts,
>  return ret;
>  }
>  
> +int avformat_query_seekable(AVFormatContext *s)
> +{
> +int ret = 0;
> +
> +if (!s || !s->iformat)
> +return -1;
> +
> +if ( strcmp(s->iformat->name, "rtsp") && (!(s->pb && s->pb->seekable) || 
> s->ctx_flags & AVFMTCTX_UNSEEKABLE) )
> +return 0;
> +
> +if (s->pb->seekable & AVIO_SEEKABLE_NORMAL)
> +ret |= AVSEEKABLE_IO_NORMAL;
> +
> +if (s->pb->seekable & AVIO_SEEKABLE_TIME)
> +ret |= AVSEEKABLE_IO_PROTOCOL;
> +
> +if (ffifmt(s->iformat)->read_seek || ffifmt(s->iformat)->read_seek2)
> +ret |= AVSEEKABLE_VIA_DEMUXER;

The existence of these functions does not imply that a given input is
seekable: E.g. some read_seek functions rely on an index being present
in the file and are useless/not better than reading linearly in case the
index is absent.

> +
> +if (ffifmt(s->iformat)->read_timestamp && !(s->iformat->flags & 
> AVFMT_NOBINSEARCH))
> +ret |= AVSEEKABLE_VIA_PKTSCAN;
> +
> +if (!(s->iformat->flags & AVFMT_NOTIMESTAMPS))
> +ret |= AVSEEKABLE_BY_TIME;
> +
> +// TODO: incomplete, a few demuxers don't set flag but error out on byte 
> seek
> +if (!(s->iformat->flags & AVFMT_NO_BYTE_SEEK))
> +ret |= AVSEEKABLE_BY_BYTE;
> +
> +// TODO: no flag for frame seeking. Add flag and enable this check
> +if (s->iformat->flags & 0)
> +ret |= AVSEEKABLE_BY_FRAME;
> +
> +if (s->iformat->flags & AVFMT_SEEK_TO_PTS)
> +ret |= AVSEEKABLE_PROP_PTS;
> +
> +// TODO: flag exists but not added to the demuxers which support it
> +if (s->iformat->flags & AVFMT_FLAG_FAST_SEEK)
> +ret |= AVSEEKABLE_PROP_FAST;
> +
> +if (!(ret & AVSEEKABLE_VIA_DEMUXER) && ret & AVSEEKABLE_VIA_PKTSCAN)
> +ret |= AVSEEKABLE_PROP_FWDONLY;
> +
> +if ( !(ret & AVSEEKABLE_VIA_DEMUXER) &&
> +   

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[Nicolas George]

softworkz . (HE12025-04-15):
>   which breaks all usages.

Please elaborate.

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

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

Re: [FFmpeg-devel] [PATCH 01/12] fftools/textformat/avtextformat: Simplify avtext_print_rational()

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Andreas Rheinhardt
> Sent: Mittwoch, 16. April 2025 07:37
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 01/12]
> fftools/textformat/avtextformat: Simplify avtext_print_rational()
> 
> softworkz .:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: Mittwoch, 16. April 2025 06:28
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH 01/12]
> >> fftools/textformat/avtextformat: Simplify avtext_print_rational()
> >>
> >> softworkz .:
> >>>
> >>>
>  -Original Message-
>  From: ffmpeg-devel  On Behalf Of
>  Andreas Rheinhardt
>  Sent: Dienstag, 15. April 2025 10:36
>  To: ffmpeg-devel@ffmpeg.org
>  Subject: Re: [FFmpeg-devel] [PATCH 01/12]
>  fftools/textformat/avtextformat: Simplify avtext_print_rational()
> 
>  softworkz .:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf
> Of
> >> Andreas Rheinhardt
> >> Sent: Dienstag, 15. April 2025 03:00
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: [FFmpeg-devel] [PATCH 01/12]
>  fftools/textformat/avtextformat:
> >> Simplify avtext_print_rational()
> >>
> >> Patches attached.
> >>
> >> - Andreas
> >
> >
> > Hi Andreas,
> >
> > thanks a lot for working through this. I'll go over it tomorrow.
> >
> > As to not waste your time, it's probably best when we get those
> > changes applied in a timely manner so that I can rebase the new
> > patchset on top of it.
> >
> > Since you're sending the patches as attachments:
> > How do you want me to reply with code context? Whole files or
> > just snippets? And quoted?
> >
> 
>  Snippets is better. So is quoted.
> 
>  - Andreas
> 
> >>>
> >>> Hi Andreas,
> >>>
> >>> thanks again for the well-spotted improvements. Just two notes:
> >>>
> >>>
> >>> 0007-fftools-textformat-Use-av_default_item_name.patch
> >>>
> >>> In the new patchset, those macros are removed from the individual
> >>> files. There's now a single macro in tf_internal.h and I've
> applied
> >>> this change there.
> >>
> >> So you use a move/deduplicate commit to change something? Not good.
> >
> > No. The patchset has a deduplication commit. That's what I've
> submitted
> > to the ML already.
> > Now I made another commit locally (on top of that) which makes this
> change.
> >
> >
> >>> 0008-fftools-textformat-avtextformat-Fix-segfault-upon-al.patch
> >>> 0009-fftools-textformat-avtextformat-Fix-segfault-upon-al.patch
> >>>
> >>> Can this happen?
> >>
> >> Of course it can. All allocations can fail. That's why we check
> them.
> >> Have you been coding with the assumption that allocations never
> fail?
> >> (You can use av_max_alloc(1); to simulate allocation failures.)
> >
> > Allocations can fail, but statically initialized global const
> values?
> 
> The pointers to said static objects are only set after having
> allocated
> the private context. So the issue can happen (not with current master)

Current master is on top of which I had applied your patches and 
there's no possible way for those pointers to be null.

That you are submitting a patch that is fixing a flaw in an
unmerged future patch is pretty cool, but was also beyond my range
of consideration. 😊

Thanks for the clarification.

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

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

Re: [FFmpeg-devel] [PATCH 01/12] fftools/textformat/avtextformat: Simplify avtext_print_rational()

[Andreas Rheinhardt]

softworkz .:
> 
> 
>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> Andreas Rheinhardt
>> Sent: Dienstag, 15. April 2025 10:36
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH 01/12]
>> fftools/textformat/avtextformat: Simplify avtext_print_rational()
>>
>> softworkz .:
>>>
>>>
 -Original Message-
 From: ffmpeg-devel  On Behalf Of
 Andreas Rheinhardt
 Sent: Dienstag, 15. April 2025 03:00
 To: FFmpeg development discussions and patches >>> de...@ffmpeg.org>
 Subject: [FFmpeg-devel] [PATCH 01/12]
>> fftools/textformat/avtextformat:
 Simplify avtext_print_rational()

 Patches attached.

 - Andreas
>>>
>>>
>>> Hi Andreas,
>>>
>>> thanks a lot for working through this. I'll go over it tomorrow.
>>>
>>> As to not waste your time, it's probably best when we get those
>>> changes applied in a timely manner so that I can rebase the new
>>> patchset on top of it.
>>>
>>> Since you're sending the patches as attachments:
>>> How do you want me to reply with code context? Whole files or
>>> just snippets? And quoted?
>>>
>>
>> Snippets is better. So is quoted.
>>
>> - Andreas
>>
> 
> Hi Andreas,
> 
> thanks again for the well-spotted improvements. Just two notes:
> 
> 
> 0007-fftools-textformat-Use-av_default_item_name.patch
> 
> In the new patchset, those macros are removed from the individual
> files. There's now a single macro in tf_internal.h and I've applied
> this change there.

So you use a move/deduplicate commit to change something? Not good.

> 
> 0008-fftools-textformat-avtextformat-Fix-segfault-upon-al.patch
> 0009-fftools-textformat-avtextformat-Fix-segfault-upon-al.patch
> 
> Can this happen?

Of course it can. All allocations can fail. That's why we check them.
Have you been coding with the assumption that allocations never fail?
(You can use av_max_alloc(1); to simulate allocation failures.)

> (yet I'm good with it)
> 
> 
> Everything else LGTM:
> 
> 0001-fftools-textformat-avtextformat-Simplify-avtext_prin.patch
> 0002-fftools-textformat-Use-not-for-lavu-headers.patch
> 0003-fftools-textformat-tw_avio-Remove-unused-private-cla.patch
> 0004-fftools-textformat-tw_avio-Don-t-flush-unnecessarily.patch
> 0005-fftools-textformat-tw_avio-Use-avio_closep.patch
> 0006-textformat-tw_avio-Remove-close_on_uninit-param-from.patch
> 
> 0010-fftools-textformat-avtextformat-Initialize-stuff-ear.patch
> 0011-fftools-textformat-avtextformat-Add-missing-AVERROR.patch
> 0012-fftools-textformat-avtextformat-Make-close-functions.patch
> 
> 
> From my side, it would be great when we can get this merged asap,
> then I'll post a rebased version of the patchset, also accounting
> for your other review comment.

Done (with the exception of the av_default_item_name commit).

- 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 01/12] fftools/textformat/avtextformat: Simplify avtext_print_rational()

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Andreas Rheinhardt
> Sent: Mittwoch, 16. April 2025 06:28
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 01/12]
> fftools/textformat/avtextformat: Simplify avtext_print_rational()
> 
> softworkz .:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: Dienstag, 15. April 2025 10:36
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH 01/12]
> >> fftools/textformat/avtextformat: Simplify avtext_print_rational()
> >>
> >> softworkz .:
> >>>
> >>>
>  -Original Message-
>  From: ffmpeg-devel  On Behalf Of
>  Andreas Rheinhardt
>  Sent: Dienstag, 15. April 2025 03:00
>  To: FFmpeg development discussions and patches   de...@ffmpeg.org>
>  Subject: [FFmpeg-devel] [PATCH 01/12]
> >> fftools/textformat/avtextformat:
>  Simplify avtext_print_rational()
> 
>  Patches attached.
> 
>  - Andreas
> >>>
> >>>
> >>> Hi Andreas,
> >>>
> >>> thanks a lot for working through this. I'll go over it tomorrow.
> >>>
> >>> As to not waste your time, it's probably best when we get those
> >>> changes applied in a timely manner so that I can rebase the new
> >>> patchset on top of it.
> >>>
> >>> Since you're sending the patches as attachments:
> >>> How do you want me to reply with code context? Whole files or
> >>> just snippets? And quoted?
> >>>
> >>
> >> Snippets is better. So is quoted.
> >>
> >> - Andreas
> >>
> >
> > Hi Andreas,
> >
> > thanks again for the well-spotted improvements. Just two notes:
> >
> >
> > 0007-fftools-textformat-Use-av_default_item_name.patch
> >
> > In the new patchset, those macros are removed from the individual
> > files. There's now a single macro in tf_internal.h and I've applied
> > this change there.
> 
> So you use a move/deduplicate commit to change something? Not good.

No. The patchset has a deduplication commit. That's what I've submitted
to the ML already. 
Now I made another commit locally (on top of that) which makes this change.


> > 0008-fftools-textformat-avtextformat-Fix-segfault-upon-al.patch
> > 0009-fftools-textformat-avtextformat-Fix-segfault-upon-al.patch
> >
> > Can this happen?
> 
> Of course it can. All allocations can fail. That's why we check them.
> Have you been coding with the assumption that allocations never fail?
> (You can use av_max_alloc(1); to simulate allocation failures.)

Allocations can fail, but statically initialized global const values?

> >
> > From my side, it would be great when we can get this merged asap,
> > then I'll post a rebased version of the patchset, also accounting
> > for your other review comment.
> 
> Done (with the exception of the av_default_item_name commit).
> 
> - Andreas

Awesome, thanks!

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

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

Re: [FFmpeg-devel] [PATCH 01/12] fftools/textformat/avtextformat: Simplify avtext_print_rational()

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> softworkz .
> Sent: Mittwoch, 16. April 2025 06:38
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 01/12]
> fftools/textformat/avtextformat: Simplify avtext_print_rational()
> 
> 



> > > 0007-fftools-textformat-Use-av_default_item_name.patch
> > >
> > > In the new patchset, those macros are removed from the individual
> > > files. There's now a single macro in tf_internal.h and I've
> applied
> > > this change there.
> >
> > So you use a move/deduplicate commit to change something? Not good.
> 
> No. The patchset has a deduplication commit. That's what I've
> submitted
> to the ML already.
> Now I made another commit locally (on top of that) which makes this
> change.

Just realized the source of confusion. By "there" I meant the new
header file, not the commit. Sorry for being unclear.

sw



___
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/9] fftools/textformat: Quality improvements

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Andreas Rheinhardt
> Sent: Mittwoch, 16. April 2025 06:51
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 2/9] fftools/textformat: Quality
> improvements
> 
> softworkz .:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: Dienstag, 15. April 2025 03:06
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH 2/9] fftools/textformat: Quality
> >> improvements
> >>
> >> softworkz:
> >>> From: softworkz 
> >>>
> >>> Signed-off-by: softworkz 
> >>> ---
> >>>  fftools/textformat/avtextformat.c | 121 +++--
> --
> >> ---
> >>>  fftools/textformat/avtextformat.h |   6 +-
> >>>  fftools/textformat/tf_default.c   |   8 +-
> >>>  fftools/textformat/tf_ini.c   |   2 +-
> >>>  fftools/textformat/tf_json.c  |   8 +-
> >>>  fftools/textformat/tf_xml.c   |   3 -
> >>>  fftools/textformat/tw_avio.c  |   9 ++-
> >>>  7 files changed, 101 insertions(+), 56 deletions(-)
> >>>
> >>> diff --git a/fftools/textformat/avtextformat.c
> >> b/fftools/textformat/avtextformat.c
> >>> index 1ce51d11e2..406025d19d 100644
> >>> --- a/fftools/textformat/avtextformat.c
> >>> +++ b/fftools/textformat/avtextformat.c
> >>> @@ -93,9 +93,8 @@ static const AVClass textcontext_class = {
> >>>
> >>>  static void bprint_bytes(AVBPrint *bp, const uint8_t *ubuf,
> size_t
> >> ubuf_size)
> >>>  {
> >>> -int i;
> >>>  av_bprintf(bp, "0X");
> >>> -for (i = 0; i < ubuf_size; i++)
> >>> +for (unsigned i = 0; i < ubuf_size; i++)
> >>
> >> Why not size_t?
> >
> > Because it creates more warnings about narrowing conversions.
> >
> >
> >
> >>>  av_bprintf(bp, "%02X", ubuf[i]);
> >>>  }
> >>>
> >>> @@ -110,8 +109,6 @@ int avtext_context_close(AVTextFormatContext
> >> **ptctx)
> >>>
> >>>  av_hash_freep(&tctx->hash);
> >>>
> >>> -av_hash_freep(&tctx->hash);
> >>> -
> >>>  if (tctx->formatter->uninit)
> >>>  tctx->formatter->uninit(tctx);
> >>>  for (i = 0; i < SECTION_MAX_NB_LEVELS; i++)
> >>> @@ -141,12 +138,18 @@ int avtext_context_open(AVTextFormatContext
> >> **ptctx,
> >>>  AVTextFormatContext *tctx;
> >>>  int i, ret = 0;
> >>>
> >>> -if (!(tctx = av_mallocz(sizeof(AVTextFormatContext {
> >>> +if (!ptctx || !formatter)
> >>> +return AVERROR(EINVAL);
> >>
> >> Can this happen?
> >
> > see below
> >
> >>> +
> >>> +if (!formatter->priv_size && formatter->priv_class)
> >>> +return AVERROR(EINVAL);
> >>
> >> Stuff like this should never happen and should not be checked (or
> >> actually: the proper place to check stuff like this is in test
> tools
> >> like lavc/tests/avcodec.c, but I don't think it is worth it for
> >> fftools).
> >
> > I probably overdid it a bit with checks, but the goal for this API
> > is still to become public at some point (like in avutil), so I
> > tried to move towards that direction already.
> >
> >
> >
> >
> >>> +
> >>> +if (!((tctx = av_mallocz(sizeof(AVTextFormatContext) {
> >>>  ret = AVERROR(ENOMEM);
> >>>  goto fail;
> >>>  }
> >>>
> >>> -if (!(tctx->priv = av_mallocz(formatter->priv_size))) {
> >>> +if (formatter->priv_size && !((tctx->priv =
> >> av_mallocz(formatter->priv_size {
> >>>  ret = AVERROR(ENOMEM);
> >>>  goto fail;
> >>>  }
> >>> @@ -215,15 +218,15 @@ int avtext_context_open(AVTextFormatContext
> >> **ptctx,
> >>>
> >>>  /* validate replace string */
> >>>  {
> >>> -const uint8_t *p = tctx->string_validation_replacement;
> >>> -const uint8_t *endp = p + strlen(p);
> >>> +const uint8_t *p = (uint8_t *)tctx-
> >>> string_validation_replacement;
> >>> +const uint8_t *endp = p + strlen((const char *)p);
> >>>  while (*p) {
> >>>  const uint8_t *p0 = p;
> >>>  int32_t code;
> >>>  ret = av_utf8_decode(&code, &p, endp, tctx-
> >>> string_validation_utf8_flags);
> >>>  if (ret < 0) {
> >>>  AVBPrint bp;
> >>> -av_bprint_init(&bp, 0, AV_BPRINT_SIZE_AUTOMATIC);
> >>> +av_bprint_init(&bp, 0, AV_BPRINT_SIZE_UNLIMITED);
> >>
> >> This adds a memleak on data where it makes a difference.
> >
> > Why? The string_validation_replacement string should be short enough
> > to fit into the stack-allocated memory, no?
> >
> >
> >>>  bprint_bytes(&bp, p0, p - p0),
> >>>  av_log(tctx, AV_LOG_ERROR,
> >>> "Invalid UTF8 sequence %s found in
> >> string validation replace '%s'\n",
> >>> @@ -259,6 +262,9 @@ static const char unit_bit_per_second_str[] =
> >> "bit/s";
> >>>
> >>>  void avtext_print_section_header(AVTextFormatContext *tctx, const
> >> void *data, int section_id)
> >>>  {
> >>> +if (!tctx || section_id < 0 || section_id >= tctx-
> >nb_sections)
> >>> +return;
> >>
> >> C

Re: [FFmpeg-devel] [PATCH v2] avcodec/webvttdec: strip classes

[Leon Grutters]

On 3/21/25 4:55 PM, Leon Grutters wrote:

If a supported tag has a class, e.g "" it is ignored entirely;
so for example "Hello" would be converted to "Hello{\i0}"
instead of the intended "{\i1}Hello{\i0}".

Signed-off-by: Leon Grutters 

Hi all,

Wondering if anyone could review and/or apply this patch.

Regards,
Leon

---
  libavcodec/webvttdec.c | 39 ---
  1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/libavcodec/webvttdec.c b/libavcodec/webvttdec.c
index 733fdee685..c375867643 100644
--- a/libavcodec/webvttdec.c
+++ b/libavcodec/webvttdec.c
@@ -34,20 +34,41 @@ static const struct {
  const char *from;
  const char *to;
  } webvtt_tag_replace[] = {
-{"", "{\\i1}"}, {"", "{\\i0}"},
-{"", "{\\b1}"}, {"", "{\\b0}"},
-{"", "{\\u1}"}, {"", "{\\u0}"},
  {"{", "\\{{}"}, {"\\", "\\\xe2\x81\xa0"}, // escape to avoid ASS markup 
conflicts
  {">", ">"}, {"<", "<"},
  {"‎", "\xe2\x80\x8e"}, {"‏", "\xe2\x80\x8f"},
  {"&", "&"}, {" ", "\\h"},
  };
+static const struct {
+const char from[6];
+const char to[6];
+} webvtt_valid_tags[] = {
+{"i", "{\\i1}"}, {"/i", "{\\i0}"},
+{"b", "{\\b1}"}, {"/b", "{\\b0}"},
+{"u", "{\\u1}"}, {"/u", "{\\u0}"},
+};
  
  static int webvtt_event_to_ass(AVBPrint *buf, const char *p)

  {
-int i, again = 0, skip = 0;
+int i, again = 0;
  
  while (*p) {

+if (*p == '<') {
+const char *tag_end = strchr(p, '>');
+ptrdiff_t len;
+if (!tag_end)
+break;
+len = tag_end - p + 1;
+for (i = 0; i < FF_ARRAY_ELEMS(webvtt_valid_tags); i++) {
+const char *from = webvtt_valid_tags[i].from;
+if(!strncmp(p + 1, from, strlen(from))) {
+av_bprintf(buf, "%s", webvtt_valid_tags[i].to);
+break;
+}
+}
+p += len;
+again = 1;
+}
  
  for (i = 0; i < FF_ARRAY_ELEMS(webvtt_tag_replace); i++) {

  const char *from = webvtt_tag_replace[i].from;
@@ -59,21 +80,17 @@ static int webvtt_event_to_ass(AVBPrint *buf, const char *p)
  break;
  }
  }
+
  if (!*p)
  break;
  
  if (again) {

  again = 0;
-skip = 0;
  continue;
  }
-if (*p == '<')
-skip = 1;
-else if (*p == '>')
-skip = 0;
-else if (p[0] == '\n' && p[1])
+if (p[0] == '\n' && p[1])
  av_bprintf(buf, "\\N");
-else if (!skip && *p != '\r')
+else if (*p != '\r')
  av_bprint_chars(buf, *p, 1);
  p++;
  }



___
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] libavformat/dashdec: Fix buffer overflow in segment URL resolution

[jing yan]

Thanks for the review!
that can't be null and I found another mistake.
I will fix this issue and send a v2 patch soon.

Michael Niedermayer  于2025年4月16日周三 07:33写道：

> Hi
>
> On Fri, Apr 11, 2025 at 03:48:08PM +0800, xiaohuan...@gmail.com wrote:
> > From: xiaohuanshu 
> >
> > Problem:
> > The max_url_size calculation for DASH segment URLs only considered the
> base URL
> > length, leading to buffer overflow when the segment's sourceURL exceeded
> the
> > pre-allocated buffer. This triggered the log error:
> > "DASH request for url 'invalid:truncated'".
> >
> > Reproduce:
> > 1. A test sample "long-sourceurl-sample.mpd" (deliberately designed with
> a long
> >sourceURL) was uploaded to VideoLAN's repository.
> > 2. Reproduce with short base path:
> >ffmpeg -i /tmp/short_path/long-sourceurl-sample.mpd
> >-> Triggers "invalid:truncated" error
> > 3. With artificially lengthened base path (e.g. /aaa/../bbb/../...):
> >ffmpeg -i
> /long/../path/../with/../many/../segments/long-sourceurl-sample.mpd
> >-> URL resolves correctly (though HTTP fetch fails due to fake URL)
> >
> > Fix:
> > Recalculate max_url_size by considering both base URL and sourceURL
> lengths,
> > ensuring sufficient buffer allocation during URL concatenation.
> >
> > Signed-off-by: xiaohuanshu 
> > ---
> >  libavformat/dashdec.c | 14 +-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> > index c3f3d7f3f8..f604d363c4 100644
> > --- a/libavformat/dashdec.c
> > +++ b/libavformat/dashdec.c
> > @@ -606,7 +606,7 @@ static int
> parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
> >  char *initialization_val = NULL;
> >  char *media_val = NULL;
> >  char *range_val = NULL;
> > -int max_url_size = c ? c->max_url_size: MAX_URL_SIZE;
> > +int max_url_size = 0;
> >  int err;
> >
> >  if (!av_strcasecmp(fragmenturl_node->name, "Initialization")) {
> > @@ -620,6 +620,12 @@ static int
> parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
> >  xmlFree(initialization_val);
> >  return AVERROR(ENOMEM);
> >  }
> > +max_url_size = FFMAX(
>
> > +c ? c->max_url_size : 0,
>
> how can c be NULL here ?
>
>
> > +initialization_val ? aligned(strlen(initialization_val)
> +
> > + (rep_id_val ?
> strlen(rep_id_val) : 0) +
> > + (rep_bandwidth_val ?
> strlen(rep_bandwidth_val) : 0)) : 0);
> > +max_url_size = max_url_size ? max_url_size : MAX_URL_SIZE;
> >  rep->init_section->url = get_content_url(baseurl_nodes, 4,
> >   max_url_size,
> >   rep_id_val,
> > @@ -641,6 +647,12 @@ static int
> parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
> >  xmlFree(media_val);
> >  return AVERROR(ENOMEM);
> >  }
> > +max_url_size = FFMAX(
> > +c ? c->max_url_size : 0,
>
> > +initialization_val ? aligned(strlen(initialization_val)
> +
>
> how can initialization_val be non NULL here ?
>
> thx
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
> ___
> 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 01/12] fftools/textformat/avtextformat: Simplify avtext_print_rational()

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Andreas Rheinhardt
> Sent: Mittwoch, 16. April 2025 08:31
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 01/12]
> fftools/textformat/avtextformat: Simplify avtext_print_rational()
> 
> softworkz .:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: Mittwoch, 16. April 2025 07:37
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH 01/12]
> >> fftools/textformat/avtextformat: Simplify avtext_print_rational()
> >>
> >> softworkz .:
> >>>
> >>>
>  -Original Message-
>  From: ffmpeg-devel  On Behalf Of
>  Andreas Rheinhardt
>  Sent: Mittwoch, 16. April 2025 06:28
>  To: ffmpeg-devel@ffmpeg.org
>  Subject: Re: [FFmpeg-devel] [PATCH 01/12]
>  fftools/textformat/avtextformat: Simplify avtext_print_rational()
> 
>  softworkz .:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf
> Of
> >> Andreas Rheinhardt
> >> Sent: Dienstag, 15. April 2025 10:36
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH 01/12]
> >> fftools/textformat/avtextformat: Simplify
> avtext_print_rational()
> >>
> >> softworkz .:
> >>>
> >>>
>  -Original Message-
>  From: ffmpeg-devel  On
> Behalf
> >> Of
>  Andreas Rheinhardt
>  Sent: Dienstag, 15. April 2025 03:00
>  To: FFmpeg development discussions and patches   de...@ffmpeg.org>
>  Subject: [FFmpeg-devel] [PATCH 01/12]
> >> fftools/textformat/avtextformat:
>  Simplify avtext_print_rational()
> 
>  Patches attached.
> 
>  - Andreas
> >>>
> >>>
> >>> Hi Andreas,
> >>>
> >>> thanks a lot for working through this. I'll go over it
> tomorrow.
> >>>
> >>> As to not waste your time, it's probably best when we get
> those
> >>> changes applied in a timely manner so that I can rebase the
> new
> >>> patchset on top of it.
> >>>
> >>> Since you're sending the patches as attachments:
> >>> How do you want me to reply with code context? Whole files or
> >>> just snippets? And quoted?
> >>>
> >>
> >> Snippets is better. So is quoted.
> >>
> >> - Andreas
> >>
> >
> > Hi Andreas,
> >
> > thanks again for the well-spotted improvements. Just two notes:
> >
> >
> > 0007-fftools-textformat-Use-av_default_item_name.patch
> >
> > In the new patchset, those macros are removed from the
> individual
> > files. There's now a single macro in tf_internal.h and I've
> >> applied
> > this change there.
> 
>  So you use a move/deduplicate commit to change something? Not
> good.
> >>>
> >>> No. The patchset has a deduplication commit. That's what I've
> >> submitted
> >>> to the ML already.
> >>> Now I made another commit locally (on top of that) which makes
> this
> >> change.
> >>>
> >>>
> > 0008-fftools-textformat-avtextformat-Fix-segfault-upon-al.patch
> > 0009-fftools-textformat-avtextformat-Fix-segfault-upon-al.patch
> >
> > Can this happen?
> 
>  Of course it can. All allocations can fail. That's why we check
> >> them.
>  Have you been coding with the assumption that allocations never
> >> fail?
>  (You can use av_max_alloc(1); to simulate allocation failures.)
> >>>
> >>> Allocations can fail, but statically initialized global const
> >> values?
> >>
> >> The pointers to said static objects are only set after having
> >> allocated
> >> the private context. So the issue can happen (not with current
> master)
> >
> > Current master is on top of which I had applied your patches and
> > there's no possible way for those pointers to be null.
> >
> > That you are submitting a patch that is fixing a flaw in an
> > unmerged future patch is pretty cool, but was also beyond my range
> > of consideration. 😊
> >
> > Thanks for the clarification.
> >
> 
> You completely misunderstand (or you try to be trolling me as your 😊
> indicates). "The issue" that can no longer happen with current master
> is
> the segfault after allocation failure. This could really happen before
> my fixes. The pointers to writer/formatter can still be NULL even on
> master (namely after allocation failure), therefore the checks need to
> be there.


I would never troll you in such a weird way. 
I just looked at a very wrong place, please take my apologies for 
the confusion.

Thanks,
sw






___
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] libavformat/dashdec: Fix buffer overflow in segment URL resolution

[xiaohuanshu]

From: xiaohuanshu 

Problem:
The max_url_size calculation for DASH segment URLs only considered the base URL
length, leading to buffer overflow when the segment's sourceURL exceeded the
pre-allocated buffer. This triggered the log error:
"DASH request for url 'invalid:truncated'".

Reproduce:
1. A test sample "long-sourceurl-sample.mpd" (deliberately designed with a long
   sourceURL) was uploaded to VideoLAN's repository.
2. Reproduce with short base path:
   ffmpeg -i /tmp/short_path/long-sourceurl-sample.mpd
   -> Triggers "invalid:truncated" error
3. With artificially lengthened base path (e.g. /aaa/../bbb/../...):
   ffmpeg -i /long/../path/../with/../many/../segments/long-sourceurl-sample.mpd
   -> URL resolves correctly (though HTTP fetch fails due to fake URL)

Fix:
Recalculate max_url_size by considering both base URL and sourceURL lengths,
ensuring sufficient buffer allocation during URL concatenation.

V2:
1. no need to determine whether initialization_val is null.
2. fix the incorrect variable name.

Signed-off-by: xiaohuanshu 
---
 libavformat/dashdec.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index c3f3d7f3f8..a574c91932 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -606,7 +606,7 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 char *initialization_val = NULL;
 char *media_val = NULL;
 char *range_val = NULL;
-int max_url_size = c ? c->max_url_size: MAX_URL_SIZE;
+int max_url_size = 0;
 int err;
 
 if (!av_strcasecmp(fragmenturl_node->name, "Initialization")) {
@@ -620,6 +620,12 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 xmlFree(initialization_val);
 return AVERROR(ENOMEM);
 }
+max_url_size = FFMAX(
+c ? c->max_url_size : 0,
+aligned(strlen(initialization_val) +
+(rep_id_val ? strlen(rep_id_val) : 0) +
+(rep_bandwidth_val ? strlen(rep_bandwidth_val) : 0)));
+max_url_size = max_url_size ? max_url_size : MAX_URL_SIZE;
 rep->init_section->url = get_content_url(baseurl_nodes, 4,
  max_url_size,
  rep_id_val,
@@ -641,6 +647,11 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 xmlFree(media_val);
 return AVERROR(ENOMEM);
 }
+max_url_size = FFMAX(
+c ? c->max_url_size : 0,
+aligned(strlen(media_val) + (rep_id_val ? strlen(rep_id_val) : 
0) +
+(rep_bandwidth_val ? strlen(rep_bandwidth_val) : 0)));
+max_url_size = max_url_size ? max_url_size : MAX_URL_SIZE;
 seg->url = get_content_url(baseurl_nodes, 4,
max_url_size,
rep_id_val,
@@ -2369,3 +2380,4 @@ const FFInputFormat ff_dash_demuxer = {
 .read_close = dash_close,
 .read_seek  = dash_read_seek,
 };
+
-- 
2.39.5 (Apple Git-154)

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

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

[FFmpeg-devel] [PATCH] avcodec/h264bsd_dec: add h264dec base on h264bsd

[Shiqi Zhu]

h264bsd url https://github.com/oneam/h264bsd
./configure --enable-decoder="h264_bsd" --extra-cflags="-I/h264bsd/src" 
--extra-ldflags="-L/h264bsd/posix/lib" --extra-libs="-lh264bsd"
Test
./ffmpeg -y -codec:v h264_bsd -i /h264bsd/test/test_640x360.h264 
./test_640x360.yuv

Signed-off-by: Shiqi Zhu 
---
 libavcodec/Makefile  |   1 +
 libavcodec/allcodecs.c   |   1 +
 libavcodec/h264bsd_dec.c | 183 +++
 3 files changed, 185 insertions(+)
 create mode 100644 libavcodec/h264bsd_dec.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 7bd1dbec9a..68cfc3abb5 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -419,6 +419,7 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o 
h264_cabac.o h264_cavlc.o \
   h264_slice.o h264data.o h274.o
 OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o
 OBJS-$(CONFIG_H264_AMF_DECODER)+= amfdec.o
+OBJS-$(CONFIG_H264_BSD_DECODER)+= h264bsd_dec.o
 OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuviddec.o
 OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o
 OBJS-$(CONFIG_H264_MEDIACODEC_ENCODER) += mediacodecenc.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f10519617e..a752f83210 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -148,6 +148,7 @@ extern const FFCodec ff_h263i_decoder;
 extern const FFCodec ff_h263p_encoder;
 extern const FFCodec ff_h263p_decoder;
 extern const FFCodec ff_h263_v4l2m2m_decoder;
+extern const FFCodec ff_h264_bsd_decoder;
 extern const FFCodec ff_h264_decoder;
 extern const FFCodec ff_h264_v4l2m2m_decoder;
 extern const FFCodec ff_h264_mediacodec_decoder;
diff --git a/libavcodec/h264bsd_dec.c b/libavcodec/h264bsd_dec.c
new file mode 100644
index 00..e687dbf8e3
--- /dev/null
+++ b/libavcodec/h264bsd_dec.c
@@ -0,0 +1,183 @@
+/*
+ * Copyright (C) 2025 Shiqi Zhu 
+ * 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
+ */
+
+/**
+ * @file
+ * MCV hardware video decoder
+ */
+
+#include "config_components.h"
+#include "avcodec.h"
+#include "codec_internal.h"
+#include "decode.h"
+#include "internal.h"
+#include "packet.h"
+#include "libavutil/opt.h"
+#include "libavutil/fifo.h"
+#include "h264bsd_decoder.h"
+
+typedef struct DecodeContext {
+AVClass *av_class;
+storage_t vdec;
+AVCodecContext *avctx;
+uint32_t ext_buffer_num;
+int coded_width;
+int coded_height;
+enum AVPixelFormat format;
+} DecodeContext;
+
+static av_cold int h264_bsd_init_decoder(AVCodecContext *avctx)
+{
+DecodeContext *x = avctx->priv_data;
+int ret;
+
+ret = h264bsdInit(&x->vdec, 0);
+if (ret != 0) {
+av_log(avctx, AV_LOG_ERROR, "Failed to open hifi decoder\n");
+return AVERROR_UNKNOWN;
+}
+
+x->avctx = avctx;
+x->format = AV_PIX_FMT_YUV420P;
+
+return 0;
+}
+
+static av_cold int h264_bsd_close_decoder(AVCodecContext *avctx)
+{
+DecodeContext *x = avctx->priv_data;
+int ret;
+
+x->avctx = NULL;
+h264bsdShutdown(&x->vdec);
+
+return 0;
+}
+
+static void h264_bsd_flush(AVCodecContext *avctx)
+{
+DecodeContext *x = avctx->priv_data;
+
+h264bsdFlushBuffer(&x->vdec);
+}
+
+static int h264_bsd_decode_frame(AVCodecContext *avctx, AVFrame *frame,
+  int *got_frame, AVPacket *avpkt)
+{
+DecodeContext *x = avctx->priv_data;
+int ret, i, w, h;
+uint32_t readBytes;
+int numPics = 0;
+uint32_t picId, isIdrPic, numErrMbs;
+uint8_t *data;
+
+while (avpkt->size > 0) {
+ret = h264bsdDecode(&x->vdec, avpkt->data, avpkt->size, 0, &readBytes);
+avpkt->data += readBytes;
+avpkt->size -= readBytes;
+
+switch (ret)
+{
+case H264BSD_PIC_RDY:
+data = h264bsdNextOutputPicture(&x->vdec, &picId, &isIdrPic, 
&numErrMbs);
+if (isIdrPic) {
+av_log(avctx, AV_LOG_DEBUG, "IDR picture %d\n", picId);
+} else {
+av_log(avctx, AV_LOG_DEBUG, "Non-IDR picture %d\n", picId);
+}
+if (numErrMbs > 0) {
+av_log(avctx, AV_LOG_DEBUG, "Picture %d has %d errors\n", 
picId, numErrMbs);
+} else {
+av_log(avctx, AV_L

Re: [FFmpeg-devel] [PATCH v2] libavformat/dashdec: Fix buffer overflow in segment URL resolution

[Andreas Rheinhardt]

xiaohuan...@gmail.com:
> From: xiaohuanshu 
> 
> Problem:
> The max_url_size calculation for DASH segment URLs only considered the base 
> URL
> length, leading to buffer overflow when the segment's sourceURL exceeded the
> pre-allocated buffer. This triggered the log error:
> "DASH request for url 'invalid:truncated'".
> 
> Reproduce:
> 1. A test sample "long-sourceurl-sample.mpd" (deliberately designed with a 
> long
>sourceURL) was uploaded to VideoLAN's repository.
> 2. Reproduce with short base path:
>ffmpeg -i /tmp/short_path/long-sourceurl-sample.mpd
>-> Triggers "invalid:truncated" error
> 3. With artificially lengthened base path (e.g. /aaa/../bbb/../...):
>ffmpeg -i 
> /long/../path/../with/../many/../segments/long-sourceurl-sample.mpd
>-> URL resolves correctly (though HTTP fetch fails due to fake URL)
> 
> Fix:
> Recalculate max_url_size by considering both base URL and sourceURL lengths,
> ensuring sufficient buffer allocation during URL concatenation.
> 
> V2:
> 1. no need to determine whether initialization_val is null.
> 2. fix the incorrect variable name.
> 
> Signed-off-by: xiaohuanshu 
> ---
>  libavformat/dashdec.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index c3f3d7f3f8..a574c91932 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -606,7 +606,7 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
> *s, struct representati
>  char *initialization_val = NULL;
>  char *media_val = NULL;
>  char *range_val = NULL;
> -int max_url_size = c ? c->max_url_size: MAX_URL_SIZE;
> +int max_url_size = 0;

This should use way smaller scope.

>  int err;
>  
>  if (!av_strcasecmp(fragmenturl_node->name, "Initialization")) {
> @@ -620,6 +620,12 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
> *s, struct representati
>  xmlFree(initialization_val);
>  return AVERROR(ENOMEM);
>  }
> +max_url_size = FFMAX(
> +c ? c->max_url_size : 0,
> +aligned(strlen(initialization_val) +
> +(rep_id_val ? strlen(rep_id_val) : 0) +
> +(rep_bandwidth_val ? strlen(rep_bandwidth_val) : 
> 0)));
> +max_url_size = max_url_size ? max_url_size : MAX_URL_SIZE;
>  rep->init_section->url = get_content_url(baseurl_nodes, 4,
>   max_url_size,
>   rep_id_val,
> @@ -641,6 +647,11 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
> *s, struct representati
>  xmlFree(media_val);
>  return AVERROR(ENOMEM);
>  }
> +max_url_size = FFMAX(
> +c ? c->max_url_size : 0,
> +aligned(strlen(media_val) + (rep_id_val ? strlen(rep_id_val) 
> : 0) +
> +(rep_bandwidth_val ? strlen(rep_bandwidth_val) : 
> 0)));
> +max_url_size = max_url_size ? max_url_size : MAX_URL_SIZE;
>  seg->url = get_content_url(baseurl_nodes, 4,
> max_url_size,
> rep_id_val,
> @@ -2369,3 +2380,4 @@ const FFInputFormat ff_dash_demuxer = {
>  .read_close = dash_close,
>  .read_seek  = dash_read_seek,
>  };
> +

Stray change

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

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

Re: [FFmpeg-devel] [PATCH 01/12] fftools/textformat/avtextformat: Simplify avtext_print_rational()

[Andreas Rheinhardt]

softworkz .:
> 
> 
>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> Andreas Rheinhardt
>> Sent: Mittwoch, 16. April 2025 06:28
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH 01/12]
>> fftools/textformat/avtextformat: Simplify avtext_print_rational()
>>
>> softworkz .:
>>>
>>>
 -Original Message-
 From: ffmpeg-devel  On Behalf Of
 Andreas Rheinhardt
 Sent: Dienstag, 15. April 2025 10:36
 To: ffmpeg-devel@ffmpeg.org
 Subject: Re: [FFmpeg-devel] [PATCH 01/12]
 fftools/textformat/avtextformat: Simplify avtext_print_rational()

 softworkz .:
>
>
>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> Andreas Rheinhardt
>> Sent: Dienstag, 15. April 2025 03:00
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: [FFmpeg-devel] [PATCH 01/12]
 fftools/textformat/avtextformat:
>> Simplify avtext_print_rational()
>>
>> Patches attached.
>>
>> - Andreas
>
>
> Hi Andreas,
>
> thanks a lot for working through this. I'll go over it tomorrow.
>
> As to not waste your time, it's probably best when we get those
> changes applied in a timely manner so that I can rebase the new
> patchset on top of it.
>
> Since you're sending the patches as attachments:
> How do you want me to reply with code context? Whole files or
> just snippets? And quoted?
>

 Snippets is better. So is quoted.

 - Andreas

>>>
>>> Hi Andreas,
>>>
>>> thanks again for the well-spotted improvements. Just two notes:
>>>
>>>
>>> 0007-fftools-textformat-Use-av_default_item_name.patch
>>>
>>> In the new patchset, those macros are removed from the individual
>>> files. There's now a single macro in tf_internal.h and I've applied
>>> this change there.
>>
>> So you use a move/deduplicate commit to change something? Not good.
> 
> No. The patchset has a deduplication commit. That's what I've submitted
> to the ML already. 
> Now I made another commit locally (on top of that) which makes this change.
> 
> 
>>> 0008-fftools-textformat-avtextformat-Fix-segfault-upon-al.patch
>>> 0009-fftools-textformat-avtextformat-Fix-segfault-upon-al.patch
>>>
>>> Can this happen?
>>
>> Of course it can. All allocations can fail. That's why we check them.
>> Have you been coding with the assumption that allocations never fail?
>> (You can use av_max_alloc(1); to simulate allocation failures.)
> 
> Allocations can fail, but statically initialized global const values?

The pointers to said static objects are only set after having allocated
the private context. So the issue can happen (not with current master)
"if an AVTextFormatContext's private context could not be allocated" (as
has been said in a commit message; similarly for AVTextWriterContext).

(In case you are wondering why I did not set the pointers to
writer/formatter before having allocated the private context: The uninit
functions are only supposed to be called with the writer/formatter's
private context already allocated (otherwise all of them would need to
check for its existence), so this would not reduce the amount of checks.)

- 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 01/12] fftools/textformat/avtextformat: Simplify avtext_print_rational()

[Andreas Rheinhardt]

softworkz .:
> 
> 
>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> Andreas Rheinhardt
>> Sent: Mittwoch, 16. April 2025 07:37
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH 01/12]
>> fftools/textformat/avtextformat: Simplify avtext_print_rational()
>>
>> softworkz .:
>>>
>>>
 -Original Message-
 From: ffmpeg-devel  On Behalf Of
 Andreas Rheinhardt
 Sent: Mittwoch, 16. April 2025 06:28
 To: ffmpeg-devel@ffmpeg.org
 Subject: Re: [FFmpeg-devel] [PATCH 01/12]
 fftools/textformat/avtextformat: Simplify avtext_print_rational()

 softworkz .:
>
>
>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> Andreas Rheinhardt
>> Sent: Dienstag, 15. April 2025 10:36
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH 01/12]
>> fftools/textformat/avtextformat: Simplify avtext_print_rational()
>>
>> softworkz .:
>>>
>>>
 -Original Message-
 From: ffmpeg-devel  On Behalf
>> Of
 Andreas Rheinhardt
 Sent: Dienstag, 15. April 2025 03:00
 To: FFmpeg development discussions and patches >>> de...@ffmpeg.org>
 Subject: [FFmpeg-devel] [PATCH 01/12]
>> fftools/textformat/avtextformat:
 Simplify avtext_print_rational()

 Patches attached.

 - Andreas
>>>
>>>
>>> Hi Andreas,
>>>
>>> thanks a lot for working through this. I'll go over it tomorrow.
>>>
>>> As to not waste your time, it's probably best when we get those
>>> changes applied in a timely manner so that I can rebase the new
>>> patchset on top of it.
>>>
>>> Since you're sending the patches as attachments:
>>> How do you want me to reply with code context? Whole files or
>>> just snippets? And quoted?
>>>
>>
>> Snippets is better. So is quoted.
>>
>> - Andreas
>>
>
> Hi Andreas,
>
> thanks again for the well-spotted improvements. Just two notes:
>
>
> 0007-fftools-textformat-Use-av_default_item_name.patch
>
> In the new patchset, those macros are removed from the individual
> files. There's now a single macro in tf_internal.h and I've
>> applied
> this change there.

 So you use a move/deduplicate commit to change something? Not good.
>>>
>>> No. The patchset has a deduplication commit. That's what I've
>> submitted
>>> to the ML already.
>>> Now I made another commit locally (on top of that) which makes this
>> change.
>>>
>>>
> 0008-fftools-textformat-avtextformat-Fix-segfault-upon-al.patch
> 0009-fftools-textformat-avtextformat-Fix-segfault-upon-al.patch
>
> Can this happen?

 Of course it can. All allocations can fail. That's why we check
>> them.
 Have you been coding with the assumption that allocations never
>> fail?
 (You can use av_max_alloc(1); to simulate allocation failures.)
>>>
>>> Allocations can fail, but statically initialized global const
>> values?
>>
>> The pointers to said static objects are only set after having
>> allocated
>> the private context. So the issue can happen (not with current master)
> 
> Current master is on top of which I had applied your patches and 
> there's no possible way for those pointers to be null.
> 
> That you are submitting a patch that is fixing a flaw in an
> unmerged future patch is pretty cool, but was also beyond my range
> of consideration. 😊
> 
> Thanks for the clarification.
> 

You completely misunderstand (or you try to be trolling me as your 😊
indicates). "The issue" that can no longer happen with current master is
the segfault after allocation failure. This could really happen before
my fixes. The pointers to writer/formatter can still be NULL even on
master (namely after allocation failure), therefore the checks need to
be there.

- Andreas

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

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

[FFmpeg-devel] [PATCH v3] libavformat/dashdec: Fix buffer overflow in segment URL resolution

[xiaohuanshu]

From: xiaohuanshu 

Problem:
The max_url_size calculation for DASH segment URLs only considered the base URL
length, leading to buffer overflow when the segment's sourceURL exceeded the
pre-allocated buffer. This triggered the log error:
"DASH request for url 'invalid:truncated'".

Reproduce:
1. A test sample "long-sourceurl-sample.mpd" (deliberately designed with a long
   sourceURL) was uploaded to VideoLAN's repository.
2. Reproduce with short base path:
   ffmpeg -i /tmp/short_path/long-sourceurl-sample.mpd
   -> Triggers "invalid:truncated" error
3. With artificially lengthened base path (e.g. /aaa/../bbb/../...):
   ffmpeg -i /long/../path/../with/../many/../segments/long-sourceurl-sample.mpd
   -> URL resolves correctly (though HTTP fetch fails due to fake URL)

Fix:
Recalculate max_url_size by considering both base URL and sourceURL lengths,
ensuring sufficient buffer allocation during URL concatenation.

V2:
1. no need to determine whether initialization_val is null.
2. fix the incorrect variable name.

V3:
1. change `max_url_size` scope into `Initialization` and `Media` blocks.

Signed-off-by: xiaohuanshu 
---
 libavformat/dashdec.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index c3f3d7f3f8..31a84bd184 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -606,7 +606,6 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 char *initialization_val = NULL;
 char *media_val = NULL;
 char *range_val = NULL;
-int max_url_size = c ? c->max_url_size: MAX_URL_SIZE;
 int err;
 
 if (!av_strcasecmp(fragmenturl_node->name, "Initialization")) {
@@ -620,6 +619,12 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 xmlFree(initialization_val);
 return AVERROR(ENOMEM);
 }
+int max_url_size = FFMAX(
+c ? c->max_url_size : 0,
+aligned(strlen(initialization_val) +
+(rep_id_val ? strlen(rep_id_val) : 0) +
+(rep_bandwidth_val ? strlen(rep_bandwidth_val) : 0)));
+max_url_size = max_url_size ? max_url_size : MAX_URL_SIZE;
 rep->init_section->url = get_content_url(baseurl_nodes, 4,
  max_url_size,
  rep_id_val,
@@ -641,6 +646,11 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 xmlFree(media_val);
 return AVERROR(ENOMEM);
 }
+int max_url_size = FFMAX(
+c ? c->max_url_size : 0,
+aligned(strlen(media_val) + (rep_id_val ? strlen(rep_id_val) : 
0) +
+(rep_bandwidth_val ? strlen(rep_bandwidth_val) : 0)));
+max_url_size = max_url_size ? max_url_size : MAX_URL_SIZE;
 seg->url = get_content_url(baseurl_nodes, 4,
max_url_size,
rep_id_val,
-- 
2.39.5 (Apple Git-154)

___
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/h264bsd_dec: add h264dec base on h264bsd

[Lynne]

On 16/04/2025 08:12, Shiqi Zhu wrote:

h264bsd url https://github.com/oneam/h264bsd
./configure --enable-decoder="h264_bsd" --extra-cflags="-I/h264bsd/src" 
--extra-ldflags="-L/h264bsd/posix/lib" --extra-libs="-lh264bsd"
Test
./ffmpeg -y -codec:v h264_bsd -i /h264bsd/test/test_640x360.h264 
./test_640x360.yuv


Yes, but we already have the best and fastest H264 decoder out there, 
and (for no more than a year or so, until its patents expire and its 
made redundant), an libopenh264 backend.



Signed-off-by: Shiqi Zhu 
---
  libavcodec/Makefile  |   1 +
  libavcodec/allcodecs.c   |   1 +
  libavcodec/h264bsd_dec.c | 183 +++
  3 files changed, 185 insertions(+)
  create mode 100644 libavcodec/h264bsd_dec.c

+
+const FFCodec ff_h264_bsd_decoder = {
+.p.name = "h264_bsd",
+CODEC_LONG_NAME("h264bsd video decoder for ffmpeg"),
+.p.type = AVMEDIA_TYPE_VIDEO,
+.p.id = AV_CODEC_ID_H264,
+.priv_data_size = sizeof(DecodeContext),
+.init = h264_bsd_init_decoder,
+.close = h264_bsd_close_decoder,
+FF_CODEC_DECODE_CB(h264_bsd_decode_frame),
+.flush = h264_bsd_flush,
+.p.priv_class = &h264_bsd_dec_class,
+.bsfs = "h264_mp4toannexb",
+.p.capabilities = AV_CODEC_CAP_DELAY,
+.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_YUV420P, 
AV_PIX_FMT_NONE },
+.p.wrapper_name = "ff_h264_bsd_decoder",
+.caps_internal = FF_CODEC_CAP_EXPORTS_CROPPING,
+};
\ No newline at end of file

^^


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


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

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[Michael Niedermayer]

On Tue, Apr 15, 2025 at 12:17:32AM +, softworkz . wrote:
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Ridley Combs via ffmpeg-devel
> > Sent: Dienstag, 15. April 2025 02:03
> > To: ffmpeg-devel 
> > Cc: Ridley Combs 
> > Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> > decode_str() did advance
> > 
> > 
> > 
> > > On Apr 15, 2025, at 08:59, softworkz .  > hotmail@ffmpeg.org> wrote:
> > >
> > >
> > >
> > >> -Original Message-
> > >> From: ffmpeg-devel mailto:ffmpeg-
> > devel-boun...@ffmpeg.org>> On Behalf Of
> > >> Michael Niedermayer
> > >> Sent: Dienstag, 15. April 2025 01:20
> > >> To: FFmpeg development discussions and patches  > >> de...@ffmpeg.org >
> > >> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> > >> decode_str() did advance
> > >>
> > >> On Sat, Apr 12, 2025 at 01:49:53AM +, softworkz . wrote:
> > >>>
> > >>>
> >  -Original Message-
> >  From: ffmpeg-devel  On Behalf Of
> >  Michael Niedermayer
> >  Sent: Samstag, 12. April 2025 00:27
> >  To: FFmpeg development discussions and patches  > >> de...@ffmpeg.org>
> >  Subject: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> >  decode_str() did advance
> > 
> >  Fixes infinite loop with unknown encodings
> > 
> >  We could alternatively error out from decode_str() or consume all
> > >> of
> >  taglen
> >  this would affect other callers though.
> > 
> >  Fixes: 409819224/clusterfuzz-testcase-minimized-
> > >> ffmpeg_dem_H261_fuzzer-
> >  6003527535362048
> >  Signed-off-by: Michael Niedermayer 
> >  ---
> >  libavformat/id3v2.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> >  diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
> >  index 90314583a74..e3f7f9e2a90 100644
> >  --- a/libavformat/id3v2.c
> >  +++ b/libavformat/id3v2.c
> >  @@ -341,10 +341,13 @@ static void read_ttag(AVFormatContext *s,
> >  AVIOContext *pb, int taglen,
> >  taglen--; /* account for encoding type byte */
> > 
> >  while (taglen > 1) {
> >  +int current_taglen = taglen;
> >  if (decode_str(s, pb, encoding, &dst, &taglen) < 0) {
> >  av_log(s, AV_LOG_ERROR, "Error reading frame %s,
> >  skipped\n", key);
> >  return;
> >  }
> >  +if (current_taglen == taglen)
> >  +return;
> > 
> >  count++;
> > 
> >  --
> >  2.49.0
> > 
> >  ___
> > >>>
> > >>> Hi Michael,
> > >>>
> > >>> this kind of conflicts with this patch that I had submitted
> > >> recently:
> > >>>
> > >>>
> > >>
> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/pull.54.ffstaging.FF
> > >> mpeg.1740873449247.ffmpegag...@gmail.com/
> > >>>
> > >>>
> > >>> I wonder whether my patch would still be prone to the issue your
> > >> patch is addressing -
> > >>
> > >> This already conflicts with rcombs patch in git master, i think
> > >> Applying: Fixes Trac ticket https://trac.ffmpeg.org/ticket/6949
> > >> Using index info to reconstruct a base tree...
> > >> Mlibavformat/id3v2.c
> > >> Falling back to patching base and 3-way merge...
> > >> Auto-merging libavformat/id3v2.c
> > >> CONFLICT (content): Merge conflict in libavformat/id3v2.c
> > >> error: Failed to merge in the changes.
> > >> Patch failed at 0001 Fixes Trac ticket
> > >> https://trac.ffmpeg.org/ticket/6949
> > >>
> > >>
> > >>> do you have a test file perhaps?
> > >>
> > >> Will email you one, but the loop with a function that doesnt
> > advance
> > >> is an issue even if the specific file doesnt trigger it in a
> > different
> > >> implementation
> > >>
> > >> also probaly a good idea if you contact rcombs as you seemed to
> > work
> > >> on
> > >> the same code
> > >>
> > >> I was looking at teh ticket and saw a link to rcombs patch, looked
> > at
> > >> the patch and applied it. I did not realize there where 2 patches
> > >
> > >
> > > Hi Michael,
> > >
> > > I know the rcombs patch, but it has a - let's say - different
> > behavior.
> > > Let's look at an example where artist and genre have multiple
> > values:
> > >
> > >
> > > This was ffmpeg output unpatched:
> > >
> > >  Metadata:
> > >title   : Infinite (Original Mix)
> > >artist  : B-Front
> > >track   : 1
> > >album   : Infinite
> > >date: 2017
> > >genre   : Hardstyle
> > >TBPM: 150
> > >compilation : 0
> > >album_artist: B-Front
> > >publisher   : Roughstate
> > >
> > >
> > > This is what the rcombs patch does:
> > >
> > >  Metadata:
> > >title   : Infinite (Original Mix)
> > >artist  : B-Front
> > >artist  : Second Artist Example
> > >track   : 1
> > >album   : I

Re: [FFmpeg-devel] AVDictionary vs. AVSet (AVDictionary2 approximation)

[Michael Niedermayer]

On Mon, Apr 14, 2025 at 01:02:00PM +, softworkz . wrote:
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > softworkz .
> > Sent: Montag, 14. April 2025 14:40
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] AVDictionary vs. AVSet (AVDictionary2
> > approximation)
> > 
> > 
> > 
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > > Michael Niedermayer
> > > Sent: Montag, 14. April 2025 13:33
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: [FFmpeg-devel] AVDictionary vs. AVSet (AVDictionary2
> > > approximation)
> > >
> > > Hi
> > >
> > > I just posted a AVSet implementation i wrote in the last 2 days (yes
> > > thats
> > > why i did dissapear for the last 2 days)
> > >
> > > My plan was to use that AVSet as basis for AVDictionary2 in case
> > > benchmarks indicate that its worth it, so is it ?
> > >
> > > with 3 entries (10 runs)
> > > AVDictionary0.040sec
> > > AVSet   0.027sec
> > >
> > > with 5 entries (10 runs)
> > > AVDictionary0.065sec
> > > AVSet   0.042sec
> > >
> > > with 10 entries (10 runs)
> > > AVDictionary0.193sec
> > > AVSet   0.087sec
> > >
> > > with 100 entries (10 runs)
> > > AVDictionary8.7  sec
> > > AVSet   1.4  sec
> > >
> > > with 1000 entries (1000 runs)
> > > AVDictionary8.0   sec
> > > AVSet   0.240 sec
> > >
> > > with 1 entries (10 runs)
> > > AVDictionary7.2   sec
> > > AVSet   0.042 sec
> > >
> > >
> > > I was a bit surprised for the 3 and 5 entry case, maybe my benchmark
> > > is buggy or
> > > AVSet is, but then AVDictionary is pretty bad with memory
> > allocations
> > >
> > > AVDictionary needs to strdup every key and value, needs to allocate
> > > the AVDictionary itself and reallocs the entry array each time
> > > thats 10 memory allocation related calls for adding 3 entries
> > >
> > > while AVSet allocates the AVSet and then uses av_fast_realloc() for
> > > the array
> > > and theres nothing else, the key/value goes in that array too
> > >
> > >
> > > bechmark code used is below:
> > >
> > >
> > > #if 0
> > > for (int runs = 0; runs < 10; runs++) {
> > > AVSet *set = av_set_new(strcmp, NULL, NULL);
> > > for(int pass = 0; pass < 2; pass++) {
> > > unsigned r = 5;
> > > for(int i=0; i<100; i++) {
> > > r = r*123 + 7;
> > > char str[2*7] = "TESTXXTESTXX";
> > > str[4] = r;
> > > str[5] = r>>8;
> > > if(pass == 0) {
> > > av_set_add(set, str, 2*7, 0);
> > > } else {
> > > av_set_get(set, NULL, str, NULL);
> > > }
> > > }
> > > }
> > > av_set_free(&set);
> > > }
> > > #else
> > > for (int runs = 0; runs < 10; runs++) {
> > > AVDictionary *dict = NULL;
> > > for(int pass = 0; pass < 2; pass++) {
> > > unsigned r = 5;
> > > for(int i=0; i<100; i++) {
> > > r = r*123 + 7;
> > > char str[7] = "TEST";
> > > str[4] = r;
> > > str[5] = r>>8;
> > > if(pass == 0) {
> > > av_dict_set(&dict, str, str, 0);
> > > } else {
> > > av_dict_get(dict, str, NULL, 0);
> > > }
> > > }
> > > }
> > > av_dict_free(&dict);
> > > }
> > > #endif
> > >
> > >
> > > --
> > 
> > Hi Michael,
> > 
> > 
> > what's not quite realistic is that all keys are starting with the same
> > 4 characters. This affects the lookups of course - and probably
> > (maybe) not equally for both sides.
> > 
> > Doesn't the code create duplicate keys (at least when it gets > 65536
> > it will for sure) ?
> > 
> > So, I think, the keys should be completely random (all chars).
> > 
> > I would also check whether the lookups are successful (just to be
> > sure).
> 
> Sorry, I forgot the most important one: 
> 
> Timing for population and lookup should be measured separately..

Sure, for the v2 (AVMap) i just posted

with TESTXX / TESTXX strings where XX is random

1000 entries
  5354505 decicycles in av_map_add, 512 runs,  0 skips
  4040575 decicycles in av_map_get, 512 runs,  0 skips
148082828 decicycles in av_dict_set, 512 runs,  0 skips
145828939 decicycles in av_dict_get, 512 runs,  0 skips

100 entries
 332015 decicycles in av_map_add, 512 runs,  0 skips
 193726 decicycles in av_map_get, 512 runs,  0 skips
1697242 decicycles in av_dict_set, 512 runs,  0 skips
1392837 decicycles in av_dict_get, 512 runs,  0 skips

10 entries
  21142 decicycles in av_map_add, 512 runs,  0 skips
  11395 decicycles in av_map_get, 512 runs,  0 skips
  45663 decicycles in a

Re: [FFmpeg-devel] [PATCH v2 5/6] libavutil: Add AVMap

[Nicolas George]

Michael Niedermayer (HE12025-04-15):
> Where exactly would that benefit FFmpeg ?
> Dictionaries generally are used to move stuff aorund, like metadata or
> options.
> Or may be used in the future to keep track of some mappings like
> timestamps to file positions during demuxing or muxing
> Or maybe codecs/formats lookup from name
> None of these are confined to a single local function

AVMap opts = av_map_create(cmp, NULL, NULL);
av_map_add(opts, "threads", "12");
av_map_add(opts, "crf", "18");
av_map_add(opts, "preset", "veryslow");
av_map_assert_small(opts);
ret = av_codec_open3(ctx, codec, opts);

> i like av_map_new() because "new" is short

The exact name does not matter to me. I forgot that we usually use
_alloc() for the case you implemented, so _new() is absolutely fine for
this.

av_map_assert_small() should assert that no dynamic allocation happened,
and at assert level 2 that the internal buffer is less than halfway full.

> and sizeof(AVMap) is not public API

It should be public API like I did for BPrint, that is my point.

Regards,

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

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

[FFmpeg-devel] [PATCH] hwcontext_vulkan: check if expect_assume is supported by the headers

[Lynne]

---
 libavutil/hwcontext_vulkan.c | 8 
 libavutil/vulkan_loader.h| 2 ++
 2 files changed, 10 insertions(+)

diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index 8823af0175..f878dfec76 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -79,7 +79,9 @@ typedef struct VulkanDeviceFeatures {
 VkPhysicalDeviceVulkan12Features vulkan_1_2;
 VkPhysicalDeviceVulkan13Features vulkan_1_3;
 VkPhysicalDeviceTimelineSemaphoreFeatures timeline_semaphore;
+#ifdef VK_KHR_expect_assume
 VkPhysicalDeviceShaderExpectAssumeFeatures expect_assume;
+#endif
 
 VkPhysicalDeviceVideoMaintenance1FeaturesKHR video_maintenance_1;
 #ifdef VK_KHR_video_maintenance2
@@ -211,8 +213,10 @@ static void device_features_init(AVHWDeviceContext *ctx, 
VulkanDeviceFeatures *f
 OPT_CHAIN(&feats->timeline_semaphore, FF_VK_EXT_PORTABILITY_SUBSET,
   VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TIMELINE_SEMAPHORE_FEATURES);
 
+#ifdef VK_KHR_expect_assume
 OPT_CHAIN(&feats->expect_assume, FF_VK_EXT_EXPECT_ASSUME,
   
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_EXPECT_ASSUME_FEATURES_KHR);
+#endif
 
 OPT_CHAIN(&feats->video_maintenance_1, FF_VK_EXT_VIDEO_MAINTENANCE_1,
   
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_MAINTENANCE_1_FEATURES_KHR);
@@ -306,7 +310,9 @@ static void 
device_features_copy_needed(VulkanDeviceFeatures *dst, VulkanDeviceF
 COPY_VAL(relaxed_extended_instruction.shaderRelaxedExtendedInstruction);
 #endif
 
+#ifdef VK_KHR_expect_assume
 COPY_VAL(expect_assume.shaderExpectAssume);
+#endif
 
 COPY_VAL(optical_flow.opticalFlow);
 #undef COPY_VAL
@@ -622,7 +628,9 @@ static const VulkanOptExtension optional_device_exts[] = {
 { VK_KHR_COOPERATIVE_MATRIX_EXTENSION_NAME,   
FF_VK_EXT_COOP_MATRIX},
 { VK_NV_OPTICAL_FLOW_EXTENSION_NAME,  
FF_VK_EXT_OPTICAL_FLOW   },
 { VK_EXT_SHADER_OBJECT_EXTENSION_NAME,
FF_VK_EXT_SHADER_OBJECT  },
+#ifdef VK_KHR_expect_assume
 { VK_KHR_SHADER_EXPECT_ASSUME_EXTENSION_NAME, 
FF_VK_EXT_EXPECT_ASSUME  },
+#endif
 { VK_KHR_VIDEO_MAINTENANCE_1_EXTENSION_NAME,  
FF_VK_EXT_VIDEO_MAINTENANCE_1},
 #ifdef VK_KHR_video_maintenance2
 { VK_KHR_VIDEO_MAINTENANCE_2_EXTENSION_NAME,  
FF_VK_EXT_VIDEO_MAINTENANCE_2},
diff --git a/libavutil/vulkan_loader.h b/libavutil/vulkan_loader.h
index 3641fcb22e..46172403ba 100644
--- a/libavutil/vulkan_loader.h
+++ b/libavutil/vulkan_loader.h
@@ -76,7 +76,9 @@ static inline uint64_t ff_vk_extensions_to_mask(const char * 
const *extensions,
 { VK_KHR_VIDEO_DECODE_H265_EXTENSION_NAME, 
FF_VK_EXT_VIDEO_DECODE_H265  },
 { VK_KHR_VIDEO_DECODE_AV1_EXTENSION_NAME,  
FF_VK_EXT_VIDEO_DECODE_AV1   },
 { VK_KHR_PUSH_DESCRIPTOR_EXTENSION_NAME,   
FF_VK_EXT_PUSH_DESCRIPTOR},
+#ifdef VK_KHR_expect_assume
 { VK_KHR_SHADER_EXPECT_ASSUME_EXTENSION_NAME,  
FF_VK_EXT_EXPECT_ASSUME  },
+#endif
 };
 
 FFVulkanExtensions mask = 0x0;
-- 
2.49.0.395.g12beb8f557c
___
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] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Dienstag, 15. April 2025 20:56
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> On Mon, Apr 14, 2025 at 11:59:02PM +, softworkz . wrote:
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > > Michael Niedermayer
> > > Sent: Dienstag, 15. April 2025 01:20
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> > > decode_str() did advance
> > >
> > > On Sat, Apr 12, 2025 at 01:49:53AM +, softworkz . wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: ffmpeg-devel  On Behalf
> Of
> > > > > Michael Niedermayer
> > > > > Sent: Samstag, 12. April 2025 00:27
> > > > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > > > Subject: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> > > > > decode_str() did advance
> > > > >
> > > > > Fixes infinite loop with unknown encodings
> > > > >
> > > > > We could alternatively error out from decode_str() or consume
> all
> > > of
> > > > > taglen
> > > > > this would affect other callers though.
> > > > >
> > > > > Fixes: 409819224/clusterfuzz-testcase-minimized-
> > > ffmpeg_dem_H261_fuzzer-
> > > > > 6003527535362048
> > > > > Signed-off-by: Michael Niedermayer 
> > > > > ---
> > > > >  libavformat/id3v2.c | 3 +++
> > > > >  1 file changed, 3 insertions(+)
> > > > >
> > > > > diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
> > > > > index 90314583a74..e3f7f9e2a90 100644
> > > > > --- a/libavformat/id3v2.c
> > > > > +++ b/libavformat/id3v2.c
> > > > > @@ -341,10 +341,13 @@ static void read_ttag(AVFormatContext
> *s,
> > > > > AVIOContext *pb, int taglen,
> > > > >  taglen--; /* account for encoding type byte */
> > > > >
> > > > >  while (taglen > 1) {
> > > > > +int current_taglen = taglen;
> > > > >  if (decode_str(s, pb, encoding, &dst, &taglen) < 0) {
> > > > >  av_log(s, AV_LOG_ERROR, "Error reading frame %s,
> > > > > skipped\n", key);
> > > > >  return;
> > > > >  }
> > > > > +if (current_taglen == taglen)
> > > > > +return;
> > > > >
> > > > >  count++;
> > > > >
> > > > > --
> > > > > 2.49.0
> > > > >
> > > > > ___
> > > >
> > > > Hi Michael,
> > > >
> > > > this kind of conflicts with this patch that I had submitted
> > > recently:
> > > >
> > > >
> > >
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/pull.54.ffstaging.FF
> > > mpeg.1740873449247.ffmpegag...@gmail.com/
> > > >
> > > >
> > > > I wonder whether my patch would still be prone to the issue your
> > > patch is addressing -
> > >
> > > This already conflicts with rcombs patch in git master, i think
> > > Applying: Fixes Trac ticket https://trac.ffmpeg.org/ticket/6949
> > > Using index info to reconstruct a base tree...
> > > M libavformat/id3v2.c
> > > Falling back to patching base and 3-way merge...
> > > Auto-merging libavformat/id3v2.c
> > > CONFLICT (content): Merge conflict in libavformat/id3v2.c
> > > error: Failed to merge in the changes.
> > > Patch failed at 0001 Fixes Trac ticket
> > > https://trac.ffmpeg.org/ticket/6949
> > >
> > >
> > > > do you have a test file perhaps?
> > >
> > > Will email you one, but the loop with a function that doesnt
> advance
> > > is an issue even if the specific file doesnt trigger it in a
> different
> > > implementation
> > >
> > > also probaly a good idea if you contact rcombs as you seemed to
> work
> > > on
> > > the same code
> > >
> > > I was looking at teh ticket and saw a link to rcombs patch, looked
> at
> > > the patch and applied it. I did not realize there where 2 patches
> >
> >
> > Hi Michael,
> >
> > I know the rcombs patch, but it has a - let's say - different
> behavior.
> > Let's look at an example where artist and genre have multiple
> values:
> >
> >
> > This was ffmpeg output unpatched:
> >
> >   Metadata:
> > title   : Infinite (Original Mix)
> > artist  : B-Front
> > track   : 1
> > album   : Infinite
> > date: 2017
> > genre   : Hardstyle
> > TBPM: 150
> > compilation : 0
> > album_artist: B-Front
> > publisher   : Roughstate
> >
> >
> > This is what the rcombs patch does:
> >
> >   Metadata:
> > title   : Infinite (Original Mix)
> > artist  : B-Front
> > artist  : Second Artist Example
> > track   : 1
> > album   : Infinite
> > date: 2017
> > genre   : Hardstyle
> > genre   : Test
> > genre   : Example
> > genre   : Hard Dance
> > TBPM: 150
> > com

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Nicolas George
> Sent: Dienstag, 15. April 2025 21:03
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> Michael Niedermayer (HE12025-04-15):
> > I think ffprobe should not generate invalid output if metadata given
> to it has
> > 2 entries with the same key, independant of that being the correct
> way to export
> > metadata.
> 
> Good thing that “The JSON syntax […] does not require that name
> strings
> be unique”.
> 
> https://ecma-international.org/publications-and-
> standards/standards/ecma-404/
> 

That's a good thing indeed, but it would be a breaking change for all
users of FFprobe output - and not only JSON but actually all formats.

sw




___
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] libpostproc: deprecate the AMD 3DNow! define

[Sean McGovern]

It was left unreferenced in 1f0948272a0fcd0e4947f629b600983f3338c02f.
---
 doc/APIchanges  | 3 +++
 libpostproc/postprocess.h   | 2 ++
 libpostproc/version.h   | 2 +-
 libpostproc/version_major.h | 2 ++
 4 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 65bf5a9419..2236ee1a88 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2025-03-28
 
 API changes, most recent first:
 
+2025-04-xx - ?? - libpostproc 59.0.101 - postprocess.h
+  Deprecate PP_CPU_CAPS_3DNOW.
+
 2025-04-07 - 19e9a203b7 - lavu 60.01.100 - dict.h
   Add AV_DICT_DEDUP.
 
diff --git a/libpostproc/postprocess.h b/libpostproc/postprocess.h
index 5decb7e8a9..d2adb6ccad 100644
--- a/libpostproc/postprocess.h
+++ b/libpostproc/postprocess.h
@@ -87,7 +87,9 @@ void pp_free_context(pp_context *ppContext);
 
 #define PP_CPU_CAPS_MMX   0x8000
 #define PP_CPU_CAPS_MMX2  0x2000
+#if FF_API_PP_AMD_3DNOW
 #define PP_CPU_CAPS_3DNOW 0x4000
+#endif
 #define PP_CPU_CAPS_ALTIVEC 0x1000
 #define PP_CPU_CAPS_AUTO  0x0008
 
diff --git a/libpostproc/version.h b/libpostproc/version.h
index bcbdd210c4..de09db989f 100644
--- a/libpostproc/version.h
+++ b/libpostproc/version.h
@@ -31,7 +31,7 @@
 #include "version_major.h"
 
 #define LIBPOSTPROC_VERSION_MINOR   0
-#define LIBPOSTPROC_VERSION_MICRO 100
+#define LIBPOSTPROC_VERSION_MICRO 101
 
 #define LIBPOSTPROC_VERSION_INT AV_VERSION_INT(LIBPOSTPROC_VERSION_MAJOR, \
LIBPOSTPROC_VERSION_MINOR, \
diff --git a/libpostproc/version_major.h b/libpostproc/version_major.h
index b40b251a73..b9946912db 100644
--- a/libpostproc/version_major.h
+++ b/libpostproc/version_major.h
@@ -28,4 +28,6 @@
 
 #define LIBPOSTPROC_VERSION_MAJOR  59
 
+#define FF_API_PP_AMD_3DNOW  (LIBPOSTPROC_VERSION_MAJOR < 60)
+
 #endif /* POSTPROC_VERSION_MAJOR_H */
-- 
2.39.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".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Dienstag, 15. April 2025 20:33
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> On Tue, Apr 15, 2025 at 12:17:32AM +, softworkz . wrote:
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > > Ridley Combs via ffmpeg-devel
> > > Sent: Dienstag, 15. April 2025 02:03
> > > To: ffmpeg-devel 
> > > Cc: Ridley Combs 
> > > Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> > > decode_str() did advance
> > >
> > >
> > >
> > > > On Apr 15, 2025, at 08:59, softworkz .  > > hotmail@ffmpeg.org> wrote:
> > > >
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: ffmpeg-devel   > > devel-boun...@ffmpeg.org>> On Behalf Of
> > > >> Michael Niedermayer
> > > >> Sent: Dienstag, 15. April 2025 01:20
> > > >> To: FFmpeg development discussions and patches  > > >> de...@ffmpeg.org >
> > > >> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check
> that
> > > >> decode_str() did advance
> > > >>
> > > >> On Sat, Apr 12, 2025 at 01:49:53AM +, softworkz . wrote:
> > > >>>
> > > >>>
> > >  -Original Message-
> > >  From: ffmpeg-devel  On
> Behalf Of
> > >  Michael Niedermayer
> > >  Sent: Samstag, 12. April 2025 00:27
> > >  To: FFmpeg development discussions and patches  > > >> de...@ffmpeg.org>
> > >  Subject: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check
> that
> > >  decode_str() did advance
> > > 
> > >  Fixes infinite loop with unknown encodings
> > > 
> > >  We could alternatively error out from decode_str() or consume
> all
> > > >> of
> > >  taglen
> > >  this would affect other callers though.
> > > 
> > >  Fixes: 409819224/clusterfuzz-testcase-minimized-
> > > >> ffmpeg_dem_H261_fuzzer-
> > >  6003527535362048
> > >  Signed-off-by: Michael Niedermayer 
> > >  ---
> > >  libavformat/id3v2.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > >  diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
> > >  index 90314583a74..e3f7f9e2a90 100644
> > >  --- a/libavformat/id3v2.c
> > >  +++ b/libavformat/id3v2.c
> > >  @@ -341,10 +341,13 @@ static void read_ttag(AVFormatContext
> *s,
> > >  AVIOContext *pb, int taglen,
> > >  taglen--; /* account for encoding type byte */
> > > 
> > >  while (taglen > 1) {
> > >  +int current_taglen = taglen;
> > >  if (decode_str(s, pb, encoding, &dst, &taglen) < 0) {
> > >  av_log(s, AV_LOG_ERROR, "Error reading frame %s,
> > >  skipped\n", key);
> > >  return;
> > >  }
> > >  +if (current_taglen == taglen)
> > >  +return;
> > > 
> > >  count++;
> > > 
> > >  --
> > >  2.49.0
> > > 
> > >  ___
> > > >>>
> > > >>> Hi Michael,
> > > >>>
> > > >>> this kind of conflicts with this patch that I had submitted
> > > >> recently:
> > > >>>
> > > >>>
> > > >>
> > >
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/pull.54.ffstaging.FF
> > > >> mpeg.1740873449247.ffmpegag...@gmail.com/
> > > >>>
> > > >>>
> > > >>> I wonder whether my patch would still be prone to the issue
> your
> > > >> patch is addressing -
> > > >>
> > > >> This already conflicts with rcombs patch in git master, i think
> > > >> Applying: Fixes Trac ticket https://trac.ffmpeg.org/ticket/6949
> > > >> Using index info to reconstruct a base tree...
> > > >> M  libavformat/id3v2.c
> > > >> Falling back to patching base and 3-way merge...
> > > >> Auto-merging libavformat/id3v2.c
> > > >> CONFLICT (content): Merge conflict in libavformat/id3v2.c
> > > >> error: Failed to merge in the changes.
> > > >> Patch failed at 0001 Fixes Trac ticket
> > > >> https://trac.ffmpeg.org/ticket/6949
> > > >>
> > > >>
> > > >>> do you have a test file perhaps?
> > > >>
> > > >> Will email you one, but the loop with a function that doesnt
> > > advance
> > > >> is an issue even if the specific file doesnt trigger it in a
> > > different
> > > >> implementation
> > > >>
> > > >> also probaly a good idea if you contact rcombs as you seemed to
> > > work
> > > >> on
> > > >> the same code
> > > >>
> > > >> I was looking at teh ticket and saw a link to rcombs patch,
> looked
> > > at
> > > >> the patch and applied it. I did not realize there where 2
> patches
> > > >
> > > >
> > > > Hi Michael,
> > > >
> > > > I know the rcombs patch, but it has a - let's say - different
> > > behavior.
> > > > Let's look at an example where artist and genre have multiple
> > > values:
> > > >
> > > >
> > > > This was ffmpeg output unpatched:
> > > >
> > > >  Metadata:
> > > >title   : Infinite (Orig

Re: [FFmpeg-devel] [PATCH] avcodec/libjxlenc: prevent color encoding from being set twice

[Leo Izen]

On 4/13/25 06:12, Leo Izen wrote:

We currently populate the color encoding bundle and then check to see
if there's an ICC profile to attach, and set the color encoding bundle
in either case. The ICC profile overrides the color encoding bundle, so
we should not calculate enum-based color encoding if we have an ICC
profile present. Fixes several unnecessary warnings from being emitted.

Signed-off-by: Leo Izen 
---
  libavcodec/libjxlenc.c | 115 +
  1 file changed, 59 insertions(+), 56 deletions(-)


Will apply soon. (I maintain this section of code.)

- Leo Izen (Traneptora)

___
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] avformat/id3v2: Check that decode_str() did advance

[Michael Niedermayer]

Hi

On Tue, Apr 15, 2025 at 01:37:56AM +, softworkz . wrote:
[...]
> > > do you have a test file perhaps?
> > 
> > Will email you one, but the loop with a function that doesnt advance
> > is an issue even if the specific file doesnt trigger it in a different
> > implementation
> 
> 
> Thanks a lot for the test file. I was able to reproduce the eternal loop
> that you were intending to fix, but I noticed that after removing the 
> patches from rcombs, that endless loop doesn't happen in the first place.

the patch was intended to fix that regression yes. But your patch contains
a very similarly looking loop to what caused that. Which is what i meant,
that because it looks similar it should be checked for that

thx

[...]
-- 
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 2/2] avformat/id3v2: Check that decode_str() did advance

[Nicolas George]

Ridley Combs via ffmpeg-devel (HE12025-04-15):
> This is an issue that should be resolved by supporting multiple
> entries all the way through the relevant ffmpeg.c and muxer code
> paths, rather than adding new fragile usage of in-band signaling
> within metadata strings.

Since it has been neglected in the ensuing discussion, I want to point
that I second that.

Regards,

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

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[Nicolas George]

Michael Niedermayer (HE12025-04-15):
> I think ffprobe should not generate invalid output if metadata given to it has
> 2 entries with the same key, independant of that being the correct way to 
> export
> metadata.

Good thing that “The JSON syntax […] does not require that name strings
be unique”.

https://ecma-international.org/publications-and-standards/standards/ecma-404/

Regards,

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

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[Michael Niedermayer]

On Mon, Apr 14, 2025 at 11:59:02PM +, softworkz . wrote:
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Michael Niedermayer
> > Sent: Dienstag, 15. April 2025 01:20
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> > decode_str() did advance
> > 
> > On Sat, Apr 12, 2025 at 01:49:53AM +, softworkz . wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel  On Behalf Of
> > > > Michael Niedermayer
> > > > Sent: Samstag, 12. April 2025 00:27
> > > > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > > > Subject: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> > > > decode_str() did advance
> > > >
> > > > Fixes infinite loop with unknown encodings
> > > >
> > > > We could alternatively error out from decode_str() or consume all
> > of
> > > > taglen
> > > > this would affect other callers though.
> > > >
> > > > Fixes: 409819224/clusterfuzz-testcase-minimized-
> > ffmpeg_dem_H261_fuzzer-
> > > > 6003527535362048
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  libavformat/id3v2.c | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
> > > > index 90314583a74..e3f7f9e2a90 100644
> > > > --- a/libavformat/id3v2.c
> > > > +++ b/libavformat/id3v2.c
> > > > @@ -341,10 +341,13 @@ static void read_ttag(AVFormatContext *s,
> > > > AVIOContext *pb, int taglen,
> > > >  taglen--; /* account for encoding type byte */
> > > >
> > > >  while (taglen > 1) {
> > > > +int current_taglen = taglen;
> > > >  if (decode_str(s, pb, encoding, &dst, &taglen) < 0) {
> > > >  av_log(s, AV_LOG_ERROR, "Error reading frame %s,
> > > > skipped\n", key);
> > > >  return;
> > > >  }
> > > > +if (current_taglen == taglen)
> > > > +return;
> > > >
> > > >  count++;
> > > >
> > > > --
> > > > 2.49.0
> > > >
> > > > ___
> > >
> > > Hi Michael,
> > >
> > > this kind of conflicts with this patch that I had submitted
> > recently:
> > >
> > >
> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/pull.54.ffstaging.FF
> > mpeg.1740873449247.ffmpegag...@gmail.com/
> > >
> > >
> > > I wonder whether my patch would still be prone to the issue your
> > patch is addressing -
> > 
> > This already conflicts with rcombs patch in git master, i think
> > Applying: Fixes Trac ticket https://trac.ffmpeg.org/ticket/6949
> > Using index info to reconstruct a base tree...
> > M   libavformat/id3v2.c
> > Falling back to patching base and 3-way merge...
> > Auto-merging libavformat/id3v2.c
> > CONFLICT (content): Merge conflict in libavformat/id3v2.c
> > error: Failed to merge in the changes.
> > Patch failed at 0001 Fixes Trac ticket
> > https://trac.ffmpeg.org/ticket/6949
> > 
> > 
> > > do you have a test file perhaps?
> > 
> > Will email you one, but the loop with a function that doesnt advance
> > is an issue even if the specific file doesnt trigger it in a different
> > implementation
> > 
> > also probaly a good idea if you contact rcombs as you seemed to work
> > on
> > the same code
> > 
> > I was looking at teh ticket and saw a link to rcombs patch, looked at
> > the patch and applied it. I did not realize there where 2 patches
> 
> 
> Hi Michael,
> 
> I know the rcombs patch, but it has a - let's say - different behavior.
> Let's look at an example where artist and genre have multiple values:
> 
> 
> This was ffmpeg output unpatched:
> 
>   Metadata:
> title   : Infinite (Original Mix)
> artist  : B-Front
> track   : 1
> album   : Infinite
> date: 2017
> genre   : Hardstyle
> TBPM: 150
> compilation : 0
> album_artist: B-Front
> publisher   : Roughstate
> 
> 
> This is what the rcombs patch does:
> 
>   Metadata:
> title   : Infinite (Original Mix)
> artist  : B-Front
> artist  : Second Artist Example
> track   : 1
> album   : Infinite
> date: 2017
> genre   : Hardstyle
> genre   : Test
> genre   : Example
> genre   : Hard Dance
> TBPM: 150
> compilation : 0
> album_artist: B-Front
> publisher   : Roughstate
> 
> 
> 
> My path does that:
> 
>   Metadata:
> title   : Infinite (Original Mix)
> artist  : B-Front;Second Artist Example
> track   : 1
> album   : Infinite
> date: 2017
> genre   : Hardstyle;Test;Example;Hard Dance
> TBPM: 150
> compilation : 0
> album_artist: B-Front
> publisher   : Roughstate

Iam perfectly fine with either way
but i have to point out that the 2nd 

Re: [FFmpeg-devel] [PATCH v2 5/6] libavutil: Add AVMap

[Nicolas George]

Michael Niedermayer (HE12025-04-15):
> +AVMap *av_map_new(AVMapCompareFunc cmp_keyvalue, AVMapCopyFunc copy, 
> AVMapFreeFunc freef)
> +{
> +AVMap *s = av_mallocz(sizeof(*s));
> +if (!s)
> +return NULL;

Please no.

The ability to allocate on stack including room for a few values is more
important than any performance enhancement for large maps.

> +AVMap *set = av_map_new(our_cmp[settype], NULL, NULL);

… should be :

AVMap set = av_map_create(cmp, NULL, NULL);

or :

AVMap set;
av_map_init(&set, sizeof(set), cmp, NULL, NULL);

Regards,

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

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

Re: [FFmpeg-devel] [PATCH v2 5/6] libavutil: Add AVMap

[Michael Niedermayer]

Hi Nicolas

On Tue, Apr 15, 2025 at 08:45:27PM +0200, Nicolas George wrote:
> Michael Niedermayer (HE12025-04-15):
> > +AVMap *av_map_new(AVMapCompareFunc cmp_keyvalue, AVMapCopyFunc copy, 
> > AVMapFreeFunc freef)
> > +{
> > +AVMap *s = av_mallocz(sizeof(*s));
> > +if (!s)
> > +return NULL;
> 
> Please no.
> 
> The ability to allocate on stack including room for a few values is more
> important than any performance enhancement for large maps.

Where exactly would that benefit FFmpeg ?
Dictionaries generally are used to move stuff aorund, like metadata or
options.
Or may be used in the future to keep track of some mappings like
timestamps to file positions during demuxing or muxing
Or maybe codecs/formats lookup from name

None of these are confined to a single local function


> 
> > +AVMap *set = av_map_new(our_cmp[settype], NULL, NULL);
> 
> … should be :
> 
>   AVMap set = av_map_create(cmp, NULL, NULL);
> 
> or :
> 
>   AVMap set;
>   av_map_init(&set, sizeof(set), cmp, NULL, NULL);

i like av_map_new() because "new" is short
and sizeof(AVMap) is not public API

thx

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Dienstag, 15. April 2025 20:26
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> Hi
> 
> On Tue, Apr 15, 2025 at 01:37:56AM +, softworkz . wrote:
> [...]
> > > > do you have a test file perhaps?
> > >
> > > Will email you one, but the loop with a function that doesnt
> advance
> > > is an issue even if the specific file doesnt trigger it in a
> different
> > > implementation
> >
> >
> > Thanks a lot for the test file. I was able to reproduce the eternal
> loop
> > that you were intending to fix, but I noticed that after removing
> the
> > patches from rcombs, that endless loop doesn't happen in the first
> place.
> 
> the patch was intended to fix that regression yes. But your patch
> contains
> a very similarly looking loop to what caused that. Which is what i
> meant,
> that because it looks similar it should be checked for that

Of course, I've checked that and - albeit similar - it does not expose
this eternal-looping problem.

Thanks
sw


___
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] hwcontext_vulkan: check if expect_assume is supported by the headers

[James Almer]

On 4/15/2025 4:31 PM, Lynne wrote:

---
  libavutil/hwcontext_vulkan.c | 8 
  libavutil/vulkan_loader.h| 2 ++
  2 files changed, 10 insertions(+)

diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index 8823af0175..f878dfec76 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -79,7 +79,9 @@ typedef struct VulkanDeviceFeatures {
  VkPhysicalDeviceVulkan12Features vulkan_1_2;
  VkPhysicalDeviceVulkan13Features vulkan_1_3;
  VkPhysicalDeviceTimelineSemaphoreFeatures timeline_semaphore;
+#ifdef VK_KHR_expect_assume


Are you sure it's not VK_KHR_shader_expect_assume as mentioned in 
https://registry.khronos.org/vulkan/specs/latest/man/html/VkPhysicalDeviceShaderExpectAssumeFeatures.html 
?



  VkPhysicalDeviceShaderExpectAssumeFeatures expect_assume;
+#endif
  
  VkPhysicalDeviceVideoMaintenance1FeaturesKHR video_maintenance_1;

  #ifdef VK_KHR_video_maintenance2
@@ -211,8 +213,10 @@ static void device_features_init(AVHWDeviceContext *ctx, 
VulkanDeviceFeatures *f
  OPT_CHAIN(&feats->timeline_semaphore, FF_VK_EXT_PORTABILITY_SUBSET,
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TIMELINE_SEMAPHORE_FEATURES);
  
+#ifdef VK_KHR_expect_assume

  OPT_CHAIN(&feats->expect_assume, FF_VK_EXT_EXPECT_ASSUME,

VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_EXPECT_ASSUME_FEATURES_KHR);
+#endif
  
  OPT_CHAIN(&feats->video_maintenance_1, FF_VK_EXT_VIDEO_MAINTENANCE_1,


VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_MAINTENANCE_1_FEATURES_KHR);
@@ -306,7 +310,9 @@ static void 
device_features_copy_needed(VulkanDeviceFeatures *dst, VulkanDeviceF
  COPY_VAL(relaxed_extended_instruction.shaderRelaxedExtendedInstruction);
  #endif
  
+#ifdef VK_KHR_expect_assume

  COPY_VAL(expect_assume.shaderExpectAssume);
+#endif
  
  COPY_VAL(optical_flow.opticalFlow);

  #undef COPY_VAL
@@ -622,7 +628,9 @@ static const VulkanOptExtension optional_device_exts[] = {
  { VK_KHR_COOPERATIVE_MATRIX_EXTENSION_NAME,   
FF_VK_EXT_COOP_MATRIX},
  { VK_NV_OPTICAL_FLOW_EXTENSION_NAME,  
FF_VK_EXT_OPTICAL_FLOW   },
  { VK_EXT_SHADER_OBJECT_EXTENSION_NAME,
FF_VK_EXT_SHADER_OBJECT  },
+#ifdef VK_KHR_expect_assume
  { VK_KHR_SHADER_EXPECT_ASSUME_EXTENSION_NAME, 
FF_VK_EXT_EXPECT_ASSUME  },
+#endif
  { VK_KHR_VIDEO_MAINTENANCE_1_EXTENSION_NAME,  
FF_VK_EXT_VIDEO_MAINTENANCE_1},
  #ifdef VK_KHR_video_maintenance2
  { VK_KHR_VIDEO_MAINTENANCE_2_EXTENSION_NAME,  
FF_VK_EXT_VIDEO_MAINTENANCE_2},
diff --git a/libavutil/vulkan_loader.h b/libavutil/vulkan_loader.h
index 3641fcb22e..46172403ba 100644
--- a/libavutil/vulkan_loader.h
+++ b/libavutil/vulkan_loader.h
@@ -76,7 +76,9 @@ static inline uint64_t ff_vk_extensions_to_mask(const char * 
const *extensions,
  { VK_KHR_VIDEO_DECODE_H265_EXTENSION_NAME, 
FF_VK_EXT_VIDEO_DECODE_H265  },
  { VK_KHR_VIDEO_DECODE_AV1_EXTENSION_NAME,  
FF_VK_EXT_VIDEO_DECODE_AV1   },
  { VK_KHR_PUSH_DESCRIPTOR_EXTENSION_NAME,   
FF_VK_EXT_PUSH_DESCRIPTOR},
+#ifdef VK_KHR_expect_assume
  { VK_KHR_SHADER_EXPECT_ASSUME_EXTENSION_NAME,  
FF_VK_EXT_EXPECT_ASSUME  },
+#endif
  };
  
  FFVulkanExtensions mask = 0x0;




OpenPGP_signature.asc
Description: OpenPGP digital 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] hwcontext_vulkan: check if expect_assume is supported by the headers

[Tristan Matthews]

On Tue, Apr 15, 2025 at 3:35 PM James Almer  wrote:

> On 4/15/2025 4:31 PM, Lynne wrote:
> > ---
> >   libavutil/hwcontext_vulkan.c | 8 
> >   libavutil/vulkan_loader.h| 2 ++
> >   2 files changed, 10 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
> > index 8823af0175..f878dfec76 100644
> > --- a/libavutil/hwcontext_vulkan.c
> > +++ b/libavutil/hwcontext_vulkan.c
> > @@ -79,7 +79,9 @@ typedef struct VulkanDeviceFeatures {
> >   VkPhysicalDeviceVulkan12Features vulkan_1_2;
> >   VkPhysicalDeviceVulkan13Features vulkan_1_3;
> >   VkPhysicalDeviceTimelineSemaphoreFeatures timeline_semaphore;
> > +#ifdef VK_KHR_expect_assume
>
> Are you sure it's not VK_KHR_shader_expect_assume as mentioned in
>
> https://registry.khronos.org/vulkan/specs/latest/man/html/VkPhysicalDeviceShaderExpectAssumeFeatures.html
> ?
>
> >   VkPhysicalDeviceShaderExpectAssumeFeatures expect_assume;
> > +#endif
> >
> >   VkPhysicalDeviceVideoMaintenance1FeaturesKHR video_maintenance_1;
> >   #ifdef VK_KHR_video_maintenance2
> > @@ -211,8 +213,10 @@ static void device_features_init(AVHWDeviceContext
> *ctx, VulkanDeviceFeatures *f
> >   OPT_CHAIN(&feats->timeline_semaphore, FF_VK_EXT_PORTABILITY_SUBSET,
> >
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_TIMELINE_SEMAPHORE_FEATURES);
> >
> > +#ifdef VK_KHR_expect_assume
> >   OPT_CHAIN(&feats->expect_assume, FF_VK_EXT_EXPECT_ASSUME,
> >
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_SHADER_EXPECT_ASSUME_FEATURES_KHR);
> > +#endif
> >
> >   OPT_CHAIN(&feats->video_maintenance_1,
> FF_VK_EXT_VIDEO_MAINTENANCE_1,
> >
>  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_VIDEO_MAINTENANCE_1_FEATURES_KHR);
> > @@ -306,7 +310,9 @@ static void
> device_features_copy_needed(VulkanDeviceFeatures *dst, VulkanDeviceF
> >
>  COPY_VAL(relaxed_extended_instruction.shaderRelaxedExtendedInstruction);
> >   #endif
> >
> > +#ifdef VK_KHR_expect_assume
> >   COPY_VAL(expect_assume.shaderExpectAssume);
> > +#endif
> >
> >   COPY_VAL(optical_flow.opticalFlow);
> >   #undef COPY_VAL
> > @@ -622,7 +628,9 @@ static const VulkanOptExtension
> optional_device_exts[] = {
> >   { VK_KHR_COOPERATIVE_MATRIX_EXTENSION_NAME,
>  FF_VK_EXT_COOP_MATRIX},
> >   { VK_NV_OPTICAL_FLOW_EXTENSION_NAME,
> FF_VK_EXT_OPTICAL_FLOW   },
> >   { VK_EXT_SHADER_OBJECT_EXTENSION_NAME,
> FF_VK_EXT_SHADER_OBJECT  },
> > +#ifdef VK_KHR_expect_assume
> >   { VK_KHR_SHADER_EXPECT_ASSUME_EXTENSION_NAME,
>  FF_VK_EXT_EXPECT_ASSUME  },
> > +#endif
> >   { VK_KHR_VIDEO_MAINTENANCE_1_EXTENSION_NAME,
> FF_VK_EXT_VIDEO_MAINTENANCE_1},
> >   #ifdef VK_KHR_video_maintenance2
> >   { VK_KHR_VIDEO_MAINTENANCE_2_EXTENSION_NAME,
> FF_VK_EXT_VIDEO_MAINTENANCE_2},
> > diff --git a/libavutil/vulkan_loader.h b/libavutil/vulkan_loader.h
> > index 3641fcb22e..46172403ba 100644
> > --- a/libavutil/vulkan_loader.h
> > +++ b/libavutil/vulkan_loader.h
> > @@ -76,7 +76,9 @@ static inline uint64_t ff_vk_extensions_to_mask(const
> char * const *extensions,
> >   { VK_KHR_VIDEO_DECODE_H265_EXTENSION_NAME,
>  FF_VK_EXT_VIDEO_DECODE_H265  },
> >   { VK_KHR_VIDEO_DECODE_AV1_EXTENSION_NAME,
> FF_VK_EXT_VIDEO_DECODE_AV1   },
> >   { VK_KHR_PUSH_DESCRIPTOR_EXTENSION_NAME,
>  FF_VK_EXT_PUSH_DESCRIPTOR},
> > +#ifdef VK_KHR_expect_assume
> >   { VK_KHR_SHADER_EXPECT_ASSUME_EXTENSION_NAME,
> FF_VK_EXT_EXPECT_ASSUME  },
> > +#endif
> >   };
> >
> >   FFVulkanExtensions mask = 0x0;
>
> Can confirm this fixes the build breakage I got from commit
> e040c087c708c3c4a4c747d7042f1825a454ca75 thanks.
>
> Best,
> -t
___
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] AVDictionary vs. AVSet (AVDictionary2 approximation)

[Michael Niedermayer]

On Tue, Apr 15, 2025 at 09:11:33PM +0200, Michael Niedermayer wrote:
> On Mon, Apr 14, 2025 at 01:02:00PM +, softworkz . wrote:
> > 
> > 
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > > softworkz .
> > > Sent: Montag, 14. April 2025 14:40
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] AVDictionary vs. AVSet (AVDictionary2
> > > approximation)
> > > 
> > > 
> > > 
> > > > -Original Message-
> > > > From: ffmpeg-devel  On Behalf Of
> > > > Michael Niedermayer
> > > > Sent: Montag, 14. April 2025 13:33
> > > > To: FFmpeg development discussions and patches  > > > de...@ffmpeg.org>
> > > > Subject: [FFmpeg-devel] AVDictionary vs. AVSet (AVDictionary2
> > > > approximation)
> > > >
> > > > Hi
> > > >
> > > > I just posted a AVSet implementation i wrote in the last 2 days (yes
> > > > thats
> > > > why i did dissapear for the last 2 days)
> > > >
> > > > My plan was to use that AVSet as basis for AVDictionary2 in case
> > > > benchmarks indicate that its worth it, so is it ?
> > > >
> > > > with 3 entries (10 runs)
> > > > AVDictionary0.040sec
> > > > AVSet   0.027sec
> > > >
> > > > with 5 entries (10 runs)
> > > > AVDictionary0.065sec
> > > > AVSet   0.042sec
> > > >
> > > > with 10 entries (10 runs)
> > > > AVDictionary0.193sec
> > > > AVSet   0.087sec
> > > >
> > > > with 100 entries (10 runs)
> > > > AVDictionary8.7  sec
> > > > AVSet   1.4  sec
> > > >
> > > > with 1000 entries (1000 runs)
> > > > AVDictionary8.0   sec
> > > > AVSet   0.240 sec
> > > >
> > > > with 1 entries (10 runs)
> > > > AVDictionary7.2   sec
> > > > AVSet   0.042 sec
> > > >
> > > >
> > > > I was a bit surprised for the 3 and 5 entry case, maybe my benchmark
> > > > is buggy or
> > > > AVSet is, but then AVDictionary is pretty bad with memory
> > > allocations
> > > >
> > > > AVDictionary needs to strdup every key and value, needs to allocate
> > > > the AVDictionary itself and reallocs the entry array each time
> > > > thats 10 memory allocation related calls for adding 3 entries
> > > >
> > > > while AVSet allocates the AVSet and then uses av_fast_realloc() for
> > > > the array
> > > > and theres nothing else, the key/value goes in that array too
> > > >
> > > >
> > > > bechmark code used is below:
> > > >
> > > >
> > > > #if 0
> > > > for (int runs = 0; runs < 10; runs++) {
> > > > AVSet *set = av_set_new(strcmp, NULL, NULL);
> > > > for(int pass = 0; pass < 2; pass++) {
> > > > unsigned r = 5;
> > > > for(int i=0; i<100; i++) {
> > > > r = r*123 + 7;
> > > > char str[2*7] = "TESTXXTESTXX";
> > > > str[4] = r;
> > > > str[5] = r>>8;
> > > > if(pass == 0) {
> > > > av_set_add(set, str, 2*7, 0);
> > > > } else {
> > > > av_set_get(set, NULL, str, NULL);
> > > > }
> > > > }
> > > > }
> > > > av_set_free(&set);
> > > > }
> > > > #else
> > > > for (int runs = 0; runs < 10; runs++) {
> > > > AVDictionary *dict = NULL;
> > > > for(int pass = 0; pass < 2; pass++) {
> > > > unsigned r = 5;
> > > > for(int i=0; i<100; i++) {
> > > > r = r*123 + 7;
> > > > char str[7] = "TEST";
> > > > str[4] = r;
> > > > str[5] = r>>8;
> > > > if(pass == 0) {
> > > > av_dict_set(&dict, str, str, 0);
> > > > } else {
> > > > av_dict_get(dict, str, NULL, 0);
> > > > }
> > > > }
> > > > }
> > > > av_dict_free(&dict);
> > > > }
> > > > #endif
> > > >
> > > >
> > > > --
> > > 
> > > Hi Michael,
> > > 
> > > 
> > > what's not quite realistic is that all keys are starting with the same
> > > 4 characters. This affects the lookups of course - and probably
> > > (maybe) not equally for both sides.
> > > 
> > > Doesn't the code create duplicate keys (at least when it gets > 65536
> > > it will for sure) ?
> > > 
> > > So, I think, the keys should be completely random (all chars).
> > > 
> > > I would also check whether the lookups are successful (just to be
> > > sure).
> > 
> > Sorry, I forgot the most important one: 
> > 
> > Timing for population and lookup should be measured separately..
> 
> Sure, for the v2 (AVMap) i just posted
> 
> with TESTXX / TESTXX strings where XX is random
> 
> 1000 entries
>   5354505 decicycles in av_map_add, 512 runs,  0 skips
>   4040575 decicycles in av_map_get, 512 runs,  0 skips
> 148082828 decicycles in av_dict_set, 512 runs,  0 skips
> 145828939 decicycles in av_dict_get, 512 runs,  0 skips
> 
> 100 entries
>  332015 decicycles in av_map_add, 

[FFmpeg-devel] [PATCH 2/9] fftools/textformat: Quality improvements

[softworkz]

From: softworkz 

Signed-off-by: softworkz 
---
 fftools/textformat/avtextformat.c | 121 +++---
 fftools/textformat/avtextformat.h |   6 +-
 fftools/textformat/tf_default.c   |   8 +-
 fftools/textformat/tf_ini.c   |   2 +-
 fftools/textformat/tf_json.c  |   8 +-
 fftools/textformat/tf_xml.c   |   3 -
 fftools/textformat/tw_avio.c  |   9 ++-
 7 files changed, 101 insertions(+), 56 deletions(-)

diff --git a/fftools/textformat/avtextformat.c 
b/fftools/textformat/avtextformat.c
index 1ce51d11e2..406025d19d 100644
--- a/fftools/textformat/avtextformat.c
+++ b/fftools/textformat/avtextformat.c
@@ -93,9 +93,8 @@ static const AVClass textcontext_class = {
 
 static void bprint_bytes(AVBPrint *bp, const uint8_t *ubuf, size_t ubuf_size)
 {
-int i;
 av_bprintf(bp, "0X");
-for (i = 0; i < ubuf_size; i++)
+for (unsigned i = 0; i < ubuf_size; i++)
 av_bprintf(bp, "%02X", ubuf[i]);
 }
 
@@ -110,8 +109,6 @@ int avtext_context_close(AVTextFormatContext **ptctx)
 
 av_hash_freep(&tctx->hash);
 
-av_hash_freep(&tctx->hash);
-
 if (tctx->formatter->uninit)
 tctx->formatter->uninit(tctx);
 for (i = 0; i < SECTION_MAX_NB_LEVELS; i++)
@@ -141,12 +138,18 @@ int avtext_context_open(AVTextFormatContext  **ptctx,
 AVTextFormatContext *tctx;
 int i, ret = 0;
 
-if (!(tctx = av_mallocz(sizeof(AVTextFormatContext {
+if (!ptctx || !formatter)
+return AVERROR(EINVAL);
+
+if (!formatter->priv_size && formatter->priv_class)
+return AVERROR(EINVAL);
+
+if (!((tctx = av_mallocz(sizeof(AVTextFormatContext) {
 ret = AVERROR(ENOMEM);
 goto fail;
 }
 
-if (!(tctx->priv = av_mallocz(formatter->priv_size))) {
+if (formatter->priv_size && !((tctx->priv = 
av_mallocz(formatter->priv_size {
 ret = AVERROR(ENOMEM);
 goto fail;
 }
@@ -215,15 +218,15 @@ int avtext_context_open(AVTextFormatContext  **ptctx,
 
 /* validate replace string */
 {
-const uint8_t *p = tctx->string_validation_replacement;
-const uint8_t *endp = p + strlen(p);
+const uint8_t *p = (uint8_t *)tctx->string_validation_replacement;
+const uint8_t *endp = p + strlen((const char *)p);
 while (*p) {
 const uint8_t *p0 = p;
 int32_t code;
 ret = av_utf8_decode(&code, &p, endp, 
tctx->string_validation_utf8_flags);
 if (ret < 0) {
 AVBPrint bp;
-av_bprint_init(&bp, 0, AV_BPRINT_SIZE_AUTOMATIC);
+av_bprint_init(&bp, 0, AV_BPRINT_SIZE_UNLIMITED);
 bprint_bytes(&bp, p0, p - p0),
 av_log(tctx, AV_LOG_ERROR,
"Invalid UTF8 sequence %s found in string 
validation replace '%s'\n",
@@ -259,6 +262,9 @@ static const char unit_bit_per_second_str[] = "bit/s";
 
 void avtext_print_section_header(AVTextFormatContext *tctx, const void *data, 
int section_id)
 {
+if (!tctx || section_id < 0 || section_id >= tctx->nb_sections)
+return;
+
 tctx->level++;
 av_assert0(tctx->level < SECTION_MAX_NB_LEVELS);
 
@@ -272,6 +278,9 @@ void avtext_print_section_header(AVTextFormatContext *tctx, 
const void *data, in
 
 void avtext_print_section_footer(AVTextFormatContext *tctx)
 {
+if (!tctx || tctx->level < 0 || tctx->level >= SECTION_MAX_NB_LEVELS)
+return;
+
 int section_id = tctx->section[tctx->level]->id;
 int parent_section_id = tctx->level
 ? tctx->section[tctx->level - 1]->id
@@ -289,7 +298,12 @@ void avtext_print_section_footer(AVTextFormatContext *tctx)
 
 void avtext_print_integer(AVTextFormatContext *tctx, const char *key, int64_t 
val)
 {
-const struct AVTextFormatSection *section = tctx->section[tctx->level];
+const AVTextFormatSection *section;
+
+if (!tctx || !key || tctx->level < 0 || tctx->level >= 
SECTION_MAX_NB_LEVELS)
+return;
+
+section = tctx->section[tctx->level];
 
 if (section->show_all_entries || av_dict_get(section->entries_to_show, 
key, NULL, 0)) {
 tctx->formatter->print_integer(tctx, key, val);
@@ -299,24 +313,28 @@ void avtext_print_integer(AVTextFormatContext *tctx, 
const char *key, int64_t va
 
 static inline int validate_string(AVTextFormatContext *tctx, char **dstp, 
const char *src)
 {
-const uint8_t *p, *endp;
+const uint8_t *p, *endp, *srcp = (const uint8_t *)src;
 AVBPrint dstbuf;
+AVBPrint bp;
 int invalid_chars_nb = 0, ret = 0;
 
+if (!tctx || !dstp || !src)
+return AVERROR(EINVAL);
+
+*dstp = NULL;
 av_bprint_init(&dstbuf, 0, AV_BPRINT_SIZE_UNLIMITED);
+av_bprint_init(&bp, 0, AV_BPRINT_SIZE_UNLIMITED);
 
-endp = src + strlen(src);
-for (p = src; *p;) {
-uint32_t code;
+endp = srcp + strlen(src);
+for (p = srcp; *p;) {
+int32_t code;
 int invalid = 0;
 const uint8_t *p0 = p;
 
 if (av_utf8_deco

[FFmpeg-devel] [PATCH] lavc/vaapi_encode_av1: Fix ref_order_hint value for second slot

[David Rosca]

We always use two slots, even when only one L0 reference is supported
by the driver. However we still need to set the correct value for the
ref_order_hint of the second slot.

Fixes bf9f921ef7 ("avcodec/hw_base_encode: restrict size of next_prev")
---
 libavcodec/vaapi_encode_av1.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/vaapi_encode_av1.c b/libavcodec/vaapi_encode_av1.c
index 1b350cd936..cf0ff53edc 100644
--- a/libavcodec/vaapi_encode_av1.c
+++ b/libavcodec/vaapi_encode_av1.c
@@ -476,6 +476,7 @@ static int 
vaapi_encode_av1_init_picture_params(AVCodecContext *avctx,
 AV1RawFrameHeader*fh = &fh_obu->obu.frame.header;
 VAEncPictureParameterBufferAV1 *vpic = vaapi_pic->codec_picture_params;
 CodedBitstreamFragment  *obu = &priv->current_obu;
+CodedBitstreamAV1Context  *cbctx = priv->cbc->priv_data;
 FFHWBaseEncodePicture *ref;
 VAAPIEncodeAV1Picture *href;
 int slot, i;
@@ -523,6 +524,8 @@ static int 
vaapi_encode_av1_init_picture_params(AVCodecContext *avctx,
 fh->ref_frame_idx[3] = href->slot;
 fh->ref_order_hint[href->slot] = ref->display_order - 
href->last_idr_frame;
 vpic->ref_frame_ctrl_l0.fields.search_idx1 = AV1_REF_FRAME_GOLDEN;
+} else {
+fh->ref_order_hint[!href->slot] = 
cbctx->ref[!href->slot].order_hint;
 }
 break;
 case FF_HW_PICTURE_TYPE_B:
-- 
2.49.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 01/12] fftools/textformat/avtextformat: Simplify avtext_print_rational()

[Andreas Rheinhardt]

Patches attached.

- Andreas
From e54f813ea94fad0081f79aad8c35daa858300176 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt 
Date: Mon, 14 Apr 2025 22:13:19 +0200
Subject: [PATCH 01/12] fftools/textformat/avtextformat: Simplify
 avtext_print_rational()

Use snprintf() directly instead of initializing an AVBPrint
just for this.

Signed-off-by: Andreas Rheinhardt 
---
 fftools/textformat/avtextformat.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/fftools/textformat/avtextformat.c b/fftools/textformat/avtextformat.c
index 6c09f9d2cd..c1b5eefab4 100644
--- a/fftools/textformat/avtextformat.c
+++ b/fftools/textformat/avtextformat.c
@@ -460,10 +460,9 @@ int avtext_print_string(AVTextFormatContext *tctx, const char *key, const char *
 void avtext_print_rational(AVTextFormatContext *tctx,
  const char *key, AVRational q, char sep)
 {
-AVBPrint buf;
-av_bprint_init(&buf, 0, AV_BPRINT_SIZE_AUTOMATIC);
-av_bprintf(&buf, "%d%c%d", q.num, sep, q.den);
-avtext_print_string(tctx, key, buf.str, 0);
+char buf[44];
+snprintf(buf, sizeof(buf), "%d%c%d", q.num, sep, q.den);
+avtext_print_string(tctx, key, buf, 0);
 }
 
 void avtext_print_time(AVTextFormatContext *tctx, const char *key,
-- 
2.45.2

From d1464f9bbe1088b70493311b05ac159f7e516d51 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt 
Date: Tue, 15 Apr 2025 00:38:44 +0200
Subject: [PATCH 02/12] fftools/textformat: Use "", not <> for lavu headers

Also remove unused headers.

Signed-off-by: Andreas Rheinhardt 
---
 fftools/textformat/tf_compact.c | 9 +++--
 fftools/textformat/tf_default.c | 6 ++
 fftools/textformat/tf_flat.c| 9 +++--
 fftools/textformat/tf_ini.c | 7 +++
 fftools/textformat/tf_json.c| 6 ++
 fftools/textformat/tf_xml.c | 9 +++--
 6 files changed, 16 insertions(+), 30 deletions(-)

diff --git a/fftools/textformat/tf_compact.c b/fftools/textformat/tf_compact.c
index 825b67bc6e..31bfc81513 100644
--- a/fftools/textformat/tf_compact.c
+++ b/fftools/textformat/tf_compact.c
@@ -25,12 +25,9 @@
 #include 
 
 #include "avtextformat.h"
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include "libavutil/bprint.h"
+#include "libavutil/error.h"
+#include "libavutil/opt.h"
 
 
 #define writer_w8(wctx_, b_) (wctx_)->writer->writer->writer_w8((wctx_)->writer, b_)
diff --git a/fftools/textformat/tf_default.c b/fftools/textformat/tf_default.c
index 23575024c1..86582829e4 100644
--- a/fftools/textformat/tf_default.c
+++ b/fftools/textformat/tf_default.c
@@ -25,10 +25,8 @@
 #include 
 
 #include "avtextformat.h"
-#include 
-#include 
-#include 
-#include 
+#include "libavutil/bprint.h"
+#include "libavutil/opt.h"
 
 #define writer_w8(wctx_, b_) (wctx_)->writer->writer->writer_w8((wctx_)->writer, b_)
 #define writer_put_str(wctx_, str_) (wctx_)->writer->writer->writer_put_str((wctx_)->writer, str_)
diff --git a/fftools/textformat/tf_flat.c b/fftools/textformat/tf_flat.c
index 6971593c77..919d44bc6b 100644
--- a/fftools/textformat/tf_flat.c
+++ b/fftools/textformat/tf_flat.c
@@ -25,12 +25,9 @@
 #include 
 
 #include "avtextformat.h"
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include "libavutil/bprint.h"
+#include "libavutil/error.h"
+#include "libavutil/opt.h"
 
 #define writer_w8(wctx_, b_) (wctx_)->writer->writer->writer_w8((wctx_)->writer, b_)
 #define writer_put_str(wctx_, str_) (wctx_)->writer->writer->writer_put_str((wctx_)->writer, str_)
diff --git a/fftools/textformat/tf_ini.c b/fftools/textformat/tf_ini.c
index 1f4216069f..d8099ff92e 100644
--- a/fftools/textformat/tf_ini.c
+++ b/fftools/textformat/tf_ini.c
@@ -25,10 +25,9 @@
 #include 
 
 #include "avtextformat.h"
-#include 
-#include 
-#include 
-#include 
+
+#include "libavutil/bprint.h"
+#include "libavutil/opt.h"
 
 #define writer_w8(wctx_, b_) (wctx_)->writer->writer->writer_w8((wctx_)->writer, b_)
 #define writer_put_str(wctx_, str_) (wctx_)->writer->writer->writer_put_str((wctx_)->writer, str_)
diff --git a/fftools/textformat/tf_json.c b/fftools/textformat/tf_json.c
index de27a36e7e..c26a912435 100644
--- a/fftools/textformat/tf_json.c
+++ b/fftools/textformat/tf_json.c
@@ -25,10 +25,8 @@
 #include 
 
 #include "avtextformat.h"
-#include 
-#include 
-#include 
-#include 
+#include "libavutil/bprint.h"
+#include "libavutil/opt.h"
 
 #define writer_w8(wctx_, b_) (wctx_)->writer->writer->writer_w8((wctx_)->writer, b_)
 #define writer_put_str(wctx_, str_) (wctx_)->writer->writer->writer_put_str((wctx_)->writer, str_)
diff --git a/fftools/textformat/tf_xml.c b/fftools/textformat/tf_xml.c
index 57171c4cb3..6c89d01e9d 100644
--- a/fftools/textformat/tf_xml.c
+++ b/fftools/textformat/tf_xml.c
@@ -25,12 +25,9 @@
 #include 
 
 #include "avtextformat.h"
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include "libavutil/bprint.h"
+#include "libavutil/error.h"
+#include "libavutil/opt.h"
 
 #define writer_w8(wctx_, b_) (wc

Re: [FFmpeg-devel] [PATCH v2] lavc: add an av1_vulkan encoder

[Andreas Rheinhardt]

Lynne:
> This commit adds a Vulkan AV1 encoder, using the native acceleration API.
> ---
>  configure  |1 +
>  libavcodec/Makefile|2 +
>  libavcodec/allcodecs.c |1 +
>  libavcodec/vulkan_encode_av1.c | 1385 
>  libavcodec/vulkan_video.c  |  103 +++
>  libavcodec/vulkan_video.h  |7 +
>  libavutil/hwcontext_vulkan.c   |2 +
>  libavutil/vulkan_functions.h   |1 +
>  libavutil/vulkan_loader.h  |1 +
>  9 files changed, 1503 insertions(+)
>  create mode 100644 libavcodec/vulkan_encode_av1.c
> 
> diff --git a/configure b/configure
> index bd4f872376..d5293ed652 100755
> --- a/configure
> +++ b/configure
> @@ -3380,6 +3380,7 @@ av1_qsv_encoder_deps="libvpl"
>  av1_qsv_encoder_select="qsvenc"
>  av1_vaapi_encoder_deps="VAEncPictureParameterBufferAV1"
>  av1_vaapi_encoder_select="cbs_av1 vaapi_encode"
> +av1_vulkan_encoder_select="cbs_av1 vulkan_encode"
>  h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m"
>  h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m"
>  h264_amf_encoder_deps="amf"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 7bd1dbec9a..b15b99d6c2 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -270,6 +270,8 @@ OBJS-$(CONFIG_AV1_MEDIACODEC_ENCODER)  += mediacodecenc.o
>  OBJS-$(CONFIG_AV1_NVENC_ENCODER)   += nvenc_av1.o nvenc.o
>  OBJS-$(CONFIG_AV1_QSV_ENCODER) += qsvenc_av1.o
>  OBJS-$(CONFIG_AV1_VAAPI_ENCODER)   += vaapi_encode_av1.o av1_levels.o
> +OBJS-$(CONFIG_AV1_VULKAN_ENCODER)  += vulkan_encode.o 
> vulkan_encode_av1.o \
> +  hw_base_encode.o av1_levels.o
>  OBJS-$(CONFIG_AVRN_DECODER)+= avrndec.o
>  OBJS-$(CONFIG_AVRP_DECODER)+= r210dec.o
>  OBJS-$(CONFIG_AVRP_ENCODER)+= r210enc.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index f10519617e..733f1aa009 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -849,6 +849,7 @@ extern const FFCodec ff_av1_amf_encoder;
>  extern const FFCodec ff_av1_amf_decoder;
>  extern const FFCodec ff_av1_mf_encoder;
>  extern const FFCodec ff_av1_vaapi_encoder;
> +extern const FFCodec ff_av1_vulkan_encoder;
>  extern const FFCodec ff_libopenh264_encoder;
>  extern const FFCodec ff_libopenh264_decoder;
>  extern const FFCodec ff_h264_amf_encoder;
> diff --git a/libavcodec/vulkan_encode_av1.c b/libavcodec/vulkan_encode_av1.c
> new file mode 100644
> index 00..596586e7e2
> --- /dev/null
> +++ b/libavcodec/vulkan_encode_av1.c
> @@ -0,0 +1,1385 @@
> +/*
> + * 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/opt.h"
> +#include "libavutil/mem.h"
> +
> +#include "cbs.h"
> +#include "cbs_av1.h"
> +#include "av1_levels.h"
> +#include "libavutil/mastering_display_metadata.h"
> +
> +#include "codec_internal.h"
> +#include "vulkan_encode.h"
> +
> +#include "libavutil/avassert.h"
> +
> +const FFVulkanEncodeDescriptor ff_vk_enc_av1_desc = {
> +.codec_id = AV_CODEC_ID_AV1,
> +.encode_extension = FF_VK_EXT_VIDEO_ENCODE_AV1,
> +.encode_op= VK_VIDEO_CODEC_OPERATION_ENCODE_AV1_BIT_KHR,
> +.ext_props = {
> +.extensionName = VK_STD_VULKAN_VIDEO_CODEC_AV1_ENCODE_EXTENSION_NAME,
> +.specVersion   = VK_STD_VULKAN_VIDEO_CODEC_AV1_ENCODE_SPEC_VERSION,
> +},
> +};
> +
> +enum UnitElems {
> +UNIT_MASTERING_DISPLAY   = 1 << 0,
> +UNIT_CONTENT_LIGHT_LEVEL = 1 << 1,
> +};
> +
> +typedef struct VulkanEncodeAV1Picture {
> +int slot;
> +int64_t last_idr_frame;
> +
> +enum UnitElems units_needed;
> +
> +StdVideoAV1TileInfo tile_info;
> +StdVideoAV1Quantization quantization;
> +StdVideoAV1Segmentation segmentation;
> +StdVideoAV1LoopFilter loop_filter;
> +StdVideoAV1CDEF cdef;
> +StdVideoAV1LoopRestoration loop_restoration;
> +StdVideoAV1GlobalMotion global_motion;
> +
> +StdVideoEncodeAV1PictureInfo av1pic_info;
> +VkVideoEncodeAV1PictureInfoKHR vkav1pic_info;
> +
> +StdVideoEncodeAV1ExtensionHeader ext_header;
> +StdVideoEncodeAV1ReferenceInfo av1dpb_info;
> +VkVideoEncodeAV1DpbSlotInfoKHR vkav1dpb_info;
> +
> +VkVideoEnc

[FFmpeg-devel] [PATCH 5/9] fftools/ffmpeg_filter: Move some declaration to new header file

[softworkz]

From: softworkz 

to allow filtergraph printing to access the information.

Signed-off-by: softworkz 
---
 fftools/ffmpeg_filter.c | 190 +---
 fftools/ffmpeg_filter.h | 234 
 2 files changed, 235 insertions(+), 189 deletions(-)
 create mode 100644 fftools/ffmpeg_filter.h

diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index d314aec206..eab9487f97 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -21,6 +21,7 @@
 #include 
 
 #include "ffmpeg.h"
+#include "ffmpeg_filter.h"
 
 #include "libavfilter/avfilter.h"
 #include "libavfilter/buffersink.h"
@@ -42,44 +43,6 @@
 // FIXME private header, used for mid_pred()
 #include "libavcodec/mathops.h"
 
-typedef struct FilterGraphPriv {
-FilterGraph  fg;
-
-// name used for logging
-char log_name[32];
-
-int  is_simple;
-// true when the filtergraph contains only meta filters
-// that do not modify the frame data
-int  is_meta;
-// source filters are present in the graph
-int  have_sources;
-int  disable_conversions;
-
-unsigned nb_outputs_done;
-
-const char  *graph_desc;
-
-int  nb_threads;
-
-// frame for temporarily holding output from the filtergraph
-AVFrame *frame;
-// frame for sending output to the encoder
-AVFrame *frame_enc;
-
-Scheduler   *sch;
-unsigned sch_idx;
-} FilterGraphPriv;
-
-static FilterGraphPriv *fgp_from_fg(FilterGraph *fg)
-{
-return (FilterGraphPriv*)fg;
-}
-
-static const FilterGraphPriv *cfgp_from_cfg(const FilterGraph *fg)
-{
-return (const FilterGraphPriv*)fg;
-}
 
 // data that is local to the filter thread and not visible outside of it
 typedef struct FilterGraphThread {
@@ -102,157 +65,6 @@ typedef struct FilterGraphThread {
 uint8_t *eof_out;
 } FilterGraphThread;
 
-typedef struct InputFilterPriv {
-InputFilter ifilter;
-
-InputFilterOptions  opts;
-
-int index;
-
-AVFilterContext*filter;
-
-// used to hold submitted input
-AVFrame*frame;
-
-/* for filters that are not yet bound to an input stream,
- * this stores the input linklabel, if any */
-uint8_t*linklabel;
-
-// filter data type
-enum AVMediaTypetype;
-// source data type: AVMEDIA_TYPE_SUBTITLE for sub2video,
-// same as type otherwise
-enum AVMediaTypetype_src;
-
-int eof;
-int bound;
-int drop_warned;
-uint64_tnb_dropped;
-
-// parameters configured for this input
-int format;
-
-int width, height;
-AVRational  sample_aspect_ratio;
-enum AVColorSpace   color_space;
-enum AVColorRange   color_range;
-
-int sample_rate;
-AVChannelLayout ch_layout;
-
-AVRational  time_base;
-
-AVFrameSideData   **side_data;
-int nb_side_data;
-
-AVFifo *frame_queue;
-
-AVBufferRef*hw_frames_ctx;
-
-int displaymatrix_present;
-int displaymatrix_applied;
-int32_t displaymatrix[9];
-
-int downmixinfo_present;
-AVDownmixInfo   downmixinfo;
-
-struct {
-AVFrame *frame;
-
-int64_t last_pts;
-int64_t end_pts;
-
-/// marks if sub2video_update should force an initialization
-unsigned int initialize;
-} sub2video;
-} InputFilterPriv;
-
-static InputFilterPriv *ifp_from_ifilter(InputFilter *ifilter)
-{
-return (InputFilterPriv*)ifilter;
-}
-
-typedef struct FPSConvContext {
-AVFrame  *last_frame;
-/* number of frames emitted by the video-encoding sync code */
-int64_t   frame_number;
-/* history of nb_frames_prev, i.e. the number of times the
- * previous frame was duplicated by vsync code in recent
- * do_video_out() calls */
-int64_t   frames_prev_hist[3];
-
-uint64_t  dup_warning;
-
-int   last_dropped;
-int   dropped_keyframe;
-
-enum VideoSyncMethod vsync_method;
-
-AVRationalframerate;
-AVRationalframerate_max;
-const AVRational *framerate_supported;
-int   framerate_clip;
-} FPSConvContext;
-
-typedef struct OutputFilterPriv {
-OutputFilterofilter;
-
-int index;
-
-void   *log_parent;
-charlog_name[32];
-
-char   *name;
-
-AVFilterContext*filter;
-
-/* desired output stream properties */
-int format;
-int width, height;
-int sample_rate;
-AVChannelLayout ch_layout;
-   

[FFmpeg-devel] [PATCH v2 1/6] avutil/tree: av_tree_find2() to also find the first and last elements comparing equal

[Michael Niedermayer]

This patch also improves the worst case of O(n) (with n equal elements) to 
O(log n)

This may be used by AVDictionary2 And AVSet for iterating over identical
keys

Signed-off-by: Michael Niedermayer 
---
 libavutil/tree.c | 34 +-
 libavutil/tree.h |  6 ++
 2 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/libavutil/tree.c b/libavutil/tree.c
index 7b57b2d39a7..9f58a3f3d49 100644
--- a/libavutil/tree.c
+++ b/libavutil/tree.c
@@ -18,6 +18,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "avassert.h"
 #include "error.h"
 #include "log.h"
 #include "mem.h"
@@ -36,19 +37,36 @@ struct AVTreeNode *av_tree_node_alloc(void)
 return av_mallocz(sizeof(struct AVTreeNode));
 }
 
-void *av_tree_find(const AVTreeNode *t, void *key,
-   int (*cmp)(const void *key, const void *b), void *next[2])
+static void tree_find_next(const AVTreeNode *t, const void *key,
+   int (*cmp)(const void *key, const void *b), void *next[4], 
int nextlen, int direction)
+{
+if (t) {
+unsigned int v = cmp(key, t->elem);
+if (v) {
+next[direction] = t->elem;
+av_assert2((v >> 31) == direction);
+tree_find_next(t->child[!direction], key, cmp, next, nextlen, 
direction);
+} else {
+if (nextlen >= 4)
+next[2+direction] = t->elem;
+tree_find_next(t->child[direction], key, cmp, next, nextlen, 
direction);
+}
+}
+}
+
+void *av_tree_find2(const AVTreeNode *t, const void *key,
+int (*cmp)(const void *key, const void *b), void *next[4], 
int nextlen)
 {
 if (t) {
 unsigned int v = cmp(key, t->elem);
 if (v) {
 if (next)
 next[v >> 31] = t->elem;
-return av_tree_find(t->child[(v >> 31) ^ 1], key, cmp, next);
+return av_tree_find2(t->child[(v >> 31) ^ 1], key, cmp, next, 
nextlen);
 } else {
 if (next) {
-av_tree_find(t->child[0], key, cmp, next);
-av_tree_find(t->child[1], key, cmp, next);
+tree_find_next(t->child[0], key, cmp, next, nextlen, 0);
+tree_find_next(t->child[1], key, cmp, next, nextlen, 1);
 }
 return t->elem;
 }
@@ -56,6 +74,12 @@ void *av_tree_find(const AVTreeNode *t, void *key,
 return NULL;
 }
 
+void *av_tree_find(const AVTreeNode *t, void *key,
+   int (*cmp)(const void *key, const void *b), void *next[2])
+{
+return av_tree_find2(t, key, cmp, next, 2);
+}
+
 void *av_tree_insert(AVTreeNode **tp, void *key,
  int (*cmp)(const void *key, const void *b), AVTreeNode 
**next)
 {
diff --git a/libavutil/tree.h b/libavutil/tree.h
index bbb8fbb1262..6bafd47e593 100644
--- a/libavutil/tree.h
+++ b/libavutil/tree.h
@@ -55,6 +55,9 @@ struct AVTreeNode *av_tree_node_alloc(void);
  * @param next If next is not NULL, then next[0] will contain the previous
  * element and next[1] the next element. If either does not exist,
  * then the corresponding entry in next is unchanged.
+ * if nextlen is 4 then next[2] will contain the first element 
comparing
+ * equal that is smaller than the returned. Similarly next[3] will
+ * contain the last element comparing equal that is larger than 
the returned
  * @param cmp compare function used to compare elements in the tree,
  *API identical to that of Standard C's qsort
  *It is guaranteed that the first and only the first argument to 
cmp()
@@ -63,6 +66,9 @@ struct AVTreeNode *av_tree_node_alloc(void);
  * @return An element with cmp(key, elem) == 0 or NULL if no such element
  * exists in the tree.
  */
+void *av_tree_find2(const struct AVTreeNode *root, const void *key,
+   int (*cmp)(const void *key, const void *b), void *next[4], 
int nextlen);
+
 void *av_tree_find(const struct AVTreeNode *root, void *key,
int (*cmp)(const void *key, const void *b), void *next[2]);
 
-- 
2.49.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 5/6] libavutil: Add AVMap

[Michael Niedermayer]

AVL Tree based Map

compared to AVDictionary this has
 * clone is O(n) instead of O(n²)
 * copy is O(n*log n) instead of O(n²)
 * O(log n) malloc() calls by default and O(1) if av_map_realloc() is used 
instead of O(n)
 * get/add/delete is O(log n)
 *
 * You can add (if memory is realloced before) and remove entries while a 
iterator stays valid
 * copy is atomic, a failure means the dst is unchanged
 *
 * there are restrictions on what compare function can be used on get depending 
on how the Map was created
 * you can mix case sensitive and case insensitive compare with 
av_map_supercmp_*
 * Supports binary objects, not just strings

Still somewhat work in progress, help more welcome than complaints ;)

Signed-off-by: Michael Niedermayer 
---
 libavutil/Makefile|   3 +
 libavutil/map.c   | 359 ++
 libavutil/map.h   | 230 
 libavutil/tests/map.c | 190 
 libavutil/tree.c  |   6 +-
 libavutil/tree_internal.h |  28 +++
 tests/fate/libavutil.mak  |   4 +
 tests/ref/fate/map|  27 +++
 8 files changed, 842 insertions(+), 5 deletions(-)
 create mode 100644 libavutil/map.c
 create mode 100644 libavutil/map.h
 create mode 100644 libavutil/tests/map.c
 create mode 100644 libavutil/tree_internal.h
 create mode 100644 tests/ref/fate/map

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 9ef118016bb..3a92748a482 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -81,6 +81,7 @@ HEADERS = adler32.h   
  \
   replaygain.h  \
   ripemd.h  \
   samplefmt.h   \
+  map.h \
   sha.h \
   sha512.h  \
   spherical.h   \
@@ -173,6 +174,7 @@ OBJS = adler32.o
\
rc4.o\
ripemd.o \
samplefmt.o  \
+   map.o\
side_data.o  \
sha.o\
sha512.o \
@@ -290,6 +292,7 @@ TESTPROGS = adler32 
\
 random_seed \
 rational\
 ripemd  \
+map \
 sha \
 sha512  \
 side_data_array \
diff --git a/libavutil/map.c b/libavutil/map.c
new file mode 100644
index 000..00dd5a1bd39
--- /dev/null
+++ b/libavutil/map.c
@@ -0,0 +1,359 @@
+/*
+ * Copyright (c) 2025 Michael Niedermayer
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include 
+
+#include "avassert.h"
+#include "avstring.h"
+#include "error.h"
+#include "mem.h"
+#include "map.h"
+
+#include "tree_internal.h" // For improved readability with AVTreeNode, do NOT 
touch AVTreeNode internals
+
+typedef struct{
+AVMapEntry map_entry;
+uint8_t treenode_and_keyvalue[0];
+} AVMapInternalEntry;
+
+struct AVMap{
+AVMapCompareFunc cmp_keyvalue;
+AVMapCopyFunc copy;
+AVMapFreeFunc freef;
+int count;
+int deleted;
+int next;   ///< index of entry in root array after all 
used entries
+unsigned internal_entries_len;
+AVTreeNode *tree_root;
+AVMap

[FFmpeg-devel] [PATCH v2 4/6] avutil/tree: Make tree_find_next() non recursive

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavutil/tree.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavutil/tree.c b/libavutil/tree.c
index a4c090e6d04..09c55f6752d 100644
--- a/libavutil/tree.c
+++ b/libavutil/tree.c
@@ -40,16 +40,16 @@ struct AVTreeNode *av_tree_node_alloc(void)
 static void tree_find_next(const AVTreeNode *t, const void *key,
int (*cmp)(const void *key, const void *b), void *next[4], 
int nextlen, int direction)
 {
-if (t) {
+while (t) {
 unsigned int v = cmp(key, t->elem);
 if (v) {
 next[direction] = t->elem;
 av_assert2((v >> 31) == direction);
-tree_find_next(t->child[!direction], key, cmp, next, nextlen, 
direction);
+t = t->child[!direction];
 } else {
 if (nextlen >= 4)
 next[2+direction] = t->elem;
-tree_find_next(t->child[direction], key, cmp, next, nextlen, 
direction);
+t = t->child[direction];
 }
 }
 }
-- 
2.49.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 3/6] avutil/tree: Make av_tree_find2() non recursive

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavutil/tree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/tree.c b/libavutil/tree.c
index 455a447bf11..a4c090e6d04 100644
--- a/libavutil/tree.c
+++ b/libavutil/tree.c
@@ -57,12 +57,12 @@ static void tree_find_next(const AVTreeNode *t, const void 
*key,
 void *av_tree_find2(const AVTreeNode *t, const void *key,
 int (*cmp)(const void *key, const void *b), void *next[4], 
int nextlen)
 {
-if (t) {
+while(t) {
 unsigned int v = cmp(key, t->elem);
 if (v) {
 if (next)
 next[v >> 31] = t->elem;
-return av_tree_find2(t->child[(v >> 31) ^ 1], key, cmp, next, 
nextlen);
+t = t->child[(v >> 31) ^ 1];
 } else {
 if (next) {
 tree_find_next(t->child[0], key, cmp, next, nextlen, 0);
-- 
2.49.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 2/6] avutil/tree: Add av_tree_move

[Michael Niedermayer]

This will allow storing a tree in a flat array and reallocating it

Signed-off-by: Michael Niedermayer 
---
 libavutil/tree.c | 15 +++
 libavutil/tree.h | 11 +++
 2 files changed, 26 insertions(+)

diff --git a/libavutil/tree.c b/libavutil/tree.c
index 9f58a3f3d49..455a447bf11 100644
--- a/libavutil/tree.c
+++ b/libavutil/tree.c
@@ -190,3 +190,18 @@ void av_tree_enumerate(AVTreeNode *t, void *opaque,
 av_tree_enumerate(t->child[1], opaque, cmp, enu);
 }
 }
+
+void av_tree_move(struct AVTreeNode *t, struct AVTreeNode *old, void *elem, 
void *old_elem)
+{
+if (t->child[0]) {
+av_tree_move(t->child[0] - old + t, t->child[0], elem, old_elem);
+t->child[0] = t->child[0] - old + t;
+}
+if (t->child[1]) {
+av_tree_move(t->child[1] - old + t, t->child[1], elem, old_elem);
+t->child[1] = t->child[1] - old + t;
+}
+
+if (t->elem && elem != old_elem)
+t->elem = (uint8_t*)t->elem - (uint8_t*)old_elem + (uint8_t*)elem;
+}
diff --git a/libavutil/tree.h b/libavutil/tree.h
index 6bafd47e593..10895e39578 100644
--- a/libavutil/tree.h
+++ b/libavutil/tree.h
@@ -136,6 +136,17 @@ void av_tree_enumerate(struct AVTreeNode *t, void *opaque,
int (*cmp)(void *opaque, void *elem),
int (*enu)(void *opaque, void *elem));
 
+/**
+ * Updates the tree in case the tree has been moved.
+ * This is needed for example when all tree nodes are in an array that is 
reallocated
+ *
+ * @param root the root of the tree to update
+ * @param old  the old root on which internal pointers are still based
+ * @param elem the array that contains all elements after the move
+ * @param old  the old element array
+ */
+void av_tree_move(struct AVTreeNode *root, struct AVTreeNode *old, void *elem, 
void *old_elem);
+
 /**
  * @}
  */
-- 
2.49.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 6/6] [NOT for git] avutil/tests/map: benchmark code

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavutil/tests/map.c | 56 +++
 1 file changed, 56 insertions(+)

diff --git a/libavutil/tests/map.c b/libavutil/tests/map.c
index 38f0a153e68..72bfafdb4f4 100644
--- a/libavutil/tests/map.c
+++ b/libavutil/tests/map.c
@@ -26,6 +26,8 @@
 #include "libavutil/mem.h"
 #include "libavutil/map.h"
 
+#include "libavutil/timer.h"
+#include "libavutil/dict.h"
 
 static void print_set(const AVMap *s)
 {
@@ -37,6 +39,7 @@ static void print_set(const AVMap *s)
 
 int main(void)
 {
+#if 0
 void *our_cmp[] = {
 strcmp,
 av_map_strcmp_keyvalue,
@@ -185,6 +188,59 @@ int main(void)
 av_map_free(&set);
 av_assert0(!set);
 }
+#else
+#define N_ENTRIES 1000
+#define P 4
+for (int runs = 0; runs < 1000; runs++) {
+AVMap *map = av_map_new(strcmp, NULL, NULL);
+for(int pass = 0; pass < 2; pass++) {
+START_TIMER
+unsigned r = 5;
+for(int i=0; i>8;
+if(pass == 0) {
+av_map_add(map, str, 7, str, 7, 0);
+} else {
+av_map_get(map, str, strcmp);
+}
+}
+if (pass) {
+STOP_TIMER("av_map_get")
+} else {
+STOP_TIMER("av_map_add")
+}
+}
+av_map_free(&map);
+}
+
+for (int runs = 0; runs < 1000; runs++) {
+AVDictionary *dict = NULL;
+for(int pass = 0; pass < 2; pass++) {
+START_TIMER
+unsigned r = 5;
+for(int i=0; i>8;
+if(pass == 0) {
+av_dict_set(&dict, str, str, 0);
+} else {
+av_dict_get(dict, str, NULL, 0);
+}
+}
+if (pass) {
+STOP_TIMER("av_dict_get")
+} else {
+STOP_TIMER("av_dict_set")
+}
+}
+av_dict_free(&dict);
+}
+#endif
 
 return 0;
 }
-- 
2.49.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] libavcodec/riscv:add RVV optimized for idct_32x32_8:

[daichengrong]

From: daichengrong 

 riscv/hevcdsp_idct_rvv: Optimize idct_32x32_8

 On Banana PI F3:

 hevc_idct_32x32_8_c:119579.3 ( 1.00x)
 hevc_idct_32x32_8_rvv_i64:   51254.4 ( 2.33x)

Signed-off-by: daichengrong 
---
 libavcodec/riscv/Makefile   |1 +
 libavcodec/riscv/hevcdsp_idct_rvv.S | 1042 +++
 libavcodec/riscv/hevcdsp_init.c |   52 +-
 3 files changed, 1075 insertions(+), 20 deletions(-)
 create mode 100644 libavcodec/riscv/hevcdsp_idct_rvv.S

diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index a80d2fa2e7..dfc33afbee 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -36,6 +36,7 @@ RVV-OBJS-$(CONFIG_H264DSP) += riscv/h264addpx_rvv.o 
riscv/h264dsp_rvv.o \
 OBJS-$(CONFIG_H264QPEL) += riscv/h264qpel_init.o
 RVV-OBJS-$(CONFIG_H264QPEL) += riscv/h264qpel_rvv.o
 OBJS-$(CONFIG_HEVC_DECODER) += riscv/hevcdsp_init.o
+OBJS-$(CONFIG_HEVC_DECODER) += riscv/hevcdsp_idct_rvv.o
 RVV-OBJS-$(CONFIG_HEVC_DECODER)  += riscv/h26x/h2656_inter_rvv.o
 OBJS-$(CONFIG_HUFFYUV_DECODER) += riscv/huffyuvdsp_init.o
 RVV-OBJS-$(CONFIG_HUFFYUV_DECODER) += riscv/huffyuvdsp_rvv.o
diff --git a/libavcodec/riscv/hevcdsp_idct_rvv.S 
b/libavcodec/riscv/hevcdsp_idct_rvv.S
new file mode 100644
index 00..f8dd2e5bf4
--- /dev/null
+++ b/libavcodec/riscv/hevcdsp_idct_rvv.S
@@ -0,0 +1,1042 @@
+/*
+ * Copyright (c) 2025 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/riscv/asm.S"
+
+const trans, align=4
+.2byte  64, 83, 64, 36
+.2byte  89, 75, 50, 18
+.2byte  90, 87, 80, 70
+.2byte  57, 43, 25, 9
+.2byte  90, 90, 88, 85
+.2byte  82, 78, 73, 67
+.2byte  61, 54, 46, 38
+.2byte  31, 22, 13, 4
+endconst
+
+.macro sum_sub out, in, c, op, p
+vsetivli   t0, 4, e16, mf2, tu, ma
+  .ifc \op, +
+.ifc \p, 2  
+vslidedown.vi  v8, \in, 4
+vwmacc.vx  \out, \c, v8
+.else
+vwmacc.vx  \out, \c, \in
+.endif
+  .else
+.ifc \p, 2  
+neg\c, \c
+vslidedown.vi  v8, \in, 4
+vwmacc.vx  \out, \c, v8
+neg\c, \c
+.else
+neg\c, \c
+vwmacc.vx  \out, \c, \in
+neg\c, \c
+.endif
+  .endif
+.endm
+
+.macro add_member32 in, t0, index0, t1, index1, t2, index2, t3, index3, op0, 
op1, op2, op3, p
+vsetivli   t0, 1, e16, m1, tu, ma
+vslidedown.vi  v12, \t0, \index0
+vmv.x.ss2, v12
+vslidedown.vi  v12, \t1, \index1
+vmv.x.ss3, v12
+vslidedown.vi  v12, \t2, \index2
+vmv.x.ss4, v12
+vslidedown.vi  v12, \t3, \index3
+vmv.x.ss5, v12
+
+sum_sub v24, \in, s2, \op0, \p
+sum_sub v25, \in, s3, \op1, \p
+sum_sub v26, \in, s4, \op2, \p
+sum_sub v27, \in, s5, \op3, \p
+.endm
+
+.macro butterfly e, o, tmp_p, tmp_m
+vsetivli t0, 4, e32, m1, tu, ma
+vadd.vv \tmp_p, \e, \o
+vsub.vv \tmp_m, \e, \o
+.endm
+
+.macro butterfly16 in0, in1, in2, in3, in4, in5, in6, in7
+vsetivli t0, 4, e32, m1, tu, ma
+vadd.vv  v20, \in0, \in1
+vsub.vv  \in0, \in0, \in1
+vadd.vv  \in1, \in2, \in3
+vsub.vv  \in2, \in2, \in3
+vadd.vv  \in3, \in4, \in5
+vsub.vv  \in4, \in4, \in5
+vadd.vv  \in5, \in6, \in7
+vsub.vv  \in6, \in6, \in7
+.endm
+
+.macro multiply in
+vsetivli   t0, 1, e16, m1, tu, ma
+vmv.x.ss2, \in
+vslidedown.vi  v12, \in, 1
+vmv.x.ss3, v12
+vslidedown.vi  v12, \in, 2
+vmv.x.ss4, v12
+vslidedown.vi  v12, \in, 3
+vmv.x.ss5, v12
+
+vsetivlit0, 4, e16, mf2, tu, ma
+vwmu

[FFmpeg-devel] [PATCH v2 1/2] avformat: add avformat_query_seekable

[Gyan Doshi]

Utility function to report seekability features for a given input.

Useful for ffprobe and to extend seek possibilities in fftools.
---
v2:
   made constants more descriptive
   add exception for rtsp false negative seekability

 doc/APIchanges |  3 +++
 libavformat/avformat.h | 22 ++
 libavformat/seek.c | 53 ++
 libavformat/version.h  |  2 +-
 4 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 65bf5a9419..879f56b572 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2025-03-28
 
 API changes, most recent first:
 
+2025-04-xx - xx - lavf 62.1.100 - avformat.h
+  Add avformat_query_seekable().
+
 2025-04-07 - 19e9a203b7 - lavu 60.01.100 - dict.h
   Add AV_DICT_DEDUP.
 
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 498c3020a5..f9da5e9e79 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2338,6 +2338,28 @@ int av_seek_frame(AVFormatContext *s, int stream_index, 
int64_t timestamp,
  */
 int avformat_seek_file(AVFormatContext *s, int stream_index, int64_t min_ts, 
int64_t ts, int64_t max_ts, int flags);
 
+#define AVSEEKABLE_IO_NORMAL   0x0001 ///< I/O is seekable like a 
local file
+#define AVSEEKABLE_IO_PROTOCOL 0x0002 ///< I/O seek is through 
protocol request via avio_seek_time
+#define AVSEEKABLE_VIA_DEMUXER 0x0004 ///< demuxer has a seek function
+#define AVSEEKABLE_VIA_PKTSCAN 0x0008 ///< seek is performed by 
consuming and scanning packet timestamps
+#define AVSEEKABLE_BY_TIME 0x0100 ///< seek target can be a 
timestamp
+#define AVSEEKABLE_BY_BYTE 0x0200 ///< seek target can be in bytes
+#define AVSEEKABLE_BY_FRAME0x0400 ///< seek target can be a frame 
index
+#define AVSEEKABLE_PROP_PTS0x0001 ///< seek target timestamp is 
expected to be PTS
+#define AVSEEKABLE_PROP_FAST   0x0002 ///< demuxer allows fast but 
inaccurate seeking
+#define AVSEEKABLE_PROP_FWDONLY0x0004 ///< set seek will be equal or 
forward of specified seek point
+
+/**
+ * Report if and how a seek can be performed in a given input.
+ *
+ * @param smedia file handle
+ *
+ * @return 0 if no seek can be performed on input,
+ * -1 if the fmt ctx is NULL or is not an input
+ * else return AVSEEKABLE_ bitflags indicating seekability features.
+ */
+int avformat_query_seekable(AVFormatContext *s);
+
 /**
  * Discard all internally buffered data. This can be useful when dealing with
  * discontinuities in the byte stream. Generally works only with formats that
diff --git a/libavformat/seek.c b/libavformat/seek.c
index c0d94371e6..8be1bdec30 100644
--- a/libavformat/seek.c
+++ b/libavformat/seek.c
@@ -712,6 +712,59 @@ int avformat_seek_file(AVFormatContext *s, int 
stream_index, int64_t min_ts,
 return ret;
 }
 
+int avformat_query_seekable(AVFormatContext *s)
+{
+int ret = 0;
+
+if (!s || !s->iformat)
+return -1;
+
+if ( strcmp(s->iformat->name, "rtsp") && (!(s->pb && s->pb->seekable) || 
s->ctx_flags & AVFMTCTX_UNSEEKABLE) )
+return 0;
+
+if (s->pb->seekable & AVIO_SEEKABLE_NORMAL)
+ret |= AVSEEKABLE_IO_NORMAL;
+
+if (s->pb->seekable & AVIO_SEEKABLE_TIME)
+ret |= AVSEEKABLE_IO_PROTOCOL;
+
+if (ffifmt(s->iformat)->read_seek || ffifmt(s->iformat)->read_seek2)
+ret |= AVSEEKABLE_VIA_DEMUXER;
+
+if (ffifmt(s->iformat)->read_timestamp && !(s->iformat->flags & 
AVFMT_NOBINSEARCH))
+ret |= AVSEEKABLE_VIA_PKTSCAN;
+
+if (!(s->iformat->flags & AVFMT_NOTIMESTAMPS))
+ret |= AVSEEKABLE_BY_TIME;
+
+// TODO: incomplete, a few demuxers don't set flag but error out on byte 
seek
+if (!(s->iformat->flags & AVFMT_NO_BYTE_SEEK))
+ret |= AVSEEKABLE_BY_BYTE;
+
+// TODO: no flag for frame seeking. Add flag and enable this check
+if (s->iformat->flags & 0)
+ret |= AVSEEKABLE_BY_FRAME;
+
+if (s->iformat->flags & AVFMT_SEEK_TO_PTS)
+ret |= AVSEEKABLE_PROP_PTS;
+
+// TODO: flag exists but not added to the demuxers which support it
+if (s->iformat->flags & AVFMT_FLAG_FAST_SEEK)
+ret |= AVSEEKABLE_PROP_FAST;
+
+if (!(ret & AVSEEKABLE_VIA_DEMUXER) && ret & AVSEEKABLE_VIA_PKTSCAN)
+ret |= AVSEEKABLE_PROP_FWDONLY;
+
+if ( !(ret & AVSEEKABLE_VIA_DEMUXER) &&
+ !(ret & AVSEEKABLE_VIA_PKTSCAN) &&
+ !(ret & AVSEEKABLE_BY_BYTE) &&
+ !(ret & AVSEEKABLE_IO_PROTOCOL) &&
+ (s->iformat->flags & AVFMT_NOGENSEARCH) )
+ret = 0;
+
+return ret;
+}
+
 /** Flush the frame reader. */
 void ff_read_frame_flush(AVFormatContext *s)
 {
diff --git a/libavformat/version.h b/libavformat/version.h
index 752aac16f7..a7c80dc564 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -31,7 +31,7 @@
 
 #include "version_major.h"
 
-#de

[FFmpeg-devel] [PATCH 1/3] avcodec: add AV_CODEC_ID_BRAW

[Lynne]

This adds codec entries for the Blackmagic RAW codec.
---
 libavcodec/codec_desc.c | 7 +++
 libavcodec/codec_id.h   | 1 +
 2 files changed, 8 insertions(+)

diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 9fb190e35a..90e31a8b6a 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1985,6 +1985,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_LOSSLESS,
 .mime_types= MT("image/jxl"),
 },
+{
+.id= AV_CODEC_ID_BRAW,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "braw",
+.long_name = NULL_IF_CONFIG_SMALL("Blackmagic RAW"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
+},
 
 /* various PCM "codecs" */
 {
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 2f6efe8261..0175fc2d7b 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -329,6 +329,7 @@ enum AVCodecID {
 AV_CODEC_ID_DNXUC,
 AV_CODEC_ID_RV60,
 AV_CODEC_ID_JPEGXL_ANIM,
+AV_CODEC_ID_BRAW,
 
 /* various PCM "codecs" */
 AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the 
start of audio codecs
-- 
2.49.0.395.g12beb8f557c
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 2/3] lavf/mov: support demuxing Blackmagic RAW streams

[Lynne]

---
 libavformat/isom_tags.c | 7 +++
 libavformat/mov.c   | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavformat/isom_tags.c b/libavformat/isom_tags.c
index f05762beec..7bf2bf7d5b 100644
--- a/libavformat/isom_tags.c
+++ b/libavformat/isom_tags.c
@@ -286,6 +286,13 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
 
 { AV_CODEC_ID_RAWVIDEO, MKTAG('B', 'G', 'G', 'R') }, /* ASC Bayer BGGR */
 
+{ AV_CODEC_ID_BRAW, MKTAG('b', 'r', 'x', 'q') }, /* Blackmagic RAW */
+{ AV_CODEC_ID_BRAW, MKTAG('b', 'r', 'h', 'q') },
+{ AV_CODEC_ID_BRAW, MKTAG('b', 'r', 's', 't') },
+{ AV_CODEC_ID_BRAW, MKTAG('b', 'r', 'l', 't') },
+{ AV_CODEC_ID_BRAW, MKTAG('b', 'r', 'v', 'l') },
+{ AV_CODEC_ID_BRAW, MKTAG('b', 'r', 'v', 'm') },
+
 { AV_CODEC_ID_MEDIA100, MKTAG('6', '0', '1', 'N') },
 { AV_CODEC_ID_MEDIA100, MKTAG('6', '0', '1', 'P') },
 { AV_CODEC_ID_MEDIA100, MKTAG('d', 't', 'n', 't') },
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 452690090c..b4056fba48 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -11349,7 +11349,7 @@ const FFInputFormat ff_mov_demuxer = {
 .p.name = "mov,mp4,m4a,3gp,3g2,mj2",
 .p.long_name= NULL_IF_CONFIG_SMALL("QuickTime / MOV"),
 .p.priv_class   = &mov_class,
-.p.extensions   = 
"mov,mp4,m4a,3gp,3g2,mj2,psp,m4b,ism,ismv,isma,f4v,avif,heic,heif",
+.p.extensions   = 
"mov,mp4,m4a,3gp,3g2,mj2,psp,m4b,ism,ismv,isma,f4v,avif,heic,heif,braw",
 .p.flags= AVFMT_NO_BYTE_SEEK | AVFMT_SEEK_TO_PTS | AVFMT_SHOW_IDS,
 .priv_data_size = sizeof(MOVContext),
 .flags_internal = FF_INFMT_FLAG_INIT_CLEANUP,
-- 
2.49.0.395.g12beb8f557c
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 3/3] avcodec: add Blackmagic RAW decoder

[Lynne]

Most of the work was done by Paul B Mahol.
I cleaned the patch up, improved the code a bit, and added slice
threading.
---
 configure  |   1 +
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/braw.c  | 666 +
 4 files changed, 669 insertions(+)
 create mode 100755 libavcodec/braw.c

diff --git a/configure b/configure
index bd4f872376..1171260d57 100755
--- a/configure
+++ b/configure
@@ -2943,6 +2943,7 @@ av1_decoder_select="atsc_a53 cbs_av1 dovi_rpudec"
 bink_decoder_select="blockdsp hpeldsp"
 binkaudio_dct_decoder_select="wma_freqs"
 binkaudio_rdft_decoder_select="wma_freqs"
+braw_decoder_select="idctdsp"
 cavs_decoder_select="blockdsp golomb h264chroma idctdsp qpeldsp videodsp"
 clearvideo_decoder_select="idctdsp"
 cllc_decoder_select="bswapdsp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 7bd1dbec9a..50733ab048 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -289,6 +289,7 @@ OBJS-$(CONFIG_BMP_ENCODER) += bmpenc.o
 OBJS-$(CONFIG_BMV_AUDIO_DECODER)   += bmvaudio.o
 OBJS-$(CONFIG_BMV_VIDEO_DECODER)   += bmvvideo.o
 OBJS-$(CONFIG_BONK_DECODER)+= bonk.o
+OBJS-$(CONFIG_BRAW_DECODER)+= braw.o
 OBJS-$(CONFIG_BRENDER_PIX_DECODER) += brenderpix.o
 OBJS-$(CONFIG_C93_DECODER) += c93.o
 OBJS-$(CONFIG_CAVS_DECODER)+= cavs.o cavsdec.o cavsdsp.o \
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f10519617e..277e17acc3 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -69,6 +69,7 @@ extern const FFCodec ff_bitpacked_encoder;
 extern const FFCodec ff_bmp_encoder;
 extern const FFCodec ff_bmp_decoder;
 extern const FFCodec ff_bmv_video_decoder;
+extern const FFCodec ff_braw_decoder;
 extern const FFCodec ff_brender_pix_decoder;
 extern const FFCodec ff_c93_decoder;
 extern const FFCodec ff_cavs_decoder;
diff --git a/libavcodec/braw.c b/libavcodec/braw.c
new file mode 100755
index 00..2246b2d645
--- /dev/null
+++ b/libavcodec/braw.c
@@ -0,0 +1,666 @@
+/*
+ * Blackmagic RAW codec
+ *
+ * Copyright (c) 2019 Paul B Mahol
+ * Copyright (c) 2025 Lynne
+ *
+ * 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 
+#include 
+#include 
+
+#include "libavutil/mem_internal.h"
+
+#include "decode.h"
+#include "thread.h"
+#include "codec_internal.h"
+#include "mpegvideo.h"
+#include "bytestream.h"
+#include "get_bits.h"
+#include "vlc.h"
+#include "simple_idct.h"
+
+#define IN_IDCT_DEPTH 16
+#define PRORES_ONLY
+#define BIT_DEPTH 12
+#include "simple_idct_template.c"
+
+#define BRAW_MAX_TILES 1024
+
+typedef struct BRAWTile {
+const uint8_t *data;
+uint32_t size;
+int x;
+int y;
+int blocks_w_in_tile;
+int blocks_h_in_tile;
+int ret;
+} BRAWTile;
+
+typedef struct BRAWContext {
+const AVClass*class;
+
+enum AVPixelFormat pix_fmt;
+
+GetByteContextgb;
+
+uint32_t  header_size;
+
+int   offsets[4][2];
+
+int   nb_tiles_w;
+int   nb_tiles_h;
+int   tile_size_w[256];
+int   tile_offset_w[257];
+int   tile_size_h;
+
+int   qscale[3];
+int   quant[2][64];
+
+ScanTable scan;
+IDCTDSPContextidsp;
+
+BRAWTile  tiles[BRAW_MAX_TILES];
+AVFrame  *frame;
+} BRAWContext;
+
+static const uint16_t dc_codes[16] = {
+0x0, 0x2, 0x3, 0x4, 0x5, 0x6, 0x1C, 0x1D, 0x3E, 0xFF4, 0xFF5, 0xFF7, 
0xFED, 0x1E, 0xFFE, 0x1FFE,
+};
+static const uint8_t dc_bits[16] = {
+2, 3, 3, 3, 3, 3, 5, 5, 6, 12, 12, 12, 12, 5, 12, 13,
+};
+
+static const uint32_t ac_codes[194] = {
+0x00, 0x01, 0x04, 0x0B, 0x0C, 0x0A,
+0x1A, 0x1B, 0x1C, 0x3A, 0x3B, 0x78,
+0x79, 0x7A, 0x7B, 0xF8, 0xF9, 0xFA,
+0x0001F6, 0x0001F7, 0x0001F8, 0x0001F9, 0x0001FA, 0x0003F6,
+0x0003F7, 0x0003F8, 0x0003F9, 0x0003FA, 0x0007F8, 0x0007F9,
+0x000FED, 0x000FF4, 0x000FF5, 0x000FF7, 0x000FEC, 0x000FF6,
+0x001FDC, 0x001FDD, 0x001FDE, 0x001FDF, 0x007FC0, 0x00FF84,
+0x00FF85, 0x00FF86, 0x00FF87, 0x00FF88, 0x00FF89, 0x00FF8A,
+0x00F

Re: [FFmpeg-devel] [PATCH v2 5/6] libavutil: Add AVMap

[Nicolas George]

Michael Niedermayer (HE12025-04-15):
> or is the goal to avoid the error handling?

Both are desirable. I am sure we have in our API a few functions that
take a dictionary but are very fast; is it really worth digging around
to convince you that avoiding dynamic allocations is worth it?

> also in the specific example
> av_codec_open3(ctx, codec, NULL);
> will no longer work as NULL is a pointer and AVMap here looks like
> it would not be

My bad, I forgot &, we obviously do not pass large structures by value.

> AVMap should be public but the implementation should not be any more
> public than needed.
> That way users cannot by mistake mess with internals

We are FFmpeg, not GNOME, we are not in the business of going out of our
way and making our code less efficient for the sole benefit of
preventing API users from shooting themselves in the foot.

If you insist, there are ways of hiding most of the internals anyway.
But I do not think it is worth it.

>  and we can
> improve the internal implementation without ABI/API breakage

The trick I introduced in BPrint allows us to improve on internal
implementation without ABI/API breakage. I would not insist on it
otherwise.

Regards,

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

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

Re: [FFmpeg-devel] [PATCH v5] Mark C globals with small code model

[Pranav Kant via ffmpeg-devel]

Hello again. Is there anything else I can do here?

On Fri, Apr 4, 2025 at 11:40 AM Pranav Kant  wrote:

> Any thoughts on this?
>
> On Thu, Mar 20, 2025 at 5:30 PM Pranav Kant  wrote:
>
>> Patch version v5:
>> - Uses two new macros DECLARE_ASM_VAR (used for both external and inline
>> asm) and DECLARE_EXTERNAL_ASM_VAR (used only for external asm)
>> - I intend to remove explicit existing use of attribute_visibility_hidden
>> in follow-up patch and instead use DECLARE_EXTERNAL_ASM_VAR for those
>> variables
>> - Other variables will be marked with these two new macros in a follow-up
>> patch. I want to settle down on the infrastructure first with a handful of
>> variables.
>>
>> Let me know if you have any questions.
>>
>> On Thu, Mar 20, 2025 at 5:28 PM Pranav Kant  wrote:
>>
>>> By default, all globals in C/C++ compiled by clang are allocated
>>> in non-large data sections. See [1] for background on code models.
>>> For PIC (Position independent code), this is fine as long as binary is
>>> small but as binary size increases, users maybe want to use medium/large
>>> code models (-mcmodel=medium) which moves data in to large sections.
>>> As data in these large sections cannot be accessed using PIC code
>>> anymore (as it may be too far away), compiler ends up using a different
>>> instruction sequence when building C/C++ code -- using GOT to access
>>> these globals (which can be relaxed by linker at link time if binary
>>> ends up being smaller). However, external assembly and inline assembly
>>> continue to access these globals using older PC-relative addressing
>>> which may not work because globals may be placed too far away.
>>>
>>> Introduce new macros for such variables that mark them with small code
>>> model attribute. This ensures that these variables are never allocated
>>> in large data sections, and continue to be validly accessed from assembly
>>> code.
>>>
>>> This patch should not have any affect on builds that use small code
>>> model, which is the default mode.
>>>
>>> [1]
>>> https://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models
>>>
>>> Signed-off-by: Pranav Kant 
>>> ---
>>>  libavcodec/ac3dsp.h |  4 +++-
>>>  libavcodec/cabac.h  |  4 +++-
>>>  libavcodec/x86/constants.h  | 12 +++-
>>>  libavutil/attributes.h  |  6 ++
>>>  libavutil/attributes_internal.h | 16 
>>>  libavutil/mem_internal.h| 13 +
>>>  6 files changed, 48 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/libavcodec/ac3dsp.h b/libavcodec/ac3dsp.h
>>> index b1b2bced8f..a3c55a833b 100644
>>> --- a/libavcodec/ac3dsp.h
>>> +++ b/libavcodec/ac3dsp.h
>>> @@ -25,11 +25,13 @@
>>>  #include 
>>>  #include 
>>>
>>> +#include "libavutil/mem_internal.h"
>>> +
>>>  /**
>>>   * Number of mantissa bits written for each bap value.
>>>   * bap values with fractional bits are set to 0 and are calculated
>>> separately.
>>>   */
>>> -extern const uint16_t ff_ac3_bap_bits[16];
>>> +extern DECLARE_EXTERNAL_ASM_VAR(16, const uint16_t,
>>> ff_ac3_bap_bits)[16];
>>>
>>>  typedef struct AC3DSPContext {
>>>  /**
>>> diff --git a/libavcodec/cabac.h b/libavcodec/cabac.h
>>> index 38d06b2842..df352258c6 100644
>>> --- a/libavcodec/cabac.h
>>> +++ b/libavcodec/cabac.h
>>> @@ -29,7 +29,9 @@
>>>
>>>  #include 
>>>
>>> -extern const uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63];
>>> +#include "libavutil/mem_internal.h"
>>> +
>>> +extern DECLARE_ASM_VAR(1, const uint8_t, ff_h264_cabac_tables)[512 +
>>> 4*2*64 + 4*64 + 63];
>>>  #define H264_NORM_SHIFT_OFFSET 0
>>>  #define H264_LPS_RANGE_OFFSET 512
>>>  #define H264_MLPS_STATE_OFFSET 1024
>>> diff --git a/libavcodec/x86/constants.h b/libavcodec/x86/constants.h
>>> index 0c6bf41fa0..2561302604 100644
>>> --- a/libavcodec/x86/constants.h
>>> +++ b/libavcodec/x86/constants.h
>>> @@ -23,13 +23,14 @@
>>>
>>>  #include 
>>>
>>> +#include "libavutil/mem_internal.h"
>>>  #include "libavutil/x86/asm.h"
>>>
>>> -extern const ymm_reg  ff_pw_1;
>>> +extern DECLARE_EXTERNAL_ASM_VAR(32, const ymm_reg, ff_pw_1);
>>>  extern const ymm_reg  ff_pw_2;
>>>  extern const xmm_reg  ff_pw_3;
>>> -extern const ymm_reg  ff_pw_4;
>>> -extern const xmm_reg  ff_pw_5;
>>> +extern DECLARE_ASM_VAR(32, const ymm_reg, ff_pw_4);
>>> +extern DECLARE_ASM_VAR(16, const xmm_reg, ff_pw_5);
>>>  extern const xmm_reg  ff_pw_8;
>>>  extern const xmm_reg  ff_pw_9;
>>>  extern const uint64_t ff_pw_15;
>>> @@ -43,7 +44,7 @@ extern const uint64_t ff_pw_128;
>>>  extern const ymm_reg  ff_pw_255;
>>>  extern const ymm_reg  ff_pw_256;
>>>  extern const ymm_reg  ff_pw_512;
>>> -extern const ymm_reg  ff_pw_1023;
>>> +extern DECLARE_EXTERNAL_ASM_VAR(32, const ymm_reg, ff_pw_1023);
>>>  extern const ymm_reg  ff_pw_1024;
>>>  extern const ymm_reg  ff_pw_2048;
>>>  extern const ymm_reg  ff_pw_4095;
>>> @@ -52,9 +53,10 @@ extern const ymm_reg  ff_pw_8192;
>>>  extern const ymm_reg  ff_pw_m1;
>>>
>>>  extern const ymm_reg  ff_pb_0;
>>> -extern c

Re: [FFmpeg-devel] [PATCH v3] [NOT for git] avutil/tests/map: benchmark code [BENCHMARK included]

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Dienstag, 15. April 2025 22:51
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: [FFmpeg-devel] [PATCH v3] [NOT for git] avutil/tests/map:
> benchmark code [BENCHMARK included]
> 

[..]

> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/tests/map.c | 57
> +++
>  1 file changed, 57 insertions(+)
> 
> diff --git a/libavutil/tests/map.c b/libavutil/tests/map.c
> index 38f0a153e68..90950769f98 100644
> --- a/libavutil/tests/map.c
> +++ b/libavutil/tests/map.c
> @@ -26,6 +26,8 @@
>  #include "libavutil/mem.h"
>  #include "libavutil/map.h"
> 
> +#include "libavutil/timer.h"
> +#include "libavutil/dict.h"
> 
>  static void print_set(const AVMap *s)
>  {
> @@ -37,6 +39,7 @@ static void print_set(const AVMap *s)
> 
>  int main(void)
>  {
> +#if 0
>  void *our_cmp[] = {
>  strcmp,
>  av_map_strcmp_keyvalue,
> @@ -185,6 +188,60 @@ int main(void)
>  av_map_free(&set);
>  av_assert0(!set);
>  }
> +#else
> +#define N_ENTRIES 1000
> +#define P 4
> +fprintf(stderr, "%d entries variable bytes at location %d-%d\n",
> N_ENTRIES, P, P+1);
> +for (int runs = 0; runs < 1000; runs++) {
> +AVMap *map = av_map_new(av_strcasecmp, NULL, NULL);
> +for(int pass = 0; pass < 2; pass++) {
> +START_TIMER
> +unsigned r = 5;
> +for(int i=0; i +r = r*123 + 7;
> +char str[7] = "TEST";
> +str[P  ] = r;
> +str[P+1] = r>>8;
> +if(pass == 0) {
> +av_map_add(map, str, 7, str, 7, 0);
> +} else {
> +av_map_get(map, str, av_strcasecmp);
> +}
> +}
> +if (pass) {
> +STOP_TIMER("av_map_get")
> +} else {
> +STOP_TIMER("av_map_add")
> +}
> +}
> +av_map_free(&map);
> +}
> +
> +for (int runs = 0; runs < 1000; runs++) {
> +AVDictionary *dict = NULL;
> +for(int pass = 0; pass < 2; pass++) {
> +START_TIMER
> +unsigned r = 5;
> +for(int i=0; i +r = r*123 + 7;
> +char str[7] = "TEST";
> +str[P  ] = r;
> +str[P+1] = r>>8;
> +if(pass == 0) {
> +av_dict_set(&dict, str, str, 0);
> +} else {
> +av_dict_get(dict, str, NULL, 0);
> +}
> +}
> +if (pass) {
> +STOP_TIMER("av_dict_get")
> +} else {
> +STOP_TIMER("av_dict_set")
> +}
> +}
> +av_dict_free(&dict);
> +}
> +#endif
> 
>  return 0;
>  }
> --

Hi Michael,

is av_map_get() supposed tg work? I wasn't able to retrieve any values
(always null return).


Thanks


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

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

Re: [FFmpeg-devel] [PATCH] libavformat/dashdec: Fix buffer overflow in segment URL resolution

[Michael Niedermayer]

Hi

On Fri, Apr 11, 2025 at 03:48:08PM +0800, xiaohuan...@gmail.com wrote:
> From: xiaohuanshu 
> 
> Problem:
> The max_url_size calculation for DASH segment URLs only considered the base 
> URL
> length, leading to buffer overflow when the segment's sourceURL exceeded the
> pre-allocated buffer. This triggered the log error:
> "DASH request for url 'invalid:truncated'".
> 
> Reproduce:
> 1. A test sample "long-sourceurl-sample.mpd" (deliberately designed with a 
> long
>sourceURL) was uploaded to VideoLAN's repository.
> 2. Reproduce with short base path:
>ffmpeg -i /tmp/short_path/long-sourceurl-sample.mpd
>-> Triggers "invalid:truncated" error
> 3. With artificially lengthened base path (e.g. /aaa/../bbb/../...):
>ffmpeg -i 
> /long/../path/../with/../many/../segments/long-sourceurl-sample.mpd
>-> URL resolves correctly (though HTTP fetch fails due to fake URL)
> 
> Fix:
> Recalculate max_url_size by considering both base URL and sourceURL lengths,
> ensuring sufficient buffer allocation during URL concatenation.
> 
> Signed-off-by: xiaohuanshu 
> ---
>  libavformat/dashdec.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index c3f3d7f3f8..f604d363c4 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -606,7 +606,7 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
> *s, struct representati
>  char *initialization_val = NULL;
>  char *media_val = NULL;
>  char *range_val = NULL;
> -int max_url_size = c ? c->max_url_size: MAX_URL_SIZE;
> +int max_url_size = 0;
>  int err;
>  
>  if (!av_strcasecmp(fragmenturl_node->name, "Initialization")) {
> @@ -620,6 +620,12 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
> *s, struct representati
>  xmlFree(initialization_val);
>  return AVERROR(ENOMEM);
>  }
> +max_url_size = FFMAX(

> +c ? c->max_url_size : 0,

how can c be NULL here ?


> +initialization_val ? aligned(strlen(initialization_val) +
> + (rep_id_val ? 
> strlen(rep_id_val) : 0) +
> + (rep_bandwidth_val ? 
> strlen(rep_bandwidth_val) : 0)) : 0);
> +max_url_size = max_url_size ? max_url_size : MAX_URL_SIZE;
>  rep->init_section->url = get_content_url(baseurl_nodes, 4,
>   max_url_size,
>   rep_id_val,
> @@ -641,6 +647,12 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
> *s, struct representati
>  xmlFree(media_val);
>  return AVERROR(ENOMEM);
>  }
> +max_url_size = FFMAX(
> +c ? c->max_url_size : 0,

> +initialization_val ? aligned(strlen(initialization_val) +

how can initialization_val be non NULL here ?

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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] doc/filters: Fix video size of mptestsrc

[Michael Niedermayer]

On Tue, Apr 08, 2025 at 04:29:14PM +0800, Zhao Zhili wrote:
> From: Zhao Zhili 
> 
> ---
>  doc/filters.texi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 52f67fbd0c..6b8d2c314c 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -29642,7 +29642,7 @@ Set the initial y position. Must be a floating point 
> value between
>  
>  Generate various test patterns, as generated by the MPlayer test filter.
>  
> -The size of the generated video is fixed, and is 256x256.
> +The size of the generated video is fixed, and is 512x512.
>  This source is useful in particular for testing encoding features.
>  
>  This source accepts the following options:

LGTM

thx

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

Give a rich man 100$ and he will turn it into 1000$.
Give a poor man 1000$ and he will spend it.


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

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

Re: [FFmpeg-devel] [PATCH v3] avformat/fifo: Check for keyframe video type before stop dropping

[Michael Niedermayer]

On Thu, Apr 10, 2025 at 07:59:15PM -0300, Arthur Grillo wrote:
> The current behavior when using restart_with_keyframe is that it will
> recover if it also encounters any audio packet, as they are flagged as a
> keyframe.
> 
> The expectation is that packets are dropped until the next _video_
> keyframe.
> 
> To fix that, check if exists a video stream, if it exists check the
> packet stream codec type, only letting it recover when it is a video
> one. If there is no video stream, resume to the original behavior, not
> checking the codec type.
> 
> Fixes ticket: #11467
> 
> Signed-off-by: Arthur Grillo 
> ---
> Changes in v3:
> - Terminate `has_video_stream` description comment with a space
> - Fix indentation (Michael Niedermayer)
> - Link to v2: 
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20250405-video-only-kf-recover-v2-1-000e71a29...@riseup.net
> 
> Changes in v2:
> - Check for the presence of a video stream (Michael Niedermayer)
> - Link to v1: 
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20250312-video-only-kf-recover-v1-1-1e0e340da...@riseup.net
> ---
>  libavformat/fifo.c | 28 +---
>  1 file changed, 25 insertions(+), 3 deletions(-)

will apply
thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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] tools: Fix deprecation warning in patcheck

[Michael Niedermayer]

On Wed, Apr 09, 2025 at 08:26:56PM +0200, Link Mauve wrote:
> From: Link Mauve 
> 
> GNU apparently deprecated their egrep alias, replace it with 'grep -E'
> to avoid getting flooded with deprecation warnings.
> ---
>  tools/patcheck | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

thx

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[Michael Niedermayer]

On Tue, Apr 15, 2025 at 11:01:14PM +, softworkz . wrote:
[...]
> Besides, the patch had been submitted 3 years ago, there hasn't been 
> any review and the merge was totally unexpected.

no reply for 1 week means commit must be expected

"Send a patch to ffmpeg-devel. If no one answers within a reasonable
 time-frame (12h for build failures and security fixes, 3 days small changes,
 1 week for big patches) then commit your patch if you think it is OK.
 Also note, the maintainer can simply ask for more time to review!
"

besides, i reviewed the patch before applying it

and there was an open bug that alot of people wanted fixed.

thx

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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] configure: Clearer documentation for "disable-safe-bitstream-reader"

[Michael Niedermayer]

On Sat, Apr 12, 2025 at 02:42:11AM +0200, Michael Niedermayer wrote:
> On Sat, Apr 12, 2025 at 02:19:08AM +0200, Timo Rothenpieler wrote:
> > On 12.04.2025 02:11, Michael Niedermayer wrote:
> > > On Fri, Apr 11, 2025 at 08:32:55AM +0200, Andreas Rheinhardt wrote:
> > > > Michael Niedermayer:
> > > > > Signed-off-by: Michael Niedermayer 
> > > > > ---
> > > > >   configure | 3 ++-
> > > > >   1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/configure b/configure
> > > > > index bd4f8723760..f1db8b6f235 100755
> > > > > --- a/configure
> > > > > +++ b/configure
> > > > > @@ -436,7 +436,8 @@ Advanced options (experts only):
> > > > > --enable-hardcoded-tables use hardcoded tables instead of runtime 
> > > > > generation
> > > > > --disable-safe-bitstream-reader
> > > > >  disable buffer boundary checking in 
> > > > > bitreaders
> > > > > -   (faster, but may crash)
> > > > > +   (This disables some security checks and 
> > > > > can cause undefined behavior,
> > > > > +it may be faster, but should only be 
> > > > > used with trusted input)
> > > > > --sws-max-filter-size=N  the max filter size swscale uses 
> > > > > [$sws_max_filter_size_default]
> > > > >   Optimization options (experts only):
> > > > 
> > > > I'd like to keep "crash" in the description. Not everyone (not even
> > > > people setting "experts only" options) will be familiar with the term
> > > > "undefined behavior".
> > > 
> > > what about:
> > > 
> > > (This disables some security checks and can cause undefined behavior and
> > >   crashes, it may be faster, but should only be used with trusted input)
> > 
> > Given that the undefined behaviour can in theory even include arbitrary code
> > execution, I'd probably make it even harsher and mention that worst-case
> > being a possibility.
> 
> what about this:
> 
> (This disables some security checks and can cause undefined behavior,
>  crashes and arbitrary code execution, it may be faster, but
>  should only be used with trusted input)

will apply, feel free to change if someone has ideas for improvment

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are 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 2/2] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Mittwoch, 16. April 2025 03:22
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> On Tue, Apr 15, 2025 at 10:59:07PM +, softworkz . wrote:
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > > Michael Niedermayer
> > > Sent: Mittwoch, 16. April 2025 00:50
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> > > decode_str() did advance
> > >
> > > On Tue, Apr 15, 2025 at 07:59:00PM +, softworkz . wrote:
> > > [...]
> > >
> > > > - The representation of multi-values - both, internally and when
> > > >   outputting as probe data - is a de-facto standard
> > >
> > > The external handling in formats is specified in the corresponing
> > > specifications. ";" is certainly not correct for formats which
> > > natively support multiple values per key.
> > >
> > > Internally, if you have a data structure that represents multiple
> > > authors, you certainly do not set it to one author and a string
> > > with a bunch of semicolons seperating multiple authors
> > >
> > > Title: "Smile ;)"
> > > Author "Smily Face ;)"
> > >
> > > is not 2 Titles and not 2 Authors and software that cannot handle
> that
> > > should not be used as reference IMHO
> > >
> > > That said, anything that works is fine with me,
> > >
> > > But internally it will be better to use a representation that is
> > > universal, generic and simple, ";" may seem to be that but only
> > > as long as you do nothing with it and dont care about corner cases
> > >
> > > Ill leave this ";" question to everyone else, i have a backlog
> > > of quite a few things i need to work on
> >
> > This is not a great outcome, because "leaving everyone else" means
> > nothing will happen.
> 
> I have a release to do, I have contracts that i should be working on,
> as iam a few month behind some deadline, I have a backlog of fuzzer
> issues i wanted to look at. I have a backlog of other things
> 
> And this ";" thing is close to the last thing i want to spend my time
> on ;)

It's fine. You don't have to. I'm also not insisting on my patch.


> > At least revert the rcombs patch until there's a conclusion, because
> > it really makes things worse than better with regards to FFprobe
> > output.
> 
> I guess thats reasonable.

Perfect, thanks.


> > This will cause deserialization errors for many people in the world
> > who are processing FFprobe data.
> 
> As said, ffprobe should not produce troublesome output

As I said, it cannot be remedied on the FFprobe side without making a 
breaking change to its output format, that's what turns this small
thing into a big one.

Thank you
sw

___
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] avformat/id3v2: Check that decode_str() did advance

[Michael Niedermayer]

On Wed, Apr 16, 2025 at 01:29:02AM +, softworkz . wrote:
[...]
> > > This will cause deserialization errors for many people in the world
> > > who are processing FFprobe data.
> > 
> > As said, ffprobe should not produce troublesome output
> 
> As I said, it cannot be remedied on the FFprobe side without making a 

If you want ffprobe to combine multiple author tags with ";", you
certainly can do that in ffprobe

thx

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

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


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

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Mittwoch, 16. April 2025 02:54
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> On Tue, Apr 15, 2025 at 11:01:14PM +, softworkz . wrote:
> [...]
> > Besides, the patch had been submitted 3 years ago, there hasn't been
> > any review and the merge was totally unexpected.
> 
> no reply for 1 week means commit must be expected
> 
> "Send a patch to ffmpeg-devel. If no one answers within a reasonable
>  time-frame (12h for build failures and security fixes, 3 days small
> changes,
>  1 week for big patches) then commit your patch if you think it is OK.
>  Also note, the maintainer can simply ask for more time to review!
> "
> 
> besides, i reviewed the patch before applying it
> 
> and there was an open bug that alot of people wanted fixed.

But not in a way that breaks their deserialization or parsing.


Essentially, you've just exchanged this bug for another way more severe 
bug in the FFprobe output. Do you just want to await the reports
and complaints coming in?

No matter whether applying this patch was OK or not in the first place,
knowing that it causes a serious regression doesn't appear to me like 
something that could just be ignored, or do you think otherwise?

sw









___
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] avformat/id3v2: Check that decode_str() did advance

[Michael Niedermayer]

On Tue, Apr 15, 2025 at 10:59:07PM +, softworkz . wrote:
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Michael Niedermayer
> > Sent: Mittwoch, 16. April 2025 00:50
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> > decode_str() did advance
> > 
> > On Tue, Apr 15, 2025 at 07:59:00PM +, softworkz . wrote:
> > [...]
> > 
> > > - The representation of multi-values - both, internally and when
> > >   outputting as probe data - is a de-facto standard
> > 
> > The external handling in formats is specified in the corresponing
> > specifications. ";" is certainly not correct for formats which
> > natively support multiple values per key.
> > 
> > Internally, if you have a data structure that represents multiple
> > authors, you certainly do not set it to one author and a string
> > with a bunch of semicolons seperating multiple authors
> > 
> > Title: "Smile ;)"
> > Author "Smily Face ;)"
> > 
> > is not 2 Titles and not 2 Authors and software that cannot handle that
> > should not be used as reference IMHO
> > 
> > That said, anything that works is fine with me,
> > 
> > But internally it will be better to use a representation that is
> > universal, generic and simple, ";" may seem to be that but only
> > as long as you do nothing with it and dont care about corner cases
> > 
> > Ill leave this ";" question to everyone else, i have a backlog
> > of quite a few things i need to work on
> 
> This is not a great outcome, because "leaving everyone else" means 
> nothing will happen.

I have a release to do, I have contracts that i should be working on,
as iam a few month behind some deadline, I have a backlog of fuzzer
issues i wanted to look at. I have a backlog of other things

And this ";" thing is close to the last thing i want to spend my time on ;)


> 
> At least revert the rcombs patch until there's a conclusion, because
> it really makes things worse than better with regards to FFprobe 
> output.

I guess thats reasonable.
I will revert it, and then stay out of this unless it reaches the TC
(where I as member will participate in finding a solution)


> This will cause deserialization errors for many people in the world
> who are processing FFprobe data.

As said, ffprobe should not produce troublesome output

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Mittwoch, 16. April 2025 03:34
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> On Wed, Apr 16, 2025 at 01:29:02AM +, softworkz . wrote:
> [...]
> > > > This will cause deserialization errors for many people in the
> world
> > > > who are processing FFprobe data.
> > >
> > > As said, ffprobe should not produce troublesome output
> >
> > As I said, it cannot be remedied on the FFprobe side without making
> a
> 
> If you want ffprobe to combine multiple author tags with ";", you
> certainly can do that in ffprobe

That's not what I want to do, and if at all, it would be up to do
for the one who wants to introduce multi-key metadata.

This has a far wider scope and cannot be introduced in a drive-by
way via a bugfix patch.

I have already shown how the additional values get lost when transcoding
and that was just about ID3 tag writing. 

What about other formats (muxers)?

Can they deal with multi-key metadata?

Does it create regressions? 
(yet untested by FATE)


What I want to say is that this is a big change that needs discussion,
planning and evaluation of the consequences in all affected areas.
I can't be introduced by a bugfix which causes regressions and others
having to clean up the mess afterwards.

Thanks
sw










___
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] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Mittwoch, 16. April 2025 02:54
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> On Tue, Apr 15, 2025 at 11:01:14PM +, softworkz . wrote:
> [...]
> > Besides, the patch had been submitted 3 years ago, there hasn't been
> > any review and the merge was totally unexpected.
> 
> no reply for 1 week means commit must be expected
> 
> "Send a patch to ffmpeg-devel. If no one answers within a reasonable
>  time-frame (12h for build failures and security fixes, 3 days small
> changes,
>  1 week for big patches) then commit your patch if you think it is OK.
>  Also note, the maintainer can simply ask for more time to review!
> "

Does that mean that I can apply any patch from the past few years without
prior notice when it hasn't received a reply?

sw
___
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] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Mittwoch, 16. April 2025 03:34
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> On Wed, Apr 16, 2025 at 01:29:02AM +, softworkz . wrote:
> [...]
> > > > This will cause deserialization errors for many people in the
> world
> > > > who are processing FFprobe data.
> > >
> > > As said, ffprobe should not produce troublesome output
> >
> > As I said, it cannot be remedied on the FFprobe side without making
> a
> 
> If you want ffprobe to combine multiple author tags with ";", you
> certainly can do that in ffprobe

Which by-the-way contradicts most of your earlier arguments against
semicolon delimited values.

I gain the impression that the actual reason for why you (seemingly)
want this, might be for having an actual use case for the duplicate key support
in AVMap..?  😊

It's at least an interesting coincidence in time...
I can understand that, don't mean it in a negative way, just don't think it 
should be done at the cost of regressing the probe output.

Thanks
sw
___
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] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Mittwoch, 16. April 2025 03:34
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> On Wed, Apr 16, 2025 at 01:29:02AM +, softworkz . wrote:
> [...]
> > > > This will cause deserialization errors for many people in the
> world
> > > > who are processing FFprobe data.
> > >
> > > As said, ffprobe should not produce troublesome output

First of all, any patch MUST NOT introduce behavior that goes
against our own specifications.

>From avformat.h:

/**
 * @defgroup metadata_api Public Metadata API
 * @{
 * @ingroup libavf
 * The metadata API allows libavformat to export metadata tags to a client
 * application when demuxing. Conversely it allows a client application to
 * set metadata when muxing.
 *
 * Metadata is exported or set as pairs of key/value strings in the 'metadata'
 * fields of the AVFormatContext, AVStream, AVChapter and AVProgram structs
 * using the @ref lavu_dict "AVDictionary" API. Like all strings in FFmpeg,
 * metadata is assumed to be UTF-8 encoded Unicode. Note that metadata
 * exported by demuxers isn't checked to be valid UTF-8 in most cases.
 *
 * Important concepts to keep in mind:
 * -  Keys are unique; there can never be 2 tags with the same key. This is
 *also meant semantically, i.e., a demuxer should not knowingly produce
 *several keys that are literally different but semantically identical.
 *E.g., key=Author5, key=Author6. In this example, all authors must be
 *placed in the same tag.
 * -  Metadata is flat, not hierarchical; there are no subtags. If you
 *want to store, e.g., the email address of the child of producer Alice
 *and actor Bob, that could have key=alice_and_bobs_childs_email_address.
 * -  Several modifiers can be applied to the tag name. This is done by
 *appending a dash character ('-') and the modifier name in the order
 *they appear in the list below -- e.g. foo-eng-sort, not foo-sort-eng.
 *-  language -- a tag whose value is localized for a particular language
 *   is appended with the ISO 639-2/B 3-letter language code.
 *   For example: Author-ger=Michael, Author-eng=Mike
 *   The original/default language is in the unqualified "Author" tag.
 *   A demuxer should set a default if it sets any translated tag.
 *-  sorting  -- a modified version of a tag that should be used for
 *   sorting will have '-sort' appended. E.g. artist="The Beatles",
 *   artist-sort="Beatles, The".


Especially:

*E.g., key=Author5, key=Author6. In this example, all authors must be
*placed in the same tag.

I think, this tells very clearly how it's gotta be and how not.


Best,
sw




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

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

[FFmpeg-devel] [PATCH v2 2/2] ffprobe: show seekability details in format section

[Gyan Doshi]

---
 doc/ffprobe.xsd  |  2 ++
 fftools/ffprobe.c| 15 ++-
 tests/ref/fate/cavs-demux|  2 +-
 tests/ref/fate/ffprobe_compact   |  2 +-
 tests/ref/fate/ffprobe_csv   |  2 +-
 tests/ref/fate/ffprobe_default   |  2 ++
 tests/ref/fate/ffprobe_flat  |  2 ++
 tests/ref/fate/ffprobe_ini   |  2 ++
 tests/ref/fate/ffprobe_json  |  2 ++
 tests/ref/fate/ffprobe_xml   |  2 +-
 tests/ref/fate/ffprobe_xsd   |  2 +-
 tests/ref/fate/flv-demux |  2 +-
 tests/ref/fate/gapless-mp3-side-data |  2 +-
 tests/ref/fate/oggopus-demux |  2 +-
 tests/ref/fate/ts-demux  |  2 +-
 tests/ref/fate/ts-opus-demux |  2 +-
 tests/ref/fate/ts-small-demux|  2 +-
 tests/ref/fate/ts-timed-id3-demux|  2 +-
 18 files changed, 36 insertions(+), 13 deletions(-)

diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd
index b53b799227..ef9c9a006c 100644
--- a/doc/ffprobe.xsd
+++ b/doc/ffprobe.xsd
@@ -432,6 +432,8 @@
 
 
 
+
+
   
 
   
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index e0a7322523..0fbf7ab057 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2260,7 +2260,7 @@ static int show_format(AVTextFormatContext *tfc, 
InputFile *ifile)
 {
 AVFormatContext *fmt_ctx = ifile->fmt_ctx;
 int64_t size = fmt_ctx->pb ? avio_size(fmt_ctx->pb) : -1;
-int ret = 0;
+int seekable, ret = 0;
 
 avtext_print_section_header(tfc, NULL, SECTION_ID_FORMAT);
 print_str_validate("filename", fmt_ctx->url);
@@ -2279,6 +2279,19 @@ static int show_format(AVTextFormatContext *tfc, 
InputFile *ifile)
 if (fmt_ctx->bit_rate > 0) print_val("bit_rate", fmt_ctx->bit_rate, 
unit_bit_per_second_str);
 else   print_str_opt("bit_rate", "N/A");
 print_int("probe_score", fmt_ctx->probe_score);
+
+seekable = avformat_query_seekable(fmt_ctx);
+if (seekable > 0) {
+print_int("seekable",  1);
+if (seekable & AVSEEKABLE_PROP_FWDONLY)
+print_int("seek_backward", 0);
+else
+print_int("seek_backward", 1);
+}
+else {
+print_int("seekable",  0);
+print_int("seek_backward", 0);
+}
 if (do_show_format_tags)
 ret = show_tags(tfc, fmt_ctx->metadata, SECTION_ID_FORMAT_TAGS);
 
diff --git a/tests/ref/fate/cavs-demux b/tests/ref/fate/cavs-demux
index b1e2c2fd25..a7f5eda73b 100644
--- a/tests/ref/fate/cavs-demux
+++ b/tests/ref/fate/cavs-demux
@@ -59,4 +59,4 @@ 
packet|codec_type=video|stream_index=0|pts=232|pts_time=1.93|dts=232
 
packet|codec_type=video|stream_index=0|pts=236|pts_time=1.97|dts=236|dts_time=1.97|duration=4|duration_time=0.03|size=83|pos=172252|flags=K__|data_hash=CRC32:a941bdf0
 
packet|codec_type=video|stream_index=0|pts=240|pts_time=2.00|dts=240|dts_time=2.00|duration=4|duration_time=0.03|size=5417|pos=172335|flags=K__|data_hash=CRC32:9d0d503b
 
stream|index=0|codec_name=cavs|profile=unknown|codec_type=video|codec_tag_string=[0][0][0][0]|codec_tag=0x|width=1280|height=720|coded_width=1280|coded_height=720|has_b_frames=0|sample_aspect_ratio=N/A|display_aspect_ratio=N/A|pix_fmt=yuv420p|level=-99|color_range=unknown|color_space=unknown|color_transfer=unknown|color_primaries=unknown|chroma_location=unspecified|field_order=unknown|refs=1|id=N/A|r_frame_rate=30/1|avg_frame_rate=25/1|time_base=1/120|start_pts=N/A|start_time=N/A|duration_ts=N/A|duration=N/A|bit_rate=N/A|max_bit_rate=N/A|bits_per_raw_sample=N/A|nb_frames=N/A|nb_read_frames=N/A|nb_read_packets=60|extradata_size=18|extradata_hash=CRC32:1255d52e|disposition:default=0|disposition:dub=0|disposition:original=0|disposition:comment=0|disposition:lyrics=0|disposition:karaoke=0|disposition:forced=0|disposition:hearing_impaired=0|disposition:visual_impaired=0|disposition:clean_effects=0|disposition:attached_pic=0|disposition:timed_thumbnails=0|disposition:non_diegetic=0|disposition:captions=0|disposition:descriptions=0|disposition:metadata=0|disposition:dependent=0|disposition:still_image=0|disposition:multilayer=0
-format|filename=bunny.mp4|nb_streams=1|nb_programs=0|nb_stream_groups=0|format_name=cavsvideo|start_time=N/A|duration=N/A|size=177752|bit_rate=N/A|probe_score=51
+format|filename=bunny.mp4|nb_streams=1|nb_programs=0|nb_stream_groups=0|format_name=cavsvideo|start_time=N/A|duration=N/A|size=177752|bit_rate=N/A|probe_score=51|seekable=1|seek_backward=1
diff --git a/tests/ref/fate/ffprobe_compact b/tests/ref/fate/ffprobe_compact
index 68b9acf599..c4c0140656 100644
--- a/tests/ref/fate/ffprobe_compact
+++ b/tests/ref/fate/ffprobe_compact
@@ -29,4 +29,4 @@ 
frame|media_type=video|stream_index=2|key_frame=1|pts=6144|pts_time=0.12|pkt
 
stream|index=0|codec_name=pcm_s16le|profile=unknown|codec_type=audio|codec_tag_string=PSD[16]|codec_tag=0x10445350|sample_fmt=s16|sample_rate=44100|channels=1|channel_layo

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[Nicolas George]

softworkz . (HE12025-04-15):
> but it would be a breaking change

Please elaborate.

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

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

Re: [FFmpeg-devel] [PATCH v2 5/6] libavutil: Add AVMap

[Michael Niedermayer]

On Tue, Apr 15, 2025 at 09:14:42PM +0200, Nicolas George wrote:
> Michael Niedermayer (HE12025-04-15):
> > Where exactly would that benefit FFmpeg ?
> > Dictionaries generally are used to move stuff aorund, like metadata or
> > options.
> > Or may be used in the future to keep track of some mappings like
> > timestamps to file positions during demuxing or muxing
> > Or maybe codecs/formats lookup from name
> > None of these are confined to a single local function
> 
>   AVMap opts = av_map_create(cmp, NULL, NULL);
>   av_map_add(opts, "threads", "12");
>   av_map_add(opts, "crf", "18");
>   av_map_add(opts, "preset", "veryslow");
>   av_map_assert_small(opts);
>   ret = av_codec_open3(ctx, codec, opts);

Allocating and creating 12 threads and encoding a x264 video
(i guess this is x264) with "preset", "veryslow" will overshadow the
25 nanoseconds of a malloc() call

or is the goal to avoid the error handling?
I think the 12 threads encoder will fail if the map run out of memory

also in the specific example
av_codec_open3(ctx, codec, NULL);
will no longer work as NULL is a pointer and AVMap here looks like
it would not be


> 
> > i like av_map_new() because "new" is short
> 
> The exact name does not matter to me. I forgot that we usually use
> _alloc() for the case you implemented, so _new() is absolutely fine for
> this.
> 
> av_map_assert_small() should assert that no dynamic allocation happened,
> and at assert level 2 that the internal buffer is less than halfway full.

>
> > and sizeof(AVMap) is not public API
> 
> It should be public API like I did for BPrint, that is my point.

AVMap should be public but the implementation should not be any more
public than needed.
That way users cannot by mistake mess with internals and we can
improve the internal implementation without ABI/API breakage

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


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 v3] [NOT for git] avutil/tests/map: benchmark code [BENCHMARK included]

[Michael Niedermayer]

1000 entries variable bytes at location 4-5
  4809796 decicycles in av_map_add, 512 runs,  0 skips
  3457756 decicycles in av_map_get, 512 runs,  0 skips
153482370 decicycles in av_dict_set, 512 runs,  0 skips
150045088 decicycles in av_dict_get, 512 runs,  0 skips

100 entries variable bytes at location 4-5
 307603 decicycles in av_map_add, 512 runs,  0 skips
 207432 decicycles in av_map_get, 512 runs,  0 skips
1743433 decicycles in av_dict_set, 512 runs,  0 skips
1609130 decicycles in av_dict_get, 512 runs,  0 skips

10 entries variable bytes at location 4-5
  20084 decicycles in av_map_add, 512 runs,  0 skips
  11145 decicycles in av_map_get, 512 runs,  0 skips
  45788 decicycles in av_dict_set, 512 runs,  0 skips
  21217 decicycles in av_dict_get, 512 runs,  0 skips

5 entries variable bytes at location 4-5
   9476 decicycles in av_map_add, 512 runs,  0 skips
   4427 decicycles in av_map_get, 512 runs,  0 skips
  19873 decicycles in av_dict_set, 512 runs,  0 skips
   5404 decicycles in av_dict_get, 512 runs,  0 skips

3 entries variable bytes at location 4-5
   5695 decicycles in av_map_add, 512 runs,  0 skips
   2553 decicycles in av_map_get, 512 runs,  0 skips
  11035 decicycles in av_dict_set, 511 runs,  1 skips
   2523 decicycles in av_dict_get, 512 runs,  0 skips

3 entries variable bytes at location 0-1
   5496 decicycles in av_map_add, 512 runs,  0 skips
   1939 decicycles in av_map_get, 512 runs,  0 skips
  10867 decicycles in av_dict_set, 510 runs,  2 skips
   1823 decicycles in av_dict_get, 512 runs,  0 skips

5 entries variable bytes at location 0-1
   8228 decicycles in av_map_add, 512 runs,  0 skips
   3297 decicycles in av_map_get, 512 runs,  0 skips
  17767 decicycles in av_dict_set, 512 runs,  0 skips
   3917 decicycles in av_dict_get, 512 runs,  0 skips

10 entries variable bytes at location 0-1
  16691 decicycles in av_map_add, 511 runs,  1 skips
   7220 decicycles in av_map_get, 512 runs,  0 skips
  37575 decicycles in av_dict_set, 512 runs,  0 skips
  11498 decicycles in av_dict_get, 512 runs,  0 skips

100 entries variable bytes at location 0-1
 231734 decicycles in av_map_add, 512 runs,  0 skips
 128690 decicycles in av_map_get, 512 runs,  0 skips
1017393 decicycles in av_dict_set, 512 runs,  0 skips
 726464 decicycles in av_dict_get, 512 runs,  0 skips

1000 entries variable bytes at location 0-1
 3857396 decicycles in av_map_add, 512 runs,  0 skips
 2563465 decicycles in av_map_get, 512 runs,  0 skips
70277113 decicycles in av_dict_set, 512 runs,  0 skips
68152897 decicycles in av_dict_get, 512 runs,  0 skips

Signed-off-by: Michael Niedermayer 
---
 libavutil/tests/map.c | 57 +++
 1 file changed, 57 insertions(+)

diff --git a/libavutil/tests/map.c b/libavutil/tests/map.c
index 38f0a153e68..90950769f98 100644
--- a/libavutil/tests/map.c
+++ b/libavutil/tests/map.c
@@ -26,6 +26,8 @@
 #include "libavutil/mem.h"
 #include "libavutil/map.h"
 
+#include "libavutil/timer.h"
+#include "libavutil/dict.h"
 
 static void print_set(const AVMap *s)
 {
@@ -37,6 +39,7 @@ static void print_set(const AVMap *s)
 
 int main(void)
 {
+#if 0
 void *our_cmp[] = {
 strcmp,
 av_map_strcmp_keyvalue,
@@ -185,6 +188,60 @@ int main(void)
 av_map_free(&set);
 av_assert0(!set);
 }
+#else
+#define N_ENTRIES 1000
+#define P 4
+fprintf(stderr, "%d entries variable bytes at location %d-%d\n", 
N_ENTRIES, P, P+1);
+for (int runs = 0; runs < 1000; runs++) {
+AVMap *map = av_map_new(av_strcasecmp, NULL, NULL);
+for(int pass = 0; pass < 2; pass++) {
+START_TIMER
+unsigned r = 5;
+for(int i=0; i>8;
+if(pass == 0) {
+av_map_add(map, str, 7, str, 7, 0);
+} else {
+av_map_get(map, str, av_strcasecmp);
+}
+}
+if (pass) {
+STOP_TIMER("av_map_get")
+} else {
+STOP_TIMER("av_map_add")
+}
+}
+av_map_free(&map);
+}
+
+for (int runs = 0; runs < 1000; runs++) {
+AVDictionary *dict = NULL;
+for(int pass = 0; pass < 2; pass++) {
+START_TIMER
+unsigned r = 5;
+for(int i=0; i>8;
+if(pass == 0) {
+av_dict_set(&dict, str, str, 0);
+} else {
+av_dict_get(dict, str, NULL, 0);
+}
+}
+if (pass) {
+STOP_TIMER("av_dict_get")
+} else {
+STOP_TIMER("av_dict_set")
+}
+}
+  

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[Michael Niedermayer]

On Tue, Apr 15, 2025 at 07:59:00PM +, softworkz . wrote:
[...]

> - The representation of multi-values - both, internally and when
>   outputting as probe data - is a de-facto standard

The external handling in formats is specified in the corresponing
specifications. ";" is certainly not correct for formats which
natively support multiple values per key.

Internally, if you have a data structure that represents multiple
authors, you certainly do not set it to one author and a string
with a bunch of semicolons seperating multiple authors

Title: "Smile ;)"
Author "Smily Face ;)"

is not 2 Titles and not 2 Authors and software that cannot handle that
should not be used as reference IMHO

That said, anything that works is fine with me,

But internally it will be better to use a representation that is
universal, generic and simple, ";" may seem to be that but only
as long as you do nothing with it and dont care about corner cases

Ill leave this ";" question to everyone else, i have a backlog
of quite a few things i need to work on

I do intend though to apply my bugfix, as i dont want to leave that
bug, even if that ends up reverted and replaced by some other solution

thx

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Mittwoch, 16. April 2025 00:50
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> On Tue, Apr 15, 2025 at 07:59:00PM +, softworkz . wrote:
> [...]
> 
> > - The representation of multi-values - both, internally and when
> >   outputting as probe data - is a de-facto standard
> 
> The external handling in formats is specified in the corresponing
> specifications. ";" is certainly not correct for formats which
> natively support multiple values per key.
> 
> Internally, if you have a data structure that represents multiple
> authors, you certainly do not set it to one author and a string
> with a bunch of semicolons seperating multiple authors
> 
> Title: "Smile ;)"
> Author "Smily Face ;)"
> 
> is not 2 Titles and not 2 Authors and software that cannot handle that
> should not be used as reference IMHO
> 
> That said, anything that works is fine with me,
> 
> But internally it will be better to use a representation that is
> universal, generic and simple, ";" may seem to be that but only
> as long as you do nothing with it and dont care about corner cases
> 
> Ill leave this ";" question to everyone else, i have a backlog
> of quite a few things i need to work on

This is not a great outcome, because "leaving everyone else" means 
nothing will happen.

At least revert the rcombs patch until there's a conclusion, because
it really makes things worse than better with regards to FFprobe 
output.
This will cause deserialization errors for many people in the world
who are processing FFprobe data.

Thanks
sw



___
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] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> softworkz .
> Sent: Mittwoch, 16. April 2025 00:59
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Michael Niedermayer
> > Sent: Mittwoch, 16. April 2025 00:50
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> > decode_str() did advance
> >
> > On Tue, Apr 15, 2025 at 07:59:00PM +, softworkz . wrote:
> > [...]
> >
> > > - The representation of multi-values - both, internally and when
> > >   outputting as probe data - is a de-facto standard
> >
> > The external handling in formats is specified in the corresponing
> > specifications. ";" is certainly not correct for formats which
> > natively support multiple values per key.
> >
> > Internally, if you have a data structure that represents multiple
> > authors, you certainly do not set it to one author and a string
> > with a bunch of semicolons seperating multiple authors
> >
> > Title: "Smile ;)"
> > Author "Smily Face ;)"
> >
> > is not 2 Titles and not 2 Authors and software that cannot handle
> that
> > should not be used as reference IMHO
> >
> > That said, anything that works is fine with me,
> >
> > But internally it will be better to use a representation that is
> > universal, generic and simple, ";" may seem to be that but only
> > as long as you do nothing with it and dont care about corner cases
> >
> > Ill leave this ";" question to everyone else, i have a backlog
> > of quite a few things i need to work on
> 
> This is not a great outcome, because "leaving everyone else" means
> nothing will happen.
> 
> At least revert the rcombs patch until there's a conclusion, because
> it really makes things worse than better with regards to FFprobe
> output.
> This will cause deserialization errors for many people in the world
> who are processing FFprobe data.
> 

Besides, the patch had been submitted 3 years ago, there hasn't been 
any review and the merge was totally unexpected.

Thanks
sw



___
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] avformat/id3v2: Check that decode_str() did advance

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Nicolas George
> Sent: Dienstag, 15. April 2025 22:47
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that
> decode_str() did advance
> 
> softworkz . (HE12025-04-15):
> >   but it would be a breaking change
> 
> Please elaborate.

You are suggesting to change to an array [..] which breaks all usages.

sw
___
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 v12 1/8] libavcodec/decode.c: intercept `AV_PKT_DATA_METADATA_UPDATE` packet extra data, attach them to the next decoded frame.

[Romain Beauxis]

---
 libavcodec/decode.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index fca0c7ff58..06d899a9dd 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -97,6 +97,8 @@ typedef struct DecodeContext {
 int lcevc_frame;
 int width;
 int height;
+
+AVDictionary *pending_metadata;
 } DecodeContext;
 
 static DecodeContext *decode_ctx(AVCodecInternal *avci)
@@ -702,6 +704,8 @@ int attribute_align_arg avcodec_send_packet(AVCodecContext 
*avctx, const AVPacke
 {
 AVCodecInternal *avci = avctx->internal;
 DecodeContext *dc = decode_ctx(avci);
+const uint8_t *side_metadata;
+size_t size;
 int ret;
 
 if (!avcodec_is_open(avctx) || !av_codec_is_decoder(avctx->codec))
@@ -719,6 +723,14 @@ int attribute_align_arg avcodec_send_packet(AVCodecContext 
*avctx, const AVPacke
 ret = av_packet_ref(avci->buffer_pkt, avpkt);
 if (ret < 0)
 return ret;
+
+side_metadata = av_packet_get_side_data(avpkt, 
AV_PKT_DATA_METADATA_UPDATE, &size);
+if (side_metadata) {
+av_dict_free(&dc->pending_metadata);
+ret = av_packet_unpack_dictionary(side_metadata, size, 
&dc->pending_metadata);
+if (ret < 0)
+return ret;
+}
 } else
 dc->draining_started = 1;
 
@@ -788,6 +800,7 @@ fail:
 int ff_decode_receive_frame(AVCodecContext *avctx, AVFrame *frame)
 {
 AVCodecInternal *avci = avctx->internal;
+DecodeContext *dc = decode_ctx(avci);
 int ret;
 
 if (avci->buffer_frame->buf[0]) {
@@ -810,6 +823,11 @@ int ff_decode_receive_frame(AVCodecContext *avctx, AVFrame 
*frame)
 
 avctx->frame_num++;
 
+if (dc->pending_metadata) {
+av_dict_copy(&frame->metadata, dc->pending_metadata, AV_DICT_APPEND);
+av_dict_free(&dc->pending_metadata);
+}
+
 return 0;
 fail:
 av_frame_unref(frame);
@@ -2220,4 +2238,5 @@ void ff_decode_internal_uninit(AVCodecContext *avctx)
 DecodeContext *dc = decode_ctx(avci);
 
 av_refstruct_unref(&dc->lcevc);
+av_dict_free(&dc->pending_metadata);
 }
-- 
2.39.5 (Apple Git-154)

___
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 v12 5/8] libavformat/oggparseflac.c: Parse ogg/flac comments in new ogg packets, add them to ogg stream new_metadata.

[Romain Beauxis]

---
 libavformat/oggparseflac.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/libavformat/oggparseflac.c b/libavformat/oggparseflac.c
index f25ed9cc15..29f5904575 100644
--- a/libavformat/oggparseflac.c
+++ b/libavformat/oggparseflac.c
@@ -78,6 +78,25 @@ flac_header (AVFormatContext * s, int idx)
 return 1;
 }
 
+static int
+flac_packet (AVFormatContext * s, int idx)
+{
+struct ogg *ogg = s->priv_data;
+struct ogg_stream *os = ogg->streams + idx;
+AVStream *st = s->streams[idx];
+int ret;
+
+if (os->psize > 0 && os->buf[os->pstart] &&
+(os->buf[os->pstart] & 0x7F) == FLAC_METADATA_TYPE_VORBIS_COMMENT) {
+ret = ff_vorbis_update_metadata(s, st, os->buf + os->pstart + 4,
+os->psize - 4);
+if (ret < 0)
+return ret;
+}
+
+return 0;
+}
+
 static int
 old_flac_header (AVFormatContext * s, int idx)
 {
@@ -130,6 +149,7 @@ const struct ogg_codec ff_flac_codec = {
 .magic = "\177FLAC",
 .magicsize = 5,
 .header = flac_header,
+.packet = flac_packet,
 .nb_header = 2,
 };
 
@@ -137,5 +157,6 @@ const struct ogg_codec ff_old_flac_codec = {
 .magic = "fLaC",
 .magicsize = 4,
 .header = old_flac_header,
+.packet = flac_packet,
 .nb_header = 0,
 };
-- 
2.39.5 (Apple Git-154)

___
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 v12 2/8] tests: Add stream dump test API util.

[Romain Beauxis]

---
 tests/Makefile|   1 +
 tests/api/Makefile|   2 +-
 tests/api/api-dump-stream-meta-test.c | 177 ++
 3 files changed, 179 insertions(+), 1 deletion(-)
 create mode 100644 tests/api/api-dump-stream-meta-test.c

diff --git a/tests/Makefile b/tests/Makefile
index f9f5fc07f3..1f7e5003c2 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -277,6 +277,7 @@ $(FATE_FFPROBE) $(FATE_FFMPEG_FFPROBE) 
$(FATE_SAMPLES_FFPROBE) $(FATE_SAMPLES_FF
 $(FATE_SAMPLES_FASTSTART): tools/qt-faststart$(EXESUF)
 $(FATE_SAMPLES_DUMP_DATA) $(FATE_SAMPLES_DUMP_DATA-yes): 
tools/venc_data_dump$(EXESUF)
 $(FATE_SAMPLES_SCALE_SLICE): tools/scale_slice_test$(EXESUF)
+$(FATE_SAMPLES_DUMP_STREAM_META): tests/api/api-dump-stream-meta-test$(EXESUF)
 
 ifdef SAMPLES
 FATE += $(FATE_EXTERN)
diff --git a/tests/api/Makefile b/tests/api/Makefile
index c96e636756..a2cb06a729 100644
--- a/tests/api/Makefile
+++ b/tests/api/Makefile
@@ -1,7 +1,7 @@
 APITESTPROGS-$(call ENCDEC, FLAC, FLAC) += api-flac
 APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264
 APITESTPROGS-$(call DEMDEC, H264, H264) += api-h264-slice
-APITESTPROGS-yes += api-seek
+APITESTPROGS-yes += api-seek api-dump-stream-meta
 APITESTPROGS-$(call DEMDEC, H263, H263) += api-band
 APITESTPROGS-$(HAVE_THREADS) += api-threadmessage
 APITESTPROGS += $(APITESTPROGS-yes)
diff --git a/tests/api/api-dump-stream-meta-test.c 
b/tests/api/api-dump-stream-meta-test.c
new file mode 100644
index 00..bbfbd1f30b
--- /dev/null
+++ b/tests/api/api-dump-stream-meta-test.c
@@ -0,0 +1,177 @@
+/*
+ * Copyright (c) 2025 Romain Beauxis
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/**
+ * Dump stream metadata
+ */
+
+#include "libavcodec/avcodec.h"
+#include "libavformat/avformat.h"
+#include "libavutil/timestamp.h"
+
+static int dump_stream_meta(const char *input_filename) {
+const AVCodec *codec = NULL;
+AVPacket *pkt = NULL;
+AVFrame *fr = NULL;
+AVFormatContext *fmt_ctx = NULL;
+AVCodecContext *ctx = NULL;
+AVCodecParameters *origin_par = NULL;
+AVStream *st;
+int stream_idx = 0;
+int result;
+char *metadata;
+
+result = avformat_open_input(&fmt_ctx, input_filename, NULL, NULL);
+if (result < 0) {
+av_log(NULL, AV_LOG_ERROR, "Can't open file\n");
+return result;
+}
+
+result = avformat_find_stream_info(fmt_ctx, NULL);
+if (result < 0) {
+av_log(NULL, AV_LOG_ERROR, "Can't get stream info\n");
+goto end;
+}
+
+if (fmt_ctx->nb_streams > 1) {
+av_log(NULL, AV_LOG_ERROR, "More than one stream found in input!\n");
+goto end;
+}
+
+origin_par = fmt_ctx->streams[stream_idx]->codecpar;
+st = fmt_ctx->streams[stream_idx];
+
+result = av_dict_get_string(st->metadata, &metadata, '=', ':');
+if (result < 0)
+goto end;
+
+printf("Stream ID: %d, codec name: %s, metadata: %s\n", stream_idx,
+   avcodec_get_name(origin_par->codec_id),
+   strlen(metadata) ? metadata : "N/A");
+
+codec = avcodec_find_decoder(origin_par->codec_id);
+if (!codec) {
+av_log(NULL, AV_LOG_ERROR, "Can't find decoder\n");
+result = AVERROR_DECODER_NOT_FOUND;
+goto end;
+}
+
+ctx = avcodec_alloc_context3(codec);
+if (!ctx) {
+av_log(NULL, AV_LOG_ERROR, "Can't allocate decoder context\n");
+result = AVERROR(ENOMEM);
+goto end;
+}
+
+result = avcodec_parameters_to_context(ctx, origin_par);
+if (result) {
+av_log(NULL, AV_LOG_ERROR, "Can't copy decoder context\n");
+goto end;
+}
+
+result = avcodec_open2(ctx, codec, NULL);
+if (result < 0) {
+av_log(ctx, AV_LOG_ERROR, "Can't open decoder\n");
+goto end;
+}
+
+pkt = av_packet_alloc();
+if (!pkt) {
+av_log(NULL, AV_LOG_ERROR, "Cannot allocate packet\n");
+result = AVERROR(ENOMEM);

[FFmpeg-devel] [PATCH v12 4/8] libavformat/oggdec.h, libavformat/oggparsevorbis.c: Factor out vorbis metadata update mechanism.

[Romain Beauxis]

---
 libavformat/oggdec.h | 14 ++
 libavformat/oggparsevorbis.c | 25 +
 2 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/libavformat/oggdec.h b/libavformat/oggdec.h
index 43df23f4cb..c8460a66e9 100644
--- a/libavformat/oggdec.h
+++ b/libavformat/oggdec.h
@@ -151,6 +151,20 @@ int ff_vorbis_comment(AVFormatContext *ms, AVDictionary 
**m,
 int ff_vorbis_stream_comment(AVFormatContext *as, AVStream *st,
  const uint8_t *buf, int size);
 
+/**
+ * Parse Vorbis comments, add metadata to an AVStream
+ *
+ * This function also attaches the metadata to the next decoded
+ * packet as AV_PKT_DATA_METADATA_UPDATE
+ *
+ * @note  The buffer will be temporarily modifed by this function,
+ *so it needs to be writable. Furthermore it must be padded
+ *by a single byte (not counted in size).
+ *All changes will have been reverted upon return.
+ */
+int ff_vorbis_update_metadata(AVFormatContext *s, AVStream *st,
+  const uint8_t *buf, int size);
+
 static inline int
 ogg_find_stream (struct ogg * ogg, int serial)
 {
diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c
index 9f50ab9ffc..308deb7feb 100644
--- a/libavformat/oggparsevorbis.c
+++ b/libavformat/oggparsevorbis.c
@@ -263,20 +263,16 @@ static void vorbis_cleanup(AVFormatContext *s, int idx)
 }
 }
 
-static int vorbis_update_metadata(AVFormatContext *s, int idx)
+int ff_vorbis_update_metadata(AVFormatContext *s, AVStream *st,
+  const uint8_t *buf, int size)
 {
 struct ogg *ogg = s->priv_data;
-struct ogg_stream *os = ogg->streams + idx;
-AVStream *st = s->streams[idx];
+struct ogg_stream *os = ogg->streams + st->index;
 int ret;
 
-if (os->psize <= 8)
-return 0;
-
 /* New metadata packet; release old data. */
 av_dict_free(&st->metadata);
-ret = ff_vorbis_stream_comment(s, st, os->buf + os->pstart + 7,
-   os->psize - 8);
+ret = ff_vorbis_stream_comment(s, st, buf, size);
 if (ret < 0)
 return ret;
 
@@ -293,6 +289,19 @@ static int vorbis_update_metadata(AVFormatContext *s, int 
idx)
 return ret;
 }
 
+static int vorbis_update_metadata(AVFormatContext *s, int idx)
+{
+struct ogg *ogg = s->priv_data;
+struct ogg_stream *os = ogg->streams + idx;
+AVStream *st = s->streams[idx];
+
+if (os->psize <= 8)
+return 0;
+
+return ff_vorbis_update_metadata(s, st, os->buf + os->pstart + 7,
+ os->psize - 8);
+}
+
 static int vorbis_header(AVFormatContext *s, int idx)
 {
 struct ogg *ogg = s->priv_data;
-- 
2.39.5 (Apple Git-154)

___
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 v12 0/8] Properly decode ogg metadata in ogg/{vorbis, flac, opus} chained bitstreams.

[Romain Beauxis]

This is a series of patches to allow proper decoding of ogg metadata in chained
`ogg/vorbis, `ogg/flac` and `ogg/opus` streams.

Samples are available at: 
https://www.dropbox.com/scl/fo/xrtrna2rxr1j354hrtymq/AGwemlxHYecBLNmQ8Fsy--4?rlkey=lzilr4m9w4gfdqygoe172vvy8&dl=0

## Changes since last version:
* Reverted metadata decoding logic to the previous, simpler
  implementation.

Romain Beauxis (8):
  libavcodec/decode.c: intercept `AV_PKT_DATA_METADATA_UPDATE` packet
extra data, attach them to the next decoded frame.
  tests: Add stream dump test API util.
  tests: Add chained ogg/vorbis stream dump test.
  libavformat/oggdec.h, libavformat/oggparsevorbis.c: Factor out vorbis
metadata update mechanism.
  libavformat/oggparseflac.c: Parse ogg/flac comments in new ogg
packets, add them to ogg stream new_metadata.
  tests: Add chained ogg/flac stream dump test.
  libavformat/oggparseopus.c: Parse comments from secondary chained
streams header packet.
  tests: Add chained ogg/opus stream dump test.

 libavcodec/decode.c|  19 +++
 libavformat/oggdec.h   |  14 ++
 libavformat/oggparseflac.c |  21 +++
 libavformat/oggparseopus.c |  13 +-
 libavformat/oggparsevorbis.c   |  25 ++-
 tests/Makefile |   4 +
 tests/api/Makefile |   2 +-
 tests/api/api-dump-stream-meta-test.c  | 177 +
 tests/fate/ogg-flac.mak|  11 ++
 tests/fate/ogg-opus.mak|  11 ++
 tests/fate/ogg-vorbis.mak  |  11 ++
 tests/ref/fate/ogg-flac-chained-meta.txt   |  13 ++
 tests/ref/fate/ogg-opus-chained-meta.txt   |  27 
 tests/ref/fate/ogg-vorbis-chained-meta.txt |  17 ++
 14 files changed, 355 insertions(+), 10 deletions(-)
 create mode 100644 tests/api/api-dump-stream-meta-test.c
 create mode 100644 tests/fate/ogg-flac.mak
 create mode 100644 tests/fate/ogg-opus.mak
 create mode 100644 tests/fate/ogg-vorbis.mak
 create mode 100644 tests/ref/fate/ogg-flac-chained-meta.txt
 create mode 100644 tests/ref/fate/ogg-opus-chained-meta.txt
 create mode 100644 tests/ref/fate/ogg-vorbis-chained-meta.txt

-- 
2.39.5 (Apple Git-154)

___
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 v12 3/8] tests: Add chained ogg/vorbis stream dump test.

[Romain Beauxis]

---
 tests/Makefile |  1 +
 tests/fate/ogg-vorbis.mak  | 11 +++
 tests/ref/fate/ogg-vorbis-chained-meta.txt | 17 +
 3 files changed, 29 insertions(+)
 create mode 100644 tests/fate/ogg-vorbis.mak
 create mode 100644 tests/ref/fate/ogg-vorbis-chained-meta.txt

diff --git a/tests/Makefile b/tests/Makefile
index 1f7e5003c2..cffa586e8d 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -219,6 +219,7 @@ include $(SRC_PATH)/tests/fate/mpeg4.mak
 include $(SRC_PATH)/tests/fate/mpegps.mak
 include $(SRC_PATH)/tests/fate/mpegts.mak
 include $(SRC_PATH)/tests/fate/mxf.mak
+include $(SRC_PATH)/tests/fate/ogg-vorbis.mak
 include $(SRC_PATH)/tests/fate/oma.mak
 include $(SRC_PATH)/tests/fate/opus.mak
 include $(SRC_PATH)/tests/fate/pcm.mak
diff --git a/tests/fate/ogg-vorbis.mak b/tests/fate/ogg-vorbis.mak
new file mode 100644
index 00..74805d591e
--- /dev/null
+++ b/tests/fate/ogg-vorbis.mak
@@ -0,0 +1,11 @@
+FATE_OGG_VORBIS += fate-ogg-vorbis-chained-meta
+fate-ogg-vorbis-chained-meta: REF = 
$(SRC_PATH)/tests/ref/fate/ogg-vorbis-chained-meta.txt
+fate-ogg-vorbis-chained-meta: CMD = run 
$(APITESTSDIR)/api-dump-stream-meta-test$(EXESUF) 
$(TARGET_SAMPLES)/ogg-vorbis/chained-meta.ogg
+
+FATE_OGG_VORBIS-$(call DEMDEC, OGG, VORBIS) += $(FATE_OGG_VORBIS)
+
+FATE_SAMPLES_DUMP_STREAM_META += $(FATE_OGG_VORBIS-yes)
+
+FATE_EXTERN += $(FATE_OGG_VORBIS-yes)
+
+fate-ogg-vorbis: $(FATE_OGG_VORBIS-yes)
diff --git a/tests/ref/fate/ogg-vorbis-chained-meta.txt 
b/tests/ref/fate/ogg-vorbis-chained-meta.txt
new file mode 100644
index 00..71514819b4
--- /dev/null
+++ b/tests/ref/fate/ogg-vorbis-chained-meta.txt
@@ -0,0 +1,17 @@
+Stream ID: 0, codec name: vorbis, metadata: encoder=Lavc61.19.100 
libvorbis:title=First Stream
+Stream ID: 0, packet PTS: 0, packet DTS: 0
+Stream ID: 0, new metadata: encoder=Lavc61.19.100 libvorbis:title=First Stream
+Stream ID: 0, packet PTS: 128, packet DTS: 128
+Stream ID: 0, frame PTS: 128, metadata: encoder=Lavc61.19.100 
libvorbis:title=First Stream
+Stream ID: 0, packet PTS: 704, packet DTS: 704
+Stream ID: 0, frame PTS: 704, metadata: N/A
+Stream ID: 0, packet PTS: 0, packet DTS: 0
+Stream ID: 0, packet PTS: 0, packet DTS: 0
+Stream ID: 0, new metadata: encoder=Lavc61.19.100 libvorbis:title=Second Stream
+Stream ID: 0, packet PTS: 0, packet DTS: 0
+Stream ID: 0, packet PTS: 0, packet DTS: 0
+Stream ID: 0, frame PTS: 0, metadata: encoder=Lavc61.19.100 
libvorbis:title=Second Stream
+Stream ID: 0, packet PTS: 128, packet DTS: 128
+Stream ID: 0, frame PTS: 128, metadata: N/A
+Stream ID: 0, packet PTS: 704, packet DTS: 704
+Stream ID: 0, frame PTS: 704, metadata: N/A
-- 
2.39.5 (Apple Git-154)

___
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 v12 8/8] tests: Add chained ogg/opus stream dump test.

[Romain Beauxis]

---
 tests/Makefile   |  1 +
 tests/fate/ogg-opus.mak  | 11 ++
 tests/ref/fate/ogg-opus-chained-meta.txt | 27 
 3 files changed, 39 insertions(+)
 create mode 100644 tests/fate/ogg-opus.mak
 create mode 100644 tests/ref/fate/ogg-opus-chained-meta.txt

diff --git a/tests/Makefile b/tests/Makefile
index a37f2ab587..75b9bcc729 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -221,6 +221,7 @@ include $(SRC_PATH)/tests/fate/mpegts.mak
 include $(SRC_PATH)/tests/fate/mxf.mak
 include $(SRC_PATH)/tests/fate/ogg-vorbis.mak
 include $(SRC_PATH)/tests/fate/ogg-flac.mak
+include $(SRC_PATH)/tests/fate/ogg-opus.mak
 include $(SRC_PATH)/tests/fate/oma.mak
 include $(SRC_PATH)/tests/fate/opus.mak
 include $(SRC_PATH)/tests/fate/pcm.mak
diff --git a/tests/fate/ogg-opus.mak b/tests/fate/ogg-opus.mak
new file mode 100644
index 00..54b6fbabde
--- /dev/null
+++ b/tests/fate/ogg-opus.mak
@@ -0,0 +1,11 @@
+FATE_OGG_OPUS += fate-ogg-opus-chained-meta
+fate-ogg-opus-chained-meta: REF = 
$(SRC_PATH)/tests/ref/fate/ogg-opus-chained-meta.txt
+fate-ogg-opus-chained-meta: CMD = run 
$(APITESTSDIR)/api-dump-stream-meta-test$(EXESUF) 
$(TARGET_SAMPLES)/ogg-opus/chained-meta.ogg
+
+FATE_OGG_OPUS-$(call DEMDEC, OGG, OPUS) += $(FATE_OGG_OPUS)
+
+FATE_SAMPLES_DUMP_STREAM_META += $(FATE_OGG_OPUS-yes)
+
+FATE_EXTERN += $(FATE_OGG_OPUS-yes)
+
+fate-ogg-opus: $(FATE_OGG_OPUS-yes)
diff --git a/tests/ref/fate/ogg-opus-chained-meta.txt 
b/tests/ref/fate/ogg-opus-chained-meta.txt
new file mode 100644
index 00..aad9b83700
--- /dev/null
+++ b/tests/ref/fate/ogg-opus-chained-meta.txt
@@ -0,0 +1,27 @@
+Stream ID: 0, codec name: opus, metadata: encoder=Lavc61.19.100 
libopus:title=First Stream
+Stream ID: 0, packet PTS: -312, packet DTS: -312
+Stream ID: 0, new metadata: encoder=Lavc61.19.100 libopus:title=First Stream
+Stream ID: 0, frame PTS: -312, metadata: N/A
+Stream ID: 0, packet PTS: 648, packet DTS: 648
+Stream ID: 0, frame PTS: 648, metadata: N/A
+Stream ID: 0, packet PTS: 1608, packet DTS: 1608
+Stream ID: 0, frame PTS: 1608, metadata: N/A
+Stream ID: 0, packet PTS: 2568, packet DTS: 2568
+Stream ID: 0, frame PTS: 2568, metadata: N/A
+Stream ID: 0, packet PTS: 3528, packet DTS: 3528
+Stream ID: 0, frame PTS: 3528, metadata: N/A
+Stream ID: 0, packet PTS: 4488, packet DTS: 4488
+Stream ID: 0, frame PTS: 4488, metadata: N/A
+Stream ID: 0, packet PTS: -312, packet DTS: -312
+Stream ID: 0, new metadata: encoder=Lavc61.19.100 libopus:title=Second Stream
+Stream ID: 0, frame PTS: -312, metadata: encoder=Lavc61.19.100 
libopus:title=Second Stream
+Stream ID: 0, packet PTS: 648, packet DTS: 648
+Stream ID: 0, frame PTS: 648, metadata: N/A
+Stream ID: 0, packet PTS: 1608, packet DTS: 1608
+Stream ID: 0, frame PTS: 1608, metadata: N/A
+Stream ID: 0, packet PTS: 2568, packet DTS: 2568
+Stream ID: 0, frame PTS: 2568, metadata: N/A
+Stream ID: 0, packet PTS: 3528, packet DTS: 3528
+Stream ID: 0, frame PTS: 3528, metadata: N/A
+Stream ID: 0, packet PTS: 4488, packet DTS: 4488
+Stream ID: 0, frame PTS: 4488, metadata: N/A
-- 
2.39.5 (Apple Git-154)

___
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 v12 6/8] tests: Add chained ogg/flac stream dump test.

[Romain Beauxis]

---
 tests/Makefile   |  1 +
 tests/fate/ogg-flac.mak  | 11 +++
 tests/ref/fate/ogg-flac-chained-meta.txt | 13 +
 3 files changed, 25 insertions(+)
 create mode 100644 tests/fate/ogg-flac.mak
 create mode 100644 tests/ref/fate/ogg-flac-chained-meta.txt

diff --git a/tests/Makefile b/tests/Makefile
index cffa586e8d..a37f2ab587 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -220,6 +220,7 @@ include $(SRC_PATH)/tests/fate/mpegps.mak
 include $(SRC_PATH)/tests/fate/mpegts.mak
 include $(SRC_PATH)/tests/fate/mxf.mak
 include $(SRC_PATH)/tests/fate/ogg-vorbis.mak
+include $(SRC_PATH)/tests/fate/ogg-flac.mak
 include $(SRC_PATH)/tests/fate/oma.mak
 include $(SRC_PATH)/tests/fate/opus.mak
 include $(SRC_PATH)/tests/fate/pcm.mak
diff --git a/tests/fate/ogg-flac.mak b/tests/fate/ogg-flac.mak
new file mode 100644
index 00..0d6a015161
--- /dev/null
+++ b/tests/fate/ogg-flac.mak
@@ -0,0 +1,11 @@
+FATE_OGG_FLAC += fate-ogg-flac-chained-meta
+fate-ogg-flac-chained-meta: REF = 
$(SRC_PATH)/tests/ref/fate/ogg-flac-chained-meta.txt
+fate-ogg-flac-chained-meta: CMD = run 
$(APITESTSDIR)/api-dump-stream-meta-test$(EXESUF) 
$(TARGET_SAMPLES)/ogg-flac/chained-meta.ogg
+
+FATE_OGG_FLAC-$(call DEMDEC, OGG, FLAC) += $(FATE_OGG_FLAC)
+
+FATE_SAMPLES_DUMP_STREAM_META += $(FATE_OGG_FLAC-yes)
+
+FATE_EXTERN += $(FATE_OGG_FLAC-yes)
+
+fate-ogg-flac: $(FATE_OGG_FLAC-yes)
diff --git a/tests/ref/fate/ogg-flac-chained-meta.txt 
b/tests/ref/fate/ogg-flac-chained-meta.txt
new file mode 100644
index 00..9c5d4fca0c
--- /dev/null
+++ b/tests/ref/fate/ogg-flac-chained-meta.txt
@@ -0,0 +1,13 @@
+Stream ID: 0, codec name: flac, metadata: encoder=Lavc61.19.100 
flac:title=First Stream
+Stream ID: 0, packet PTS: 0, packet DTS: 0
+Stream ID: 0, new metadata: encoder=Lavc61.19.100 flac:title=First Stream
+Stream ID: 0, frame PTS: 0, metadata: N/A
+Stream ID: 0, packet PTS: 4608, packet DTS: 4608
+Stream ID: 0, frame PTS: 4608, metadata: N/A
+Stream ID: 0, packet PTS: 0, packet DTS: 0
+Stream ID: 0, packet PTS: 0, packet DTS: 0
+Stream ID: 0, new metadata: encoder=Lavc61.19.100 flac:title=Second Stream
+Stream ID: 0, packet PTS: 0, packet DTS: 0
+Stream ID: 0, frame PTS: 0, metadata: encoder=Lavc61.19.100 flac:title=Second 
Stream
+Stream ID: 0, packet PTS: 4608, packet DTS: 4608
+Stream ID: 0, frame PTS: 4608, metadata: N/A
-- 
2.39.5 (Apple Git-154)

___
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 v12 7/8] libavformat/oggparseopus.c: Parse comments from secondary chained streams header packet.

[Romain Beauxis]

---
 libavformat/oggparseopus.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/libavformat/oggparseopus.c b/libavformat/oggparseopus.c
index 218e9df581..fe25ad44f3 100644
--- a/libavformat/oggparseopus.c
+++ b/libavformat/oggparseopus.c
@@ -29,6 +29,7 @@
 
 struct oggopus_private {
 int need_comments;
+int comments_parsed;
 unsigned pre_skip;
 int64_t cur_dts;
 };
@@ -81,7 +82,17 @@ static int opus_header(AVFormatContext *avf, int idx)
 if (priv->need_comments) {
 if (os->psize < 8 || memcmp(packet, "OpusTags", 8))
 return AVERROR_INVALIDDATA;
-ff_vorbis_stream_comment(avf, st, packet + 8, os->psize - 8);
+
+if (!priv->comments_parsed) {
+ff_vorbis_stream_comment(avf, st, packet + 8, os->psize - 8);
+priv->comments_parsed = 1;
+} else {
+ret = ff_vorbis_update_metadata(avf, st, packet + 8, os->psize - 
8);
+
+if (ret < 0)
+return ret;
+}
+
 priv->need_comments--;
 return 1;
 }
-- 
2.39.5 (Apple Git-154)

___
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/h264_mb: Fix buffer stride for arm

[Michael Niedermayer]

On Tue, Apr 08, 2025 at 07:22:32PM +0800, Bin Peng wrote:
> When decoding a bitstream with weighted-bipred enabled,
> the results on ARM and x86 platforms may differ.
> 
> The reason for the inconsistency is that the value of
> STRIDE_ALIGN differs between platforms. And STRIDE_ALIGN
> is set to the buffer stride of temporary buffers for U
> and V components in mc_part_weighted.
> 
> If the buffer stride is 32 or 64 (as on x86 platforms),
> the U and V pixels can be interleaved row by row without
> overlapping, resulting in correct output.
> However, on ARM platforms where the stride is 16,
> the V component will overwrite part of the U component's pixels,
> leading to incorrect predicted pixels.
> 
> The bug can be reproduced by the following bitstream.
> 
> https://trac.ffmpeg.org/attachment/ticket/11357/inter_weighted_bipred2.264
> 
> And the ref/fate file is also added in this patch.
> 
> Fixes: ticket 11357
> Signed-off-by: Bin Peng 
> ---
>  libavcodec/utils.c|  4 ++-

>  .../h264-conformance-weighted_bipred2.264 | 31 +++

is this supposed to be a fate test ?
if so theres something missing also the file extension is a bit misleading
and tests covering more cases is always welcome


>  2 files changed, 34 insertions(+), 1 deletion(-)
>  create mode 100644 tests/ref/fate/h264-conformance-weighted_bipred2.264
> 
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 90867ed6b1..5d15f5c8fa 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -144,6 +144,7 @@ void avcodec_align_dimensions2(AVCodecContext *s, int 
> *width, int *height,
>  int i;
>  int w_align = 1;
>  int h_align = 1;
> +int stride_align = STRIDE_ALIGN;
>  AVPixFmtDescriptor const *desc = av_pix_fmt_desc_get(s->pix_fmt);
>  
>  if (desc) {
> @@ -339,13 +340,14 @@ void avcodec_align_dimensions2(AVCodecContext *s, int 
> *width, int *height,
>  // increasing witdth ensure that the temporary area is large enough,
>  // the next rounded up width is 32
>  *width = FFMAX(*width, 32);
> +stride_align = FFMAX(stride_align, 32);

does the following fix this too ?

diff --git a/libavcodec/h264_mb.c b/libavcodec/h264_mb.c
index 6083f7ad84f..0d6562b5830 100644
--- a/libavcodec/h264_mb.c
+++ b/libavcodec/h264_mb.c
@@ -407,7 +407,7 @@ static av_always_inline void mc_part_weighted(const 
H264Context *h, H264SliceCon
 /* don't optimize for luma-only case, since B-frames usually
  * use implicit weights => chroma too. */
 uint8_t *tmp_cb = sl->bipred_scratchpad;
-uint8_t *tmp_cr = sl->bipred_scratchpad + (16 << pixel_shift);
+uint8_t *tmp_cr = sl->bipred_scratchpad + (8 << pixel_shift + 
(chroma_idc == 3));
 uint8_t *tmp_y  = sl->bipred_scratchpad + 16 * sl->mb_uvlinesize;
 int refn0   = sl->ref_cache[0][scan8[n]];
 int refn1   = sl->ref_cache[1][scan8[n]];

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

Never trust a computer, one day, it may think you are the virus. -- Compn


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

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

Re: [FFmpeg-devel] [PATCH 01/12] fftools/textformat/avtextformat: Simplify avtext_print_rational()

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Andreas Rheinhardt
> Sent: Dienstag, 15. April 2025 10:36
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 01/12]
> fftools/textformat/avtextformat: Simplify avtext_print_rational()
> 
> softworkz .:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> >> Andreas Rheinhardt
> >> Sent: Dienstag, 15. April 2025 03:00
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: [FFmpeg-devel] [PATCH 01/12]
> fftools/textformat/avtextformat:
> >> Simplify avtext_print_rational()
> >>
> >> Patches attached.
> >>
> >> - Andreas
> >
> >
> > Hi Andreas,
> >
> > thanks a lot for working through this. I'll go over it tomorrow.
> >
> > As to not waste your time, it's probably best when we get those
> > changes applied in a timely manner so that I can rebase the new
> > patchset on top of it.
> >
> > Since you're sending the patches as attachments:
> > How do you want me to reply with code context? Whole files or
> > just snippets? And quoted?
> >
> 
> Snippets is better. So is quoted.
> 
> - Andreas
> 

Hi Andreas,

thanks again for the well-spotted improvements. Just two notes:


0007-fftools-textformat-Use-av_default_item_name.patch

In the new patchset, those macros are removed from the individual
files. There's now a single macro in tf_internal.h and I've applied
this change there.



0008-fftools-textformat-avtextformat-Fix-segfault-upon-al.patch
0009-fftools-textformat-avtextformat-Fix-segfault-upon-al.patch

Can this happen?
(yet I'm good with it)


Everything else LGTM:

0001-fftools-textformat-avtextformat-Simplify-avtext_prin.patch
0002-fftools-textformat-Use-not-for-lavu-headers.patch
0003-fftools-textformat-tw_avio-Remove-unused-private-cla.patch
0004-fftools-textformat-tw_avio-Don-t-flush-unnecessarily.patch
0005-fftools-textformat-tw_avio-Use-avio_closep.patch
0006-textformat-tw_avio-Remove-close_on_uninit-param-from.patch

0010-fftools-textformat-avtextformat-Initialize-stuff-ear.patch
0011-fftools-textformat-avtextformat-Add-missing-AVERROR.patch
0012-fftools-textformat-avtextformat-Make-close-functions.patch


>From my side, it would be great when we can get this merged asap,
then I'll post a rebased version of the patchset, also accounting
for your other review comment.

Thanks again,
sw




___
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".