Investigate about building FFmpeg with the Visual Studio compiler

[Ceylo]

http://vimeo.com/69111871

[feliwir]

current build_ffmpeg.sh requires visual studio to be a standard installation (line 125) Suggested fix: optionally pass msvc installation dir to the script

[Ceylo]

I agree with your comment, but this is off-topic for the current issue, which is about compiling FFmpeg through Visual Studio rather than GCC. Please create a new issue for this :)

[bluekirby0]

Honestly, if ffmpeg builds with express versions of MSVC 2013 there is little reason to support a different configuration. The v12 and v12_xp runtimes are ABI-compatible back to vc9 as far as I have seen (just remember to use v12_xp if you plan to distribute software that will run on Windows XP/Server 2003/Home Server).

The only downside I see is that fewer people are likely to already have the runtime libraries installed already for 2013 as opposed to 2010/2012, but that is bound to change soon with the added std::shared_ptr and C99 support added in 2013 (both very coveted features that have been missed by the cross-platform developer community), among other C++11 things that have been slipped in.

[Ceylo]

What is the vc12_xp runtime? I don't find much on it when googling.

As for building with VS2013, the main drawback I see in the tutorial is that is still requires installation of MSYS, so this is not completely for free. On the other side, it allows building without MinGW and without using Windows cmd, plus it may give the ability to use FFmpeg as static libraries on Windows with MSVC (there were issues with missing entry points when using static FFmpeg built with MinGW in Visual Studio).

[bluekirby0]

The vc12_xp runtime is just a runtime library that got added after 2013 was originally released to allow building executables that can run in Windows XP environments. You select it as your toolset in your general project configuration. The default toolset for new projects is vc12 (programs built with this runtime will not even be seen as executable on systems older than Vista/Server 2008).

You misunderstand the tutorial, somewhat. It is to show you how to build with versions PRIOR to MSVC 2013. You can tell because of the C99-to-C89 wrapper being used in it (2013 supports C99 directly). I have not tried building ffmpeg in 2013 yet but it should be a fairly straight-forward process now.

EDIT: My apologies...you can get a better idea if you do a search for v120_xp which is the proper name of the platform toolset.

[Ceylo]

As for the need of MSYS, I was refering to the need of running the configure script and make, even if the selected toolchain is VS2013. How do you do this if you do things with VS2013 only as FFmpeg's build system is based on (apparently) autotools?

[bluekirby0]

I was mistaken...it would require setting up an entirely different build system (which isn't feasible). You can, however, get the required bash environment to build with MSVC 2013 down to just over 10 MB (maybe smaller if you trim out some of the common *nix tools, but they might come in handy later when extending the build system).

[Ceylo]

Is such environment the one you're working on?

[bluekirby0]

Yes, and I have it working now except for the space bug you ran into before (I really wanted ffmpeg to be built inside the cmake build directory, so I'm investigating possible fixes for that).

[bluekirby0]

Progress on this discussed in issue #42

[Ceylo]

To continue on this topic in the right thread. You've used a symbolic link to avoid filling the C drive with YASM and FFmpeg sources. Recently when setting up Continuous Integration with Jenkins, I found out that the current build system in origin and in your fork do now allow building sfeMovie several times for different configurations at the same time. This is because after one FFmpeg build is done, it cleans the temporary directory, but this temporary directory may be used by another build in the meantime! The same applies when launching a new build: it overwrites the files in the temporary directory.

So whatever the build systems, it would need some unique naming.

[bluekirby0]

Am I to take it then that my fork is actually building on non-msvc targets? I haven't had much chance to test this so that would be welcome news.

Hmm...that presents an interesting problem...I suppose the temp folder name can be altered based on the target system (or with a random value if target system is too vague)

[Ceylo]

No I did not try your fork yet. Currently the CI builds sfeMovie fine with GCC on Linux, Clang on OS X and VS2013 on Windows. The main issue I have at the moment with OS X is that the Internet connection :confused: I still have to add MinGW, which will allow me to test your fork. You can check it out at https://yalir.org:8080 if you're interested.

Relying on the target system to create the temporary folder name would not be enough: the current build matrix on Jenkins can build sfeMovie with either "Free" and "All" decoders. In this case the target system is the same. I don't know if unique number generators are available through CMake though.

[firefly2442]

I don't know if unique number generators are available through CMake though.

RANDOM was the only thing I could find for unique strings. http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:string

[Ceylo]

Indeed, although I don't know if it is good enough though: you need a seed (usually the time), but two builds could start at the same time and in this case the generated string wouldn't be unique anymore. It's not possible either to check if the directory already exists because it can be created by other builds between the moment you check for it and create it. We would need some kind of locks for files.

I wonder whether we can still simply use the random name generation though, as there are low probabilities of starting at the same millisecond. There would probably be very few failures cases because of that.

Or another simple solution is to let the Jenkins slaves build sfeMovie only one at a time. But this doesn't fix user cases.

All of that because FFmpeg doesn't like paths with spaces!!! :rage:

[bluekirby0]

How about something like Ffmpeg-platform-arch-toolchain-gitcommithash For naming? I do not know what kinds of simultaneous builds might be occurring on a regular basis but if you get that specific and there are still collisions then I do not know how such an operation could be useful.

i.e. Ffmpeg-win-x86_64-msvc12-c4e03fd3cfd05dac0e6e2c3997248814db1c278b

Also, HTTPS is broken on your server. Have not looked into why. Probably a self signed certificate.

[Ceylo]

It could indeed, although I don't think the commit hash can be used because the user may not have it if he just downloaded an archive of the repo. I don't think this is priority though so I've created an issue not to forget this: #53

As for HTTPS, I actually have a correctly signed certificate from "Gandi Standard SSL CA". I have looked on the Internet and I found out I may need to give my server the CA certificate. I did this for the main website, but not for the Jenkins embedded server because I don't know how yet. Gandi's website also states that providing the CA certificate is only required by pre-2010 browsers. Are you in this case?

http://wiki.gandi.net/en/ssl/intermediate

Can you also confirm that you can access https://yalir.org/ without any warning?

[Ceylo]

I have moved Jenkins behind Apache at https://yalir.org/jenkins Do you still get a warning?

Edit: moved back to the old URL because putting Jenkins behind Apache prevents slaves from connecting... could not get it to work for now..

[bluekirby0]

I can access yalir.org via HTTPS without problems. Using chrome for android and it is up to date.

[Ceylo]

Ok so the only difference is indeed the CA certificate. I'll see if I can find a way to provide it with Jenkins embedded server. Is everything fine with your desktop browser?

[bluekirby0]

Looks fine on my desktop chrome.

[Ceylo]

To give some news on this topic:

I've decided to put this task at top priority after seeking is finished, because I want to get rid of MinGW. I only get problems with it:

• additional DLLs to be provided
• several incompatible distributions (and SFML doesn't use the one from mingw.org anymore)
• latest MinGW from mingw.org is unable to build FFmpeg due to name conflicts

So put simply I want to stop support for MinGW builds and do MSVC builds without MinGW.

To do so I plan the following:

• put YASM as an external dependency
• rely on MSYS or MSYS2 for Bash (by the way MSYS2 can provide YASM through its package manager :) )
• use part of bluekirby's work to get it done

In the end that should let us focus more on development than MinGW issues and should allow fully static builds of sfeMovie even for MSVC.

[Ceylo]

Merged into master through pull request https://github.com/Yalir/sfeMovie/pull/88