search

AOMediaCodec / libavif

libavif - Library for encoding and decoding .avif files
Other
1.57k stars 202 forks source link

Switch to zlib-ng for performance & newer libpng compatibility #2496

Open gitoss opened 5 days ago

gitoss commented 5 days ago

Since I seem to depend on the built-in libs with Visual Studio (I cannot get previously build libs to link with libavif due to some obscure "linking module flags: IDs have conflicting values" error:

A switch from old school zlib to zlib ng would enhance png performance, plus (probably) allow for libpng versions >1.6.40 (1.7 is is beta...). It's supposed a drop-in replacement with -DZLIB_COMPAT=ON

https://github.com/zlib-ng/zlib-ng https://github.com/AOMediaCodec/libavif/blob/main/cmake/Modules/LocalZlibpng.cmake

wantehchang commented 5 days ago

I also considered zlib alternatives before because zlib's CMakeLists.txt did not support Windows well and the patch I sent to the zlib maintainer (both by email and as a pull request) was not reviewed. Another zlib fork worth considering is Chrome's zlib fork: https://chromium.googlesource.com/chromium/src/third_party/zlib

gitoss commented 5 days ago

Another zlib fork worth considering is Chrome's zlib fork: https://chromium.googlesource.com/chromium/src/third_party/zlib

Interesting, I didn't know that.

zlib-ng looks appealing because of the SIMD code, but it might still be more hassle to configure even with the documentation provided. The chrome zlib looks simple, because there is no documenation (on the git site) at all :->

It probably doesn't matter that much unless encoding or decoding very big png files with high compression ... but it might still happen, I'm exporting Lightroom => PNG => avif/heic because PNG "just works".

Alas, being stuck with the old libpng doesn't look appealing at all... https://github.com/madler/zlib/issues/1019

wantehchang commented 4 days ago

@gitoss I'd like to know why you are interested in zlib alternatives. From your earlier comment, I think the reasons are:

  1. Better performance
  2. Upgrade to libpng > v1.6.40

Is this correct?

Regarding the second reason, I am wondering how libpng 1.6.41-1.6.44 could be released without a zlib release containing https://github.com/madler/zlib/commit/f1f503da85d52e56aae11557b4d79a42bcaa2b86.

The only reason I considered zlib alternatives was to fix a Windows build issue (https://github.com/madler/zlib/pull/818). We are working around that Windows build issue in our LocalZlibpng.cmake file. Note: I think that issue has been fixed on the zlib main branch in another way, based on the two target_include_directories() calls shown in https://github.com/madler/zlib/commit/f1f503da85d52e56aae11557b4d79a42bcaa2b86. It seems that I can abandon https://github.com/madler/zlib/pull/818 and write a new pull request to remove the two include_directories() calls.

gitoss commented 2 days ago
  1. Better performance
  2. Upgrade to libpng > v1.6.40

Yes, that is correct. The libpng issue probably will get solved sooner or later, but with bulk image encoding every bit of more performance helps - so why not use what's for 'free' by switching libs or optimizing compiler flags.

I've even compiled pgo-optimized versions of svt-av1, plus using faster maths functions - which makes a great difference in libavif, very like much more than a faster libpng.