VC1 shares some VLCs with MSMPEG-4, but vc1_block.c
simply duplicates the defines instead of including
the appropriate headers; furthermore, use a proper
prefix for these defines: DC_VLC_BITS is also used
by other codecs.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
and include said header at the place where the VLCs are created.
This allows to make said tables static.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_vc1_norm6_spec has been removed in commit
356be9307c (and it seems that it
has never been used); the declarations of the 8x8_zz arrays meanwhile
have been added in f0c02e1cbc
without having ever been defined.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The defines in vc1data.c are duplicates of the ones in vc1data.h;
they are also pointless, because they are not used anywhere.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unnecessary to initialize the VLCs: The only VLC
that was only ever used by the code reachable from the parser
was ff_vc1_bfraction_vlc; and this VLC has been removed.
Yet vc1dsp is still needed for startcode_find_candidate.
Maybe this should be factored out of vc1dsp in a later
commit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Added in b50be4e38dc83389925dc14f24fa11e660d32197;
this check was racy back then (as the VLC could be initialized
concurrently) and it is redundant (always-false)
since commit c742ab4e81.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This check has been added in c617bed34f,
merging ee769c6a7c to fix
a possible segfault if AVCodecContext.codec is not set
as it may be during parsing. While this fixes the segfault,
it has the unfortunate side effect that it makes the output
of the parser dependent on whether a decoder is set (and
ultimately available). The fix later applied in
5d2be71b9e does not have this
downside and makes checking AVCodecContext.codec superfluous.
So remove this check.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are sill many users of these APIs within libav*, so this commit
introduced too many deprecation warnings, making compilation too noisy and
potentially hiding legit warnings.
Once the remaining users are ported, this can be reapplied.
This reverts commit 76d0038579.
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.
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>
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>
