Re: [FFmpeg-devel] [PATCH 5/6] lavc/apv: AVX2 transquant for x86-64

2025-04-19 Thread Mark Thompson
On 19/04/2025 20:07, Mark Thompson wrote:
> Typical checkasm result on Alder Lake:
> 
> decode_transquant_8_c: 408.7 ( 1.00x)
> decode_transquant_8_avx2:   94.2 ( 4.34x)
> decode_transquant_10_c:413.1 ( 1.00x)
> decode_transquant_10_avx2:  87.5 ( 4.72x)

Interestingly this is signficantly better on an older Skylake.  Typical result 
there:

decode_transquant_8_c: 892.5 ( 1.00x)
decode_transquant_8_avx2:  143.4 ( 6.22x)
decode_transquant_10_c:938.7 ( 1.00x)
decode_transquant_10_avx2: 137.9 ( 6.81x)

> ---
>  libavcodec/apv_dsp.c  |   4 +
>  libavcodec/apv_dsp.h  |   2 +
>  libavcodec/x86/Makefile   |   2 +
>  libavcodec/x86/apv_dsp.asm| 243 ++
>  libavcodec/x86/apv_dsp_init.c |  41 ++
>  tests/checkasm/Makefile   |   1 +
>  tests/checkasm/apv_dsp.c  | 113 
>  tests/checkasm/checkasm.c |   3 +
>  tests/checkasm/checkasm.h |   1 +
>  9 files changed, 410 insertions(+)
>  create mode 100644 libavcodec/x86/apv_dsp.asm
>  create mode 100644 libavcodec/x86/apv_dsp_init.c
>  create mode 100644 tests/checkasm/apv_dsp.c
> 
> diff --git a/libavcodec/apv_dsp.c b/libavcodec/apv_dsp.c
> index 6b8b6ce590..108a3cd370 100644
> --- a/libavcodec/apv_dsp.c
> +++ b/libavcodec/apv_dsp.c
> @@ -133,4 +133,8 @@ static void apv_decode_transquant_c(void *output,
>  av_cold void ff_apv_dsp_init(APVDSPContext *dsp)
>  {
>  dsp->decode_transquant = apv_decode_transquant_c;
> +
> +#if ARCH_X86_64
> +ff_apv_dsp_init_x86_64(dsp);
> +#endif
>  }
> diff --git a/libavcodec/apv_dsp.h b/libavcodec/apv_dsp.h
> index 13f401c4cc..a7b5377357 100644
> --- a/libavcodec/apv_dsp.h
> +++ b/libavcodec/apv_dsp.h
> @@ -34,4 +34,6 @@ typedef struct APVDSPContext {
>  
>  void ff_apv_dsp_init(APVDSPContext *dsp);
>  
> +void ff_apv_dsp_init_x86_64(APVDSPContext *dsp);
> +
>  #endif /* AVCODEC_APV_DSP_H */
> diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
> index 5d53515381..821c410a0f 100644
> --- a/libavcodec/x86/Makefile
> +++ b/libavcodec/x86/Makefile
> @@ -44,6 +44,7 @@ OBJS-$(CONFIG_ADPCM_G722_DECODER)  += x86/g722dsp_init.o
>  OBJS-$(CONFIG_ADPCM_G722_ENCODER)  += x86/g722dsp_init.o
>  OBJS-$(CONFIG_ALAC_DECODER)+= x86/alacdsp_init.o
>  OBJS-$(CONFIG_APNG_DECODER)+= x86/pngdsp_init.o
> +OBJS-$(CONFIG_APV_DECODER) += x86/apv_dsp_init.o
>  OBJS-$(CONFIG_CAVS_DECODER)+= x86/cavsdsp.o
>  OBJS-$(CONFIG_CFHD_DECODER)+= x86/cfhddsp_init.o
>  OBJS-$(CONFIG_CFHD_ENCODER)+= x86/cfhdencdsp_init.o
> @@ -149,6 +150,7 @@ X86ASM-OBJS-$(CONFIG_ADPCM_G722_DECODER) += x86/g722dsp.o
>  X86ASM-OBJS-$(CONFIG_ADPCM_G722_ENCODER) += x86/g722dsp.o
>  X86ASM-OBJS-$(CONFIG_ALAC_DECODER) += x86/alacdsp.o
>  X86ASM-OBJS-$(CONFIG_APNG_DECODER) += x86/pngdsp.o
> +X86ASM-OBJS-$(CONFIG_APV_DECODER)  += x86/apv_dsp.o
>  X86ASM-OBJS-$(CONFIG_CAVS_DECODER) += x86/cavsidct.o
>  X86ASM-OBJS-$(CONFIG_CFHD_ENCODER) += x86/cfhdencdsp.o
>  X86ASM-OBJS-$(CONFIG_CFHD_DECODER) += x86/cfhddsp.o
> diff --git a/libavcodec/x86/apv_dsp.asm b/libavcodec/x86/apv_dsp.asm
> new file mode 100644
> index 00..0329089f45
> --- /dev/null
> +++ b/libavcodec/x86/apv_dsp.asm
> @@ -0,0 +1,243 @@
> +;
> +;* 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
> +;* 51, Inc., Foundation Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> +;**
> +
> +%include "libavutil/x86/x86util.asm"
> +
> +SECTION .text
> +
> +align 32
> +const tmatrixh
> +dw  64,  89,  84,  75,  64,  50,  35,  18
> +dw  64,  75,  35, -18, -64, -89, -84, -50
> +dw  64,  50, -35, -89, -64,  18,  84,  75
> +dw  64,  18, -84, -50,  64,  75, -35, -89
> +dw  64, -18, -84,  50,  64, -75, -35,  89
> +dw  64, -50, -35,  89, -64, -18,  84, -75
> +dw  64, -75,  35,  18, -64,  89, -84,  50
> +dw  64, -89,  84, -75,  64, -50,  35, -18
> +const tmatrixv
> +dw  64,

[FFmpeg-devel] [PATCH] avutil/map: [WIP] Introduction

2025-04-19 Thread Michael Niedermayer
Note, help is welcome.
Time i spend on this, i cannot spend on other things

Note2: i intend to push AVMap after the release unless the release
ends up delayed alot for other reasons, theres no real reason
to hurry here except that i seem to keep workig on it when
people ask for some non trivial changes/improvments :)
so dont ask, send patch yourself if its not a trivial change :))

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

diff --git a/libavutil/map.h b/libavutil/map.h
index 8211a05ec8d..0d3f7eab9ac 100644
--- a/libavutil/map.h
+++ b/libavutil/map.h
@@ -31,6 +31,92 @@
 #include "tree.h"
 
 /**
+ * @file
+ *
+ * AVMap is a simple and fast key -> value map.
+ *
+ * -- Creating AVMaps --
+ *
+ * AVMap *map = av_map_alloc(strcmp, AV_MAP_CMP_CASE_SENSITIVE + 
AV_MAP_CMP_KEY, NULL, NULL);
+ *
+ * This creates a case sensitve string based map using strcmp(). It will not 
allow
+ * multiple entries with the same key.
+ * or
+ *
+ * AVMap *map = av_map_alloc(av_map_strcmp_keyvalue, AV_MAP_CMP_CASE_SENSITIVE 
+ AV_MAP_CMP_KEYVALUE, NULL, NULL);
+ *
+ * This is like the previous, but it will allow multiple entries with the same 
key
+ * the difference here is that the compare function compares the value too when
+ * the key is equal.
+ * All entries in a map must always be different. So by comparing the value
+ * too we can have multiple entries with the same key
+ *
+ * The remaining 2 pointers in av_map_alloc() are for a function copying an 
element
+ * and one for freeing it. That is only needed for complex objects, not for 
strings.
+ *
+ *
+ * --- Adding entries -
+ *
+ * av_map_add_strings(map, "cat", "neko", 0); // add new entry or do nothing
+ *
+ * av_map_add_strings(map, "cat", "neko", AV_MAP_REPLACE); // add new entry or 
replace existing
+ *
+ *
+ * --- Removing entries -
+ *
+ * Removing entries does by default not rebuild the map. That is, while access 
will always
+ * be O(log n) when n becomes smaller, memory consumption will not decrease 
until
+ * AV_SET_ALLOW_REBUILD is used. Note if you use AV_SET_ALLOW_REBUILD, all 
previously
+ * returned elements become invalid.
+ *
+ * av_map_del(map, "cat", 0); // remove one entry matching "the key"
+ *
+ * av_map_del(map, "cat", AV_SET_ALLOW_REBUILD); // remove one entry matching 
"the key" and rebuild the map to re
+ *
+ *
+ * --- Retrieving an entry --
+ *
+ * AVMapEntry *e = av_map_get(map, "cat", AV_MAP_CMP_KEY); //Find an entry 
with the key = "cat"
+ *
+ * AVMapEntry *e = av_map_get(map, "cat", 
AV_MAP_CMP_KEY+AV_MAP_CMP_CASE_INSENSITIVE); //Find an entry with the key = 
"cat", "Cat", "cAt", ...
+ * // this will only work if one of the set compare functions is case 
insensitive
+ *
+ *
+ * --- Iterating over all elements --
+ *
+ * const AVMapEntry *t = NULL;
+ * while ((t = av_map_iterate(s, t)))
+ * printf("%s=%s %zu,%zu   ", t->key, t->value, t->keylen, t->valuelen);
+ *
+ *
+ * --- copying all elements of a mep into another map
+ *
+ * av_map_copy(dst, src);
+ *
+ *
+ * --- freeing a map -
+ *
+ * av_map_free(&map);
+ *
+ *
+ * --- multiple compare function in a single map ---
+ *
+ * Each map has a primary compare function, which is used for ordering 
elements.
+ * Additional (compatible) compare functions can be added with 
av_map_add_cmp_func()
+ *
+ * What "compaibility" means here is that every added function returns the 
same value
+ * as the primary function or 0.
+ *
+ * An example, Imagine we have "cat", "dog", "Dog", "fox"
+ * a function that treats "dog" and "Dog" as equal is compatible to this 
ordering
+ * OTOH
+ * if we have have strcmp() as primary function we would order like this:
+ * "Dog", "cat", "dog", "fox"
+ * and here we could not treat "dog" and "Dog" as equal, and thus case 
insensitive
+ * compare would not be possible
+ *
+ * --- compared to AVDictionary ---
+ *
  * compared to AVDictionary this has
  * clone is O(n) instead of O(n²)
  * copy is O(n*log n) instead of O(n²)
-- 
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] fftools/ffmpeg: Log 'EXIT' on exit

2025-04-19 Thread softworkz
From: softworkz 

When viewing logs, there are situations where it is not entirely
clear whether ffmpeg CLI has exited gracefully. The two primary cases
are

- A crash/segfault has occured
  Windows for example doesn't output any message to the calling shell
- The process has been terminated (e.g. killed externally)

Printing "EXIT" on exit provides a reliable indication that the
process has exited normally.

Signed-off-by: softworkz 
---
fftools/ffmpeg: Log 'EXIT' on exit

When viewing logs, there are situations where it is not entirely clear
whether ffmpeg CLI has exited gracefully. The two primary cases are

 * A crash/segfault has occured Windows for example doesn't output any
   message to the calling shell
 * The process has been terminated (e.g. killed externally)

Printing "EXIT" on exit provides a reliable indication that the process
has exited normally.

Signed-off-by: softworkz softwo...@hotmail.com

Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-69%2Fsoftworkz%2Fsubmit_exit_message-v1
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-69/softworkz/submit_exit_message-v1
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/69

 fftools/ffmpeg.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index dc321fb4a2..26746699ff 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1012,5 +1012,8 @@ finish:
 
 sch_free(&sch);
 
+av_log(NULL, AV_LOG_INFO, "\n");
+av_log(NULL, AV_LOG_INFO, "EXIT\n");
+
 return ret;
 }

base-commit: 7cd1edeaa410d977a9f1ff8436f480cb45b80178
-- 
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@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 5/6] lavc/apv: AVX2 transquant for x86-64

2025-04-19 Thread James Almer

On 4/19/2025 4:07 PM, Mark Thompson wrote:

diff --git a/libavcodec/x86/apv_dsp.asm b/libavcodec/x86/apv_dsp.asm
new file mode 100644
index 00..0329089f45
--- /dev/null
+++ b/libavcodec/x86/apv_dsp.asm
@@ -0,0 +1,243 @@
+;
+;* 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
+;* 51, Inc., Foundation Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+;**
+
+%include "libavutil/x86/x86util.asm"
+
+SECTION .text
+
+align 32
+const tmatrixh


SECTION_RODATA 32

tmatrixh: dw ...
tmatrixy: dw ...

etc. Add only functions to SECTION .text


+dw  64,  89,  84,  75,  64,  50,  35,  18
+dw  64,  75,  35, -18, -64, -89, -84, -50
+dw  64,  50, -35, -89, -64,  18,  84,  75
+dw  64,  18, -84, -50,  64,  75, -35, -89
+dw  64, -18, -84,  50,  64, -75, -35,  89
+dw  64, -50, -35,  89, -64, -18,  84, -75
+dw  64, -75,  35,  18, -64,  89, -84,  50
+dw  64, -89,  84, -75,  64, -50,  35, -18
+const tmatrixv
+dw  64,  89,  84,  75,  64,  50,  35,  18
+dw  64, -18, -84,  50,  64, -75, -35,  89
+dw  64,  75,  35, -18, -64, -89, -84, -50
+dw  64, -50, -35,  89, -64, -18,  84, -75
+dw  64,  50, -35, -89, -64,  18,  84,  75
+dw  64, -75,  35,  18, -64,  89, -84,  50
+dw  64,  18, -84, -50,  64,  75, -35, -89
+dw  64, -89,  84, -75,  64, -50,  35, -18
+
+; Memory targets for vpbroadcastd (register version requires AVX512).
+const one
+dd   1


There's pd_1 defined in constants.c, and you can include it here with

cextern pd_1


+const sixtyfour
+dd  64
+
+; void ff_apv_decode_transquant_avx2(void *output,
+;ptrdiff_t pitch,
+;const int16_t *input,
+;const int16_t *qmatrix,
+;int64_t bit_depth,
+;int64_t qp_shift);
+
+INIT_YMM avx2
+
+cglobal apv_decode_transquant, 6, 6, 16, output, pitch, input, qmatrix, 
bit_depth, qp_shift
+
+; Load input and dequantise
+
+lea   rax, [bit_depthq - 2]


Are you sure you're not overwriting a passed in argument with this? rax 
is different on Unix64, x86_32, and Win64 ABIs. You have qp_shift free 
after the mov to xm8 if you need a tmp register.
In general, you should use the names you gave the registers, or the r$ 
aliases from x86inc.



+movq  xm8, qp_shiftq


Both bit_depth and this fit in an int, so unless there's a real reason 
to use int64_t in the prototype, you can change them to int and read 32 
bits from the registers.



+movq  xm9, rax
+vpbroadcastd  m10, [one]
+vpslldm10, m10, xm9
+vpsrldm10, m10, 1


No need to add the v prefix to pre-AVX instructions. x86inc will do its 
magic and add emit the VEX encoded version for them as required. 
Similarly, if dst and src1 are the same, you can remove one of them and 
x86inc will also handle it, so just do:


   pslldm10, xm9

And so. This is important to get yelled at by x86inc if you misuse an 
instruction in some cases, and if you use SWAP and other x86inc helpers 
so the correct register is used.



+
+; m8  = scalar qp_shift
+; m9  = scalar bd_shift
+; m10 = vector 1 << (bd_shift - 1)
+; m11 = qmatrix load
+%macro LOAD_AND_DEQUANT 2 ; (xmm input, constant offset)
+vpmovsxwd m%1, [inputq   + %2]
+vpmovsxwd m11, [qmatrixq + %2]
+vpmulld   m%1, m%1, m11


Can't you use pmaddwd here, seeing it's 16bit x 16bit -> 32bit? pmulld 
is super slow, like 10 cycles vs 3 or less from every other integer 
multiply instruction.



+vpslldm%1, m%1, xm8
+vpadddm%1, m%1, m10
+vpsradm%1, m%1, xm9
+vpackssdw m%1, m%1, m%1
+%endmacro





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


[FFmpeg-devel] [PATCH] fftools/ffmpeg: Include elapsed-time in print_report()

2025-04-19 Thread softworkz
From: softworkz 

It's a highly useful metric, both at runtime and when viewing logs.

Signed-off-by: softworkz 
---
fftools/ffmpeg: Include elapsed-time in print_report()

It's a highly useful metric, both at runtime and when viewing logs.

Signed-off-by: softworkz softwo...@hotmail.com

Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-68%2Fsoftworkz%2Fsubmit_elapsed-v1
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-68/softworkz/submit_elapsed-v1
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/68

 fftools/ffmpeg.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index dc321fb4a2..6d184f9189 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -555,7 +555,7 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 static int64_t last_time = -1;
 static int first_report = 1;
 uint64_t nb_frames_dup = 0, nb_frames_drop = 0;
-int mins, secs, us;
+int mins, secs, ms, us;
 int64_t hours;
 const char *hours_sign;
 int ret;
@@ -579,6 +579,16 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 vid = 0;
 av_bprint_init(&buf, 0, AV_BPRINT_SIZE_AUTOMATIC);
 av_bprint_init(&buf_script, 0, AV_BPRINT_SIZE_AUTOMATIC);
+
+secs = (int)t;
+ms = (int)((t - secs) * 1000);
+mins = secs / 60;
+secs %= 60;
+hours = mins / 60;
+mins %= 60;
+
+av_bprintf(&buf, "elapsed=%02d:%02d:%02d.%02d ", hours, mins, secs, ms / 
10);
+
 for (OutputStream *ost = ost_iter(NULL); ost; ost = ost_iter(ost)) {
 const float q = ost->enc ? atomic_load(&ost->quality) / (float) 
FF_QP2LAMBDA : -1;
 

base-commit: 7cd1edeaa410d977a9f1ff8436f480cb45b80178
-- 
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[FFmpeg-devel] [PATCH] fftools/ffprobe: Disable stderr buffering on Windows

2025-04-19 Thread softworkz
From: softworkz 

An identical call exists in ffmpeg.c

With POSIX/glibc, stderr is already unbuffered (or line-buffered when
a terminal is connected), but not in case of MSVCRT.
Explicitly calling setvbuf() like in this commit, makes the Windows
runtime behave like POSIX, giving the same “print immediately” behavior.

Signed-off-by: softworkz 
---
fftools/ffprobe: Disable stderr buffering on Windows

An identical call exists in ffmpeg.c

With POSIX/glibc, stderr is already unbuffered (or line-buffered when a
terminal is connected), but not in case of MSVCRT. Explicitly calling
setvbuf() like in this commit, makes the Windows runtime behave like
POSIX, giving the same “print immediately” behavior.

Signed-off-by: softworkz softwo...@hotmail.com

Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-67%2Fsoftworkz%2Fsubmit_probe_nobuf-v1
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-67/softworkz/submit_probe_nobuf-v1
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/67

 fftools/ffprobe.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index f5c83925b9..d980d4e64f 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -3081,6 +3081,8 @@ int main(int argc, char **argv)
 
 init_dynload();
 
+setvbuf(stderr, NULL, _IONBF, 0); /* win32 runtime needs this */
+
 av_log_set_flags(AV_LOG_SKIP_REPEATED);
 
 options = real_options;

base-commit: 7cd1edeaa410d977a9f1ff8436f480cb45b80178
-- 
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Hardware purchase request: Ryzen 9 CPU

2025-04-19 Thread Neal Gompa
On Fri, Apr 4, 2025 at 5:22 PM Niklas Haas  wrote:
>
> On Fri, 04 Apr 2025 22:41:39 +0200 Lynne  wrote:
> > On 04/04/2025 19:20, Niklas Haas wrote:
> > > Hi all,
> > >
> > > My current workstation (first generation Zen) is getting rather old (8 
> > > years).
> > > On top of being slow and power hungry, it is also not very representative
> > > anymore of modern hardware.
> > >
> > > Additionally, I would like to try and incorporate AVX-512 instructions for
> > > my swscale rewrite, in particular for the pixel conversions.
> > >
> > > The recently released Ryzen 9 series of workstation CPUs are looking very
> > > attractive right now; In particular the 9950X3D, which appears at the top 
> > > of
> > > the timed compilation benchmarks.
> > >
> > > As such, I am humbly requesting the purchase of this CPU, alongside a 
> > > suitable
> > > mainboard and RAM:
> > >
> > > https://de.pcpartpicker.com/list/fFshGJ
> > > The total price at time of posting would be 1364 EUR.
> >
> > Sure, looks good to me.
> > I'd advise going for ECC RAM these days, if only because they don't have
> > LEDs, but up to you.
>
> Afaict, no current X870-generation motherboard on the market support ECC,
> or if they do, they cost significantly more. (As well as the RAM)
>

The memory controller is part of the CPU, and all AMD Ryzen CPUs
support ECC memory as long as they physically fit in the slot. :)


-- 
真実はいつも一つ!/ Always, there's only one truth!
___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavutil: Add AVMap

2025-04-19 Thread 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

Signed-off-by: Michael Niedermayer 
---
 libavutil/Makefile|   3 +
 libavutil/map.c   | 437 ++
 libavutil/map.h   | 279 
 libavutil/tests/map.c | 221 +++
 libavutil/tree.c  |   6 +-
 libavutil/tree_internal.h |  28 +++
 tests/fate/libavutil.mak  |   4 +
 tests/ref/fate/map|  27 +++
 8 files changed, 1000 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..af1ca61054e
--- /dev/null
+++ b/libavutil/map.c
@@ -0,0 +1,437 @@
+/*
+ * 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{
+#define CMP_MASK 31
+AVMapCompareFunc cmp[27];
+AVMapCopyFunc copy;
+AVMapFreeFunc freef;
+size_t count;
+size_t deleted;
+size_t next;   ///< index of entry in root array after all 
used entries
+unsigned internal_entries_len;
+AVTreeNode *tree_root;
+AVMapInternalEntry *internal_entries;
+};
+
+static

Re: [FFmpeg-devel] [PATCH 5/6] lavc/apv: AVX2 transquant for x86-64

2025-04-19 Thread James Almer

On 4/19/2025 4:07 PM, Mark Thompson wrote:

Typical checkasm result on Alder Lake:

decode_transquant_8_c: 408.7 ( 1.00x)
decode_transquant_8_avx2:   94.2 ( 4.34x)
decode_transquant_10_c:413.1 ( 1.00x)
decode_transquant_10_avx2:  87.5 ( 4.72x)
---
  libavcodec/apv_dsp.c  |   4 +
  libavcodec/apv_dsp.h  |   2 +
  libavcodec/x86/Makefile   |   2 +
  libavcodec/x86/apv_dsp.asm| 243 ++
  libavcodec/x86/apv_dsp_init.c |  41 ++
  tests/checkasm/Makefile   |   1 +
  tests/checkasm/apv_dsp.c  | 113 
  tests/checkasm/checkasm.c |   3 +
  tests/checkasm/checkasm.h |   1 +
  9 files changed, 410 insertions(+)
  create mode 100644 libavcodec/x86/apv_dsp.asm
  create mode 100644 libavcodec/x86/apv_dsp_init.c
  create mode 100644 tests/checkasm/apv_dsp.c


[...]


diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index d5c50e5599..193c1e4633 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -28,6 +28,7 @@ AVCODECOBJS-$(CONFIG_AAC_DECODER)   += aacpsdsp.o \
 sbrdsp.o
  AVCODECOBJS-$(CONFIG_AAC_ENCODER)   += aacencdsp.o
  AVCODECOBJS-$(CONFIG_ALAC_DECODER)  += alacdsp.o
+AVCODECOBJS-$(CONFIG_APV_DECODER)   += apv_dsp.o
  AVCODECOBJS-$(CONFIG_DCA_DECODER)   += synth_filter.o
  AVCODECOBJS-$(CONFIG_DIRAC_DECODER) += diracdsp.o
  AVCODECOBJS-$(CONFIG_EXR_DECODER)   += exrdsp.o
diff --git a/tests/checkasm/apv_dsp.c b/tests/checkasm/apv_dsp.c
new file mode 100644
index 00..a0272d8edc
--- /dev/null
+++ b/tests/checkasm/apv_dsp.c
@@ -0,0 +1,113 @@
+/*
+ * 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 "checkasm.h"
+
+#include "libavutil/attributes.h"
+#include "libavutil/mem_internal.h"
+#include "libavcodec/apv_dsp.h"
+
+
+static void check_decode_transquant_8(void)
+{
+LOCAL_ALIGNED_16(int16_t, input,  [64]);
+LOCAL_ALIGNED_16(int16_t, qmatrix,[64]);
+LOCAL_ALIGNED_16(uint8_t, new_output, [64]);
+LOCAL_ALIGNED_16(uint8_t, ref_output, [64]);
+
+declare_func(void,
+ uint8_t *output,
+ ptrdiff_t pitch,
+ const int16_t *input,
+ const int16_t *qmatrix,
+ int64_t bit_depth,
+ int64_t qp_shift);
+
+for (int i = 0; i < 64; i++) {
+// Any signed 12-bit integer.
+input[i] = rnd() % 2048 - 1024;
+
+// qmatrix input is premultiplied by level_scale, so
+// range is 1 to 255 * 71.  Interesting values are all
+// at the low end of that, though.
+qmatrix[i] = rnd() % 16 + 16;
+}
+
+call_ref(ref_output, 8, input, qmatrix, 8, 4);
+call_new(new_output, 8, input, qmatrix, 8, 4);
+
+for (int i = 0; i < 64; i++) {
+if (ref_output[i] != new_output[i])


memcmp?


+fail();
+}
+
+bench_new(new_output, 8, input, qmatrix, 8, 4);
+}
+
+static void check_decode_transquant_10(void)
+{
+LOCAL_ALIGNED_16( int16_t, input,  [64]);
+LOCAL_ALIGNED_16( int16_t, qmatrix,[64]);
+LOCAL_ALIGNED_16(uint16_t, new_output, [64]);
+LOCAL_ALIGNED_16(uint16_t, ref_output, [64]);
+
+declare_func(void,
+ uint16_t *output,
+ ptrdiff_t pitch,
+ const int16_t *input,
+ const int16_t *qmatrix,
+ int64_t bit_depth,
+ int64_t qp_shift);
+
+for (int i = 0; i < 64; i++) {
+// Any signed 14-bit integer.
+input[i] = rnd() % 16384 - 8192;
+
+// qmatrix input is premultiplied by level_scale, so
+// range is 1 to 255 * 71.  Interesting values are all
+// at the low end of that, though.
+qmatrix[i] = 16; //rnd() % 16 + 16;
+}
+
+call_ref(ref_output, 16, input, qmatrix, 10, 4);
+call_new(new_output, 16, input, qmatrix, 10, 4);
+
+for (int i = 0; i < 64; i++) {
+if (ref_output[i] != new_output[i])
+fail();
+}
+
+bench_new(new_output, 16, input, qmatrix, 10, 4);
+}
+
+void checkasm_check_apv_dsp(void)
+{

[FFmpeg-devel] [PATCH] fftools/ffprobe: Print size of attachments

2025-04-19 Thread softworkz
From: softworkz 

libavformat/asfdec: Fix regression bug when reading image attachments
---
fftools/ffprobe: Print size of attachments

libavformat/asfdec: Fix regression bug when reading image attachments

Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-71%2Fsoftworkz%2Fsubmit_attachment_size-v1
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-71/softworkz/submit_attachment_size-v1
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/71

 doc/ffprobe.xsd   | 3 +++
 fftools/ffprobe.c | 4 
 2 files changed, 7 insertions(+)

diff --git a/doc/ffprobe.xsd b/doc/ffprobe.xsd
index b53b799227..8c2326e499 100644
--- a/doc/ffprobe.xsd
+++ b/doc/ffprobe.xsd
@@ -319,6 +319,9 @@
 
 
 
+
+
+
   
 
   
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index f5c83925b9..0da44b8c49 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -1847,6 +1847,10 @@ static int show_stream(AVTextFormatContext *tfc, 
AVFormatContext *fmt_ctx, int s
 else
 print_str_opt("height",  "N/A");
 break;
+
+case AVMEDIA_TYPE_ATTACHMENT:
+if (par->extradata_size)
+print_int("attachment_size", par->extradata_size);
 }
 
 if (show_private_data) {

base-commit: 7cd1edeaa410d977a9f1ff8436f480cb45b80178
-- 
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavformat/asfdec: Fix regression bug when reading image attachments

2025-04-19 Thread softworkz
From: softworkz 

Commit c8140fe7324f264faacf7395b27e12531d1f13f7 had introduced
a check for value_len > UINT16_MAX.
As a consequence, attached images of sizes larger than UINT16_MAX
could no longer be read.

This is a minimal fix of the regression, avoiding the controversies
of my earlier submission regarding int type handling in asfdec.

Signed-off-by: softworkz 
---
libavformat/asfdec: Fix regression bug when reading image attachments

Commit c8140fe7324f264faacf7395b27e12531d1f13f7 had introduced a check
for value_len > UINT16_MAX. As a consequence, attached images of sizes
larger than UINT16_MAX could no longer be read.

This is a minimal fix of the regression, avoiding the controversies of
my earlier submission regarding int type handling in asfdec.

Signed-off-by: softworkz softwo...@hotmail.com

Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-70%2Fsoftworkz%2Fsubmit_asf_attachments-v1
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-70/softworkz/submit_asf_attachments-v1
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/70

 libavformat/asfdec_f.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/asfdec_f.c b/libavformat/asfdec_f.c
index 2441cadb44..ef5e5696c8 100644
--- a/libavformat/asfdec_f.c
+++ b/libavformat/asfdec_f.c
@@ -608,7 +608,8 @@ static int asf_read_metadata(AVFormatContext *s)
 {
 AVIOContext *pb = s->pb;
 ASFContext *asf = s->priv_data;
-int n, stream_num, name_len_utf16, name_len_utf8, value_len;
+int n, stream_num, name_len_utf16, name_len_utf8;
+unsigned int value_len;
 int ret, i;
 n = avio_rl16(pb);
 
@@ -622,7 +623,7 @@ static int asf_read_metadata(AVFormatContext *s)
 value_type = avio_rl16(pb); /* value_type */
 value_len  = avio_rl32(pb);
 
-if (value_len < 0 || value_len > UINT16_MAX)
+if (value_len < 0 || value_len >= (INT_MAX - LEN) / 2)
 return AVERROR_INVALIDDATA;
 
 name_len_utf8 = 2*name_len_utf16 + 1;

base-commit: 7cd1edeaa410d977a9f1ff8436f480cb45b80178
-- 
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH] avformat/mov: Fix decoding fragmented MP4 with multiple sample entries and empty stsc

2025-04-19 Thread Dimitry Andric
On 10 Apr 2025, at 11:03, Dimitry Andric  wrote:
> 
> On 3 Apr 2025, at 22:02, Dimitry Andric  wrote:
>> 
>> When decoding fragmented MP4 files that have an empty stsc box, and
>> instead contain sample description indexes in their tfhd boxes, the mov
>> demuxer does not notify the decoder whenever the current sample
>> description index changes. If the SPS or PPS changed sufficiently, this
>> can lead to unexpected decoding errors.
>> 
>> To fix this, in mov_finalize_packet(), when stsc_data is not available,
>> use get_frag_stream_info_from_pkt() to get at the current fragment
>> stream info, and retrieve the current sample description index from
>> there. Then use that index in a similar manner as the stsc case.
>> 
>> Signed-off-by: Dimitry Andric 
>> ---
>> libavformat/mov.c | 50 ---
>> 1 file changed, 30 insertions(+), 20 deletions(-)
>> 
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index 452690090c..ead89192f4 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -10756,25 +10756,29 @@ static int mov_switch_root(AVFormatContext *s, 
>> int64_t target, int index)
>>return 1;
>> }
>> 
>> -static int mov_change_extradata(AVStream *st, AVPacket *pkt)
>> +static int mov_change_extradata(AVStream *st, AVPacket *pkt, int stsd_id)
>> {
>>MOVStreamContext *sc = st->priv_data;
>>uint8_t *side, *extradata;
>>int extradata_size;
>> 
>> -/* Save the current index. */
>> -sc->last_stsd_index = sc->stsc_data[sc->stsc_index].id - 1;
>> +if (stsd_id > 0 &&
>> +stsd_id - 1 < sc->stsd_count &&
>> +stsd_id - 1 != sc->last_stsd_index) {
>> +/* Save the current index. */
>> +sc->last_stsd_index = stsd_id - 1;
>> 
>> -/* Notify the decoder that extradata changed. */
>> -extradata_size = sc->extradata_size[sc->last_stsd_index];
>> -extradata = sc->extradata[sc->last_stsd_index];
>> -if (st->discard != AVDISCARD_ALL && extradata_size > 0 && extradata) {
>> -side = av_packet_new_side_data(pkt,
>> -   AV_PKT_DATA_NEW_EXTRADATA,
>> -   extradata_size);
>> -if (!side)
>> -return AVERROR(ENOMEM);
>> -memcpy(side, extradata, extradata_size);
>> +/* Notify the decoder that extradata changed. */
>> +extradata_size = sc->extradata_size[sc->last_stsd_index];
>> +extradata = sc->extradata[sc->last_stsd_index];
>> +if (st->discard != AVDISCARD_ALL && extradata_size > 0 && 
>> extradata) {
>> +side = av_packet_new_side_data(pkt,
>> +   AV_PKT_DATA_NEW_EXTRADATA,
>> +   extradata_size);
>> +if (!side)
>> +return AVERROR(ENOMEM);
>> +memcpy(side, extradata, extradata_size);
>> +}
>>}
>> 
>>return 0;
>> @@ -10893,13 +10897,10 @@ static int mov_finalize_packet(AVFormatContext *s, 
>> AVStream *st, AVIndexEntry *s
>> 
>>/* Multiple stsd handling. */
>>if (sc->stsc_data) {
>> -if (sc->stsc_data[sc->stsc_index].id > 0 &&
>> -sc->stsc_data[sc->stsc_index].id - 1 < sc->stsd_count &&
>> -sc->stsc_data[sc->stsc_index].id - 1 != sc->last_stsd_index) {
>> -int ret = mov_change_extradata(st, pkt);
>> -if (ret < 0)
>> -return ret;
>> -}
>> +int stsd_id = sc->stsc_data[sc->stsc_index].id;
>> +int ret = mov_change_extradata(st, pkt, stsd_id);
>> +if (ret < 0)
>> +return ret;
>> 
>>/* Update the stsc index for the next sample */
>>sc->stsc_sample++;
>> @@ -10908,6 +10909,15 @@ static int mov_finalize_packet(AVFormatContext *s, 
>> AVStream *st, AVIndexEntry *s
>>sc->stsc_index++;
>>sc->stsc_sample = 0;
>>}
>> +} else {
>> +MOVContext *mov = s->priv_data;
>> +MOVFragmentStreamInfo *frag_stream_info = 
>> get_frag_stream_info_from_pkt(&mov->frag_index, pkt, sc->id);
>> +if (frag_stream_info) {
>> +int stsd_id = frag_stream_info->stsd_id;
>> +int ret = mov_change_extradata(st, pkt, stsd_id);
>> +if (ret < 0)
>> +return ret;
>> +}
>>}
>> 
>>return 0;
>> -- 
>> 2.43.0
>> 
> 
> Any comments on this patch?

Ping :)

-Dimitry

___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavutil: Add AVMap

2025-04-19 Thread Michael Niedermayer
Hi Leo

On Sat, Apr 19, 2025 at 06:36:56AM -0400, Leo Izen wrote:
> On 4/17/25 12:52, Michael Niedermayer wrote:
[...]
> > +typedef struct{
> > +AVMapEntry map_entry;
> > +uint8_t treenode_and_keyvalue[0];
> > +} AVMapInternalEntry;
> > +
> > +struct AVMap{
> > +#define CMP_MASK 31
> > +AVMapCompareFunc cmp[27];
> > +AVMapCopyFunc copy;
> > +AVMapFreeFunc freef;
> > +int count;
> > +int deleted;
> > +int next;   ///< index of entry in root array after 
> > all used entries
> 
> Indices into arrays and counts and the like should be size_t.

I guess AVMap will be one of the first parts of FFmpeg doing that

git grep 'int count' | wc
3542493   27289
git grep 'size_t count' | wc
  2   8  97

git grep 'int [a-zA-Z_]*index' | wc
   12797735   94963
git grep 'size_t [a-zA-Z_]*index' | wc
 29 1181888

also we use av_fast_realloc() which doesnt use size_t
and av_map_realloc() must return a signed value to allow error codes so it will 
use int64_t not size_t


> 
> > +unsigned internal_entries_len;
> > +AVTreeNode *tree_root;
> > +AVMapInternalEntry *internal_entries;
> > +};
> > +
> > +static uint8_t deleted_entry;
> 
> static const should allow the compiler to put it in a different section if
> it wishes. You can still address it even then.

I dont want to put it in a different section. Its value should be available
with a minimum of computation.


[...]
> > +int av_map_add_cmp_func(AVMap *m, AVMapCompareFunc cmp, int cmp_flags)
> > +{
> > +static const uint8_t sensitivity[27][3] = {
> > +{0,0, 0},{1,0, 0},{2,0, 0}, {0,3, 0},{1,3, 0},{2,3, 0}, {0,6, 
> > 0},{1,6, 0},{2,6, 0},
> > +{0,0, 9},{1,0, 9},{2,0, 9}, {0,3, 9},{1,3, 9},{2,3, 9}, {0,6, 
> > 9},{1,6, 9},{2,6, 9},
> > +{0,0,18},{1,0,18},{2,0,18}, {0,3,18},{1,3,18},{2,3,18}, 
> > {0,6,18},{1,6,18},{2,6,18},};
> > +int case_sensitive   =  sensitivity[cmp_flags][0];
> > +int keyvalue_sensitive   =  sensitivity[cmp_flags][1];
> > +int truncated_sensitive  =  sensitivity[cmp_flags][2];
> > +
> > +if (!keyvalue_sensitive || !truncated_sensitive || cmp_flags >= 27U)
> > +return AVERROR(EINVAL);
> 
> Need to check for cmp_flags >= 27U before indexing into the array. The

ok


> compiler may pull this array off the stack cause it's static const so you
> risk hitting a dead page here.

printf("A"+5) also might hit a dead page, the user is not supposed to input
invalid data, and theres no gurantee that passing invalid data will not crash


[...]
> > +AVMap *av_map_new(AVMapCompareFunc cmp_keyvalue, int cmp_flags, 
> > AVMapCopyFunc copy, AVMapFreeFunc freef)
> > +{
> > +AVMap *s = av_mallocz(sizeof(*s));
> > +if (!s)
> > +return NULL;
> > +
> > +s->copy  = copy;
> > +s->freef = freef;
> > +
> > +av_map_add_cmp_func(s, cmp_keyvalue, cmp_flags);
> 
> No check for return value. av_map_add_cmp_func can return AVERROR(EINVAL)
> depending on cmp_flags.

indeed, i missed that, good find


[...]
> > +return advance;
> > +}
> > +
> > +int av_map_add(AVMap *s, const char *key, int keylen, const char *value, 
> > int valuelen, int flags)
> > +{
> > +av_assert2(keylen || valuelen); // patch welcome but how would the 
> > compare function compare a len=0 element without knowing it is a len 0 
> > element
> > +
> 
> This is a public function so we should be returning AVERROR(EINVAL) on
> invalid input rather than asserting. Since a library user could do that.

Its a speed relevent function
testing for the caller to do something stupid is not its job
The assert helps the user to find such a mistake


[...]
> > +int av_map_copy(AVMap *dst, const AVMap *src)
> > +{
> > +const AVMapEntry *t = NULL;
> > +AVMap *bak = av_memdup(dst, sizeof(*dst));
> > +if (!bak)
> > +return AVERROR(ENOMEM);
> > +
> > +AVMapInternalEntry *new_internal_entries = 
> > av_memdup(bak->internal_entries, bak->internal_entries_len);
> > +AVMapInternalEntry *old_internal_entries = dst->internal_entries;
> 
> We don't allow mixed delcarations and statements. Hoist the defintion above
> if (!bak) and then put the assignment below it.

commit 890b8da1ce27fd365eaffefc7efcbadae9f01f2a

configure: Allow mixing declarations and statements


> 
> > +
> > +while ((t = av_map_iterate(src, t))) {
> > +int ret = av_map_add(dst, t->key, t->keylen, t->value, 
> > t->valuelen, 0);
> > +
> > +if (ret < 0) {
> > +update_pointers(bak, new_internal_entries, 
> > old_internal_entries);
> > +av_free(dst->internal_entries);
> > +memcpy(dst, bak, sizeof(*dst));
> > +return ret;
> 
> You leak bak here. Possibly new_internal_entries as well.

fixed


[...]
> > +typedef struct AVMapEntry {
> > +uint8_t *key;
> > +uint8_t *value;
> 
> Any particular reason to use unsigned char here rather than just char when
> working with strings? Most

[FFmpeg-devel] [PATCH] avformat/mpegts: update stream info when PMT ES stream_type changes

2025-04-19 Thread Pavel Koshevoy
I have a couple of .ts captures where video and audio codec changes
even though the PMT version does not change and the PIDs stay the same.
---
 libavformat/mpegts.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 54594b3a11..8a72d6988a 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2508,7 +2508,7 @@ static void pmt_cb(MpegTSFilter *filter, const uint8_t 
*section, int section_len
 if (!st)
 goto out;
 
-if (pes && !pes->stream_type)
+if (pes && pes->stream_type != stream_type)
 mpegts_set_stream_info(st, pes, stream_type, prog_reg_desc);
 
 add_pid_to_program(prg, pid);
-- 
2.43.0

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

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


[FFmpeg-devel] [PATCH] avcodec/vulkan_{av1, h264, hevc}: demote per frame logs to AV_LOG_DEBUG

2025-04-19 Thread llyyr
Matches vaapi and software decoding behavior

Signed-off-by: llyyr 
---
 libavcodec/vulkan_av1.c  | 2 +-
 libavcodec/vulkan_h264.c | 2 +-
 libavcodec/vulkan_hevc.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vulkan_av1.c b/libavcodec/vulkan_av1.c
index 0e5958b20b48..6a6ca56783e4 100644
--- a/libavcodec/vulkan_av1.c
+++ b/libavcodec/vulkan_av1.c
@@ -626,7 +626,7 @@ static int vk_av1_end_frame(AVCodecContext *avctx)
 rav[i] = ap->ref_src[i]->f;
 }
 
-av_log(avctx, AV_LOG_VERBOSE, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i 
tiles\n",
+av_log(avctx, AV_LOG_DEBUG, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i 
tiles\n",
vp->slices_size, ap->av1_pic_info.tileCount);
 
 return ff_vk_decode_frame(avctx, pic->f, vp, rav, rvp);
diff --git a/libavcodec/vulkan_h264.c b/libavcodec/vulkan_h264.c
index 2ac031c00997..09f394dacf98 100644
--- a/libavcodec/vulkan_h264.c
+++ b/libavcodec/vulkan_h264.c
@@ -556,7 +556,7 @@ static int vk_h264_end_frame(AVCodecContext *avctx)
 rav[i] = hp->ref_src[i]->f;
 }
 
-av_log(avctx, AV_LOG_VERBOSE, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i 
slices\n",
+av_log(avctx, AV_LOG_DEBUG, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i 
slices\n",
vp->slices_size, hp->h264_pic_info.sliceCount);
 
 return ff_vk_decode_frame(avctx, pic->f, vp, rav, rvp);
diff --git a/libavcodec/vulkan_hevc.c b/libavcodec/vulkan_hevc.c
index 4b10da65a068..78ad8333088e 100644
--- a/libavcodec/vulkan_hevc.c
+++ b/libavcodec/vulkan_hevc.c
@@ -921,7 +921,7 @@ static int vk_hevc_end_frame(AVCodecContext *avctx)
 rvp[i] = &rfhp->vp;
 }
 
-av_log(avctx, AV_LOG_VERBOSE, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i 
slices\n",
+av_log(avctx, AV_LOG_DEBUG, "Decoding frame, %"SIZE_SPECIFIER" bytes, %i 
slices\n",
vp->slices_size, hp->h265_pic_info.sliceSegmentCount);
 
 return ff_vk_decode_frame(avctx, pic->f, vp, rav, rvp);

base-commit: 5fc424c27cde3a86a335d41df4939d183775c4ca
-- 
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".


Re: [FFmpeg-devel] [PATCH 2/3] doc/dict2: Add doc and api change for AVDictionary2

2025-04-19 Thread softworkz .



> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Samstag, 19. April 2025 04:29
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/3] doc/dict2: Add doc and api
> change for AVDictionary2
> 
> Hi
> 
> On Thu, Apr 17, 2025 at 10:38:32PM +, softworkz . wrote:
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> [...]
> > > the LLM would probably mix and confuse things and hallucinate
> > > a lot of nonsense.
> >
> > That's less of a problem meanwhile as the available context
> > windows have increased and operating on trac ticket discussions
> > does not create such long conversations where the context
> > window overflows and important parts fall off.
> > Some care might only need to be taken for that it doesn't ingest
> > really large log outputs as are sometimes included in the tickets.
> >
> > At this time, it would be still too bold to let it work fully
> > autonomously, but that's not necessary because its
> > operations could be easily arbitrated by conventional logic.
> >
> > It could be controlled by a set of tags - something like:
> >
> > - tracbot-error
> > - tracbot-inconclusive
> > - tracbot-needs-manual-review
> > - tracbot-awaiting-user-response
> > - tracbot-reproduced-in-master
> > - tracbot-fixed-in-master
> >
> > Then, a scheduler service would run over all open issues and
> > invoke the AI on it (see below).
> >
> > The scheduler would exclude tickets which already have one of
> > those tags assigned.
> > Additionally, it would include tickets that are tagged with
> > "tracbot-awaiting-user-response" and have been updated since
> > the tag was assigned.
> >
> >
> > When the AI is invoked on a ticked, it has clear instructions
> > to follow. The primary directive is to reproduce the reported
> > issue. If the specified information is unclear or incomplete
> > or when no test file is provided, it posts a message, asking
> > for the missing information and applies the awaiting-user-response
> > tag.
> >
> > The AI would have an execution environment in a Docker
> > container where it has access to a library with daily builds
> > from the past 5 years.
> > If the issue doesn't reproduce with the latest daily build,
> > it adds the tracbot-fixed-in-master tag.
> >
> > If it can be reproduced with the latest build, it "bisects"
> > the issue using the daily binaries.
> > It adds a message like: "Issue reproducible since version
> > 20xx-xx-xx and the tag tracbot-reproduced-in-master
> >
> > If it can't make sense of it, or is platform-specific or
> > needs certain hardware, or errors, it adds one of the
> > other tags.
> >
> > Some safeguards must be added to avoid anybody getting
> > into a longer chat with it (always ending with
> > awaiting-user-response), but otherwise, I don't think
> > that there's much that can go wrong.
> >
> > A mailing list could be set up, to which it reports it
> > operations, and where interested members (or anybody)
> > can subscribe to. This would provide a kind of real-time
> > monitoring by the community.
> >
> >
> > All-in-all I think it's well doable.
> >
> > Unfortunately though, I cannot spend that much time.
> > Perhaps a candidate for GSoC?
> 
> GsoC would need a mentor and a student/contributor wanting to work on
> this.
> Also this would need someone (ideally either the mentor or
> contributor)
> willing to maintain it after GSoC
> 
> And it would not surprise me if its more work for us to do this in
> GSoC
> than just do it ourselfs.


Hi Michael,


yea, that's also one of the reasons why I'm not considering myself as a 
good teacher: I use to think that I'll be able to get it done by myself
even before I'm done explaining to someone else.

The other day I had let the same setup like for the dictionary run on 
it, and it struggled, saying it cannot get past the "Anubis" bot 
protection on trac.ffmpeg.org. Is that right, do we have that kind of
protection for the trac server? If yes, is there another way to access
the trac site via API?

After it couldn't access it, it started writing code to just "mock" the
API access and when I forbid that, it resorted to a browser automation
approach (via Puppeteer) but that's suboptimal of course, even though
it succeeded in retrieving ticket content.

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 3/6] lavc/cbs: APV support

2025-04-19 Thread Mark Thompson
---
 configure|   1 +
 libavcodec/Makefile  |   1 +
 libavcodec/apv.h |  86 
 libavcodec/cbs.c |   6 +
 libavcodec/cbs_apv.c | 395 ++
 libavcodec/cbs_apv.h | 209 ++
 libavcodec/cbs_apv_syntax_template.c | 598 +++
 libavcodec/cbs_internal.h|   4 +
 libavformat/cbs.h|   1 +
 9 files changed, 1301 insertions(+)
 create mode 100644 libavcodec/apv.h
 create mode 100644 libavcodec/cbs_apv.c
 create mode 100644 libavcodec/cbs_apv.h
 create mode 100644 libavcodec/cbs_apv_syntax_template.c

diff --git a/configure b/configure
index c94b8eac43..ca404d2797 100755
--- a/configure
+++ b/configure
@@ -2562,6 +2562,7 @@ CONFIG_EXTRA="
 bswapdsp
 cabac
 cbs
+cbs_apv
 cbs_av1
 cbs_h264
 cbs_h265
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 7bd1dbec9a..a5f5c4e904 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -83,6 +83,7 @@ OBJS-$(CONFIG_BLOCKDSP)+= blockdsp.o
 OBJS-$(CONFIG_BSWAPDSP)+= bswapdsp.o
 OBJS-$(CONFIG_CABAC)   += cabac.o
 OBJS-$(CONFIG_CBS) += cbs.o cbs_bsf.o
+OBJS-$(CONFIG_CBS_APV) += cbs_apv.o
 OBJS-$(CONFIG_CBS_AV1) += cbs_av1.o
 OBJS-$(CONFIG_CBS_H264)+= cbs_h2645.o cbs_sei.o h2645_parse.o
 OBJS-$(CONFIG_CBS_H265)+= cbs_h2645.o cbs_sei.o h2645_parse.o
diff --git a/libavcodec/apv.h b/libavcodec/apv.h
new file mode 100644
index 00..27e089ea22
--- /dev/null
+++ b/libavcodec/apv.h
@@ -0,0 +1,86 @@
+/*
+ * 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
+ */
+
+#ifndef AVCODEC_APV_H
+#define AVCODEC_APV_H
+
+// PBU types (section 5.3.3).
+enum {
+APV_PBU_PRIMARY_FRAME   = 1,
+APV_PBU_NON_PRIMARY_FRAME   = 2,
+APV_PBU_PREVIEW_FRAME   = 25,
+APV_PBU_DEPTH_FRAME = 26,
+APV_PBU_ALPHA_FRAME = 27,
+APV_PBU_ACCESS_UNIT_INFORMATION = 65,
+APV_PBU_METADATA= 66,
+APV_PBU_FILLER  = 67,
+};
+
+// Format parameters (section 4.2).
+enum {
+APV_MAX_NUM_COMP = 4,
+APV_MB_WIDTH = 16,
+APV_MB_HEIGHT= 16,
+APV_TR_SIZE  = 8,
+};
+
+// Chroma formats (section 4.2).
+enum {
+APV_CHROMA_FORMAT_400  = 0,
+APV_CHROMA_FORMAT_422  = 2,
+APV_CHROMA_FORMAT_444  = 3,
+APV_CHROMA_FORMAT_ = 4,
+};
+
+// Coefficient limits (section 5.3.15).
+enum {
+APV_BLK_COEFFS  = (APV_TR_SIZE * APV_TR_SIZE),
+APV_MIN_TRANS_COEFF = -32768,
+APV_MAX_TRANS_COEFF =  32767,
+};
+
+// Profiles (section 10.1.3).
+enum {
+APV_PROFILE_422_10  = 33,
+APV_PROFILE_422_12  = 44,
+APV_PROFILE_444_10  = 55,
+APV_PROFILE_444_12  = 66,
+APV_PROFILE__10 = 77,
+APV_PROFILE__12 = 88,
+APV_PROFILE_400_10  = 99,
+};
+
+// General level limits for tiles (section 10.1.4.1).
+enum {
+APV_MIN_TILE_WIDTH_IN_MBS  = 16,
+APV_MIN_TILE_HEIGHT_IN_MBS = 8,
+APV_MAX_TILE_COLS  = 20,
+APV_MAX_TILE_ROWS  = 20,
+APV_MAX_TILE_COUNT = APV_MAX_TILE_COLS * APV_MAX_TILE_ROWS,
+};
+
+// Metadata types (section 10.3.1).
+enum {
+APV_METADATA_ITU_T_T35= 4,
+APV_METADATA_MDCV = 5,
+APV_METADATA_CLL  = 6,
+APV_METADATA_FILLER   = 10,
+APV_METADATA_USER_DEFINED = 170,
+};
+
+#endif /* AVCODEC_APV_H */
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index ba1034a72e..9b485420d5 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -31,6 +31,9 @@
 
 
 static const CodedBitstreamType *const cbs_type_table[] = {
+#if CBS_APV
+&CBS_FUNC(type_apv),
+#endif
 #if CBS_AV1
 &CBS_FUNC(type_av1),
 #endif
@@ -58,6 +61,9 @@ static const CodedBitstreamType *const cbs_type_table[] = {
 };
 
 const enum AVCodecID CBS_FUNC(all_codec_ids)[] = {
+#if CBS_APV
+AV_CODEC_ID_APV,
+#endif
 #if CBS_AV1
 AV_CODEC_ID_AV1,
 #endif
diff --git a/libavcodec/cbs_apv.c b/libavcodec/cbs_apv.c
new file mode 100644
index 00..c37124168a
--- /dev/null
+++ b/libavcodec/cbs_apv.c
@@ -0,0 +1,395 @@
+/*
+ * This file is part of FFmpeg.

[FFmpeg-devel] [PATCH 0/6] APV support

2025-04-19 Thread Mark Thompson
Hi all,

This set implements some support for APV.  APV is "Advanced Professional 
Video", yet another JPEG knockoff codec being promoted by Samsung for 
professional applications.  It seems to have some adoption for Android devices, 
though it's unclear to what degree that will succeed.

Spec: 
Reference codec: 

Included is:
* Demuxer for flat files as defined in the spec.
* CBS support for read/write, including all of the metadata.
* Decoder.
* AVX2 asm for the decoder to make it faster on all recent x86-64 devices.
* Metadata filer, since that comes pretty much for free with the CBS support.

This decoder is slightly faster than the reference decoder for single-thread 
and much faster for many-thread (mostly because of frame threading support).

Test coverage on this is all rather spotty: the decoder is bit-exact with the 
reference decoder output and I've tried to test the components standalone, but 
lack of a good suite of test inputs means there is probably something missing.

Further things which I am currently thinking about:
* Encoder - bad encoder is trivial, but I'd like to do better than that.
* Better AVX asm - the transform has useful substructure which I am currently 
ignoring in favour of a brute force matrix multiply, there is probably some 
gain to be had there.
* Transformation BSF - the format allows some lossless transformations like 
rotate which would make a cute BSF.

Other things which I am not currently doing which other people may be 
interested in:
* Non-AVX asm.  SSE is possible but will be bitten by lack of registers given 
all the 8-wide 32-bit intermediates.  Haven't thought at all about non-x86.
* ISOBMFF: 
.
* MKV/WebM is presumably going to be a thing since this seems to be adopted by 
Android things?
* RTP if you really want it 
.

Thanks,

- Mark

Mark Thompson (6):
  lavc: APV codec ID and descriptor
  lavf: APV demuxer
  lavc/cbs: APV support
  lavc: APV decoder
  lavc/apv: AVX2 transquant for x86-64
  lavc: APV metadata bitstream filter

 configure|   2 +
 libavcodec/Makefile  |   2 +
 libavcodec/allcodecs.c   |   1 +
 libavcodec/apv.h |  86 
 libavcodec/apv_decode.c  | 327 +++
 libavcodec/apv_decode.h  |  80 
 libavcodec/apv_dsp.c | 140 +++
 libavcodec/apv_dsp.h |  39 ++
 libavcodec/apv_entropy.c | 200 +
 libavcodec/bitstream_filters.c   |   1 +
 libavcodec/bsf/Makefile  |   1 +
 libavcodec/bsf/apv_metadata.c| 134 ++
 libavcodec/cbs.c |   6 +
 libavcodec/cbs_apv.c | 395 ++
 libavcodec/cbs_apv.h | 209 ++
 libavcodec/cbs_apv_syntax_template.c | 598 +++
 libavcodec/cbs_internal.h|   4 +
 libavcodec/codec_desc.c  |   7 +
 libavcodec/codec_id.h|   1 +
 libavcodec/x86/Makefile  |   2 +
 libavcodec/x86/apv_dsp.asm   | 243 +++
 libavcodec/x86/apv_dsp_init.c|  41 ++
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/apvdec.c | 245 +++
 libavformat/cbs.h|   1 +
 tests/checkasm/Makefile  |   1 +
 tests/checkasm/apv_dsp.c | 113 +
 tests/checkasm/checkasm.c|   3 +
 tests/checkasm/checkasm.h|   1 +
 30 files changed, 2885 insertions(+)
 create mode 100644 libavcodec/apv.h
 create mode 100644 libavcodec/apv_decode.c
 create mode 100644 libavcodec/apv_decode.h
 create mode 100644 libavcodec/apv_dsp.c
 create mode 100644 libavcodec/apv_dsp.h
 create mode 100644 libavcodec/apv_entropy.c
 create mode 100644 libavcodec/bsf/apv_metadata.c
 create mode 100644 libavcodec/cbs_apv.c
 create mode 100644 libavcodec/cbs_apv.h
 create mode 100644 libavcodec/cbs_apv_syntax_template.c
 create mode 100644 libavcodec/x86/apv_dsp.asm
 create mode 100644 libavcodec/x86/apv_dsp_init.c
 create mode 100644 libavformat/apvdec.c
 create mode 100644 tests/checkasm/apv_dsp.c

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

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


[FFmpeg-devel] [PATCH 2/6] lavf: APV demuxer

2025-04-19 Thread Mark Thompson
Demuxes raw streams as defined in draft spec section 10.2.
---
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/apvdec.c | 245 +++
 3 files changed, 247 insertions(+)
 create mode 100644 libavformat/apvdec.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index a94ac66e7e..ef96c2762e 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -119,6 +119,7 @@ OBJS-$(CONFIG_APTX_DEMUXER)  += aptxdec.o
 OBJS-$(CONFIG_APTX_MUXER)+= rawenc.o
 OBJS-$(CONFIG_APTX_HD_DEMUXER)   += aptxdec.o
 OBJS-$(CONFIG_APTX_HD_MUXER) += rawenc.o
+OBJS-$(CONFIG_APV_DEMUXER)   += apvdec.o
 OBJS-$(CONFIG_AQTITLE_DEMUXER)   += aqtitledec.o subtitles.o
 OBJS-$(CONFIG_ARGO_ASF_DEMUXER)  += argo_asf.o
 OBJS-$(CONFIG_ARGO_ASF_MUXER)+= argo_asf.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 445f13f42a..90a4fe64ec 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -72,6 +72,7 @@ extern const FFInputFormat  ff_aptx_demuxer;
 extern const FFOutputFormat ff_aptx_muxer;
 extern const FFInputFormat  ff_aptx_hd_demuxer;
 extern const FFOutputFormat ff_aptx_hd_muxer;
+extern const FFInputFormat  ff_apv_demuxer;
 extern const FFInputFormat  ff_aqtitle_demuxer;
 extern const FFInputFormat  ff_argo_asf_demuxer;
 extern const FFOutputFormat ff_argo_asf_muxer;
diff --git a/libavformat/apvdec.c b/libavformat/apvdec.c
new file mode 100644
index 00..008cbef708
--- /dev/null
+++ b/libavformat/apvdec.c
@@ -0,0 +1,245 @@
+/*
+ * 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 "libavcodec/apv.h"
+#include "libavcodec/get_bits.h"
+#include "avformat.h"
+#include "avio_internal.h"
+#include "demux.h"
+#include "internal.h"
+
+
+#define APV_TAG MKBETAG('a', 'P', 'v', '1')
+
+typedef struct APVHeaderInfo {
+uint8_t  pbu_type;
+uint16_t group_id;
+
+uint8_t  profile_idc;
+uint8_t  level_idc;
+uint8_t  band_idc;
+
+uint32_t frame_width;
+uint32_t frame_height;
+
+uint8_t  chroma_format_idc;
+uint8_t  bit_depth_minus8;
+
+enum AVPixelFormat pixel_format;
+} APVHeaderInfo;
+
+static const enum AVPixelFormat apv_format_table[5][5] = {
+{ AV_PIX_FMT_GRAY8,AV_PIX_FMT_GRAY10, AV_PIX_FMT_GRAY12, 
AV_PIX_FMT_GRAY14, AV_PIX_FMT_GRAY16 },
+{ 0 }, // 4:2:0 is not valid.
+{ AV_PIX_FMT_YUV422P,  AV_PIX_FMT_YUV422P10,  AV_PIX_FMT_YUV422P12,  
AV_PIX_FMT_GRAY14, AV_PIX_FMT_YUV422P16 },
+{ AV_PIX_FMT_YUV444P,  AV_PIX_FMT_YUV444P10,  AV_PIX_FMT_YUV444P12,  
AV_PIX_FMT_GRAY14, AV_PIX_FMT_YUV444P16 },
+{ AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUVA444P10, AV_PIX_FMT_YUVA444P12, 
AV_PIX_FMT_GRAY14, AV_PIX_FMT_YUVA444P16 },
+};
+
+static int apv_extract_header_info(APVHeaderInfo *info,
+   GetBitContext *gbc)
+{
+int zero, bit_depth_index;
+
+info->pbu_type = get_bits(gbc, 8);
+info->group_id = get_bits(gbc, 16);
+
+zero = get_bits(gbc, 8);
+if (zero != 0)
+return 0;
+
+if (info->pbu_type != APV_PBU_PRIMARY_FRAME)
+return 0;
+
+info->profile_idc = get_bits(gbc, 8);
+info->level_idc   = get_bits(gbc, 8);
+info->band_idc= get_bits(gbc, 3);
+
+zero = get_bits(gbc, 5);
+if (zero != 0)
+return 0;
+
+info->frame_width  = get_bits(gbc, 24);
+info->frame_height = get_bits(gbc, 24);
+if (info->frame_width  < 1 || info->frame_width  > 65536 ||
+info->frame_height < 1 || info->frame_height > 65536)
+return 0;
+
+info->chroma_format_idc = get_bits(gbc, 4);
+info->bit_depth_minus8  = get_bits(gbc, 4);
+
+if (info->bit_depth_minus8 > 8) {
+return 0;
+}
+if (info->bit_depth_minus8 % 2) {
+// Odd bit depths are technically valid but not useful here.
+return 0;
+}
+bit_depth_index = info->bit_depth_minus8 / 2;
+
+switch (info->chroma_format_idc) {
+case APV_CHROMA_FORMAT_400:
+case APV_CHROMA_FORMAT_422:
+case APV_CHROMA_FORMAT_444:
+case APV_CHROMA_FORMAT_:
+info->pixel_format = 
apv_format_table[info->chroma_format_idc][bit_depth_index];
+break;
+default:
+   

[FFmpeg-devel] [PATCH 4/6] lavc: APV decoder

2025-04-19 Thread Mark Thompson
---
 configure|   1 +
 libavcodec/Makefile  |   1 +
 libavcodec/allcodecs.c   |   1 +
 libavcodec/apv_decode.c  | 327 +++
 libavcodec/apv_decode.h  |  80 ++
 libavcodec/apv_dsp.c | 136 
 libavcodec/apv_dsp.h |  37 +
 libavcodec/apv_entropy.c | 200 
 8 files changed, 783 insertions(+)
 create mode 100644 libavcodec/apv_decode.c
 create mode 100644 libavcodec/apv_decode.h
 create mode 100644 libavcodec/apv_dsp.c
 create mode 100644 libavcodec/apv_dsp.h
 create mode 100644 libavcodec/apv_entropy.c

diff --git a/configure b/configure
index ca404d2797..ee270b770c 100755
--- a/configure
+++ b/configure
@@ -2935,6 +2935,7 @@ apng_decoder_select="inflate_wrapper"
 apng_encoder_select="deflate_wrapper llvidencdsp"
 aptx_encoder_select="audio_frame_queue"
 aptx_hd_encoder_select="audio_frame_queue"
+apv_decoder_select="cbs_apv"
 asv1_decoder_select="blockdsp bswapdsp idctdsp"
 asv1_encoder_select="aandcttables bswapdsp fdctdsp pixblockdsp"
 asv2_decoder_select="blockdsp bswapdsp idctdsp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a5f5c4e904..e674671460 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -244,6 +244,7 @@ OBJS-$(CONFIG_APTX_HD_DECODER) += aptxdec.o aptx.o
 OBJS-$(CONFIG_APTX_HD_ENCODER) += aptxenc.o aptx.o
 OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
 OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
+OBJS-$(CONFIG_APV_DECODER) += apv_decode.o apv_entropy.o apv_dsp.o
 OBJS-$(CONFIG_ARBC_DECODER)+= arbc.o
 OBJS-$(CONFIG_ARGO_DECODER)+= argo.o
 OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f10519617e..09f06c71d6 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -47,6 +47,7 @@ extern const FFCodec ff_anm_decoder;
 extern const FFCodec ff_ansi_decoder;
 extern const FFCodec ff_apng_encoder;
 extern const FFCodec ff_apng_decoder;
+extern const FFCodec ff_apv_decoder;
 extern const FFCodec ff_arbc_decoder;
 extern const FFCodec ff_argo_decoder;
 extern const FFCodec ff_asv1_encoder;
diff --git a/libavcodec/apv_decode.c b/libavcodec/apv_decode.c
new file mode 100644
index 00..066b5a9735
--- /dev/null
+++ b/libavcodec/apv_decode.c
@@ -0,0 +1,327 @@
+/*
+ * 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/mem_internal.h"
+
+#include "apv.h"
+#include "apv_decode.h"
+#include "apv_dsp.h"
+#include "avcodec.h"
+#include "cbs.h"
+#include "cbs_apv.h"
+#include "codec_internal.h"
+#include "decode.h"
+#include "thread.h"
+
+
+typedef struct APVDecodeContext {
+CodedBitstreamContext *cbc;
+APVDSPContext dsp;
+
+CodedBitstreamFragment au;
+APVDerivedTileInfo tile_info;
+
+APVVLCLUT decode_lut;
+
+AVFrame *output_frame;
+} APVDecodeContext;
+
+static const enum AVPixelFormat apv_format_table[5][5] = {
+{ AV_PIX_FMT_GRAY8,AV_PIX_FMT_GRAY10, AV_PIX_FMT_GRAY12, 
AV_PIX_FMT_GRAY14, AV_PIX_FMT_GRAY16 },
+{ 0 }, // 4:2:0 is not valid.
+{ AV_PIX_FMT_YUV422P,  AV_PIX_FMT_YUV422P10,  AV_PIX_FMT_YUV422P12,  
AV_PIX_FMT_GRAY14, AV_PIX_FMT_YUV422P16 },
+{ AV_PIX_FMT_YUV444P,  AV_PIX_FMT_YUV444P10,  AV_PIX_FMT_YUV444P12,  
AV_PIX_FMT_GRAY14, AV_PIX_FMT_YUV444P16 },
+{ AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUVA444P10, AV_PIX_FMT_YUVA444P12, 
AV_PIX_FMT_GRAY14, AV_PIX_FMT_YUVA444P16 },
+};
+
+static int apv_decode_check_format(AVCodecContext *avctx,
+   const APVRawFrameHeader *header)
+{
+int err, bit_depth;
+
+avctx->profile = header->frame_info.profile_idc;
+avctx->level   = header->frame_info.level_idc;
+
+bit_depth = header->frame_info.bit_depth_minus8 + 8;
+if (bit_depth < 8 || bit_depth > 16 || bit_depth % 2) {
+avpriv_request_sample(avctx, "Bit depth %d", bit_depth);
+return AVERROR_PATCHWELCOME;
+}
+avctx->pix_fmt =
+apv_format_table[header->frame_info.chroma_format_idc][bit_depth - 4 
>> 2];
+
+err = ff_set_dimensions(avctx,
+FFALIGN(header->frame_info.frame_width,  16),
+FFALI

[FFmpeg-devel] [PATCH 5/6] lavc/apv: AVX2 transquant for x86-64

2025-04-19 Thread Mark Thompson
Typical checkasm result on Alder Lake:

decode_transquant_8_c: 408.7 ( 1.00x)
decode_transquant_8_avx2:   94.2 ( 4.34x)
decode_transquant_10_c:413.1 ( 1.00x)
decode_transquant_10_avx2:  87.5 ( 4.72x)
---
 libavcodec/apv_dsp.c  |   4 +
 libavcodec/apv_dsp.h  |   2 +
 libavcodec/x86/Makefile   |   2 +
 libavcodec/x86/apv_dsp.asm| 243 ++
 libavcodec/x86/apv_dsp_init.c |  41 ++
 tests/checkasm/Makefile   |   1 +
 tests/checkasm/apv_dsp.c  | 113 
 tests/checkasm/checkasm.c |   3 +
 tests/checkasm/checkasm.h |   1 +
 9 files changed, 410 insertions(+)
 create mode 100644 libavcodec/x86/apv_dsp.asm
 create mode 100644 libavcodec/x86/apv_dsp_init.c
 create mode 100644 tests/checkasm/apv_dsp.c

diff --git a/libavcodec/apv_dsp.c b/libavcodec/apv_dsp.c
index 6b8b6ce590..108a3cd370 100644
--- a/libavcodec/apv_dsp.c
+++ b/libavcodec/apv_dsp.c
@@ -133,4 +133,8 @@ static void apv_decode_transquant_c(void *output,
 av_cold void ff_apv_dsp_init(APVDSPContext *dsp)
 {
 dsp->decode_transquant = apv_decode_transquant_c;
+
+#if ARCH_X86_64
+ff_apv_dsp_init_x86_64(dsp);
+#endif
 }
diff --git a/libavcodec/apv_dsp.h b/libavcodec/apv_dsp.h
index 13f401c4cc..a7b5377357 100644
--- a/libavcodec/apv_dsp.h
+++ b/libavcodec/apv_dsp.h
@@ -34,4 +34,6 @@ typedef struct APVDSPContext {
 
 void ff_apv_dsp_init(APVDSPContext *dsp);
 
+void ff_apv_dsp_init_x86_64(APVDSPContext *dsp);
+
 #endif /* AVCODEC_APV_DSP_H */
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 5d53515381..821c410a0f 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -44,6 +44,7 @@ OBJS-$(CONFIG_ADPCM_G722_DECODER)  += x86/g722dsp_init.o
 OBJS-$(CONFIG_ADPCM_G722_ENCODER)  += x86/g722dsp_init.o
 OBJS-$(CONFIG_ALAC_DECODER)+= x86/alacdsp_init.o
 OBJS-$(CONFIG_APNG_DECODER)+= x86/pngdsp_init.o
+OBJS-$(CONFIG_APV_DECODER) += x86/apv_dsp_init.o
 OBJS-$(CONFIG_CAVS_DECODER)+= x86/cavsdsp.o
 OBJS-$(CONFIG_CFHD_DECODER)+= x86/cfhddsp_init.o
 OBJS-$(CONFIG_CFHD_ENCODER)+= x86/cfhdencdsp_init.o
@@ -149,6 +150,7 @@ X86ASM-OBJS-$(CONFIG_ADPCM_G722_DECODER) += x86/g722dsp.o
 X86ASM-OBJS-$(CONFIG_ADPCM_G722_ENCODER) += x86/g722dsp.o
 X86ASM-OBJS-$(CONFIG_ALAC_DECODER) += x86/alacdsp.o
 X86ASM-OBJS-$(CONFIG_APNG_DECODER) += x86/pngdsp.o
+X86ASM-OBJS-$(CONFIG_APV_DECODER)  += x86/apv_dsp.o
 X86ASM-OBJS-$(CONFIG_CAVS_DECODER) += x86/cavsidct.o
 X86ASM-OBJS-$(CONFIG_CFHD_ENCODER) += x86/cfhdencdsp.o
 X86ASM-OBJS-$(CONFIG_CFHD_DECODER) += x86/cfhddsp.o
diff --git a/libavcodec/x86/apv_dsp.asm b/libavcodec/x86/apv_dsp.asm
new file mode 100644
index 00..0329089f45
--- /dev/null
+++ b/libavcodec/x86/apv_dsp.asm
@@ -0,0 +1,243 @@
+;
+;* 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
+;* 51, Inc., Foundation Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+;**
+
+%include "libavutil/x86/x86util.asm"
+
+SECTION .text
+
+align 32
+const tmatrixh
+dw  64,  89,  84,  75,  64,  50,  35,  18
+dw  64,  75,  35, -18, -64, -89, -84, -50
+dw  64,  50, -35, -89, -64,  18,  84,  75
+dw  64,  18, -84, -50,  64,  75, -35, -89
+dw  64, -18, -84,  50,  64, -75, -35,  89
+dw  64, -50, -35,  89, -64, -18,  84, -75
+dw  64, -75,  35,  18, -64,  89, -84,  50
+dw  64, -89,  84, -75,  64, -50,  35, -18
+const tmatrixv
+dw  64,  89,  84,  75,  64,  50,  35,  18
+dw  64, -18, -84,  50,  64, -75, -35,  89
+dw  64,  75,  35, -18, -64, -89, -84, -50
+dw  64, -50, -35,  89, -64, -18,  84, -75
+dw  64,  50, -35, -89, -64,  18,  84,  75
+dw  64, -75,  35,  18, -64,  89, -84,  50
+dw  64,  18, -84, -50,  64,  75, -35, -89
+dw  64, -89,  84, -75,  64, -50,  35, -18
+
+; Memory targets for vpbroadcastd (register version requires AVX512).
+const one
+dd   1
+const sixtyfour
+dd  64
+
+; void ff_apv_decode_transquant_avx2(void *output,
+;ptrdiff_t pitch,
+; 

[FFmpeg-devel] [PATCH 6/6] lavc: APV metadata bitstream filter

2025-04-19 Thread Mark Thompson
---
 libavcodec/bitstream_filters.c |   1 +
 libavcodec/bsf/Makefile|   1 +
 libavcodec/bsf/apv_metadata.c  | 134 +
 3 files changed, 136 insertions(+)
 create mode 100644 libavcodec/bsf/apv_metadata.c

diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index f923411bee..da9d0d2513 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -25,6 +25,7 @@
 #include "bsf_internal.h"
 
 extern const FFBitStreamFilter ff_aac_adtstoasc_bsf;
+extern const FFBitStreamFilter ff_apv_metadata_bsf;
 extern const FFBitStreamFilter ff_av1_frame_merge_bsf;
 extern const FFBitStreamFilter ff_av1_frame_split_bsf;
 extern const FFBitStreamFilter ff_av1_metadata_bsf;
diff --git a/libavcodec/bsf/Makefile b/libavcodec/bsf/Makefile
index 40b7fc6e9b..39ea091b50 100644
--- a/libavcodec/bsf/Makefile
+++ b/libavcodec/bsf/Makefile
@@ -2,6 +2,7 @@ clean::
$(RM) $(CLEANSUFFIXES:%=libavcodec/bsf/%)
 
 OBJS-$(CONFIG_AAC_ADTSTOASC_BSF)  += bsf/aac_adtstoasc.o
+OBJS-$(CONFIG_APV_METADATA_BSF)   += bsf/apv_metadata.o
 OBJS-$(CONFIG_AV1_FRAME_MERGE_BSF)+= bsf/av1_frame_merge.o
 OBJS-$(CONFIG_AV1_FRAME_SPLIT_BSF)+= bsf/av1_frame_split.o
 OBJS-$(CONFIG_AV1_METADATA_BSF)   += bsf/av1_metadata.o
diff --git a/libavcodec/bsf/apv_metadata.c b/libavcodec/bsf/apv_metadata.c
new file mode 100644
index 00..a1cdcf86c8
--- /dev/null
+++ b/libavcodec/bsf/apv_metadata.c
@@ -0,0 +1,134 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/common.h"
+#include "libavutil/opt.h"
+
+#include "bsf.h"
+#include "bsf_internal.h"
+#include "cbs.h"
+#include "cbs_bsf.h"
+#include "cbs_apv.h"
+
+typedef struct APVMetadataContext {
+CBSBSFContext common;
+
+int color_primaries;
+int transfer_characteristics;
+int matrix_coefficients;
+int full_range_flag;
+} APVMetadataContext;
+
+
+static int apv_metadata_update_frame_header(AVBSFContext *bsf,
+APVRawFrameHeader *hdr)
+{
+APVMetadataContext *ctx = bsf->priv_data;
+
+if (ctx->color_primaries >= 0  ||
+ctx->transfer_characteristics >= 0 ||
+ctx->matrix_coefficients >= 0  ||
+ctx->full_range_flag >= 0) {
+hdr->color_description_present_flag = 1;
+
+if (ctx->color_primaries >= 0)
+hdr->color_primaries = ctx->color_primaries;
+if (ctx->transfer_characteristics >= 0)
+hdr->transfer_characteristics = ctx->transfer_characteristics;
+if (ctx->matrix_coefficients >= 0)
+hdr->matrix_coefficients = ctx->matrix_coefficients;
+if (ctx->full_range_flag >= 0)
+hdr->full_range_flag = ctx->full_range_flag;
+}
+
+return 0;
+}
+
+static int apv_metadata_update_fragment(AVBSFContext *bsf, AVPacket *pkt,
+CodedBitstreamFragment *frag)
+{
+int err, i;
+
+for (i = 0; i < frag->nb_units; i++) {
+if (frag->units[i].type == APV_PBU_PRIMARY_FRAME) {
+APVRawFrame *pbu = frag->units[i].content;
+err = apv_metadata_update_frame_header(bsf, &pbu->frame_header);
+if (err < 0)
+return err;
+}
+}
+
+return 0;
+}
+
+static const CBSBSFType apv_metadata_type = {
+.codec_id= AV_CODEC_ID_APV,
+.fragment_name   = "access unit",
+.unit_name   = "PBU",
+.update_fragment = &apv_metadata_update_fragment,
+};
+
+static int apv_metadata_init(AVBSFContext *bsf)
+{
+return ff_cbs_bsf_generic_init(bsf, &apv_metadata_type);
+}
+
+#define OFFSET(x) offsetof(APVMetadataContext, x)
+#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_BSF_PARAM)
+static const AVOption apv_metadata_options[] = {
+{ "color_primaries", "Set color primaries (section 5.3.5)",
+OFFSET(color_primaries), AV_OPT_TYPE_INT,
+{ .i64 = -1 }, -1, 255, FLAGS },
+{ "transfer_characteristics", "Set transfer characteristics (section 
5.3.5)",
+OFFSET(transfer_characteristics), AV_OPT_TYPE_INT,
+{ .i64 = -1 }, -1, 255, FLAGS },
+{ "matrix_coefficients", "Set matrix coefficients (section 5.3.5)",
+OFFSET(matrix_coeffici

[FFmpeg-devel] [PATCH] rtpdec_vp9: Update header parsing to RFC 9628

2025-04-19 Thread Parallelc
Signed-off-by: Parallelc 
---
 libavformat/rtpdec_vp9.c | 141 ---
 1 file changed, 72 insertions(+), 69 deletions(-)

diff --git a/libavformat/rtpdec_vp9.c b/libavformat/rtpdec_vp9.c
index 6bbdf4847a..924065b5da 100644
--- a/libavformat/rtpdec_vp9.c
+++ b/libavformat/rtpdec_vp9.c
@@ -1,5 +1,5 @@
 /*
- * RTP parser for VP9 payload format (draft version 02) - experimental
+ * RTP parser for VP9 payload format (RFC 9628) - experimental
  * Copyright (c) 2015 Thomas Volkert 
  *
  * This file is part of FFmpeg.
@@ -47,8 +47,7 @@ static int vp9_handle_packet(AVFormatContext *ctx, 
PayloadContext *rtp_vp9_ctx,
 {
 int has_pic_id, has_layer_idc, has_ref_idc, has_ss_data;
 av_unused int pic_id = 0, non_key_frame = 0, inter_picture_layer_frame;
-av_unused int layer_temporal = -1, layer_spatial = -1, layer_quality = -1;
-int ref_fields = 0, has_ref_field_ext_pic_id = 0;
+av_unused int layer_temporal = -1, layer_spatial = -1;
 int first_fragment, last_fragment;
 int rtp_m;
 int res = 0;
@@ -68,16 +67,17 @@ static int vp9_handle_packet(AVFormatContext *ctx, 
PayloadContext *rtp_vp9_ctx,
  *
  *  0 1 2 3 4 5 6 7
  * +-+-+-+-+-+-+-+-+
- * |I|P|L|F|B|E|V|-| (REQUIRED)
+ * |I|P|L|F|B|E|V|Z| (REQUIRED)
  * +-+-+-+-+-+-+-+-+
  *
- * I: PictureID present
- * P: Inter-picture predicted layer frame
+ * I: Picture ID (PID) present
+ * P: Inter-picture predicted frame
  * L: Layer indices present
  * F: Flexible mode
- * B: Start of VP9 frame
- * E: End of picture
- * V: Scalability Structure (SS) present
+ * B: Start of Frame
+ * E: End of Frame
+ * V: Scalability Structure (SS) data present
+ * Z: Not a reference frame for upper spatial layers
  */
 has_pic_id = !!(buf[0] & 0x80);
 inter_picture_layer_frame = !!(buf[0] & 0x40);
@@ -89,7 +89,7 @@ static int vp9_handle_packet(AVFormatContext *ctx, 
PayloadContext *rtp_vp9_ctx,
 
 rtp_m = !!(flags & RTP_FLAG_MARKER);
 
-/* sanity check for markers: B should always be equal to the RTP M marker 
*/
+/* sanity check for markers: E should always be equal to the RTP M marker 
*/
 if (last_fragment != rtp_m) {
 av_log(ctx, AV_LOG_ERROR, "Invalid combination of B and M marker (%d 
!= %d)\n", last_fragment, rtp_m);
 return AVERROR_INVALIDDATA;
@@ -134,72 +134,70 @@ static int vp9_handle_packet(AVFormatContext *ctx, 
PayloadContext *rtp_vp9_ctx,
  *
  *  0 1 2 3 4 5 6 7
  * +-+-+-+-+-+-+-+-+
- *   L:| T | S | Q | R | (CONDITIONALLY RECOMMENDED)
+ *   L:| TID |U| SID |D| (Conditionally RECOMMENDED)
+ * +-+-+-+-+-+-+-+-+
+ * |   TL0PICIDX   | (Conditionally REQUIRED)
  * +-+-+-+-+-+-+-+-+
  *
- *   T, S and Q are 2-bit indices for temporal, spatial, and quality 
layers.
- *   If "F" is set in the initial octet, R is 2 bits representing the 
number
- *   of reference fields this frame refers to.
+ *   TID: Temporal layer ID (3 bits)
+ *   U: Switching up point (1 bit)
+ *   SID: Spatial layer ID (3 bits)
+ *   D: Inter-layer dependency used (1 bit)
+ *   TL0PICIDX: Temporal Layer 0 Picture Index (8 bits, non-flexible mode 
only)
  */
 if (has_layer_idc) {
 if (len < 1) {
 av_log(ctx, AV_LOG_ERROR, "Too short RTP/VP9 packet\n");
 return AVERROR_INVALIDDATA;
 }
-layer_temporal = buf[0] & 0xC0;
-layer_spatial  = buf[0] & 0x30;
-layer_quality  = buf[0] & 0x0C;
-if (has_ref_idc) {
-ref_fields = buf[0] & 0x03;
-if (ref_fields)
-non_key_frame = 1;
-}
+layer_temporal = buf[0] >> 5;
+layer_spatial  = (buf[0] >> 1) & 0x07;
 buf++;
 len--;
+
+if (!has_ref_idc) {
+if (len < 1) {
+av_log(ctx, AV_LOG_ERROR, "Too short RTP/VP9 packet\n");
+return AVERROR_INVALIDDATA;
+}
+/* ignore TL0PICIDX */
+buf++;
+len--;
+}
 }
 
 /*
- * decode the reference fields
+ * decode reference indices
  *
  *  0 1 2 3 4 5 6 7
- * +-+-+-+-+-+-+-+-+  -\
- *   F:| PID |X| RS| RQ| (OPTIONAL).
- * +-+-+-+-+-+-+-+-+   . - R times
- *   X:| EXTENDED PID  | (OPTIONAL).
- * +-+-+-+-+-+-+-+-+  -/
+ * +-+-+-+-+-+-+-+-+ -\
+ *   P,F:  | P_DIFF  |N| (Conditionally REQUIRED)- up to 3 times
+ * +-+-+-+-+-+-+-+-+ -/
  *
- *   PID:  The relative Picture ID referred to by this frame.
- *   RS and RQ:  The spatial and quality layer IDs.
- *   X: 1 if this lay

Re: [FFmpeg-devel] [PATCH v3 0/2] Improve HWDeviceContext logging

2025-04-19 Thread softworkz .



> -Original Message-
> From: ffmpegagent 
> Sent: Samstag, 19. April 2025 16:43
> To: ffmpeg-devel@ffmpeg.org
> Cc: softworkz 
> Subject: [PATCH v3 0/2] Improve HWDeviceContext logging
> 
> This changeset
> 
>  * adds an av class category for hw device contexts
>  * assigns a color to it
>  * adds an item_name function to the av class for hw device context
> 
> 
> Before
> ==
> 
> [AVHWDeviceContext @ 0260A9C63E00] Selecting d3d11va adapter 2
> [AVHWDeviceContext @ 0260A9C63E00] Using device 8086:4c8a
> (Intel(R) UH..
> [AVHWDeviceContext @ 0260A9BFFC40] Use Intel(R) Media SDK to
> create MF..
> [AVHWDeviceContext @ 0260A9BFFC40] Initialize MFX session:
> implementat..
> [h264 @ 0260AC0DC640] Reinit context to 1920x800, pix_fmt: yuv420p
> 
> 
> After
> =
> 
> [D3D11VA @ 0184942C25C0] Selecting d3d11va adapter 2
> [D3D11VA @ 0184942C25C0] Using device 8086:4c8a (Intel(R) UHD
> Graphics..
> [QSV @ 0184942601C0] Use Intel(R) Media SDK to create MFX session,
> API..
> [QSV @ 0184942601C0] Initialize MFX session: implementation
> version is..
> [h264 @ 0184964BA9C0] Reinit context to 1920x800, pix_fmt: yuv420p
> 
> (..unable to show the terminal color change in plain text e-mail)
> 
> 
> V2
> ==
> 
>  * Resolved merge conflicts
>  * PING
> 
> 
> V3
> ==
> 
> TWO QUESTIONS BEFORE PUSHING:
> 
>  1. Adding an enum member without affecting the value of the last
> member
> (_NB)
> 
> =>Is that a MINOR or a MICRO version bump?
> 
>  2. The date in doc/APIchanges
> 
> => Should I adjust it to the date when pushing or keep the date it had
> in
> the submitted patchset?
> 


>From the history of APIChanges, most of the time - but not always - the
date appears to be set to the date when it's finally pushed, so I'll 
go with that.


Could somebody please confirm the kind of version bump needed for this 
specific case?

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 v3] libavutil: Add AVMap

2025-04-19 Thread Nicolas George
Michael Niedermayer (HE12025-04-19):
> I dont know what you are trying to acomplish here.

I am trying to help make this API as good as possible before it becomes
public and cannot be changed. I am nowhere as good as you in many areas,
but I think I can say that architecture, and in particular API design,
is the thing I am especially good at.

> The key-value part is a fundamental part of the design and it leads to
> multiple advantages.
> it makes the code simpler, faster and enables several features that
> otherwise would be messy/complex
> 
> Also I have no interrest nor time for working on someone elses design
> maybe if that design would convince me but this one does not.

I am not trying to impose my own design. In fact, I think would have
mostly done the same as you

> I think you should resubmit AVWriter and work on it. I think most people
> will respect your design choices unless there are really good technical
> reasons to do something differently.
> The same way I also expect you to respect my choice in AVMap unless theres
> really something better

I am precisely trying to steer a small part of the design towards
something better. You already changed your mind once about the compare
functions, can you not take two steps back, look at it and just consider
changing your mind a second time.

> There is no need for a "user context" pointer in the core API because the user
> specified key is always passed in the first argument of the compare function.
> A struct {Context *c, char *key} can be passed in that if someone really ever
> needs this, noone needed this till now it seems.

There is a need for a user context to the compare function if you want
to have a dictionary in German and a dictionary in French, because the
rules for alphabetical order are slightly different.

But that can be added later.

> You are the mathematican, my terminology is likely off by at least a bit if 
> not more

Sorry for the nitpicking. Math expresses things slightly differently, so
there is no single word to express it in the case of 3-valued compare
functions. You can call it either “partial order” or “total preorder”,
but get rid of the word “strict”.

> Basically by chaining increasingly specific compare functions in code
> (like av_strcasecmp and strcmp in the example)
> it is later possible to stop before all functions are run and have
> wider matches (like case insensitve in  the example)
> 
> Of course for adding elements, always the same and most specific function
> is used so everything is always ordered the same way. Its only the
> find/get stuff that can use these other functions

That makes sense.

> But all this really is under the hood and the user doesnt need to know
> the user just asks for case insensitve and gets it as long as the av_map
> was settup in a way that allows it.

The user needs to understand that if they want to make a map of their
own type and need to provide the compare function.

Let me make you a promise: if you can write an introduction to the API
(as all non-trivial APIs should have) that makes other major developers
say “that was clear”, I will leave the matter alone.

But as is, I still think this is needlessly complex.

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 v3] libavutil: Add AVMap

2025-04-19 Thread Nicolas George
Nicolas George (HE12025-04-19):
> Let me make you a promise: if you can write an introduction to the API
> (as all non-trivial APIs should have) that makes other major developers
> say “that was clear”, I will leave the matter alone.

… which does not mean I demand you do that. You can probably convince me
otherwise if your design is indeed the best.

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 v3] libavutil: Add AVMap

2025-04-19 Thread Leo Izen

On 4/17/25 12:52, Michael Niedermayer wrote:

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

Signed-off-by: Michael Niedermayer 
---
  libavutil/Makefile|   3 +
  libavutil/map.c   | 415 ++
  libavutil/map.h   | 270 +
  libavutil/tests/map.c | 221 
  libavutil/tree.c  |   6 +-
  libavutil/tree_internal.h |  28 +++
  tests/fate/libavutil.mak  |   4 +
  tests/ref/fate/map|  27 +++
  8 files changed, 969 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..59b87a1f074
--- /dev/null
+++ b/libavutil/map.c
@@ -0,0 +1,415 @@
+/*
+ * 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{
+#define CMP_MASK 31
+AVMapCompareFunc cmp[27];
+AVMapCopyFunc copy;
+AVMapFreeFunc freef;
+int count;
+int deleted;
+int next;   ///< index of entry in root array after all 
used entries


Indices into arrays and counts and t

Re: [FFmpeg-devel] [PATCH v3] libavutil: Add AVMap

2025-04-19 Thread Nicolas George
Michael Niedermayer (HE12025-04-17):
> ok, i will change teh name

Thanks.

> You can implement an av_map_new() variant thats on the stack
> if thats what you want to have / to use / to do
> once the code is in git
> or maybe i will do it but there are many more interresting things

I have checked, it can be done after the fact. (I am surprised you do
not consider this interesting).

> yes, mails take alot of time to read and reply to.

Sorry, I had assumed you would have replied before posting an updated
version because that is what I would have done.


Summary of the rest of the message:

- Keep the core API simple:

- no duplicated values;

- one compare function set once and for all at creation time.

- Implement extra features as utility functions on top of the core API.


> thats neither efficient nor does it fit the existing APIs.
> The value is most of the time not used and when used it is known exactly
> where it is. after a string compare of the key thats equal the value location 
> is known
> or with arbitrary binary data the compare function knows the size of the data.
> also existing APIs from av_tree strcmp() av_strcasecmp() and so on none of
> which take 4 pointers from which they would ignore 2.

The more I think on if, the more I think this idea of giving the value
to the compare function is a bad idea. It is a break of abstraction,
unlike most other dictionaries API. The concatenation bit is kind of
exposing the specifics of the implementation.

IIUC, the point is to use it to allow multiple values with the same key.
But it also introduces de-duplication that might not be wanted.

In retrospect, I think shoehorning duplicated keys into AVDictionary was
a bad idea, and imitating that here is compounding the bad idea status.

If API-users want multiple values with de-dupliction like that, it is
simpler to do on their side by making the value part of the key, and
using dummy values:

"x" => "first" |"x:first" => ""
"x" => "second"|"x:second" => ""
"y" => "other" |"y:other" => ""

Callers can choose the best delimiters for their needs.

If API-users want multiple values without de-duplication, better treat
the value itself as an array/list somehow. If the code does not treat \0
as special in the value, we can do a lot of things like easily.

We can offer utility functions to support these patterns if that happens
to be useful. It is better than having these minor features affect the
design of the data structure.

> Passing redudant pointers just wastes cpu cycles

Does it make a non-negligible difference? Because when it comes to extra
pointers, there is more: real compare function might need a global
argument to determine their behavior: strcoll_l() and its third argument
for example.

If the extra pointer does make a significant difference, I have a
solution too. It requires a flags argument to the creation function
would help.

> the compare functions are needed purely for setup. And there
> they are needed because of arbitrary data support. av_map cannot
> know how to compare your data. (if its not strings)

Of course, we need to be able to set the compare function. My point it:
singular: ONE compare function for the whole map, set at creation and
never changed afterwards.

> But the existing code is much simpler:
> 
> AVMapEntry e = NULL;
> while (e = av_map_get_multiple(set, e, "author", 
> AV_MAP_CMP_CASE_INSENSITIVE | AV_MAP_CMP_KEY) {
> printf("Tag key:%s value:%s\n", e->key, e->value);
> }

That could be done as an utility function wrapping the “vs” code below I
snipped. It is better than letting this complicate the core API.

> Also the code above will just give wrong results with no warning if the 
> compare
> function the map is setup with is incompatible with

I think you forgot the end of the sentence.

Reading more carefully, the business with the multiple compare function
makes even less sense to me:

>>> + * it must form a strict total order on all elements 
>>> you want to store.

>>> + * @param cmp   compatible compare function that comapres key or 
>>> keyvalues

There is only order compatible with a total order is itself. As is, the
documentation says all the compare functions must return the exact same
thing, but that cannot be what it means.

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 v3] libavutil: Add AVMap

2025-04-19 Thread Michael Niedermayer
Hi

On Sat, Apr 19, 2025 at 03:03:16PM +0200, Nicolas George wrote:
> Michael Niedermayer (HE12025-04-17):
> > ok, i will change teh name
> 
> Thanks.
> 
> > You can implement an av_map_new() variant thats on the stack
> > if thats what you want to have / to use / to do
> > once the code is in git
> > or maybe i will do it but there are many more interresting things
> 
> I have checked, it can be done after the fact. (I am surprised you do
> not consider this interesting).

There are too many interresting things. Its interresting but not
interresting enough. Also its easy to add later


> 
> > yes, mails take alot of time to read and reply to.
> 
> Sorry, I had assumed you would have replied before posting an updated
> version because that is what I would have done.
> 
> 
> Summary of the rest of the message:
> 
> - Keep the core API simple:
> 
> - no duplicated values;
> 
> - one compare function set once and for all at creation time.
> 
> - Implement extra features as utility functions on top of the core API.
> 
> 
> > thats neither efficient nor does it fit the existing APIs.
> > The value is most of the time not used and when used it is known exactly
> > where it is. after a string compare of the key thats equal the value 
> > location is known
> > or with arbitrary binary data the compare function knows the size of the 
> > data.
> > also existing APIs from av_tree strcmp() av_strcasecmp() and so on none of
> > which take 4 pointers from which they would ignore 2.
> 
> The more I think on if, the more I think this idea of giving the value
> to the compare function is a bad idea. It is a break of abstraction,
> unlike most other dictionaries API. The concatenation bit is kind of
> exposing the specifics of the implementation.
> 
> IIUC, the point is to use it to allow multiple values with the same key.
> But it also introduces de-duplication that might not be wanted.
> 
[...]
>
> If API-users want multiple values with de-dupliction like that, it is
> simpler to do on their side by making the value part of the key, and
> using dummy values:
> 
> "x" => "first" |"x:first" => ""
> "x" => "second"|"x:second" => ""
> "y" => "other" |"y:other" => ""
> 
> Callers can choose the best delimiters for their needs.
> 
> If API-users want multiple values without de-duplication, better treat
> the value itself as an array/list somehow. If the code does not treat \0
> as special in the value, we can do a lot of things like easily.
> 
> We can offer utility functions to support these patterns if that happens
> to be useful. It is better than having these minor features affect the
> design of the data structure.

I dont know what you are trying to acomplish here.

The key-value part is a fundamental part of the design and it leads to
multiple advantages.
it makes the code simpler, faster and enables several features that
otherwise would be messy/complex

Also I have no interrest nor time for working on someone elses design
maybe if that design would convince me but this one does not.

I think you should resubmit AVWriter and work on it. I think most people
will respect your design choices unless there are really good technical
reasons to do something differently.
The same way I also expect you to respect my choice in AVMap unless theres
really something better


> 
> > Passing redudant pointers just wastes cpu cycles
> 
> Does it make a non-negligible difference? Because when it comes to extra
> pointers, there is more: real compare function might need a global
> argument to determine their behavior: strcoll_l() and its third argument
> for example.
> 
> If the extra pointer does make a significant difference, I have a
> solution too. It requires a flags argument to the creation function
> would help.

There is no need for a "user context" pointer in the core API because the user
specified key is always passed in the first argument of the compare function.
A struct {Context *c, char *key} can be passed in that if someone really ever
needs this, noone needed this till now it seems.


> 
> > the compare functions are needed purely for setup. And there
> > they are needed because of arbitrary data support. av_map cannot
> > know how to compare your data. (if its not strings)
> 
> Of course, we need to be able to set the compare function. My point it:
> singular: ONE compare function for the whole map, set at creation and
> never changed afterwards.
> 
> > But the existing code is much simpler:
> > 
> > AVMapEntry e = NULL;
> > while (e = av_map_get_multiple(set, e, "author", 
> > AV_MAP_CMP_CASE_INSENSITIVE | AV_MAP_CMP_KEY) {
> > printf("Tag key:%s value:%s\n", e->key, e->value);
> > }
> 
> That could be done as an utility function wrapping the “vs” code below I
> snipped. It is better than letting this complicate the core API.
> 
> > Also the code above will just give wrong results with no warning if the 
> > compare
> > function the map is setup with is in

[FFmpeg-devel] [PATCH v3 1/2] avutil/log, hwcontext: Add AV_CLASS_CATEGORY_HWDEVICE

2025-04-19 Thread softworkz
From: softworkz 

Signed-off-by: softworkz 
---
 doc/APIchanges| 3 +++
 libavutil/hwcontext.c | 1 +
 libavutil/log.c   | 1 +
 libavutil/log.h   | 1 +
 libavutil/version.h   | 2 +-
 5 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 22aa6fa5c7..af1c5e644a 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-03-12 - xx - lavu 60.2.100 - log.h
+  Add AV_CLASS_CATEGORY_HWDEVICE.
+
 2025-04-16 - c818c67991 - libpostproc 59.1.100 - postprocess.h
   Deprecate PP_CPU_CAPS_3DNOW.
 
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index f06d49c45c..276dc9cee6 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -140,6 +140,7 @@ enum AVHWDeviceType av_hwdevice_iterate_types(enum 
AVHWDeviceType prev)
 static const AVClass hwdevice_ctx_class = {
 .class_name = "AVHWDeviceContext",
 .item_name  = av_default_item_name,
+.category   = AV_CLASS_CATEGORY_HWDEVICE,
 .version= LIBAVUTIL_VERSION_INT,
 };
 
diff --git a/libavutil/log.c b/libavutil/log.c
index c5ee876a88..2b721aea5a 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -81,6 +81,7 @@ static const uint8_t color[16 + AV_CLASS_CATEGORY_NB] = {
 [16+AV_CLASS_CATEGORY_BITSTREAM_FILTER] =  9,
 [16+AV_CLASS_CATEGORY_SWSCALER] =  7,
 [16+AV_CLASS_CATEGORY_SWRESAMPLER ] =  7,
+[16+AV_CLASS_CATEGORY_HWDEVICE] =  6,
 [16+AV_CLASS_CATEGORY_DEVICE_VIDEO_OUTPUT ] = 13,
 [16+AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT  ] = 5,
 [16+AV_CLASS_CATEGORY_DEVICE_AUDIO_OUTPUT ] = 13,
diff --git a/libavutil/log.h b/libavutil/log.h
index dd094307ce..ac5b08b632 100644
--- a/libavutil/log.h
+++ b/libavutil/log.h
@@ -37,6 +37,7 @@ typedef enum {
 AV_CLASS_CATEGORY_BITSTREAM_FILTER,
 AV_CLASS_CATEGORY_SWSCALER,
 AV_CLASS_CATEGORY_SWRESAMPLER,
+AV_CLASS_CATEGORY_HWDEVICE,
 AV_CLASS_CATEGORY_DEVICE_VIDEO_OUTPUT = 40,
 AV_CLASS_CATEGORY_DEVICE_VIDEO_INPUT,
 AV_CLASS_CATEGORY_DEVICE_AUDIO_OUTPUT,
diff --git a/libavutil/version.h b/libavutil/version.h
index 5139883569..4717cd562b 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  60
-#define LIBAVUTIL_VERSION_MINOR   1
+#define LIBAVUTIL_VERSION_MINOR   2
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
-- 
ffmpeg-codebot

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

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


[FFmpeg-devel] [PATCH v3 2/2] avutil/hwcontext: Add item_name function for AVHWDeviceContext

2025-04-19 Thread softworkz
From: softworkz 

Signed-off-by: softworkz 
---
 libavutil/hwcontext.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 276dc9cee6..3111a44651 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -137,9 +137,15 @@ enum AVHWDeviceType av_hwdevice_iterate_types(enum 
AVHWDeviceType prev)
 return set ? next : AV_HWDEVICE_TYPE_NONE;
 }
 
+static const char *hwdevice_ctx_get_name(void *ptr)
+{
+FFHWDeviceContext *ctx = ptr;
+return ctx->hw_type->name;
+}
+
 static const AVClass hwdevice_ctx_class = {
 .class_name = "AVHWDeviceContext",
-.item_name  = av_default_item_name,
+.item_name  = hwdevice_ctx_get_name,
 .category   = AV_CLASS_CATEGORY_HWDEVICE,
 .version= LIBAVUTIL_VERSION_INT,
 };
-- 
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[FFmpeg-devel] [PATCH v3 0/2] Improve HWDeviceContext logging

2025-04-19 Thread ffmpegagent
This changeset

 * adds an av class category for hw device contexts
 * assigns a color to it
 * adds an item_name function to the av class for hw device context


Before
==

[AVHWDeviceContext @ 0260A9C63E00] Selecting d3d11va adapter 2
[AVHWDeviceContext @ 0260A9C63E00] Using device 8086:4c8a (Intel(R) UH..
[AVHWDeviceContext @ 0260A9BFFC40] Use Intel(R) Media SDK to create MF..
[AVHWDeviceContext @ 0260A9BFFC40] Initialize MFX session: implementat..
[h264 @ 0260AC0DC640] Reinit context to 1920x800, pix_fmt: yuv420p


After
=

[D3D11VA @ 0184942C25C0] Selecting d3d11va adapter 2
[D3D11VA @ 0184942C25C0] Using device 8086:4c8a (Intel(R) UHD Graphics..
[QSV @ 0184942601C0] Use Intel(R) Media SDK to create MFX session, API..
[QSV @ 0184942601C0] Initialize MFX session: implementation version is..
[h264 @ 0184964BA9C0] Reinit context to 1920x800, pix_fmt: yuv420p

(..unable to show the terminal color change in plain text e-mail)


V2
==

 * Resolved merge conflicts
 * PING


V3
==

TWO QUESTIONS BEFORE PUSHING:

 1. Adding an enum member without affecting the value of the last member
(_NB)

=>Is that a MINOR or a MICRO version bump?

 2. The date in doc/APIchanges

=> Should I adjust it to the date when pushing or keep the date it had in
the submitted patchset?

Thanks, sw

softworkz (2):
  avutil/log,hwcontext: Add AV_CLASS_CATEGORY_HWDEVICE
  avutil/hwcontext: Add item_name function for AVHWDeviceContext

 doc/APIchanges| 3 +++
 libavutil/hwcontext.c | 9 -
 libavutil/log.c   | 1 +
 libavutil/log.h   | 1 +
 libavutil/version.h   | 2 +-
 5 files changed, 14 insertions(+), 2 deletions(-)


base-commit: ec3f3457fdfdf49b64e57c1e6c8cefd0603bc309
Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-61%2Fsoftworkz%2Fsubmit_hwdevice_logging-v3
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-61/softworkz/submit_hwdevice_logging-v3
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/61

Range-diff vs v2:

 1:  3547fc2de7 ! 1:  5d0366d826 avutil/log,hwcontext: Add 
AV_CLASS_CATEGORY_HWDEVICE
 @@ doc/APIchanges: The last version increases of all libraries were on 
2025-03-28
   
   API changes, most recent first:
   
 -+2025-03-12 - xx - lavu 60.1.100 - log.h
 ++2025-03-12 - xx - lavu 60.2.100 - log.h
  +  Add AV_CLASS_CATEGORY_HWDEVICE.
  +
 - 2025-03-17 - xx - lavu 59.60.100 - pixfmt.h
 -   Add AV_PIX_FMT_GBRAP32BE and AV_PIX_FMT_GBRAP32LE.
 + 2025-04-16 - c818c67991 - libpostproc 59.1.100 - postprocess.h
 +   Deprecate PP_CPU_CAPS_3DNOW.
   
  
   ## libavutil/hwcontext.c ##
 @@ libavutil/version.h
*/
   
   #define LIBAVUTIL_VERSION_MAJOR  60
 --#define LIBAVUTIL_VERSION_MINOR   0
 -+#define LIBAVUTIL_VERSION_MINOR   1
 +-#define LIBAVUTIL_VERSION_MINOR   1
 ++#define LIBAVUTIL_VERSION_MINOR   2
   #define LIBAVUTIL_VERSION_MICRO 100
   
   #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
 2:  600d0e65a4 = 2:  a907d39ca2 avutil/hwcontext: Add item_name function for 
AVHWDeviceContext

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

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


[FFmpeg-devel] [PATCH 1/6] lavc: APV codec ID and descriptor

2025-04-19 Thread Mark Thompson
---
 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..88fed478a3 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_APV,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "apv",
+.long_name = NULL_IF_CONFIG_SMALL("Advanced Professional Video"),
+.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..be0a65bcb9 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_APV,
 
 /* various PCM "codecs" */
 AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the 
start of audio codecs
-- 
2.47.2

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

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