[FFmpeg-devel] Experimental MSVC port

[Ramiro Polla]

Hello,

Ole Andr? Vadla Ravn?s <oleavr <at> gmail.com> writes:
> FWIW, for those of you interested in building a somewhat semi-recent ffmpeg,
> r11247 (the revision currently suggested by GStreamer's gst-ffmpeg) with
> MSVC15, I've ported and included it in OABuild:

Great, you've ruined what I had been planning to do for SOC this summer =)

Here is what I had written up this morning:
Porting FFmpeg to MSVC is not *that* hard. But making a maintainable port is.
The intention on this project is to clearly define what changes are needed
to make FFmpeg work and pass regression tests with MSVC, and stop all
the FUD around MSVC. Well, not all FUD, but most.
The 2008 Express edition has been released and it still
contains the most well-known problems:
- Does not understand named initializers;
- Does not understand variable-length arrays;
- Does not understand the inline keyword (understands _inline though);
- Does not allow explicit divisions by 0.0;
- Does not understand compound litterals;
- Does not understand AT&T style asm;
- Probably others. I gathered this info from libavutil and some other
  problems I remembered.
Some of these changes shouldn't have any effect on gcc optimized code, like:
instead of
init_multbl2(dec_multbl[0], (int[4]){0xe, 0x9, 0xd, 0xb}, log8, alog8, 
inv_sbox);
something like
const int someconst[4] = {0xe, 0x9, 0xd, 0xb};
init_multbl2(dec_multbl[0], someconst, log8, alog8, inv_sbox);
 
Changes that either slow down C99 code or make the binary bigger are
obviously not welcome. The same goes for changes that bloat the source code.
(what people consider bloat varies wildly, but I hope we can reach a 
consensus).
 
For asm, rewrite the inline into Intel-syntax under #ifdef.
 
For the build system, use the same gcc calling syntax. I believe only 
configure would
have to be changed (+ some other stuff in the Makefiles like using
normal gcc for i386/).
 
Missing POSIX functionality can be obtained from libmingwex, so there won't be 
any need
to port them again. There should be no more Win32 code than there already is.
 
The changes that are absolutelly unnaceptable for FFmpeg SVN inclusion
could be kept in an MSVC patches folder, that I intend to maintain (help is 
always
welcome, of course). The patches would be related to what they fix (such as
00_division_by_0.0.diff), and not per file. I imagine maintaining it would 
just be
updating line numbers from time to time, and fixing any new code that
comes in.
 
As for a mentor, we don't have one yet, but I suggest someone who has already
done a complete port, like Steve Lhomme, the folks at ffdshow, etc. Whoever has
already done this, please speak up.

Note: I don't like MSVC much more than gcc, but at least MSVC shows it still
optimizes very well, and doesn't follow the "inverse proportional relation 
between
version number and performance which was so nicely followed since [gcc] 2.95"
 
Ramiro Polla