Also remove pthread_cond_broadcast(progress_cond) on uninit.
Broadcasting it is not required because workers are always
parked when they are not in thread_execute. So it is imposible
that a worker is waiting on progress_cond when uninitialized.
Benchmark:
./ffmpeg -threads $threads -thread_type slice -i 10slices.mp4 -f null null
threads=2:
old: 70.212s 70.525s 70.877s
new: 65.219s 65.377s 65.484s
threads=3:
old: 65.086s 66.306s 66.409s
new: 63.229s 65.026s 65.116s
threads=4:
old: 60.993s 61.482s 62.123s
new: 59.224s 59.441s 59.667s
threads=5:
old: 57.576s 57.860s 58.832s
new: 53.032s 53.948s 54.086s
Signed-off-by: Muhammad Faiz <mfcc64@gmail.com>
When calling ff_alloc_entries, a number of entries are created.
They are never freed, as running fate with slice threading and
several frames on e.g. fate-hevc-conformance-ENTP_A_Qualcomm_1
would show.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '38ecc3702dabbea09230f6d6333f59e74f5d1c12':
pthread: store thread contexts in AVCodecInternal instead of AVCodecContext
Conflicts:
libavcodec/internal.h
libavcodec/utils.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'cc14ee03a7b91c69343f8d60c9e089a1950eeadb':
lavc: split slice and frame threading functions into separate files
Conflicts:
libavcodec/Makefile
libavcodec/pthread.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
