On Wed, Apr 23, 2014 at 7:43 PM, Jan Ehrhardt wrote:
> Hi Anatol,
>
> anatol@belski.net, 23/04/14, 19:19:
>>
>> > The previous message was a little clearer:
>> > https://mailman.videolan.org/pipermail/x264-devel/2011-May/008517.html
>>
>> I don't see where it was issue with building with MSVC
Hi Anatol,
anatol@belski.net, 23/04/14, 19:19:
> The previous message was a little clearer:
> https://mailman.videolan.org/pipermail/x264-devel/2011-May/008517.html
I don't see where it was issue with building with MSVC in that link, the
person just started to build with MinGW right on. To
Pierre Joye in php.pecl.dev (Wed, 23 Apr 2014 19:01:56 +0200):
>see:
>
>http://libav.org/platform.html#Windows
The only reference to x264 over there is in Paragraph 4.4:
Compilation under Cygwin
Also note this one:
If you want to build Libav with additional libraries, download Cygwin
"Devel" pac
see:
http://libav.org/platform.html#Windows
If a github repository is provided with ready to be used sources, we
will make it.
By the way, linking is not the problem, never was. I could link
anything vs anything. The problems appear at runtime, and they can be
pretty hard to track down.
Cheers,
Pierre Joye in php.pecl.dev (Wed, 23 Apr 2014 18:11:01 +0200):
>That being said, it is possible to build libav with vc, especially with
>2013. If you can provide a ready to be used sources tree, we will happily
>use it to provide automatic binaries build, which will then be available
>at the same
On Apr 23, 2014 4:10 PM, "Chung Leong" wrote:
>
> The distinction seems entirely philosophical. The usage of MSVCRT.DLL
> either leads to problems or it doesn't. How code executes in the computer
> isn't affected by our classification of it.
>
> In any event, it's possible to manually bind the Zer
Chung Leong in php.pecl.dev (Wed, 23 Apr 2014 16:10:01 +0200):
>The distinction seems entirely philosophical. The usage of MSVCRT.DLL
>either leads to problems or it doesn't. How code executes in the computer
>isn't affected by our classification of it.
>
>In any event, it's possible to manually bi
The distinction seems entirely philosophical. The usage of MSVCRT.DLL
either leads to problems or it doesn't. How code executes in the computer
isn't affected by our classification of it.
In any event, it's possible to manually bind the Zeranoe DLLs to the VC9 or
VC11 CRT.
On Wed, Apr 23, 2014 a
On Wed, Apr 23, 2014 at 9:49 AM, Jan Ehrhardt wrote:
> Pierre Joye in php.pecl.dev (Wed, 23 Apr 2014 08:53:47 +0200):
>>However, we do not support that for any libraries we provide or bundle
>>and for any pecl extension we build and provide. There are way too
>>many possible issues and we wasted p
Pierre Joye in php.pecl.dev (Wed, 23 Apr 2014 08:53:47 +0200):
>However, we do not support that for any libraries we provide or bundle
>and for any pecl extension we build and provide. There are way too
>many possible issues and we wasted plenty of times trying to fixing
>these issues. It is easier
On Wed, Apr 23, 2014 at 8:48 AM, Jan Ehrhardt wrote:
> "Anatol Belski" in php.pecl.dev (Wed, 23 Apr 2014 07:56:07 +0200):
>>> https://projects.blender.org/scm/viewvc.php/trunk/lib/win64/ffmpeg/Readme.txt?view=markup&root=bf-blender
>>> http://www.blender.org/download/
>>
>>Blender is not PHP. It m
"Anatol Belski" in php.pecl.dev (Wed, 23 Apr 2014 07:56:07 +0200):
>> https://projects.blender.org/scm/viewvc.php/trunk/lib/win64/ffmpeg/Readme.txt?view=markup&root=bf-blender
>> http://www.blender.org/download/
>
>Blender is not PHP. It might work if they only use the same compiler and
>dont mix C
Hi Leong,
> -Original Message-
> From: Chung Leong [mailto:cleong...@gmail.com]
> Sent: Wednesday, April 23, 2014 4:07 AM
> To: Anatol Belski
> Cc: pecl-dev@lists.php.net
> Subject: Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
>
> Okay, I tried
Jan,
On Wed, April 23, 2014 05:08, Jan Ehrhardt wrote:
> "Anatol Belski" in php.pecl.dev (Tue, 22 Apr 2014 21:53:35 +0200):
>
>> "The msvcrt.dll is now a "known DLL," meaning that it is a system
>> component owned and built by Windows. It is intended for future use only
>> by system-level compone
Chung Leong in php.pecl.dev (Wed, 23 Apr 2014 05:18:09 +0200):
>I just realized that PHP5TS.DLL imports the same DLLs.
Yes, but advapi.dll and user32.dll are system-level components on
Windows. Thus they are allowed to use msvcrt.dll.
>On Wed, Apr 23, 2014 at 4:52 AM, Jan Ehrhardt wrote:
>
>> Ch
I just realized that PHP5TS.DLL imports the same DLLs.
On Wed, Apr 23, 2014 at 4:52 AM, Jan Ehrhardt wrote:
> Chung Leong in php.pecl.dev (Wed, 23 Apr 2014 04:06:33 +0200):
> >Okay, I tried loading the FFmpeg DLLs manually. It turns out that it's
> >impossible to avoid loading MSVCRT.DLL into t
"Anatol Belski" in php.pecl.dev (Tue, 22 Apr 2014 21:53:35 +0200):
>"The msvcrt.dll is now a "known DLL," meaning that it is a system
>component owned and built by Windows. It is intended for future use only
>by system-level components."
>
>and neither PHP nor ffmpeg are system-level. So that is no
Chung Leong in php.pecl.dev (Wed, 23 Apr 2014 04:06:33 +0200):
>Okay, I tried loading the FFmpeg DLLs manually. It turns out that it's
>impossible to avoid loading MSVCRT.DLL into the process. FFmpeg imports
>from ADVAPI.DLL and USER32.DLL. Those system DLLs in turn will bring in
>MSVCRT.DLL. Even
Okay, I tried loading the FFmpeg DLLs manually. It turns out that it's
impossible to avoid loading MSVCRT.DLL into the process. FFmpeg imports
from ADVAPI.DLL and USER32.DLL. Those system DLLs in turn will bring in
MSVCRT.DLL. Even if we link statically or rebuild FFmpeg in VC, MSVCRT.DLL
will stil
On Tue, April 22, 2014 20:22, Chung Leong wrote:
> If loading msvcrt.dll is considered harmful, I guess I could just load
> the DLLs manually and redirect imports of functions in msvcrt.dll to the
> current CRT. It's never advisable to go that deep into an OS's internals
> but that's the only pract
Pierre Joye in php.pecl.dev (Tue, 22 Apr 2014 19:37:53 +0200):
>On Tue, Apr 22, 2014 at 7:25 PM, Jan Ehrhardt wrote:
>> Just curious: is there any OS still using ext/pspell? If not, should not
>> it be removed?
>
>Would love to but not willing to battle for that :)
Crystal clear ;-)
Jan
--
PEC
On Tue, Apr 22, 2014 at 7:25 PM, Jan Ehrhardt wrote:
> Pierre Joye in php.pecl.dev (Tue, 22 Apr 2014 19:01:20 +0200):
>>Also aspell is not supported on windows, for the exact reasons we
>>listed here. But it is also useless in regard to the other backends.
>
> Just curious: is there any OS still u
Pierre Joye in php.pecl.dev (Tue, 22 Apr 2014 19:01:20 +0200):
>Also aspell is not supported on windows, for the exact reasons we
>listed here. But it is also useless in regard to the other backends.
Just curious: is there any OS still using ext/pspell? If not, should not
it be removed?
Jan
--
On Tue, Apr 22, 2014 at 7:00 PM, Pierre Joye wrote:
> On Tue, Apr 22, 2014 at 6:58 PM, Jan Ehrhardt wrote:
>> "Anatol Belski" in php.pecl.dev (Tue, 22 Apr 2014 18:43:05 +0200):
>>>Hi Jan,
>>>
>>>On Tue, April 22, 2014 17:38, Jan Ehrhardt wrote:
I might be mistaken, but isn't the php_enchant.
On Tue, Apr 22, 2014 at 6:58 PM, Jan Ehrhardt wrote:
> "Anatol Belski" in php.pecl.dev (Tue, 22 Apr 2014 18:43:05 +0200):
>>Hi Jan,
>>
>>On Tue, April 22, 2014 17:38, Jan Ehrhardt wrote:
>>> I might be mistaken, but isn't the php_enchant.dll extension doing more
>>> or less the same thing:
>>
>>No
"Anatol Belski" in php.pecl.dev (Tue, 22 Apr 2014 18:43:05 +0200):
>Hi Jan,
>
>On Tue, April 22, 2014 17:38, Jan Ehrhardt wrote:
>> I might be mistaken, but isn't the php_enchant.dll extension doing more
>> or less the same thing:
>
>No, all the deps provided for the core and PECL exts are linked w
Hi Jan,
On Tue, April 22, 2014 17:38, Jan Ehrhardt wrote:
> Pierre Joye in php.pecl.dev (Tue, 22 Apr 2014 16:47:29 +0200):
>
>> Which means it links against the default crt, which is sadly the VC6
>> one, available by defatult on all windows install.
>
> I might be mistaken, but isn't the php_ench
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
>> wrote:
>>
>>> There is hardly any way to avoid that. The extension will only be
>>> useable, if it produces at least
Pierre Joye in php.pecl.dev (Tue, 22 Apr 2014 16:47:29 +0200):
>Which means it links against the default crt, which is sadly the VC6
>one, available by defatult on all windows install.
I might be mistaken, but isn't the php_enchant.dll extension doing more
or less the same thing:
https://github.c
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 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
On Tue, Apr 22, 2014 at 4:28 PM, Jan Ehrhardt wrote:
> "Anatol Belski" in php.pecl.dev (Tue, 22 Apr 2014 10:44:52 +0200):
>>I would strongely discourage you from linking with the libraries built
>>with MinGW.
>
> There is hardly any way to avoid that. The extension will only be
> useable, if it pr
Jan Ehrhardt in php.pecl.dev (Tue, 22 Apr 2014 16:28:30 +0200):
>"Anatol Belski" in php.pecl.dev (Tue, 22 Apr 2014 10:44:52 +0200):
>>I would strongely discourage you from linking with the libraries built
>>with MinGW.
>
>There is hardly any way to avoid that. The extension will only be
>useable, i
"Anatol Belski" in php.pecl.dev (Tue, 22 Apr 2014 10:44:52 +0200):
>I would strongely discourage you from linking with the libraries built
>with MinGW.
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
Hi Leong,
On Tue, April 22, 2014 02:31, Chung Leong wrote:
> I would like to add my AV extension to PECL. The extension gives PHP
> programmers a way to decode and encode video using the FFmpeg or Libav
> (the
> latter is favored by some distros like Debian). I've written about it
> here:
> http:/
I would like to add my AV extension to PECL. The extension gives PHP
programmers a way to decode and encode video using the FFmpeg or Libav (the
latter is favored by some distros like Debian). I've written about it here:
http://www.php-qb.net/index.php/2-uncategorised/16-a-new-bridge-between-php-an
35 matches
Mail list logo
