Re: Re: Finishing AVIF support in getimagesize()

From: Date: Wed, 08 Dec 2021 18:40:26 +0000
Subject: Re: Re: Finishing AVIF support in getimagesize()
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-116592@lists.php.net to get a copy of this message
On 08.12.2021 at 19:22, Yannis Guyon via internals wrote: >> On a general principle, I understood that bundling libs should be avoided. > > libavifinfo was designed more as a copy-pastable snippet than a library. Thanks for clarifying. > Unfortunately AVIF is complex and avifinfo.c is lengthier than expected, > although > I believe 700 lines are still reasonable and way below a library's scale.. > >> I am not totally sure aviinfo is stable enough to be bundle either way. > > What would you call "stable enough"? > There is a test > > <https://aomedia.googlesource.com/libavifinfo/+/refs/heads/main/tests/avifinfo_test.cc>, > it is currently internally fuzzed > > <https://aomedia.googlesource.com/libavifinfo/+/refs/heads/main/tests/avifinfo_fuzz.cc> > and > was successfully run on more > than 60k crawled AVIF images. I do not plan on modifying or testing it > further > until the AVIF format changes. > >> The format will be widely used in a near future so i would rather allow it >> if libavinfo js available rather than bundling it. > > What would be the pros and cons of using a javascript version of libavifinfo > rather than the C one? I think that "js" is a typo, and should have actually been "is". :) Anyhow, that is the point. If there will be no (widely available) libavifinfo, it makes sense to either bundle it, and have the full getimagesize() functionality for AVIF, or to not bundle it, and have only the most basic getimagesize() support for AVIF (as it is now). Christoph

« previous php.internals (#116592) next »