Current Patches, Where to get them, How they affect speed/output

[[ReX]]

[ReX], i'm trying to adapt icl compiler in to pseudo mingw environment to work as gcc or as msvc. in short - you must set almost all env-variables from windows environment in to mingw (in mingw notation). e.g CPATH=${ICPP_COMPILER11}/ipp/em64t/include:${ICPP_COMPILER11}/mkl/include
sufficient to set: ICPP_COMPILER11;VSINSTALLDIR;WindowsSdkDir;INTEL_LICENSE_FILE;CPATH;FPATH;IPPROOT;LIBPATH;LIBRARY_PATH;INCLUDE;LIB;PATH variables.

I'm not familiar with variables in msys, where should I set them?

kemuri let me in on a trick that works with cygwin at least. Start the ICL IA-32/Intel64 command prompt first, and then launch cygwin from that prompt. It will automatically pass over all environment settings. This might work with mingw, too.

I launched the Intel command prompt and launched msys.bat from it, still getting the same error. I'm using Windows 7.

[kemuri-_9]

;1365622']I launched the Intel command prompt and launched msys.bat from it, still getting the same error. I'm using Windows 7.

in this situation as the path setup is msys then icl,
you'll need to rename msys's link.exe to something else as it'll interfere with msvc's link.exe
after that you should have minimal issues.

you can also do
start msys.bat
or
\msys\bin\bash --login -i

as other options to get the environment going.

also do note that i've been debating back and forth between being inconsistent or consistent with mingw here, and for the time being i've chosen to be consistent.
so if you are using icl x86_64, you'll need to do
./configure --intel --host=x86_64-pc-mingw32 ...
to get it to configure correctly.
(setting the host flag is also required for x86_64 mingw, thus it is consistent)

[[ReX]]

in this situation as the path setup is msys then icl,
you'll need to rename msys's link.exe to something else as it'll interfere with msvc's link.exe
after that you should have minimal issues.

you can also do
start msys.bat
or
\msys\bin\bash --login -i

as other options to get the environment going.

also do note that i've been debating back and forth between being inconsistent or consistent with mingw here, and for the time being i've chosen to be consistent.
so if you are using icl x86_64, you'll need to do
./configure --intel --host=x86_64-pc-mingw32 ...
to get it to configure correctly.
(setting the host flag is also required for x86_64 mingw, thus it is consistent)

Thanks, it worked with start.
One last question, how can I set additional command line parameters for ICC (like /QxSSE4.1 /O3)?

[komisar]

[ReX], --extra-cflags="-QxSSE4.1 -O3"

[kemuri-_9]

[ReX], --extra-cflags="-QxSSE4.1 -O3"

yes, don't use / but - instead for indicating flags.
msvc and icl both support using - or /,
but using / interferes with the file system lookup and you'll get errors in this scenario.

if you need to add flags to link/xilink, that's done via --extra-ldflags="<stuff>"

[schweinsz]

Anybody seen this patch? dated 14 Jan 2010:
http://akuvian.org/src/x264/x264_plane_copy.diff

It would be interesting to see what difference it would make speed wise, combined with aq4 patch of course :)
Don't expect more on this patch, these functions in the diff are not critical time-comsuming functions.
But you can expect that I will improve the x264 on speed greatly after this march.

[Dark Shikari]

Don't expect more on this patch, these functions in the diff are not critical time-comsuming functions.
But you can expect that I will improve the x264 on speed greatly after this march.The function is quite important at fast speeds; it can eat up 6-10% of total time on Ultrafast and seems to have some very bizarre effects on caching, especially with multithreading.

[burfadel]

DS I read your blog after I wrote that, some very interesting stuff coming this year by the sounds of things!

[rack04]

x264_x86_r1400M (http://www.mediafire.com/?q2urywnnzdi)

Toolchain:
gcc-core-4.4.2 (x86.core2.Komisar) (http://komisar.gin.by/mingw/index.html)
Patch:
patch -p1 < /c/x264/nal_hrd_patch_v1.0.diff
patch -p1 < /c/x264/x264_AQ_experiments_v4.diff
Build:
./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: no
ffms input: no
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
fprofiled:
make fprofiled VIDS="/c/x264/parkrun.1280x720.yuv"

[juGGaKNot]

x264_x86_r1400M

x264 --fullhelp >> aa.txt crashes at : --rc-lookahead 60 --ref 16

Makes the text file, 4kb, crashes at that line.

From x264.nl works fine.

[kemuri-_9]

gcc 4.4.3 released, those using 4.4.2 should update (when able).

[VFR maniac]

x264_rev1400M_release2.rar (http://www.megaupload.com/?d=GJ8L8Z6J)

gcc: 4.4.3-dwarf2
pthreads: 2.9.0.0 (autostatic)
ffmpeg: rev21414 (--enable-pthreads)
libswscale: rev30417
ffms2: rev263
gpac: 2010-01-23 UTC
patch:
x264_hrd_pd_interlace.20_r1391.diff (http://pastebin.com/m76f87038)
x264_tcfile_io_v4_r1391.diff (http://pastebin.com/m2b81af43)
x264_thread_pool_v2.5.diff (http://stashbox.org/740452/x264_thread_pool_v2.5.diff)
x264_fgo_r1369.diff (http://www.esnips.com/doc/9f6713d7-8733-4d9b-9ec1-dc952dca893f/x264_fgo_r1369)
x264_AQ_experiments_v4.diff (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
$ ./configure --extra-cflags="-I/usr/local/include -march=core2 -fno-strict-aliasing" --extra-ldflags="-L/usr/local/lib"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

My lavf/ffms compilation guide on MSYS/MinGW32 is here (http://forum.doom9.org/showpost.php?p=1363644&postcount=86).

[bob0r]

pthreads: 2.9.0.0 (autostatic)
gpac: 2010-01-23 UTC

Where do you get those "versions" from?

[VFR maniac]

The latest CVS.
I don't pay attention to their accurate versions.

[burfadel]

ffms2: rev262

Is it possible to get that and later revisions when available from somewhere?

[bob0r]

ffms2: rev262

Is it possible to get that and later revisions when available from somewhere?


svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
configure --enable-gpl --enable-postproc --enable-memalign-hack --cpu=i686 --disable-devices --disable-filters --enable-runtime-cpudetect --disable-encoders --disable-muxers --disable-network --disable-decoder=aac,ac3,adpcm_*,alac,als,ape,atrac?,cook,dca,dsicinaudio,dxa,eac3,flac,interplay_dpcm,mlp,mp1,mp2,mp3,mp3*,mpc?,pcm_*,qcelp,ra_*,sipr,truehd,truespeech,tta,vorbis,wavpack,wma*,twinvq --disable-demuxer=aac,ac3,pcm_*,ape,amr,ass,au,avs,dts,eac3,flac,mp3,mpc,mpc8,truehd,tta,w64,wav,wv --disable-parser=aac,ac3,dca,mlp,mpegaudio
make
make install


ffmpegsource tested with revision: 21414


svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffmpegsource
copy/overwrite: http://x264.nl/CMakeLists.txt to ffmpegsource/
cmake -G "MSYS Makefiles"
make
cp libFFMS2.a /usr/local/lib/
cp include/ffms.h /usr/local/include/


ffmpegsource tested with revision: 263

[VFR maniac]

ffms2: rev262

Is it possible to get that and later revisions when available from somewhere?

You cannot get the latest ffms2.dll somewhere at present.
You can get the latest ffms2.dll by making yourself it.

[techouse]

x264_x86_r1400_QxSSSE3_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x86/x264_x86_r1400_QxSSSE3_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.054, almost unpatched, -QxSSSE3 -O3, fprofiled

x264_x86_r1400_generic_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x86/x264_x86_r1400_generic_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.054, almost unpatched, -O3, fprofiled

x264_x64_r1400_QxSSSE3_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x64/x264_x64_r1400_QxSSSE3_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.054, almost unpatched, -QxSSSE3 -O3, fprofiled

x264_x64_r1400_generic_vanilla_icc_techouse (http://techouse.project357.com/builds/vanilla/x64/x264_x64_r1400_generic_vanilla_icc_techouse.7z)
Intel C++ Compiler 11.1.054, almost unpatched, -O3, fprofiled

Patches used:

x264_intel_support.diff (http://kemuri9.net/dev/x264/patches/x264_intel_support.diff)

---------------------------------------------------------

x264_x86_r1400_QxSSSE3_icc_techouse (http://techouse.project357.com/builds/x86/x264_x86_r1400_QxSSSE3_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x86/x264_x86_r1400_QxSSSE3_icc_techouse.txt)
Intel C++ Compiler 11.1.054, -QxSSSE3 -O3, fprofiled

x264_x86_r1400_generic_icc_techouse (http://techouse.project357.com/builds/x86/x264_x86_r1400_generic_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x86/x264_x86_r1400_generic_icc_techouse.txt)
Intel C++ Compiler 11.1.054, -O3, fprofiled

x264_x64_r1400_QxSSSE3_icc_techouse (http://techouse.project357.com/builds/x64/x264_x64_r1400_QxSSSE3_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x64/x264_x64_r1400_QxSSSE3_icc_techouse.txt)
Intel C++ Compiler 11.1.054, -QxSSSE3 -O3, fprofiled

x264_x64_r1400_generic_icc_techouse (http://techouse.project357.com/builds/x64/x264_x64_r1400_generic_icc_techouse.7z) | INFO (http://techouse.project357.com/nfo/x64/x264_x64_r1400_generic_icc_techouse.txt)
Intel C++ Compiler 11.1.054, -O3, fprofiled

Patches used:

x264_intel_support.diff (http://kemuri9.net/dev/x264/patches/x264_intel_support.diff)
x264_NAL_HRD.10b.diff (http://komisar.gin.by/x.patch/last.used/x264_NAL_HRD.10b.diff)





QxSSSE3 = for Intel Core 2 and newer Intel processor (http://en.wikipedia.org/wiki/SSSE3)
generic = for Intel Core, Intel Pentium 4, Intel Pentium III and AMD processors

[rack04]

x264_x86_r1400M (http://www.mediafire.com/?muuijufzjcv)

Toolchain:
gcc-core-4.4.3 (x86.core2.Komisar) (http://komisar.gin.by/mingw/index.html)
Patch:
x264_hrd_pd_interlace.20_r1391 (http://pastebin.com/m76f87038)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
Build:
march=core2
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled
LAVF/FFMS input:
ffmpeg (http://kemuri9.net/dev/x264/other/ffmpeg.zip)
ffms2 (http://kemuri9.net/dev/x264/other/ffms2.zip)

[kemuri-_9]

LAVF/FFMS input:
ffmpeg (http://kemuri9.net/dev/x264/other/ffmpeg.zip)
ffms2 (http://kemuri9.net/dev/x264/other/ffms2.zip)

woah, i had totally forgotten i had those there...
they're outdated now, so it would be better if you compiled your own versions and used that instead.

[rack04]

woah, i had totally forgotten i had those there...
they're outdated now, so it would be better if you compiled your own versions and used that instead.

Very well. Thanks.

EDIT: When I try to compile ffmpeg using the following:

cd /c/x264/
git clone git://git.ffmpeg.org/ffmpeg/ ffmpeg-src
cd /c/x264/ffmpeg-src/
./configure --enable-gpl --enable-postproc --enable-memalign-hack --enable-runtime-cpudetect --disable-devices --disable-filters --disable-encoders --disable-muxers --disable-network --disable-decoder=aac,ac3,adpcm_*,alac,als,ape,atrac?,cook,dca,dsicinaudio,dxa,eac3,flac,interplay_dpcm,mlp,mp1,mp2,mp3,mp3*,mpc?,pcm_*,qcelp,ra_*,sipr,truehd,truespeech,tta,vorbis,wavpack,wma*,twinvq --disable-demuxer=aac,ac3,pcm_*,ape,amr,ass,au,avs,dts,eac3,flac,mp3,mpc,mpc8,truehd,tta,w64,wav,wv --disable-parser=aac,ac3,dca,mlp,mpegaudio


I get numerous "line 250: pr: command not found" and "line 2791: pr: command not found". Am I missing something?

[kemuri-_9]

missing the pr command which ffmpeg configure uses.

it's part of the msys coreutils ext package: http://sourceforge.net/projects/mingw/files/MSYS%20coreutils/coreutils-5.97-2/coreutils-5.97-2-msys-1.0.11-ext.tar.lzma/download

[rack04]

x264_x86_r1400M (http://www.filedump.net/dumped/x264x86r1400m1264450195.zip)

Toolchain:
gcc-core-4.4.3 (x86.core2.Komisar) (http://komisar.gin.by/mingw/index.html)
Patch:
x264_hrd_pd_interlace.20_r1391 (http://pastebin.com/m76f87038)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
Build:
march=core2
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled
LAVF/FFMS input:
ffmpeg r21450 (http://www.mediafire.com/?0jlzyzy0yio)
ffms2 r263 (http://www.mediafire.com/?ywyjed1nfmm)

[rack04]

svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffmpegsource-src

For some reason when I try to download the latest ffms source is doesn't contain CMakeLists.txt. Has anyone else noticed this?

[kemuri-_9]

svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffmpegsource-src

For some reason when I try to download the latest ffms source is doesn't contain CMakeLists.txt. Has anyone else noticed this?

the build system just flipped from cmake to a configure-based system (e.g. ./configure [opts])

that would be why the cmake stuff no longer exists

[bob0r]

For mingw/msys:
http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/pkg-config_0.23-3_win32.zip
copied: bin/pkg-config.exe to /local/bin/
http://ftp.gnome.org/pub/gnome/binaries/win32/glib/2.22/glib_2.22.3-1_win32.zip
copied: bin/libgio-2.0-0.dll, libglib-2.0-0.dll, libgmodule-2.0-0.dll, libgobject-2.0-0.dll, libgthread-2.0-0.dll to /local/bin/
(probably only libglib-2.0-0.dll needed)

But i get this now:


$ make
Making all in src
Making all in core
CXX audiosource.o
CXX ffms.o
CXX haaliaudio.o
CXX haaliindexer.o
CXX haalivideo.o
CXX indexing.o
CXX lavfaudio.o
CXX lavfindexer.o
CXX lavfvideo.o
CXX matroskaaudio.o
CXX matroskaindexer.o
CC matroskaparser.o
CXX matroskavideo.o
CC stdiostream.o
CXX utils.o
CXX videosource.o
CXX wave64writer.o
LINK libffms2.la
libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries
Making all in index
CXX ffmsindex.o
LINK ffmsindex.exe
ffmsindex.o: In function `main':
F:\msys\1.0\home\xuser\ffmpegsource\src\index/ffmsindex.cpp:244: undefined reference to `CoInitializeEx@8'
F:\msys\1.0\home\xuser\ffmpegsource\src\index/ffmsindex.cpp:278: undefined reference to `CoUninitialize@0'
collect2: ld returned 1 exit status
make[2]: *** [ffmsindex.exe] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1


With cmade it did work, any idea?

Edit: It now works, just:

svn checkout http://ffmpegsource.googlecode.com/svn/trunk/ ffmpegsource
configure
make
make install

Note:
My previous cmake libFFMS2.a: 762 KB (781,302 bytes)
My make libffms2.a: 1.90 MB (2,001,826 bytes)

[Kovensky]

Note:
My previous cmake libFFMS2.a: 762 KB (781,302 bytes)
My make libffms2.a: 1.90 MB (2,001,826 bytes)
configure it with CFLAGS=-O2 CXXFLAGS=-O2 ./configure, or just svn up since they no longer have -g by default.

[rack04]

Nevermind. I got it to work.

[roozhou]

Could someone provide a compiled libffms2.a?

[kemuri-_9]

Could someone provide a compiled libffms2.a?

here's the ffms2 portion of what i use for compiling x264 in both mingw and icl with ffms2 support
ffms2_x86+x64.zip (http://kemuri9.net/dev/avs/ffms2/ffms2_x86+x64.zip)

[rack04]

here's the ffms2 portion of what i use for compiling x264 in both mingw and icl with ffms2 support
ffms2_x86+x64.zip (http://kemuri9.net/dev/avs/ffms2/ffms2_x86+x64.zip)

How did you build x64 using mingw?

[kemuri-_9]

How did you build x64 using mingw?

the same way i did the x86 mingw version except using the x64 compiler?
not really seeing what you're asking...

[rack04]

the same way i did the x86 mingw version except using the x64 compiler?
not really seeing what you're asking...

Sorry. What I meant was what ./configure [opts] to enable x64.

[burfadel]

Kemuri, that ffms2 doesn't want to work in Staxrip... With the version that came with Staxrip works fine, replace the ffms2.dll and ffmsindex.exe, and it says there's no function named ''FFVideoSource".

I tried the filed from the x86 and x64 folder, in case they were around the wrong way (which I highly doubted), no luck.

[rack04]

x264_x86_r1400M (http://www.mediafire.com/?tlentmcfyj2)

Toolchain:
gcc-core-4.4.3 (x86.core2.Komisar) (http://komisar.gin.by/mingw/index.html)
Patch:
nal_hrd_patch_v1.1 (http://pastebin.com/d51413f02)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
Build:
--extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled
LAVF/FFMS input (http://www.mediafire.com/?citmegimzxa)
ffmpeg rev21463
libswscale r30437
ffms2 r269

[burfadel]

Is ffms2.dll needed for x264.exe? Just asking as its missing from that LAVF/FFMS input archive, and Kemuri's link earlier had a ffms2.dll that didn't work with avisynth.

Also, why is the ffmsindex.exe 17MB?! especially since ffmpeg.exe is smaller than others (4mb vs ~10mb)

[LoRd_MuldeR]

Is ffms2.dll needed for x264.exe? Just asking as its missing from that LAVF/FFMS input archive, and Kemuri's link earlier had a ffms2.dll that didn't work with avisynth...

Depends. If x264 was linked against the static lib, then you don't need the DLL. If it was linked against the dynamic lib, then the DLL is needed at runtime.

If in doubt, you can always check the dependencies of an executable with the good old Dependency Walker (http://dependencywalker.com/) utility ;)

[kemuri-_9]

Kemuri, that ffms2 doesn't want to work in Staxrip... With the version that came with Staxrip works fine, replace the ffms2.dll and ffmsindex.exe, and it says there's no function named ''FFVideoSource".

I tried the filed from the x86 and x64 folder, in case they were around the wrong way (which I highly doubted), no luck.

my dlls are avisynth plugins and they are "not" at the same time.
they use the avisynth C interface as this is required by plugins compiled within MinGW as they cannot use the C++ interface due to some incompatibility issues with avisynth being compiled in MSVC.
the C interface is rather non-standard (afaik yadif is the only other plugin that uses the C interface)
i've programmed them to where LoadPlugin("ffms2.dll") returns "use LoadCPlugin", allowing

( LoadPlugin("ffms2.dll") == "Use LoadCPlugin" ) ? LoadCPlugin("ffms2.dll") : NOP()

to load the dlls without interfering with the official builds which are compiled with MSVC and use the C++ interface.

Is ffms2.dll needed for x264.exe? Just asking as its missing from that LAVF/FFMS input archive, and Kemuri's link earlier had a ffms2.dll that didn't work with avisynth.

referring to my own goods,
A) if you used libffms2.a: no
B) if you used libffms2.dll.a: yes
C) if you created a MSVC/ICL import lib using the .def and linked against that: yes

Sorry. What I meant was what ./configure [opts] to enable x64.
sorry, not using the official build system, so couldn't tell you how to do it in it.

[burfadel]

I tried the Loadcplugin method and it didn't work! oh well, just hope the time between easy to work with ffms.dll's isn't too long! (as I'm sure others would agree).

Automated builds like available here for ffmpeg:
http://ffmpeg.arrozcru.org/autobuilds/

Would be very handy! :) but I realise thats just wishful thinking :D

[kemuri-_9]

I tried the Loadcplugin method and it didn't work! oh well, just hope the time between easy to work with ffms.dll's isn't too long! (as I'm sure others would agree).

it would help if you actually stated HOW it didn't work. it seems like people think i have telepathy :/

[burfadel]

I found out why it wasn't working! The problem lies with how staxrip loads the filters. Staxrip automatically adds the loadplugin line above the avisynth script, it doesn't actually show in the programme. When adding Loadcplugin inside the programme itself, it is after the loadplugin command is given. Loadcplugin doesn't work after the plugin is already loaded with loadplugin.

I don't know how to rectify that with Staxrip, using v1.1.4.3

[magnatique]

I am having a strange bug. I used to encode with an older build I had taken with nal-hrd to have Blu-ray compliant files without problem... But I seem to not be able to encode source files larger than 40GB or more right now. I downloaded a few different latest builds without luck.

it goes and starts, but crashes after 20-70 frames. I get similar probs on qtinput of large 40gb prores sources... I just launched from same source avs a encode from megui with default crf16 ultra-fast +fastdecode settings and it seems to be going good...

anyone got some input on how to modify my command to stop crashes while preserving fast fast decoding, bluray compliant?

"C:\Program Files\megui\tools\x264\x264-new.exe" --profile high --level 4.1 --preset fast --tune fastdecode --crf 16.0 --thread-input --deblock -1:-1 --keyint 30 --min-keyint 2 --b-adapt 2 --direct auto --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 40000 --no-mbtree --merange 12 --subme 2 --partitions all --trellis 0 --mvrange 511 --nal-hrd --sar 1:1 --aud --slices 4 --output "v:\encoded\tt030_jeremysommers_patrickkennedy.mp4" "c:\users\encode\Desktop\mp4-run\lagatomp4\tt030_jeremysommers_patrickkennedy.avs"

[roozhou]

@kemuri-_9
Help! How can I link to your libffms2.a using MSVC?

I added libffms2.a to additional dependencies and the linker complains:
unresolved external symbol _FFMS_GetVideoProperties@4 (and more)

Then I changed the line in ffms.h
# define FFMS_CC __stdcall -> # define FFMS_CC __cdecl
This time the linker complains:
module machine type 'x64' conflicts with target machine type 'X86'

[kemuri-_9]

@kemuri-_9
Help! How can I link to your libffms2.a using MSVC?

I added libffms2.a to additional dependencies and the linker complains:
unresolved external symbol _FFMS_GetVideoProperties@4 (and more)

you are using the x86 library with trying to compile a x86 version of x264 with msvc right?

and shouldn't you just compile a static lib version with msvc as ffms already has some slns for msvc?
think you'd only need to change the project type to static lib and drop all the linker comments in libs.cpp...
wrapping the linker statements in

#ifdef _DLL
....
#endif

should work fine for doing that.


Then I changed the line in ffms.h
# define FFMS_CC __stdcall -> # define FFMS_CC __cdecl
This time the linker complains:
module machine type 'x64' conflicts with target machine type 'X86'

do not do this, simply changing the calling convention in the header declaration without recompiling will cause the program to seg fault on using any of the functions due to corrupting the stack.

[roozhou]

you are using the x86 library with trying to compile a x86 version of x264 with msvc right?

Yes, it links OK using GCC.


and shouldn't you just compile a static lib version with msvc as ffms already has some slns for msvc?
think you'd only need to change the project type to static lib and drop all the linker comments in libs.cpp...
wrapping the linker statements in

#ifdef _DLL
....
#endif

should work fine for doing that.

No, it didn't compile.

I changed project type to .lib and added ffmpeg's folder to the include directories. The compiler complained about inttypes.h and stdint.h, so i copied them from x264. Unfortunately the compiler still failed in ffms.h.

Since MSVC can link to libav*.a and libx264.a compiled by gcc, I wonder why it fails with libffms2.a compiled by g++.


do not do this, simply changing the calling convention in the header declaration without recompiling will cause the program to seg fault on using any of the functions due to corrupting the stack.
Does g++ and MSVC use different name mangling?

[kemuri-_9]

Yes, it links OK using GCC.
No, it didn't compile.
I changed project type to .lib and added ffmpeg's folder to the include directories. The compiler complained about inttypes.h and stdint.h, so i copied them from x264. Unfortunately the compiler still failed in ffms.h.

whine at the FFmpegSource thread to get them to add a static solution that'll work then, since only TheFluff and Myrsloik deal with the msvc stuff.

oh right ffms.h automatically adds declspec decorations to the API when compiled within msvc...

you'll need to change line 39 in ffms.h from

# ifdef _MSC_VER

to
something else that would allow static linking... like

# if defined(_MSC_VER) && !defined(FFMS_STATIC_LIB)

defining FFMS_STATIC_LIB in the project settings and also when including ffms.h within x264
or something along these lines


Since MSVC can link to libav*.a and libx264.a compiled by gcc, I wonder why it fails with libffms2.a compiled by g++.

Does g++ and MSVC use different name mangling?

yes they do have different name mangling for C++ functions,
but those functions are included too so they should resolve ok....

for C functions they are the same only for x86.

[rack04]

x264_x86_r1400M (http://www.mediafire.com/?oymawijmjij)

Toolchain:
gcc-core-4.4.3 (x86.core2.Komisar) (http://komisar.gin.by/mingw/index.html)
Patch:
nal_hrd_patch_v1.1 (http://pastebin.com/d51413f02)
x264_AQ_experiments_v4 (http://komisar.gin.by/test/x264_AQ_experiments_v4.diff)
Build:
march=core2
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled
LAVF/FFMS input:
ffmpeg rev21518 (http://www.mediafire.com/?x33amjmz3wi)
ffms2 r272 (http://www.mediafire.com/?m0nljd1j1nz)

[burfadel]

Rack04, any chance of ffms2 builds that include ffms2.dll that can be used with Staxrip/Avisynth? :)

[rack04]

Rack04, any chance of ffms2 builds that include ffms2.dll that can be used with Staxrip/Avisynth? :)

Nope.

[Boulder]

Is it possible to get any extra information from x264 crashing? I've been getting very random unhandled win32 exception crashes with techouse's unpatched x264 ICC build r1400 (QxSSSE3 used).