Because the properties of frames returned from ff_get/reget_buffer
are not reset at all, lots of returned frames had palette_has_changed
wrongly set to 1. This has been changed, too.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
AVCodecInternal.last_pkt_props is not used when decoding subtitles;
ergo it makes no sense to set it at all.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Use AVCodecInternal.buffer_pkt (previously only used in
avcodec_send_packet) instead of stack packets when decoding subtitles.
Also stop sharing side-data between packets and use the user-supplied
packet directly for decoding when possible (no subtitle decoder ever
modifies the packet it is given).
Reusing AVCodecInternal.buffer_pkt is based upon an idea from James
Almer.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Avoids closing iconv when the size check fails.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Allows to remove one level of indentation.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It has been deprecated for 4 years and certain new codecs do not work
with it.
Also include AVCodecContext.refcounted_frames, as it has no effect with
the new API.
Fixes a decoding regression introduced by e9a2a87773, and as a side effect also
fixes bogus values set to certain audio frames that had some samples discarded,
where the offsets added to pts, pkt_dts and pkt_duration were not reflected in
best_effort_timestamp.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: 2147483647 + 64 cannot be represented in type 'int'
Fixes: 26218/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CRI_fuzzer-5734075396259840
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Keeping only the latest packet fed to the decoder works only for decoders that
return a frame immediately after every consumed packet. Decoders that consume
several packets before they return a frame will fill said frame with properties
taken from the last consumed packet instead of the earliest.
Signed-off-by: James Almer <jamrial@gmail.com>
This uses av_image_fill_plane_sizes instead of av_image_fill_pointers
when we are getting plane sizes to avoid UB from adding offsets to NULL.
Signed-off-by: Brian Kim <bkkim@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Previously, there was no way to flush an encoder such that after
draining, the encoder could be used again. We generally suggested
that clients teardown and replace the encoder instance in these
situations. However, for at least some hardware encoders, the cost of
this tear down/replace cycle is very high, which can get in the way of
some use-cases - for example: segmented encoding with nvenc.
To help address that use case, we added support for calling
avcodec_flush_buffers() to nvenc and things worked in practice,
although it was not clearly documented as to whether this should work
or not. There was only one previous example of an encoder implementing
the flush callback (audiotoolboxenc) and it's unclear if that was
intentional or not. However, it was clear that calling
avocdec_flush_buffers() on any other encoder would leave the encoder in
an undefined state, and that's not great.
As part of cleaning this up, this change introduces a formal capability
flag for encoders that support flushing and ensures a flush call is a
no-op for any other encoder. This allows client code to check if it is
meaningful to call flush on an encoder before actually doing it.
I have not attempted to separate the steps taken inside
avcodec_flush_buffers() because it's not doing anything that's wrong
for an encoder. But I did add a sanity check to reject attempts to
flush a frame threaded encoder because I couldn't wrap my head around
whether that code path was actually safe or not. As this combination
doesn't exist today, we'll deal with it if it ever comes up.
Currently the frame pool used by the default get_buffer2()
implementation is a single struct, allocated when opening the decoder.
A pointer to it is simply copied to each frame thread and we assume that
no thread attempts to modify it at an unexpected time. This is rather
fragile and potentially dangerous.
With this commit, the frame pool is made refcounted, with the reference
being propagated across threads along with other context variables. The
frame pool is now also immutable - when the stream parameters change we
drop the old reference and create a new one.
Fixes: signed integer overflow: 1677721600 * 32 cannot be represented in type 'int'
Fixes: 18885/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5741242185154560
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some decoders may not need a writable buffer in some specific cases, but only
a reference to the existing buffer with updated frame properties instead, for
the purpose of returning duplicate frames. For this, the
FF_REGET_BUFFER_FLAG_READONLY flag is added, which will prevent potential
allocations and buffer copies when they are not needed.
Signed-off-by: James Almer <jamrial@gmail.com>
-1 will be map to error number "EPERM", and will be map to the error
message like "Error while decoding stream #0:0: Operation not permitted",
it's a strange error message when debug update_frame_pool fail,
now only return the error code from av_image_fill_pointers in case
of av_image_fill_pointers failure.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
This reverts commit f631c328e6.
The avcodec_parameters_to_context() call was freeing and reallocating
AVCodecContext->extradata, essentially taking ownership of it, which according
to the doxy is user owned. This is an API break and has produced crashes in
some library users like Firefox[1].
Revert until a better solution is found to internally propagate the filtered
extradata back into the decoder context, or a decision is made to change the
API.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1486080
Signed-off-by: James Almer <jamrial@gmail.com>
Certain AVCodecParameters, like the contents of the extradata, may be changed
by the init() function of any of the bitstream filters in the chain.
Signed-off-by: James Almer <jamrial@gmail.com>
