RE: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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 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 still get loaded. While I see some value in not loading an extra C runtime, if it's going to be there irregardless, I don't think it's worth the trouble avoiding it. The likelihood of MSVCRT.DLL working for FFMPEG.EXE but somehow failing when the same code is used in a PHP extension is exceedingly low. I just don't see how that can happen. On Tue, Apr 22, 2014 at 9:53 PM, Anatol Belski anatol@belski.netwrote: 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 practical solution I see. I don't really think loading mscvrt is such a serious issue. I know how things can go haywired when you start passing file handle and malloc'ed memory from one CRT to another. As long as the CRT's don't interact, there should be no problem. The CRTs must be able to co-exist for Windows to work at all. I just did a scan of my SysWOW64. A total of 1416 DLLs imports mscvrt.dll, including such critical files as comdlg32.dll and usp10.dll. On Tue, Apr 22, 2014 at 6:37 PM, Anatol Belski anatol@belski.netwrote: 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 Yep, they also say on that page 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 not an issue for components built by windows itself, but it can be it very much for everything else. And that's what they say and you confirm :) msvcrt.dll will be different on every different platform/edition and so on. Yes, you're right - as long as they don't interact, it should work. But, doesn't it sound somehow ... too freaky? I mean that's fine as a thing to experiment with, but ... would you do the same on unix? Would you recommend people to use it in production because it should work despite they say we shouldn't do it? Maybe at least try some static build, or build with visual studio? Best regards Anatol Yeah, lets ignore that stupid docs :) However user32.dll is a system component, and it exports some functions. So you talk about a standard OS library. Many OSS projects use this approach in hope it'll work, but they at least don't mix CRT. Many other OSS projects use the same approach we do - but that should to be consistent. Best regards Anatol -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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=markuproot=bf-blender http://www.blender.org/download/ Blender is not PHP. It might work if they only use the same compiler and dont mix CRT, like many other projects do. We have another situation. They do mix compilers. Blender is compiled with VC9, but they link to FFmpeg DLL's including dependencies like x264 that are compiled with GCC 4.7.4. Quote: 5. There were some problems with linking blender against installed dll-s which were solved by manual stripping dll (strip --strip-unneeded --strip-debug) and generating .lib-files for them This is exactly the same thing that Chung Leong is doing in his AV-extension. If you browse around in Blender's trunk, you can see they also are preparing the same thing for VC11 and VC12. Jan -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
On Wed, Apr 23, 2014 at 8:48 AM, Jan Ehrhardt php...@ehrhardt.nl 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=markuproot=bf-blender http://www.blender.org/download/ Blender is not PHP. It might work if they only use the same compiler and dont mix CRT, like many other projects do. We have another situation. They do mix compilers. Blender is compiled with VC9, but they link to FFmpeg DLL's including dependencies like x264 that are compiled with GCC 4.7.4. Quote: 5. There were some problems with linking blender against installed dll-s which were solved by manual stripping dll (strip --strip-unneeded --strip-debug) and generating .lib-files for them This is exactly the same thing that Chung Leong is doing in his AV-extension. If you browse around in Blender's trunk, you can see they also are preparing the same thing for VC11 and VC12. Let me state it again for clarity: It is possible to mix CRTs, when done very very carefully. Firebird does it for example and the firebird clients work with any crt versions. 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, safer and cleaner to provide all binaries linked against the same CRT. Now, if you like to do it with various CRTs, go ahead, no issue here :) But we do not support external binaries, be from Zend or any other 3rd party. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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, safer and cleaner to provide all binaries linked against the same CRT. Now, if you like to do it with various CRTs, go ahead, no issue here :) But we do not support external binaries, be from Zend or any other 3rd party. Summary: 1. Building using the extension on Windows is just impossible without linking to DLL's that are compiled with GCC. 2. You do not support external binaries. So, I guess you will never provide a php_av.dll on windows.php.net. Now, what is the consequnce? Do you still welcome Chung's extension on PECL for the *nix users? Jan -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
On Wed, Apr 23, 2014 at 9:49 AM, Jan Ehrhardt php...@ehrhardt.nl 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 plenty of times trying to fixing these issues. It is easier, safer and cleaner to provide all binaries linked against the same CRT. Now, if you like to do it with various CRTs, go ahead, no issue here :) But we do not support external binaries, be from Zend or any other 3rd party. Summary: 1. Building using the extension on Windows is just impossible without linking to DLL's that are compiled with GCC. 2. You do not support external binaries. So, I guess you will never provide a php_av.dll on windows.php.net. Now, what is the consequnce? Do you still welcome Chung's extension on PECL for the *nix users? indeed :) -- Pierre @pierrejoye | http://www.libgd.org -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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 at 5:59 AM, Jan Ehrhardt php...@ehrhardt.nl wrote: 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 php...@ehrhardt.nl 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 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 still get loaded. Jan -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
On Apr 23, 2014 4:10 PM, Chung Leong cleong...@gmail.com 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 Zeranoe DLLs to the VC9 or VC11 CRT. No it is based on facts and bug reports. That does not prevent you to release under pecl tho'. 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 place than the src. Cheers, Pierre
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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 place than the src.
Wow.
Is that including the required (output) libs? Will VS2013 be able to
build a static VC9-lib for x264? Source are here:
ftp://ftp.videolan.org/pub/videolan/x264/snapshots/last_stable_x264.tar.bz2
When cross-compiling on Ubuntu the first step is to build all
dependencies as static lib, like this:
./configure \
--prefix=/home/sergey/lib/x264 \
--extra-cflags=-g -Wall -Wextra \
--extra-ldflags=-Wl,--as-needed -static-libgcc \
--enable-static \
--enable-win32thread \
--disable-lavf \
--cross-prefix=mingw32- \
--host=mingw32
After you have built all dependencies (as static lib) you link them
while building FFmpeg.exe and its DLL's itself.
Taking Blender as example (where the --enable clauses are the most
interesting):
./configure \
--prefix=/home/sergey/lib/ffmpeg-2.1.4 \
--enable-shared \
--disable-static \
--disable-avfilter \
--disable-vdpau \
--disable-bzlib \
--disable-libgsm \
--enable-libschroedinger \
--disable-libspeex \
--enable-libtheora \
--enable-libvorbis \
--enable-zlib \
--enable-libvpx \
--enable-stripping \
--enable-runtime-cpudetect \
--disable-vaapi \
--enable-libopenjpeg \
--disable-nonfree \
--enable-gpl \
--disable-postproc \
--disable-x11grab \
--enable-libmp3lame \
--disable-librtmp \
--enable-libx264 \
--enable-libxvid \
--disable-libopencore-amrnb \
--disable-libopencore-amrwb \
--disable-libdc1394 \
--disable-version3 \
--disable-debug \
--enable-optimizations \
--disable-sse \
--disable-ssse3 \
--enable-ffplay \
--enable-w32threads \
--disable-pthreads \
--extra-cflags=-g -Wall -Wextra -I${LIBS}/lame/include
-I${LIBS}/openjpeg/include -I${LIBS}/ogg/include
-I${LIBS}/vorbis/include -I${LIBS}/theora/include
-I${LIBS}/vpx-${VPX_VERSION}/include -I${LIBS}/x264/include
-I${LIBS}/xvid/include -I${LIBS}/dirac/include/dirac
-I${LIBS}/schroedinger/include/schroedinger-1.0 -I${LIBS}/zlib/include
\
--extra-ldflags=-Wl,--as-needed -static-libgcc -L${LIBS}/lame/lib
-L${LIBS}/openjpeg/lib -L${LIBS}/ogg/lib -L${LIBS}/vorbis/lib
-L${LIBS}/theora/lib -L${LIBS}/vpx-${VPX_VERSION}/lib -L${LIBS}/x264/lib
-L${LIBS}/xvid/lib -L${LIBS}/dirac/lib -L${LIBS}/schroedinger/lib
-L${LIBS}/orc/lib -L${LIBS}/zlib/lib
Jan
--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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,
On Wed, Apr 23, 2014 at 6:46 PM, Jan Ehrhardt php...@ehrhardt.nl wrote:
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 place than the src.
Wow.
Is that including the required (output) libs? Will VS2013 be able to
build a static VC9-lib for x264? Source are here:
ftp://ftp.videolan.org/pub/videolan/x264/snapshots/last_stable_x264.tar.bz2
When cross-compiling on Ubuntu the first step is to build all
dependencies as static lib, like this:
./configure \
--prefix=/home/sergey/lib/x264 \
--extra-cflags=-g -Wall -Wextra \
--extra-ldflags=-Wl,--as-needed -static-libgcc \
--enable-static \
--enable-win32thread \
--disable-lavf \
--cross-prefix=mingw32- \
--host=mingw32
After you have built all dependencies (as static lib) you link them
while building FFmpeg.exe and its DLL's itself.
Taking Blender as example (where the --enable clauses are the most
interesting):
./configure \
--prefix=/home/sergey/lib/ffmpeg-2.1.4 \
--enable-shared \
--disable-static \
--disable-avfilter \
--disable-vdpau \
--disable-bzlib \
--disable-libgsm \
--enable-libschroedinger \
--disable-libspeex \
--enable-libtheora \
--enable-libvorbis \
--enable-zlib \
--enable-libvpx \
--enable-stripping \
--enable-runtime-cpudetect \
--disable-vaapi \
--enable-libopenjpeg \
--disable-nonfree \
--enable-gpl \
--disable-postproc \
--disable-x11grab \
--enable-libmp3lame \
--disable-librtmp \
--enable-libx264 \
--enable-libxvid \
--disable-libopencore-amrnb \
--disable-libopencore-amrwb \
--disable-libdc1394 \
--disable-version3 \
--disable-debug \
--enable-optimizations \
--disable-sse \
--disable-ssse3 \
--enable-ffplay \
--enable-w32threads \
--disable-pthreads \
--extra-cflags=-g -Wall -Wextra -I${LIBS}/lame/include
-I${LIBS}/openjpeg/include -I${LIBS}/ogg/include
-I${LIBS}/vorbis/include -I${LIBS}/theora/include
-I${LIBS}/vpx-${VPX_VERSION}/include -I${LIBS}/x264/include
-I${LIBS}/xvid/include -I${LIBS}/dirac/include/dirac
-I${LIBS}/schroedinger/include/schroedinger-1.0 -I${LIBS}/zlib/include
\
--extra-ldflags=-Wl,--as-needed -static-libgcc -L${LIBS}/lame/lib
-L${LIBS}/openjpeg/lib -L${LIBS}/ogg/lib -L${LIBS}/vorbis/lib
-L${LIBS}/theora/lib -L${LIBS}/vpx-${VPX_VERSION}/lib -L${LIBS}/x264/lib
-L${LIBS}/xvid/lib -L${LIBS}/dirac/lib -L${LIBS}/schroedinger/lib
-L${LIBS}/orc/lib -L${LIBS}/zlib/lib
Jan
--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
Pierre
@pierrejoye | http://www.libgd.org
--
PECL development discussion Mailing List (http://pecl.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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 build it with MSVC it'll need some work to convert the build system to something portable or to an VC project. It was an answer to the question in the topic-start: Is there any build setup for MSVC or how to use mingw built library in MSVC. The answers all involved non native MSVC compilers. So the question remains: how to build a static VC9 lib for the current x264. Also note this remark in the Libav reference by Pierre: The recommendation for x264 is to build it from source, as it evolves too quickly for Cygwin Ports to be up to date. So the work to convert the x264 source to something portable or to a VC project should be an automatic one. Jan -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
On Wed, Apr 23, 2014 at 7:43 PM, Jan Ehrhardt php...@ehrhardt.nl 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 in that link, the person just started to build with MinGW right on. To build it with MSVC it'll need some work to convert the build system to something portable or to an VC project. It was an answer to the question in the topic-start: Is there any build setup for MSVC or how to use mingw built library in MSVC. The answers all involved non native MSVC compilers. So the question remains: how to build a static VC9 lib for the current x264. Also note this remark in the Libav reference by Pierre: The recommendation for x264 is to build it from source, as it evolves too quickly for Cygwin Ports to be up to date. So the work to convert the x264 source to something portable or to a VC project should be an automatic one. afair libogg builds fine with VC, only needs some tweaks to export some missing symbols. This issue does not exist if you built it static. -- Pierre @pierrejoye | http://www.libgd.org -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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://www.php-qb.net/index.php/2-uncategorised/16-a-new-bridge-between-ph p-and-ffmpeg I would strongely discourage you from linking with the libraries built with MinGW. Especially if those are C++, but also in case of simple C. You can read here a bit about some issues which could be caused http://www.mingw.org/wiki/Interoperability_of_Libraries_Created_by_Different_Compiler_Brands but also in case of simple C - different alignment, passing around allocated object pointers, file descriptors - the risk of an instability is very high. Instead, ffmpeg libraries and their dependencies should be built with the native vc++, namely the same the corresponding PHP version is using. I'm reading this one right now https://www.ffmpeg.org/platform.html#Microsoft-Visual-C_002b_002b-or-Intel-C_002b_002b-Compiler-for-Windows Regards Anatol -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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 compiled with x264 support. And you cannot compile libx264 with native MSVC: https://mailman.videolan.org/pipermail/x264-devel/2011-May/008518.html The same accounts for many more libraries that are compiled into FFmpeg. When you are on a Windows platform, there only is one rock-solid FFmpeg implementation: Zeranoe's builds. Zeranoe's builds are cross-compiled on Linux, using MingGW-w64. However, the DLL's are not dependent on any external cygwin-dll or libgcc-dll, so they are pretty much self-contained. Jan -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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, 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: https://mailman.videolan.org/pipermail/x264-devel/2011-May/008518.html The previous message was a little clearer: https://mailman.videolan.org/pipermail/x264-devel/2011-May/008517.html Jan -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
On Tue, Apr 22, 2014 at 4:28 PM, Jan Ehrhardt php...@ehrhardt.nl 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 produces at least MP4 (x264) output. This means ffmpeg has to be compiled with x264 support. And you cannot compile libx264 with native MSVC: https://mailman.videolan.org/pipermail/x264-devel/2011-May/008518.html The same accounts for many more libraries that are compiled into FFmpeg. When you are on a Windows platform, there only is one rock-solid FFmpeg implementation: Zeranoe's builds. Zeranoe's builds are cross-compiled on Linux, using MingGW-w64. However, the DLL's are not dependent on any external cygwin-dll or libgcc-dll, so they are pretty much self-contained. Which means it links against the default crt, which is sadly the VC6 one, available by defatult on all windows install. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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. Jan -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
On Tue, Apr 22, 2014 at 6:58 PM, Jan Ehrhardt php...@ehrhardt.nl 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, all the deps provided for the core and PECL exts are linked with the same CRT corresponding to the PHP version. https://github.com/winlibs/enchant/blob/master/src/aspell/aspell_provider.c#L458 Three options: 1. You have a (lib)aspell-15.dll, compiled with VC9 / VC11 2. You do not link/load (lib)aspell-15.dll 3. You link/load a GCC (lib)aspell-15.dll Option 2? Again, we build all libraries and deps using the same environments. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
On Tue, Apr 22, 2014 at 7:00 PM, Pierre Joye pierre@gmail.com wrote: On Tue, Apr 22, 2014 at 6:58 PM, Jan Ehrhardt php...@ehrhardt.nl 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, all the deps provided for the core and PECL exts are linked with the same CRT corresponding to the PHP version. https://github.com/winlibs/enchant/blob/master/src/aspell/aspell_provider.c#L458 Three options: 1. You have a (lib)aspell-15.dll, compiled with VC9 / VC11 2. You do not link/load (lib)aspell-15.dll 3. You link/load a GCC (lib)aspell-15.dll Option 2? Again, we build all libraries and deps using the same environments. 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. -- Pierre @pierrejoye | http://www.libgd.org -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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 php...@ehrhardt.nl 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 -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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 still get loaded. While I see some value in not loading an extra C runtime, if it's going to be there irregardless, I don't think it's worth the trouble avoiding it. The likelihood of MSVCRT.DLL working for FFMPEG.EXE but somehow failing when the same code is used in a PHP extension is exceedingly low. I just don't see how that can happen. On Tue, Apr 22, 2014 at 9:53 PM, Anatol Belski anatol@belski.netwrote: 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 practical solution I see. I don't really think loading mscvrt is such a serious issue. I know how things can go haywired when you start passing file handle and malloc'ed memory from one CRT to another. As long as the CRT's don't interact, there should be no problem. The CRTs must be able to co-exist for Windows to work at all. I just did a scan of my SysWOW64. A total of 1416 DLLs imports mscvrt.dll, including such critical files as comdlg32.dll and usp10.dll. On Tue, Apr 22, 2014 at 6:37 PM, Anatol Belski anatol@belski.netwrote: 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 Yep, they also say on that page 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 not an issue for components built by windows itself, but it can be it very much for everything else. And that's what they say and you confirm :) msvcrt.dll will be different on every different platform/edition and so on. Yes, you're right - as long as they don't interact, it should work. But, doesn't it sound somehow ... too freaky? I mean that's fine as a thing to experiment with, but ... would you do the same on unix? Would you recommend people to use it in production because it should work despite they say we shouldn't do it? Maybe at least try some static build, or build with visual studio? Best regards Anatol
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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 not an issue for components built by windows itself, but it can be it very much for everything else. And that's what they say and you confirm :) msvcrt.dll will be different on every different platform/edition and so on. Yes, you're right - as long as they don't interact, it should work. But, doesn't it sound somehow ... too freaky? To be frank: No, it does not sound too freaky. FFmpeg.exe itself uses msvcrt.dll, VLC does it, Blender does it. See this reference for Blender: https://projects.blender.org/scm/viewvc.php/trunk/lib/win64/ffmpeg/Readme.txt?view=markuproot=bf-blender Would I recommend using Blender in a Windows production environment? Yes, I would. And so do they: http://www.blender.org/download/ Jan -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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 php...@ehrhardt.nl 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 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 still get loaded. Jan -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PECL-DEV] Extension Proposal: Video Encoding using FFmpeg
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 components. and neither PHP nor ffmpeg are system-level. So that is not an issue for components built by windows itself, but it can be it very much for everything else. And that's what they say and you confirm :) msvcrt.dll will be different on every different platform/edition and so on. Yes, you're right - as long as they don't interact, it should work. But, doesn't it sound somehow ... too freaky? To be frank: No, it does not sound too freaky. FFmpeg.exe itself uses msvcrt.dll, VLC does it, Blender does it. See this reference for Blender: https://projects.blender.org/scm/viewvc.php/trunk/lib/win64/ffmpeg/Readme . txt?view=markuproot=bf-blender Would I recommend using Blender in a Windows production environment? Yes, I would. And so do they: http://www.blender.org/download/ Jan -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php Blender is not PHP. It might work if they only use the same compiler and dont mix CRT, like many other projects do. We have another situation. Regards Anatol -- PECL development discussion Mailing List (http://pecl.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
