Actually, ff_slice_thread_allocz_entries() always already
allocates zeroed entries, so ff_reset_entries() was already
unnecessary. Make this more clear by renaming it to
ff_slice_thread_allocz_entries().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It results in undefined behaviour. Instead initialize the mutexes
and condition variables once during init (and check these
initializations).
Also combine the corresponding mutex and condition variable
into one structure so that one can allocate their array
jointly.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, codec.h contains both public and private parts
of AVCodec. This exposes the internals of AVCodec to users
and leads them into the temptation of actually using them
and forces us to forward-declare structures and types that
users can't use at all.
This commit changes this by adding a new structure FFCodec to
codec_internal.h that extends AVCodec, i.e. contains the public
AVCodec as first member; the private fields of AVCodec are moved
to this structure, leaving codec.h clean.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also move FF_CODEC_TAGS_END as well as struct AVCodecDefault.
This reduces the amount of files that have to include internal.h
(which comes with quite a lot of indirect inclusions), as e.g.
most encoders don't need it. It is furthemore in preparation
for moving the private part of AVCodec out of the public codec.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_slice_thread_init() uses a static variable to hold a function
pointer, although the value of said pointer needn't be saved between
different runs of this function at all.
The reason for this being so is probably that said pointer points to
a static function (if used); but storage class specifiers like "static"
are not part of the type of an object and so including it in the pointer
declaration is wrong (anyway, "static" means different things in both
contexts: for the function declaration it affects linkage, for the
variable storage duration).
Using a static variable here can lead to races, e.g. when initializing
VP9 (for which said function pointer was added) and H.264 with slice
threading. The latter has the FF_CODEC_CAP_INIT_THREADSAFE flag set and
is therefore unaffected by the lock guarding initializations of
decoders.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This removes the XP compatibility code, and switches entirely to SRW
locks, which are available starting at Windows Vista.
This removes CRITICAL_SECTION use, which allows us to add
PTHREAD_MUTEX_INITIALIZER, which will be useful later.
Windows XP is hereby not a supported build target anymore.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This removes the XP compatibility code, and switches entirely to SWR
locks, which are available starting at Windows Vista.
This removes CRITICAL_SECTION use, which allows us to add
PTHREAD_MUTEX_INITIALIZER, which will be useful later.
Windows XP is hereby not a supported build target anymore. It was
decided in a project vote that this is OK.
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>
Andreas Rheinhardt
Andreas Rheinhardt
wm4
Ilia Valiakhmetov
Muhammad Faiz
Clément Bœsch
Michael Niedermayer
Christophe Gisquet
Michael Niedermayer
Anton Khirnov