FFMS / ffms2

An FFmpeg based source library and Avisynth/VapourSynth plugin for easy frame accurate access
Other
579 stars 105 forks source link

MSVC build for release 2.22 is broken #272

Closed levicki closed 7 years ago

levicki commented 7 years ago

I downloaded 2.22 source tarball and tried building it using MSYS with MSVC toolchain.

First problem I faced was ./configure of ffmpeg failing to find opencore-amr libs if work directory is /home/user/ instead of absolute path with drive letter (i.e. c/some/folder/).

Maybe it would be easier if this was mentioned somewhere in the INSTALL or README?

Second problem is that after successfully building deps building solution in Visual Studio out of the box didn't work because of unresolved externals. Again it is not documented anywhere in the tarball that you need to uncomment defines for opencore-amr in msvc-config.h.

Third problem is that there is no mention which avisynth release headers are needed.

Fourth problem is that libs.cpp has the following code:

#ifdef WITH_SWRESAMPLE
#pragma comment(lib, "libswresample.a")
#else
#pragma comment(lib, "libavresample.a")
#endif

However, msvc-config.h does not even mention this setting.

If you don't define it you get this:

1>libavcodec.a(opusdec.o) : error LNK2019: unresolved external symbol swr_alloc referenced in function opus_decode_init
1>libavcodec.a(opusdec.o) : error LNK2019: unresolved external symbol swr_init referenced in function opus_init_resample
1>libavcodec.a(opusdec.o) : error LNK2019: unresolved external symbol swr_is_initialized referenced in function opus_decode_frame
1>libavcodec.a(opusdec.o) : error LNK2019: unresolved external symbol swr_free referenced in function opus_decode_close
1>libavcodec.a(opusdec.o) : error LNK2019: unresolved external symbol swr_close referenced in function opus_decode_flush
1>libavcodec.a(opusdec.o) : error LNK2019: unresolved external symbol swr_convert referenced in function opus_decode_frame
1>C:\WORK\IVANA\2016\ffms2-2.22\build-msvc\bin\x64\Debug\ffms2.dll : fatal error LNK1120: 6 unresolved externals

If you do define it, you get this:

1>audiosource.obj : error LNK2019: unresolved external symbol avresample_alloc_context referenced in function "public: __cdecl unknown_size<struct AVAudioResampleContext,&struct AVAudioResampleContext * __cdecl avresample_alloc_context(void),&void __cdecl avresample_free(struct AVAudioResampleContext * *)>::unknown_size<struct AVAudioResampleContext,&struct AVAudioResampleContext * __cdecl avresample_alloc_context(void),&void __cdecl avresample_free(struct AVAudioResampleContext * *)>(void)" (??0?$unknown_size@UAVAudioResampleContext@@$1?avresample_alloc_context@@YAPEAU1@XZ$1?avresample_free@@YAXPEAPEAU1@@Z@@QEAA@XZ)
1>audiosource.obj : error LNK2019: unresolved external symbol avresample_open referenced in function "public: void __cdecl FFMS_AudioSource::SetOutputFormat(struct FFMS_ResampleOptions const &)" (?SetOutputFormat@FFMS_AudioSource@@QEAAXAEBUFFMS_ResampleOptions@@@Z)
1>audiosource.obj : error LNK2019: unresolved external symbol avresample_free referenced in function "public: __cdecl unknown_size<struct AVAudioResampleContext,&struct AVAudioResampleContext * __cdecl avresample_alloc_context(void),&void __cdecl avresample_free(struct AVAudioResampleContext * *)>::~unknown_size<struct AVAudioResampleContext,&struct AVAudioResampleContext * __cdecl avresample_alloc_context(void),&void __cdecl avresample_free(struct AVAudioResampleContext * *)>(void)" (??1?$unknown_size@UAVAudioResampleContext@@$1?avresample_alloc_context@@YAPEAU1@XZ$1?avresample_free@@YAXPEAPEAU1@@Z@@QEAA@XZ)
1>lavfaudio.obj : error LNK2001: unresolved external symbol avresample_free
1>audiosource.obj : error LNK2019: unresolved external symbol avresample_convert referenced in function "public: void __cdecl FFMS_AudioSource::ResampleAndCache(class std::_List_iterator<class std::_List_val<struct std::_List_simple_types<struct FFMS_AudioSource::AudioBlock> > >)" (?ResampleAndCache@FFMS_AudioSource@@QEAAXV?$_List_iterator@V?$_List_val@U?$_List_simple_types@UAudioBlock@FFMS_AudioSource@@@std@@@std@@@std@@@Z)
1>C:\WORK\IVANA\2016\ffms2-2.22\build-msvc\bin\x64\Debug\ffms2.dll : fatal error LNK1120: 4 unresolved externals

Only if you edit libs.cpp to contain the following:

#pragma comment(lib, "libswresample.a")
#pragma comment(lib, "libavresample.a")

You get it to build without errors, but I am not sure if that was supposed to work that way? I'd appreciate if you can clarify.

Finally, ffms2-2.22-msvc.7z references specific ffmpeg commit cf28490 in the COPYING file which I am not mistaken is referencing ffmpeg 2.8. Current release version of ffmpeg is 3.1.4 so this may also affect the ability of people to reproduce your binary build for a specific release -- in my opinion build-win-deps.sh should checkout the specific version of dependencies, not just do a hard reset to origin/master.

kblomster commented 7 years ago

I guess it was kind of assumed by default that nobody who wasn't already three feet deep in this insanity would ever try to build it on Windows since there's rarely any reason to do so, so the build process is mostly not documented, or incorrectly documented, and any problems you run into are for you to solve. People mostly turn up to complain on IRC if shit's broken.

That really doesn't mean it shouldn't be fixed, though. It would be nice to have more contributors and this dumb and rather easily fixed documentation issue certainly isn't helping with accessibility - it's already a pain to just build the dependencies on Windows. I think @dwbuiten was considering taking a stab at it. Or feel free to submit a patch.

edit: also I don't think the MSYS build gets tested much these days, I think people prefer building ffmpeg with Visual Studio now

levicki commented 7 years ago

Your "three feet deep in insanity" comment made me laugh yesterday (because I subconsciously converted it into metric units while reading it), so thanks for that :-)

I don't use IRC, so this was the only way of "complaining". The reason I am putting that word under the quotes is because I have solved the problem for myself so I don't expect any actions to be taken by the FFMS2 team. I already have some bad experience from reporting open-source bugs and issues, and I have learned not to expect anything (except arrogance and condescension which seem pretty universal in OSS communities for some reason), but I still report them for the sake of others who might stumble upon them.

I could try submitting a patch. However, I don't have enough experience with GitHub and git when it comes to projects with more than one person working on it so maybe it would be more efficient if I submitted it via email?

I propose the following changes:

  1. Creating a file INSTALL-WIN where we would put the instructions on building the dependencies and the Visual Studio solution itself.
  2. Modifying build-win-deps.sh to checkout the particular commit of ffmpeg and opencore-amr so that release builds of FFMS2 can be reproducible by everyone. Perhaps having an option to also use the origin/master?
  3. Modifying libs.cpp to fix swresample / avresample dependencies -- this depends on your answer whether it is expected / normal for both of them to be needed? I was under impression that only one of them should be used? Maybe FFMS2 code referencing the functions from those libraries should be changed instead? Please clarify.
  4. Fixing project file for Visual Studio (minor bug, release build for x64 does not build ffmsindex.exe by default -- it is not selected for build).

As for MSYS and ffmpeg -- I was not aware that you can build ffmpeg from Visual Studio? Do they now provide project / solution files? I used MSYS but with MSVC toolchain. Please clarify.

Finally, it would be nice if there was also an option to build FFMS2 with ffmpeg, opencore-amr, and zlib as shared libraries to save space / avoid code duplication in projects which use FFMS2 for decoding and ffmpeg for encoding -- they could use the same shared build of ffmpeg for this.

Please let me know your thoughts.

myrsloik commented 7 years ago

Basically the idea is to release 2.23 in a week or so and then prune the shit out of the whole project. That's why none of us really care. After those 2.23 binaries go out it will be a literal codebath and only one true configuration shall remain. Most likely msys+vs2015 recent ffmpeg.

levicki commented 7 years ago

@myrsloik Do you mean release 2.23 with the (hopefully trivial) fixes I mentioned above, or do you mean release 2.23 and do a major cleanup post-release? Please clarify.

I would also like to point out that many people, both personally and at work are still using Visual Studio 2013 update 5 due to their licensing model or client requirements. In my opinion this should still be supported in addition to VS2015 (i.e. the project should not depend on VS2015 specific features), because people using commercial software have a real, significant cost of upgrade that goes beyond simple project file conversion. On the other hand, changing gcc version usually costs you only some of your time to install.

Finally, could someone please clarify avresample/swresample thing? I would really appreciate it.

myrsloik commented 7 years ago

After release. No more code will be touched before release I think. Unless huge wild regressions appear.

I have no idea how it's supposed to be with sw/avresample. FFmpeg has one and libav has another so you just define that to match. I can never remember which one is which.

I have a real significant cost of doing testing too. And I don't just mean my sanity, I could be spending quality time with my favorite guinea pig in the whole world instead. Not going to do your job for free. I also didn't see the part where you promised to pass on some of the corporate savings to this project in return. Patches welcome if you care. Pull requests preferred. Tab indentation only or we complain.

Also, clang-cl which renders most your objection even more pointless.

levicki commented 7 years ago

Wow...

Such a dickish, arrogant, non-answer has fully met my expectations.

You also managed to twist and misunderstand most of what I said.

If this is how you welcome people who show interest in your project no wonder nobody wants to contribute.

Sorry for wasting your precious time. Please go back to your guinea pig, I don't want you to feel alone once you manage to drive away all the humans with your elite social skills.

Sent from my iPhone

On Oct 9, 2016, at 17:05, Fredrik Mellbin notifications@github.com wrote:

After release. No more code will be touched before release I think. Unless huge wild regressions appear.

I have no idea how it's supposed to be with sw/avresample. FFmpeg has one and libav has another so you just define that to match. I can never remember which one is which.

I have a real significant cost of doing testing too. And I don't just mean my sanity, I could be spending quality time with my favorite guinea pig in the whole world instead. Not going to do your job for free. I also didn't see the part where you promised to pass on some of the corporate savings to this project in return. Patches welcome if you care. Pull requests preferred. Tab indentation only or we complain.

Also, clang-cl which renders most your objection even more pointless.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.