Closed levicki closed 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
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:
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.
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.
@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.
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.
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.
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:
However, msvc-config.h does not even mention this setting.
If you don't define it you get this:
If you do define it, you get this:
Only if you edit libs.cpp to contain the following:
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.