[FFmpeg-devel] [RFC] Removing non-pthreads support

Ramiro Polla ramiro.polla
Tue Apr 20 04:19:09 CEST 2010


2010/4/19 M?ns Rullg?rd <mans at mansr.com>:
> FFmpeg currently supports four different threading libraries:
> pthreads, beos, win32, and OS/2. ?I suspect most people already use
> pthreads, and all the relevant operating systems seem to have a
> pthreads implementation, even OS/2. ?I'm not sure about old BeOS, but
> I doubt anyone is still using that, much less with threads.
>
> To ease the maintenance burden, I suggest we drop support for all but
> pthreads in FFmpeg. ?If there is a compelling reason for keeping any
> of the others, please speak up now.

What's the best way to test threads performance? I tried mpeg4 encoding with:

ffmpeg_g.exe -i SP.S14E05.avi -an -y -vcodec mpeg4 -threads x
-benchmark 2 -f mpeg NUL

I added the option -benchmark 2 to fall back to using av_gettime().
Otherwise Windows would sum up all threads' times and that's pretty
useless for this test.

running in cmd.exe, on a macbook 4.1. Windows XP SP3.
Intel(R) Core(TM)2 Duo CPU
T8300 @ 2.40GHz

input file:
  Duration: 00:21:45.64, start: 0.000000, bitrate: 1126 kb/s
    Stream #0.0: Video: mpeg4, yuv420p, 624x352 [PAR 1:1 DAR 39:22],
23.98 tbr, 23.98 tbn, 23.98 tbc

pthreads
x=1
bench: utime=67.250s maxrss=13384kB
bench: utime=67.266s maxrss=13384kB
bench: utime=67.203s maxrss=13384kB
bench: utime=67.219s maxrss=13384kB
bench: utime=67.312s maxrss=13384kB
67.2500
42.632e-3

x=2
bench: utime=45.250s maxrss=13640kB
bench: utime=45.328s maxrss=13640kB
bench: utime=45.281s maxrss=13640kB
bench: utime=45.328s maxrss=13640kB
bench: utime=45.281s maxrss=13640kB
45.2936
33.857e-3

x=3
bench: utime=50.078s maxrss=13788kB
bench: utime=50.125s maxrss=13788kB
bench: utime=50.219s maxrss=13788kB
50.1407
71.794e-3

w32threads
x=1
bench: utime=67.328s maxrss=13384kB
bench: utime=67.344s maxrss=13384kB
bench: utime=67.250s maxrss=13384kB
bench: utime=67.266s maxrss=13384kB
bench: utime=67.391s maxrss=13384kB
67.3158
57.898e-3

x=2
bench: utime=45.359s maxrss=13596kB
bench: utime=45.219s maxrss=13596kB
bench: utime=45.078s maxrss=13596kB
bench: utime=45.109s maxrss=13504kB
bench: utime=45.266s maxrss=13596kB
45.2062
115.0769e-3

x=3
bench: utime=51.234s maxrss=13756kB
bench: utime=51.219s maxrss=13756kB
bench: utime=51.328s maxrss=13756kB
51.2603
59.079e-3

for x=1 and 2 it's pretty inconclusive, but for x=3 w32threads wins.
of course x=3 shouldn't be done since it's slower than x=2.

If anyone can suggest better ways to measure (some win32 function that
gets the user time without summing all threads), or some better
decoder/encoder combo... for x=1 I got 50% load, for x=2 I got from
74-80% load.



More information about the ffmpeg-devel mailing list