Jan, Leong,

On Tue, April 22, 2014 17:09, Jan Ehrhardt wrote:
> Pierre Joye in php.pecl.dev (Tue, 22 Apr 2014 16:47:29 +0200):
>
>> On Tue, Apr 22, 2014 at 4:28 PM, Jan Ehrhardt <php...@ehrhardt.nl>
>> wrote:
>>
>>> There is hardly any way to avoid that. The extension will only be
>>> useable, if it produces at least MP4 (x264) output. This means ffmpeg
>>> has to be compiled with x264 support. And you cannot compile libx264
>>> with native MSVC:
>>
>> Which means it links against the default crt, which is sadly the VC6
>> one, available by defatult on all windows install.
>
> True. But I do not see another possibility if you want to include
> libx264, except for exec() calls to ffmpeg.exe. If the FFmpeg API is
> straightforward that should not be a problem.
>
> The extension links to VC9 / VC11 libs that are created by dumpbin
> /exports, which enables the extension to call the publicly available
> functions of the libav*.dll's. A call to msvcrt.dll on the backend of the
> libav*.dll does not really matter, AFAIK.
>
It might look unavoidable and doable, but indeed it is a bad thing. You
can read more here http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx .
Such things are not done on any other platforms, like on Linux there is
always one libc instance for all the packages. That is for example the
reason why we don't use the sqlite binaries produced by sqlite.org, see
bug #66968. I would never recommend something like that for production, as
you never know where it will bang.

Best regards

Anatol


-- 
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to