[FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for gzip support in zlib

[FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for gzip support in zlib

[Ramiro Polla]

We currently test at build-time whether zlib supports decoding gzip.
This is not needed for the build to succeed, since only the gzip
command is necessary to perform compression at build-time.

Presumably this check will help the user by not enabling compression at
build-time if their system won't be able to decompress at runtime.

But there are no guarantees that the system where the build is made is
the same system where it will run. The build system could support gzip
in zlib, but not the system at runtime, or the other way around.

Realistically, the chances of there being a system where zlib does not
support gzip are very slim. It is safe to assume that zlib will support
gzip.

This commit changes the dependency for support of compressed resources
and ptx files to normal zlib support, and the existence of the gzip
command.
---
 configure | 13 ++-----------
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/configure b/configure
index 3730b0524c..79c4fcf327 100755
--- a/configure
+++ b/configure
@@ -2548,7 +2548,6 @@ HAVE_LIST="
     posix_ioctl
     texi2html
     xmllint
-    zlib_gzip
     openvino2
 "
 
@@ -6895,19 +6894,11 @@ enabled  zlib && { check_pkg_config zlib zlib "zlib.h" zlibVersion ||
 enabled bzlib && check_lib bzlib bzlib.h BZ2_bzlibVersion    -lbz2
 enabled  lzma && check_lib lzma   lzma.h lzma_version_number -llzma
 
-enabled zlib && test_exec $zlib_extralibs <<EOF && enable zlib_gzip
-#include <zlib.h>
-int main(void) {
-    if (zlibCompileFlags() & (1 << 17)) return 1;
-    return 0;
-}
-EOF
-
 [ -x "$(command -v gzip)" ] && enable gzip
 
-enabled zlib_gzip && enabled gzip || disable ptx_compression
+enabled zlib && enabled gzip || disable ptx_compression
 
-enabled zlib_gzip && enabled gzip || disable resource_compression
+enabled zlib && enabled gzip || disable resource_compression
 
 # On some systems dynamic loading requires no extra linker flags
 check_lib libdl dlfcn.h "dlopen dlsym" || check_lib libdl dlfcn.h "dlopen dlsym" -ldl
-- 
2.39.5

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

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

[FFmpeg-devel] [PATCH 2/5] configure: move embedded resource checks to dependency tracker

[Ramiro Polla]

---
 configure | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/configure b/configure
index 79c4fcf327..c19e0bc081 100755
--- a/configure
+++ b/configure
@@ -4113,6 +4113,10 @@ htmlpages_deps_any="makeinfo_html texi2html"
 txtpages_deps="perl makeinfo"
 doc_deps_any="manpages htmlpages podpages txtpages"
 
+# embedded resources
+ptx_compression_deps="zlib gzip"
+resource_compression_deps="zlib gzip"
+
 # default parameters
 
 logfile="ffbuild/config.log"
@@ -6896,10 +6900,6 @@ enabled  lzma && check_lib lzma   lzma.h lzma_version_number -llzma
 
 [ -x "$(command -v gzip)" ] && enable gzip
 
-enabled zlib && enabled gzip || disable ptx_compression
-
-enabled zlib && enabled gzip || disable resource_compression
-
 # On some systems dynamic loading requires no extra linker flags
 check_lib libdl dlfcn.h "dlopen dlsym" || check_lib libdl dlfcn.h "dlopen dlsym" -ldl
 
-- 
2.39.5

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

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

[FFmpeg-devel] [PATCH 3/5] configure: improve gzip check

[Ramiro Polla]

Test that the command actually runs.
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index c19e0bc081..7939228e0d 100755
--- a/configure
+++ b/configure
@@ -6898,7 +6898,7 @@ enabled  zlib && { check_pkg_config zlib zlib "zlib.h" zlibVersion ||
 enabled bzlib && check_lib bzlib bzlib.h BZ2_bzlibVersion    -lbz2
 enabled  lzma && check_lib lzma   lzma.h lzma_version_number -llzma
 
-[ -x "$(command -v gzip)" ] && enable gzip
+gzip -V > /dev/null 2>&1 && enable gzip
 
 # On some systems dynamic loading requires no extra linker flags
 check_lib libdl dlfcn.h "dlopen dlsym" || check_lib libdl dlfcn.h "dlopen dlsym" -ldl
-- 
2.39.5

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

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

[FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move fftools/resources-specific code its Makefile

[Ramiro Polla]

- Intermediate files are no longer removed;
- A .res suffix has been added to resource files, so that there's no
  need to add new rules for each new filetype;
- Superfluous comments have been removed;
- Targets depending on CONFIG_RESOURCE_COMPRESSION have been
  deduplicated.
---
 ffbuild/common.mak                            | 45 +------------------
 fftools/resources/.gitignore                  |  7 ++-
 fftools/resources/Makefile                    | 31 ++++++++++---
 .../resources/{graph.css => graph.css.res}    |  0
 .../resources/{graph.html => graph.html.res}  |  0
 fftools/resources/resman.c                    | 12 ++---
 6 files changed, 36 insertions(+), 59 deletions(-)
 rename fftools/resources/{graph.css => graph.css.res} (100%)
 rename fftools/resources/{graph.html => graph.html.res} (100%)

diff --git a/ffbuild/common.mak b/ffbuild/common.mak
index ddf48923ea..27dd48a4e6 100644
--- a/ffbuild/common.mak
+++ b/ffbuild/common.mak
@@ -139,46 +139,6 @@ else
 	$(BIN2C) $(patsubst $(SRC_PATH)/%,$(SRC_LINK)/%,$<) $@ $(subst .,_,$(basename $(notdir $@)))
 endif
 
-# 1) Preprocess CSS to a minified version
-%.css.min: TAG = SED
-%.css.min: %.css
-	$(M)sed 's!/\\*.*\\*/!!g' $< \
-	| tr '\n' ' ' \
-	| tr -s ' ' \
-	| sed 's/^ //; s/ $$//' \
-	> $@
-
-ifdef CONFIG_RESOURCE_COMPRESSION
-
-# 2) Gzip the minified CSS
-%.css.min.gz: TAG = GZIP
-%.css.min.gz: %.css.min
-	$(M)gzip -nc9 $< > $@
-
-# 3) Convert the gzipped CSS to a .c array
-%.css.c: %.css.min.gz $(BIN2CEXE)
-	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
-
-# 4) Gzip the HTML file (no minification needed)
-%.html.gz: TAG = GZIP
-%.html.gz: %.html
-	$(M)gzip -nc9 $< > $@
-
-# 5) Convert the gzipped HTML to a .c array
-%.html.c: %.html.gz $(BIN2CEXE)
-	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
-
-else   # NO COMPRESSION
-
-# 2) Convert the minified CSS to a .c array
-%.css.c: %.css.min $(BIN2CEXE)
-	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
-
-# 3) Convert the plain HTML to a .c array
-%.html.c: %.html $(BIN2CEXE)
-	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
-endif
-
 clean::
 	$(RM) $(BIN2CEXE) $(CLEANSUFFIXES:%=ffbuild/%)
 
@@ -229,10 +189,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)
 
@@ -252,7 +211,7 @@ $(TOOLOBJS): | tools
 
 OUTDIRS := $(OUTDIRS) $(dir $(OBJS) $(HOBJS) $(HOSTOBJS) $(SHLIBOBJS) $(STLIBOBJS) $(TESTOBJS))
 
-CLEANSUFFIXES     = *.d *.gcda *.gcno *.h.c *.ho *.map *.o *.objs *.pc *.ptx *.ptx.gz *.ptx.c *.ver *.version *.html.gz *.html.c *.css.gz *.css.c  *$(DEFAULT_X86ASMD).asm *~ *.ilk *.pdb
+CLEANSUFFIXES     = *.d *.gcda *.gcno *.h.c *.ho *.map *.o *.objs *.pc *.ptx *.ptx.gz *.ptx.c *.ver *.version *.min.res *.res.gz *.res.c *$(DEFAULT_X86ASMD).asm *~ *.ilk *.pdb
 LIBSUFFIXES       = *.a *.lib *.so *.so.* *.dylib *.dll *.def *.dll.a
 
 define RULES
diff --git a/fftools/resources/.gitignore b/fftools/resources/.gitignore
index 5f496535a6..4c56856284 100644
--- a/fftools/resources/.gitignore
+++ b/fftools/resources/.gitignore
@@ -1,4 +1,3 @@
-*.html.c
-*.css.c
-*.html.gz
-*.css.gz
+*.res.c
+*.res.gz
+*.res
diff --git a/fftools/resources/Makefile b/fftools/resources/Makefile
index 8579a52678..a8eb111441 100644
--- a/fftools/resources/Makefile
+++ b/fftools/resources/Makefile
@@ -1,13 +1,32 @@
 clean::
 	$(RM) $(CLEANSUFFIXES:%=fftools/resources/%)
 
-vpath %.html $(SRC_PATH)
-vpath %.css  $(SRC_PATH)
+vpath %.res $(SRC_PATH)
 
-# Uncomment to prevent deletion during build
-#.PRECIOUS: %.css.c %.css.min %.css.gz %.css.min.gz %.html.gz %.html.c
+RESOURCEOBJS += fftools/resources/graph.css.min.res.o
+RESOURCEOBJS += fftools/resources/graph.html.res.o
 
 OBJS-resman +=                     \
     fftools/resources/resman.o     \
-    fftools/resources/graph.html.o \
-    fftools/resources/graph.css.o  \
+    $(RESOURCEOBJS)
+
+%.css.min.res: TAG = SED
+%.css.min.res: %.css.res
+	$(M)sed 's!/\\*.*\\*/!!g' $< \
+	| tr '\n' ' ' \
+	| tr -s ' ' \
+	| sed 's/^ //; s/ $$//' \
+	> $@
+
+ifdef CONFIG_RESOURCE_COMPRESSION
+RES_GZ = .gz
+endif
+
+%.res.gz: TAG = GZIP
+%.res.gz: %.res
+	$(M)gzip -nc9 $< > $@
+
+%.res.c: %.res$(RES_GZ) $(BIN2CEXE)
+	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
+
+.SECONDARY: $(RESOURCEOBJS:.o=) $(RESOURCEOBJS:.o=.c) $(RESOURCEOBJS:.o=.gz)
diff --git a/fftools/resources/graph.css b/fftools/resources/graph.css.res
similarity index 100%
rename from fftools/resources/graph.css
rename to fftools/resources/graph.css.res
diff --git a/fftools/resources/graph.html b/fftools/resources/graph.html.res
similarity index 100%
rename from fftools/resources/graph.html
rename to fftools/resources/graph.html.res
diff --git a/fftools/resources/resman.c b/fftools/resources/resman.c
index a9e21626fa..00518efd87 100644
--- a/fftools/resources/resman.c
+++ b/fftools/resources/resman.c
@@ -38,15 +38,15 @@
 #include "libavutil/dict.h"
 #include "libavutil/common.h"
 
-extern const unsigned char ff_graph_html_data[];
-extern const unsigned int ff_graph_html_len;
+extern const unsigned char ff_graph_html_res_data[];
+extern const unsigned int ff_graph_html_res_len;
 
-extern const unsigned char ff_graph_css_data[];
-extern const unsigned ff_graph_css_len;
+extern const unsigned char ff_graph_css_min_res_data[];
+extern const unsigned ff_graph_css_min_res_len;
 
 static const FFResourceDefinition resource_definitions[] = {
-    [FF_RESOURCE_GRAPH_CSS]   = { FF_RESOURCE_GRAPH_CSS,   "graph.css",   &ff_graph_css_data[0],   &ff_graph_css_len   },
-    [FF_RESOURCE_GRAPH_HTML]  = { FF_RESOURCE_GRAPH_HTML,  "graph.html",  &ff_graph_html_data[0],  &ff_graph_html_len  },
+    [FF_RESOURCE_GRAPH_CSS]   = { FF_RESOURCE_GRAPH_CSS,   "graph.css",   &ff_graph_css_min_res_data[0],  &ff_graph_css_min_res_len },
+    [FF_RESOURCE_GRAPH_HTML]  = { FF_RESOURCE_GRAPH_HTML,  "graph.html",  &ff_graph_html_res_data[0],     &ff_graph_html_res_len    },
 };
 
 
-- 
2.39.5

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

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

[FFmpeg-devel] [PATCH 5/5] fftools/Makefile: clean files from fftools/{graph, textformat}/

[Ramiro Polla]

---
 fftools/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/Makefile b/fftools/Makefile
index c1eba733da..b3c08ae5a0 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -92,4 +92,4 @@ uninstall-progs:
 	$(RM) $(addprefix "$(BINDIR)/", $(ALLAVPROGS))
 
 clean::
-	$(RM) $(ALLAVPROGS) $(ALLAVPROGS_G) $(CLEANSUFFIXES:%=fftools/%)
+	$(RM) $(ALLAVPROGS) $(ALLAVPROGS_G) $(CLEANSUFFIXES:%=fftools/%) $(CLEANSUFFIXES:%=fftools/graph/%) $(CLEANSUFFIXES:%=fftools/textformat/%)
-- 
2.39.5

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

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

Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for gzip support in zlib

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> Sent: Dienstag, 27. Mai 2025 03:33
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for
> gzip support in zlib
> 
> We currently test at build-time whether zlib supports decoding gzip.
> This is not needed for the build to succeed, since only the gzip
> command is necessary to perform compression at build-time.
> 
> Presumably this check will help the user by not enabling compression at
> build-time if their system won't be able to decompress at runtime.
> 
> But there are no guarantees that the system where the build is made is
> the same system where it will run. The build system could support gzip
> in zlib, but not the system at runtime, or the other way around.

Hi,

What about static builds? Doesn't the check test exactly the zlib lib
that will go into the binary?

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move fftools/resources-specific code its Makefile

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> Sent: Dienstag, 27. Mai 2025 03:33
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move
> fftools/resources-specific code its Makefile
> 
> - Intermediate files are no longer removed;
> - A .res suffix has been added to resource files, so that there's no
>   need to add new rules for each new filetype;
> - Superfluous comments have been removed;
> - Targets depending on CONFIG_RESOURCE_COMPRESSION have been
>   deduplicated.
> ---
>  ffbuild/common.mak                            | 45 +------------------
>  fftools/resources/.gitignore                  |  7 ++-
>  fftools/resources/Makefile                    | 31 ++++++++++---
>  .../resources/{graph.css => graph.css.res}    |  0
>  .../resources/{graph.html => graph.html.res}  |  0
>  fftools/resources/resman.c                    | 12 ++---
>  6 files changed, 36 insertions(+), 59 deletions(-)
>  rename fftools/resources/{graph.css => graph.css.res} (100%)
>  rename fftools/resources/{graph.html => graph.html.res} (100%)
> 
> diff --git a/ffbuild/common.mak b/ffbuild/common.mak
> index ddf48923ea..27dd48a4e6 100644
> --- a/ffbuild/common.mak
> +++ b/ffbuild/common.mak
> @@ -139,46 +139,6 @@ else
>  	$(BIN2C) $(patsubst $(SRC_PATH)/%,$(SRC_LINK)/%,$<) $@ $(subst
> .,_,$(basename $(notdir $@)))
>  endif
> 
> -# 1) Preprocess CSS to a minified version
> -%.css.min: TAG = SED
> -%.css.min: %.css
> -	$(M)sed 's!/\\*.*\\*/!!g' $< \
> -	| tr '\n' ' ' \
> -	| tr -s ' ' \
> -	| sed 's/^ //; s/ $$//' \
> -	> $@
> -
> -ifdef CONFIG_RESOURCE_COMPRESSION
> -
> -# 2) Gzip the minified CSS
> -%.css.min.gz: TAG = GZIP
> -%.css.min.gz: %.css.min
> -	$(M)gzip -nc9 $< > $@
> -
> -# 3) Convert the gzipped CSS to a .c array
> -%.css.c: %.css.min.gz $(BIN2CEXE)
> -	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
> -
> -# 4) Gzip the HTML file (no minification needed)
> -%.html.gz: TAG = GZIP
> -%.html.gz: %.html
> -	$(M)gzip -nc9 $< > $@
> -
> -# 5) Convert the gzipped HTML to a .c array
> -%.html.c: %.html.gz $(BIN2CEXE)
> -	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
> -
> -else   # NO COMPRESSION
> -
> -# 2) Convert the minified CSS to a .c array
> -%.css.c: %.css.min $(BIN2CEXE)
> -	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
> -
> -# 3) Convert the plain HTML to a .c array
> -%.html.c: %.html $(BIN2CEXE)
> -	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
> -endif
> -
>  clean::
>  	$(RM) $(BIN2CEXE) $(CLEANSUFFIXES:%=ffbuild/%)
> 
> @@ -229,10 +189,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)
> 
> @@ -252,7 +211,7 @@ $(TOOLOBJS): | tools
> 
>  OUTDIRS := $(OUTDIRS) $(dir $(OBJS) $(HOBJS) $(HOSTOBJS) $(SHLIBOBJS)
> $(STLIBOBJS) $(TESTOBJS))
> 
> -CLEANSUFFIXES     = *.d *.gcda *.gcno *.h.c *.ho *.map *.o *.objs *.pc *.ptx
> *.ptx.gz *.ptx.c *.ver *.version *.html.gz *.html.c *.css.gz *.css.c
> *$(DEFAULT_X86ASMD).asm *~ *.ilk *.pdb
> +CLEANSUFFIXES     = *.d *.gcda *.gcno *.h.c *.ho *.map *.o *.objs *.pc *.ptx
> *.ptx.gz *.ptx.c *.ver *.version *.min.res *.res.gz *.res.c
> *$(DEFAULT_X86ASMD).asm *~ *.ilk *.pdb
>  LIBSUFFIXES       = *.a *.lib *.so *.so.* *.dylib *.dll *.def *.dll.a
> 
>  define RULES
> diff --git a/fftools/resources/.gitignore b/fftools/resources/.gitignore
> index 5f496535a6..4c56856284 100644
> --- a/fftools/resources/.gitignore
> +++ b/fftools/resources/.gitignore
> @@ -1,4 +1,3 @@
> -*.html.c
> -*.css.c
> -*.html.gz
> -*.css.gz
> +*.res.c
> +*.res.gz
> +*.res
> diff --git a/fftools/resources/Makefile b/fftools/resources/Makefile
> index 8579a52678..a8eb111441 100644
> --- a/fftools/resources/Makefile
> +++ b/fftools/resources/Makefile
> @@ -1,13 +1,32 @@
>  clean::
>  	$(RM) $(CLEANSUFFIXES:%=fftools/resources/%)
> 
> -vpath %.html $(SRC_PATH)
> -vpath %.css  $(SRC_PATH)
> +vpath %.res $(SRC_PATH)
> 
> -# Uncomment to prevent deletion during build
> -#.PRECIOUS: %.css.c %.css.min %.css.gz %.css.min.gz %.html.gz %.html.c
> +RESOURCEOBJS += fftools/resources/graph.css.min.res.o
> +RESOURCEOBJS += fftools/resources/graph.html.res.o
> 
>  OBJS-resman +=                     \
>      fftools/resources/resman.o     \
> -    fftools/resources/graph.html.o \
> -    fftools/resources/graph.css.o  \
> +    $(RESOURCEOBJS)
> +
> +%.css.min.res: TAG = SED
> +%.css.min.res: %.css.res
> +	$(M)sed 's!/\\*.*\\*/!!g' $< \
> +	| tr '\n' ' ' \
> +	| tr -s ' ' \
> +	| sed 's/^ //; s/ $$//' \
> +	> $@
> +
> +ifdef CONFIG_RESOURCE_COMPRESSION
> +RES_GZ = .gz
> +endif
> +
> +%.res.gz: TAG = GZIP
> +%.res.gz: %.res
> +	$(M)gzip -nc9 $< > $@
> +
> +%.res.c: %.res$(RES_GZ) $(BIN2CEXE)
> +	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
> +
> +.SECONDARY: $(RESOURCEOBJS:.o=) $(RESOURCEOBJS:.o=.c) $(RESOURCEOBJS:.o=.gz)
> diff --git a/fftools/resources/graph.css b/fftools/resources/graph.css.res
> similarity index 100%
> rename from fftools/resources/graph.css
> rename to fftools/resources/graph.css.res
> diff --git a/fftools/resources/graph.html b/fftools/resources/graph.html.res
> similarity index 100%
> rename from fftools/resources/graph.html
> rename to fftools/resources/graph.html.res
> diff --git a/fftools/resources/resman.c b/fftools/resources/resman.c
> index a9e21626fa..00518efd87 100644
> --- a/fftools/resources/resman.c
> +++ b/fftools/resources/resman.c
> @@ -38,15 +38,15 @@
>  #include "libavutil/dict.h"
>  #include "libavutil/common.h"
> 
> -extern const unsigned char ff_graph_html_data[];
> -extern const unsigned int ff_graph_html_len;
> +extern const unsigned char ff_graph_html_res_data[];
> +extern const unsigned int ff_graph_html_res_len;
> 
> -extern const unsigned char ff_graph_css_data[];
> -extern const unsigned ff_graph_css_len;
> +extern const unsigned char ff_graph_css_min_res_data[];
> +extern const unsigned ff_graph_css_min_res_len;
> 
>  static const FFResourceDefinition resource_definitions[] = {
> -    [FF_RESOURCE_GRAPH_CSS]   = { FF_RESOURCE_GRAPH_CSS,   "graph.css",
> &ff_graph_css_data[0],   &ff_graph_css_len   },
> -    [FF_RESOURCE_GRAPH_HTML]  = { FF_RESOURCE_GRAPH_HTML,  "graph.html",
> &ff_graph_html_data[0],  &ff_graph_html_len  },
> +    [FF_RESOURCE_GRAPH_CSS]   = { FF_RESOURCE_GRAPH_CSS,   "graph.css",
> &ff_graph_css_min_res_data[0],  &ff_graph_css_min_res_len },
> +    [FF_RESOURCE_GRAPH_HTML]  = { FF_RESOURCE_GRAPH_HTML,  "graph.html",
> &ff_graph_html_res_data[0],     &ff_graph_html_res_len    },
>  };
> 
> 
> --

I actually wanted to push this tomorrow:

https://patchwork.ffmpeg.org/project/ffmpeg/patch/pull.80.v4.ffstaging.FFmpeg.1748037922309.ffmpegagent@gmail.com/

As discussed with Timo, the V4 keeps .ptx files unconditionally while 
all other intermediates are handled as intermediates per Gnu make 
default behavior (i.e. get deleted)

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for gzip support in zlib

[Ramiro Polla]

On Tue, May 27, 2025 at 3:44 AM softworkz .
<softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> > Sent: Dienstag, 27. Mai 2025 03:33
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for
> > gzip support in zlib
> >
> > We currently test at build-time whether zlib supports decoding gzip.
> > This is not needed for the build to succeed, since only the gzip
> > command is necessary to perform compression at build-time.
> >
> > Presumably this check will help the user by not enabling compression at
> > build-time if their system won't be able to decompress at runtime.
> >
> > But there are no guarantees that the system where the build is made is
> > the same system where it will run. The build system could support gzip
> > in zlib, but not the system at runtime, or the other way around.
>
> What about static builds? Doesn't the check test exactly the zlib lib
> that will go into the binary?

Perhaps, but it's an unnecessary test in any case. test_exec should
only be used for very important tests.

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

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

Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move fftools/resources-specific code its Makefile

[softworkz .]

Hi Ramiro,

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> Sent: Dienstag, 27. Mai 2025 03:33
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move
> fftools/resources-specific code its Makefile
> 
> - Intermediate files are no longer removed;

Why? That's the way it's meant to work and it's working fine (will push tomorrow) 

> - A .res suffix has been added to resource files, so that there's no
>   need to add new rules for each new filetype;

I don't want this. I want the editor to be aware of the file type when opening.

Thanks,
sw

> - Superfluous comments have been removed;
> - Targets depending on CONFIG_RESOURCE_COMPRESSION have been
>   deduplicated.
> ---
>  ffbuild/common.mak                            | 45 +------------------
>  fftools/resources/.gitignore                  |  7 ++-
>  fftools/resources/Makefile                    | 31 ++++++++++---
>  .../resources/{graph.css => graph.css.res}    |  0
>  .../resources/{graph.html => graph.html.res}  |  0
>  fftools/resources/resman.c                    | 12 ++---
>  6 files changed, 36 insertions(+), 59 deletions(-)
>  rename fftools/resources/{graph.css => graph.css.res} (100%)
>  rename fftools/resources/{graph.html => graph.html.res} (100%)
> 
> diff --git a/ffbuild/common.mak b/ffbuild/common.mak
> index ddf48923ea..27dd48a4e6 100644
> --- a/ffbuild/common.mak
> +++ b/ffbuild/common.mak
> @@ -139,46 +139,6 @@ else
>  	$(BIN2C) $(patsubst $(SRC_PATH)/%,$(SRC_LINK)/%,$<) $@ $(subst
> .,_,$(basename $(notdir $@)))
>  endif
> 
> -# 1) Preprocess CSS to a minified version
> -%.css.min: TAG = SED
> -%.css.min: %.css
> -	$(M)sed 's!/\\*.*\\*/!!g' $< \
> -	| tr '\n' ' ' \
> -	| tr -s ' ' \
> -	| sed 's/^ //; s/ $$//' \
> -	> $@
> -
> -ifdef CONFIG_RESOURCE_COMPRESSION
> -
> -# 2) Gzip the minified CSS
> -%.css.min.gz: TAG = GZIP
> -%.css.min.gz: %.css.min
> -	$(M)gzip -nc9 $< > $@
> -
> -# 3) Convert the gzipped CSS to a .c array
> -%.css.c: %.css.min.gz $(BIN2CEXE)
> -	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
> -
> -# 4) Gzip the HTML file (no minification needed)
> -%.html.gz: TAG = GZIP
> -%.html.gz: %.html
> -	$(M)gzip -nc9 $< > $@
> -
> -# 5) Convert the gzipped HTML to a .c array
> -%.html.c: %.html.gz $(BIN2CEXE)
> -	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
> -
> -else   # NO COMPRESSION
> -
> -# 2) Convert the minified CSS to a .c array
> -%.css.c: %.css.min $(BIN2CEXE)
> -	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
> -
> -# 3) Convert the plain HTML to a .c array
> -%.html.c: %.html $(BIN2CEXE)
> -	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
> -endif
> -
>  clean::
>  	$(RM) $(BIN2CEXE) $(CLEANSUFFIXES:%=ffbuild/%)
> 
> @@ -229,10 +189,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)
> 
> @@ -252,7 +211,7 @@ $(TOOLOBJS): | tools
> 
>  OUTDIRS := $(OUTDIRS) $(dir $(OBJS) $(HOBJS) $(HOSTOBJS) $(SHLIBOBJS)
> $(STLIBOBJS) $(TESTOBJS))
> 
> -CLEANSUFFIXES     = *.d *.gcda *.gcno *.h.c *.ho *.map *.o *.objs *.pc *.ptx
> *.ptx.gz *.ptx.c *.ver *.version *.html.gz *.html.c *.css.gz *.css.c
> *$(DEFAULT_X86ASMD).asm *~ *.ilk *.pdb
> +CLEANSUFFIXES     = *.d *.gcda *.gcno *.h.c *.ho *.map *.o *.objs *.pc *.ptx
> *.ptx.gz *.ptx.c *.ver *.version *.min.res *.res.gz *.res.c
> *$(DEFAULT_X86ASMD).asm *~ *.ilk *.pdb
>  LIBSUFFIXES       = *.a *.lib *.so *.so.* *.dylib *.dll *.def *.dll.a
> 
>  define RULES
> diff --git a/fftools/resources/.gitignore b/fftools/resources/.gitignore
> index 5f496535a6..4c56856284 100644
> --- a/fftools/resources/.gitignore
> +++ b/fftools/resources/.gitignore
> @@ -1,4 +1,3 @@
> -*.html.c
> -*.css.c
> -*.html.gz
> -*.css.gz
> +*.res.c
> +*.res.gz
> +*.res
> diff --git a/fftools/resources/Makefile b/fftools/resources/Makefile
> index 8579a52678..a8eb111441 100644
> --- a/fftools/resources/Makefile
> +++ b/fftools/resources/Makefile
> @@ -1,13 +1,32 @@
>  clean::
>  	$(RM) $(CLEANSUFFIXES:%=fftools/resources/%)
> 
> -vpath %.html $(SRC_PATH)
> -vpath %.css  $(SRC_PATH)
> +vpath %.res $(SRC_PATH)
> 
> -# Uncomment to prevent deletion during build
> -#.PRECIOUS: %.css.c %.css.min %.css.gz %.css.min.gz %.html.gz %.html.c
> +RESOURCEOBJS += fftools/resources/graph.css.min.res.o
> +RESOURCEOBJS += fftools/resources/graph.html.res.o
> 
>  OBJS-resman +=                     \
>      fftools/resources/resman.o     \
> -    fftools/resources/graph.html.o \
> -    fftools/resources/graph.css.o  \
> +    $(RESOURCEOBJS)
> +
> +%.css.min.res: TAG = SED
> +%.css.min.res: %.css.res
> +	$(M)sed 's!/\\*.*\\*/!!g' $< \
> +	| tr '\n' ' ' \
> +	| tr -s ' ' \
> +	| sed 's/^ //; s/ $$//' \
> +	> $@
> +
> +ifdef CONFIG_RESOURCE_COMPRESSION
> +RES_GZ = .gz
> +endif
> +
> +%.res.gz: TAG = GZIP
> +%.res.gz: %.res
> +	$(M)gzip -nc9 $< > $@
> +
> +%.res.c: %.res$(RES_GZ) $(BIN2CEXE)
> +	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
> +
> +.SECONDARY: $(RESOURCEOBJS:.o=) $(RESOURCEOBJS:.o=.c) $(RESOURCEOBJS:.o=.gz)
> diff --git a/fftools/resources/graph.css b/fftools/resources/graph.css.res
> similarity index 100%
> rename from fftools/resources/graph.css
> rename to fftools/resources/graph.css.res
> diff --git a/fftools/resources/graph.html b/fftools/resources/graph.html.res
> similarity index 100%
> rename from fftools/resources/graph.html
> rename to fftools/resources/graph.html.res
> diff --git a/fftools/resources/resman.c b/fftools/resources/resman.c
> index a9e21626fa..00518efd87 100644
> --- a/fftools/resources/resman.c
> +++ b/fftools/resources/resman.c
> @@ -38,15 +38,15 @@
>  #include "libavutil/dict.h"
>  #include "libavutil/common.h"
> 
> -extern const unsigned char ff_graph_html_data[];
> -extern const unsigned int ff_graph_html_len;
> +extern const unsigned char ff_graph_html_res_data[];
> +extern const unsigned int ff_graph_html_res_len;
> 
> -extern const unsigned char ff_graph_css_data[];
> -extern const unsigned ff_graph_css_len;
> +extern const unsigned char ff_graph_css_min_res_data[];
> +extern const unsigned ff_graph_css_min_res_len;
> 
>  static const FFResourceDefinition resource_definitions[] = {
> -    [FF_RESOURCE_GRAPH_CSS]   = { FF_RESOURCE_GRAPH_CSS,   "graph.css",
> &ff_graph_css_data[0],   &ff_graph_css_len   },
> -    [FF_RESOURCE_GRAPH_HTML]  = { FF_RESOURCE_GRAPH_HTML,  "graph.html",
> &ff_graph_html_data[0],  &ff_graph_html_len  },
> +    [FF_RESOURCE_GRAPH_CSS]   = { FF_RESOURCE_GRAPH_CSS,   "graph.css",
> &ff_graph_css_min_res_data[0],  &ff_graph_css_min_res_len },
> +    [FF_RESOURCE_GRAPH_HTML]  = { FF_RESOURCE_GRAPH_HTML,  "graph.html",
> &ff_graph_html_res_data[0],     &ff_graph_html_res_len    },
>  };
> 
> 
> --
> 2.39.5
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move fftools/resources-specific code its Makefile

[Ramiro Polla]

On Tue, May 27, 2025 at 3:48 AM softworkz .
<softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> > Sent: Dienstag, 27. Mai 2025 03:33
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move
> > fftools/resources-specific code its Makefile
[...]
> I actually wanted to push this tomorrow:
>
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/pull.80.v4.ffstaging.FFmpeg.1748037922309.ffmpegagent@gmail.com/
>
> As discussed with Timo, the V4 keeps .ptx files unconditionally while
> all other intermediates are handled as intermediates per Gnu make
> default behavior (i.e. get deleted)

It seems we don't delete any other intermediate files (i.e.: ptx and
vulkan). At least I don't remember seeing the rm commands at the end
of builds before like they appear now. I don't think we need to make
an exception for the resource files.

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

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

Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move fftools/resources-specific code its Makefile

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> Sent: Dienstag, 27. Mai 2025 04:05
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move
> fftools/resources-specific code its Makefile
> 
> On Tue, May 27, 2025 at 3:48 AM softworkz .
> <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro
> Polla
> > > Sent: Dienstag, 27. Mai 2025 03:33
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move
> > > fftools/resources-specific code its Makefile
> [...]
> > I actually wanted to push this tomorrow:
> >
> >
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/pull.80.v4.ffstaging.FFmpeg.
> 1748037922309.ffmpegagent@gmail.com/
> >
> > As discussed with Timo, the V4 keeps .ptx files unconditionally while
> > all other intermediates are handled as intermediates per Gnu make
> > default behavior (i.e. get deleted)
> 
> It seems we don't delete any other intermediate files (i.e.: ptx and
> vulkan). At least I don't remember seeing the rm commands at the end
> of builds before like they appear now. I don't think we need to make
> an exception for the resource files.

This is not about making exceptions. The use of .SECONDARY in order to retain
intermediates has only been a workaround because the rebuild condition that
came from the .d files hadn't been understood.
This is fixed now and make can do its job as intended without any workarounds.

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move fftools/resources-specific code its Makefile

[Ramiro Polla]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

On Tue, May 27, 2025 at 4:11 AM softworkz .
<softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> > Sent: Dienstag, 27. Mai 2025 03:33
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move
> > fftools/resources-specific code its Makefile
> >
> > - Intermediate files are no longer removed;
>
> Why? That's the way it's meant to work and it's working fine (will push tomorrow)

Deleting intermediate files prints an "rm" message at the end of the
build. It also deletes files that we might want to inspect later.

> > - A .res suffix has been added to resource files, so that there's no
> >   need to add new rules for each new filetype;
>
> I don't want this. I want the editor to be aware of the file type when opening.

Fair enough. New patch attached.

[-- Attachment #2: v2-0004-ffbuild-common.mak-clean-up-and-move-fftools-reso.patch --]
[-- Type: text/x-patch, Size: 5785 bytes --]

From 9fb4a90735eb1e5fc223128376b98bc7e3a8b597 Mon Sep 17 00:00:00 2001
From: Ramiro Polla <ramiro.polla@gmail.com>
Date: Tue, 27 May 2025 00:13:47 +0200
Subject: [PATCH v2 4/5] ffbuild/common.mak: clean up and move
 fftools/resources-specific code its Makefile

- Intermediate files are no longer removed;
- Superfluous comments have been removed;
- Targets depending on CONFIG_RESOURCE_COMPRESSION have been
  deduplicated.
---
 ffbuild/common.mak           | 45 ++----------------------------------
 fftools/resources/.gitignore |  5 ++--
 fftools/resources/Makefile   | 32 +++++++++++++++++++++----
 fftools/resources/resman.c   |  6 ++---
 4 files changed, 35 insertions(+), 53 deletions(-)

diff --git a/ffbuild/common.mak b/ffbuild/common.mak
index ddf48923ea..7060ba0bb0 100644
--- a/ffbuild/common.mak
+++ b/ffbuild/common.mak
@@ -139,46 +139,6 @@ else
 	$(BIN2C) $(patsubst $(SRC_PATH)/%,$(SRC_LINK)/%,$<) $@ $(subst .,_,$(basename $(notdir $@)))
 endif
 
-# 1) Preprocess CSS to a minified version
-%.css.min: TAG = SED
-%.css.min: %.css
-	$(M)sed 's!/\\*.*\\*/!!g' $< \
-	| tr '\n' ' ' \
-	| tr -s ' ' \
-	| sed 's/^ //; s/ $$//' \
-	> $@
-
-ifdef CONFIG_RESOURCE_COMPRESSION
-
-# 2) Gzip the minified CSS
-%.css.min.gz: TAG = GZIP
-%.css.min.gz: %.css.min
-	$(M)gzip -nc9 $< > $@
-
-# 3) Convert the gzipped CSS to a .c array
-%.css.c: %.css.min.gz $(BIN2CEXE)
-	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
-
-# 4) Gzip the HTML file (no minification needed)
-%.html.gz: TAG = GZIP
-%.html.gz: %.html
-	$(M)gzip -nc9 $< > $@
-
-# 5) Convert the gzipped HTML to a .c array
-%.html.c: %.html.gz $(BIN2CEXE)
-	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
-
-else   # NO COMPRESSION
-
-# 2) Convert the minified CSS to a .c array
-%.css.c: %.css.min $(BIN2CEXE)
-	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
-
-# 3) Convert the plain HTML to a .c array
-%.html.c: %.html $(BIN2CEXE)
-	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
-endif
-
 clean::
 	$(RM) $(BIN2CEXE) $(CLEANSUFFIXES:%=ffbuild/%)
 
@@ -229,10 +189,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)
 
@@ -252,7 +211,7 @@ $(TOOLOBJS): | tools
 
 OUTDIRS := $(OUTDIRS) $(dir $(OBJS) $(HOBJS) $(HOSTOBJS) $(SHLIBOBJS) $(STLIBOBJS) $(TESTOBJS))
 
-CLEANSUFFIXES     = *.d *.gcda *.gcno *.h.c *.ho *.map *.o *.objs *.pc *.ptx *.ptx.gz *.ptx.c *.ver *.version *.html.gz *.html.c *.css.gz *.css.c  *$(DEFAULT_X86ASMD).asm *~ *.ilk *.pdb
+CLEANSUFFIXES     = *.d *.gcda *.gcno *.h.c *.ho *.map *.o *.objs *.pc *.ptx *.ptx.gz *.ptx.c *.ver *.version *$(DEFAULT_X86ASMD).asm *~ *.ilk *.pdb
 LIBSUFFIXES       = *.a *.lib *.so *.so.* *.dylib *.dll *.def *.dll.a
 
 define RULES
diff --git a/fftools/resources/.gitignore b/fftools/resources/.gitignore
index 5f496535a6..8fc0e8b407 100644
--- a/fftools/resources/.gitignore
+++ b/fftools/resources/.gitignore
@@ -1,4 +1,5 @@
 *.html.c
-*.css.c
+*.min.c
 *.html.gz
-*.css.gz
+*.min.gz
+*.min
diff --git a/fftools/resources/Makefile b/fftools/resources/Makefile
index 8579a52678..fe82d02594 100644
--- a/fftools/resources/Makefile
+++ b/fftools/resources/Makefile
@@ -1,13 +1,35 @@
+RES_CLEANSUFFIXES = *.o *.css.min.c *.html.c *.d *.gz *.min
+
 clean::
-	$(RM) $(CLEANSUFFIXES:%=fftools/resources/%)
+	$(RM) $(RES_CLEANSUFFIXES:%=fftools/resources/%)
 
 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
+RESOURCEOBJS += fftools/resources/graph.css.min.o
+RESOURCEOBJS += fftools/resources/graph.html.o
 
 OBJS-resman +=                     \
     fftools/resources/resman.o     \
-    fftools/resources/graph.html.o \
-    fftools/resources/graph.css.o  \
+    $(RESOURCEOBJS)
+
+%.css.min: TAG = SED
+%.css.min: %.css
+	$(M)sed 's!/\\*.*\\*/!!g' $< \
+	| tr '\n' ' ' \
+	| tr -s ' ' \
+	| sed 's/^ //; s/ $$//' \
+	> $@
+
+ifdef CONFIG_RESOURCE_COMPRESSION
+RES_GZ = .gz
+endif
+
+$(RESOURCEOBJS:.o=.gz): TAG = GZIP
+$(RESOURCEOBJS:.o=.gz): %.gz: %
+	$(M)gzip -nc9 $< > $@
+
+$(RESOURCEOBJS:.o=.c): %.c: %$(RES_GZ) $(BIN2CEXE)
+	$(BIN2C) $< $@ $(subst .,_,$(basename $(notdir $@)))
+
+.SECONDARY: $(RESOURCEOBJS:.o=) $(RESOURCEOBJS:.o=.c) $(RESOURCEOBJS:.o=.gz)
diff --git a/fftools/resources/resman.c b/fftools/resources/resman.c
index a9e21626fa..6c131dd4e7 100644
--- a/fftools/resources/resman.c
+++ b/fftools/resources/resman.c
@@ -41,11 +41,11 @@
 extern const unsigned char ff_graph_html_data[];
 extern const unsigned int ff_graph_html_len;
 
-extern const unsigned char ff_graph_css_data[];
-extern const unsigned ff_graph_css_len;
+extern const unsigned char ff_graph_css_min_data[];
+extern const unsigned ff_graph_css_min_len;
 
 static const FFResourceDefinition resource_definitions[] = {
-    [FF_RESOURCE_GRAPH_CSS]   = { FF_RESOURCE_GRAPH_CSS,   "graph.css",   &ff_graph_css_data[0],   &ff_graph_css_len   },
+    [FF_RESOURCE_GRAPH_CSS]   = { FF_RESOURCE_GRAPH_CSS,   "graph.css",   &ff_graph_css_min_data[0], &ff_graph_css_min_len },
     [FF_RESOURCE_GRAPH_HTML]  = { FF_RESOURCE_GRAPH_HTML,  "graph.html",  &ff_graph_html_data[0],  &ff_graph_html_len  },
 };
 
-- 
2.39.5


[-- Attachment #3: Type: text/plain, Size: 251 bytes --]

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

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

Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move fftools/resources-specific code its Makefile

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> Sent: Dienstag, 27. Mai 2025 05:29
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move
> fftools/resources-specific code its Makefile
> 
> On Tue, May 27, 2025 at 4:11 AM softworkz .
> <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro
> Polla
> > > Sent: Dienstag, 27. Mai 2025 03:33
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move
> > > fftools/resources-specific code its Makefile
> > >
> > > - Intermediate files are no longer removed;
> >
> > Why? That's the way it's meant to work and it's working fine (will push
> tomorrow)
> 
> Deleting intermediate files prints an "rm" message at the end of the
> build. 

Yes, that's correct. That's how make behaves by default. I had set up
a minimal repro to verify.

It also deletes files that we might want to inspect later.

In 99.9% of cases - no.
For the remainder, there's a line in the Makefile to uncomment,
to make the files persists for debugging purposes.

Further, I'm afraid, I also do not agree with the moving around
of the make rules from common.mak. They are there for good reasons:


1. PTX compression is handled there. It makes a lot of sense to 
   bundle code of similar concern instead of spreading it all 
   over many files

2. It allows to have a uniform implementation for all the compression
   without any divergent code over different places

3. The rules in common.mak are intended to be re-usable. Same like
   ptx files could occur not only in avfilter but possibly also in 
   avcodec, the same is true for resources:
   It is very well possible that FFprobe might get similar resources
   for some graph visualization in a different folder.
   Also, the intention for the AVTextFormat API is that it can be
   used from the libs, e.g. formatted data output from a filter
   or visualized as a graph, in which case the filter would require 
   some css or also html resources. That's why the rules should
   remain in common.mak


> > > - A .res suffix has been added to resource files, so that there's no
> > >   need to add new rules for each new filetype;
> >
> > I don't want this. I want the editor to be aware of the file type when
> opening.
> 
> Fair enough. New patch attached.

Anyway, it wouldn't have made any sense, because .css files have a 
different build sequence than html files, which is why you were 
appending .res, but then had to still include the original extension 
for distinction (.css.res).

To be honest, I see no improvement in patches 4/5 and 5/5.
Haven't looked into the removed check.
Michael has some build where no zlib is available, so he'll probably 
let you know in case.

Just to clarify: 

- Static build
- No zlib available
- cli gzip is available

Will compression be used when compiling?

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/5] configure: improve gzip check

[Jacob Lifshay]

On Mon, May 26, 2025 at 6:34 PM Ramiro Polla <ramiro.polla@gmail.com> wrote:
> -[ -x "$(command -v gzip)" ] && enable gzip
> +gzip -V > /dev/null 2>&1 && enable gzip

idk if you intend it to build with busybox gzip, but busybox gzip
doesn't support the -V option, a better command could be something like:
gzip < /dev/null > /dev/null 2>&1 && enable gzip
since that does work with busybox too.

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

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

Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move fftools/resources-specific code its Makefile

[Ramiro Polla]

On Tue, May 27, 2025 at 6:02 AM softworkz .
<softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> > Sent: Dienstag, 27. Mai 2025 05:29
> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move
> > fftools/resources-specific code its Makefile
> >
> > On Tue, May 27, 2025 at 4:11 AM softworkz .
> > <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > > > -----Original Message-----
> > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro
> > Polla
> > > > Sent: Dienstag, 27. Mai 2025 03:33
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Subject: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move
> > > > fftools/resources-specific code its Makefile
> > > >
> > > > - Intermediate files are no longer removed;
> > >
> > > Why? That's the way it's meant to work and it's working fine (will push
> > tomorrow)
> >
> > Deleting intermediate files prints an "rm" message at the end of the
> > build.
>
> Yes, that's correct. That's how make behaves by default. I had set up
> a minimal repro to verify.

Being make's default behaviour doesn't mean that's how we want it to
behave. I don't like make silently deleting files. I also don't like
make loudly deleting files at the end of the build. I believe others
feel the same.

> It also deletes files that we might want to inspect later.
>
> In 99.9% of cases - no.
> For the remainder, there's a line in the Makefile to uncomment,
> to make the files persists for debugging purposes.

Very few people will know that line exists at all.

> Further, I'm afraid, I also do not agree with the moving around
> of the make rules from common.mak. They are there for good reasons:
>
>
> 1. PTX compression is handled there. It makes a lot of sense to
>    bundle code of similar concern instead of spreading it all
>    over many files

I left ptx out of this patchset, but it could be improved as well.
Also, ptx has one common suffix for many different files. Resources
could be anything.

There were 7 rules in common.mak to build 2 files that were specific
to fftools/resources. The rules could stay in common.mak if we come up
with a way to have 1 common rule for each action.

> 2. It allows to have a uniform implementation for all the compression
>    without any divergent code over different places
>
> 3. The rules in common.mak are intended to be re-usable. Same like
>    ptx files could occur not only in avfilter but possibly also in
>    avcodec, the same is true for resources:
>    It is very well possible that FFprobe might get similar resources
>    for some graph visualization in a different folder.
>    Also, the intention for the AVTextFormat API is that it can be
>    used from the libs, e.g. formatted data output from a filter
>    or visualized as a graph, in which case the filter would require
>    some css or also html resources. That's why the rules should
>    remain in common.mak

Resources are currently centralized in fftools/resources. New
resources would also need to be added to resman.c and resman.h.

How do you plan on adding new resources to different parts of FFmpeg,
like ffprobe or avfilter? How will files be laid out in the directory
structure, and how will they be included in the resource manager?
Having a clear plan will help us moving forward.

> > > > - A .res suffix has been added to resource files, so that there's no
> > > >   need to add new rules for each new filetype;
> > >
> > > I don't want this. I want the editor to be aware of the file type when
> > opening.
> >
> > Fair enough. New patch attached.
>
> Anyway, it wouldn't have made any sense, because .css files have a
> different build sequence than html files, which is why you were
> appending .res, but then had to still include the original extension
> for distinction (.css.res).
>
> To be honest, I see no improvement in patches 4/5 and 5/5.

Patch 5/5 removes files left over in fftools/{graph,textformat} when
"make clean" is called. This should be pretty uncontroversial.

> Haven't looked into the removed check.
> Michael has some build where no zlib is available, so he'll probably
> let you know in case.
>
> Just to clarify:
>
> - Static build
> - No zlib available
> - cli gzip is available
>
> Will compression be used when compiling?

No.


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

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

Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for gzip support in zlib

[Timo Rothenpieler]

On 27.05.2025 03:33, Ramiro Polla wrote:
> We currently test at build-time whether zlib supports decoding gzip.
> This is not needed for the build to succeed, since only the gzip
> command is necessary to perform compression at build-time.
> 
> Presumably this check will help the user by not enabling compression at
> build-time if their system won't be able to decompress at runtime.
> 
> But there are no guarantees that the system where the build is made is
> the same system where it will run. The build system could support gzip
> in zlib, but not the system at runtime, or the other way around.
> 
> Realistically, the chances of there being a system where zlib does not
> support gzip are very slim. It is safe to assume that zlib will support
> gzip.
> 
> This commit changes the dependency for support of compressed resources
> and ptx files to normal zlib support, and the existence of the gzip
> command.
> ---
>   configure | 13 ++-----------
>   1 file changed, 2 insertions(+), 11 deletions(-)
> 
> diff --git a/configure b/configure
> index 3730b0524c..79c4fcf327 100755
> --- a/configure
> +++ b/configure
> @@ -2548,7 +2548,6 @@ HAVE_LIST="
>       posix_ioctl
>       texi2html
>       xmllint
> -    zlib_gzip
>       openvino2
>   "
>   
> @@ -6895,19 +6894,11 @@ enabled  zlib && { check_pkg_config zlib zlib "zlib.h" zlibVersion ||
>   enabled bzlib && check_lib bzlib bzlib.h BZ2_bzlibVersion    -lbz2
>   enabled  lzma && check_lib lzma   lzma.h lzma_version_number -llzma
>   
> -enabled zlib && test_exec $zlib_extralibs <<EOF && enable zlib_gzip
> -#include <zlib.h>
> -int main(void) {
> -    if (zlibCompileFlags() & (1 << 17)) return 1;
> -    return 0;
> -}
> -EOF
> -
>   [ -x "$(command -v gzip)" ] && enable gzip
>   
> -enabled zlib_gzip && enabled gzip || disable ptx_compression
> +enabled zlib && enabled gzip || disable ptx_compression
>   
> -enabled zlib_gzip && enabled gzip || disable resource_compression
> +enabled zlib && enabled gzip || disable resource_compression
>   
>   # On some systems dynamic loading requires no extra linker flags
>   check_lib libdl dlfcn.h "dlopen dlsym" || check_lib libdl dlfcn.h "dlopen dlsym" -ldl

I don't see why this should be removed.
It does not hurt in any way, and can prevent bad surprises for people 
building in odd environments where zlib for some reason does not support 
this.

Chances are high that if the build env doesn't support it, neither will 
the intended runtime env.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 3/5] configure: improve gzip check

[Ramiro Polla]

Hi Jacob,

On Tue, May 27, 2025 at 8:55 AM Jacob Lifshay <programmerjake@gmail.com> wrote:
> On Mon, May 26, 2025 at 6:34 PM Ramiro Polla <ramiro.polla@gmail.com> wrote:
> > -[ -x "$(command -v gzip)" ] && enable gzip
> > +gzip -V > /dev/null 2>&1 && enable gzip
>
> idk if you intend it to build with busybox gzip, but busybox gzip
> doesn't support the -V option, a better command could be something like:
> gzip < /dev/null > /dev/null 2>&1 && enable gzip
> since that does work with busybox too.

Thanks. I hadn't thought about gzip implementations that don't support -V.

What about the following?
echo | gzip -c > /dev/null 2>&1 && enable gzip

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

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

Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for gzip support in zlib

[Ramiro Polla]

Hi Timo,

On Tue, May 27, 2025 at 3:19 PM Timo Rothenpieler <timo@rothenpieler.org> wrote:
> On 27.05.2025 03:33, Ramiro Polla wrote:
> > We currently test at build-time whether zlib supports decoding gzip.
> > This is not needed for the build to succeed, since only the gzip
> > command is necessary to perform compression at build-time.
> >
> > Presumably this check will help the user by not enabling compression at
> > build-time if their system won't be able to decompress at runtime.
> >
> > But there are no guarantees that the system where the build is made is
> > the same system where it will run. The build system could support gzip
> > in zlib, but not the system at runtime, or the other way around.
> >
> > Realistically, the chances of there being a system where zlib does not
> > support gzip are very slim. It is safe to assume that zlib will support
> > gzip.
> >
> > This commit changes the dependency for support of compressed resources
> > and ptx files to normal zlib support, and the existence of the gzip
> > command.
> > ---
> >   configure | 13 ++-----------
> >   1 file changed, 2 insertions(+), 11 deletions(-)
> >
> > diff --git a/configure b/configure
> > index 3730b0524c..79c4fcf327 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2548,7 +2548,6 @@ HAVE_LIST="
> >       posix_ioctl
> >       texi2html
> >       xmllint
> > -    zlib_gzip
> >       openvino2
> >   "
> >
> > @@ -6895,19 +6894,11 @@ enabled  zlib && { check_pkg_config zlib zlib "zlib.h" zlibVersion ||
> >   enabled bzlib && check_lib bzlib bzlib.h BZ2_bzlibVersion    -lbz2
> >   enabled  lzma && check_lib lzma   lzma.h lzma_version_number -llzma
> >
> > -enabled zlib && test_exec $zlib_extralibs <<EOF && enable zlib_gzip
> > -#include <zlib.h>
> > -int main(void) {
> > -    if (zlibCompileFlags() & (1 << 17)) return 1;
> > -    return 0;
> > -}
> > -EOF
> > -
> >   [ -x "$(command -v gzip)" ] && enable gzip
> >
> > -enabled zlib_gzip && enabled gzip || disable ptx_compression
> > +enabled zlib && enabled gzip || disable ptx_compression
> >
> > -enabled zlib_gzip && enabled gzip || disable resource_compression
> > +enabled zlib && enabled gzip || disable resource_compression
> >
> >   # On some systems dynamic loading requires no extra linker flags
> >   check_lib libdl dlfcn.h "dlopen dlsym" || check_lib libdl dlfcn.h "dlopen dlsym" -ldl
>
> I don't see why this should be removed.
> It does not hurt in any way, and can prevent bad surprises for people
> building in odd environments where zlib for some reason does not support
> this.
>
> Chances are high that if the build env doesn't support it, neither will
> the intended runtime env.

We don’t perform build-time runtime checks for any other functionality.

Are there any examples of systems where this has been a problem in practice?

Unless we can find any real world use case where this test makes a
difference, I don't see why we should keep it. In this case, less is
better.

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

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

Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move fftools/resources-specific code its Makefile

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Ramiro Polla
> Sent: Dienstag, 27. Mai 2025 14:36
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up
> and move fftools/resources-specific code its Makefile
> 
> On Tue, May 27, 2025 at 6:02 AM softworkz .
> <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Ramiro Polla
> > > Sent: Dienstag, 27. Mai 2025 05:29
> > > To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean
> up and move
> > > fftools/resources-specific code its Makefile
> > >
> > > On Tue, May 27, 2025 at 4:11 AM softworkz .
> > > <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > > > > -----Original Message-----
> > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
> Of Ramiro
> > > Polla
> > > > > Sent: Dienstag, 27. Mai 2025 03:33
> > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > Subject: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean
> up and move
> > > > > fftools/resources-specific code its Makefile
> > > > >
> > > > > - Intermediate files are no longer removed;
> > > >
> > > > Why? That's the way it's meant to work and it's working fine
> (will push
> > > tomorrow)
> > >
> > > Deleting intermediate files prints an "rm" message at the end of
> the
> > > build.
> >
> > Yes, that's correct. That's how make behaves by default. I had set
> up
> > a minimal repro to verify.
> 
> Being make's default behaviour doesn't mean that's how we want it to
> behave. I don't like make silently deleting files. 

It doesn't do it silently.


> I also don't like
> make loudly deleting files at the end of the build. I believe others
> feel the same.

Since when do we make decisions based on whether we like the log
output or not?
And how does it go together when you say you don't want it to happen
silently and you also say that you don't like when make informs you
about it?


> > It also deletes files that we might want to inspect later.
> >
> > In 99.9% of cases - no.
> > For the remainder, there's a line in the Makefile to uncomment,
> > to make the files persists for debugging purposes.
> 
> Very few people will know that line exists at all.

For those few who need to know it, their first action will be
to look at the Makefile, where it's right at the top.


> > Further, I'm afraid, I also do not agree with the moving around
> > of the make rules from common.mak. They are there for good reasons:
> >
> >
> > 1. PTX compression is handled there. It makes a lot of sense to
> >    bundle code of similar concern instead of spreading it all
> >    over many files
> 
> I left ptx out of this patchset, but it could be improved as well.
> Also, ptx has one common suffix for many different files. Resources
> could be anything.

Please discuss this with Timo, whether he would agree to moving
those pattern rules to the avfilter Makefile.
It doesn't make sense to do it differently for ptx and resource.


> > 2. It allows to have a uniform implementation for all the
> compression
> >    without any divergent code over different places
> >
> > 3. The rules in common.mak are intended to be re-usable. Same like
> >    ptx files could occur not only in avfilter but possibly also in
> >    avcodec, the same is true for resources:
> >    It is very well possible that FFprobe might get similar resources
> >    for some graph visualization in a different folder.
> >    Also, the intention for the AVTextFormat API is that it can be
> >    used from the libs, e.g. formatted data output from a filter
> >    or visualized as a graph, in which case the filter would require
> >    some css or also html resources. That's why the rules should
> >    remain in common.mak
> 
> Resources are currently centralized in fftools/resources. New
> resources would also need to be added to resman.c and resman.h.
> 
> How do you plan on adding new resources to different parts of FFmpeg,
> like ffprobe or avfilter? How will files be laid out in the directory
> structure, and how will they be included in the resource manager?
> Having a clear plan will help us moving forward.

I have more resources in my work branch which are for use by FFprobe
(so we're not talking about hypothetical cases here). There, all
resources go into both tools - which would probably be objected.

The answer is that there's no clear plan yet. Keeping the rules
in common.mak provides the flexibility that might be required, when
going forward.



> > > > > - A .res suffix has been added to resource files, so that
> there's no
> > > > >   need to add new rules for each new filetype;
> > > >
> > > > I don't want this. I want the editor to be aware of the file
> type when
> > > opening.
> > >
> > > Fair enough. New patch attached.
> >
> > Anyway, it wouldn't have made any sense, because .css files have a
> > different build sequence than html files, which is why you were
> > appending .res, but then had to still include the original extension
> > for distinction (.css.res).
> >
> > To be honest, I see no improvement in patches 4/5 and 5/5.
> 
> Patch 5/5 removes files left over in fftools/{graph,textformat} when
> "make clean" is called. This should be pretty uncontroversial.
> 
> > Haven't looked into the removed check.
> > Michael has some build where no zlib is available, so he'll probably
> > let you know in case.
> >
> > Just to clarify:
> >
> > - Static build
> > - No zlib available
> > - cli gzip is available
> >
> > Will compression be used when compiling?
> 
> No.

Okay, I have no objections to that change then, but I also do not
understand what the benefit would be in removing the check.

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/5] configure: improve gzip check

[Jacob Lifshay]

On May 27, 2025 9:12:47 AM PDT, Ramiro Polla <ramiro.polla@gmail.com> wrote:
> Hi Jacob,
> 
> Thanks. I hadn't thought about gzip implementations that don't support -V.
> 
> What about the following?
> echo | gzip -c > /dev/null 2>&1 && enable gzip

That should also work afaik. busybox does support -c.

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

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

Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move fftools/resources-specific code its Makefile

[Ramiro Polla]

On Tue, May 27, 2025 at 9:20 PM softworkz .
<softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Ramiro Polla
> > Sent: Dienstag, 27. Mai 2025 14:36
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up
> > and move fftools/resources-specific code its Makefile
> >
> > On Tue, May 27, 2025 at 6:02 AM softworkz .
> > <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > > > -----Original Message-----
> > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Ramiro Polla
> > > > Sent: Dienstag, 27. Mai 2025 05:29
> > > > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean
> > up and move
> > > > fftools/resources-specific code its Makefile
> > > >
> > > > On Tue, May 27, 2025 at 4:11 AM softworkz .
> > > > <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > > > > > -----Original Message-----
> > > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
> > Of Ramiro
> > > > Polla
> > > > > > Sent: Dienstag, 27. Mai 2025 03:33
> > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > Subject: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean
> > up and move
> > > > > > fftools/resources-specific code its Makefile
> > > > > >
> > > > > > - Intermediate files are no longer removed;
> > > > >
> > > > > Why? That's the way it's meant to work and it's working fine
> > (will push
> > > > tomorrow)
> > > >
> > > > Deleting intermediate files prints an "rm" message at the end of
> > the
> > > > build.
> > >
> > > Yes, that's correct. That's how make behaves by default. I had set
> > up
> > > a minimal repro to verify.
> >
> > Being make's default behaviour doesn't mean that's how we want it to
> > behave. I don't like make silently deleting files.
>
> It doesn't do it silently.
>
>
> > I also don't like
> > make loudly deleting files at the end of the build. I believe others
> > feel the same.
>
> Since when do we make decisions based on whether we like the log
> output or not?
> And how does it go together when you say you don't want it to happen
> silently and you also say that you don't like when make informs you
> about it?

I don't like make deleting files.

> > > Further, I'm afraid, I also do not agree with the moving around
> > > of the make rules from common.mak. They are there for good reasons:
> > >
> > >
> > > 1. PTX compression is handled there. It makes a lot of sense to
> > >    bundle code of similar concern instead of spreading it all
> > >    over many files
> >
> > I left ptx out of this patchset, but it could be improved as well.
> > Also, ptx has one common suffix for many different files. Resources
> > could be anything.
>
> Please discuss this with Timo, whether he would agree to moving
> those pattern rules to the avfilter Makefile.
> It doesn't make sense to do it differently for ptx and resource.

Oh, I don't plan on moving the ptx file rules out of common.mak. Like
I said, there is one common suffix for many different files.

It can be improved by deduplicating rules though.

> > > 2. It allows to have a uniform implementation for all the
> > compression
> > >    without any divergent code over different places
> > >
> > > 3. The rules in common.mak are intended to be re-usable. Same like
> > >    ptx files could occur not only in avfilter but possibly also in
> > >    avcodec, the same is true for resources:
> > >    It is very well possible that FFprobe might get similar resources
> > >    for some graph visualization in a different folder.
> > >    Also, the intention for the AVTextFormat API is that it can be
> > >    used from the libs, e.g. formatted data output from a filter
> > >    or visualized as a graph, in which case the filter would require
> > >    some css or also html resources. That's why the rules should
> > >    remain in common.mak
> >
> > Resources are currently centralized in fftools/resources. New
> > resources would also need to be added to resman.c and resman.h.
> >
> > How do you plan on adding new resources to different parts of FFmpeg,
> > like ffprobe or avfilter? How will files be laid out in the directory
> > structure, and how will they be included in the resource manager?
> > Having a clear plan will help us moving forward.
>
> I have more resources in my work branch which are for use by FFprobe
> (so we're not talking about hypothetical cases here). There, all
> resources go into both tools - which would probably be objected.
>
> The answer is that there's no clear plan yet. Keeping the rules
> in common.mak provides the flexibility that might be required, when
> going forward.

Ok, I'll move it back to common.mak. But as long as it's one rule per
action, and not multiple per file type.

Please come up with a plan on how to add resource files from different
places in the codebase, and how to include them in the resource
manager. Because currently it's not very flexible.

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

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

Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move fftools/resources-specific code its Makefile

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Ramiro Polla
> Sent: Dienstag, 27. Mai 2025 21:59
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up
> and move fftools/resources-specific code its Makefile
> 
> On Tue, May 27, 2025 at 9:20 PM softworkz .
> <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > Ramiro Polla
> > > Sent: Dienstag, 27. Mai 2025 14:36
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean
> up
> > > and move fftools/resources-specific code its Makefile
> > >
> > > On Tue, May 27, 2025 at 6:02 AM softworkz .
> > > <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > > > > -----Original Message-----
> > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
> Of
> > > Ramiro Polla
> > > > > Sent: Dienstag, 27. Mai 2025 05:29
> > > > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel@ffmpeg.org>
> > > > > Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak:
> clean
> > > up and move
> > > > > fftools/resources-specific code its Makefile
> > > > >
> > > > > On Tue, May 27, 2025 at 4:11 AM softworkz .
> > > > > <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > > > > > > -----Original Message-----
> > > > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On
> Behalf
> > > Of Ramiro
> > > > > Polla
> > > > > > > Sent: Dienstag, 27. Mai 2025 03:33
> > > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > > Subject: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak:
> clean
> > > up and move
> > > > > > > fftools/resources-specific code its Makefile
> > > > > > >
> > > > > > > - Intermediate files are no longer removed;
> > > > > >
> > > > > > Why? That's the way it's meant to work and it's working fine
> > > (will push
> > > > > tomorrow)
> > > > >
> > > > > Deleting intermediate files prints an "rm" message at the end
> of
> > > the
> > > > > build.
> > > >
> > > > Yes, that's correct. That's how make behaves by default. I had
> set
> > > up
> > > > a minimal repro to verify.
> > >
> > > Being make's default behaviour doesn't mean that's how we want it
> to
> > > behave. I don't like make silently deleting files.
> >
> > It doesn't do it silently.
> >
> >
> > > I also don't like
> > > make loudly deleting files at the end of the build. I believe
> others
> > > feel the same.
> >
> > Since when do we make decisions based on whether we like the log
> > output or not?
> > And how does it go together when you say you don't want it to happen
> > silently and you also say that you don't like when make informs you
> > about it?
> 
> I don't like make deleting files.
> 
> > > > Further, I'm afraid, I also do not agree with the moving around
> > > > of the make rules from common.mak. They are there for good
> reasons:
> > > >
> > > >
> > > > 1. PTX compression is handled there. It makes a lot of sense to
> > > >    bundle code of similar concern instead of spreading it all
> > > >    over many files
> > >
> > > I left ptx out of this patchset, but it could be improved as well.
> > > Also, ptx has one common suffix for many different files.
> Resources
> > > could be anything.
> >
> > Please discuss this with Timo, whether he would agree to moving
> > those pattern rules to the avfilter Makefile.
> > It doesn't make sense to do it differently for ptx and resource.
> 
> Oh, I don't plan on moving the ptx file rules out of common.mak. Like
> I said, there is one common suffix for many different files.
> 
> It can be improved by deduplicating rules though.
> 
> > > > 2. It allows to have a uniform implementation for all the
> > > compression
> > > >    without any divergent code over different places
> > > >
> > > > 3. The rules in common.mak are intended to be re-usable. Same
> like
> > > >    ptx files could occur not only in avfilter but possibly also
> in
> > > >    avcodec, the same is true for resources:
> > > >    It is very well possible that FFprobe might get similar
> resources
> > > >    for some graph visualization in a different folder.
> > > >    Also, the intention for the AVTextFormat API is that it can
> be
> > > >    used from the libs, e.g. formatted data output from a filter
> > > >    or visualized as a graph, in which case the filter would
> require
> > > >    some css or also html resources. That's why the rules should
> > > >    remain in common.mak
> > >
> > > Resources are currently centralized in fftools/resources. New
> > > resources would also need to be added to resman.c and resman.h.
> > >
> > > How do you plan on adding new resources to different parts of
> FFmpeg,
> > > like ffprobe or avfilter? How will files be laid out in the
> directory
> > > structure, and how will they be included in the resource manager?
> > > Having a clear plan will help us moving forward.
> >
> > I have more resources in my work branch which are for use by FFprobe
> > (so we're not talking about hypothetical cases here). There, all
> > resources go into both tools - which would probably be objected.
> >
> > The answer is that there's no clear plan yet. Keeping the rules
> > in common.mak provides the flexibility that might be required, when
> > going forward.
> 
> Ok, I'll move it back to common.mak. But as long as it's one rule per
> action, and not multiple per file type.
> 
> Please come up with a plan on how to add resource files from different
> places in the codebase, and how to include them in the resource
> manager. Because currently it's not very flexible.

Sure I will, but first of all, we need to get the way of building
intermediates settled. I'm considering the way you are proposing 
(keeping intermediates) as inferior and against the intended behavior
of make. What's been there before, has only been a workaround to avoid
rebuilds triggered by dependency generation.
In turn, I do not agree to turn back to that ugly and more complicated
workaround, now that the original problem (which led to that workaround)
has been identified and solved.

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up and move fftools/resources-specific code its Makefile

[Ramiro Polla]

On Tue, May 27, 2025 at 10:13 PM softworkz .
<softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > Ramiro Polla
> > Sent: Dienstag, 27. Mai 2025 21:59
> > To: FFmpeg development discussions and patches <ffmpeg-
> > devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up
> > and move fftools/resources-specific code its Makefile
> >
> > On Tue, May 27, 2025 at 9:20 PM softworkz .
> > <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > > > -----Original Message-----
> > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> > > > Ramiro Polla
> > > > Sent: Dienstag, 27. Mai 2025 14:36
> > > > To: FFmpeg development discussions and patches <ffmpeg-
> > > > devel@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean
> > up
> > > > and move fftools/resources-specific code its Makefile
> > > >
> > > > On Tue, May 27, 2025 at 6:02 AM softworkz .
> > > > <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > > > > > -----Original Message-----
> > > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf
> > Of
> > > > Ramiro Polla
> > > > > > Sent: Dienstag, 27. Mai 2025 05:29
> > > > > > To: FFmpeg development discussions and patches <ffmpeg-
> > > > devel@ffmpeg.org>
> > > > > > Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak:
> > clean
> > > > up and move
> > > > > > fftools/resources-specific code its Makefile
> > > > > >
> > > > > > On Tue, May 27, 2025 at 4:11 AM softworkz .
> > > > > > <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > > > > > > > -----Original Message-----
> > > > > > > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On
> > Behalf
> > > > Of Ramiro
> > > > > > Polla
> > > > > > > > Sent: Dienstag, 27. Mai 2025 03:33
> > > > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > > > Subject: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak:
> > clean
> > > > up and move
> > > > > > > > fftools/resources-specific code its Makefile
> > > > > > > >
> > > > > > > > - Intermediate files are no longer removed;
> > > > > > >
> > > > > > > Why? That's the way it's meant to work and it's working fine
> > > > (will push
> > > > > > tomorrow)
> > > > > >
> > > > > > Deleting intermediate files prints an "rm" message at the end
> > of
> > > > the
> > > > > > build.
> > > > >
> > > > > Yes, that's correct. That's how make behaves by default. I had
> > set
> > > > up
> > > > > a minimal repro to verify.
> > > >
> > > > Being make's default behaviour doesn't mean that's how we want it
> > to
> > > > behave. I don't like make silently deleting files.
> > >
> > > It doesn't do it silently.
> > >
> > >
> > > > I also don't like
> > > > make loudly deleting files at the end of the build. I believe
> > others
> > > > feel the same.
> > >
> > > Since when do we make decisions based on whether we like the log
> > > output or not?
> > > And how does it go together when you say you don't want it to happen
> > > silently and you also say that you don't like when make informs you
> > > about it?
> >
> > I don't like make deleting files.
> >
> > > > > Further, I'm afraid, I also do not agree with the moving around
> > > > > of the make rules from common.mak. They are there for good
> > reasons:
> > > > >
> > > > >
> > > > > 1. PTX compression is handled there. It makes a lot of sense to
> > > > >    bundle code of similar concern instead of spreading it all
> > > > >    over many files
> > > >
> > > > I left ptx out of this patchset, but it could be improved as well.
> > > > Also, ptx has one common suffix for many different files.
> > Resources
> > > > could be anything.
> > >
> > > Please discuss this with Timo, whether he would agree to moving
> > > those pattern rules to the avfilter Makefile.
> > > It doesn't make sense to do it differently for ptx and resource.
> >
> > Oh, I don't plan on moving the ptx file rules out of common.mak. Like
> > I said, there is one common suffix for many different files.
> >
> > It can be improved by deduplicating rules though.
> >
> > > > > 2. It allows to have a uniform implementation for all the
> > > > compression
> > > > >    without any divergent code over different places
> > > > >
> > > > > 3. The rules in common.mak are intended to be re-usable. Same
> > like
> > > > >    ptx files could occur not only in avfilter but possibly also
> > in
> > > > >    avcodec, the same is true for resources:
> > > > >    It is very well possible that FFprobe might get similar
> > resources
> > > > >    for some graph visualization in a different folder.
> > > > >    Also, the intention for the AVTextFormat API is that it can
> > be
> > > > >    used from the libs, e.g. formatted data output from a filter
> > > > >    or visualized as a graph, in which case the filter would
> > require
> > > > >    some css or also html resources. That's why the rules should
> > > > >    remain in common.mak
> > > >
> > > > Resources are currently centralized in fftools/resources. New
> > > > resources would also need to be added to resman.c and resman.h.
> > > >
> > > > How do you plan on adding new resources to different parts of
> > FFmpeg,
> > > > like ffprobe or avfilter? How will files be laid out in the
> > directory
> > > > structure, and how will they be included in the resource manager?
> > > > Having a clear plan will help us moving forward.
> > >
> > > I have more resources in my work branch which are for use by FFprobe
> > > (so we're not talking about hypothetical cases here). There, all
> > > resources go into both tools - which would probably be objected.
> > >
> > > The answer is that there's no clear plan yet. Keeping the rules
> > > in common.mak provides the flexibility that might be required, when
> > > going forward.
> >
> > Ok, I'll move it back to common.mak. But as long as it's one rule per
> > action, and not multiple per file type.
> >
> > Please come up with a plan on how to add resource files from different
> > places in the codebase, and how to include them in the resource
> > manager. Because currently it's not very flexible.
>
> Sure I will, but first of all, we need to get the way of building
> intermediates settled. I'm considering the way you are proposing
> (keeping intermediates) as inferior and against the intended behavior
> of make. What's been there before, has only been a workaround to avoid
> rebuilds triggered by dependency generation.
> In turn, I do not agree to turn back to that ugly and more complicated
> workaround, now that the original problem (which led to that workaround)
> has been identified and solved.

I've split the patchset in two parts and sent a new revision for the
resource manager part.

I don't like intermediate files but I left it like that for now to try
and get this merged more quickly.

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

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

Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for gzip support in zlib

[Ramiro Polla]

Hi Timo,

On Tue, May 27, 2025 at 7:55 PM Ramiro Polla <ramiro.polla@gmail.com> wrote:
> On Tue, May 27, 2025 at 3:19 PM Timo Rothenpieler <timo@rothenpieler.org> wrote:
> > On 27.05.2025 03:33, Ramiro Polla wrote:
> > > We currently test at build-time whether zlib supports decoding gzip.
> > > This is not needed for the build to succeed, since only the gzip
> > > command is necessary to perform compression at build-time.
> > >
> > > Presumably this check will help the user by not enabling compression at
> > > build-time if their system won't be able to decompress at runtime.
> > >
> > > But there are no guarantees that the system where the build is made is
> > > the same system where it will run. The build system could support gzip
> > > in zlib, but not the system at runtime, or the other way around.
> > >
> > > Realistically, the chances of there being a system where zlib does not
> > > support gzip are very slim. It is safe to assume that zlib will support
> > > gzip.
> > >
> > > This commit changes the dependency for support of compressed resources
> > > and ptx files to normal zlib support, and the existence of the gzip
> > > command.
> > > ---
> > >   configure | 13 ++-----------
> > >   1 file changed, 2 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/configure b/configure
> > > index 3730b0524c..79c4fcf327 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -2548,7 +2548,6 @@ HAVE_LIST="
> > >       posix_ioctl
> > >       texi2html
> > >       xmllint
> > > -    zlib_gzip
> > >       openvino2
> > >   "
> > >
> > > @@ -6895,19 +6894,11 @@ enabled  zlib && { check_pkg_config zlib zlib "zlib.h" zlibVersion ||
> > >   enabled bzlib && check_lib bzlib bzlib.h BZ2_bzlibVersion    -lbz2
> > >   enabled  lzma && check_lib lzma   lzma.h lzma_version_number -llzma
> > >
> > > -enabled zlib && test_exec $zlib_extralibs <<EOF && enable zlib_gzip
> > > -#include <zlib.h>
> > > -int main(void) {
> > > -    if (zlibCompileFlags() & (1 << 17)) return 1;
> > > -    return 0;
> > > -}
> > > -EOF
> > > -
> > >   [ -x "$(command -v gzip)" ] && enable gzip
> > >
> > > -enabled zlib_gzip && enabled gzip || disable ptx_compression
> > > +enabled zlib && enabled gzip || disable ptx_compression
> > >
> > > -enabled zlib_gzip && enabled gzip || disable resource_compression
> > > +enabled zlib && enabled gzip || disable resource_compression
> > >
> > >   # On some systems dynamic loading requires no extra linker flags
> > >   check_lib libdl dlfcn.h "dlopen dlsym" || check_lib libdl dlfcn.h "dlopen dlsym" -ldl
> >
> > I don't see why this should be removed.
> > It does not hurt in any way, and can prevent bad surprises for people
> > building in odd environments where zlib for some reason does not support
> > this.
> >
> > Chances are high that if the build env doesn't support it, neither will
> > the intended runtime env.
>
> We don’t perform build-time runtime checks for any other functionality.
>
> Are there any examples of systems where this has been a problem in practice?
>
> Unless we can find any real world use case where this test makes a
> difference, I don't see why we should keep it. In this case, less is
> better.

I'll postpone this part of the patchset (patches 1 to 3) for a while
to give more time for people to comment. If anybody can find a system
where zlib doesn't support gzip, please let us know.

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

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

Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for gzip support in zlib

[Jacob Lifshay]

On May 30, 2025 4:10:45 AM PDT, Ramiro Polla <ramiro.polla@gmail.com> wrote:
> I'll postpone this part of the patchset (patches 1 to 3) for a while
> to give more time for people to comment. If anybody can find a system
> where zlib doesn't support gzip, please let us know.

idk if anyone is using it as the system zlib, but zlib-rs supports zlib's c api but doesn't come with a gzip executable. https://github.com/trifectatechfoundation/zlib-rs/blob/7fafed0d3ed7990349f5863dfba755cbac9ca543/README.md#c-projects

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

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

Re: [FFmpeg-devel] [PATCH 5/5] fftools/Makefile: clean files from fftools/{graph, textformat}/

[Ramiro Polla]

On Tue, May 27, 2025 at 3:33 AM Ramiro Polla <ramiro.polla@gmail.com> wrote:
>
> ---
>  fftools/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fftools/Makefile b/fftools/Makefile
> index c1eba733da..b3c08ae5a0 100644
> --- a/fftools/Makefile
> +++ b/fftools/Makefile
> @@ -92,4 +92,4 @@ uninstall-progs:
>         $(RM) $(addprefix "$(BINDIR)/", $(ALLAVPROGS))
>
>  clean::
> -       $(RM) $(ALLAVPROGS) $(ALLAVPROGS_G) $(CLEANSUFFIXES:%=fftools/%)
> +       $(RM) $(ALLAVPROGS) $(ALLAVPROGS_G) $(CLEANSUFFIXES:%=fftools/%) $(CLEANSUFFIXES:%=fftools/graph/%) $(CLEANSUFFIXES:%=fftools/textformat/%)
> --
> 2.39.5

I'll apply this patch tomorrow.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 5/5] fftools/Makefile: clean files from fftools/{graph, textformat}/

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> Sent: Sonntag, 1. Juni 2025 23:31
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 5/5] fftools/Makefile: clean files from
> fftools/{graph, textformat}/
> 
> On Tue, May 27, 2025 at 3:33 AM Ramiro Polla <ramiro.polla@gmail.com> wrote:
> >
> > ---
> >  fftools/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/fftools/Makefile b/fftools/Makefile
> > index c1eba733da..b3c08ae5a0 100644
> > --- a/fftools/Makefile
> > +++ b/fftools/Makefile
> > @@ -92,4 +92,4 @@ uninstall-progs:
> >         $(RM) $(addprefix "$(BINDIR)/", $(ALLAVPROGS))
> >
> >  clean::
> > -       $(RM) $(ALLAVPROGS) $(ALLAVPROGS_G) $(CLEANSUFFIXES:%=fftools/%)
> > +       $(RM) $(ALLAVPROGS) $(ALLAVPROGS_G) $(CLEANSUFFIXES:%=fftools/%)
> $(CLEANSUFFIXES:%=fftools/graph/%) $(CLEANSUFFIXES:%=fftools/textformat/%)
> > --
> > 2.39.5
> 
> I'll apply this patch tomorrow.

Do you mean this one or the whole series?

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/5] fftools/Makefile: clean files from fftools/{graph, textformat}/

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of softworkz .
> Sent: Sonntag, 1. Juni 2025 23:46
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 5/5] fftools/Makefile: clean files from
> fftools/{graph, textformat}/
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro
> Polla
> > Sent: Sonntag, 1. Juni 2025 23:31
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH 5/5] fftools/Makefile: clean files from
> > fftools/{graph, textformat}/
> >
> > On Tue, May 27, 2025 at 3:33 AM Ramiro Polla <ramiro.polla@gmail.com> wrote:
> > >
> > > ---
> > >  fftools/Makefile | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/fftools/Makefile b/fftools/Makefile
> > > index c1eba733da..b3c08ae5a0 100644
> > > --- a/fftools/Makefile
> > > +++ b/fftools/Makefile
> > > @@ -92,4 +92,4 @@ uninstall-progs:
> > >         $(RM) $(addprefix "$(BINDIR)/", $(ALLAVPROGS))
> > >
> > >  clean::
> > > -       $(RM) $(ALLAVPROGS) $(ALLAVPROGS_G) $(CLEANSUFFIXES:%=fftools/%)
> > > +       $(RM) $(ALLAVPROGS) $(ALLAVPROGS_G) $(CLEANSUFFIXES:%=fftools/%)
> > $(CLEANSUFFIXES:%=fftools/graph/%) $(CLEANSUFFIXES:%=fftools/textformat/%)
> > > --
> > > 2.39.5
> >
> > I'll apply this patch tomorrow.
> 
> Do you mean this one or the whole series?
> 
> Thanks
> sw
> _______________________________________________

I have nothing against 1,2,3 and 5. For 4, you've sent a new one
anyway - just wanted to be sure I didn't misunderstand.

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for gzip support in zlib

[Ramiro Polla]

Hi Jacob,

On Fri, May 30, 2025 at 8:19 PM Jacob Lifshay <programmerjake@gmail.com> wrote:
> On May 30, 2025 4:10:45 AM PDT, Ramiro Polla <ramiro.polla@gmail.com> wrote:
> > I'll postpone this part of the patchset (patches 1 to 3) for a while
> > to give more time for people to comment. If anybody can find a system
> > where zlib doesn't support gzip, please let us know.
>
> idk if anyone is using it as the system zlib, but zlib-rs supports zlib's c api but doesn't come with a gzip executable. https://github.com/trifectatechfoundation/zlib-rs/blob/7fafed0d3ed7990349f5863dfba755cbac9ca543/README.md#c-projects

Thank you for sharing this.

The issue we're looking for is not whether a gzip executable exists,
but whether the zlib API supports decoding gzip files or only raw
deflate streams.

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

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

Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for gzip support in zlib

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> Sent: Dienstag, 3. Juni 2025 01:22
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for
> gzip support in zlib
> 
> Hi Jacob,
> 
> On Fri, May 30, 2025 at 8:19 PM Jacob Lifshay <programmerjake@gmail.com>
> wrote:
> > On May 30, 2025 4:10:45 AM PDT, Ramiro Polla <ramiro.polla@gmail.com> wrote:
> > > I'll postpone this part of the patchset (patches 1 to 3) for a while
> > > to give more time for people to comment. If anybody can find a system
> > > where zlib doesn't support gzip, please let us know.
> >
> > idk if anyone is using it as the system zlib, but zlib-rs supports zlib's c
> api but doesn't come with a gzip executable.
> https://github.com/trifectatechfoundation/zlib-
> rs/blob/7fafed0d3ed7990349f5863dfba755cbac9ca543/README.md#c-projects
> 
> Thank you for sharing this.
> 
> The issue we're looking for is not whether a gzip executable exists,
> but whether the zlib API supports decoding gzip files or only raw
> deflate streams.
> 
> Ramiro
> _______________________________________________

Hi Ramiro,

with Andreas' new patchset, this question becomes obsoleted.
I'm no sure whether you've seen it?

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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for gzip support in zlib

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of softworkz .
> Sent: Dienstag, 3. Juni 2025 01:26
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for
> gzip support in zlib
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro
> Polla
> > Sent: Dienstag, 3. Juni 2025 01:22
> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check
> for
> > gzip support in zlib
> >
> > Hi Jacob,
> >
> > On Fri, May 30, 2025 at 8:19 PM Jacob Lifshay <programmerjake@gmail.com>
> > wrote:
> > > On May 30, 2025 4:10:45 AM PDT, Ramiro Polla <ramiro.polla@gmail.com>
> wrote:
> > > > I'll postpone this part of the patchset (patches 1 to 3) for a while
> > > > to give more time for people to comment. If anybody can find a system
> > > > where zlib doesn't support gzip, please let us know.
> > >
> > > idk if anyone is using it as the system zlib, but zlib-rs supports zlib's
> c
> > api but doesn't come with a gzip executable.
> > https://github.com/trifectatechfoundation/zlib-
> > rs/blob/7fafed0d3ed7990349f5863dfba755cbac9ca543/README.md#c-projects
> >
> > Thank you for sharing this.
> >
> > The issue we're looking for is not whether a gzip executable exists,
> > but whether the zlib API supports decoding gzip files or only raw
> > deflate streams.
> >
> > Ramiro
> > _______________________________________________
> 
> Hi Ramiro,
> 
> with Andreas' new patchset, this question becomes obsoleted.

Same do both of our patchsets, so we can close this case 
peacefully 😊

Best regards
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-request@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for gzip support in zlib

[Ramiro Polla]

On Tue, Jun 3, 2025 at 1:26 AM softworkz .
<softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> > Sent: Dienstag, 3. Juni 2025 01:22
> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for
> > gzip support in zlib
> >
> > Hi Jacob,
> >
> > On Fri, May 30, 2025 at 8:19 PM Jacob Lifshay <programmerjake@gmail.com>
> > wrote:
> > > On May 30, 2025 4:10:45 AM PDT, Ramiro Polla <ramiro.polla@gmail.com> wrote:
> > > > I'll postpone this part of the patchset (patches 1 to 3) for a while
> > > > to give more time for people to comment. If anybody can find a system
> > > > where zlib doesn't support gzip, please let us know.
> > >
> > > idk if anyone is using it as the system zlib, but zlib-rs supports zlib's c
> > api but doesn't come with a gzip executable.
> > https://github.com/trifectatechfoundation/zlib-
> > rs/blob/7fafed0d3ed7990349f5863dfba755cbac9ca543/README.md#c-projects
> >
> > Thank you for sharing this.
> >
> > The issue we're looking for is not whether a gzip executable exists,
> > but whether the zlib API supports decoding gzip files or only raw
> > deflate streams.
>
> with Andreas' new patchset, this question becomes obsoleted.
> I'm no sure whether you've seen it?

Yes, I've seen his patchset. I really liked his solution! We still
need to figure out how to properly find zlib using the host
pkg-config, something we currently don't have in configure. This could
be a bit tricky, especially regarding pkg-config's environment
variables.

But I guess you're right, with his approach, this test_exec check will
end up being removed as well.

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

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

Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for gzip support in zlib

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro Polla
> Sent: Dienstag, 3. Juni 2025 02:19
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check for
> gzip support in zlib
> 
> On Tue, Jun 3, 2025 at 1:26 AM softworkz .
> <softworkz-at-hotmail.com@ffmpeg.org> wrote:
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Ramiro
> Polla
> > > Sent: Dienstag, 3. Juni 2025 01:22
> > > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH 1/5] configure: remove build-time check
> for
> > > gzip support in zlib
> > >
> > > Hi Jacob,
> > >
> > > On Fri, May 30, 2025 at 8:19 PM Jacob Lifshay <programmerjake@gmail.com>
> > > wrote:
> > > > On May 30, 2025 4:10:45 AM PDT, Ramiro Polla <ramiro.polla@gmail.com>
> wrote:
> > > > > I'll postpone this part of the patchset (patches 1 to 3) for a while
> > > > > to give more time for people to comment. If anybody can find a system
> > > > > where zlib doesn't support gzip, please let us know.
> > > >
> > > > idk if anyone is using it as the system zlib, but zlib-rs supports
> zlib's c
> > > api but doesn't come with a gzip executable.
> > > https://github.com/trifectatechfoundation/zlib-
> > > rs/blob/7fafed0d3ed7990349f5863dfba755cbac9ca543/README.md#c-projects
> > >
> > > Thank you for sharing this.
> > >
> > > The issue we're looking for is not whether a gzip executable exists,
> > > but whether the zlib API supports decoding gzip files or only raw
> > > deflate streams.
> >
> > with Andreas' new patchset, this question becomes obsoleted.
> > I'm no sure whether you've seen it?
> 
> Yes, I've seen his patchset. I really liked his solution! 

Yea, me too. Even though we both did some unnecessary work now,
this way clearly wins.


> We still
> need to figure out how to properly find zlib using the host
> pkg-config, something we currently don't have in configure. This could
> be a bit tricky, especially regarding pkg-config's environment
> variables.

I don't know much in that area, I thought you might be able to
help with this.

> But I guess you're right, with his approach, this test_exec check will
> end up being removed as well.

It's for the better, even though it came a bit as a surprise 😊

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-request@ffmpeg.org with subject "unsubscribe".