All that remains in it are things that belong in avfilter_internal.h.
Move them there and remove internal.h
Signed-off-by: Paul B Mahol <onemda@gmail.com>
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.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
internal.h currently mixes interfaces intended to be used by filters
with those that should be limited to generic filter- or graph-level
code.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Serializing frame threading for non-threadsafe hwaccels is handled at the
generic level, the decoder does not need to care about it.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
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.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Instead of a single AVFrame.
Will be useful in future commits, where we will want to produce multiple
output frames for a single coded frame.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
It provides a FIFO for "container" objects like AVFrame/AVPacket and
features an integrated FFRefStructPool-based pool to avoid allocating an
freeing them repeatedly.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
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>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
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>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Text based on suggestion by: epirat07@gmail.com
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Found by fuzzer.
Bug: https://crbug.com/356720789
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
checkasm --bench on a Raspberry Pi 5 Model B Rev 1.0:
yuv420p_gbrp_128_c: 1243.0
yuv420p_gbrp_128_neon: 453.5
yuv420p_gbrp_1920_c: 18165.5
yuv420p_gbrp_1920_neon: 6700.0
yuv422p_gbrp_128_c: 1463.5
yuv422p_gbrp_128_neon: 471.5
yuv422p_gbrp_1920_c: 21343.7
yuv422p_gbrp_1920_neon: 6743.5
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This will be used in the upcoming yuv42{0,2}p -> gbrp unscaled
colorspace converters.
There is no difference in performance.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This will be used in the upcoming yuv42{0,2}p -> gbrp unscaled
colorspace converters.
There is no difference in performance.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
checkasm --bench for Raspberry Pi 5 Model B Rev 1.0:
sse_0_c: 241.5
sse_0_neon: 37.2
sse_0_dotprod: 22.2
vsse_4_c: 148.7
vsse_4_neon: 31.0
vsse_4_dotprod: 15.7
Signed-off-by: Paul B Mahol <onemda@gmail.com>
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>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
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>
Signed-off-by: Paul B Mahol <onemda@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.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fixes regression since d566a37003d0257229f06436bef8062fee3af6e9.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Paul B Mahol <onemda@gmail.com>
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.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
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.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Some DM types do not fill the whole struct, so just clear it entirely
before going filling the decoded values.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This implements the limited DM metadata compression scheme described in
chapter 9 of the dolby vision bitstream specification.
The spec is a bit unclear about how to handle the presence of static
metadata inside compressed frames; in that it doesn't explicitly forbid
an encoder from repeating redundant metadata. In theory, we would need
to detect this case and then strip the corresponding duplicate metadata
from the existing set of static metadata. However, this is difficult to
implement - esspecially for the case of metadata blocks which may be
internally repeated (e.g. level 10).
That said, the spec states outright that static metadata should be
constant throughout the entire sequence, so a sane bitstream should not
have any static metadata values changing from one frame to the next (at
least up to a keyframe boundary), and therefore they should never be
present in compressed frames. As a consequence, it makes sense to treat
this as an error state regardless. (Ignoring them by default, or
erroring if either AV_EF_EXPLODE or AV_EF_AGGRESSIVE are set)
I was not able to find such samples in the wild (outside of artificially
produced test cases for this exact scenario), so I don't think we need
to worry about it until somebody produces one.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Static and dynamic extension blocks are handled differently by metadata
compression, so we need to separate the extension block array into two.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Slightly re-organize the logic around extension blocks in order to allow
expanding the state tracking in a following commit.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This can be used to strip dovi metadata, or enable/disable dovi
metadata compression. Possibly more use cases in the future.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
More flexible version of ff_dovi_configure() which does not require an
AVCodecContext. Usable, for example, inside a bitstream filter.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Keyframes must reset the metadata compression state, so we need to
also signal this at rpu generation time.
Default to uncompressed, because encoders cannot generally know if
a given frame will be a keyframe before they finish encoding, but also
cannot retroactively attach the RPU. (Within the confines of current
APIs)
Signed-off-by: Paul B Mahol <onemda@gmail.com>
And move the choice of desired container to `flags`. This is needed to
handle differing API requirements (e.g. libx265 requires the NAL RBSP,
but CBS BSF requires the unescaped bytes).
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Limited mode can only ever maintain a single VDR RPU reference, and
furthermore requires vdr_rpu_id == 0. So in practice, it will only ever
use VDR RPU slot 0. All remaining slots get flushed in this case, to
avoid leaking partial state.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This struct itself contains vdr_rpu_id, so we can never match it except
in the case of i == vdr_rpu_id. So just directly use this ID.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
