~22 FPS on Windows (~65 on Mac with same 30 FPS video)…

[Philip George]

Update:

Ok, before we were passing in NULL for the options dictionary in the call to avcodec_open2().

Now were passing in a dictionary:

AVDictionary * options = NULL;
av_dict_set(&options, “b”, “2.5M”, 0);

This was a little sample snippet from one of the headers. It doesn’t seem to change anything.

I’m assuming “b” is bitrate, but is this necessary when decoding? Doesn’t the decoder just work as fast as it possibly can?

It’s not throttling itself in some way is it?

If so, how do I tell it to operate faster?

PG

[Reuben Martin]

Aside from possible differences in what code revision was checkout out when building, I would suspect that the difference in decoding speed is entirely determined by build options, compilers used, and differences between the capabilities of the hardware and OS.

i.e. The code is last place you should be looking in this case.

[Philip George]

It’s a zeranoe build:

Here’s the README:

https://ffmpeg.zeranoe.com/builds/readme/win32/shared/ffmpeg-20120503-git-c1fe2db-win32-shared-readme.txt

Here’s the text:

This is a FFmpeg Win32 Shared build by Kyle Schwarz.

Zeranoe’s FFmpeg Builds Home Page:

This build was compiled on: May 3 2012 11:42:19

FFmpeg version: 2012-05-03 git-c1fe2db
libavutil 51. 49.100 / 51. 49.100
libavcodec 54. 17.101 / 54. 17.101
libavformat 54. 3.100 / 54. 3.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 72.104 / 2. 72.104
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 11.100 / 0. 11.100
libpostproc 52. 0.100 / 52. 0.100

This FFmpeg was configured with:
–disable-static
–enable-shared
–enable-gpl
–enable-version3
–disable-w32threads
–enable-runtime-cpudetect
–enable-avisynth
–enable-bzlib
–enable-frei0r
–enable-libass
–enable-libcelt
–enable-libopencore-amrnb
–enable-libopencore-amrwb
–enable-libfreetype
–enable-libgsm
–enable-libmp3lame
–enable-libnut
–enable-libopenjpeg
–enable-librtmp
–enable-libschroedinger
–enable-libspeex
–enable-libtheora
–enable-libutvideo
–enable-libvo-aacenc
–enable-libvo-amrwbenc
–enable-libvorbis
–enable-libvpx
–enable-libx264
–enable-libxavs
–enable-libxvid
–enable-zlib

This build was compiled with these external libraries:
bzip2 1.0.6:
CELT 0.11.1:
FreeType 2.4.8:
Frei0r 20111008-git-16cfe66:
LAME 3.99.5:
libass 0.10.0:
libgsm 1.0.13-3:
Theora 1.1.1:
Vorbis 1.3.2:
libvpx 1.0.0:
NUT 20110326-git-5e471c2:
OpenCORE AMR 0.1.2:
OpenJPEG 1.5.0:
RTMPDump 20120308-git-7340f6d:
Schroedinger 1.0.11:
Speex 1.2rc1:
Ut Video 10.2.4:
VisualOn AAC 0.1.2:
VisualOn AMR-WB 0.1.2:
x264 20120119-git-da19765:
XAVS svn-55:
Xvid 1.3.2:
zlib 1.2.6:

The source code for this FFmpeg build can be found at:

This build was compiled on Debian (64-bit):

This build was compiled with the MinGW-w64 toolchain:

License files for each library can be found in the ‘licenses’ folder.

[Philip George]

SOLVED
——

[Sorry, I posted the wrong solution before.]

There actually was no problem. We were taking our timing measurements at the wrong points.

We were effectively measuring two things instead of just one:

1 – FFmpeg’s decode function

2 – Conversion from YUV to RGB (our own code)

… and our YUV to RGB functionality — which relies heavily on two inline functions — wasn’t getting inlined by the Visual Studio compiler, when building the Debug build:

On a Mac in Xcode, when building a Debug build, the setting for inline functions actually being unrolled is set (ie: inlines are properly inlined, even in Debug builds [by default]).

However, in Visual Studio, inlines are not unrolled **by default** in Debug builds.

Enabling inline function unrolling in the Debug build settings of our project fixed the problem.

Now the Windows build is performing as well as the Mac build.

… The bigger point to take from this is just that we were measuring too much activity and not just the FFmpeg decode function itself.

FFmpeg was performing fine all along.

One of our own project settings (as it related to our own code) was what was causing the long delay.