Merge commit '517ce1d09b5e6b72afc2ef9490b5f8ca42fa6a65' into release/2.4
authorMichael Niedermayer <michaelni@gmx.at>
Thu, 27 Nov 2014 23:57:32 +0000 (00:57 +0100)
committerMichael Niedermayer <michaelni@gmx.at>
Fri, 28 Nov 2014 00:00:50 +0000 (01:00 +0100)
commitb6691fba77afb0ca6ce6d7ca33fa8285f3c78911
treef6855016915f724c36ce2c0c2c4111b6549f2eac
parent15fd62110fd82f19f9e127cf8401756231112ce0
parent517ce1d09b5e6b72afc2ef9490b5f8ca42fa6a65
Merge commit '517ce1d09b5e6b72afc2ef9490b5f8ca42fa6a65' into release/2.4

* commit '517ce1d09b5e6b72afc2ef9490b5f8ca42fa6a65':
  lavu: fix memory leaks by using a mutex instead of atomics

Conflicts:
libavutil/buffer.c

The atomics code is left in place as a fallback for synchronization in the
absence of p/w32 threads. Our ABI did not requires applications to
only use threads (and matching ones) to what libavutil was build with
Our code also was not affected by the leak this change fixes, though
no question the atomics based implementation is not pretty at all.
First and foremost the code must work, being pretty comes after that.

If this causes problems, for example when libavutil is used by multiple
applications each using a different kind of threading system then the
default possibly has to be changed to the uglier atomics.

See: cea3a63ba3d89d8403eef008f7a7c54d645cff70
Merged-by: Michael Niedermayer <michaelni@gmx.at>
libavutil/buffer.c
libavutil/buffer_internal.h