The MPEG-1/2 decoders don't need ScanTable.raster_end
(as the coefficients are unquantized as they are parsed).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is pointless to try to report the true number because
decode_simple_internal() always treats the buffer as
completely consumed for video codecs anyway.
(Apart from that: The h263dec code would report to only
have consumed the header data in case decoding is aborted
due to skip_frame which makes no sense.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Added in 59fa3f96f4,
yet avctx->workaround_bugs is never copied to
MpegEncContext.workaround_bugs, so this code is dead
(it seems that this was true even when it was added).
Furthermore, workaround_bugs is flagged as decoder-only,
so just remove the code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Don't reuse MpegEncContext.max_b_frames, which is supposed
to be encoder-only.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by MPEG-4 (and is used in h263dec.c and can therefore
not just be moved to Mpeg4DecContext...).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since d50635cd24 the
dct_unquantize_h263_intra functions have set the number of
coefficients to 63 in case of ac_pred, so ff_msmpeg4_decode_block()
doesn't have to bump it on its own.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This code has been added in f5957f3fe2
when support for WMV1 has been added. It was needed for decoding
inter macroblocks, as WMV1 uses a different scantable and
the ScanTable and ScanTable.raster_end was not yet introduced
(the H263 unquantize function instead used a hardcoded version
of ff_zigzag_direct's raster_end). In other words,
there is no reason to continue to do so for WMV1 inter blocks.
(Apart from that: WMV1 inter blocks don't use
dct_unquantize_h263_inter any more, as unquantizing happens
when parsing the block via specialized RL VLC tables.)
It is also not needed for WMV1/2 intra blocks (for non-ac_pred
it uses the correct ScanTable used by the h263 unquantize
intra function; for ac_pred, the number is overridden)
as well as for WMV2 inter-blocks (raster_end is not really
used in this case; the ordinary ScanTable is used in case
abt_type is zero, otherwise there are two different ScanTables
and block_last_index is overridden in wmv2dec.c).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This decoder unquantizes while parsing blocks
and does not use dct_unquantize_mpeg1_intra
(which uses *_dc_scale) at all.
repeat_field was unused since
e0a3d744a0.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The value here has been set in ff_set_qscale() from
ff_mpeg1_dc_scale_table, all of whose entries are 8.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Effectively reverts c59b5e3d1e.
This is possible now that ff_print_debug_info2() uses
the MPVPicture dimensions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MotionEstContext contains pointers (to function pointers) that
have been set on a per-frame basis depending upon no_rounding
in ff_me_init_pic() to avoid branches like these. Also makes
MotionEstContext more independent of MpegEncContext.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The mpegvideo-based encoders do one uncommon thing with
the packet's data given by ff_alloc_packet(): They potentially
reallocate it. But this only affects the internal buffer
and is not user-facing at all, so one can nevertheless
use the AV_CODEC_CAP_DR1 for them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When there are multiple candidates for macroblock type, the encoder
tries them all. In order to do so, it keeps several sets of states
containing the variables that get modified when encoding
the macroblock and in the end uses the best of these.
Yet one variable was set, but not included in this state:
The current macroblock's qscale value in the current picture's
qscale_table. This may currently be set multiple times in
mpv_reconstruct_mb(), yet it is read when adaptive_quant is true.
Currently, the value read can be the value set by the last attempt
to write the current macroblock and not the initial value.
Fix this by only setting the qscale_table value in one place
outside of mpv_reconstruct_mb() (where it does not belong at all).
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reduce binary size at the same time. The performance compared to clang -O3
is the same.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
ff_decode_frame_props() injects global side data passed by the caller (Usually
coming from the container) but ignores the global side data the decoder
gathered from the bitstream itself.
This commit amends this.
Signed-off-by: James Almer <jamrial@gmail.com>
Instead of calculating a^2, b^2, (a+b)^2 and (a-b)^2, calculate only
a^2, b^2 and 2*a*b in each iteration and derive the latter parts from
these three at the end.
Before and after:
A78
ac3_sum_square_bufferfly_int32_neon: 484.8 ( 2.00x)
ac3_sum_square_bufferfly_int32_neon: 468.2 ( 2.08x)
A72
ac3_sum_square_bufferfly_int32_neon: 793.6 ( 1.26x)
ac3_sum_square_bufferfly_int32_neon: 527.3 ( 1.92x)
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
