aboutsummaryrefslogtreecommitdiffstats
path: root/libavcodec/mlpdec.c
diff options
context:
space:
mode:
authorMichael Niedermayer <michaelni@gmx.at>2014-11-28 00:57:32 +0100
committerMichael Niedermayer <michaelni@gmx.at>2014-11-28 01:00:50 +0100
commitb6691fba77afb0ca6ce6d7ca33fa8285f3c78911 (patch)
treef6855016915f724c36ce2c0c2c4111b6549f2eac /libavcodec/mlpdec.c
parent15fd62110fd82f19f9e127cf8401756231112ce0 (diff)
parent517ce1d09b5e6b72afc2ef9490b5f8ca42fa6a65 (diff)
downloadffmpeg-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