Use AV1DecContext's current_obu to access the original OBUs, and
feed them to videotoolbox, rather than the bare slice data passed
via decode_slice.
This requires a small addition to AV1DecContext, for keeping track
of the current range of OBUs that belong to the current frame.
Co-authored-by: Ruslan Chernenko <ractyfree@gmail.com>
Co-authored-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes: CID1544265 Logically dead code
Sponsored-by: Sovereign Tech Fund
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Before 0f8763fbea, av1_frame_ref()
and update_reference_list() could fail and therefore needed to
be checked, which incidentally set ret. This is no longer happening,
leading to a potential use of an uninitialized value which is
also the subject of Coverity ticket #1596605.
Fix this by always setting ret before goto end; do not return
some random ancient value.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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.
AV1 can put a frame into multiple reference slots;
up until now, this involved creating a new reference
to the underlying AVFrame; therefore av1_frame_ref()
could fail.
This commit changes this by using the ProgressFrame API
to share the underlying AVFrames.
(Hint: vaapi_av1_surface_id() checked whether the AV1Frames
contained in the AV1DecContext were NULL or not (of course
they were not); this has been changed to actually check for
whether said AV1Frame is blank or not.)
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is needed by Vulkan. Constructing this can't be delegated to CBS
because packets might contain multiple frames (when non-shown frames are
present) but we need separate snapshots immediately before each frame
for the decoder.
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>
Not directly signalled by AV1, but we should still set this accordingly
so that users will know what the original intended video characteristics
and chroma resolution were.
Fixes errors when opening streams with no extradata (like those from raw OBU
sources). It also calls get_format() on new Sequence Headers when required.
Signed-off-by: James Almer <jamrial@gmail.com>
So that can show OBU info even it doesn't have decomposed content. And
add OBU content status into the message.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Unnecessary since acf63d5350adeae551d412db699f8ca03f7e76b9;
also avoids relocations.
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>
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>
This avoids allocations and error checks etc. as well
as duplicate pointer lists in the CodedBitstreamFooContexts.
It also avoids casting const away for use as opaque,
as the RefStruct API supports const opaques.
The fact that some of the units are not refcounted
(i.e. they are sometimes part of an encoding context
like VAAPIEncodeH264Context) meant that CodedBitstreamUnit
still contains two pointers, one to the content
and another ownership pointer, replacing the AVBufferRef* pointer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since fb548fba04,
this return -1 is in a function returning enum AVPixelFormat
whose caller checks for AV_PIX_FMT_NONE for failure.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It indicates to the reader that said function does not modify
any state.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
And remove the AVOID_PROBING flag, given it's the last av1 decoder to be tested
either way.
This fixes a regression introduced in 1652f2492f,
where even if forcing the native av1 decoder, if another decoder was present,
like libdav1d or libaom-av1, they'd be used for probing and some fate tests
would have different results.
Signed-off-by: James Almer <jamrial@gmail.com>
Makes the output of the native decoder consistent with external decoders like
libdav1d with fate-enhanced-flv-av1.
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: James Almer <jamrial@gmail.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>
All usages of ff_hwaccel_frame_priv_alloc() have the same pattern:
Check for whether a hwaccel is in use; check whether it needs
private frame-specific data; allocate the AVBuffer and set
it.
This commit modifies ff_hwaccel_frame_priv_alloc() to perform
this task on its own.
(It also seems that the H.264 decoder did not perform proper
cleanup in case the buffer could not be allocated. This has been
changed.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are circumstances where the flag isn't set but the skip mode
frames are. So don't use the inferred bit which has other inputs
when deciding to pass the skip mode frames to the device.
This fixes some decoding bugs on intel av1
* take num_ticks_per_picture_minus_1 into account, since that is a part
of the framerate computation
* stop exporting num_ticks_per_picture_minus_1 into
AVCodecContext.ticks_per_frame, as that field is used for other
purposes (in conjunction with repeat_pict, which is not used at all by
av1)
These fields are supposed to store information about the packet the
frame was decoded from, specifically the byte offset it was stored at
and its size.
However,
- the fields are highly ad-hoc - there is no strong reason why
specifically those (and not any other) packet properties should have a
dedicated field in AVFrame; unlike e.g. the timestamps, there is no
fundamental link between coded packet offset/size and decoded frames
- they only make sense for frames produced by decoding demuxed packets,
and even then it is not always the case that the encoded data was
stored in the file as a contiguous sequence of bytes (in order for pos
to be well-defined)
- pkt_pos was added without much explanation, apparently to allow
passthrough of this information through lavfi in order to handle byte
seeking in ffplay. That is now implemented using arbitrary user data
passthrough in AVFrame.opaque_ref.
- several filters use pkt_pos as a variable available to user-supplied
expressions, but there seems to be no established motivation for using them.
- pkt_size was added for use in ffprobe, but that too is now handled
without using this field. Additonally, the values of this field
produced by libavcodec are flawed, as described in the previous
ffprobe conversion commit.
In summary - these fields are ill-defined and insufficiently motivated,
so deprecate them.
