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

[Alexander Strange]

On Apr 19, 2010, at 10:19 PM, Ramiro Polla wrote:

> 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.

av_gettime() should be the wallclock/real time (actual seconds) instead of the user time (cpu seconds).
That's actually what we want, though, I'm not sure how to interpret user times with threads.

With real time shorter is better, so pthreads seem OK.
You could try decoding some MPEG2, which should use threads pretty fairly.


> 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.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel