Re: [FFmpeg-devel] [PATCH 3/4] fftools/graph/graphprint: load CSS and HTML resources from ffmpeg data directories

2025-05-17 Thread Marton Balint




On Sat, 17 May 2025, softworkz . wrote:





-Original Message-
From: ffmpeg-devel  On Behalf Of Marton
Balint
Sent: Samstag, 17. Mai 2025 01:09
To: ffmpeg-devel@ffmpeg.org
Cc: Marton Balint 
Subject: [FFmpeg-devel] [PATCH 3/4] fftools/graph/graphprint: load CSS and
HTML resources from ffmpeg data directories

Similar to how it is done for ffpreset files. This allows the users to change
the HTML/CSS templates at will.

Signed-off-by: Marton Balint 
---
 Makefile|  2 +-
 doc/ffmpeg.texi |  4 ++-
 fftools/cmdutils.c  | 48 +
 fftools/cmdutils.h  |  2 ++
 fftools/graph/graphprint.c  | 16 ---
 fftools/textformat/tf_mermaid.h |  4 +--
 6 files changed, 68 insertions(+), 8 deletions(-)

diff --git a/Makefile b/Makefile
index e2250f6bc6..ebc50bb510 100644
--- a/Makefile
+++ b/Makefile
@@ -32,7 +32,7 @@ FFLIBS-$(CONFIG_SWSCALE)+= swscale

 FFLIBS := avutil

-DATA_FILES := $(wildcard $(SRC_PATH)/presets/*.ffpreset)
$(SRC_PATH)/doc/ffprobe.xsd
+DATA_FILES := $(wildcard $(SRC_PATH)/presets/*.ffpreset)
$(SRC_PATH)/doc/ffprobe.xsd $(SRC_PATH)/fftools/resources/graph.css
$(SRC_PATH)/fftools/resources/graph.html

 SKIPHEADERS = compat/w32pthreads.h

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 35675b5309..8edf188ab9 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1402,7 +1402,9 @@ Writes execution graph details to the specified file in
the format set via -prin

 @item -print_graphs_format @var{format} (@emph{global})
 Sets the output format (available formats are: default, compact, csv, flat,
ini, json, xml, mermaid, mermaidhtml)
-The default format is json.
+The default format is json. The mermarid and mermaidhtml formats need
graph.css
+and graph.html resources which are searched in the FFMPEG data directories,
+similar to ffpreset files.

 @item -progress @var{url} (@emph{global})
 Send program-friendly progress information to @var{url}.
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 1de670c2e4..01e57d91e8 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1005,6 +1005,54 @@ FILE *get_preset_file(AVBPrint *filename,
 return f;
 }

+int file_read_from_datadir(const char *filename, char **outbuf)
+{
+FILE *f;
+char *buf = NULL;
+long size;
+AVBPrint bp;
+
+av_bprint_init(&bp, 0, AV_BPRINT_SIZE_UNLIMITED);
+f = get_datadir_file_fmt(&bp, "%s", filename);
+if (!f)
+return AVERROR(errno);
+
+if (fseek(f, 0, SEEK_END)) {
+int ret = AVERROR(errno);
+fclose(f);
+return ret;
+}
+
+size = ftell(f);
+if (size < 0 || size >= INT_MAX) {
+fclose(f);
+return AVERROR(EINVAL);
+}
+
+if (fseek(f, 0, SEEK_SET)) {
+int ret = AVERROR(errno);
+fclose(f);
+return ret;
+}
+
+buf = av_malloc(size + 1);
+if (!buf) {
+fclose(f);
+return AVERROR(ENOMEM);
+}
+
+if (fread(buf, 1, size, f) != size) {
+fclose(f);
+return AVERROR(EIO);
+}
+buf[size] = 0;
+
+fclose(f);
+
+*outbuf = buf;
+return 0;
+}
+
 int cmdutils_isalnum(char c)
 {
 return (c >= '0' && c <= '9') ||
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index 216a2bcfe7..b324e5fc65 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -504,6 +504,8 @@ int read_yesno(void);
 FILE *get_preset_file(AVBPrint *filename,
   const char *preset_name, int is_path, const char
*codec_name);

+int file_read_from_datadir(const char *filename, char **buf);
+
 /**
  * Realloc array to hold new_size elements of elem_size.
  *
diff --git a/fftools/graph/graphprint.c b/fftools/graph/graphprint.c
index fc94a75797..fbcb7f1b75 100644
--- a/fftools/graph/graphprint.c
+++ b/fftools/graph/graphprint.c
@@ -41,7 +41,6 @@
 #include "libavutil/hwcontext.h"
 #include "fftools/textformat/avtextformat.h"
 #include "fftools/textformat/tf_mermaid.h"
-#include "fftools/resources/resman.h"

 typedef enum {
 SECTION_ID_ROOT,
@@ -935,10 +934,19 @@ static int init_graphprint(GraphPrintContext **pgpc,
AVBPrint *target_buf)
 }

 if (!strcmp(text_formatter->name, "mermaid") || !strcmp(text_formatter-

name, "mermaidhtml")) {

-gpc->diagram_config.diagram_css =
ff_resman_get_string(FF_RESOURCE_GRAPH_CSS);
+ret = file_read_from_datadir("graph.css", &gpc-

diagram_config.diagram_css);

+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR, "graph.css needed for mermaid graph
format cannot be opened: %s\n", av_err2str(ret));
+goto fail;
+}

-if (!strcmp(text_formatter->name, "mermaidhtml"))
-gpc->diagram_config.html_template =
ff_resman_get_string(FF_RESOURCE_GRAPH_HTML);
+if (!strcmp(text_formatter->name, "mermaidhtml")) {
+ret = file_read_from_datadir("graph.html", &gpc-

diagram_config.html_template);

+if (ret < 0) {
+av

Re: [FFmpeg-devel] [PATCH] avfilter/version: Bump minor for avfilter_link_get_hw_frames_ctx()

2025-05-17 Thread James Almer

On 5/17/2025 10:13 AM, Andreas Rheinhardt wrote:

Patch attached. (APIchanges even uses the wrong major version.)

- Andreas


I think this function should be removed instead, because it should have 
never been committed. The AVFilterLink API states that the user is not 
meant to access its internals directly, but through the Buffersink API 
instead.




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

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


Re: [FFmpeg-devel] [PATCH 3/4] fftools/graph/graphprint: load CSS and HTML resources from ffmpeg data directories

2025-05-17 Thread softworkz .



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Marton
> Balint
> Sent: Samstag, 17. Mai 2025 11:14
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH 3/4] fftools/graph/graphprint: load CSS and
> HTML resources from ffmpeg data directories
> 
> 
> 
> On Sat, 17 May 2025, softworkz . wrote:
> 
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of Marton
> >> Balint
> >> Sent: Samstag, 17. Mai 2025 01:09
> >> To: ffmpeg-devel@ffmpeg.org
> >> Cc: Marton Balint 
> >> Subject: [FFmpeg-devel] [PATCH 3/4] fftools/graph/graphprint: load CSS and
> >> HTML resources from ffmpeg data directories
> >>
> >> Similar to how it is done for ffpreset files. This allows the users to
> change
> >> the HTML/CSS templates at will.
> >>
> >> Signed-off-by: Marton Balint 
> >> ---
> >>  Makefile|  2 +-
> >>  doc/ffmpeg.texi |  4 ++-
> >>  fftools/cmdutils.c  | 48 +
> >>  fftools/cmdutils.h  |  2 ++
> >>  fftools/graph/graphprint.c  | 16 ---
> >>  fftools/textformat/tf_mermaid.h |  4 +--
> >>  6 files changed, 68 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/Makefile b/Makefile
> >> index e2250f6bc6..ebc50bb510 100644
> >> --- a/Makefile
> >> +++ b/Makefile
> >> @@ -32,7 +32,7 @@ FFLIBS-$(CONFIG_SWSCALE)+= swscale
> >>
> >>  FFLIBS := avutil
> >>
> >> -DATA_FILES := $(wildcard $(SRC_PATH)/presets/*.ffpreset)
> >> $(SRC_PATH)/doc/ffprobe.xsd
> >> +DATA_FILES := $(wildcard $(SRC_PATH)/presets/*.ffpreset)
> >> $(SRC_PATH)/doc/ffprobe.xsd $(SRC_PATH)/fftools/resources/graph.css
> >> $(SRC_PATH)/fftools/resources/graph.html
> >>
> >>  SKIPHEADERS = compat/w32pthreads.h
> >>
> >> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> >> index 35675b5309..8edf188ab9 100644
> >> --- a/doc/ffmpeg.texi
> >> +++ b/doc/ffmpeg.texi
> >> @@ -1402,7 +1402,9 @@ Writes execution graph details to the specified file
> in
> >> the format set via -prin
> >>
> >>  @item -print_graphs_format @var{format} (@emph{global})
> >>  Sets the output format (available formats are: default, compact, csv,
> flat,
> >> ini, json, xml, mermaid, mermaidhtml)
> >> -The default format is json.
> >> +The default format is json. The mermarid and mermaidhtml formats need
> >> graph.css
> >> +and graph.html resources which are searched in the FFMPEG data
> directories,
> >> +similar to ffpreset files.
> >>
> >>  @item -progress @var{url} (@emph{global})
> >>  Send program-friendly progress information to @var{url}.
> >> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> >> index 1de670c2e4..01e57d91e8 100644
> >> --- a/fftools/cmdutils.c
> >> +++ b/fftools/cmdutils.c
> >> @@ -1005,6 +1005,54 @@ FILE *get_preset_file(AVBPrint *filename,
> >>  return f;
> >>  }
> >>
> >> +int file_read_from_datadir(const char *filename, char **outbuf)
> >> +{
> >> +FILE *f;
> >> +char *buf = NULL;
> >> +long size;
> >> +AVBPrint bp;
> >> +
> >> +av_bprint_init(&bp, 0, AV_BPRINT_SIZE_UNLIMITED);
> >> +f = get_datadir_file_fmt(&bp, "%s", filename);
> >> +if (!f)
> >> +return AVERROR(errno);
> >> +
> >> +if (fseek(f, 0, SEEK_END)) {
> >> +int ret = AVERROR(errno);
> >> +fclose(f);
> >> +return ret;
> >> +}
> >> +
> >> +size = ftell(f);
> >> +if (size < 0 || size >= INT_MAX) {
> >> +fclose(f);
> >> +return AVERROR(EINVAL);
> >> +}
> >> +
> >> +if (fseek(f, 0, SEEK_SET)) {
> >> +int ret = AVERROR(errno);
> >> +fclose(f);
> >> +return ret;
> >> +}
> >> +
> >> +buf = av_malloc(size + 1);
> >> +if (!buf) {
> >> +fclose(f);
> >> +return AVERROR(ENOMEM);
> >> +}
> >> +
> >> +if (fread(buf, 1, size, f) != size) {
> >> +fclose(f);
> >> +return AVERROR(EIO);
> >> +}
> >> +buf[size] = 0;
> >> +
> >> +fclose(f);
> >> +
> >> +*outbuf = buf;
> >> +return 0;
> >> +}
> >> +
> >>  int cmdutils_isalnum(char c)
> >>  {
> >>  return (c >= '0' && c <= '9') ||
> >> diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
> >> index 216a2bcfe7..b324e5fc65 100644
> >> --- a/fftools/cmdutils.h
> >> +++ b/fftools/cmdutils.h
> >> @@ -504,6 +504,8 @@ int read_yesno(void);
> >>  FILE *get_preset_file(AVBPrint *filename,
> >>const char *preset_name, int is_path, const char
> >> *codec_name);
> >>
> >> +int file_read_from_datadir(const char *filename, char **buf);
> >> +
> >>  /**
> >>   * Realloc array to hold new_size elements of elem_size.
> >>   *
> >> diff --git a/fftools/graph/graphprint.c b/fftools/graph/graphprint.c
> >> index fc94a75797..fbcb7f1b75 100644
> >> --- a/fftools/graph/graphprint.c
> >> +++ b/fftools/graph/graphprint.c
> >> @@ -41,7 +41,6 @@
> >>  #include "libavutil/hwcontext.h"
> >>  #include "fftools/textformat/avtextformat.h"
> >>  #include "fftools/textformat/tf_mermaid.h"
> >> -#include

Re: [FFmpeg-devel] [PATCH 2/3] fftools/graphprint: Fix leak of graphprint object

2025-05-17 Thread softworkz .



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Mark
> Thompson
> Sent: Samstag, 17. Mai 2025 13:14
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 2/3] fftools/graphprint: Fix leak of graphprint
> object
> 
> ---
>  fftools/graph/graphprint.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fftools/graph/graphprint.c b/fftools/graph/graphprint.c
> index fc94a75797..9e3e03274a 100644
> --- a/fftools/graph/graphprint.c
> +++ b/fftools/graph/graphprint.c
> @@ -862,6 +862,8 @@ static void uninit_graphprint(GraphPrintContext *gpc)
> 
>  // Finalize the print buffer if it was initialized
>  av_bprint_finalize(&gpc->pbuf, NULL);
> +
> +av_freep(&gpc);
>  }
> 
>  static int init_graphprint(GraphPrintContext **pgpc, AVBPrint *target_buf)
> --

Hi Mark,

good catch, thanks for the patch!

LGTM

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 1/3] fftools/resources: fix preservation of intermediary resman build artifacts

2025-05-17 Thread softworkz .



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Timo
> Rothenpieler
> Sent: Samstag, 17. Mai 2025 01:02
> To: ffmpeg-devel@ffmpeg.org
> Cc: Timo Rothenpieler 
> Subject: [FFmpeg-devel] [PATCH 1/3] fftools/resources: fix preservation of
> intermediary resman build artifacts
> 
> Without this, make install triggers a full re-generation of the graph
> stuff, which results in re-linking during install.
> ---
>  ffbuild/common.mak | 3 +--
>  fftools/resources/Makefile | 5 ++---
>  2 files changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/ffbuild/common.mak b/ffbuild/common.mak
> index 0e1eb1f62b..4a3cc0c748 100644
> --- a/ffbuild/common.mak
> +++ b/ffbuild/common.mak
> @@ -229,10 +229,9 @@ SKIPHEADERS += $(ARCH_HEADERS:%=$(ARCH)/%) $(SKIPHEADERS-
> )
>  SKIPHEADERS := $(SKIPHEADERS:%=$(SUBDIR)%)
>  HOBJS= $(filter-out $(SKIPHEADERS:.h=.h.o),$(ALLHEADERS:.h=.h.o))
>  PTXOBJS  = $(filter %.ptx.o,$(OBJS))
> -RESOURCEOBJS = $(filter %.css.o %.html.o,$(OBJS))
>  $(HOBJS): CCFLAGS += $(CFLAGS_HEADERS)
>  checkheaders: $(HOBJS)
> -.SECONDARY:   $(HOBJS:.o=.c) $(PTXOBJS:.o=.c) $(PTXOBJS:.o=.gz)
> $(PTXOBJS:.o=) $(RESOURCEOBJS:.o=.c) $(RESOURCEOBJS:%.css.o=%.css.min)
> $(RESOURCEOBJS:%.css.o=%.css.min.gz) $(RESOURCEOBJS:%.html.o=%.html.gz)
> $(RESOURCEOBJS:.o=)
> +.SECONDARY:   $(HOBJS:.o=.c) $(PTXOBJS:.o=.c) $(PTXOBJS:.o=.gz)
> $(PTXOBJS:.o=)
> 
>  alltools: $(TOOLS)
> 
> diff --git a/fftools/resources/Makefile b/fftools/resources/Makefile
> index 8579a52678..3a307bef12 100644
> --- a/fftools/resources/Makefile
> +++ b/fftools/resources/Makefile
> @@ -4,10 +4,9 @@ clean::
>  vpath %.html $(SRC_PATH)
>  vpath %.css  $(SRC_PATH)
> 
> -# Uncomment to prevent deletion during build
> -#.PRECIOUS: %.css.c %.css.min %.css.gz %.css.min.gz %.html.gz %.html.c
> -
>  OBJS-resman += \
>  fftools/resources/resman.o \
>  fftools/resources/graph.html.o \
>  fftools/resources/graph.css.o  \
> +
> +.SECONDARY: $(OBJS-resman:.o=.c) $(OBJS-resman:.css.o=.css.min) $(OBJS-
> resman:.css.o=.css.min.gz) $(OBJS-resman:.html.o=.html.gz)
> --
> 2.49.0
> 
> ___

Hi Timo,

thanks for the patchset!

Most of it LGTM, but for the main issue, that's not the optimal way yet,
because with that patch, the intermediates do not get deleted when doing
make clean (I've been there already).

I wasn't aware of the relinking issue, have started to investigate futher.

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 3/3] fftools/resources: add missing extensions to .gitignore

2025-05-17 Thread softworkz .



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Timo
> Rothenpieler
> Sent: Samstag, 17. Mai 2025 01:02
> To: ffmpeg-devel@ffmpeg.org
> Cc: Timo Rothenpieler 
> Subject: [FFmpeg-devel] [PATCH 3/3] fftools/resources: add missing extensions
> to .gitignore
> 
> ---
>  fftools/resources/.gitignore | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fftools/resources/.gitignore b/fftools/resources/.gitignore
> index 5f496535a6..bda2c59a1c 100644
> --- a/fftools/resources/.gitignore
> +++ b/fftools/resources/.gitignore
> @@ -2,3 +2,5 @@
>  *.css.c
>  *.html.gz
>  *.css.gz
> +*.min
> +*.min.gz
> --

LGTM, thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[FFmpeg-devel] [PATCH] avcodec/tests/.gitignore: Add apv test tool

2025-05-17 Thread Andreas Rheinhardt
Patch attached.

- Andreas
From abc080244caa6aa137e5bccd82aff5617c23d130 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt 
Date: Sat, 17 May 2025 19:52:37 +0200
Subject: [PATCH] avcodec/tests/.gitignore: Add apv test tool

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/tests/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/tests/.gitignore b/libavcodec/tests/.gitignore
index 0df4ae10a0..2c5bbec7f9 100644
--- a/libavcodec/tests/.gitignore
+++ b/libavcodec/tests/.gitignore
@@ -1,3 +1,4 @@
+/apv
 /av1_levels
 /avcodec
 /avpacket
-- 
2.45.2

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

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


Re: [FFmpeg-devel] [PATCH 1/3] ffmpeg: Don't print graphs if there are no graphs to print

2025-05-17 Thread softworkz .



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Mark
> Thompson
> Sent: Samstag, 17. Mai 2025 13:14
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 1/3] ffmpeg: Don't print graphs if there are no
> graphs to print
> 
> Avoids writing an empty json blob in setup error cases.
> ---
>  fftools/ffmpeg.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 964770df23..ad28cff78d 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -309,7 +309,8 @@ const AVIOInterruptCB int_cb = { decode_interrupt_cb, NULL
> };
> 
>  static void ffmpeg_cleanup(int ret)
>  {
> -if (print_graphs || print_graphs_file)
> +if ((print_graphs || print_graphs_file) &&
> +(nb_filtergraphs > 0 || nb_output_files > 0))
>  print_filtergraphs(filtergraphs, nb_filtergraphs, input_files,
> nb_input_files, output_files, nb_output_files);

The feature is not just about filter graphs, that's why it's been renamed
as "Execution Graph Printing". It also works when no filter graphs are
in play at all. 
Here's an example:

https://softworkz.github.io/ffmpeg_output_apis/1_nofilters_3_in_1_out.html


As for the nb_output_files check, I'm not sure - is it 0 or 1 in case of
-f null output?

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

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


Re: [FFmpeg-devel] [PATCH 1/2] avformat/demux: use io_close2 when closing avfromat

2025-05-17 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Kacper Michajłow:
>> It's not valid to call avio_close() on context that has not been open
>> with avio_open().
>>
>> This fixes use of custom IO. (io_open / io_close2 callbacks)
>>
>> Note that by default io_close2 is set to io_close2_default() which calls
>> avio_close(), so default case will work the same as before.
>>
>> Signed-off-by: Kacper Michajłow 
>> ---
>>  libavformat/demux.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/libavformat/demux.c b/libavformat/demux.c
>> index 2795863567..ecd4f40da9 100644
>> --- a/libavformat/demux.c
>> +++ b/libavformat/demux.c
>> @@ -383,11 +383,10 @@ void avformat_close_input(AVFormatContext **ps)
>>  if (ffifmt(s->iformat)->read_close)
>>  ffifmt(s->iformat)->read_close(s);
>>  
>> +ff_format_io_close(s, &pb);
>>  avformat_free_context(s);
>>  
>>  *ps = NULL;
>> -
>> -avio_close(pb);
>>  }
>>  
>>  static void force_codec_ids(AVFormatContext *s, AVStream *st)
> 
> avformat_open_input() sets AVFMT_FLAG_CUSTOM_IO when using custom IO and
> avformat_close_input() checks for this and does not free the
> AVFormatContext's AVIOContext in this case (but does avio_close(NULL) in
> this case).
> Your patch furthermore presumes that the custom IO context is compatible
> with io_close2, which need not be true at all (one can use custom IO
> without ever touching io_open/io_close2 pointers; I expect users that
> use custom IO, but not formats that open new AVIOContexts to do so).

On reading a bit further, init_input() uses io_open to open the
AVIOContext in case no AVIOContext was supplied (and one is needed).
This means that the AVFMT_FLAG_CUSTOM_IO flag is misleading, as it is
possible to use custom IO even with this flag unset. It also means that
your patch is likely correct.

- Andreas

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

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


[FFmpeg-devel] [PATCH] avformat/avformat: Remove outdated io_close2 documentation

2025-05-17 Thread Andreas Rheinhardt
Patch attached.

- Andreas
From 0e27f202721b7d3c6e06db5bb909787532350837 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt 
Date: Sat, 17 May 2025 15:21:48 +0200
Subject: [PATCH] avformat/avformat: Remove outdated io_close2 documentation

The io_close callback has been removed in
d6799ee0e41dee35ebf9c664173aed8e3ab24141.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/avformat.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 498c3020a5..2034d2aecc 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1870,10 +1870,6 @@ typedef struct AVFormatContext {
 /**
  * A callback for closing the streams opened with AVFormatContext.io_open().
  *
- * Using this is preferred over io_close, because this can return an error.
- * Therefore this callback is used instead of io_close by the generic
- * libavformat code if io_close is NULL or the default.
- *
  * @param s the format context
  * @param pb IO context to be closed and freed
  * @return 0 on success, a negative AVERROR code on failure
-- 
2.45.2

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

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


Re: [FFmpeg-devel] [PATCH] avformat/flvenc: Specify codec tag with MKTAG

2025-05-17 Thread Zhao Zhili


> On May 17, 2025, at 19:14, Timo Rothenpieler  wrote:
> 
> On 17.05.2025 06:35, Zhao Zhili wrote:
>>> 在 2025年5月17日,上午1:39,Timo Rothenpieler  写道:
>>> 
>>> On 16.05.2025 19:24, Zhao Zhili wrote:
>> On May 17, 2025, at 01:10, Zhao Zhili 
>>  wrote:
> 
> 
> 
>> On May 17, 2025, at 00:27, Timo Rothenpieler  
>> wrote:
>> 
>> On 16.05.2025 17:59, Zhao Zhili wrote:
 On May 16, 2025, at 22:52, Timo Rothenpieler  
 wrote:
 
 On 16/05/2025 16:24, Zhao Zhili wrote:
> From: Zhao Zhili  >
> ffmpeg -i input.mp4 -c copy -tag:v av01 output.flv
> [flv @ 0x143204080] Tag av01 incompatible with output codec id '225' 
> (10va)
 
 I don't quite understand what causes this.
 Is this an issue when running on big endian architectures?
 I'm pretty sure I tested all combinations of codecs with muxing and 
 demuxing, and never ran into that error.
>>> The key point is when specify tag via command line, e.g., -tag:v av01, 
>>> it’s
>>> passed to AVCodecParameters codec_tag in little endian.
>>> You didn’t see the error because without specify the tag explicitly, 
>>> codec_tag is copied
>>> from AVOutputFormat codec_tag to AVCodecParameters codec_tag, so they 
>>> are
>>> the same.
>>> Another example is codec_mp4_tags.
>> 
>> This still irks me as wrong.
>> There is _a lot_ of places all over flvenv.c, in all kinds of functions, 
>> that hard-depend on the values in par->codec_tag being from the 
>> _codec_ids tables at the top of the file.
>> Like, they contain flv specific audio and video codec IDs for the 
>> pre-ext-flv codecs, those would all also break.
>> 
>> So there seems to be a deeper issue there if those values can be 
>> overridden from the commandline. The encoder clearly does not expect 
>> that.
>> 
>> Looking at the code this error comes from:
>> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mux.c#L314
>> 
>> It looks to to me like it's working exactly as intended and required by 
>> flvenc, protecting it from invalid tags.
>> 
>> So, when the user provides a custom tag that is invalid, isn't that 
>> kinda on the user?
>> The check you're running into does what it's supposed to:
>> It detects that the provided tag is invalid for this codec in this 
>> container.
>> 
>> Why do you want to override it anyway? There is only exactly one valid 
>> tag for each codec.
> 
> A user shows the error message to me. Because he know there are -tag 
> option for mp4, and
> enhanced-rtmp use fourcc for extended codecs, so he thought it should 
> work.
> 
> The -tag:v av01 is redundant, it should be a NOP, not trigger error. The 
> strings “av01”
> is the right order of fourcc in spec. The endian issue should be limited 
> to the internal.
> Current error message is confusing, because it shows 10va instead of av01.
 Doc from Microsoft shows fourcc use small endian
 https://learn.microsoft.com/en-us/windows/win32/directshow/fourcc-codes
 While wiki and enhanced rtmp spec says it’s big endian
 https://en.wikipedia.org/wiki/FourCC
 It’s clear in av_fourcc_make_string
 that we use small endian.
 For normal codec id in flv, e.g, 7 for H.264, it’s not a big issue, since 
 they’re not fourcc.
>>> 
>>> This patch just fixes it for a very small subset of codecs in flv though.
>>> There's nothing indicating that -tag:v is needed or sensibly supported in 
>>> flvenc.
>>> If you'd want to pass h264 or aac as fourcc, it'd be flat out impossible, 
>>> and no easy fix is available.
>>> 
>>> I'd rather not complicate flvenc, even if just a little bit, just to swap 
>>> around the endianness of the few codecs that do use a fourcc based tag.
>>> 
>>> flvenv should probably just completely ignore -tag:v, since the option 
>>> makes no sense for it anyway.
>> I can remove setting tag list to AVOutputFormat, does that works for you?
> 
> Won't that break even more things?
> The code heavily relies on the tags being what they are, and passing the tag 
> list to AVOutputFormat would remove avformat enforcing that, with said error 
> when trying to override it with something invalid.

The enforcing logic has a precondition, that codec_tag is in little endian.
flv_video_codec_ids and flv_audio_codec_ids don’t match this requirement.

> 
> I honestly don't think anything needs to be changed at all.
> Passing custom tags is simply not something flv sensibly supports.

AVOutputFormat codec_tag is API exported to users. Even if users
are not supposed to pass codec_tag to flvenc, the exported information
should match the tradition, that codec_tag is in little endian according to
the code in av_fourcc_make_string, mov, matroska, and so on.

There is no explici

Re: [FFmpeg-devel] FFmpeg 4.4.6 and 4.2.11

2025-05-17 Thread Michael Niedermayer
On Sat, Mar 15, 2025 at 01:36:59AM +0100, Michael Niedermayer wrote:
> On Wed, Mar 12, 2025 at 02:17:32PM +0100, Michael Niedermayer wrote:
> > On Mon, Mar 03, 2025 at 02:10:49AM +0100, Michael Niedermayer wrote:
> > > Hi all
> > > 
> > > As ive already backported and somewhat tested release/4.3 i intend to
> > > make the next point release from that and after that next is
> > > 3.4 (because its the supported branch that is longest without a release)
> > > 
> > > like always, please backport things if you want something backported
> > > please test, if you want something tested
> > > and tell me if theres anything i need to know (like waiting for something)
> > 
> > 4.3.9 released, 3.4.14 is next
> 
> 3.4.14 released a few days ago too
> 
> next is 4.4.6 and 4.2.11

4.4.6 done, will do 4.2.11 later today or tomorrow

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

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


Re: [FFmpeg-devel] [PATCH 1/2] avformat/demux: use io_close2 when closing avfromat

2025-05-17 Thread Andreas Rheinhardt
Kacper Michajłow:
> It's not valid to call avio_close() on context that has not been open
> with avio_open().
> 
> This fixes use of custom IO. (io_open / io_close2 callbacks)
> 
> Note that by default io_close2 is set to io_close2_default() which calls
> avio_close(), so default case will work the same as before.
> 
> Signed-off-by: Kacper Michajłow 
> ---
>  libavformat/demux.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libavformat/demux.c b/libavformat/demux.c
> index 2795863567..ecd4f40da9 100644
> --- a/libavformat/demux.c
> +++ b/libavformat/demux.c
> @@ -383,11 +383,10 @@ void avformat_close_input(AVFormatContext **ps)
>  if (ffifmt(s->iformat)->read_close)
>  ffifmt(s->iformat)->read_close(s);
>  
> +ff_format_io_close(s, &pb);
>  avformat_free_context(s);
>  
>  *ps = NULL;
> -
> -avio_close(pb);
>  }
>  
>  static void force_codec_ids(AVFormatContext *s, AVStream *st)

avformat_open_input() sets AVFMT_FLAG_CUSTOM_IO when using custom IO and
avformat_close_input() checks for this and does not free the
AVFormatContext's AVIOContext in this case (but does avio_close(NULL) in
this case).
Your patch furthermore presumes that the custom IO context is compatible
with io_close2, which need not be true at all (one can use custom IO
without ever touching io_open/io_close2 pointers; I expect users that
use custom IO, but not formats that open new AVIOContexts to do so).

- Andreas

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

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


[FFmpeg-devel] [PATCH] avfilter/version: Bump minor for avfilter_link_get_hw_frames_ctx()

2025-05-17 Thread Andreas Rheinhardt
Patch attached. (APIchanges even uses the wrong major version.)

- Andreas
From 51232a1e903fdd11bd6a3fd5d7b20dd970f259c3 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt 
Date: Sat, 17 May 2025 15:08:48 +0200
Subject: [PATCH] avfilter/version: Bump minor for
 avfilter_link_get_hw_frames_ctx()

Forgotten in e2f39671ae2b644eddc14f0b5d997569729c7843.
Also add the proper version in APIchanges.

Signed-off-by: Andreas Rheinhardt 
---
 doc/APIchanges| 2 +-
 libavfilter/version.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index d0869561f3..9048d4491a 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,7 +2,7 @@ The last version increases of all libraries were on 2025-03-28
 
 API changes, most recent first:
 
-2025-02-xx - xx - lavfi 10.10.100 - avfilter.h
+2025-05-15 - e2f39671ae - lavfi 11.1.100 - avfilter.h
   Add avfilter_link_get_hw_frames_ctx().
 
 2025-04-21 - xx - lavu 60.2.100 - log.h
diff --git a/libavfilter/version.h b/libavfilter/version.h
index d5a6bc143a..1e884d9b44 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -31,7 +31,7 @@
 
 #include "version_major.h"
 
-#define LIBAVFILTER_VERSION_MINOR   0
+#define LIBAVFILTER_VERSION_MINOR   1
 #define LIBAVFILTER_VERSION_MICRO 100
 
 
-- 
2.45.2

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

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


Re: [FFmpeg-devel] [PATCH v2 1/3] avcodec/libaribb24: change new lines to \n in ASS header

2025-05-17 Thread Marton Balint



On Fri, 9 Aug 2024, Kacper Michajlow wrote:


On Fri, 9 Aug 2024 at 00:04, Jan Ekström  wrote:


On Fri, May 10, 2024 at 11:31 PM Kacper Michajłow  wrote:
>
> Fixes remaining \r\n is ASS header after 57c545090d.
>
> Signed-off-by: Kacper Michajłow 
> ---

With an initial look this set looks good. If I understand correctly,
the generic ASS encoder moved to outputting LF only in
7bf1b9b35769b37684dd2f18a54f01d852a540c8 and thus these modules which
still output manual headers with CRLF cause mismatching endlines
within a single document.


This patchest indeed fixes mismatched endlines, but the main thing it fixes is
libzvbi_teletextdec converter which currently always returns
AVERROR_BUG, because default style no longer matches (after 7bf1b9b35)
the `strstr` expectation.
https://github.com/FFmpeg/FFmpeg/blob/c390234da2e3c7a8884f5592f0b9b4928c482b3e/libavcodec/libzvbi-teletextdec.c#L94

   event_pos = strstr(avctx->subtitle_header, "\r\n[Events]\r\n");
   if (!event_pos)
   return AVERROR_BUG;


It seems this patchset got forgotten, I will apply.

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

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


Re: [FFmpeg-devel] [PATCH] avformat/flvenc: Specify codec tag with MKTAG

2025-05-17 Thread Timo Rothenpieler

On 17.05.2025 16:05, Zhao Zhili wrote:




On May 17, 2025, at 19:14, Timo Rothenpieler  wrote:

On 17.05.2025 06:35, Zhao Zhili wrote:

在 2025年5月17日,上午1:39,Timo Rothenpieler  写道:

On 16.05.2025 19:24, Zhao Zhili wrote:

On May 17, 2025, at 01:10, Zhao Zhili  
wrote:





On May 17, 2025, at 00:27, Timo Rothenpieler  wrote:

On 16.05.2025 17:59, Zhao Zhili wrote:

On May 16, 2025, at 22:52, Timo Rothenpieler  wrote:

On 16/05/2025 16:24, Zhao Zhili wrote:

From: Zhao Zhili mailto:zhiliz...@tencent.com>>
ffmpeg -i input.mp4 -c copy -tag:v av01 output.flv
[flv @ 0x143204080] Tag av01 incompatible with output codec id '225' (10va)


I don't quite understand what causes this.
Is this an issue when running on big endian architectures?
I'm pretty sure I tested all combinations of codecs with muxing and demuxing, 
and never ran into that error.

The key point is when specify tag via command line, e.g., -tag:v av01, it’s
passed to AVCodecParameters codec_tag in little endian.
You didn’t see the error because without specify the tag explicitly, codec_tag 
is copied
from AVOutputFormat codec_tag to AVCodecParameters codec_tag, so they are
the same.
Another example is codec_mp4_tags.


This still irks me as wrong.
There is _a lot_ of places all over flvenv.c, in all kinds of functions, that 
hard-depend on the values in par->codec_tag being from the _codec_ids tables at 
the top of the file.
Like, they contain flv specific audio and video codec IDs for the pre-ext-flv 
codecs, those would all also break.

So there seems to be a deeper issue there if those values can be overridden 
from the commandline. The encoder clearly does not expect that.

Looking at the code this error comes from:
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mux.c#L314

It looks to to me like it's working exactly as intended and required by flvenc, 
protecting it from invalid tags.

So, when the user provides a custom tag that is invalid, isn't that kinda on 
the user?
The check you're running into does what it's supposed to:
It detects that the provided tag is invalid for this codec in this container.

Why do you want to override it anyway? There is only exactly one valid tag for 
each codec.


A user shows the error message to me. Because he know there are -tag option for 
mp4, and
enhanced-rtmp use fourcc for extended codecs, so he thought it should work.

The -tag:v av01 is redundant, it should be a NOP, not trigger error. The 
strings “av01”
is the right order of fourcc in spec. The endian issue should be limited to the 
internal.
Current error message is confusing, because it shows 10va instead of av01.

Doc from Microsoft shows fourcc use small endian
https://learn.microsoft.com/en-us/windows/win32/directshow/fourcc-codes
While wiki and enhanced rtmp spec says it’s big endian
https://en.wikipedia.org/wiki/FourCC
It’s clear in av_fourcc_make_string
that we use small endian.
For normal codec id in flv, e.g, 7 for H.264, it’s not a big issue, since 
they’re not fourcc.


This patch just fixes it for a very small subset of codecs in flv though.
There's nothing indicating that -tag:v is needed or sensibly supported in 
flvenc.
If you'd want to pass h264 or aac as fourcc, it'd be flat out impossible, and 
no easy fix is available.

I'd rather not complicate flvenc, even if just a little bit, just to swap 
around the endianness of the few codecs that do use a fourcc based tag.

flvenv should probably just completely ignore -tag:v, since the option makes no 
sense for it anyway.

I can remove setting tag list to AVOutputFormat, does that works for you?


Won't that break even more things?
The code heavily relies on the tags being what they are, and passing the tag 
list to AVOutputFormat would remove avformat enforcing that, with said error 
when trying to override it with something invalid.


The enforcing logic has a precondition, that codec_tag is in little endian.
flv_video_codec_ids and flv_audio_codec_ids don’t match this requirement.


That's not true, it correctly enforces it to what's in the tag array.
It makes sure that for each codec in there, the tag can only be one 
that's listed.




I honestly don't think anything needs to be changed at all.
Passing custom tags is simply not something flv sensibly supports.


AVOutputFormat codec_tag is API exported to users. Even if users
are not supposed to pass codec_tag to flvenc, the exported information
should match the tradition, that codec_tag is in little endian according to
the code in av_fourcc_make_string, mov, matroska, and so on.


Only a very small handful of codecs in flv even use a human-readable 
tag, the others are just arbitrary numbers.
I really don't understand why it'd matter if those are in big or little 
endian order. They cannot be changed, passing the via -tag:v achieves 
nothing.

Not a single codec flv can write has an alternative tag available to it.


There is no explicit documentation on the endian issue of codec_tag.
I hope developers familiar with th

Re: [FFmpeg-devel] [PATCH 1/3] ffmpeg: Don't print graphs if there are no graphs to print

2025-05-17 Thread Mark Thompson
On 17/05/2025 18:52, softworkz . wrote:
> 
> 
>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of Mark
>> Thompson
>> Sent: Samstag, 17. Mai 2025 13:14
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH 1/3] ffmpeg: Don't print graphs if there are 
>> no
>> graphs to print
>>
>> Avoids writing an empty json blob in setup error cases.
>> ---
>>  fftools/ffmpeg.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
>> index 964770df23..ad28cff78d 100644
>> --- a/fftools/ffmpeg.c
>> +++ b/fftools/ffmpeg.c
>> @@ -309,7 +309,8 @@ const AVIOInterruptCB int_cb = { decode_interrupt_cb, 
>> NULL
>> };
>>
>>  static void ffmpeg_cleanup(int ret)
>>  {
>> -if (print_graphs || print_graphs_file)
>> +if ((print_graphs || print_graphs_file) &&
>> +(nb_filtergraphs > 0 || nb_output_files > 0))
>>  print_filtergraphs(filtergraphs, nb_filtergraphs, input_files,
>> nb_input_files, output_files, nb_output_files);
> 
> The feature is not just about filter graphs, that's why it's been renamed
> as "Execution Graph Printing". It also works when no filter graphs are
> in play at all. 
> Here's an example:
> 
> https://softworkz.github.io/ffmpeg_output_apis/1_nofilters_3_in_1_out.html
> 
> 
> As for the nb_output_files check, I'm not sure - is it 0 or 1 in case of
> -f null output?

1, including when you stream copy to null and there aren't any real graphs.  At 
least one output is mandatory for a valid command line, so it should always 
appear in non-error cases as far as I am aware.

The aim is to avoid to the nonsense json blob when an early error happens - 
example below.  It does still get printed on later errors (such as a muxer 
error), because the graph is created then and some operations will have 
happened at that point.

Thanks,

- Mark


$ ./ffmpeg_g -print_graphs -i nonexistent -f null -
...
[in#0 @ 0x51300200] Error opening input: No such file or directory
Error opening input file nonexistent.
Error opening input files: No such file or directory
{
"graphs": [

],
"inputfiles": [
{
"index": "0",
"inputstreams": [

]
}
],
"decoders": [

],
"encoders": [

],
"outputfiles": [

],
"streamlinks": [

]
}

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

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


Re: [FFmpeg-devel] [PATCH 1/3] ffmpeg: Don't print graphs if there are no graphs to print

2025-05-17 Thread softworkz .



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Mark
> Thompson
> Sent: Samstag, 17. Mai 2025 20:19
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] ffmpeg: Don't print graphs if there
> are no graphs to print
> 
> On 17/05/2025 18:52, softworkz . wrote:
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of Mark
> >> Thompson
> >> Sent: Samstag, 17. Mai 2025 13:14
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: [FFmpeg-devel] [PATCH 1/3] ffmpeg: Don't print graphs if there are
> no
> >> graphs to print
> >>
> >> Avoids writing an empty json blob in setup error cases.
> >> ---
> >>  fftools/ffmpeg.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> >> index 964770df23..ad28cff78d 100644
> >> --- a/fftools/ffmpeg.c
> >> +++ b/fftools/ffmpeg.c
> >> @@ -309,7 +309,8 @@ const AVIOInterruptCB int_cb = { decode_interrupt_cb,
> NULL
> >> };
> >>
> >>  static void ffmpeg_cleanup(int ret)
> >>  {
> >> -if (print_graphs || print_graphs_file)
> >> +if ((print_graphs || print_graphs_file) &&
> >> +(nb_filtergraphs > 0 || nb_output_files > 0))
> >>  print_filtergraphs(filtergraphs, nb_filtergraphs, input_files,
> >> nb_input_files, output_files, nb_output_files);
> >
> > The feature is not just about filter graphs, that's why it's been renamed
> > as "Execution Graph Printing". It also works when no filter graphs are
> > in play at all.
> > Here's an example:
> >
> > https://softworkz.github.io/ffmpeg_output_apis/1_nofilters_3_in_1_out.html
> >
> >
> > As for the nb_output_files check, I'm not sure - is it 0 or 1 in case of
> > -f null output?
> 
> 1, including when you stream copy to null and there aren't any real graphs.
> At least one output is mandatory for a valid command line, so it should always
> appear in non-error cases as far as I am aware.
> 
> The aim is to avoid to the nonsense json blob when an early error happens -
> example below.  It does still get printed on later errors (such as a muxer
> error), because the graph is created then and some operations will have
> happened at that point.
> 
> Thanks,
> 
> - Mark

Okay, thanks for the clarification, and yes - it's important to get the output
even in cases of error, but I agree that it doesn't need to be generated
as long as output files haven't been configured yet.

If you could resubmit without the nb_filtergraphs check that would be fine!

Thank you
sw



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

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


Re: [FFmpeg-devel] [PATCH 2/3] ffbuild: correctly silence and tag new css/html steps

2025-05-17 Thread softworkz .



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Timo
> Rothenpieler
> Sent: Samstag, 17. Mai 2025 01:02
> To: ffmpeg-devel@ffmpeg.org
> Cc: Timo Rothenpieler 
> Subject: [FFmpeg-devel] [PATCH 2/3] ffbuild: correctly silence and tag new
> css/html steps
> 
> ---
>  ffbuild/common.mak | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/ffbuild/common.mak b/ffbuild/common.mak
> index 4a3cc0c748..31ed19c141 100644
> --- a/ffbuild/common.mak
> +++ b/ffbuild/common.mak
> @@ -140,9 +140,9 @@ else
>  endif
> 
>  # 1) Preprocess CSS to a minified version
> +%.css.min: TAG = SED
>  %.css.min: %.css
> - # Must start with a tab in the real Makefile
> - sed 's!/\\*.*\\*/!!g' $< \
> + $(M)sed 's!/\\*.*\\*/!!g' $< \
>   | tr '\n' ' ' \
>   | tr -s ' ' \
>   | sed 's/^ //; s/ $$//' \
> @@ -151,6 +151,7 @@ endif
>  ifdef CONFIG_RESOURCE_COMPRESSION
> 
>  # 2) Gzip the minified CSS
> +%.css.min.gz: TAG = GZIP
>  %.css.min.gz: %.css.min
>   $(M)gzip -nc9 $< > $@
> 
> @@ -159,6 +160,7 @@ ifdef CONFIG_RESOURCE_COMPRESSION
>   $(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
> 
>  # 4) Gzip the HTML file (no minification needed)
> +%.html.gz: TAG = GZIP
>  %.html.gz: %.html
>   $(M)gzip -nc9 $< > $@
> 
> --

Thanks for the patch. I had those tags in earlier revisions, dropped them
while investigating the OOT build issue and then forgotten to re-add.

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

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


Re: [FFmpeg-devel] [PATCH v5 6/7] ogg/vorbis: implement header packet skip in chained ogg bitstreams.

2025-05-17 Thread Romain Beauxis
Le mar. 13 mai 2025 à 14:23, Michael Niedermayer  a
écrit :
>
> On Fri, May 09, 2025 at 06:43:26PM -0500, Romain Beauxis wrote:
> > ---
> >  libavcodec/vorbisdec.c |  37 +
> >  libavformat/oggparsevorbis.c   | 174 +
> >  tests/ref/fate/ogg-vorbis-chained-meta.txt |   3 -
> >  3 files changed, 117 insertions(+), 97 deletions(-)
> >
> > diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c
> > index a778dc6b58..f069ac6ab3 100644
> > --- a/libavcodec/vorbisdec.c
> > +++ b/libavcodec/vorbisdec.c
> > @@ -1776,39 +1776,17 @@ static int vorbis_decode_frame(AVCodecContext
*avctx, AVFrame *frame,
> >  GetBitContext *gb = &vc->gb;
> >  float *channel_ptrs[255];
> >  int i, len, ret;
> > +const int8_t *new_extradata;
> > +size_t new_extradata_size;
> >
> >  ff_dlog(NULL, "packet length %d \n", buf_size);
> >
> > -if (*buf == 1 && buf_size > 7) {
> > -if ((ret = init_get_bits8(gb, buf + 1, buf_size - 1)) < 0)
> > -return ret;
> > -
> > -vorbis_free(vc);
> > -if ((ret = vorbis_parse_id_hdr(vc))) {
> > -av_log(avctx, AV_LOG_ERROR, "Id header corrupt.\n");
> > -vorbis_free(vc);
> > -return ret;
> > -}
> > -
> > -av_channel_layout_uninit(&avctx->ch_layout);
> > -if (vc->audio_channels > 8) {
> > -avctx->ch_layout.order   = AV_CHANNEL_ORDER_UNSPEC;
> > -avctx->ch_layout.nb_channels = vc->audio_channels;
> > -} else {
> > -av_channel_layout_copy(&avctx->ch_layout,
&ff_vorbis_ch_layouts[vc->audio_channels - 1]);
> > -}
> > -
> > -avctx->sample_rate = vc->audio_samplerate;
> > -return buf_size;
> > -}
> > -
> > -if (*buf == 3 && buf_size > 7) {
> > -av_log(avctx, AV_LOG_DEBUG, "Ignoring comment header\n");
> > -return buf_size;
> > -}
> > +new_extradata = av_packet_get_side_data(avpkt,
AV_PKT_DATA_NEW_EXTRADATA,
> > +&new_extradata_size);
> >
> > -if (*buf == 5 && buf_size > 7 && vc->channel_residues &&
!vc->modes) {
> > -if ((ret = init_get_bits8(gb, buf + 1, buf_size - 1)) < 0)
> > +if (new_extradata && *new_extradata == 5 && new_extradata_size > 7
&&
> > +vc->channel_residues && !vc->modes) {
> > +if ((ret = init_get_bits8(gb, new_extradata + 1,
new_extradata_size - 1)) < 0)
> >  return ret;
> >
> >  if ((ret = vorbis_parse_setup_hdr(vc))) {
> > @@ -1816,7 +1794,6 @@ static int vorbis_decode_frame(AVCodecContext
*avctx, AVFrame *frame,
> >  vorbis_free(vc);
> >  return ret;
> >  }
> > -return buf_size;
> >  }
> >
> >  if (!vc->channel_residues || !vc->modes) {
> > diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c
> > index 9f50ab9ffc..452728b54d 100644
> > --- a/libavformat/oggparsevorbis.c
> > +++ b/libavformat/oggparsevorbis.c
> > @@ -293,6 +293,62 @@ static int vorbis_update_metadata(AVFormatContext
*s, int idx)
> >  return ret;
> >  }
> >
> > +static int vorbis_parse_header(AVFormatContext *s, AVStream *st,
> > +   const uint8_t *p, unsigned int psize)
> > +{
> > +unsigned blocksize, bs0, bs1;
> > +int srate;
> > +int channels;
> > +
> > +if (psize != 30)
> > +return AVERROR_INVALIDDATA;
> > +
> > +p += 7; /* skip "\001vorbis" tag */
> > +
> > +if (bytestream_get_le32(&p) != 0) /* vorbis_version */
> > +return AVERROR_INVALIDDATA;
> > +
> > +channels = bytestream_get_byte(&p);
> > +if (st->codecpar->ch_layout.nb_channels &&
> > +channels != st->codecpar->ch_layout.nb_channels) {
> > +av_log(s, AV_LOG_ERROR, "Channel change is not supported\n");
> > +return AVERROR_PATCHWELCOME;
> > +}
> > +st->codecpar->ch_layout.nb_channels = channels;
> > +srate   = bytestream_get_le32(&p);
> > +p += 4; // skip maximum bitrate
> > +st->codecpar->bit_rate = bytestream_get_le32(&p); // nominal
bitrate
> > +p += 4; // skip minimum bitrate
> > +
> > +blocksize = bytestream_get_byte(&p);
> > +bs0   = blocksize & 15;
> > +bs1   = blocksize >> 4;
> > +
> > +if (bs0 > bs1)
> > +return AVERROR_INVALIDDATA;
> > +if (bs0 < 6 || bs1 > 13)
> > +return AVERROR_INVALIDDATA;
> > +
> > +if (bytestream_get_byte(&p) != 1) /* framing_flag */
> > +return AVERROR_INVALIDDATA;
> > +
> > +st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
> > +st->codecpar->codec_id   = AV_CODEC_ID_VORBIS;
> > +
> > +if (srate > 0) {
> > +if (st->codecpar->sample_rate &&
> > +srate != st->codecpar->sample_rate) {
> > +av_log(s, AV_LOG_ERROR, "Sample rate change is not
supported\n");
> > +return AVERROR_PATCHWELCOME;
> > +}
> > +
> > +st->codecpar->sample_rate = srat

Re: [FFmpeg-devel] [PATCH 3/3] fftools/graphprint: Fix leak of graph section header string

2025-05-17 Thread softworkz .



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Mark
> Thompson
> Sent: Samstag, 17. Mai 2025 13:14
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 3/3] fftools/graphprint: Fix leak of graph
> section header string
> 
> ---
>  fftools/graph/graphprint.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fftools/graph/graphprint.c b/fftools/graph/graphprint.c
> index 9e3e03274a..50f1a2ecdc 100644
> --- a/fftools/graph/graphprint.c
> +++ b/fftools/graph/graphprint.c
> @@ -780,6 +780,8 @@ static int print_streams(GraphPrintContext *gpc, InputFile
> **ifiles, int nb_ifil
> 
>  avtext_print_section_header(tfc, &sec_ctx, SECTION_ID_OUTPUTSTREAMS);
> 
> +av_freep(&sec_ctx.context_id);
> +
>  for (int i = 0; i < of->nb_streams; i++) {
>  OutputStream *ost = of->streams[i];
>  const AVCodecDescriptor *codec_desc = avcodec_descriptor_get(ost-
> >st->codecpar->codec_id);
> --

LGTM - thanks for the patch!

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 1/2] avformat/demux: use io_close2 when closing avfromat

2025-05-17 Thread Kacper Michajlow
On Sat, 17 May 2025 at 15:03, Andreas Rheinhardt
 wrote:
>
> Andreas Rheinhardt:
> > Kacper Michajłow:
> >> It's not valid to call avio_close() on context that has not been open
> >> with avio_open().
> >>
> >> This fixes use of custom IO. (io_open / io_close2 callbacks)
> >>
> >> Note that by default io_close2 is set to io_close2_default() which calls
> >> avio_close(), so default case will work the same as before.
> >>
> >> Signed-off-by: Kacper Michajłow 
> >> ---
> >>  libavformat/demux.c | 3 +--
> >>  1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/libavformat/demux.c b/libavformat/demux.c
> >> index 2795863567..ecd4f40da9 100644
> >> --- a/libavformat/demux.c
> >> +++ b/libavformat/demux.c
> >> @@ -383,11 +383,10 @@ void avformat_close_input(AVFormatContext **ps)
> >>  if (ffifmt(s->iformat)->read_close)
> >>  ffifmt(s->iformat)->read_close(s);
> >>
> >> +ff_format_io_close(s, &pb);
> >>  avformat_free_context(s);
> >>
> >>  *ps = NULL;
> >> -
> >> -avio_close(pb);
> >>  }
> >>
> >>  static void force_codec_ids(AVFormatContext *s, AVStream *st)
> >
> > avformat_open_input() sets AVFMT_FLAG_CUSTOM_IO when using custom IO and
> > avformat_close_input() checks for this and does not free the
> > AVFormatContext's AVIOContext in this case (but does avio_close(NULL) in
> > this case).
> > Your patch furthermore presumes that the custom IO context is compatible
> > with io_close2, which need not be true at all (one can use custom IO
> > without ever touching io_open/io_close2 pointers; I expect users that
> > use custom IO, but not formats that open new AVIOContexts to do so).
>
> On reading a bit further, init_input() uses io_open to open the
> AVIOContext in case no AVIOContext was supplied (and one is needed).
> This means that the AVFMT_FLAG_CUSTOM_IO flag is misleading, as it is
> possible to use custom IO even with this flag unset. It also means that
> your patch is likely correct.

Exactly. AVFMT_FLAG_CUSTOM_IO is used when an "external" AVIOContext
is provided. This is different when "custom" IO is used by changing
io_open/io_close2, where the lifetime of AVIOContext is still managed
internally, but uses custom implementation. I was initially confused
in exactly the same way you were, but those two "custom/external" IO
are not actually related.

Note that avformat_close_input() already zeroes the `pb` pointer if
the AVIOContext shouldn't be released, so ff_format_io_close() is noop
as expected for the AVFMT_FLAG_CUSTOM_IO case. (same as avio_close()
was).

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

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


[FFmpeg-devel] [PATCH v2] ffmpeg: Don't print graphs if there are no outputs yet

2025-05-17 Thread Mark Thompson
Avoids writing an empty json blob in setup error cases.
---
On 17/05/2025 20:08, softworkz . wrote:
> If you could resubmit without the nb_filtergraphs check that would be fine!

Sure, here.

Thanks,

- Mark

 fftools/ffmpeg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 964770df23..bd6f22e421 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -309,7 +309,7 @@ const AVIOInterruptCB int_cb = { decode_interrupt_cb, NULL 
};
 
 static void ffmpeg_cleanup(int ret)
 {
-if (print_graphs || print_graphs_file)
+if ((print_graphs || print_graphs_file) && nb_output_files > 0)
 print_filtergraphs(filtergraphs, nb_filtergraphs, input_files, 
nb_input_files, output_files, nb_output_files);
 
 if (do_benchmark) {
-- 
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".


Re: [FFmpeg-devel] [PATCH v2] ffmpeg: Don't print graphs if there are no outputs yet

2025-05-17 Thread softworkz .



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Mark
> Thompson
> Sent: Samstag, 17. Mai 2025 22:02
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2] ffmpeg: Don't print graphs if there are no
> outputs yet
> 
> Avoids writing an empty json blob in setup error cases.
> ---
> On 17/05/2025 20:08, softworkz . wrote:
> > If you could resubmit without the nb_filtergraphs check that would be fine!
> 
> Sure, here.
> 
> Thanks,
> 
> - Mark
> 
>  fftools/ffmpeg.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 964770df23..bd6f22e421 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -309,7 +309,7 @@ const AVIOInterruptCB int_cb = { decode_interrupt_cb, NULL
> };
> 
>  static void ffmpeg_cleanup(int ret)
>  {
> -if (print_graphs || print_graphs_file)
> +if ((print_graphs || print_graphs_file) && nb_output_files > 0)
>  print_filtergraphs(filtergraphs, nb_filtergraphs, input_files,
> nb_input_files, output_files, nb_output_files);
> 
>  if (do_benchmark) {
> --

Excellent, thanks a lot for reviewing the feature!

LGTM
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 3/4] fftools/graph/graphprint: load CSS and HTML resources from ffmpeg data directories

2025-05-17 Thread softworkz .



> -Original Message-
> From: ffmpeg-devel  On Behalf Of softworkz .
> Sent: Samstag, 17. Mai 2025 19:22
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH 3/4] fftools/graph/graphprint: load CSS and
> HTML resources from ffmpeg data directories
> 
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Marton
> > Balint
> > Sent: Samstag, 17. Mai 2025 11:14
> > To: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] [PATCH 3/4] fftools/graph/graphprint: load CSS
> and
> > HTML resources from ffmpeg data directories
> >
> >
> >
> > On Sat, 17 May 2025, softworkz . wrote:
> >
> > >
> > >
> > >> -Original Message-
> > >> From: ffmpeg-devel  On Behalf Of Marton
> > >> Balint
> > >> Sent: Samstag, 17. Mai 2025 01:09
> > >> To: ffmpeg-devel@ffmpeg.org
> > >> Cc: Marton Balint 
> > >> Subject: [FFmpeg-devel] [PATCH 3/4] fftools/graph/graphprint: load CSS
> and
> > >> HTML resources from ffmpeg data directories
> > >>
> > >> Similar to how it is done for ffpreset files. This allows the users to
> > change
> > >> the HTML/CSS templates at will.
> > >>
> > >> Signed-off-by: Marton Balint 
> > >> ---
> > >>  Makefile|  2 +-
> > >>  doc/ffmpeg.texi |  4 ++-
> > >>  fftools/cmdutils.c  | 48 +
> > >>  fftools/cmdutils.h  |  2 ++
> > >>  fftools/graph/graphprint.c  | 16 ---
> > >>  fftools/textformat/tf_mermaid.h |  4 +--
> > >>  6 files changed, 68 insertions(+), 8 deletions(-)
> > >>
> > >> diff --git a/Makefile b/Makefile
> > >> index e2250f6bc6..ebc50bb510 100644
> > >> --- a/Makefile
> > >> +++ b/Makefile
> > >> @@ -32,7 +32,7 @@ FFLIBS-$(CONFIG_SWSCALE)+= swscale
> > >>
> > >>  FFLIBS := avutil
> > >>
> > >> -DATA_FILES := $(wildcard $(SRC_PATH)/presets/*.ffpreset)
> > >> $(SRC_PATH)/doc/ffprobe.xsd
> > >> +DATA_FILES := $(wildcard $(SRC_PATH)/presets/*.ffpreset)
> > >> $(SRC_PATH)/doc/ffprobe.xsd $(SRC_PATH)/fftools/resources/graph.css
> > >> $(SRC_PATH)/fftools/resources/graph.html
> > >>
> > >>  SKIPHEADERS = compat/w32pthreads.h
> > >>
> > >> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > >> index 35675b5309..8edf188ab9 100644
> > >> --- a/doc/ffmpeg.texi
> > >> +++ b/doc/ffmpeg.texi
> > >> @@ -1402,7 +1402,9 @@ Writes execution graph details to the specified
> file
> > in
> > >> the format set via -prin
> > >>
> > >>  @item -print_graphs_format @var{format} (@emph{global})
> > >>  Sets the output format (available formats are: default, compact, csv,
> > flat,
> > >> ini, json, xml, mermaid, mermaidhtml)
> > >> -The default format is json.
> > >> +The default format is json. The mermarid and mermaidhtml formats need
> > >> graph.css
> > >> +and graph.html resources which are searched in the FFMPEG data
> > directories,
> > >> +similar to ffpreset files.
> > >>
> > >>  @item -progress @var{url} (@emph{global})
> > >>  Send program-friendly progress information to @var{url}.
> > >> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> > >> index 1de670c2e4..01e57d91e8 100644
> > >> --- a/fftools/cmdutils.c
> > >> +++ b/fftools/cmdutils.c
> > >> @@ -1005,6 +1005,54 @@ FILE *get_preset_file(AVBPrint *filename,
> > >>  return f;
> > >>  }
> > >>
> > >> +int file_read_from_datadir(const char *filename, char **outbuf)
> > >> +{
> > >> +FILE *f;
> > >> +char *buf = NULL;
> > >> +long size;
> > >> +AVBPrint bp;
> > >> +
> > >> +av_bprint_init(&bp, 0, AV_BPRINT_SIZE_UNLIMITED);
> > >> +f = get_datadir_file_fmt(&bp, "%s", filename);
> > >> +if (!f)
> > >> +return AVERROR(errno);
> > >> +
> > >> +if (fseek(f, 0, SEEK_END)) {
> > >> +int ret = AVERROR(errno);
> > >> +fclose(f);
> > >> +return ret;
> > >> +}
> > >> +
> > >> +size = ftell(f);
> > >> +if (size < 0 || size >= INT_MAX) {
> > >> +fclose(f);
> > >> +return AVERROR(EINVAL);
> > >> +}
> > >> +
> > >> +if (fseek(f, 0, SEEK_SET)) {
> > >> +int ret = AVERROR(errno);
> > >> +fclose(f);
> > >> +return ret;
> > >> +}
> > >> +
> > >> +buf = av_malloc(size + 1);
> > >> +if (!buf) {
> > >> +fclose(f);
> > >> +return AVERROR(ENOMEM);
> > >> +}
> > >> +
> > >> +if (fread(buf, 1, size, f) != size) {
> > >> +fclose(f);
> > >> +return AVERROR(EIO);
> > >> +}
> > >> +buf[size] = 0;
> > >> +
> > >> +fclose(f);
> > >> +
> > >> +*outbuf = buf;
> > >> +return 0;
> > >> +}
> > >> +
> > >>  int cmdutils_isalnum(char c)
> > >>  {
> > >>  return (c >= '0' && c <= '9') ||
> > >> diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
> > >> index 216a2bcfe7..b324e5fc65 100644
> > >> --- a/fftools/cmdutils.h
> > >> +++ b/fftools/cmdutils.h
> > >> @@ -504,6 +504,8 @@ int read_yesno(void);
> > >>  FILE *get_preset_file(AVBPrint *filename,
> > >>const char *prese

[FFmpeg-devel] [PATCH v4 1/4] libavcodec/vc2enc: Split out common functions between software and hardware encoders

2025-05-17 Thread IndecisiveTurtle
From: IndecisiveTurtle 

---
 libavcodec/Makefile|   2 +-
 libavcodec/vc2enc.c| 679 ++---
 libavcodec/vc2enc_common.c | 571 +++
 libavcodec/vc2enc_common.h | 178 ++
 4 files changed, 772 insertions(+), 658 deletions(-)
 create mode 100644 libavcodec/vc2enc_common.c
 create mode 100644 libavcodec/vc2enc_common.h

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 77734dff24..bdf0d6742e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -771,7 +771,7 @@ OBJS-$(CONFIG_VC1_CUVID_DECODER)   += cuviddec.o
 OBJS-$(CONFIG_VC1_MMAL_DECODER)+= mmaldec.o
 OBJS-$(CONFIG_VC1_QSV_DECODER) += qsvdec.o
 OBJS-$(CONFIG_VC1_V4L2M2M_DECODER) += v4l2_m2m_dec.o
-OBJS-$(CONFIG_VC2_ENCODER) += vc2enc.o vc2enc_dwt.o diractab.o
+OBJS-$(CONFIG_VC2_ENCODER) += vc2enc.o vc2enc_dwt.o 
vc2enc_common.o diractab.o
 OBJS-$(CONFIG_VCR1_DECODER)+= vcr1.o
 OBJS-$(CONFIG_VMDAUDIO_DECODER)+= vmdaudio.o
 OBJS-$(CONFIG_VMDVIDEO_DECODER)+= vmdvideo.o
diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 99ca95c40a..939bafa195 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -30,505 +30,11 @@
 #include "put_bits.h"
 #include "version.h"
 
-#include "vc2enc_dwt.h"
-#include "diractab.h"
-
-/* The limited size resolution of each slice forces us to do this */
-#define SSIZE_ROUND(b) (FFALIGN((b), s->size_scaler) + 4 + s->prefix_bytes)
+#include "vc2enc_common.h"
 
 /* Decides the cutoff point in # of slices to distribute the leftover bytes */
 #define SLICE_REDIST_TOTAL 150
 
-typedef struct VC2BaseVideoFormat {
-enum AVPixelFormat pix_fmt;
-AVRational time_base;
-int width, height;
-uint8_t interlaced, level;
-char name[13];
-} VC2BaseVideoFormat;
-
-static const VC2BaseVideoFormat base_video_fmts[] = {
-{ 0 }, /* Custom format, here just to make indexing equal to base_vf */
-{ AV_PIX_FMT_YUV420P,   { 1001, 15000 },  176,  120, 0, 1, "QSIF525" },
-{ AV_PIX_FMT_YUV420P,   {2,25 },  176,  144, 0, 1, "QCIF"},
-{ AV_PIX_FMT_YUV420P,   { 1001, 15000 },  352,  240, 0, 1, "SIF525"  },
-{ AV_PIX_FMT_YUV420P,   {2,25 },  352,  288, 0, 1, "CIF" },
-{ AV_PIX_FMT_YUV420P,   { 1001, 15000 },  704,  480, 0, 1, "4SIF525" },
-{ AV_PIX_FMT_YUV420P,   {2,25 },  704,  576, 0, 1, "4CIF"},
-
-{ AV_PIX_FMT_YUV422P10, { 1001, 3 },  720,  480, 1, 2,   "SD480I-60" },
-{ AV_PIX_FMT_YUV422P10, {1,25 },  720,  576, 1, 2,   "SD576I-50" },
-
-{ AV_PIX_FMT_YUV422P10, { 1001, 6 }, 1280,  720, 0, 3,  "HD720P-60"  },
-{ AV_PIX_FMT_YUV422P10, {1,50 }, 1280,  720, 0, 3,  "HD720P-50"  },
-{ AV_PIX_FMT_YUV422P10, { 1001, 3 }, 1920, 1080, 1, 3,  "HD1080I-60" },
-{ AV_PIX_FMT_YUV422P10, {1,25 }, 1920, 1080, 1, 3,  "HD1080I-50" },
-{ AV_PIX_FMT_YUV422P10, { 1001, 6 }, 1920, 1080, 0, 3,  "HD1080P-60" },
-{ AV_PIX_FMT_YUV422P10, {1,50 }, 1920, 1080, 0, 3,  "HD1080P-50" },
-
-{ AV_PIX_FMT_YUV444P12, {1,24 }, 2048, 1080, 0, 4,"DC2K" },
-{ AV_PIX_FMT_YUV444P12, {1,24 }, 4096, 2160, 0, 5,"DC4K" },
-
-{ AV_PIX_FMT_YUV422P10, { 1001, 6 }, 3840, 2160, 0, 6, "UHDTV 4K-60" },
-{ AV_PIX_FMT_YUV422P10, {1,50 }, 3840, 2160, 0, 6, "UHDTV 4K-50" },
-
-{ AV_PIX_FMT_YUV422P10, { 1001, 6 }, 7680, 4320, 0, 7, "UHDTV 8K-60" },
-{ AV_PIX_FMT_YUV422P10, {1,50 }, 7680, 4320, 0, 7, "UHDTV 8K-50" },
-
-{ AV_PIX_FMT_YUV422P10, { 1001, 24000 }, 1920, 1080, 0, 3,  "HD1080P-24" },
-{ AV_PIX_FMT_YUV422P10, { 1001, 3 },  720,  486, 1, 2,  "SD Pro486"  },
-};
-static const int base_video_fmts_len = FF_ARRAY_ELEMS(base_video_fmts);
-
-enum VC2_QM {
-VC2_QM_DEF = 0,
-VC2_QM_COL,
-VC2_QM_FLAT,
-
-VC2_QM_NB
-};
-
-typedef struct SubBand {
-dwtcoef *buf;
-ptrdiff_t stride;
-int width;
-int height;
-} SubBand;
-
-typedef struct Plane {
-SubBand band[MAX_DWT_LEVELS][4];
-dwtcoef *coef_buf;
-int width;
-int height;
-int dwt_width;
-int dwt_height;
-ptrdiff_t coef_stride;
-} Plane;
-
-typedef struct SliceArgs {
-const struct VC2EncContext *ctx;
-union {
-int cache[DIRAC_MAX_QUANT_INDEX];
-uint8_t *buf;
-};
-int x;
-int y;
-int quant_idx;
-int bits_ceil;
-int bits_floor;
-int bytes;
-} SliceArgs;
-
-typedef struct TransformArgs {
-const struct VC2EncContext *ctx;
-Plane *plane;
-const void *idata;
-ptrdiff_t istride;
-int field;
-VC2TransformContext t;
-} TransformArgs;
-
-typedef struct VC2EncContext {
-AVClass *av_class;
-PutBitContext pb;
-Plane plane[3];
-AVCodecContext *avctx;
-DiracVersionInfo ver;
-
-SliceArgs *slice_args;
-TransformArgs transform_args[3];
-
-/* For conversion from unsigne

[FFmpeg-devel] [PATCH v4 3/4] libavcodec/vulkan: Add modifications to common shader for VC2 vulkan encoder

2025-05-17 Thread IndecisiveTurtle
From: IndecisiveTurtle 

---
 libavcodec/vulkan/common.comp | 54 ---
 1 file changed, 44 insertions(+), 10 deletions(-)

diff --git a/libavcodec/vulkan/common.comp b/libavcodec/vulkan/common.comp
index 10af9c0623..db216a2ac6 100644
--- a/libavcodec/vulkan/common.comp
+++ b/libavcodec/vulkan/common.comp
@@ -18,6 +18,9 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#extension GL_EXT_buffer_reference : require
+#extension GL_EXT_buffer_reference2 : require
+
 layout(buffer_reference, buffer_reference_align = 1) buffer u8buf {
 uint8_t v;
 };
@@ -61,22 +64,20 @@ layout(buffer_reference, buffer_reference_align = 8) buffer 
u64buf {
 #define mid_pred(a, b, c) \
 max(min((a), (b)), min(max((a), (b)), (c)))
 
-/* TODO: optimize */
+
 uint align(uint src, uint a)
 {
-uint res = src % a;
-if (res == 0)
-return src;
-return src + a - res;
+return (src + a - 1) & ~(a - 1);
+}
+
+int align(int src, int a)
+{
+return (src + a - 1) & ~(a - 1);
 }
 
-/* TODO: optimize */
 uint64_t align64(uint64_t src, uint64_t a)
 {
-uint64_t res = src % a;
-if (res == 0)
-return src;
-return src + a - res;
+return (src + a - 1) & ~(a - 1);
 }
 
 #define reverse4(src) \
@@ -167,6 +168,39 @@ uint32_t flush_put_bits(inout PutBitContext pb)
 return uint32_t(pb.buf - pb.buf_start);
 }
 
+void skip_put_bytes(inout PutBitContext pb, int n)
+{
+int bytes_left = pb.bit_left >> 3;
+if (n < bytes_left)
+{
+int n_bits = n << 3;
+int mask = (1 << n_bits) - 1;
+pb.bit_buf <<= n_bits;
+pb.bit_buf |= mask;
+pb.bit_left -= uint8_t(n_bits);
+return;
+}
+if (pb.bit_left < BUF_BITS)
+{
+int mask = (1 << pb.bit_left) - 1;
+pb.bit_buf <<= pb.bit_left;
+pb.bit_buf |= mask;
+u32vec2buf(pb.buf).v = BUF_REVERSE(pb.bit_buf);
+pb.buf += BUF_BYTES;
+n -= pb.bit_left >> 3;
+}
+int skip_dwords = n >> 2;
+while (skip_dwords > 0)
+{
+u8vec4buf(pb.buf).v = u8vec4(0xFF);
+pb.buf += 4;
+skip_dwords--;
+}
+int skip_bits = (n & 3) << 3;
+pb.bit_buf = (1 << skip_bits) - 1;
+pb.bit_left = uint8_t(BUF_BITS - skip_bits);
+}
+
 void init_put_bits(out PutBitContext pb, u8buf data, uint64_t len)
 {
 pb.buf_start = uint64_t(data);
-- 
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 v4 2/4] libavcodec/vc2enc: Switch quant to int

2025-05-17 Thread IndecisiveTurtle
From: IndecisiveTurtle 

Prevents compiler from mistaking it as a string
Also makes passing it to the GPU in a buffer easier
---
 libavcodec/vc2enc_common.c | 2 +-
 libavcodec/vc2enc_common.h | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vc2enc_common.c b/libavcodec/vc2enc_common.c
index bd27fd3c40..d4415674e7 100644
--- a/libavcodec/vc2enc_common.c
+++ b/libavcodec/vc2enc_common.c
@@ -304,7 +304,7 @@ static const uint8_t vc2_qm_flat_tab[][4] = {
 { 0,  0,  0,  0}
 };
 
-void ff_vc2_init_quant_matrix(VC2EncContext *s, uint8_t 
quant[MAX_DWT_LEVELS][4])
+void ff_vc2_init_quant_matrix(VC2EncContext *s, int quant[MAX_DWT_LEVELS][4])
 {
 int level, orientation;
 
diff --git a/libavcodec/vc2enc_common.h b/libavcodec/vc2enc_common.h
index 0466869943..159f72452e 100644
--- a/libavcodec/vc2enc_common.h
+++ b/libavcodec/vc2enc_common.h
@@ -108,7 +108,7 @@ typedef struct VC2EncContext {
 int profile;
 
 /* Quantization matrix */
-uint8_t quant[MAX_DWT_LEVELS][4];
+int quant[MAX_DWT_LEVELS][4];
 int custom_quant_matrix;
 
 /* Division LUT */
@@ -169,7 +169,7 @@ int ff_vc2_encode_init(AVCodecContext *avctx, int depth);
 
 int ff_vc2_frame_init_properties(AVCodecContext *avctx, VC2EncContext *s);
 
-void ff_vc2_init_quant_matrix(VC2EncContext *s, uint8_t 
quant[MAX_DWT_LEVELS][4]);
+void ff_vc2_init_quant_matrix(VC2EncContext *s, int quant[MAX_DWT_LEVELS][4]);
 
 void ff_vc2_encode_frame(VC2EncContext *s, 
void(*encode_slices)(VC2EncContext*));
 
-- 
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 v4 4/4] lavc: implement a Vulkan-based VC-2 encoder Implements a Vulkan based dirac encoder. Supports Haar and Legall wavelets and should work with all wavelet depths.

2025-05-17 Thread IndecisiveTurtle
From: IndecisiveTurtle 

Performance wise, encoding a 3440x1440 1-minute video is performed in about 2.4 
minutes with the cpu encoder running on my Ryzen 5 4600H, while it takes about 
1.3 minutes on my NVIDIA GTX 1650

Haar shader has a subgroup optimized variant that applies when configured 
wavelet depth allows it
---
 configure|   1 +
 libavcodec/Makefile  |   3 +
 libavcodec/allcodecs.c   |   1 +
 libavcodec/vc2enc_vulkan.c   | 775 +++
 libavcodec/vulkan/vc2_dwt_haar.comp  |  82 ++
 libavcodec/vulkan/vc2_dwt_haar_subgroup.comp |  75 ++
 libavcodec/vulkan/vc2_dwt_hor_legall.comp|  82 ++
 libavcodec/vulkan/vc2_dwt_upload.comp|  96 +++
 libavcodec/vulkan/vc2_dwt_ver_legall.comp|  78 ++
 libavcodec/vulkan/vc2_encode.comp| 159 
 libavcodec/vulkan/vc2_slice_sizes.comp   | 170 
 11 files changed, 1522 insertions(+)
 create mode 100644 libavcodec/vc2enc_vulkan.c
 create mode 100644 libavcodec/vulkan/vc2_dwt_haar.comp
 create mode 100644 libavcodec/vulkan/vc2_dwt_haar_subgroup.comp
 create mode 100644 libavcodec/vulkan/vc2_dwt_hor_legall.comp
 create mode 100644 libavcodec/vulkan/vc2_dwt_upload.comp
 create mode 100644 libavcodec/vulkan/vc2_dwt_ver_legall.comp
 create mode 100644 libavcodec/vulkan/vc2_encode.comp
 create mode 100644 libavcodec/vulkan/vc2_slice_sizes.comp

diff --git a/configure b/configure
index 2e69b3c56c..09f9dff258 100755
--- a/configure
+++ b/configure
@@ -3132,6 +3132,7 @@ utvideo_encoder_select="bswapdsp huffman llvidencdsp"
 vble_decoder_select="llviddsp"
 vbn_decoder_select="texturedsp"
 vbn_encoder_select="texturedspenc"
+vc2_vulkan_encoder_select="vulkan spirv_compiler"
 vmix_decoder_select="idctdsp"
 vc1_decoder_select="blockdsp h264qpel intrax8 mpegvideodec qpeldsp vc1dsp"
 vc1image_decoder_select="vc1_decoder"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index bdf0d6742e..20968520d7 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -772,6 +772,9 @@ OBJS-$(CONFIG_VC1_MMAL_DECODER)+= mmaldec.o
 OBJS-$(CONFIG_VC1_QSV_DECODER) += qsvdec.o
 OBJS-$(CONFIG_VC1_V4L2M2M_DECODER) += v4l2_m2m_dec.o
 OBJS-$(CONFIG_VC2_ENCODER) += vc2enc.o vc2enc_dwt.o 
vc2enc_common.o diractab.o
+OBJS-$(CONFIG_VC2_VULKAN_ENCODER)  += vc2enc_vulkan.o vulkan/vc2_encode.o 
vulkan/vc2_slice_sizes.o \
+  vulkan/vc2_dwt_hor_legall.o 
vulkan/vc2_dwt_ver_legall.o \
+  vulkan/vc2_dwt_upload.o 
vulkan/vc2_dwt_haar.o vulkan/vc2_dwt_haar_subgroup.o
 OBJS-$(CONFIG_VCR1_DECODER)+= vcr1.o
 OBJS-$(CONFIG_VMDAUDIO_DECODER)+= vmdaudio.o
 OBJS-$(CONFIG_VMDVIDEO_DECODER)+= vmdvideo.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index cd4f6ecd59..cd23a9490c 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -367,6 +367,7 @@ extern const FFCodec ff_vc1_mmal_decoder;
 extern const FFCodec ff_vc1_qsv_decoder;
 extern const FFCodec ff_vc1_v4l2m2m_decoder;
 extern const FFCodec ff_vc2_encoder;
+extern const FFCodec ff_vc2_vulkan_encoder;
 extern const FFCodec ff_vcr1_decoder;
 extern const FFCodec ff_vmdvideo_decoder;
 extern const FFCodec ff_vmix_decoder;
diff --git a/libavcodec/vc2enc_vulkan.c b/libavcodec/vc2enc_vulkan.c
new file mode 100644
index 00..23b204cf92
--- /dev/null
+++ b/libavcodec/vc2enc_vulkan.c
@@ -0,0 +1,775 @@
+/*
+ * Copyright (C) 2025 raphaelthegreat 
+ *
+ * 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/avassert.h"
+#include "libavutil/mem.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "libavutil/thread.h"
+#include "libavutil/version.h"
+#include "libavutil/vulkan_spirv.h"
+#include "libavutil/hwcontext_vulkan.h"
+#include "libavutil/vulkan_loader.h"
+#include "libavutil/vulkan.h"
+#include "codec_internal.h"
+#include "internal.h"
+#include "encode.h"
+#include "version.h"
+#include "vc2enc_common.h"
+#include "hwconfig.h"
+
+#define LEGALL_TILE_DIM 16
+#define LEGALL_WORKGROUP_X 64
+#define SLICE_WORKGROUP_X 128
+#define MAX_NUM_PLANES 3
+
+extern const char *ff_source_common_comp;
+extern

Re: [FFmpeg-devel] [PATCH v4 4/4] lavc: implement a Vulkan-based VC-2 encoder Implements a Vulkan based dirac encoder. Supports Haar and Legall wavelets and should work with all wavelet depths.

2025-05-17 Thread IndecisiveTurtle
I tried to solve all the review comments from the last patchset,
please review in case I missed anything. Thanks

Στις Σάβ 17 Μαΐ 2025 στις 11:49 μ.μ., ο/η IndecisiveTurtle
 έγραψε:
>
> From: IndecisiveTurtle 
>
> Performance wise, encoding a 3440x1440 1-minute video is performed in about 
> 2.4 minutes with the cpu encoder running on my Ryzen 5 4600H, while it takes 
> about 1.3 minutes on my NVIDIA GTX 1650
>
> Haar shader has a subgroup optimized variant that applies when configured 
> wavelet depth allows it
> ---
>  configure|   1 +
>  libavcodec/Makefile  |   3 +
>  libavcodec/allcodecs.c   |   1 +
>  libavcodec/vc2enc_vulkan.c   | 775 +++
>  libavcodec/vulkan/vc2_dwt_haar.comp  |  82 ++
>  libavcodec/vulkan/vc2_dwt_haar_subgroup.comp |  75 ++
>  libavcodec/vulkan/vc2_dwt_hor_legall.comp|  82 ++
>  libavcodec/vulkan/vc2_dwt_upload.comp|  96 +++
>  libavcodec/vulkan/vc2_dwt_ver_legall.comp|  78 ++
>  libavcodec/vulkan/vc2_encode.comp| 159 
>  libavcodec/vulkan/vc2_slice_sizes.comp   | 170 
>  11 files changed, 1522 insertions(+)
>  create mode 100644 libavcodec/vc2enc_vulkan.c
>  create mode 100644 libavcodec/vulkan/vc2_dwt_haar.comp
>  create mode 100644 libavcodec/vulkan/vc2_dwt_haar_subgroup.comp
>  create mode 100644 libavcodec/vulkan/vc2_dwt_hor_legall.comp
>  create mode 100644 libavcodec/vulkan/vc2_dwt_upload.comp
>  create mode 100644 libavcodec/vulkan/vc2_dwt_ver_legall.comp
>  create mode 100644 libavcodec/vulkan/vc2_encode.comp
>  create mode 100644 libavcodec/vulkan/vc2_slice_sizes.comp
>
> diff --git a/configure b/configure
> index 2e69b3c56c..09f9dff258 100755
> --- a/configure
> +++ b/configure
> @@ -3132,6 +3132,7 @@ utvideo_encoder_select="bswapdsp huffman llvidencdsp"
>  vble_decoder_select="llviddsp"
>  vbn_decoder_select="texturedsp"
>  vbn_encoder_select="texturedspenc"
> +vc2_vulkan_encoder_select="vulkan spirv_compiler"
>  vmix_decoder_select="idctdsp"
>  vc1_decoder_select="blockdsp h264qpel intrax8 mpegvideodec qpeldsp vc1dsp"
>  vc1image_decoder_select="vc1_decoder"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index bdf0d6742e..20968520d7 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -772,6 +772,9 @@ OBJS-$(CONFIG_VC1_MMAL_DECODER)+= mmaldec.o
>  OBJS-$(CONFIG_VC1_QSV_DECODER) += qsvdec.o
>  OBJS-$(CONFIG_VC1_V4L2M2M_DECODER) += v4l2_m2m_dec.o
>  OBJS-$(CONFIG_VC2_ENCODER) += vc2enc.o vc2enc_dwt.o 
> vc2enc_common.o diractab.o
> +OBJS-$(CONFIG_VC2_VULKAN_ENCODER)  += vc2enc_vulkan.o 
> vulkan/vc2_encode.o vulkan/vc2_slice_sizes.o \
> +  vulkan/vc2_dwt_hor_legall.o 
> vulkan/vc2_dwt_ver_legall.o \
> +  vulkan/vc2_dwt_upload.o 
> vulkan/vc2_dwt_haar.o vulkan/vc2_dwt_haar_subgroup.o
>  OBJS-$(CONFIG_VCR1_DECODER)+= vcr1.o
>  OBJS-$(CONFIG_VMDAUDIO_DECODER)+= vmdaudio.o
>  OBJS-$(CONFIG_VMDVIDEO_DECODER)+= vmdvideo.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index cd4f6ecd59..cd23a9490c 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -367,6 +367,7 @@ extern const FFCodec ff_vc1_mmal_decoder;
>  extern const FFCodec ff_vc1_qsv_decoder;
>  extern const FFCodec ff_vc1_v4l2m2m_decoder;
>  extern const FFCodec ff_vc2_encoder;
> +extern const FFCodec ff_vc2_vulkan_encoder;
>  extern const FFCodec ff_vcr1_decoder;
>  extern const FFCodec ff_vmdvideo_decoder;
>  extern const FFCodec ff_vmix_decoder;
> diff --git a/libavcodec/vc2enc_vulkan.c b/libavcodec/vc2enc_vulkan.c
> new file mode 100644
> index 00..23b204cf92
> --- /dev/null
> +++ b/libavcodec/vc2enc_vulkan.c
> @@ -0,0 +1,775 @@
> +/*
> + * Copyright (C) 2025 raphaelthegreat 
> + *
> + * 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/avassert.h"
> +#include "libavutil/mem.h"
> +#include "libavutil/pixdesc.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/thread.h"
> +#include "libavutil/version.h"
> +#include "libavutil/vulkan_spirv.h"
> +#include "libavutil/hwcontext

[FFmpeg-devel] [PATCH v1] lavc/vvc: Avoid UB in DB strength derivation for PLT CUs

2025-05-17 Thread Frank Plowman
When called for palette-predicted CUs, boundary_strength could cause
undefined behaviour due to accessing uninitialised motion information.
The spec doesn't include this, but in the reference software it seems
the deblock strength is always set to 0 for palette CUs due to some
implementation details: perhaps this is a spec issue?

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/filter.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/vvc/filter.c b/libavcodec/vvc/filter.c
index e3886d008e..3815668bcf 100644
--- a/libavcodec/vvc/filter.c
+++ b/libavcodec/vvc/filter.c
@@ -385,6 +385,9 @@ static int boundary_strength(const VVCLocalContext *lc, 
const MvField *curr, con
 {
 RefPicList *rpl = lc->sc->rpl;
 
+if (curr->pred_flag == PF_PLT)
+return 0;
+
 if (curr->pred_flag == PF_IBC)
 return FFABS(neigh->mv[0].x - curr->mv[0].x) >= 8 || 
FFABS(neigh->mv[0].y - curr->mv[0].y) >= 8;
 
-- 
2.47.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 v1] lavc/vvc: Validate num_signalled_palette_entries

2025-05-17 Thread Frank Plowman
"The value of CurrentPaletteSize[ startComp ] shall be in the range of 0
to maxNumPaletteEntries, inclusive."

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/ctu.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
index 62c9d4f5c0..70800ba5fa 100644
--- a/libavcodec/vvc/ctu.c
+++ b/libavcodec/vvc/ctu.c
@@ -20,6 +20,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "libavutil/error.h"
 #include "libavutil/refstruct.h"
 
 #include "cabac.h"
@@ -1873,7 +1874,7 @@ static void palette_predicted(VVCLocalContext *lc, const 
bool local_dual_tree, i
 cu->plt[c].size = nb_predicted;
 }
 
-static void palette_signaled(VVCLocalContext *lc, const bool local_dual_tree,
+static int palette_signaled(VVCLocalContext *lc, const bool local_dual_tree,
 const int start, const int end, const int max_entries)
 {
 const VVCSPS *sps = lc->fc->ps.sps;
@@ -1883,6 +1884,9 @@ static void palette_signaled(VVCLocalContext *lc, const 
bool local_dual_tree,
 const int size= nb_predicted + nb_signaled;
 const bool dual_tree_luma = local_dual_tree && cu->tree_type == 
DUAL_TREE_LUMA;
 
+if (size > max_entries)
+return AVERROR_INVALIDDATA;
+
 for (int c = start; c < end; c++) {
 Palette *plt = cu->plt + c;
 for (int i = nb_predicted; i < size; i++) {
@@ -1894,6 +1898,8 @@ static void palette_signaled(VVCLocalContext *lc, const 
bool local_dual_tree,
 }
 plt->size = size;
 }
+
+return 0;
 }
 
 static void palette_update_predictor(VVCLocalContext *lc, const bool 
local_dual_tree, int start, int end,
@@ -2070,7 +2076,7 @@ static int hls_palette_coding(VVCLocalContext *lc, const 
VVCTreeType tree_type)
 int max_index = 0;
 int prev_run_pos  = 0;
 
-int predictor_size, start, end;
+int predictor_size, start, end, ret;
 bool reused[VVC_MAX_NUM_PALETTE_PREDICTOR_SIZE];
 uint8_t run_type[MAX_PALETTE_CU_SIZE * MAX_PALETTE_CU_SIZE];
 uint8_t index[MAX_PALETTE_CU_SIZE * MAX_PALETTE_CU_SIZE];
@@ -2083,7 +2089,9 @@ static int hls_palette_coding(VVCLocalContext *lc, const 
VVCTreeType tree_type)
 predictor_size = pp[start].size;
 memset(reused, 0, sizeof(reused[0]) * predictor_size);
 palette_predicted(lc, local_dual_tree, start, end, reused, predictor_size, 
max_entries);
-palette_signaled(lc, local_dual_tree, start, end, max_entries);
+ret = palette_signaled(lc, local_dual_tree, start, end, max_entries);
+if (ret < 0)
+return ret;
 palette_update_predictor(lc, local_dual_tree, start, end, reused, 
predictor_size);
 
 if (cu->plt[start].size > 0)
-- 
2.47.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] cbs_apv: Fix memory leak on metadata parse failure

2025-05-17 Thread Mark Thompson
On 14/05/2025 21:50, Mark Thompson wrote:
> Buffers are allocated inside some metadata types, so we must ensure
> that the object is visible to the free function before a parse failure.
> 
> Found by libFuzzer.
> ---
>  libavcodec/cbs_apv_syntax_template.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/cbs_apv_syntax_template.c 
> b/libavcodec/cbs_apv_syntax_template.c
> index ca66349141..fc8a08ff31 100644
> --- a/libavcodec/cbs_apv_syntax_template.c
> +++ b/libavcodec/cbs_apv_syntax_template.c
> @@ -543,11 +543,11 @@ static int FUNC(metadata)(CodedBitstreamContext *ctx, 
> RWContext *rw,
>  return AVERROR_INVALIDDATA;
>  }
>  
> +current->metadata_count = p + 1;
> +
>  CHECK(FUNC(metadata_payload)(ctx, rw, pl));
>  
>  metadata_bytes_left -= pl->payload_size;
> -
> -current->metadata_count = p + 1;
>  if (metadata_bytes_left == 0)
>  break;
>  }

Applied.  Simple application of libFuzzer to the decoder hasn't found anything 
else, either.

Thanks,

- Mark

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

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


Re: [FFmpeg-devel] [PATCH] avformat/flvenc: Specify codec tag with MKTAG

2025-05-17 Thread Timo Rothenpieler

On 17.05.2025 06:35, Zhao Zhili wrote:



在 2025年5月17日,上午1:39,Timo Rothenpieler  写道:

On 16.05.2025 19:24, Zhao Zhili wrote:

On May 17, 2025, at 01:10, Zhao Zhili  
wrote:





On May 17, 2025, at 00:27, Timo Rothenpieler  wrote:

On 16.05.2025 17:59, Zhao Zhili wrote:

On May 16, 2025, at 22:52, Timo Rothenpieler  wrote:

On 16/05/2025 16:24, Zhao Zhili wrote:

From: Zhao Zhili mailto:zhiliz...@tencent.com>>
ffmpeg -i input.mp4 -c copy -tag:v av01 output.flv
[flv @ 0x143204080] Tag av01 incompatible with output codec id '225' (10va)


I don't quite understand what causes this.
Is this an issue when running on big endian architectures?
I'm pretty sure I tested all combinations of codecs with muxing and demuxing, 
and never ran into that error.

The key point is when specify tag via command line, e.g., -tag:v av01, it’s
passed to AVCodecParameters codec_tag in little endian.
You didn’t see the error because without specify the tag explicitly, codec_tag 
is copied
from AVOutputFormat codec_tag to AVCodecParameters codec_tag, so they are
the same.
Another example is codec_mp4_tags.


This still irks me as wrong.
There is _a lot_ of places all over flvenv.c, in all kinds of functions, that 
hard-depend on the values in par->codec_tag being from the _codec_ids tables at 
the top of the file.
Like, they contain flv specific audio and video codec IDs for the pre-ext-flv 
codecs, those would all also break.

So there seems to be a deeper issue there if those values can be overridden 
from the commandline. The encoder clearly does not expect that.

Looking at the code this error comes from:
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mux.c#L314

It looks to to me like it's working exactly as intended and required by flvenc, 
protecting it from invalid tags.

So, when the user provides a custom tag that is invalid, isn't that kinda on 
the user?
The check you're running into does what it's supposed to:
It detects that the provided tag is invalid for this codec in this container.

Why do you want to override it anyway? There is only exactly one valid tag for 
each codec.


A user shows the error message to me. Because he know there are -tag option for 
mp4, and
enhanced-rtmp use fourcc for extended codecs, so he thought it should work.

The -tag:v av01 is redundant, it should be a NOP, not trigger error. The 
strings “av01”
is the right order of fourcc in spec. The endian issue should be limited to the 
internal.
Current error message is confusing, because it shows 10va instead of av01.

Doc from Microsoft shows fourcc use small endian
https://learn.microsoft.com/en-us/windows/win32/directshow/fourcc-codes
While wiki and enhanced rtmp spec says it’s big endian
https://en.wikipedia.org/wiki/FourCC
It’s clear in av_fourcc_make_string
that we use small endian.
For normal codec id in flv, e.g, 7 for H.264, it’s not a big issue, since 
they’re not fourcc.


This patch just fixes it for a very small subset of codecs in flv though.
There's nothing indicating that -tag:v is needed or sensibly supported in 
flvenc.
If you'd want to pass h264 or aac as fourcc, it'd be flat out impossible, and 
no easy fix is available.

I'd rather not complicate flvenc, even if just a little bit, just to swap 
around the endianness of the few codecs that do use a fourcc based tag.

flvenv should probably just completely ignore -tag:v, since the option makes no 
sense for it anyway.


I can remove setting tag list to AVOutputFormat, does that works for you?


Won't that break even more things?
The code heavily relies on the tags being what they are, and passing the 
tag list to AVOutputFormat would remove avformat enforcing that, with 
said error when trying to override it with something invalid.


I honestly don't think anything needs to be changed at all.
Passing custom tags is simply not something flv sensibly supports.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[FFmpeg-devel] [PATCH 3/3] fftools/graphprint: Fix leak of graph section header string

2025-05-17 Thread Mark Thompson
---
 fftools/graph/graphprint.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fftools/graph/graphprint.c b/fftools/graph/graphprint.c
index 9e3e03274a..50f1a2ecdc 100644
--- a/fftools/graph/graphprint.c
+++ b/fftools/graph/graphprint.c
@@ -780,6 +780,8 @@ static int print_streams(GraphPrintContext *gpc, InputFile 
**ifiles, int nb_ifil
 
 avtext_print_section_header(tfc, &sec_ctx, SECTION_ID_OUTPUTSTREAMS);
 
+av_freep(&sec_ctx.context_id);
+
 for (int i = 0; i < of->nb_streams; i++) {
 OutputStream *ost = of->streams[i];
 const AVCodecDescriptor *codec_desc = 
avcodec_descriptor_get(ost->st->codecpar->codec_id);
-- 
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/3] fftools/graphprint: Fix leak of graphprint object

2025-05-17 Thread Mark Thompson
---
 fftools/graph/graphprint.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fftools/graph/graphprint.c b/fftools/graph/graphprint.c
index fc94a75797..9e3e03274a 100644
--- a/fftools/graph/graphprint.c
+++ b/fftools/graph/graphprint.c
@@ -862,6 +862,8 @@ static void uninit_graphprint(GraphPrintContext *gpc)
 
 // Finalize the print buffer if it was initialized
 av_bprint_finalize(&gpc->pbuf, NULL);
+
+av_freep(&gpc);
 }
 
 static int init_graphprint(GraphPrintContext **pgpc, AVBPrint *target_buf)
-- 
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 1/3] ffmpeg: Don't print graphs if there are no graphs to print

2025-05-17 Thread Mark Thompson
Avoids writing an empty json blob in setup error cases.
---
 fftools/ffmpeg.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 964770df23..ad28cff78d 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -309,7 +309,8 @@ const AVIOInterruptCB int_cb = { decode_interrupt_cb, NULL 
};
 
 static void ffmpeg_cleanup(int ret)
 {
-if (print_graphs || print_graphs_file)
+if ((print_graphs || print_graphs_file) &&
+(nb_filtergraphs > 0 || nb_output_files > 0))
 print_filtergraphs(filtergraphs, nb_filtergraphs, input_files, 
nb_input_files, output_files, nb_output_files);
 
 if (do_benchmark) {
-- 
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".


Re: [FFmpeg-devel] [PATCH v5 6/7] ogg/vorbis: implement header packet skip in chained ogg bitstreams.

2025-05-17 Thread Michael Niedermayer
On Sat, May 17, 2025 at 01:10:26PM -0500, Romain Beauxis wrote:
> Le mar. 13 mai 2025 à 14:23, Michael Niedermayer  a
> écrit :
> >
> > On Fri, May 09, 2025 at 06:43:26PM -0500, Romain Beauxis wrote:
> > > ---
> > >  libavcodec/vorbisdec.c |  37 +
> > >  libavformat/oggparsevorbis.c   | 174 +
> > >  tests/ref/fate/ogg-vorbis-chained-meta.txt |   3 -
> > >  3 files changed, 117 insertions(+), 97 deletions(-)
> > >
> > > diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c
> > > index a778dc6b58..f069ac6ab3 100644
> > > --- a/libavcodec/vorbisdec.c
> > > +++ b/libavcodec/vorbisdec.c
> > > @@ -1776,39 +1776,17 @@ static int vorbis_decode_frame(AVCodecContext
> *avctx, AVFrame *frame,
> > >  GetBitContext *gb = &vc->gb;
> > >  float *channel_ptrs[255];
> > >  int i, len, ret;
> > > +const int8_t *new_extradata;
> > > +size_t new_extradata_size;
> > >
> > >  ff_dlog(NULL, "packet length %d \n", buf_size);
> > >
> > > -if (*buf == 1 && buf_size > 7) {
> > > -if ((ret = init_get_bits8(gb, buf + 1, buf_size - 1)) < 0)
> > > -return ret;
> > > -
> > > -vorbis_free(vc);
> > > -if ((ret = vorbis_parse_id_hdr(vc))) {
> > > -av_log(avctx, AV_LOG_ERROR, "Id header corrupt.\n");
> > > -vorbis_free(vc);
> > > -return ret;
> > > -}
> > > -
> > > -av_channel_layout_uninit(&avctx->ch_layout);
> > > -if (vc->audio_channels > 8) {
> > > -avctx->ch_layout.order   = AV_CHANNEL_ORDER_UNSPEC;
> > > -avctx->ch_layout.nb_channels = vc->audio_channels;
> > > -} else {
> > > -av_channel_layout_copy(&avctx->ch_layout,
> &ff_vorbis_ch_layouts[vc->audio_channels - 1]);
> > > -}
> > > -
> > > -avctx->sample_rate = vc->audio_samplerate;
> > > -return buf_size;
> > > -}
> > > -
> > > -if (*buf == 3 && buf_size > 7) {
> > > -av_log(avctx, AV_LOG_DEBUG, "Ignoring comment header\n");
> > > -return buf_size;
> > > -}
> > > +new_extradata = av_packet_get_side_data(avpkt,
> AV_PKT_DATA_NEW_EXTRADATA,
> > > +&new_extradata_size);
> > >
> > > -if (*buf == 5 && buf_size > 7 && vc->channel_residues &&
> !vc->modes) {
> > > -if ((ret = init_get_bits8(gb, buf + 1, buf_size - 1)) < 0)
> > > +if (new_extradata && *new_extradata == 5 && new_extradata_size > 7
> &&
> > > +vc->channel_residues && !vc->modes) {
> > > +if ((ret = init_get_bits8(gb, new_extradata + 1,
> new_extradata_size - 1)) < 0)
> > >  return ret;
> > >
> > >  if ((ret = vorbis_parse_setup_hdr(vc))) {
> > > @@ -1816,7 +1794,6 @@ static int vorbis_decode_frame(AVCodecContext
> *avctx, AVFrame *frame,
> > >  vorbis_free(vc);
> > >  return ret;
> > >  }
> > > -return buf_size;
> > >  }
> > >
> > >  if (!vc->channel_residues || !vc->modes) {
> > > diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c
> > > index 9f50ab9ffc..452728b54d 100644
> > > --- a/libavformat/oggparsevorbis.c
> > > +++ b/libavformat/oggparsevorbis.c
> > > @@ -293,6 +293,62 @@ static int vorbis_update_metadata(AVFormatContext
> *s, int idx)
> > >  return ret;
> > >  }
> > >
> > > +static int vorbis_parse_header(AVFormatContext *s, AVStream *st,
> > > +   const uint8_t *p, unsigned int psize)
> > > +{
> > > +unsigned blocksize, bs0, bs1;
> > > +int srate;
> > > +int channels;
> > > +
> > > +if (psize != 30)
> > > +return AVERROR_INVALIDDATA;
> > > +
> > > +p += 7; /* skip "\001vorbis" tag */
> > > +
> > > +if (bytestream_get_le32(&p) != 0) /* vorbis_version */
> > > +return AVERROR_INVALIDDATA;
> > > +
> > > +channels = bytestream_get_byte(&p);
> > > +if (st->codecpar->ch_layout.nb_channels &&
> > > +channels != st->codecpar->ch_layout.nb_channels) {
> > > +av_log(s, AV_LOG_ERROR, "Channel change is not supported\n");
> > > +return AVERROR_PATCHWELCOME;
> > > +}
> > > +st->codecpar->ch_layout.nb_channels = channels;
> > > +srate   = bytestream_get_le32(&p);
> > > +p += 4; // skip maximum bitrate
> > > +st->codecpar->bit_rate = bytestream_get_le32(&p); // nominal
> bitrate
> > > +p += 4; // skip minimum bitrate
> > > +
> > > +blocksize = bytestream_get_byte(&p);
> > > +bs0   = blocksize & 15;
> > > +bs1   = blocksize >> 4;
> > > +
> > > +if (bs0 > bs1)
> > > +return AVERROR_INVALIDDATA;
> > > +if (bs0 < 6 || bs1 > 13)
> > > +return AVERROR_INVALIDDATA;
> > > +
> > > +if (bytestream_get_byte(&p) != 1) /* framing_flag */
> > > +return AVERROR_INVALIDDATA;
> > > +
> > > +st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
> > > +st->codecpar->codec_id   = AV_CODEC_ID_VORBIS;
> > > +
> 

Re: [FFmpeg-devel] [PATCH v5 1/7] libavformat/oggdec.h: Document packet function return value.

2025-05-17 Thread Michael Niedermayer
On Fri, May 16, 2025 at 12:39:36PM -0500, Romain Beauxis wrote:
> Le mer. 14 mai 2025 à 17:32, Michael Niedermayer  a
> écrit :
> >
> > On Fri, May 09, 2025 at 06:43:21PM -0500, Romain Beauxis wrote:
> > > ---
> > >  libavformat/oggdec.h | 6 ++
> > >  1 file changed, 6 insertions(+)
> > >
> > > diff --git a/libavformat/oggdec.h b/libavformat/oggdec.h
> > > index 43df23f4cb..5225b77a07 100644
> > > --- a/libavformat/oggdec.h
> > > +++ b/libavformat/oggdec.h
> > > @@ -38,6 +38,12 @@ struct ogg_codec {
> > >   * -1 if an error occurred or for unsupported stream
> > >   */
> > >  int (*header)(AVFormatContext *, int);
> > > +/**
> > > + * Attempt to process a packet as a data packet
> > > + * @return < 0 (AVERROR) code or -1 on error
> > > + * == 0 if the packet was a regular data packet.
> > > + * == 0 or 1 if the packet was a header from a chained
> bitstream.
> > > + */
> > >  int (*packet)(AVFormatContext *, int);
> > >  /**
> > >   * Translate a granule into a timestamp.
> > > --
> >
> > will apply, so the patchset becomes smaller
> 
> Thanks!
> 
> I'll address the comments on the vorbis diff.
> 
> Opus and flac could go in too if you want.

no objection, if someone wants to apply them

thx

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

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


Re: [FFmpeg-devel] FFmpeg 6.1.3 and 7.0.3

2025-05-17 Thread Michael Niedermayer
On Sat, May 17, 2025 at 05:03:22PM +0200, Michael Niedermayer wrote:
> On Sat, Mar 15, 2025 at 01:36:59AM +0100, Michael Niedermayer wrote:
> > On Wed, Mar 12, 2025 at 02:17:32PM +0100, Michael Niedermayer wrote:
> > > On Mon, Mar 03, 2025 at 02:10:49AM +0100, Michael Niedermayer wrote:
> > > > Hi all
> > > > 
> > > > As ive already backported and somewhat tested release/4.3 i intend to
> > > > make the next point release from that and after that next is
> > > > 3.4 (because its the supported branch that is longest without a release)
> > > > 
> > > > like always, please backport things if you want something backported
> > > > please test, if you want something tested
> > > > and tell me if theres anything i need to know (like waiting for 
> > > > something)
> > > 
> > > 4.3.9 released, 3.4.14 is next
> > 
> > 3.4.14 released a few days ago too
> > 
> > next is 4.4.6 and 4.2.11
> 
> 4.4.6 done, will do 4.2.11 later today or tomorrow

4.2.11 done

Next will be 6.1.3 and 7.0.3


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

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


Re: [FFmpeg-devel] [PATCH] avformat/flvenc: Specify codec tag with MKTAG

2025-05-17 Thread Michael Niedermayer
Hi Zhao Zhili

On Sat, May 17, 2025 at 10:05:34PM +0800, Zhao Zhili wrote:
> 
> 
> > On May 17, 2025, at 19:14, Timo Rothenpieler  wrote:
> > 
> > On 17.05.2025 06:35, Zhao Zhili wrote:
> >>> 在 2025年5月17日,上午1:39,Timo Rothenpieler  写道:
> >>> 
> >>> On 16.05.2025 19:24, Zhao Zhili wrote:
> >> On May 17, 2025, at 01:10, Zhao Zhili 
> >>  wrote:
> > 
> > 
> > 
> >> On May 17, 2025, at 00:27, Timo Rothenpieler  
> >> wrote:
> >> 
> >> On 16.05.2025 17:59, Zhao Zhili wrote:
>  On May 16, 2025, at 22:52, Timo Rothenpieler  
>  wrote:
>  
>  On 16/05/2025 16:24, Zhao Zhili wrote:
> > From: Zhao Zhili  > >
> > ffmpeg -i input.mp4 -c copy -tag:v av01 output.flv
> > [flv @ 0x143204080] Tag av01 incompatible with output codec id 
> > '225' (10va)
>  
>  I don't quite understand what causes this.
>  Is this an issue when running on big endian architectures?
>  I'm pretty sure I tested all combinations of codecs with muxing and 
>  demuxing, and never ran into that error.
> >>> The key point is when specify tag via command line, e.g., -tag:v 
> >>> av01, it’s
> >>> passed to AVCodecParameters codec_tag in little endian.
> >>> You didn’t see the error because without specify the tag explicitly, 
> >>> codec_tag is copied
> >>> from AVOutputFormat codec_tag to AVCodecParameters codec_tag, so they 
> >>> are
> >>> the same.
> >>> Another example is codec_mp4_tags.
> >> 
> >> This still irks me as wrong.
> >> There is _a lot_ of places all over flvenv.c, in all kinds of 
> >> functions, that hard-depend on the values in par->codec_tag being from 
> >> the _codec_ids tables at the top of the file.
> >> Like, they contain flv specific audio and video codec IDs for the 
> >> pre-ext-flv codecs, those would all also break.
> >> 
> >> So there seems to be a deeper issue there if those values can be 
> >> overridden from the commandline. The encoder clearly does not expect 
> >> that.
> >> 
> >> Looking at the code this error comes from:
> >> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mux.c#L314
> >> 
> >> It looks to to me like it's working exactly as intended and required 
> >> by flvenc, protecting it from invalid tags.
> >> 
> >> So, when the user provides a custom tag that is invalid, isn't that 
> >> kinda on the user?
> >> The check you're running into does what it's supposed to:
> >> It detects that the provided tag is invalid for this codec in this 
> >> container.
> >> 
> >> Why do you want to override it anyway? There is only exactly one valid 
> >> tag for each codec.
> > 
> > A user shows the error message to me. Because he know there are -tag 
> > option for mp4, and
> > enhanced-rtmp use fourcc for extended codecs, so he thought it should 
> > work.
> > 
> > The -tag:v av01 is redundant, it should be a NOP, not trigger error. 
> > The strings “av01”
> > is the right order of fourcc in spec. The endian issue should be 
> > limited to the internal.
> > Current error message is confusing, because it shows 10va instead of 
> > av01.
>  Doc from Microsoft shows fourcc use small endian
>  https://learn.microsoft.com/en-us/windows/win32/directshow/fourcc-codes
>  While wiki and enhanced rtmp spec says it’s big endian
>  https://en.wikipedia.org/wiki/FourCC
>  It’s clear in av_fourcc_make_string
>  that we use small endian.
>  For normal codec id in flv, e.g, 7 for H.264, it’s not a big issue, 
>  since they’re not fourcc.
> >>> 
> >>> This patch just fixes it for a very small subset of codecs in flv though.
> >>> There's nothing indicating that -tag:v is needed or sensibly supported in 
> >>> flvenc.
> >>> If you'd want to pass h264 or aac as fourcc, it'd be flat out impossible, 
> >>> and no easy fix is available.
> >>> 
> >>> I'd rather not complicate flvenc, even if just a little bit, just to swap 
> >>> around the endianness of the few codecs that do use a fourcc based tag.
> >>> 
> >>> flvenv should probably just completely ignore -tag:v, since the option 
> >>> makes no sense for it anyway.
> >> I can remove setting tag list to AVOutputFormat, does that works for you?
> > 
> > Won't that break even more things?
> > The code heavily relies on the tags being what they are, and passing the 
> > tag list to AVOutputFormat would remove avformat enforcing that, with said 
> > error when trying to override it with something invalid.
> 
> The enforcing logic has a precondition, that codec_tag is in little endian.
> flv_video_codec_ids and flv_audio_codec_ids don’t match this requirement.
> 
> > 
> > I honestly don't think anything needs to be changed at all.
> > Passing custom tags is simply not something flv sensibly 

Re: [FFmpeg-devel] [PATCH v1] lavc/vvc: Validate num_signalled_palette_entries

2025-05-17 Thread Nuo Mi
Hi Frank,
👍,your fuzzing infrastructure caught this issue as well.
How about this:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20250517055150.807683-1-nuomi2...@gmail.com/

On Sun, May 18, 2025 at 5:05 AM Frank Plowman  wrote:

> "The value of CurrentPaletteSize[ startComp ] shall be in the range of 0
> to maxNumPaletteEntries, inclusive."
>
> Signed-off-by: Frank Plowman 
> ---
>  libavcodec/vvc/ctu.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
> index 62c9d4f5c0..70800ba5fa 100644
> --- a/libavcodec/vvc/ctu.c
> +++ b/libavcodec/vvc/ctu.c
> @@ -20,6 +20,7 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
>   */
>
> +#include "libavutil/error.h"
>  #include "libavutil/refstruct.h"
>
>  #include "cabac.h"
> @@ -1873,7 +1874,7 @@ static void palette_predicted(VVCLocalContext *lc,
> const bool local_dual_tree, i
>  cu->plt[c].size = nb_predicted;
>  }
>
> -static void palette_signaled(VVCLocalContext *lc, const bool
> local_dual_tree,
> +static int palette_signaled(VVCLocalContext *lc, const bool
> local_dual_tree,
>  const int start, const int end, const int max_entries)
>  {
>  const VVCSPS *sps = lc->fc->ps.sps;
> @@ -1883,6 +1884,9 @@ static void palette_signaled(VVCLocalContext *lc,
> const bool local_dual_tree,
>  const int size= nb_predicted + nb_signaled;
>  const bool dual_tree_luma = local_dual_tree && cu->tree_type ==
> DUAL_TREE_LUMA;
>
> +if (size > max_entries)
> +return AVERROR_INVALIDDATA;
> +
>  for (int c = start; c < end; c++) {
>  Palette *plt = cu->plt + c;
>  for (int i = nb_predicted; i < size; i++) {
> @@ -1894,6 +1898,8 @@ static void palette_signaled(VVCLocalContext *lc,
> const bool local_dual_tree,
>  }
>  plt->size = size;
>  }
> +
> +return 0;
>  }
>
>  static void palette_update_predictor(VVCLocalContext *lc, const bool
> local_dual_tree, int start, int end,
> @@ -2070,7 +2076,7 @@ static int hls_palette_coding(VVCLocalContext *lc,
> const VVCTreeType tree_type)
>  int max_index = 0;
>  int prev_run_pos  = 0;
>
> -int predictor_size, start, end;
> +int predictor_size, start, end, ret;
>  bool reused[VVC_MAX_NUM_PALETTE_PREDICTOR_SIZE];
>  uint8_t run_type[MAX_PALETTE_CU_SIZE * MAX_PALETTE_CU_SIZE];
>  uint8_t index[MAX_PALETTE_CU_SIZE * MAX_PALETTE_CU_SIZE];
> @@ -2083,7 +2089,9 @@ static int hls_palette_coding(VVCLocalContext *lc,
> const VVCTreeType tree_type)
>  predictor_size = pp[start].size;
>  memset(reused, 0, sizeof(reused[0]) * predictor_size);
>  palette_predicted(lc, local_dual_tree, start, end, reused,
> predictor_size, max_entries);
> -palette_signaled(lc, local_dual_tree, start, end, max_entries);
> +ret = palette_signaled(lc, local_dual_tree, start, end, max_entries);
> +if (ret < 0)
> +return ret;
>  palette_update_predictor(lc, local_dual_tree, start, end, reused,
> predictor_size);
>
>  if (cu->plt[start].size > 0)
> --
> 2.47.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] ffbuild/commonmak: Fix rebuild check with implicit rule chains

2025-05-17 Thread softworkz
From: softworkz 

When there's a chain of implicit rules, make treats files generated
inside that chain as intermediate files. Those intermediate files are
removed after completion of make. When make is run again, it normally
determines the need for a rebuild by comparing the timestamps of the
original source file and the final output of the chain and if still
up-to-date, it doesn't rebuild, even when the intermediate files are
not present. That makes sense of course - why would it delete them
otherwise, it would end up in builds being never up-to-date.
But this original by-the-book logic appeared to be broken and has been
worked around by adding all intermediate files to the .SECONDARY
special target, which required extra logic and issues with make clean.

What broke the up-to-date checking is the dependency file generation.
For the .c files generated by BIN2C the compile target created a .d
file which indicated that the .ptx.o file has a dependency on the
ptx.c file. And that dependency broke the normal make behavior with
intermediate files.

This patch compiles the BIN2C generated .c files without generating
.d files. In turn the files do not longer need to be added to the
.SECONDARY target in common.mak.

When interested in those files for debugging, a line can be added to
the corresponding Makefile like

.SECONDARY: %.ptx.c %.ptx.gz

Signed-off-by: softworkz 
---
ffbuild/commonmak: Fix rebuild check with implicit rule chains

When there's a chain of implicit rules, make treats files generated
inside that chain as intermediate files. Those intermediate files are
removed after completion of make. When make is run again, it normally
determines the need for a rebuild by comparing the timestamps of the
original source file and the final output of the chain and if still
up-to-date, it doesn't rebuild, even when the intermediate files are not
present. That makes sense of course - why would it delete them
otherwise, it would end up in builds being never up-to-date. But this
original by-the-book logic appeared to be broken and has been worked
around by adding all intermediate files to the .SECONDARY special
target, which required extra logic and issues with make clean.

What broke the up-to-date checking is the dependency file generation.
For the .c files generated by BIN2C the compile target created a .d file
which indicated that the .ptx.o file has a dependency on the ptx.c file.
And that dependency broke the normal make behavior with intermediate
files.

This patch compiles the BIN2C generated .c files without generating .d
files. In turn the files do not longer need to be added to the
.SECONDARY target in common.mak.

When interested in those files for debugging, a line can be added to the
corresponding Makefile like

.SECONDARY: %.ptx.c %.ptx.gz

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

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

 ffbuild/common.mak | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/ffbuild/common.mak b/ffbuild/common.mak
index 0e1eb1f62b..6231bc472e 100644
--- a/ffbuild/common.mak
+++ b/ffbuild/common.mak
@@ -139,6 +139,10 @@ else
$(BIN2C) $(patsubst $(SRC_PATH)/%,$(SRC_LINK)/%,$<) $@ $(subst 
.,_,$(basename $(notdir $@)))
 endif
 
+%.ptx.o: %.ptx.c
+   $(CC) $(CCFLAGS) -x c -c -o $@ $<
+
+
 # 1) Preprocess CSS to a minified version
 %.css.min: %.css
# Must start with a tab in the real Makefile
@@ -177,6 +181,13 @@ else   # NO COMPRESSION
$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
 endif
 
+%.html.o: %.html.c
+   $(CC) $(CCFLAGS) -x c -c -o $@ $<
+
+%.css.o: %.css.c
+   $(CC) $(CCFLAGS) -x c -c -o $@ $<
+
+
 clean::
$(RM) $(BIN2CEXE) $(CLEANSUFFIXES:%=ffbuild/%)
 
@@ -228,11 +239,9 @@ ALLHEADERS := $(subst $(SRC_DIR)/,$(SUBDIR),$(wildcard 
$(SRC_DIR)/*.h $(SRC_DIR)
 SKIPHEADERS += $(ARCH_HEADERS:%=$(ARCH)/%) $(SKIPHEADERS-)
 SKIPHEADERS := $(SKIPHEADERS:%=$(SUBDIR)%)
 HOBJS= $(filter-out $(SKIPHEADERS:.h=.h.o),$(ALLHEADERS:.h=.h.o))
-PTXOBJS  = $(filter %.ptx.o,$(OBJS))
-RESOURCEOBJS = $(filter %.css.o %.html.o,$(OBJS))
 $(HOBJS): CCFLAGS += $(CFLAGS_HEADERS)
 checkheaders: $(HOBJS)
-.SECONDARY:   $(HOBJS:.o=.c) $(PTXOBJS:.o=.c) $(PTXOBJS:.o=.gz) $(PTXOBJS:.o=) 
$(RESOURCEOBJS:.o=.c) $(RESOURCEOBJS:%.css.o=%.css.min) 
$(RESOURCEOBJS:%.css.o=%.css.min.gz) $(RESOURCEOBJS:%.html.o=%.html.gz) 
$(RESOURCEOBJS:.o=)
+.SECONDARY:   $(HOBJS:.o=.c)
 
 alltools: $(TOOLS)
 

base-commit: eb6dc952cbd479bf43673af9ca0bc83f37f8f329
-- 
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.or

Re: [FFmpeg-devel] [PATCH 1/3] fftools/resources: fix preservation of intermediary resman build artifacts

2025-05-17 Thread softworkz .



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Timo
> Rothenpieler
> Sent: Samstag, 17. Mai 2025 01:02
> To: ffmpeg-devel@ffmpeg.org
> Cc: Timo Rothenpieler 
> Subject: [FFmpeg-devel] [PATCH 1/3] fftools/resources: fix preservation of
> intermediary resman build artifacts
> 
> Without this, make install triggers a full re-generation of the graph
> stuff, which results in re-linking during install.
> ---
>  ffbuild/common.mak | 3 +--
>  fftools/resources/Makefile | 5 ++---
>  2 files changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/ffbuild/common.mak b/ffbuild/common.mak
> index 0e1eb1f62b..4a3cc0c748 100644
> --- a/ffbuild/common.mak
> +++ b/ffbuild/common.mak
> @@ -229,10 +229,9 @@ SKIPHEADERS += $(ARCH_HEADERS:%=$(ARCH)/%) $(SKIPHEADERS-
> )
>  SKIPHEADERS := $(SKIPHEADERS:%=$(SUBDIR)%)
>  HOBJS= $(filter-out $(SKIPHEADERS:.h=.h.o),$(ALLHEADERS:.h=.h.o))
>  PTXOBJS  = $(filter %.ptx.o,$(OBJS))
> -RESOURCEOBJS = $(filter %.css.o %.html.o,$(OBJS))
>  $(HOBJS): CCFLAGS += $(CFLAGS_HEADERS)
>  checkheaders: $(HOBJS)
> -.SECONDARY:   $(HOBJS:.o=.c) $(PTXOBJS:.o=.c) $(PTXOBJS:.o=.gz)
> $(PTXOBJS:.o=) $(RESOURCEOBJS:.o=.c) $(RESOURCEOBJS:%.css.o=%.css.min)
> $(RESOURCEOBJS:%.css.o=%.css.min.gz) $(RESOURCEOBJS:%.html.o=%.html.gz)
> $(RESOURCEOBJS:.o=)
> +.SECONDARY:   $(HOBJS:.o=.c) $(PTXOBJS:.o=.c) $(PTXOBJS:.o=.gz)
> $(PTXOBJS:.o=)
> 
>  alltools: $(TOOLS)
> 
> diff --git a/fftools/resources/Makefile b/fftools/resources/Makefile
> index 8579a52678..3a307bef12 100644
> --- a/fftools/resources/Makefile
> +++ b/fftools/resources/Makefile
> @@ -4,10 +4,9 @@ clean::
>  vpath %.html $(SRC_PATH)
>  vpath %.css  $(SRC_PATH)
> 
> -# Uncomment to prevent deletion during build
> -#.PRECIOUS: %.css.c %.css.min %.css.gz %.css.min.gz %.html.gz %.html.c
> -
>  OBJS-resman += \
>  fftools/resources/resman.o \
>  fftools/resources/graph.html.o \
>  fftools/resources/graph.css.o  \
> +
> +.SECONDARY: $(OBJS-resman:.o=.c) $(OBJS-resman:.css.o=.css.min) $(OBJS-
> resman:.css.o=.css.min.gz) $(OBJS-resman:.html.o=.html.gz)
> --

Hi,

I managed to hunt down the underlying problem for why the preservation even 
appeared to be needed. Please see my upcoming patch
"ffbuild/commonmak: Fix rebuild check with implicit rule chains"

Thanks
sw


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

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


[FFmpeg-devel] [PATCH v2] ffbuild/commonmak: Fix rebuild check with implicit rule chains

2025-05-17 Thread softworkz
From: softworkz 

When there's a chain of implicit rules, make treats files generated
inside that chain as intermediate files. Those intermediate files are
removed after completion of make. When make is run again, it normally
determines the need for a rebuild by comparing the timestamps of the
original source file and the final output of the chain and if still
up-to-date, it doesn't rebuild, even when the intermediate files are
not present. That makes sense of course - why would it delete them
otherwise, it would end up in builds being never up-to-date.
But this original by-the-book logic appeared to be broken and has been
worked around by adding all intermediate files to the .SECONDARY
special target, which required extra logic and issues with make clean.

What broke the up-to-date checking is the dependency file generation.
For the .c files generated by BIN2C the compile target created a .d
file which indicated that the .ptx.o file has a dependency on the
ptx.c file. And that dependency broke the normal make behavior with
intermediate files.

This patch compiles the BIN2C generated .c files without generating
.d files. In turn the files do not longer need to be added to the
.SECONDARY target in common.mak.

When interested in those files for debugging, a line can be added to
the corresponding Makefile like

.SECONDARY: %.ptx.c %.ptx.gz

Signed-off-by: softworkz 
---
ffbuild/commonmak: Fix rebuild check with implicit rule chains

When there's a chain of implicit rules, make treats files generated
inside that chain as intermediate files. Those intermediate files are
removed after completion of make. When make is run again, it normally
determines the need for a rebuild by comparing the timestamps of the
original source file and the final output of the chain and if still
up-to-date, it doesn't rebuild, even when the intermediate files are not
present. That makes sense of course - why would it delete them
otherwise, it would end up in builds being never up-to-date. But this
original by-the-book logic appeared to be broken and has been worked
around by adding all intermediate files to the .SECONDARY special
target, which required extra logic and issues with make clean.

What broke the up-to-date checking is the dependency file generation.
For the .c files generated by BIN2C the compile target created a .d file
which indicated that the .ptx.o file has a dependency on the ptx.c file.
And that dependency broke the normal make behavior with intermediate
files.

This patch compiles the BIN2C generated .c files without generating .d
files. In turn the files do not longer need to be added to the
.SECONDARY target in common.mak.

When interested in those files for debugging, a line can be added to the
corresponding Makefile like

.SECONDARY: %.ptx.c %.ptx.gz


V2
==

 * Fix MSVC build
   (use the universal command pattern)

Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-80%2Fsoftworkz%2Fsubmit_commonmak-v2
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-80/softworkz/submit_commonmak-v2
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/80

Range-diff vs v1:

 1:  e276f54ffc ! 1:  f468ea2431 ffbuild/commonmak: Fix rebuild check with 
implicit rule chains
 @@ ffbuild/common.mak: else
   endif
   
  +%.ptx.o: %.ptx.c
 -+ $(CC) $(CCFLAGS) -x c -c -o $@ $<
 ++ $(CC) $(CCFLAGS) $(CC_C) $(CC_O) $(patsubst 
$(SRC_PATH)/%,$(SRC_LINK)/%,$<)
  +
  +
   # 1) Preprocess CSS to a minified version
 @@ ffbuild/common.mak: else   # NO COMPRESSION
   endif
   
  +%.html.o: %.html.c
 -+ $(CC) $(CCFLAGS) -x c -c -o $@ $<
 ++ $(CC) $(CCFLAGS) $(CC_C) $(CC_O) $(patsubst 
$(SRC_PATH)/%,$(SRC_LINK)/%,$<)
  +
  +%.css.o: %.css.c
 -+ $(CC) $(CCFLAGS) -x c -c -o $@ $<
 ++ $(CC) $(CCFLAGS) $(CC_C) $(CC_O) $(patsubst 
$(SRC_PATH)/%,$(SRC_LINK)/%,$<)
  +
  +
   clean::


 ffbuild/common.mak | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/ffbuild/common.mak b/ffbuild/common.mak
index 0e1eb1f62b..d9462271d5 100644
--- a/ffbuild/common.mak
+++ b/ffbuild/common.mak
@@ -139,6 +139,10 @@ else
$(BIN2C) $(patsubst $(SRC_PATH)/%,$(SRC_LINK)/%,$<) $@ $(subst 
.,_,$(basename $(notdir $@)))
 endif
 
+%.ptx.o: %.ptx.c
+   $(CC) $(CCFLAGS) $(CC_C) $(CC_O) $(patsubst 
$(SRC_PATH)/%,$(SRC_LINK)/%,$<)
+
+
 # 1) Preprocess CSS to a minified version
 %.css.min: %.css
# Must start with a tab in the real Makefile
@@ -177,6 +181,13 @@ else   # NO COMPRESSION
$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
 endif
 
+%.html.o: %.html.c
+   $(CC) $(CCFLAGS) $(CC_C) $(CC_O) $(patsubst 
$(SRC_PATH)/%,$(SRC_LINK)/%,$<)
+
+%.css.o: %.css.c
+   $(CC) $(CCFLAGS) $(CC_C) $(CC_O) $(patsubst 
$(SRC_PATH)/%,$(SRC_LINK)/%,$

Re: [FFmpeg-devel] [PATCH v1] lavc/vvc: Validate num_signalled_palette_entries

2025-05-17 Thread Frank Plowman
On 18/05/2025 02:42, Nuo Mi wrote:
> Hi Frank,
> 👍,your fuzzing infrastructure caught this issue as well.
> How about this:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20250517055150.807683-1-nuomi2...@gmail.com/

Sorry, I missed this.  Your patch looks good to me: probably preferable
in that it also validates the predicted size by the looks of it
(although I don't have a stream which exercises this aspect).

> 
> On Sun, May 18, 2025 at 5:05 AM Frank Plowman  wrote:
> 
>> "The value of CurrentPaletteSize[ startComp ] shall be in the range of 0
>> to maxNumPaletteEntries, inclusive."
>>
>> Signed-off-by: Frank Plowman 
>> ---
>>  libavcodec/vvc/ctu.c | 14 +++---
>>  1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
>> index 62c9d4f5c0..70800ba5fa 100644
>> --- a/libavcodec/vvc/ctu.c
>> +++ b/libavcodec/vvc/ctu.c
>> @@ -20,6 +20,7 @@
>>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>> 02110-1301 USA
>>   */
>>
>> +#include "libavutil/error.h"
>>  #include "libavutil/refstruct.h"
>>
>>  #include "cabac.h"
>> @@ -1873,7 +1874,7 @@ static void palette_predicted(VVCLocalContext *lc,
>> const bool local_dual_tree, i
>>  cu->plt[c].size = nb_predicted;
>>  }
>>
>> -static void palette_signaled(VVCLocalContext *lc, const bool
>> local_dual_tree,
>> +static int palette_signaled(VVCLocalContext *lc, const bool
>> local_dual_tree,
>>  const int start, const int end, const int max_entries)
>>  {
>>  const VVCSPS *sps = lc->fc->ps.sps;
>> @@ -1883,6 +1884,9 @@ static void palette_signaled(VVCLocalContext *lc,
>> const bool local_dual_tree,
>>  const int size= nb_predicted + nb_signaled;
>>  const bool dual_tree_luma = local_dual_tree && cu->tree_type ==
>> DUAL_TREE_LUMA;
>>
>> +if (size > max_entries)
>> +return AVERROR_INVALIDDATA;
>> +
>>  for (int c = start; c < end; c++) {
>>  Palette *plt = cu->plt + c;
>>  for (int i = nb_predicted; i < size; i++) {
>> @@ -1894,6 +1898,8 @@ static void palette_signaled(VVCLocalContext *lc,
>> const bool local_dual_tree,
>>  }
>>  plt->size = size;
>>  }
>> +
>> +return 0;
>>  }
>>
>>  static void palette_update_predictor(VVCLocalContext *lc, const bool
>> local_dual_tree, int start, int end,
>> @@ -2070,7 +2076,7 @@ static int hls_palette_coding(VVCLocalContext *lc,
>> const VVCTreeType tree_type)
>>  int max_index = 0;
>>  int prev_run_pos  = 0;
>>
>> -int predictor_size, start, end;
>> +int predictor_size, start, end, ret;
>>  bool reused[VVC_MAX_NUM_PALETTE_PREDICTOR_SIZE];
>>  uint8_t run_type[MAX_PALETTE_CU_SIZE * MAX_PALETTE_CU_SIZE];
>>  uint8_t index[MAX_PALETTE_CU_SIZE * MAX_PALETTE_CU_SIZE];
>> @@ -2083,7 +2089,9 @@ static int hls_palette_coding(VVCLocalContext *lc,
>> const VVCTreeType tree_type)
>>  predictor_size = pp[start].size;
>>  memset(reused, 0, sizeof(reused[0]) * predictor_size);
>>  palette_predicted(lc, local_dual_tree, start, end, reused,
>> predictor_size, max_entries);
>> -palette_signaled(lc, local_dual_tree, start, end, max_entries);
>> +ret = palette_signaled(lc, local_dual_tree, start, end, max_entries);
>> +if (ret < 0)
>> +return ret;
>>  palette_update_predictor(lc, local_dual_tree, start, end, reused,
>> predictor_size);
>>
>>  if (cu->plt[start].size > 0)
>> --
>> 2.47.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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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