Check the alpha plane for (almost) transparent frames, instead of checking
the luma channel for almost black frames.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: nxtedition
Up until now, our muxer wrote FFV1 in video-for-windows
compatibility mode out of concern for old demuxers that
only support that (whereas the demuxer accepts V_FFV1).
This commit switches to using native mode, because
a) V_FFV1 is around long enough so that old demuxers
should not be an issue (support in FFmpeg has been added
in commit 9ae762da7e
in March 2017/FFmpeg 3.3),
b) using native mode uses fewer bytes for the CodecPrivate,
c) the VfW extradata is zero-padded to an even length
if necessary, but our demuxer forgot to undo the padding
until very recently (92e310eb82),
so that there are many versions of our demuxer around that
are buggy wrt VFW, but not V_FFV1.
This affects the FFV1 extradata checksums, specifically
the (experimental) version 4 files with error check version 2*
as created by
ffmpeg -i ../fate-suite/mpeg2/sony-ct3.bs -c:v ffv1 \
-slices 16 -frames 1 -level 4 -strict experimental ffv1.mkv
VFW files like the above created by this muxer before this patch
would not work with an old demuxer.
*: Without error check version 2, the CRC for the whole extradata
is zero, which is not changed by appending a zero byte.
Reviewed-by: compn <ff@hawaiiantel.net>
Reviewed-by: Dave Rice <dave@dericed.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Legal since commit 1cd0a9be4b2d1e7c60184ec68404e00e46e3123e
(Jan 4) in the Cellar Matroska specification git repo.
We still hold out on muxing it due to compatibility with
old demuxers.
Reviewed-by: compn <ff@hawaiiantel.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
- merge forgotten uninit from work branch
- add set_str() function to free before overwriting
- fix some other leaks
Signed-off-by: softworkz <softworkz@hotmail.com>
The structure is padded to an even length with an internal
size field to indicate the real size.
The matroska-matroska-display-metadata test (writing FFV1
in VFW mode) was affected by this.
It should also fix ticket #11613.
Reviewed-by: compn <ff@hawaiiantel.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
crcref needs to be set properly iff ec is two, regardless
of whether it has been explicitly set by the user or set
by default based on level/version.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
On msys2, `uname -m` returns the architecture of the base msys2
layer. On Windows on arm64, the base msys2 layer itself is still
x86_64 only, even if running with e.g. the clangarm64 where the
windows native applications are built as aarch64.
If MSYSTEM_CARCH is set, use this instead of `uname -m` for
the default architecture. This gives the correct behaviour
for the clangarm64 environments. It also gives the correct
default for the 32 bit x86 environments such as `mingw32`.
(On `mingw32`, the fact that `uname -m` returned `x86_64`
hasn't been an issue, as both that and `i686` gets normalized
into `x86` internally in ffmpeg's configure.)
Signed-off-by: Coia Prant <coiaprant@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
It is only used to indicate to ff_h263_show_pict_info()
that we are decoding H.263+; pass this information
via a function parameter instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This means that these buffers won't be allocated any more
for H.263+ with AIC disabled.
Also remove setting h263_plus for the RV20 encoder,
as it has only been done to force allocating dc_val.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Just ensure that dct_unquantize_inter is set iff it is used
and check for the function pointer instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to remove checks from ff_xvid_idct_init()
(and also the AVCodecContext* parameter).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_xvid_idct_init() is now only called from ff_idctdsp_init()
and only if idct_algo is FF_IDCT_XVID.
This also implies that it is unnecessary to initalize
the permutation on our own.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unnecessary: If the dst context is not already initialized,
then it will be initialized by memcpy(dst, src, sizeof(*dst),
which already initializes the IDCT to the desired one, potentially
followed by ff_mpv_common_init(), which does not touch the IDCT.
(This call has been added in f89d76c10355242c39b08f253c1d1524f45ef778;
the aforementioned copying took place back then, too, but
ff_mpv_common_init() reinitialized the IDCT to a non-xvid one,
therefore the initialization here has been added to fix
multithreaded decoding.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These are sufficiently different to warrant their own functions;
in particular, the earlier code had two callsites for the actual
"write block" function, one for intra and one for inter, yet
the "write block" function nevertheless performed a check
(that the compiler can't optimize away) for whether the current
MB is intra or not.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
While it offers modest speedups compared to the ordinary code,
removing it completely offers even bigger speedups; and given
that these speedups also exist in the ordinary mode, they are
even more important. The no-output code has a 7.8% performance
improvement (based on benchmarking mpeg4_encode_mb()), yet
removing the no-output code resulted in a 9.4% improvement.
Furthermore, the no-output code was broken for the majority of
its existence (until 9207dc3b0d)
and no one complained, so it is likely not used at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MPEG-4 decoder can now initialize ff_mpeg4_rl_intra
directly given that the MPEG-4 encoder no longer wants
it performed, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There four cases for the LUT entry: An ordinary entry
or one of three escaping methods. Three of these methods
are only rarely possible --they correspond to the 102
codes of the underlying VLC and so only 102 of 16384 entries
are possible.
The earlier code would nevertheless try them all for every
LUT entry and use the best one; the new code meanwhile only
uses one method (the fallback one (i.e. the worst)) for them all
and only processes the 102 valid entries afterwards.
The implementation used also means that index_run, max_level
and max_run of the RLTable are no longer needed; the earlier
code would initialize said static tables although they are only
used for a short time to initialize something else.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Multiple PutBitContexts are used when encoding partitioned
frames. When there are multiple candidates for macroblock types,
multiple states (namely the state before encoding the current MB,
the best state among the ones already tried and the current one)
need to be kept; duplicates of the PutBitContexts are among this
state. The temporary buffers for them are kept on the stack
in encode_thread() and their size is quite generous (MAX_MB_SIZE
- 3000 bytes). This commit uses tighter bounds, bringing the
size of the pb2 buffer down to 15 bytes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The reversible VLC tables use a simpler escaping method
than the ordinary VLCs: It does not use max_run, max_level etc.
and therefore one does not need to initialize these at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is confusing, because the AV_RL32("ASUS") already
returns an endian-independent value, so converting
it via av_le2ne32() makes no real sense: one would need
to transform the native value to le and write it as
a natie endian uint32_t for it to make sense (the current
code only works because le2ne32 and ne2le32 are the same
for both endianness that we care about). Or one can just
use AV_RL32 and create the number via MKTAG().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Removes implicit checks for "do I need to output the buffer now?".
Codesize with Clang 19 with -O3 decreased from 7136B to 6108B
(although asv2_put_level() is now inlined).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the encoder replicated all the border pixels
for incomplete 16x16 macroblocks. In case the available width
or height is <= 8, some of the luma blocks of the MB
do not correspond to actual input, so that we should encode
them using the least amount of bits. Zeroing the block coefficients
(as this commit does) achieves this, replicating the pixels
and performing an FDCT does not.
This commit also removes the frame copying code for insufficiently
aligned dimensions.
The vsynth3-asv[12] FATE tests use a 34x34 input file and are
therefore affected by this. As the ref updates show, the size
and checksum of the encoded changes, yet the decoded output
stays the same.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
