Thread Library Comparison (pthreads-win32, winpthreads, & w32threads)

[Zeranoe]

I conducted a speed comparison of the three different thread libraries available.

FFmpeg and libx264 were compiled with each library, and tested with five trial runs.

The test loop was:

Code: Select all

FOR %%a IN (pthreadsw32 w32threads winpthreads) DO (
  FOR /L %%b IN (1,1,5) DO (
    ECHO %%a %%b
    ECHO !TIME!
    ffmpeg-%%a -loglevel error -i bbb_sunflower_1080p_60fps_normal.mp4 -c:v libx264 -y out.mp4 || EXIT /B
    ECHO !TIME!
  )
)

The input test media was Big Buck Bunny (1920x1080, 60fps) from http://bbb3d.renderfarming.net/download.html

The average run time results of the five test (in MM:SS.ss) was:

1. w32threads = 8:16.1 (SD 1.784035874s)
2. pthreads-win32 = 8:20.8 (SD 2.207393033s)
3. winpthreads = 8:21.3 (SD 2.468970636s)

The fastest threading implementation was found to be w32threads, and the current builds (release and git) use w32threads.

[rogerdpack]

I assume the largest impact was how libx264 was compiled, do you think?
Compiling ffmpeg without pthreads might have some other unintended consequencies, like "non multi thread UDP support" possibly, FWIW...

[Zeranoe]

I assume the largest impact was how libx264 was compiled, do you think?

To my understanding FFmpeg implements its own threading and does not use the library threading. I still compiled both with each library to avoid needing to include libpthread.a

[rogerdpack]

I assume the largest impact was how libx264 was compiled, do you think?

To my understanding FFmpeg implements its own threading and does not use the library threading. I still compiled both with each library to avoid needing to include libpthread.a

I believe it just calls out to libx264.a and libx264 is doing its own threading internally, but I'm not expert on it.

[mms2]

Seems right about UDP support getting :

[udp @ 03541f00] 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required)

and no output is produced, this is when calling something like this:

ffmpeg.exe -rtsp_transport udp -an -i rtsp://.. -f image2 -qscale:v 2 -vframes 1 -y thumb.jpg

Is this related? How to fix this? Are there builds with pthread support available?

[filmars]

hello

since the removal of the pthreads library from the official builds, I have also this kind of error message during the play of rtp stream

ffplay.exe "rtsp://wowzaec2demo.streamlock.net/vod/mp4:BigBuckBunny_115k.mov"

[udp @ 0000000000655fe0] 'circular_buffer_size' option was set but it is not supported on this build (pthread support is required)

any solution for this ?

thanks !

[mikeversteeg]

Although I welcome experiments like these (just sorry I missed the announcement, is there a channel for this type of news?), it looks like ffmpeg is not ready for this as too much is now broken (including decklink support). So my vote is to go back to the old situation. Maybe a "beta" build with documented changes would be an idea, allowing everyone to test properly before the changes become final?

[Zeranoe]

it looks like ffmpeg is not ready for this as too much is now broken (including decklink support).

Decklink is not broken because of this, it is a licensing issue: http://git.videolan.org/gitweb.cgi/ffmp ... 29fe01736e

Other than decklink very little has been adversely effected, and the gains outweigh them.

[mikeversteeg]

I don't see the issue in supporting DeckLink (in fact they endorse it) and the link you provide does not offer any information? Does this mean we have to make our own builds from now on?

[Zeranoe]

DeckLink has been moved into non-free, so it can't be included in a public build. If you need the external lib itself you will probably have to build yourself.

You can do a lot with just dshow though.