And make it public.
For encoding, users may also be interested in the configured level and
compatibility ID. So generalize the dv_profile field and just expose the
whole configuration record.
This makes the already rather reductive ff_dovi_update_cfg() function
almost wholly redundant, since users can just directly assign
DOVIContext.cfg.
It avoids having to sync ProgressFrame.f and the pointer
typically used to access the AVFrame.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids implicit av_frame_ref() and therefore allocations
and error checks. It also avoids explicitly allocating
the AVFrames (done implicitly when getting the buffer).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before commit f025b8e110,
every frame-threaded decoder used ThreadFrames, even when
they did not have any inter-frame dependencies at all.
In order to distinguish those decoders that need the AVBuffer
for progress communication from those that do not (to avoid
the allocation for the latter), the former decoders were marked
with the FF_CODEC_CAP_ALLOCATE_PROGRESS internal codec cap.
Yet distinguishing these two can be done in a more natural way:
Don't use ThreadFrames when not needed and split ff_thread_get_buffer()
into a core function that calls the user's get_buffer2 callback
and a wrapper around it that also allocates the progress AVBuffer.
This has been done in 02220b88fc
and since that commit the ALLOCATE_PROGRESS cap was nearly redundant.
The only exception was WebP and VP8. WebP can contain VP8
and uses the VP8 decoder directly (i.e. they share the same
AVCodecContext). Both decoders are frame-threaded and VP8
has inter-frame dependencies (in general, not in valid WebP)
and therefore the ALLOCATE_PROGRESS cap. In order to avoid
allocating progress in case of a frame-threaded WebP decoder
the cap and the check for the cap has been kept in place.
Yet now the VP8 decoder has been switched to use ProgressFrames
and therefore there is just no reason any more for this check
and the cap. This commit therefore removes both.
Also change the value of FF_CODEC_CAP_USES_PROGRESSFRAMES
to leave no gaps.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Invalid input files may contain film grain metadata which survives
ff_h274_film_grain_params_supported() but does not pass
av_film_grain_params_select(), leading to a SIGSEGV on hevc_frame_end().
Fix this by duplicating the av_film_grain_params_select() check at frame
init time.
An alternative solution here would be to defer the incompatibility check
to hevc_frame_end(), but this has the downside of allocating a film
grain buffer even when we already know we can't apply film grain.
Fixes: https://trac.ffmpeg.org/ticket/10951
The Dolby Vision RPU contains a CRC32 to validate the payload against.
The implementation is CRC32/MPEG-2.
The CRC is only verified with the AV_EF_CRCCHECK flag.
Co-authored-by: quietvoid <tcChlisop0@gmail.com>
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If the time code side data is overridden by the packet level, we also
make sure not to update `out->metadata` to a mismatched timecode.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Unnecessary since acf63d5350;
also avoids relocations.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
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>
It avoids allocations and the corresponding error checks.
Also avoids casts and indirections.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids allocations and error checks for these allocations;
e.g. syncing buffers across threads can't fail any more
and needn't be checked. It also gets rid of casts and
indirections.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
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>
There is likely a better way to fix this, this is mainly to show the problem
Fixes: MC within same frame resulting in overlapping memcpy()
Fixes: 60189/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-4992746590175232
Fixes: 61753/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5022150806077440
Fixes: 58062/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-4717458841010176
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These defines are also used in other contexts than just AVCodecContext
ones, e.g. in libavformat. Furthermore, given that these defines are
public, the AV-prefix is the right one, so deprecate (and not just move)
the FF-macros.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit is the AVHWAccel analogue of commit
20f9727018: 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>
This allows this common H.274 SEI to be parsed from both H.264
as well as HEVC, as well as probably from VVC in the future.
Generally attempts to keep the original code as similar as possible.
FATE test refererence changes only change the order of side data
export within a single frame. Nothing else seems to have changed.
This allows this common H.274 SEI to be parsed from both H.264
as well as HEVC, as well as probably from VVC in the future.
Generally attempts to keep the original code as similar as possible.
FATE test refererence changes only change the order of side data
export within a single frame. Nothing else seems to have changed.
Fixes: runtime error: pointer index expression with base 0x000000000000 overflowed to 0xfffffffffffffff8
Fixes: 58440/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5956015530311680
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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.
num_ref_idx_l0_active_minus1, num_ref_idx_l1_active_minus1,
num_ref_idx_l0_default_active_minus1, and num_ref_idx_l1_default_active_minus1
are all in the range 0 to 14, inclusive.
Signed-off-by: James Almer <jamrial@gmail.com>
Screen Content Coding allows non-intra slice in an IRAP frame which can
reference the frame itself, and would mark the current decoded picture
as "used for long-term reference", no matter TwoVersionsOfCurrDecPicFlag(8.1.3),
hence some previous restricts are not suitable any more.
Constructe RefPicListTemp and RefPicList according to 8-8/9/10. Disable
slice decoding for SCC profile to avoid unexpected error in hevc native
decoder and patch welcome.
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>
This unfortunately involved adding some parameters
to ff_h2645_sei_to_frame() that will be mostly unused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are only slight differences between H.264 and HEVC
for this side data, so it makes sense to share the code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
With the necessary pixel formats defined, we can now expose support for
the remaining 10/12bit combinations that VAAPI can handle.
Specifically, we are adding support for:
* HEVC
** 12bit 420
** 10bit 422
** 12bit 422
** 10bit 444
** 12bit 444
* VP9
** 10bit 444
** 12bit 444
These obviously require actual hardware support to be usable, but where
that exists, it is now enabled.
Note that unlike YUVA/YUVX, the Intel driver does not formally expose
support for the alphaless formats XV30 and XV360, and so we are
implicitly discarding the alpha from the decoder and passing undefined
values for the alpha to the encoder. If a future encoder iteration was
to actually do something with the alpha bits, we would need to use a
formal alpha capable format or the encoder would need to explicitly
accept the alphaless format.
