PDA

View Full Version : bundled ffmpeg isn't multithreaded



RMerlin
07-23-2010, 02:38 AM
Hi,

The version of ffmpeg bundled with Mezzmo 2.1.8 isn't multithreaded (or at least the libx264 library linked with isn't).

I modified a device profile to use -threads 8 (default was -threads 4). This is my CPU usage (i7 860: 4 phy cores + 4 HT threads) while transcoding using the Conceiva bundled ffmpeg:

http://www.lostrealm.ca/temp/conceiva-ffmpeg.png

This one is while using a static build from http://ffmpeg.arrozcru.org/autobuilds/ :

http://www.lostrealm.ca/temp/mt-ffmpeg.png

The test was done with the same sample file in both case (an MPEG2 AC3 being transcoded to libx264 and AC3)

On a related subject, a suggestion: add an option to Mezzmo to determine the number of threads to use, and pass that information to ffmpeg instead of hardcoding it into device profiles. I would suggest querying the PC to determine how many CPU threads are supported by the computer, then offer the user to select between 1 and the number of threads available, with the addition of "Auto" (as the default option), which would automatically pass the maximum number of threads to ffmpeg.

Paul
07-23-2010, 08:43 AM
Yes, the previous one wasn't multithreaded either. We'll need to re-build FFmpeg with pthread support (instead of the current w32threads) to enable multithreading for libx264, but it presents a bunch of problems with static linking (which we use for our FFmpeg builds), so this hasn't been done yet (there needs to be some patching first AFAIK). This is something we plan to do really soon and I'd be happy to provide you with a multithreaded-enabled build before the official release.

Of course transcoding to other formats is still multithreaded (if the format supports that).

We do query the processor to determine its capabilities, but we use that to limit the maximum number of simultaneous transcodings going on. I agree that it would be better to utilize this on the FFmpeg level as well, once a proper multithreaded build is available.

RMerlin
07-23-2010, 08:58 AM
Hi Dennis,

The build I'm using with multithreading is also statically linked, and has been working well for me since I started using it a few months ago. They use mingw32 for their compile environment (maybe that's the main difference between your own toolchain and theirs). Here's the compile options (in case it might help you):



built on Jul 17 2010 04:19:43 with gcc 4.4.2
configuration: --enable-gpl --enable-version3 --enable-libgsm --enable-pthreads
--enable-libvorbis --enable-libtheora --enable-libspeex --enable-libmp3lame
--enable-libopenjpeg --enable-libschroedinger --enable-libopencore_amrwb
--enable-libopencore_amrnb --enable-libvpx --arch=x86 --enable-runtime-cpudetect
--enable-libxvid --enable-libx264 --extra-libs='-lx264 -lpthread' --enable-librtmp
--extra-libs='-lrtmp -lpolarssl -lws2_32 -lwinmm' --target-os=mingw32
--enable-avisynth --cross-prefix=i686-mingw32- --cc='ccache i686-mingw32-gcc'
--enable-memalign-hack
libavutil 50.22. 0 / 50.22. 0
libavcodec 52.83. 0 / 52.83. 0
libavformat 52.74. 0 / 52.74. 0
libavdevice 52. 2. 0 / 52. 2. 0
libavfilter 1.22. 0 / 1.22. 0
libswscale 0.11. 0 / 0.11. 0


AFAIK these builds are based on SVN snapshots so I doubt they had to patch anything (since it's automatically done every night). Might be worth investigating when you get down to looking at this.

Paul
07-23-2010, 09:02 AM
Thanks for the info.

We use mingw32 as well and also build from SVN, but if it's done as-is, the build fails. Patching can be applied automatically, so I don't know for sure whether they patch or not, but it's something that I'll be looking into very soon. Perhaps the additional configuration options such as cross-compiliing will allow it to build.

I build FFmpeg at least once a week to check up on outstanding transcoding failure issues (as well as monitoring their bugtracker almost daily for changes), so we try to keep on top of things as much as possible here ;)

Fronobulax
09-18-2010, 08:42 PM
Any update on this?

Paul
09-20-2010, 08:42 AM
Yes, the next update of Mezzmo (2.1.10) will included a multi-threaded FFmpeg build so that x264 encoding will be faster (most advantages are in this area).