Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116592 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 47947 invoked from network); 8 Dec 2021 17:40:04 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 8 Dec 2021 17:40:04 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id AF7991804D4 for ; Wed, 8 Dec 2021 10:40:31 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,NICE_REPLY_A, RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS8560 212.227.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 8 Dec 2021 10:40:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1638988827; bh=4B//zZxh4PdsHHEOOzb86B2Vl0kldcI5n7PGZT6kc8I=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=kg5eP3ekndP8GPJysK+QnJu8mwV28LpBb3i4WfhMFhUvSSOzDuBkaVUP3KraFMS07 pOcERnMYflgnz4JJkVzEBFu7S/186qT5p2cQSig4JKQF1AehUlxUNUHW8k9O+W4SZR w94b7v/T8PXDJut/Kqq0AAjMcYdxV4XMDlPxiDPo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.2.130] ([84.179.239.183]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MdvmO-1mNLH31tiA-00b7Zt; Wed, 08 Dec 2021 19:40:27 +0100 Message-ID: <0f858079-9966-a04c-95d4-a5368f36b86b@gmx.de> Date: Wed, 8 Dec 2021 19:40:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: de-DE To: Yannis Guyon , Pierre Joye Cc: Ben Morss , PHP internals References: <7c4411c8-8bf6-36f1-36f8-1a7391c2a3d7@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:N1esvmnrkDx/vq6REVMpG65rAE+MF24cOQX8KSPts/CYmQhw0Lz hTobqD1VBqraMlu/EYIFdiKctNuVUxSZt8bvFDGZhsLY8UfcnEwiE9RqxIkuJrvMlq7OZ6D WYleWurxs0xE8lL+GXbCTBxTiv2Fi78XxaukEpESDM25I1RwXFSe+MdiDvvBVlhh67PodvH gC8vidS0xhNBOg4mA0hlg== X-UI-Out-Filterresults: notjunk:1;V03:K0:STHplTh8oL8=:og/pRiW73D2tEYPnWd0cio xxTIShi9XESZ4DnOFV28L6MQPjB+lMpJLpXUQAzJxVjCyW+Mls/dgi9OHnnE7KANmUk5virPy 07pVeJe3z1V4Vxl2Urmq2C4yEgCrG+dTJjal3/N4SLA8zhMIdHJxxp85j/jSq/ccwjzVRC+Uc p/iyocZA53pjxJ6aRURfu7a/6KvtZ5ZDYJHDKogbhAL6g+LMNe+aipou5jbKY6aSnvsgQT3Dy re0nFGcyWeqOBiyWySDLiXPFr5zGxGPTNE4vL6KLN5XwFxv63B7UytPa2HVwoyDu9s6CsZe4M +SDquks0io6puSeO74PPF/bgiTMWgccG/m9FSflrjsx0a8uhx+gAztkuD0OjKz2qHYveIxsx3 3LEi+OMLLS26rML9xNgNWSm4XdiOsc+H3izlLpTCC/OZgVT0WubBHrKNsKHO4wrGWp0QsfpJZ a3dlbh+wRsuvt4Ospk8eFaPBraJLf0lQxRthdv885Ufoi0jt+lrLTkl8WNlDC43oVEn1CQbTg a0M1Z0/Y1TLLkhIn31jMmQR7EhefzPrmw60C80eI688hUuT6PU4pjuc/lLWQk8LKzaMLniBUU WwmL6b2tJ6f6vucUIJ6uTHgNuo98gyDlpbg0cm0TcT1x98t4pYRecoKUu1IV1co0nb8uszjDh xnTVl+WhMNgBDe+Rk8BOyQCCcwnBYMPPb/wAcHWukzhZ0ivVHpYhq9RcEmTGFb9I11KKaFna7 3Xaid3fQlI0+S9rtST4lB+X4iiYXQz/wo6JIP0AnsiIji+gZZEh6vkb4E6lJCF/b+2v1Tc9BT N8DbeQ7VHlcyCc5GYMcxQoNUaE9jZ3gaYMcimExD6A1IGpUBH3vOhdhvDD5y+30D9eM2uNmSA Vp1abSf9sHEvrJxY+f6P7oSCrPbQiG/bKhrixCoq9LwmteIUWv7HZsE0c6fOw/LgfEbsAr8KC TYEGtX/vLxLftoNYoMOtfc6Z+nUbapbilr+3fKipzjHHS4ahS8tZEMKduz3KrAccgON9Vsxna 3fgYEzyXQW5Rb04zdtcOMZn6vpbFhaSHQyEQvFwiWbnGO4bDiW5OBPmEgV9ZxaHtzG4ZZIjXZ SqyvBlFjjF6rUk= Subject: Re: [PHP-DEV] Re: Finishing AVIF support in getimagesize() From: cmbecker69@gmx.de ("Christoph M. Becker") On 08.12.2021 at 19:22, Yannis Guyon via internals wrote: >> On a general principle, I understood that bundling libs should be avoid= ed. > > 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 > , > it is currently internally fuzzed > > 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 allo= w it >> if libavinfo js available rather than bundling it. > > What would be the pros and cons of using a javascript version of libavif= info > 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