Filter init can change extradata from avcc/hvcc to annexb format.
With different passthrough logic, packets can still in avcc/hvcc
format. Use same passthrough logic for init and filter.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The color range should be set to match the input when creating
the VideoToolbox context. Otherwise, the new context will default
to limited range, creates inconsistencies with full range inputs.
Signed-off-by: Gnattu OC <gnattuoc@me.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This fixes failures in recently added checkasm tests.
While the buffers in most cases are aligned, libswscale in general
can't assume the output to be aligned.
Signed-off-by: Martin Storsjö <martin@martin.st>
The only thing this function does beyond calling av_get_pix_fmt() is
falling back onto parsing the argument as a number. No other filters
should need to do this.
Current code is written around the "simple" decode API's limitation that
a single input packet (AU/coded frame) triggers the output of at most
one output frame. However the spec contains two cases where a coded
frame may cause multiple frames to be output (cf. C.5.2.2.2):
* start of a new sequence
* overflowing sps_max_dec_pic_buffering
The decoder currently contains rather convoluted logic to handle these
cases:
* decode/output/per-frame sequence counters,
* HEVC_FRAME_FLAG_BUMPING
* ff_hevc_bump_frame()
* special clauses in ff_hevc_output_frame()
However, with the receive_frame() API none of that is necessary, as we
can just output multiple frames at once. Previously added ContainerFifo
allows that to be done in a straightforward and efficient manner.
It provides a FIFO for "container" objects like AVFrame/AVPacket and
features an integrated FFRefStructPool-based pool to avoid allocating an
freeing them repeatedly.
Fixes: use of uninitialized value
Fixes: 70929/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-5931276639469568
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of 1 by 31 places cannot be represented in type 'int'
Fixes: 70726/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-6149928703819776
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found by fuzzer.
Bug: https://crbug.com/356720789
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This results in an unnecessary ~800k allocation with H.264. A
nearby callsite uses avcodec_is_open() to avoid this, so do the
same when exiting avformat_find_stream_info().
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Usually the MediaCodec context will be released immediately, or it needs to stay
alive due to existing hardware buffers.
However we can free resources early in the case of
hw_buffer_count == 0 && refcount > 1, which can be reproduced by keeping frames
referenced after flushing and closing. mpv currently behaves like this.
Signed-off-by: sfan5 <sfan5@live.de>
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Without resetting it, if there was a previous set of varstreams with
subtitles, it would subtract from all the streams, leading to chaos and
segfaults when trying to access for example stream -1.
In the absence of an RPU header, we can consult the colorspace tags to
make a more informed guess about whether we're looking at profile 5 or
profile 8.
This implements limited metadata compression. To be a bit more lenient,
we try and re-order the static extension blocks when testing for an
exact match.
For sanity, and to avoid producing bitstreams we couldn't ourselves
decode, we don't accept partial matches - if some extension blocks
change while others remain static, compression is disabled for the
entire frame.
This shouldn't be an issue in practice because static extension blocks
are stated to remain constant throughout the entire sequence.
