This is easily possible with an X macro.
Using an enum for the offsets also allows to remove
two arrays which are not really needed and will typically
be optimized away by the compiler: The first just exists
to count the number of syntax elements*, the second one
exists to get offset[CONSTANT]. These constants were
of type enum SyntaxElement and this enum was only used
in hevc_cabac.c (although it was declared in hevcdec.h);
it is now no longer needed at all and has therefore been
removed.
The first of these arrays led to a warning from Clang
which is fixed by this commit:
warning: variable 'num_bins_in_se' is not needed and will
not be emitted [-Wunneeded-internal-declaration]
*: One could also just added a trailing SYNTAX_ELEMENT_NB
to the SyntaxElement enum for this purpose.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It involves less allocations and therefore has the nice property
that deriving a reference from a reference can't fail,
simplifying hevc_ref_frame().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the collocated_ref of the current frame (i.e. HEVCContext.ref)
is ever used*, so move it to HEVCContext directly after ref.
*: This goes so far that collocated_ref was not even synced across
threads in case of frame-threading.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
Given that the RefStruct API relies on the user to know
the size of the objects and does not provide a way to get it,
we need to store the number of elements allocated ourselves;
but this is actually better than deriving it from the size
in bytes.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids allocations and therefore error checks: Syncing
hwaccel_picture_private across threads can't fail any more.
Also gets rid of an unnecessary pointer in structures and
in the parameter list of ff_hwaccel_frame_priv_alloc().
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Lynne <dev@lynne.ee>
Tested-by: Lynne <dev@lynne.ee>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Applying film grain happens after ff_thread_finish_setup(),
so the parameters synced in hevc_update_thread_context() must not
be modified. But this is exactly what happens in case applying
film grain fails. (The likely result is that in case of frame threading
an uninitialized frame is output.)
Given that it is actually very easy to know in advance whether
ff_h274_apply_film_grain() supports a given set of parameters,
one can check for this before ff_thread_finish_setup()
and avoid allocating an unused buffer lateron.
Reviewed-by: Niklas Haas <ffmpeg@haasn.xyz>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It was introduced for Vulkan, but it is equivalent to
short_term_ref_pic_set_size when !short_term_ref_pic_set_sps_flag,
and when !!short_term_ref_pic_set_sps_flag, Vulkan hardcodes a zero
anyway.
uint8_t is big enough and keep consistent with the definition in
cbs_h265.h.
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
According to 7.3.6.1, use_integer_mv_flag should be parsed if
motion_vector_resolution_control_idc equals to 2. If not present, it
equals to motion_vector_resolution_control_idc.
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
We will generate a new frame for a missed reference. The frame can only
be used for reference. We assign an invalid decode sequence to it, so
it will not be involved in any dpb process.
Tested-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: Xu Guangxin <guangxin.xu@intel.com>
It used to be allocated separately, so that the pointer to it
is copied to all HEVCContexts, so that all slice-threads
use the same. This is completely unnecessary now that there
is only one HEVCContext any more. There is just one minor
complication left: The slice-threads only get a pointer to
const HEVCContext, but they need to modify the common CABAC
state. Fix this by adding a pointer to the common CABAC state
to HEVCLocalContext and document why it exists.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The HEVC decoder has both HEVCContext and HEVCLocalContext
structures. The latter is supposed to be the structure
containing the per-slicethread state.
Yet up until now that is not how it is handled in practice:
Each HEVCLocalContext has a unique HEVCContext allocated for it
and each of these coincides except in exactly one field: The
corresponding HEVCLocalContext. This makes it possible to pass
the HEVCContext everywhere where logically a HEVCLocalContext
should be used. And up until recently, this is how it has been done.
Yet the preceding patches changed this, making it possible
to avoid allocating redundant HEVCContexts.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The HEVC decoder has both HEVCContext and HEVCLocalContext
structures. The latter is supposed to be the structure
containing the per-slicethread state.
Yet that is not how it is handled in practice: Each HEVCLocalContext
has a unique HEVCContext allocated for it and each of these
coincides except in exactly one field: The corresponding
HEVCLocalContext. This makes it possible to pass the HEVCContext
everywhere where logically a HEVCLocalContext should be used.
This commit stops doing this for lavc/hevc_cabac.c; it also constifies
everything that is possible in order to ensure that no slice thread
accidentally modifies the main HEVCContext state.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The HEVC decoder has both HEVCContext and HEVCLocalContext
structures. The latter is supposed to be the structure
containing the per-slicethread state.
Yet that is not how it is handled in practice: Each HEVCLocalContext
has a unique HEVCContext allocated for it and each of these
coincides with the main HEVCContext except in exactly one field:
The corresponding HEVCLocalContext.
This makes it possible to pass the HEVCContext everywhere where
logically a HEVCLocalContext should be used.
This led to confusion in the first version of what eventually became
commit c8bc0f66a8:
Before said commit, the initialization of the Rice parameter derivation
state was incorrect; the fix for single-threaded as well as
frame-threaded decoding was to add backup stats to HEVCContext
that are used when the cabac state is updated*, see
https://ffmpeg.org/pipermail/ffmpeg-devel/2020-August/268861.html
Yet due to what has been said above, this does not work for
slice-threading, because the each HEVCLocalContext has its own
HEVCContext, so the Rice parameter state would not be transferred
between threads.
This is fixed in c8bc0f66a8
by a hack: It rederives what the previous thread was and accesses
the corresponding HEVCContext.
Fix this by treating the Rice parameter state the same way
the ordinary CABAC parameters are shared between threads:
Make them part of the same struct that is shared between
slice threads. This does not cause races, because
the parts of the code that access these Rice parameters
are a subset of the parts of code that access the CABAC parameters.
*: And if the persistent_rice_adaptation_enabled_flag is set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The HEVC decoder has both HEVCContext and HEVCLocalContext
structures. The latter is supposed to be the structure
containing the per-slicethread state.
Yet that is not how it is handled in practice: Each HEVCLocalContext
has a unique HEVCContext allocated for it and each of these
coincides with the main HEVCContext except in exactly one field:
The corresponding HEVCLocalContext.
This makes it possible to pass the HEVCContext everywhere where
logically a HEVCLocalContext should be used.
This commit stops doing this for lavc/hevc_filter.c; it also constifies
everything that is possible in order to ensure that no slice thread
accidentally modifies the main HEVCContext state.
There are places where this was not possible, namely with the SAOParams
in sao_filter_CTB() or with sao_pixels_buffer_h in copy_CTB_to_hv().
Both of these instances lead to data races, see
https://fate.ffmpeg.org/report.cgi?time=20220629145651&slot=x86_64-archlinux-gcc-tsan-slices
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The HEVC decoder has both HEVCContext and HEVCLocalContext
structures. The latter is supposed to be the structure
containing the per-slicethread state.
Yet that is not how it is handled in practice: Each HEVCLocalContext
has a unique HEVCContext allocated for it and each of these
coincides except in exactly one field: The corresponding
HEVCLocalContext. This makes it possible to pass the HEVCContext
everywhere where logically a HEVCLocalContext should be used.
This commit stops doing this for lavc/hevc_mvs.c; it also constifies
everything that is possible in order to ensure that no slice thread
accidentally modifies the main HEVCContext state.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is safe for a slice thread to read the main context
and therefore it is safe to add a pointer to const HEVCContext
(namely the parent context) to each HEVCLocalContext.
It is also safe (and actually redundant) to add a pointer
to a logcontext to HEVCLocalContext.
Doing so allows to pass the HEVCLocalContext as context in
the parts of the code that is run slice-threaded when slice-threading
is in use (currently these parts of the code use ordinary
HEVCContext*). This way one is not tempted to modify
the main context from the slice contexts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All contexts are always initialized during init, regardless
of whether frame threading is in use or not.
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>
And expose the parsed values as frame side data. Update FATE results to
match.
It's worth documenting that this relies on the dovi configuration record
being present on the first AVPacket fed to the decoder, which in
practice is the case if if the API user has called something like
av_format_inject_global_side_data, which is unfortunately not the
default.
This commit is not the time and place to change that behavior, though.
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Similar in spirit and design to 66845cffc3, but slightly simpler due
to the lack of interlaced frames in HEVC. See that commit for more
details.
For the seed value, since no specification for this appears to exist, I
semi-arbitrarily decided to base it off the POC id alone, since there's
no analog of the idr_pic_id in HEVC's I-frames. This design is stable
across remuxes and seeks, but changes for adjacent frames with a period
that's typically long enough not to be noticeable, which makes it
satisfy all of the requirements that a film grain seed should have.
Tested with and without threading, using a patch to insert film grain
metadata artificially (for lack of real files containing film grain).
It's required by the 9.3.1 TableStatCoeff* section.
Following clips have this feature:
WPP_HIGH_TP_444_8BIT_RExt_Apple_2.bit
Bitdepth_A_RExt_Sony_1.bin
Bitdepth_B_RExt_Sony_1.bin
EXTPREC_HIGHTHROUGHPUT_444_16_INTRA_10BIT_RExt_Sony_1.bit
EXTPREC_HIGHTHROUGHPUT_444_16_INTRA_12BIT_RExt_Sony_1.bit
EXTPREC_HIGHTHROUGHPUT_444_16_INTRA_8BIT_RExt_Sony_1.bit
EXTPREC_MAIN_444_16_INTRA_10BIT_RExt_Sony_1.bit
EXTPREC_MAIN_444_16_INTRA_12BIT_RExt_Sony_1.bit
EXTPREC_MAIN_444_16_INTRA_8BIT_RExt_Sony_1.bit
WPP_AND_TILE_10Bit422Test_HIGH_TP_444_10BIT_RExt_Apple_2.bit
WPP_AND_TILE_AND_CABAC_BYPASS_ALIGN_0_HIGH_TP_444_14BIT_RExt_Apple_2.bit
WPP_AND_TILE_AND_CABAC_BYPASS_ALIGN_1_HIGH_TP_444_14BIT_RExt_Apple_2.bit
WPP_AND_TILE_HIGH_TP_444_8BIT_RExt_Apple_2.bit
you can download them from:
https://www.itu.int/wftp3/av-arch/jctvc-site/bitstream_exchange/draft_conformance/RExt/
Signed-off-by: Xu Guangxin <oddstone@gmail.com>
Signed-off-by: Linjie Fu <linjie.justin.fu@gmail.com>
following comandline will crash the ffmpeg
ffmpeg -threads 17 -thread_type slice -i WPP_A_ericsson_MAIN_2.bit out.yuv -y
the HEVCContext->sList size is MAX_NB_THREADS(16), any > 16 thread number will crash the application
Signed-off-by: Anton Khirnov <anton@khirnov.net>
After inspecting the source code of x265, mpv and ffmpeg, I've found that
ffmpeg mistakenly regards EVC_NAL_BLA_N_LP and HEVC_NAL_IDR_N_LP as non-
reference frames, which are acutally reference frames according to the
specification in x265, and drops them.
This patch should address the problem. I have tested it with mpv.
Signed-off-by: Mark Wu <wfwf1997@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
* commit 'c3f0357bdf7d3c542aad2c58b94184b9f56edc41':
hevcdec: move the MD5 context out of HEVCSEIPictureHash back into HEVCContext
Merged-by: James Almer <jamrial@gmail.com>
Fixes: runtime error: left shift of 1965559808 by 4 places cannot be represented in type 'int'
Fixes: 2333/clusterfuzz-testcase-minimized-5223935677300736
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
HEVCSEIPictureHash should store only the information extracted from the
bitstream and exported to the higher layer (the decoder or the parser).
The MD5 context is allocated, used and freed by this higher layer, so it
makes more sense for it to also be stored there.
Based on the H264 SEI implementation.
This will be mainly useful once support for SEI messages that can be
used by the hevc parser are implemented, like Picture Timing.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This is in preparation for a following patch.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Aaron Levinson <alevinsn@aracnet.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Move it to hevc_ps as well. This is in preparation for a following patch.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Aaron Levinson <alevinsn@aracnet.com>
Signed-off-by: James Almer <jamrial@gmail.com>
It doesn't depend on hevcdec anymore.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Aaron Levinson <alevinsn@aracnet.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Based on the H264 SEI implementation.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Aaron Levinson <alevinsn@aracnet.com>
Signed-off-by: James Almer <jamrial@gmail.com>
