Intel C Compiler

Intel sells a C++ compiler for Windows, Linux and OS X that is freely available for non-commercial usage. The Linux version of the compiler can be used to compile binaries of MPlayer and FFmpeg that are known to be slightly more optimized speed-wise than binaries compiled with gcc. The Windows version still has some issues.

Caveats

For 32 bit compilation with icc, the following highly optimized SSE2 functions for H264 decoding cannot be used due to stack pointer alignment issues. The functions are deactivated for non-beta versions of icc.

• ff_x264_deblock_v_luma_sse2
• ff_x264_deblock_h_luma_sse2
• ff_x264_deblock_v_luma_intra_sse2
• ff_x264_deblock_h_luma_intra_sse2

A possible fix would be to define a prologue and epilogue for these functions in libavcodec/x86/x86inc.asm that saves, aligns and restores the stack pointer.

FFmpeg

Compilation with icc was tested for the following versions:

11.1

11.1.059 is currently covered by FATE.

11.1 32 bit

Compilation of said sse2 functions is disabled.

11.1.038 (and later) are supported and expected to pass regression tests.

11.1 64 bit

11.1.058 (and later) are supported and expected to pass regression tests.

All versions including 11.1.069 miscompile the function decode_var_block_data() in libavcodec/alsdec.c (Intel issue 583664), possible work-arounds are:

• Pass -parallel to the compilation
• Don't compile alsdec.c with -O3
• Disable optimizations for decode_var_block_data() with #pragma optimize

At least 11.1.038 and earlier versions were known to badly compile the following files if optimization is used (Intel issue 540759):

• libavcodec/h263.c

The function h263_pred_motion() gets miscompiled.

• libavcodec/wmv2dec.c

The functon wmv2_pred_motion() gets miscompiled: A printf() after the initialization of *C shows that mot_val, A[], B[] and C[] often differ from compilation with -O0 while xy and wrap are unchanged.

Artefacts are clearly visible.

• libavcodec/snow.c

The function pred_mv() gets miscompiled.

• libavcodec/h264.c

The function pred_motion() gets miscompiled.

• libavcodec/vc1dec.c

Possible workarounds are to compile these files with -O0, with icc 10.1 or gcc, or put

#pragma optimize ( "", off )

and

#pragma optimize ( "", on )

around the affected functions. With one of these workarounds, regression tests are expected to pass.

Earlier beta versions were not able to compile FFmpeg with optimizations enabled: Compilation of dsputil_mmx.c and cavsdsp_mmx.c failed.

11.0

11.0.083 is currently covered by FATE.

11.0 32 bit

All versions should be supported and are expected to pass regression tests.

11.0.083 is covered by FATE.

11.0 64 bit

11.0.081 and prior versions are known to fail compiling dsputil_mmx.c and cavsdsp_mmx.c with an internal error. This was fixed with 11.0.083.

The same issues as with 11.1.038 exist for all versions, at least including 11.0.084 (Intel issue 540759). This is very unlikely to get fixed.

All versions are known to incorrectly compile vc1_mc_4mv_chroma() in libavcodec/vc1dec.c leading to artefacts when decoding some files (Intel issue 556938). A possible workaround is to compile vc1dec.c with -O0.

10.1

10.1.022 is covered by FATE.

10.1 32 bit

Compiling libavcodec/vorbis_dec.o fails with an internal error if "-parallel" was passed to the compiler. This is Intel issue 583182 and unlikely to get fixed.

Versions prior to 10.1.021 cannot compile the program audiogen (Intel issue 480656), needed for regression tests. A possible workaround is using gcc to compile audiogen:

./configure --cc=icc --host-cc=gcc

To pass the regression tests, the cpu option has to be passed to configure: --cpu=pentium3|pentium4|core2.

10.1 64 bit

All versions should be supported and are expected to pass regression tests. Note that the iccbin binary itself is a 32 bit executable, seemingly causing trouble on some installations.

The function vc1_mc_4mv_chroma() in libavcodec/vc1dec.c is miscompiled, leading to artefacts (for example with the sample from issue 255). This is unlikely to get fixed for 10.1. Possible workarounds are to disable optimization for this function using pragma optimize or compile vc1dec.c with -O0.

MPlayer

The only additional issue MPlayer has is that it is difficult to compile a 32 bit binary with icc on a 64 bit system because MPlayer's configure script does not test what kind of object file the compiler outputs (and icc does not know the option -m32, but has different binaries for 32 and 64 bit).

Windows version

The Windows version of the compiler cannot be used to compile FFmpeg. The main issues are:

• it uses Microsoft's header files and libs, which are not POSIX compliant;
• it does not support ".align" in assembly;
• it does not accept constructs such as

int foo = ({int bar=10; bar;});

which are used by macros in FFmpeg;

• it does not support the MANGLE macro. This gives error messages such as:

error: The direct symbol reference in movq is currently unsupported.  Access symbols through the asm interface.

Some positive points that make it much more attractive than Microsoft Visual C++ for a port effort are:

• it supports C99;
• it accepts at&t style asm.