[FFmpeg-devel] [PATCH] avcodec/utils: use a default lock manager that uses a spinlock

Reimar Döffinger Reimar.Doeffinger at gmx.de
Fri Oct 18 18:20:20 CEST 2013

On 18.10.2013, at 14:17, wm4 <nfxjfg at googlemail.com> wrote:
> On Fri, 18 Oct 2013 08:41:36 +0200
> Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
>> Pthreads is not always available, and even if it is there is no guarantee it will be compatible with the threading system the application uses.
> Well, ffmpeg is doing the multithreading, so of course pthreads will be
> available?

"The multithreading"? None of this is required or in any way relevant for the FFmpeg internal threading.
So no, pthreads might not be available, or FFmpeg might have been compiled without threading support.

> Why should there be any "compatibility" be necessary? As far as I can
> see, ffmpeg will always use the system's standard threading API, so
> what exactly is the problem?

There have been pthread implementations that could not "see" the native threads (as a stupid example, a generic pthread implementation based on cooperative scheduling which only uses one single native thread). In those cases a pthread lock will fail to affect the applications native threads, i.e. the lock will simply not work for threads not created by pthreads.
There are many variants of this.
There is no general way to know if the applications threading method is compatible with what FFmpeg used, which is the reason to have the lock manager in the first place.

More information about the ffmpeg-devel mailing list