Replace libvpx with libwebp

[cmb69]

See the respective bug report and a related discussion.

[weltling]

@cmb69 After talking to @remicollet it turned out that this change might create an issue to the downstream redists using various libgd versions (2.0, 2.1, 2.2).

I've managed to build libvpx on Windows (finally!)

http://windows.php.net/downloads/php-sdk/deps/vc14/x64/libvpx-1.4.0-vc14-x64.zip
http://windows.php.net/downloads/php-sdk/deps/vc14/x86/libvpx-1.4.0-vc14-x86.zip

Quite a complicated process, but as it works - probably we shouldn't introduce changes that could break something else, at least not ATM. I pity your work very much. Maybe you could check a libvpx build? We probably should use them for beta2.

/cc @pierrejoye

Thanks.

[cmb69]

Well, if we have to cater to downstream distros, it seems to me that we'd have to support both libvpx as well as libwebp. libgd-master has been already switched to libwebp…

Besides additional maintenance in the long run, this mostly seems to be a config issue for now. We'd have to undelete webpimg.c/h as well as bring back the old gd_webp.c (the collision with the new gd_webp.c would have to be resolved somehow), and we'd have to modifiy config.* accordingly.

I'll have a look at your libvpx builds anyway. Do you have some documentation regarding the build process available?

[pierrejoye]

5.x must remain using vpx. 7 can go with webp. Vpx usage for webp is a call
for a serie of issues as they tend to do their own stuff inside webp lately.
On Jul 21, 2015 3:22 AM, "Anatol Belski" notifications@github.com wrote:

@cmb69 https://github.com/cmb69 After talking to @remicollet
https://github.com/remicollet it turned out that this change might
create an issue to the downstream redists using various libgd versions
(2.0, 2.1, 2.2).

I've managed to build libvpx on Windows (finally!)

http://windows.php.net/downloads/php-sdk/deps/vc14/x64/libvpx-1.4.0-vc14-x64.zip

http://windows.php.net/downloads/php-sdk/deps/vc14/x86/libvpx-1.4.0-vc14-x86.zip

Quite a complicated process, but as it works - probably we shouldn't
introduce changes that could break something else, at least not ATM. I pity
your work very much. Maybe you could check a libvpx build? We probably
should use them for beta2.

/cc @pierrejoye https://github.com/pierrejoye

Thanks.

—
Reply to this email directly or view it on GitHub
#1429 (comment).

[pierrejoye]

Also vpx was fairly easy to build with vc9/11. Maybe they change some
things but it should not be too hard, for the time left for 5.x ;)
On Jul 21, 2015 3:22 AM, "Anatol Belski" notifications@github.com wrote:

@cmb69 https://github.com/cmb69 After talking to @remicollet
https://github.com/remicollet it turned out that this change might
create an issue to the downstream redists using various libgd versions
(2.0, 2.1, 2.2).

I've managed to build libvpx on Windows (finally!)

http://windows.php.net/downloads/php-sdk/deps/vc14/x64/libvpx-1.4.0-vc14-x64.zip

http://windows.php.net/downloads/php-sdk/deps/vc14/x86/libvpx-1.4.0-vc14-x86.zip

Quite a complicated process, but as it works - probably we shouldn't
introduce changes that could break something else, at least not ATM. I pity
your work very much. Maybe you could check a libvpx build? We probably
should use them for beta2.

/cc @pierrejoye https://github.com/pierrejoye

Thanks.

—
Reply to this email directly or view it on GitHub
#1429 (comment).

[remicollet]

Sorry but I think it is a bad idea which will introduce more confusion, and nightmare for downstream distribution which use system libgd.
For now PHP still use a old dev version of libgd.
libgd have switch to libwebp, but this is not released.

We should try to reduce diff with libgd upstream first, instead of increasing the mess.

[weltling]

@cmb69 you mean the php build process? It's nothing special, just drop libvpx into deps and --with-libvpx ... for building the libvpx itself there are docs on the home page.

@pierrejoye At the end - MSYS from MingW, but not a normal one - the one explicitly used by the Chromium deps is what has worked. It's a tool issue, obviously including my head :)

IMHO we should hold on till 7.1, then we stand better with the overall stability.

Thanks.

[pierrejoye]

Gd 2.2 will be released before 7. I do not think there are any issues with
PHP about that.

The PHP extension code does not depend at all on any of these libraries but
phpinfo, the bundle library does it.

If a distro uses the system library then php will provide the features the
system gd has. Whether it uses libvpx or libwebp does not matter.

If a distro uses 7 and the bundled gd, libwebp will be installed too. It
can be installed in parallel of libvpx.

Or do I miss something?
On Jul 21, 2015 1:23 PM, "Remi Collet" notifications@github.com wrote:

Sorry but I think it is a bad idea which will introduce more confusion,
and nightmare for downstream distribution which use system libgd.
For now PHP still use a old dev version of libgd.
libgd have switch to libwebp, but this is not released.

We should try to reduce diff with libgd upstream first, instead of
increasing the mess.

—
Reply to this email directly or view it on GitHub
#1429 (comment).

[pierrejoye]

I do not see why we should wait 7.1 but won't battle too much for it.

Keeping in mind that libwebp is by far superior to libvpx custom
implementation for webp various formats.
On Jul 21, 2015 1:56 PM, "Anatol Belski" notifications@github.com wrote:

@cmb69 https://github.com/cmb69 you mean the php build process? It's
nothing special, just drop libvpx into deps and --with-libvpx ... for
building the libvpx itself there are docs on the home page.

@pierrejoye https://github.com/pierrejoye At the end - MSYS from MingW,
but not a normal one - the one explicitly used by the Chromium deps is what
has worked. It's a tool issue, obviously including my head :)

IMHO we should hold on till 7.1, then we stand better with the overall
stability.

Thanks.

—
Reply to this email directly or view it on GitHub
#1429 (comment).

[weltling]

Ok, in this case i would pull this in beta2. Checked also Debian/Ubuntu and they all use the shared lib. On the other hand, it'll simplify the Windows maintanance part a lot, so probably is worthy.

Thanks.

[php-pulls]

Comment on behalf of ab at php.net:

merged in beta2

[cmb69]

@remicollet

For now PHP still use a old dev version of libgd.

However, several improvements have made to the bundled libgd which have not all been backported to upstream.

@weltling

for building the libvpx itself there are docs on the home page.

Thanks. However, it appears the issue is over now. :)

[remicollet]

However, several improvements have made to the bundled libgd which have not all been backported to upstream.

If true, this is obviously not acceptable.
Changes MUST go upstream first.

[cmb69]

If true, this is obviously not acceptable.
Changes MUST go upstream first.

See, for instance, my latest ticket for libgd. The clipping to the upper bounds had been implemented for the bundled libgd in 2003. I suspect that more changes had been made back then, which are not yet implemented upstream.

Wrt. to recent changes see, for instance, reading webp is broken which had been reported two years ago. As apparently none of the libgd developers had the time to look into this issue, I have fixed it for the bundled libgd to be able to write a meaningful PHPT to test imagewebp() and imagecreatefromwebp() to be able to check at least the basic working of this PR, and of course to make imagecreatefromwebp() available at least to those who use the bundled libgd. BTW, imagewebp() has a similar severe issue which I fixed in the bundled libgd (and reported to upstream).

Also see Pierre's answer to my inquiry wrt. to libgd.

[pierrejoye]

There are no improvement (as in feature) in php-src's gd since 5.4 afaict.

All new features go upstream first. Some features are only in PHP for BC
reason. 2.2 will solve this problem. Hopefully :)
On Jul 21, 2015 8:11 PM, "Remi Collet" notifications@github.com wrote:

However, several improvements have made to the bundled libgd which have
not all been backported to upstream.

If true, this is obviously not acceptable.
Changes MUST go upstream first.

—
Reply to this email directly or view it on GitHub
#1429 (comment).

[Jan-E]

@weltling With respect to #1429 (comment)

I did it with Cygwin. I am calling Cygwin as follows:

@echo off
call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86
C:
chdir C:\cygwin\bin
bash --login -i

Then in Cygwin:

$ cd /cygdrive/c/php-sdk/winlibs/libvpx/build
$ ../configure --target=x86-win32-vs12 --enable-static-msvcrt
$ make

This generates a vpx.sln for VC 2013. Open this vpx.sln in VC14, upgrade all *.vcxproj's amd you are almost there. --target=x86-win32-vs11 should work as well, I guess. But I did not try that.

Almost, because in the third_party\libyuv sources two commands are not compatible with VC14:

__declspec(align(16))
__declspec(align(32))

You can just remove those, because VC14 does the aligning.

Once you get the grip of it, the process is fairly easy. Something to document on github/winlibs/libvpx

[weltling]

@Jan-E you should principally avoid cygwin because it breaks anything possible on the system, you never know. Did you also build that project? Earlier version of libvpx was generating broken paths with cygwin. Anyway, MSYS worked now, but we don't need it now anyway.

Thanks.

[Jan-E]

All was done with the cl.exe, lib.exe and/or link.exe from the MSVC's on my system. Nothing native Cygwin. And in the end I just had a vpx.sln that I could open outside of Cygwin.
And, yes, I did build it this way. No broken paths with Libvpx 1.4.0.

[weltling]

Maybe cygwin has improved, but i'd better not to try to find out :)

[Jan-E]

With libvpx 1.1.0 the paths are still broken. Libvpx has improved, Cygwin is still the same. See 'Configure The Build Root' at http://www.webmproject.org/code/build-prerequisites/

Start a Cygwin or MSYS shell

[weltling]

Or maybe both. MingW was anyway not much better to the time of libvpx 1.1.0, make was just crashing AFAIR. We have improved as well by not having to use all that.

Thanks.

[yanjiuhuang]

If I want to integrate current gd master code in PHP 5.x by rebuilding from source code in order to fix some webp encoding problem, is there any problems or known issues ?

[cmb69]

@yanjiuhuang Which encoding problems have you found? Maybe these are resolved in PHP 5.6.12 (fixed bug #70102 (imagecreatefromwebm() shifts colors); fixed bug #66590 (imagewebp() doesn't pad to even length)); backporting these fixes, if necessary, might be easier for you. If there are still issue, please feel free to file a bug report.

[pierrejoye]

@remicollet Given the extended life of 5.6, I would be fine if we backport this PR to 5.6.

To other, any opposition?

[Jan-E]

Shouldn't be a problem for the Windows builds. I just created the static libs for VC11, using https://github.com/winlibs/libwebp and that went OK.

[pierrejoye]

Yes we use it already in 7.x.

The question is about using it in 5.6+ as well.
On Jun 6, 2016 3:02 PM, "Jan-E" notifications@github.com wrote:

Shouldn't be a problem for the Windows builds. I just created the static
libs for VC11, using https://github.com/winlibs/libwebp and that went OK.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1429 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AARPKDvJ2j0MoZ9Gf-uVW4Qa5ZyY0mDkks5qI9QtgaJpZM4Fb_SD
.

[Jan-E]

Yes, I was referring to 5.6. Note the 'VC11'.

[weltling]

Maybe we could backport the webp part so there's a choice between libwebp and libvpx in 5.6? Then it would allow to have consistent dependency without produce a BC breach.

Thanks.