VS build is slower

[shiftmediaproject]

VS build is slower

[Dan203]

This is what I use to use for MinGW build....

CXXFLAGS=-D__STDC_CONSTANT_MACROS ./configure --disable-doc --disable-outdevs --disable-static --enable-shared --disable-ffplay --disable-ffserver --enable-memalign-hack --enable-w32threads --enable-zlib --cpu=i686

[Sibras]

I assume your comparing the Release configurations speed as opposed to the debug configuration (the debug is the default configuration)?

There are some differences in a few cases as old code in the ffmpeg user base sometimes has inline assembly code that is not supported by msvc compiler. All the more recent code uses nasm as an external assembler to support assembly optimisations so as long as you project uses nasm for assembly youll get all the latest optimisations. It is however possible that an older codec such as mpeg2 still uses the older inline asm and hasnt been updated due to its age. If you use a more recent encoder you should see near identical performance, if not then that would require additional investigation.

[Dan203]

Is there any way to get that inline assembly code to compile in VS? Using the Intel encoder maybe? Our main purpose for using VS over MinGW was being able to add breakpoints to the ffmpeg code when we were having issues, but we rely on that MPEG-2 encoder and can’t use it if it's 1/2 the speed.

[Sibras]

The intel compiler does support the inline assembly and FFVS supports creating projects for icl.

[Dan203]

I've been doing some testing and the VS build is slower in other areas too. I was testing all the decoders and the MinGW build is faster in every test. Something weird is going on. I'm going o download the trial for the Intel compiler and see if it makes a difference.

[Sibras]

You may also want to try testing against the precompiled binaries at https://github.com/ShiftMediaProject/FFmpeg/releases to see if there is a difference there.

[Dan203]

Good idea. I'll try that too just to be sure

[Sibras]

Did you end up reproducing the speed issues with the precompiled binaries? If not ill close this issue.

[Dan203]

I got pulled away on another project so I couldn’t finish all my testing. But the precompiled binaries did not have the speed issues. However the one we compiled, using your project generator and VS2019, does. And I have no idea why. Same code compiled in mingw is faster so we're just using that for now. I plan to revisit this eventually but I'm busy on another project right now.

[Sibras]

Well the precompiled binaries are using the supplied VS projects with any modification. Double check and make sure that you are using one of the Release Configurations and your not accidentally comparing it to a debug build.

[Dan203]

We're using a custom build script and your project generator, not your published project files. We need a custom build because we're using this in a commercial app and can only use the LGPL stuff. We also need zlib support because we have customers who edit MP4 files with compressed headers.

It's been a couple years since I generated the projects, so maybe you've fixed something since then. It was just a big process, and I need to remember how exactly to do it, so I haven’t had time to start over and do it again. I'm hoping that's all it is. But if not I'll start a new bug if you close this one.

[Sibras]

Closing this for now.
For reference if all you want is lgpl with zlib then you can use FFVS with the command line "--enable-lgpl --disable-autodetect --enable-zlib" then just build one of the desired release configurations in the generated VS projects.