Ffmpeg Xp Install
I'd like to share the, including my notes for the compilers. This is therefore a report rather than an 'issue'.
: Today when I did some testing with -c:v libx264 another fatal error popped up: The exception Illegal Instruction An attempt was made to execute an illegal instruction. (0xc000001d) occurred in the application at location 0x011e166a. I have narrowed it down to ffmpeg-20150823-git-1bf76cd-win32-static.7z being the latest working build. Ffmpeg-20150825-git-4c39892-win32-static.7z shows the fatal error. I wrongfully assumed a ffmpeg commit was the culprit for this error, as I've recently found out that with I could once again use the libx264 video encoder.
Examining its build configuration and comparing it to mine I found original_cflags='-mtune=core2 -O3' to be the cause and original_cflags='-mtune=generic -mfpmath=sse -msse' to be the solution for my non-sse2 cpu. Cross_compile_ffmpeg.sh 2017-03-29 18:00000 +0200 +++ cross_compile_ffmpeg.sh 2017-04-02 09:25000 +0200 @@ -1481,7 +1481,7 @@ build_ffmpeg() { # avoid installing this to system? Postpend_configure_opts='$postpend_configure_opts --prefix=$final_install_dir --disable-libgme' # gme broken for shared as of yet TODO. On Sun, Apr 2, 2017 at 7:21 AM, Reino Wijnsma ***@***.***>wrote:: Today when I did some testing with -c:v libx264 another fatal error popped up: The exception Illegal Instruction An attempt was made to execute an illegal instruction.
(0xc000001d) occurred in the application at location 0x011e166a. I have narrowed it down to ffmpeg-20150823-git-1bf76cd-win32-static.7z being the latest working build. Ffmpeg-20150825-git-4c39892-win32-static.7z shows the fatal error.
I wrongfully assumed a ffmpeg commit was the culprit for this error, as I've recently found out that with AbeChin's ffmpeg builds I could once again use the libx264 video encoder. Examining its build configuration and comparing it to mine I found original_cflags='-mtune=core2 -O3' to be the cause and original_cflags='-mtune=generic -mfpmath=sse -msse' to be the solution for my non-sse2 cpu. Diff: --- cross_compile_ffmpeg.sh 2017-03-29 18:00000 +0200+++ cross_compile_ffmpeg.sh 2017-04-02 09:25000 +0200@@ -1481,7 +1481,7 @@ build_ffmpeg() { # avoid installing this to system? Postpend_configure_opts='$postpend_configure_opts --prefix=$final_install_dir --disable-libgme' # gme broken for shared as of yet TODO. Can someone fix the binutils?
There is no Windows installer included in the builds so we need to decide where to put the program files. I chose to use the Windows standard location of “C: Program Files ”. You may choose your own location. Just make sure to use the location you have chosen in the following steps. Before you begin, make sure you have.
OK, ffmpeg built like this doesn't appear to crash. Thank you, I did have some fun learning:) and will check the things you raised (only rdp can change his patches/mingw-w64-build-3.6.7.local although I suppose ordinary illiterate peasants like me can create a local copy to try out the change). Suggestions on a free web host which allows direct downloads with the filename on the end of the url (as is required by one of the functions) would be welcome. 'xvid =>1.3.4'. Xvid isn't built (the function is there though) as Reino17 linked to an ffmpeg web page which suggested it was now handled 'internally'. An open-source HEVC encoder.
Looks interesting. Kvazaar_rdo_gcc7snapshot.patch.txt held in abeyance (and anticipation) until gcc v7 arrives in rdp's script and zeranoe's toolchain, then:). Nope, xvid code still comes from xvid. What's inside is the 'handling' as in eg. '--enable-libkvazaar' before.
But the lib has to be supplied. The following should be missing if compiled without --enable-xvid (this is from ffmpeg -h full): libxvid AVOptions: -lumi_aq E.V. Luminance masking AQ (from 0 to 1) (default 0) -variance_aq E.V. Variance AQ (from 0 to 1) (default 0) -ssim E.V.
Show SSIM information to stdout (from 0 to 2) (default off) off E.V. -ssim_acc E.V. SSIM accuracy (from 0 to 4) (default 2) -gmc E.V. Use GMC (from 0 to 1) (default 0) -me_quality E.V.
Motion estimation quality (from 0 to 6) (default 0) -mpeg_quant E.V. Use MPEG quantizers instead of H.263 (from 0 to 1) (default 0). + download_and_unpack_file + cd game-music-emu-0.6.1 + do_cmake_and_install '-DBUILD_SHARED_LIBS=OFF'. + generic_download_and_make_and_install + download_and_unpack_file openjpeg-2.1.2 + cd openjpeg-2.1.2 + export CFLAGS='$CFLAGS -DOPJ_STATIC' + do_cmake_and_install '-DBUILD_SHARED_LIBS:BOOL=off -DBUILD_THIRDPARTY:BOOL=on -DBUILD_PKGCONFIG_FILES:BOOL=on' + reset_cflags Thanks! Libgme and libopenjpeg are built without problems now.
Now those that remain unsuccessful are: gsm-1.0-pl14 -->gsm-1.0-pl16 libtheora-1.2.0alpha1 -->theora_git (libpng-1.5.26 -->libpng-1.6.29) vamp-plugin-sdk-2.6 -->vamp-plugin-sdk-2.7.1 libsamplerate-0.1.8 -->libsamplerate-0.1.9 libcaca-0.99.beta18 -->libcaca-0.99.beta19 libdvdread-4.9.9 -->libdvdread-5.0.3 libdvdnav-4.2.1 -->libdvdnav-5.0.3 libdvdcss-1.2.13 -->libdvdcss-1.4.0 libbluray-0.7.0 -->libbluray-1.0.0 I would advice you to include. If [[ $prefer_stable = 'n ' ]]; then do_git_checkout ' $checkout_dir 'origin/master ' else do_git_checkout ' $checkout_dir 'origin/stable ' fi build_x264_with_libav defaults to yes so that x264 can input mpeg files directly I'd say, keep the default 'no'. I think the majority of users of this script use it to build FFMpeg and not x264. It takes another 60-90min to build a FFMpeg without libx264 for this.
Ok, with ' (') I've successfully built. Compared to last one: game-music-emu-0.6.0 -->game-music-emu-0.6.1 snappy-1.1.3-14-g32d6d7d -->snappy-1.1.4 openjpeg-1.5.2 -->openjpeg-2.1.2 See. I haven't tested it, because I'm still on WinXP, but this should be a workaround. I checked and found 2 things: libcaca =>beta19. My ' cross_compile_ffmpeg.sh': # beta19 and git are xp unfriendly. Libcaca-0.99.beta19 and FFMpeg are compiled without problems, but FFMpeg then returns: 'The procedure entry point _vsnprintf_s could not be located in the dynamic link library msvcrt.dll'.
Nope, xvid code still comes from xvid. Well, that's a surprise then. I don't use XviD anymore, but is it bad to not have these options anymore for diehard XviD-encoders? What about WavPack?
Does the built-in implementation also have limitations? I've just quickly done some decoding and encoding and all went fine. Just some points: I have no problem connecting to. Well I prefer to stick with bitbucket, sourceforge, github etc as 1.) who knows what some tuukani (Tumbuktu?) website is doing with/to some sourcecode and 2.) who knows if such a site will still be there in a couple of days. Gendef It exist to rip of some info off ie. DLL's for which no sourcecode is provided, NVidia in this case. Old openssl These days a lot is going on with SSL, TLS etc, so most people 1.) have the 10 bucks to buy a legit Windows 7 CD on ebay and 2.) want to have the most recent openssl version they can find =>security holes etc.
Libcaca beta19 / _vsnprintf_s win xp I understand all that but this is a script for the 'majority'. It shouldn't be a problem to stick with your version and then just do a compare to rdp's (there's graphical diff tools for that you know) and then only cherry pick from rdp's script(s) what you need in the future. Well I prefer to stick with bitbucket, sourceforge, github etc You have a point there.
These days a lot is going on with SSL, TLS etc, so most people 1.) have the 10 bucks to buy a legit Windows 7 CD on ebay and 2.) want to have the most recent openssl version they can find =>security holes etc. Are you saying you had success building OpenSSL 1.1.0e with it's current configuration? I understand all that but this is a script for the 'majority'. I started this 'issue' with ' This is a report rather than an 'issue'.' So it was never my intention to demand for my cross_compile_ffmpeg.sh to be used. I just report.:) So it seems you need --with-libavcodec then, just check your exe-helpfiles.
Could you elaborate on this? Need it for what and where? Some old devices like old mobile phones and tablets etc can still deal with xvid but not hevc so xvid is still in use today:) But are these options really needed for old devices? Wouldn't create a good enough output? So you also got ERROR: openssl not found with OpenSSL 1.1.0e? I thought it was you who needed that wavpack functionality?
But why include libwavpack when wavpack can do everything too? In the meantime I've noticed: ffmpeg.exe -hide_banner -h encoder=wavpack Encoder wavpack [WavPack]: General capabilities: small Threading capabilities: none Supported sample formats: u8p s16p s32p fltp WavPack encoder AVOptions: -joint_stereo E.A.
(default auto) -optimize_mono E.A. (default false) ffmpeg.exe -hide_banner -h encoder=libwavpack Encoder libwavpack []: General capabilities: delay small Threading capabilities: none Supported sample formats: s32 Every 16bit audio you feed to libwavpack it converts to 32bit, as somehow that's all it supports. Ffmpeg.exe -i 'input.wav' -c:a wavpack -compression_level 4 'output.wv' works just fine (where -compression_level 4 equals wavpack's -hhx2), so libwavpack isn't needed at all. Btw, I still don't understand what you meant with --with-libavcodec. Is it a valid parameter? It's not in FFMpeg's configure at least. Yes, but no 'finetuning' then, no parameters, nothing then.
Check the complete xvid options, none of that is available then. I've just done 2 quick XviD encodes on a 640x480 video sample. One with -c:v mpeg4 -vtag xvid -b:v 1000k, the other with -c:v libxvid -b:v 1000k. You can see right away that libxvid produces a better result than mpeg4. I'll include libxvid again next time.;). But why include libwavpack when wavpack can do everything too? This is what I meant!
All you had to do is check your ffmpeg's help.:) Btw, I still don't understand what you meant with --with-libavcodec Sorry, I'm not familar with wavpack nor use it, wrong idea/track on my part in the rush. I'll include libxvid again next time.;) On the cmdline you'll have to make that an uppercase '-vtag XVID' as otherwise some important details are missing as you can see with tools like mediainfo etc. And just for fun openssl is already compiling again but now's got some libcrypto errors. Already got libs and.pc files:) Will try to check later this week if I get it working again. But that's a monster and complex anyway so I guess I'll stumble from one error to next etc, so I'm not sure!
'PROPER wipe.' Deleting the sandbox isn't proper cleaning actually. There's $mingw_w64_x86_64_prefix/lib/* and headers/files etc left some people only delete the win32 and x86_64 folders inside the sandbox and keep the cross_compilers folder, and that's not good enough.
Just to confirm, do you mean: when building a library, first check those folders for files which may have already been created by a previous run of that build function and remove them prior to running the function again? Sort of like a pre-build cleanup in each function? Or is there more to it than that? I suppose as a once-off way to find the files to be removed, an initial 'ls -alR' of the sandbox/cross_compilers folder tree and then 'again with a diff' after each function call would show the additional files to be removed as a 'begin' phase of that function? Edit: not sure if that's what you meant at all nor if this assists, attached is a zip listing the files each function creates under folder cross_compilers. It's not just the difference in files. Denon Dct A100 Manual Dexterity. It's because of the dependencies.
There are/will be libs which are linked against 'other components' (libs and object files etc). So if you change any of the 'other components' like say the gnutls version then nettle MAY throw errors unless it's removed/rebuild as well etc. Standalone things which do not depend on anything else and for which no dependencies exist elsewhere, like for instance that recent kvazaar addition, can just simply be removed (just use find. '*kvazaar*' xargs rm -fr) and be rebuild and it should compile/build without any further hassle/waste of time. OK thank you schmidthubert. Based on your comment it seems uncertain what to remove other than delete the complete sandbox every time I suppose. Playing around for my own purposes, in addition to the build library version updates I considered updating to gcc 6.3.0 etc, a bit like this using a locally updated copy of mingw-w64-build-3.6.7.local #mingw_w64_release_ver='5.0.1' # or git:) #mingw_w64_ver='git' mingw_w64_release_ver='5.0.2' gcc_release_ver='6.3.0' gcc_old_release_ver='4.9.4' # default if none specified, was 4.9.4 cannot be same as gcc_release_ver above, apparently, as a note.
#mpfr_release_ver='3.1.3' mpfr_release_ver='3.1.5' mpc_release_ver='1.0.3' #binutils_release_ver='2.27' binutils_release_ver='2.28' #gmp_release_ver='6.1.1' gmp_release_ver='6.1.2' isl_release_ver='0.16.1' pthreads_w32_release_ver='2-9-1' And then I re-read DeadSix27's work including a patch for GCC 6.3.0 weak references (?) and whatnot # 2017.04.11 patch per # and if [ '$gcc_ver' == '6.3.0' ]; then # We only support 6.3.0, patch the directx headers to work with vlc snd possibly other things, credits to: for the patches. Cd 'mingw-w64-$mingw_w64_ver' echo 'Patching mingw headers' curl --retry 5 '-O --fail exit 1 curl --retry 5 '-O --fail exit 1 curl --retry 5 '-O --fail exit 1 curl --retry 5 '-O --fail exit 1 echo 'applying patch 0003-dxgi-Add-missing-dxgi-1.2-structs-and-interfaces.patch' patch -p1 Raw bytestream.mkv ->Matroska.flv ->Flash Video.mp4 ->MP4 if compiled with GPAC or L-SMASH support (no) Output bit depth: 8 (configured at compile time) Time to look for the build bug (it worked under 4.9.4) and then for some ffmpeg.exe crash-detection tests I suppose. At a guess, I suppose the updated scripts have compatibility broken for anything other than running under Ubuntu 16.04.2. : Do you know of these patches still apply? -- apply_patch apply_patch No, sorry. Someone else should test that.
I only use the script to build FFMpeg. I only noticed there was a new version available for qt-everywhere-opensource. Files: As I'm still relatively new to Github, can you explain to me how you upload (temporary) files to someone's repository like this?: openssl 1.1.0e with --enable-openssl as well is building for me now again. Are you saying you had success building OpenSSL 1.1.0e with it's current configuration? I should've asked: '. And compiling FFMpeg?!' Because I've also had succes building OpenSSL 1.1.0e with both configs (the original and yours), but got ERROR: openssl not found once FFMpeg finished configuring.
I got this error without --enable-librtmp mind you, because. Would you mind having a look at build_librtmp as well?
It looks as if rtmpdump's openssl development stopped at some point, maybe in 2010 already. So it's not compatible with newer openssl versions anymore and therefore runs into these errors.
Just search for 'hmac_ctx_st' for instance and check its definition in openssl 1.0.2k and openssl.git, I'm running into similar errors as you: make[1]: *** Waiting for unfinished jobs. Hashswf.c:292:12: error: field 'ctx' has incomplete type HMAC_CTX ctx; ^ I don't think anyone will fix/update rtmpdump's code to work again with newer openssl versions. WinXP is dead now anyway, and it's the time of TLS now. You should really spend those 20 bucks for Win7 / Win81 Pro now. : To build with all features enabled, you will also need a Cryptography library and the zlib compression library. It uses OpenSSL by default, but you can also use GnuTLS or PolarSSL instead.
If it's true what you say, then why would they still put this on their frontpage? I think I'll send them a mail one of these days about the error we got. And it's the time of TLS now I hope you don't believe OpenSSL only supports SSL. Anyway, I've already successfully built RTMPDump with GnuTLS (+nettle and gmp), so I'm good. But if you include OpenSSL in your script, then I'd say you'd also have to make it work for those who prefer OpenSSL over GnuTLS. Apart from building OpenSSL, did you now also successfully built FFMpeg with OpenSSL 1.1.0e??
You should really spend those 20 bucks for Win7 / Win81 Pro now I'd have to buy a completely new computer first.;). And it's the time of TLS now I hope you don't believe OpenSSL only supports SSL. Don't worry, I know which is which and what is what.
Apart from building OpenSSL, did you now also successfully built FFMpeg with OpenSSL 1.1.0e?? Maybe you don't yet quite understand the concept of a program? If no code in a program is calling a certain function then no code of that function is actually included/(in ffmpeg mostly:statically) linked to/with that program.
So if there are no openssl function calls from librtmp (because it's using gnutls now) then no code FROM openssl will be included/linked in/with ffmpeg.exe even if 'ffmpeg -buildconf' shows BOTH --enable-gnutls AND --enable-openssl because that's just a BUILDCONF-'string' and 'ffmpeg -protocols' will still/only tell you that ffmpeg can 'speak' https and tls, that's all. Try this: include '--enable-openssl' 3 times in $config_options, that will will help you zilch, it's still only a BUILDCONF-string without any further meaning regarding the function(s) of ffmpeg. You should really spend those 20 bucks for Win7 / Win81 Pro now I'd have to buy a completely new computer first.;) I don't know any computer which doesn't work with Win7. There's Intel+AMD drivers for CPU+chipset even if older and in case your onboard USB or network card doesn't work there's PCI(e) cards with drivers for all OS's. That's probably because of Maybe you don't yet quite understand the concept of a program?
I may be new to cross compiling, but that I do understand. But I wasn't talking about RTMPDump. Openssl 1.1.0e with --enable-openssl as well is building for me now again. Are you saying you had success building OpenSSL 1.1.0e with it's current configuration? I should've asked: '. And compiling FFMpeg?!' Because I've also had succes building OpenSSL 1.1.0e with both configs (the original and yours), but got ERROR: openssl not found once FFMpeg finished configuring.
I got this error without --enable-librtmp mind you. I actually should've asked: ' Are you saying you had success building FFMpeg with --enable-openssl (OpenSSL 1.1.0. Davidson Medicine Free Download. e) and without --enable-librtmp (because it doesn't work with OpenSSL at the moment anyway)? Because only then I get ERROR: openssl not found. And this again is most likely because of. Besides: Because only then I get ERROR: openssl not found.
There's no such thing like a librtmp dependency in ffmpeg's./configure, all there's is --enable-gcrypt enable gcrypt, needed for rtmp(t)e support if openssl, librtmp or gmp is not used [no] --enable-gmp enable gmp, needed for rtmp(t)e support if openssl or librtmp is not used [no] --enable-gnutls enable gnutls, needed for https support if openssl is not used [no] and --enable-openssl enable openssl, needed for https support if gnutls is not used [no] and that's that. It's the other way around: ffrtmpcrypt_protocol_deps_any='gcrypt gmp openssl' So if you get openssl 'not found' errors then that MAYBE because you didn't nuke your sandbox COMPLETLY which maybe cluttered by a lot of dependencies/symbols already because you switched ffmpegs options a lot and simply 'forgot' about cleaning it. Such drastic changes will never work without PROPER wiping. It's 0's and 1's, there's no 'maybe'. To be 100% sure as in 1's you have to ALWAYS wipe it IF NOT 100% sure, there's no 0,9 in computing.
I've decided to fork rdp's project. I've updated the entire script, updated every dependency and fixed numerous things. I've spent way too much time on this the last 7 weeks or so, but boy have I learned a lot (for a Windows user)! On Sun, Jun 4, 2017 at 2:57 PM, Reino Wijnsma ***@***.***>wrote: Ok.
I've decided to fork rdp's project. I've updated the entire script, updated every dependency and fixed numerous things. I've spent way too much time on this the last 7 weeks or so, but boy have I learned a lot (for a Windows user)! If you want the latest nasm (ubuntu didn't install the latest), something like this in the build script helps (assuming run under sudo so the make install worked:)). #------------------------------------------------------------------------------------------------ # 2017.05.26 x264 has a new dependency on nasm 2.13.1 or greater. # before we do anything, build NASM if need be set -x if [[!
-d 'nasm-2.13.01' ]]; then echo 'Downloading nasm 2.13.01' download_and_unpack_file 'echo 'Configuring nasm 2.13.01' cd nasm-2.13.01./autogen.sh exit 1./configure --prefix=/usr --exec_prefix=/usr --enable-sections --enable-lto exit 1 # echo 'Make nasm 2.13.01' #make #everything make exit 1 # echo 'Installing nasm 2.13.01' make install exit 1 # cd. Echo 'Done Building and Installing nasm 2.13.01' fi set +x #read -p 'After nasm build, press Enter to continue' #------------------------------------------------------------------------------------------------ if you're tinkering with opencl, you may consider building gendef as well.
Nice./$zeranoe_script_name $zeranoe_script_options --build-type=win64 --enable-gendef exit 1 edit: I guess I should post this over at the fork. I didn't know Kyle released another update.
Building now. I'm not totally sure what you mean by 'when it feels stable'. The FFmpeg build works fine, so that's 'stable'. Concerning ' cross_compile_ffmpeg.sh' however, you do have to realize that all of this works on my (old) system AND I've only done win32 static builds! Win64 I can't test and the entire script needs another update in order to do shared builds. I've also made choices that not everyone might like.
Building libraries only for instances. While it shortens the total compilation time (and prevents compilation failure a couple of times), it also causes lot's of dependency exe-files not being build (x264.exe and x265.exe for instance). Building a shared libfdk-aac is another example. On the other hand, you're free to cherry-pick what you like of course. Just be sure to double check if it also works on your system.: Thanks.
At the moment however I'm satisfied with the 'stable' x264-release, so it's not needed. For whatever reason it's needed for the 'origin/master'-branch and since it's not included in Kyle's 'MingGW-w64 Build Script', we'd have to add it ourselves. Is this your code btw, or have you found it somewhere else? I can't just let things like this rest that easily. I'm only satisfied until it's fixed.. I'm closing this 'issue' now as I've succeeded in building a legacy hardware/software compatible static and shared FFmpeg build. Fresh builds: ( 'libfdk-aac-1.dll') ( 'libeay32.dll', 'ssleay32.dll') ( 'libcrypto-1_1.dll', 'libssl-1_1.dll') Compared to last release: mingw-w64-build-r21.local -->mingw-w64-build-r22.local (most notably GCC 6.3.0 -->7.1.0) netcdf-c_git (v4.4.1.1) -->libmysofa_git freetype-2.7.1 -->freetype-2.8 fontconfig-2.12.1 -->fontconfig-2.12.4 gnutls-3.5.12 -->gnutls-3.5.14 openssl-1.0.2k -->openssl-1.0.2l openssl-1.1.0e -->openssl-1.1.0f gsm-1.0-pl16 -->libsndfile_git (included).