On Fri, Mar 24, 2017 at 01:47:10PM +0100, wm4 wrote:
> async_mutex has is used in a very strange but intentional way: it is
> locked by default, and unlocked only in regions that can be run
> concurrently.
> 
> If the user was calling API functions to the same context from different
> threads (in a safe way), this could unintentionally unlock the mutex on
> a different thread than the previous lock operation. It's not allowed by
> the pthread API.
> 
> Fix this by emulating a binary semaphore using a mutex and condition
> variable. (Posix semaphores are not available on all platforms.)
> ---
>  libavcodec/pthread_frame.c | 41 +++++++++++++++++++++++++++++++----------
>  1 file changed, 31 insertions(+), 10 deletions(-)

this breaks flac

make -j12 ffmpeg && ./ffmpeg -i ~/tickets/4421/testwav_cut.wav out.flac ; 
./ffmpeg -i out.flac -f null -
https://trac.ffmpeg.org/attachment/ticket/4421/testwav_cut.wav

Input #0, flac, from 'out.flac':
  Metadata:
    ENCODER         : Lavf57.67.100
  Duration: 00:00:10.00, start: 0.000000, bitrate: 912 kb/s
    Stream #0:0: Audio: flac, 44100 Hz, stereo, s16
Stream mapping:
  Stream #0:0 -> #0:0 (flac (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
  Metadata:
    encoder         : Lavf57.67.100
    Stream #0:0: Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s
    Metadata:
      encoder         : Lavc57.86.103 pcm_s16le
Assertion ret <= avpkt->size failed at libavcodec/utils.c:2507
Aborted

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to