[FFmpeg-devel] mutlithreading in ffmpeg?

Frank Barchard fbarchard at google.com
Tue Mar 29 03:26:07 CEST 2011

On Sat, Mar 26, 2011 at 4:14 AM, Michael Niedermayer <michaelni at gmx.at>wrote:

> On Fri, Mar 25, 2011 at 06:57:37PM -0700, Frank Barchard wrote:
> > On Sat, Mar 19, 2011 at 5:09 AM, Reimar Döffinger
> > <Reimar.Doeffinger at gmx.de>wrote:
> >
> > > On Fri, Mar 18, 2011 at 06:02:08PM -0700, Frank Barchard wrote:
> > > > I think theres a minor bug in ffmpeg-mt theora too.  Its reproducible
> in
> > > > webkit layout tests.  It doesn't happen in ffmpeg.
> > >
> > > Frame-multithreaded decoding for theora is already in FFmpeg AFAIK...
> > >
> >
> > You'll need to try Fate with and without threading to detect the
> difference.
> >
> > I gave ffmpeg threading a quick try on Windows, but the configure script
> > doesn't support static pthreads.
> > I'll try again with the patch
> >
> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches/to_upstream/01_static_pthread_O2.patch?revision=65546&content-type=text%2Fplain
> This patch looks like it would break if libavcodec would be linked
> with an application that itself also used static pthreads

libpthreadGC2.a will statically link into avcodec-52.dll.
Its okay to also link libpthreadGC2.a into an application.
The static pthread link step is not applicable to the static ffmpeg
This is only for Windows - pthreads come with OSX and Linux.  It reduces
download/startup time having 1 less DLL (by about 75 ms)
(The O2 part of this patch also reduces download/startup time, but is a
mixed blessing on decode performance.  Faster on Pentium4, slower on Atom,
about the same on Core.  But its substantially smaller, helping download
time and startup time on all CPUs.  I'd prefer we use O2 and manually
inline/unroll when its a win)

Applying 01_static_pthread_O2.patch<http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patches/to_upstream/01_static_pthread_O2.patch?revision=65546&content-type=text%2Fplain>
to head ffmpeg, configure shows:
threading support         pthreads

Performance scales up as expected:
Caveat: the following numbers are inaccurate, as I'm doing some compression
at the same time
>media_bench --stream=video --video-threads=1 tulip2.mp4
        FPS:     127.36
>media_bench --stream=video --video-threads=2 tulip2.mp4
        FPS:     224.08
>media_bench --stream=video --video-threads=8 tulip2.mp4
        FPS:     706.86

And Theora looks good:
>media_bench --stream=video --video-threads=8 tulip2.ogv
        FPS:    1365.54

vp8 using libvpx slice threading, which works, but not as well:

>media_bench --flush --stream=video --video-threads=1 tulip2.webm
        FPS:     249.84
>media_bench --stream=video --video-threads=8 tulip2.webm
        FPS:     480.38

MT-style frame level multithreading for vp8 would do alot better.

More information about the ffmpeg-devel mailing list