Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: "softworkz ." <softworkz-at-hotmail.com@ffmpeg.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH WIP 01/10] ffbuild/bin2c: Use zlib directly instead of gzip
Date: Tue, 17 Jun 2025 13:23:30 +0000
Message-ID: <DM8P223MB036551B41B597C67CCC41C5CBA73A@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <aFE1lDZkziDdrWZ7@phare.normalesup.org>



> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Nicolas George
> Sent: Tuesday, June 17, 2025 11:30 AM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH WIP 01/10] ffbuild/bin2c: Use zlib
> directly instead of gzip
> 
> softworkz . (HE12025-06-16):
> > But why that? If we include the decompression code (that's why I've
> > been searching for the most compact implementations available with
> > compatible licenses), then we won't have any zlib dependency anymore -
> > neither at build- nor at run-time.
> 
> Wait. What you want to do is not offer the option to link with a different
> implementation of decompression feature but import the code of a certain
> library into our source tree?
> 
> We do not do that.
> 
> If somebody would write an implementation of zlib specifically for ffmpeg,
> using av_malloc() and av_log() and all our utility API, and if that
> implementation had some kind of benefit over any existing implementation,
> then we would be happy to adopt it.

It's not about replacing zlib in general. The scope is having our own compression
code for ptx and resource compression only. I gave a number of examples for 
how this could possibly be achieved with a small amount of code - which of 
course would need to be adapted to match our style and procedures.

The compression side would be in bin2c and only the decompression code
would ship (e.g. in avutil). Only if that part would be really small, the benefits
would weigh out the size added by the decomp code.

As long as we don't know the compression ratios achievable with such low-code
compression routines, this is merely an idea which might not work out at all
but at least worth exploring IMO.

Anyway, I'm not surprised. Making wrong assumptions and then ranting about,
is one of your most typical patterns.

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

  reply	other threads:[~2025-06-17 13:23 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-02  2:38 Andreas Rheinhardt
2025-06-02  3:22 ` softworkz .
2025-06-02 22:33 ` softworkz .
2025-06-03 14:33   ` Andreas Rheinhardt
2025-06-03 14:47     ` softworkz .
2025-06-11  3:05     ` softworkz .
2025-06-16 18:51       ` Andreas Rheinhardt
2025-06-16 19:15         ` softworkz .
2025-06-16 19:24           ` Andreas Rheinhardt
2025-06-16 20:18             ` softworkz .
2025-06-16 22:15               ` Andreas Rheinhardt
2025-06-17  9:29               ` Nicolas George
2025-06-17 13:23                 ` softworkz . [this message]
2025-06-17 14:09                   ` Nicolas George
2025-06-17 14:35                     ` softworkz .
2025-06-17 14:40                       ` Nicolas George
2025-06-17 14:41               ` James Almer
2025-06-17 14:51                 ` softworkz .
2025-06-18  7:09                 ` Nicolas George

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM8P223MB036551B41B597C67CCC41C5CBA73A@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM \
    --to=softworkz-at-hotmail.com@ffmpeg.org \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git