diff options
author | Michael Niedermayer <michaelni@gmx.at> | 2014-11-28 00:57:32 +0100 |
---|---|---|
committer | Michael Niedermayer <michaelni@gmx.at> | 2014-11-28 01:00:50 +0100 |
commit | b6691fba77afb0ca6ce6d7ca33fa8285f3c78911 (patch) | |
tree | f6855016915f724c36ce2c0c2c4111b6549f2eac /libavcodec/mlpdec.c | |
parent | 15fd62110fd82f19f9e127cf8401756231112ce0 (diff) | |
parent | 517ce1d09b5e6b72afc2ef9490b5f8ca42fa6a65 (diff) | |
download | ffmpeg-b6691fba77afb0ca6ce6d7ca33fa8285f3c78911.tar.gz |
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>
Diffstat (limited to 'libavcodec/mlpdec.c')
0 files changed, 0 insertions, 0 deletions