Replaced by lavu/tx. Dedicated code soon to be removed, replaced with
a simple wrapper code.

It's not needed nor used by anything anymore, lavu/tx is faster,
and better in every way. RIP.

Converts both the decoder and encoders.

The encoder is fixed point, and uses an MDCT only for analysis. Due
to the slightly different rounding, the encoder makes a different
decision, so the tests have to be adjusted as well.

Fully converts the DCA decoder to lavu/tx.

Thanks to Martin Storsjö <martin@martin.st> for fixing and testing the
arm32 and aarch64 changes.

This also fixes not checking the return values on transform init.

Total decoder speedup on Zen 3: 9%

This patch replaces the transform used in AAC with lavu/tx and removes
the limitation on only being able to decode 960-sample files
with the float decoder.
This commit also removes a whole bunch of unnecessary and slow
lifting steps the decoder did to compensate for the poor accuracy
of the old integer transformation code.

Overall float decoder speedup on Zen 3 for 64kbps: 32%

Mostly consistent formatting and consistently ordering of
warnings/notes to be next to the description.

Additionally group the AV_DICT_* macros.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

This is a more explicit iteration API rather than using the "magic"
av_dict_get(d, "", t, AV_DICT_IGNORE_SUFFIX) which is not really
trivial to grasp what it does when casually reading through code.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

dts != pts is actually a spec violation for AV1, given it has no
reordering in the classical sense.

We don't really need the whole timestamp queue in this case and can just
pass through the timestamp as is for both dts and pts.

The encoder seems to be trading blows with hevc_nvenc.
In terms of quality at low bitrate cbr settings, it seems to
outperform it even. It produces fewer artifacts and the ones it
does produce are less jarring to my perception.

At higher bitrates I had a hard time finding differences between
the two encoders in terms of subjective visual quality.

Using the 'slow' preset, av1_nvenc outperformed hevc_nvenc in terms
of encoding speed by 75% to 100% while performing above tests.

Needless to say, it always massively outperformed h264_nvenc in terms
of quality for a given bitrate, while also being slightly faster.

Makes it possible to use deinterlacers which output one frame for each field as fallback if field
matching fails (combmatch=full).

Currently, the documented example with fallback on a post-deinterlacer will only work in case the
deinterlacer outputs one frame per first field (as yadif=mode=0). The reason for that is that
fieldmatch will attempt to match the second field regardless of whether it recognizes the end
result is still interlaced. This produces garbled output with for example mixed telecined 24fps and
60i content combined with a field-based deinterlaced such as yadif=mode=1.
This patch orders fieldmatch to revert to using the second field of the current frame in case the
end result is still interlaced and a post-deinterlacer is assumed to be used.
Signed-off-by: lovesyk <lovesyk@users.noreply.github.com>

Fixes: Timeout
Fixes: 52161/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-6440216563154944

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: signed integer overflow: -2147483648 * 100000 cannot be represented in type 'int'
Fixes: 52060/clusterfuzz-testcase-minimized-ffmpeg_dem_MP3_fuzzer-5131616708329472

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: integer overflow
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>