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.
These fields are ad-hoc and will be deprecated. Use the recently-added
AV_CODEC_FLAG_COPY_OPAQUE to pass arbitrary user data from packets to
frames.
Changes the result of the flcl1905 test, which uses ffprobe to decode
wmav2 with multiple frames per packet. Such packets are handled
internally by calling the decoder's decode callback multiple times,
offsetting the internal packet's data pointer and decreasing its size
after each call. The output pkt_size value before this commit is then
the remaining internal packet size at the time of each internal decode
call.
After this commit, output pkt_size is simply the size of the full packet
submitted by the caller to the decoder. This is more correct, since
internal packets are never seen by the caller and should have no
observable outside effects.
Rescale the timestamp for AVERROR_EOF. This can fix tickets 10261 and
10262.
Tested-by: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The AVPacket given to an encoder's encode callback
is unreferenced generically on error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AVPacket given to an encoder's encode callback
is unreferenced generically on error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AVPacket given to an encoder's encode callback
is unreferenced generically on error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
FFmpeg's assembly code currently does not abide by the
plattform-specific ABIs wrt its handling of the X86 MMX flag:
Resetting the MMX state is deferred to avoid doing it multiple times
instead of ensuring that the CPU is in floating point state
upon return from any function.
Furthermore, resetting said state is sometimes done generically,
namely for all the decoders using the ordinary decode callback;
yet this is not done for the decoders using the receive_frame API.
This led to problems when MJPEG (and the MJPEG-based decoders)
were switched to the receive_frame API in commit
e9a2a87773, because ff_mjpeg_decode_sos()
only resets the MMX state on success, not on failure.
Such issues are probably still possible with SMVJPEG, which still
uses the receive_frame API. See issue #10210.
This commit therefore also resets the MMX state for
the receive_frame API to avoid any more surprises of this sort.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The base_enable_flag is parallel to three_Spline_enable_flag. The
typesetting of the specification is very misleading.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
It conflicts the comments. The operation based on Delta_enable_mode
can be applied by user during tone mapping.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The original code would strip off the PTS/DTS of any packets
which had a stream ID of STREAM_ID_PRIVATE_STREAM_1. While the
intent was to apply this to asynchronous KLV packets, it was
being applied to any codec that had that same stream ID (including
types such as SMPTE 2038).
Add a clause to the if() statement to ensure it only gets applied
if the codec actually is KLV.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
ipcm is defined by ISO/IEC 23003-5, not defined by quicktime. After
adding ISO/IEC 23003-5 support, we don't need it for ticket #9219.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This also fixes the number of planes for the NV formats
(this seems to not have caused any problems).
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SSIM360Context.ssim360_hist is an array of four pointers to double;
so sizeof(*ssim360_hist[0]) (=sizeof(double)) is the correct size
to use to calculate the amount of memory to allocate, not
sizeof(*ssim360_hist) (which is sizeof(double*)).
Use FF_ALLOCZ_TYPED_ARRAY to avoid this issue altogether.
Fixes Coverity issue #1520671.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Generally if maxrate is set, the calculation should be maxrate over
bufsize. This additionally enables CRF + maxrate & bufsize usage.
In order to keep negative values from enabling zero to be treated
as larger and causing a division by zero, check that one of the
variables is larger than zero.
This has not been functional since a year ago, including in our current
minimum dependency of libplacebo (v4.192.0). It also causes build errors
against libplacebo v6, so it needs to be removed from the code. We can
keep the option around for now, but it should also be removed soon.
Signed-off-by: Niklas Haas <git@haasn.dev>
Signed-off-by: James Almer <jamrial@gmail.com>
