It is unnecessary since the removal of non-thread-safe callbacks
in e0786a8eeb. Since then, the
AVCodecContext has only been used as logcontext.
Removing ff_thread_release_buffer() allowed to remove AVCodecContext*
parameters from several other functions (not only unref functions,
but also e.g. ff_h264_ref_picture() which calls ff_h264_unref_picture()
on error).
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids allocations and error checks and allows to remove
cleanup code for earlier allocations. Also avoids casts
and indirections.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids allocations and frees and error checks for said allocations;
also avoids a few indirections and casts.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since 432adca5fe no decoder
looks at the slice_count and slice_offset fields at all,
so there is no reason to synchronize them between the worker
and the user thread.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The '<' in ///< says that the comment pertains to the previous item
on the same line as the ///<.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit is the AVHWAccel analogue of commit
20f972701806be20a77f808db332d9489343bb78: It moves the private fields
of AVHWAccel to a new struct FFHWAccel extending AVHWAccel
in an internal header (namely hwaccel_internal.h).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
libavcodec/hwconfig.h currently contains HWACCEL_CAP_* flags
as well as the definition of AVCodecHWConfigInternal and some
macros to create them.
The users of these two are nearly disjoint: The flags are used
by files providing AVHWAccels whereas AVCodecHWConfigInternal
is used by files providing codecs (for FFCodec.hw_configs).
This patch therefore moves these flags to a new file hwaccel_internal.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The issue is that with a threadsafe hwaccel and multiple enabled
frame threads, hwaccel->uninit() is never called.
Previously, the function was guaranteed to never have any threads
with hwaccel contexts, so it never bothered to uninit any.
For encoding, this field is entirely redundant with
AVCodecContext.framerate.
For decoding, this field is entirely redundant with
AV_CODEC_PROP_FIELDS.
Frame counters can overflow relatively easily (INT_MAX number of frames is
slightly more than 1 year for 60 fps content), so make sure we use 64 bit
values for them.
Also deprecate the old 32 bit frame_number attribute.
Signed-off-by: Marton Balint <cus@passwd.hu>
Making it point to the input packet results in different behavior during flush,
where its contents will be that of an empty packet instead of containing the
props from the last input packet fed to the decoder.
After this change, decoding with more than one thread will shield the same
results as using a single thread.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes assertion failures after avcodec_flush_buffers(), where
stashed hwaccel state is present, but prev_thread is NULL.
Found-by: Wang Bin <wbsecg1@gmail.com>
This state is not refcounted, so make sure it always has a well-defined
owner.
Remove the block added in 091341f2ab, as
this commit also solves that issue in a more general way.
Currently, ff_frame_thread_free() uses the last worker thread
to updates the first worker thread via update_context_from_thread()
immediately before freeing all these worker threads. This is
a remnant of the time in which the first worker was special.
(E.g. the first worker shared its AVCodecInternal with the public
AVCodecContext.)
But these times are over (none of the uses of is_copy matter
for ff_frame_thread_free()); nowadays the only thing that
update_context_from_thread() does is referencing a few
buffers/frames and replacing them with other references instead.
These new references will then be freed immediately thereafter
when the first worker thread is freed. Ensuring that the code is
free of double-frees is achieved by using reference-counted structures
(or in case of AVChannelLayouts: by giving each worker its own copy).
Some archaeology:
a) Updating the first worker thread from the last one used
has been done since frame-threading was added in
37b00b47cb.
b) The precursor to ff_mpv_common_end() checked for is_copy
before freeing pictures (i.e. it only freed them for the first
worker thread).
c) Commits c2dfb1e37c and
e33811bd26 modified the
update_thread_context function of the H.264 decoder
so that it could fail before calling ff_mpeg_update_thread_context().
d) This led to a double free/an assert violation with a H.264
sample for which ff_mpeg_update_thread_context() is not reached
for the final update_context_from_thread(). Commit
a6e4796fbf added code to fix this
sample.
e) This issue was fixed (even with the last mentioned commit reverted)
when the H.264 decoder was deMpegEncContextized in commit
b7fe35c9e5 (merging commit
2c54155407).
f) mpegvideo.c stopped using is_copy when it was switched to refcounted
frames in 759001c534.
g) 1f4cf92cfb removed the init_thread_copy
callbacks; now no FFCodec.close callback checks for is_copy at all
any more.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible, because every given FFCodec has to implement
exactly one of these. Doing so decreases sizeof(FFCodec) and
therefore decreases the size of the binary.
Notice that in case of position-independent code the decrease
is in .data.rel.ro, so that this translates to decreased
memory consumption.
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>
This avoids including version.h in all source files, avoiding
unnecessary rebuilds when the version number is bumped. Only
version_major.h is included by the main header, which defines
availability of e.g. FF_API_* macros, and which is bumped much
less often.
This isn't done for libavutil/version.h, because that header needs
to be included essentially everywhere due to LIBAVUTIL_VERSION_INT
being used wherever an AVClass is constructed.
Signed-off-by: Martin Storsjö <martin@martin.st>
Since the request_channel_layout is used only by a handful of codecs,
move the option to codec private contexts.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>
If a frame-threaded decoder with inter-frame dependencies
returns an error when decoding a frame and the returned frame
isn't clean, an error message is emitted claiming that this
is a bug. This seems to be based upon the thinking that
in this case a ThreadFrame has not been properly unreferenced.
Yet this is wrong, as decoders with inter-frame dependencies
don't use the frame for output for synchronization and therefore
don't use ThreadFrames at all for this. So unreferencing
this frame generically is fine and not a bug.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use ff_thread_release_buffer() instead of av_frame_unref(),
as the former handles the case of non-thread-safe callbacks
properly. (This is possible now that ff_thread_release_buffer()
no longer requires a ThreadFrame.)
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The majority of frame-threaded decoders (mainly the intra-only)
need exactly one part of ThreadFrame: The AVFrame. They don't
need the owners nor the progress, yet they had to use it because
ff_thread_(get|release)_buffer() requires it.
This commit changes this and makes these functions work with ordinary
AVFrames; the decoders that need the extra fields for progress
use ff_thread_(get|release)_ext_buffer() which work exactly
as ff_thread_(get|release)_buffer() used to do.
This also avoids some unnecessary allocations of progress AVBuffers,
namely for H.264 and HEVC film grain frames: These frames are not
used for synchronization and therefore don't need a ThreadFrame.
Also move the ThreadFrame structure as well as ff_thread_ref_frame()
to threadframe.h, the header for frame-threaded decoders with
inter-frame dependencies.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These will be used by the codecs that need allocated progress
and is in preparation for no longer using ThreadFrame by the codecs
that don't.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for further commits that will stop
using ThreadFrame for frame-threaded codecs that don't use
ff_thread_(await|report)_progress(); the API for those codecs
having inter-frame depdendencies will live in threadframe.h.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Several of our decoders support both frame- as well as slice-threading;
in case of the latter avctx->internal->thread_ctx points to
a SliceThreadContext, not to a frame-thread PerThreadContext.
So only treat avctx->internal->thread_ctx as the latter after
having checked that frame-threading is active.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
'*src' and '*avctx' point to the same memory. It is enough to keep one of them.
Signed-off-by: Yu Yang <yuyang14@kuaishou.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
We have more mutexes/condition variables whose initialization is
unchecked.
Also use a proper namespace for these functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Some frame threaded decoders set it, but this information never reached the
caller in frame threading scenarios.
Signed-off-by: James Almer <jamrial@gmail.com>
Right now all AVCodecContexts except those using frame-threaded decoding
call the codec's init function and expect its close function to be
called. In order to make sure that the close function is not called for
frame-threaded decoding ff_frame_thread_free() resets
AVCodecContext.codec (and because of this it has to free the private
AVOptions of the main AVCodecContext itself). This is not obvious and
potentially fragile. Instead add a field to AVCodecInternal that
indicates whether close should be called for this AVCodecContext.
It is always zero when using frame-threaded decoding, so that resetting
the codec is no longer necessary and has been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Deprecated in 40cf1bbacc.
(The currently disabled filter vf_mcdeint and vf_uspp were users of
this field; they have not been changed, so that whoever wants to fix
them can see the state of these filters when they were disabled.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
James Almer
Andreas Rheinhardt
Anton Khirnov
Lynne
Marton Balint
Martin Storsjö
Vittorio Giovara
Yu Yang
Hendrik Leppkes