Right now, the private contexts of every decoder supporting
H.274 film grain synthesis (namely H.264, HEVC and VVC)
contain a H274FilmGrainDatabase; said structure is very large
700442B before this commit) and takes up the overwhelming
majority of said contexts: Removing it reduces sizeof(H264Context)
by 92.88%, sizeof(HEVCContext) by 97.78% and sizeof(VVCContext)
by 99.86%. This is especially important for H.264 and HEVC
when using frame-threading.
The content of said film grain database does not depend on
any input parameter; it is shareable between all its users and
could be hardcoded in the binary (but isn't, because it is so huge).
This commit adds a database with static storage duration to h274.c
and uses it instead of the elements in the private contexts above.
It is still lazily initialized as-needed; a mutex is used
for the necessary synchronization. An alternative would be to use
an AV_ONCE to initialize the whole database either in the decoders'
init function (which would be wasteful given that most videos
don't use film grain synthesis) or in ff_h274_apply_film_grain().
Reviewed-by: Niklas Haas <ffmpeg@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There's very little performance difference vs SSE2/SSSE3 and most
systems will use the AVX2 implementations anyway.
This reduces code size and compilation time by a significant amount.
using fast realloc leaves the entries uninitialized and frees garbage pointers on
errors
Fixes: bug_triggering_file
Found-by: *2ourc3, 5pider
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This allows compilers to optimize accesses like
ff_vvc_diag_scan_x[2][2][x] by baking the offset derived
from [2][2] into the relocation (so that it is performed
at link-time).
Reviewed-by: Wu Jianhua <toqsxw@outlook.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVBR does not use VAEncMiscParameterTypeHRD, so attempting to set
rc_buffer_size and bit_rate together will cause the rc_buffer_size
to be ignored if the VAAPI driver supports AVBR. We should prefer
regular VBR for that case.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Regression since 5acbdd2264, which removed
setting both values from PerThreadContext.
Given the pthread code calls ff_decode_receive_frame_internal() on the frame,
any value set before it will be overwritten, so instead sync each thread's
DecodeContext and let ff_decode_receive_frame_internal() handle these values.
Fixes issue #20534.
Signed-off-by: James Almer <jamrial@gmail.com>
Only the mxpeg sets reference at all.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is quite big and we only need one function from it.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the mxpeg decoder uses it (and the reference/bitmask feature
of ff_mjpeg_decode_sos()). So only initialize it for mxpeg which
allows to remove the mjpeg->hpeldsp dependency.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
mjpeg_decode_dc() currently has a special return value (0xfffff)
for the case of invalid data; this value does not overlap with
the ordinary return values, yet the compiler can't prove this
(at least on x86 where an asm version of NEG_USR32 is used
inside get_xbits()), so the non-error return value has to be checked
for being the special value even if mjpeg_decode_dc() is inlined.
This commit avoids this by separating error code and ordinary return
value. It also means that the ljpeg functions return the proper
error code and not -1 in case of invalid data.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, a DC error in decode_block() or decode_dc_progressive()
would lead to a warning from mjpeg_decode_dc() and a (less verbose)
error from the caller. Upgrade the former to an error status (all
callers treat is an error) and remove the latter.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There is no reason to add the address of an element of
MJpegDecodeContext (which makes logmessage nonreproducible).
Also avoid always printing a zero.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The strategy to count free slots isn't reliable. The value of
INPUT_MAX_PACKETS is a hardcoded value, and MPP_DEC_GET_STREAM_COUNT
doesn't always work as expected. When freeslots is nonzero, the mpp
decoder still returns MPP_ERR_BUFFER_FULL. Before this patch, all
packets are dropped once went into MPP_ERR_BUFFER_FULL state.
Don't drop packet and return error in MPP_ERR_BUFFER_FULL state.
Receive frame to allow the decoder's state machine to resume.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Currently, any nonnegative return value from an init function
is just treated as success and otherwise ignored; while it is
not explicitly forbidden to return something else than 0 (there
is no documentation whatsoever), the assumption is that
they return zero on success. So change dvdsubdec.c accordingly.
Also change dvdsub_parse_extradata() to return zero on success.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since ae448e00af the various
tableinit functions are not compiled unconditionally any more,
so that pcm_tablegen.c (which creates the hardcoded tables)
needs to be updated.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is supported only for H.264 on Intel Macs, but it can be used with
both H.264 and HEVC on Apple Silicon.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
When PARSER_FLAG_COMPLETE_FRAMES is set (e.g. in Matroska),
unesc_index is not reset after the first frame, which causes
subsequent frames to inherit leftover header data.
This leads to incorrect keyframe marking and broken decoding.
See also this bug report: https://trac.ffmpeg.org/ticket/8515
Signed-off-by: DE-AI <max.christoph@pentaxmedical.com>
The max_frame_size in byte will be filled in
VAEncMiscParameterBufferMaxFrameSize which receives size in bit.
This requires max_frame_size * 8.
Signed-off-by: Tong Wu <wutong1208@outlook.com>
libjxl consumes no input if it returns an error, so this loops over
and over while it spits out the same error many times. If we got an
error from libjxl and consumed no input, then we instead consume the
whole packet.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Since 9dc79241d9 we now always pop the
orientation off of the IFD and use a display matrix instead. This means
we should not produce a warning and refuse if the orientation field
indicates a default orientation (i.e. 1).
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reported-by: Ramiro Polla <ramiro.polla@gmail.com>
