The issue is that this could consume gigabytes of VRAM at higher
resolutions for not that much of a speedup.
Automatic detection was not a good idea as we can't know how much
VRAM is actually free.
Just remove it.
External libraries are not components and so their CONFIG_ define
is in config.h.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It currently uses an intermediate int which wouldn't work
if linesize exceeded the range of int and inhibits compiler
optimizations. Also switch to pointer arithmetic and use
smaller scope.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avctx->bits_per_raw_sample is always 10 or 12 here;
the checks have been added in preparation for making
bits_per_raw_sample user-settable via an AVOption,
but this never happened.
While just at it, also set unpack_alpha earlier
(where bits_per_raw_sample is set).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Using LONG_BITSTREAM_READER means that every get_bits() call
uses an AV_RB64() to ensure that cache always contains 32 valid bits
(as opposed to the ordinary 25 guaranteed by reading 32 bits);
yet this is unnecessary when unpacking alpha. So only use these
64bit reads where necessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If there's ever a rework of the AAC encoder, it won't start from here.
The codec, with all its oddities and tweaks needed to acheive good quality
has strayed far from the academic work upon which this coder was based on.
Its been 20 years since this paper was released, and no known existing
implementations, open-source or proprietary that we know of, are based on it.
The LTP profile of AAC is... terrible.
It was an early 90's attempt at bridging the gap between speech
codecs and general purpose codecs. It did so by trying to exploit the fact
that most speech patterns are regular.
Unfortunately, it went about it the same way as AAC Main, by taking
the previous frame's samples, modifying them through an LPC filter,
transforming them back using a forward MDCT, putting the output
coefficients back into the current frame, and using delta coding.
But once again, they ignored basic mathematics and MDCT leakage.
Thankfully, because AAC LTP is meant to operate at very low bitrates,
the extreme quantization results in most leakage being irrelevant.
Unfortunately, the result is that the output sounds pretty much
terrible regardless of whether LTP is enabled or not.
This was the first attempt at trying to couple speech coding into AAC.
No, the second attempt did not succeed either.
Nnnneither did the third. Or fourth.
For the fifth one, they literally just jammed a speech codec into AAC
with USAC once they saw Opus do it.
Just drop support for encoding AAC LTP. It was always experimental
to begin with.
The Main profile of AAC is... terrible.
It enables the use of delta coding across coefficients of two frames
to try to increase compression, and it enabled one more pole for TNS
filters.
What the AAC authors failed to take into account were basic
mathematics, as MDCT leakage (e.g. the spread of each frequency when
represented in a discrete spectrum) is significant in most audio codecs.
This leads to huge variations between each frame, basically rendering
prediction completely pointless.
In fact, enabling AAC-Main prediction does not, in general, even recoup
the metadata losses from signalling the profile and prediction properties
in the first place. So you lose efficiency by using AAC Main.
The rumor is that it was put in the AAC spec for patent reasons, though
patent-wise, it has about as much use as a patent for a bicycle designed
for use by snakes.
The only other thing AAC Main changes is it permits 3-pole TNS filters.
When AAC's bands are absolutely tiny, except for very high frequency bands,
where you're likely to use PNS instead.
Just get rid of it.
WMA files that fail to decode due to incoherent block lengths and
frame lengths currently result in a "Operation not permitted".
After this change, they will instead result in "Invalid data found
when processing input".
Several other error cases are also changed from returning -1.
As we change the error propagation logic in wma_decode_frame and
wma_decode_superframe, previous occurrences of returning
AVERROR_INVALIDDATA are also affected by this. This includes
"total_gain overread" and a "channel exponents_initialized" check.
---
Tomas: changed some -1's to AVERROR_INVALIDDATA
This fixed wasm checkasm failure
$ wasm-tools validate tests/checkasm/checkasm
error: wasisdk://v25.0/build/sysroot/wasi-libc-wasm32-wasip1-threads/libc-top-half/musl/src/stdio/__stdio_close.c:24:9 function `__stdio_close` failed to validate
Caused by:
0: func 4581 failed to validate
1: type mismatch: expected i32 but nothing on stack (at offset 0x43b770)
Since close is declared as static function, it's more like a bug
in wasi sdk, but we can workaround it easily.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reviewed-by: James Almer <jamrial@gmail.com>
This is essentially a re-implementation of
2024100522.54158-1-post@frankplowman.com/
That patch was not applied last time. Instead we opted to identify
issues which could be caused by invalid subpicture layouts and remedy
those issues where they manifest, either through error detection or code
hardening. This was primarily implemented in the set
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=13381.
This has worked to some degree, however issues with subpicture layouts
continue to crop up from the fuzzer and I've fixed a number of bugs
related to subpicture layouts since then. I think it's best to return
to the initial plan and simply check if the subpicture layout is valid
initially.
This implementation is also lighter than the first time -- by doing a
bit more logic in pps_subpic_less_than_one_tile_slice, we are able to
store a tile_in_subpic map rather than a ctu_in_subpic map. This
reduces the size of the map to the point it becomes possible to allocate
it on the stack. Similar to 8bd66a8c95,
the layout is also validated in the slice map construction code, rather
than in the CBS, which avoids duplicating some logic.
Signed-off-by: Frank Plowman <post@frankplowman.com>
In the case pps_subpic_less_than_one_tile_slice is called, the
subpicture is smaller than the tile and so there are multiple
subpictures in the tile. Of course, then, not all the
subpictures can start in the top-left corner as the code before the
patch does. Patch fixes this, so each subpicture starts at the
signalled location as is specified in section 6.5.1 of H.266(V3).
Signed-off-by: Frank Plowman <post@frankplowman.com>
A large part of this template is decoder-only. This makes
the complexity of the IS_ENCODER-checks not worth it.
So simply merge the template into both its users.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is a more appropriate place than a function designed
to reconstruct a macroblock. It furthermore limits these checks
to the codecs that actually need it (and removes it from e.g.
RV10 and RV20 -- the latter actually uses these buffers, but
only for intra-frames, so they don't need to be cleaned
manually).
This furthermore means that ff_mpv_reconstruct_mb() and therefore
also the error-resilience code no longer needs block_index set.
This fixes a crash caused by 65d5ccb808
when ff_mpv_reconstruct_mb() is called by VC-1 code without
block_index being initialized properly (VC-1 uses and initializes
block_index itself normally).
Fixes: 69814/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VC1_fuzzer-4868081575329792
Fixes: heap-buffer-overflow
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MPEG-1/2 encoders are the only non-intra-only mpegvideo
encoders that want last_dc reset when encoding non-intra macroblocks.
Therefore move resetting it to mpeg12enc.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the MPEG-1/2, MSMPEG4V1, MPEG-4 and RV.10 decoders use last_dc
at all. Of these, RV.10 only uses it for intra frames; it does not
need these predictors reset in ff_mpv_reconstruct_mb(). MSMPEG4V1
has h263_pred set, so that last_dc is already not reset in
ff_mpv_reconstruct_mb() (instead it is reset at the beginning
of every line). MPEG-4 also has h263_pred set (and uses last_dc only
for the intra-only studio profile and needs them reset to sligthly
different values anyway).
So only the MPEG-1/2 decoders need these values reset. So move
resetting them there. This avoids resetting them unnecessarily
for FLV1, H.261, H.263I, RV.10, RV.20 and H.263(+)
(for the latter it depends upon whether h263_aic is in use).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
SVT-AV1 made a change in their public API in 988e930c but without a
version bump or any other accessible marker, thus breaking ffmpeg build
with current versions of SVT-AV1.
They have finally bumped versions a month later, so check added.
The clamping of idxYInv from H.266(V3) section 8.8.2.3 was missing.
This could lead to OOB reads from lmcs->pivot or input_pivot.
I also changed the derivation of the forward LMCS idx to use a shift
rather than a division for speed and as this is actually how the
variable is declared in the specification (8.7.5.2).
Signed-off-by: Frank Plowman <post@frankplowman.com>
This adds support for default range coder tables, rather than
only custom ones. Its two lines, as the same code can be used
for both thanks to ffv1enc.c setting f->state_transition properly.
Remove a for loop and make it easy to extend to support other types
of scalability. Move ScalabilityMask to hevc header file so it can
be used in hevc decoder.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Fixes: out of array access
Fixes: 385170375/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV60_fuzzer-4710055187906560
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The limit is based on later code storing 32bits
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Fixes: 393164866/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-4606798354513920
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
types and SFO become confused for a USAC stream
Fixes: out of array access
Fixes: 383854203/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_LATM_fuzzer-4996677847547904.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In the fail: block of decode_nal_units, a check as to whether fc->ref is
nonzero is used. Before this patch, fc->ref was set to NULL in
frame_context_setup. The issue is that, by the time frame_context_setup
is called, falliable functions (namely slices_realloc and
ff_vvc_decode_frame_ps) have already been called. Therefore, there
could arise a situation in which the fc->ref test of decode_nal_units'
fail: block is performed while fc->ref has an invalid value. This seems
to be particularly prevalent in situations where the FrameContexts are
being reused. The patch resolves the issue by moving the assignment of
fc->ref to NULL to the very top of decode_nal_units, before any falliable
functions are called.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Parameter sets may be coded in the packet before an IRAP (as is the case for
the hev1 ISO-BMFF brand), and they should have priority as they may override
the extradata ones.
As such, prepend the extradata PS NALUs to the packet PS NALUs if they are
present before an IRAP, instead of prepending them to the IRAP slice.
Should fix ticket #11458.
Signed-off-by: James Almer <jamrial@gmail.com>
