summary: This patch modifies the `curves` filter with new `interp` option
to let user pick the existing natural cubic spline interpolation
and the new PCHIP interapolation.
reason: The natural cubic spline does not impose monotonicity between
the keypoints. As such, the fitted curve may vary wildly against
user's intension. The PCHIP interpolation is not as smooth as
the natural spline but guarantees the monotonicity. Providing
both options enhances users experience (e.g., reduces the number
of keypoints to realize the desired curve). See the related bug
report for the example of an ill-interpolated curve.
alternate solution:
Both Photoshop and GIMP appear to use monotonic interpolation in
their curve tools, which were the models for this filter. As
such, an alternate solution is to drop the natural spline and
go without the `interp` option.
related bug report: https://trac.ffmpeg.org/ticket/9947 (filed by myself)
Signed-off-by: Takeshi (Kesh) Ikuma <tikuma@hotmail.com>
Renaming the decoder to speedhqdec.c makes sense since
we have an encoder in speedhqenc.c. Given that ff_rl_speedhq
is also used by the encoder, it is kept in speedhq.c
and a proper header for it is created to replace the ad-hoc
declaration in speedhqenc.c. This also allows to remove
the check for CONFIG_SPEEDHQ_DECODER, as it is always true
when speedhqdec.c is compiled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The number of channels that is checked here is automatically
valid because it has just been set by us (based upon an entry
in codec_props).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It just contains duplicates of values from AVCodecContext
as well as an write-only pointer to said AVCodecContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This file is built iff said hwaccel is enabled.
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: signed integer overflow: 9223372036854550860 + 530259564 cannot be represented in type 'long'
Fixes: 49093/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_O_fuzzer-4697179192688640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
codec_id is always AV_CODEC_ID_MPEG4 for mpeg4_decode_mb(),
as the MPEG-4 decoder is the only decoder for which
ff_mpeg4_decode_picture_header() as well as decode_init()
are ever called and these are the only places where
the decode_mb function pointer is ever set to mpeg4_decode_mb().
ff_mpeg4_workaround_bugs() is also only called for the MPEG-4
decoder (the caller checks the codec id).
(ff_mpeg4_decode_picture_header() is also called for the MPEG-4
parser, but it never uses the decode_mb function pointer.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is set in the vol header and is therefore a sequence and
not only a picture property.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by gmc/gmc1 which is only used by the MPEG-4
decoder, so move it to Mpeg4DecContext and rename it
to Mpeg4VideoDSP. Also compile it iff the MPEG-4 decoder is compiled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
None of the MPEG-1/2 codecs support frame threading,
so one can optimize the check for it away.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This has the advantage of not having to check for whether
a given MpegEncContext is actually a decoder or an encoder
context at runtime.
To do so, mpv_reconstruct_mb_internal() is moved into a new
template file that is included by both mpegvideo_enc.c
and mpegvideo_dec.c; the decoder-only code (mainly lowres)
are also moved to mpegvideo_dec.c. The is_encoder checks are
changed to #if IS_ENCODER in order to avoid having to include
headers for decoder-only functions in mpegvideo_enc.c.
This approach also has the advantage that it is easy to adapt
mpv_reconstruct_mb_internal() to using different structures
for decoders and encoders (e.g. the check for whether
a macroblock should be processed for the encoder or not
uses MpegEncContext elements that make no sense for decoders
and should not be part of their context).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, we inlined lowres_flag as well as is_mpeg12
independently (unless CONFIG_SMALL was true); this commit
changes this to instead inline mpv_reconstruct_mb_internal()
(at most) four times, namely once for encoders, once for decoders
using lowres and once for non-lowres mpeg-1/2 decoders and once
for non-lowres non-mpeg-1/2 decoders (mpeg-1/2 is not inlined
in case of CONFIG_SMALL). This is neutral performance-wise,
but proved beneficial size-wise: It saved 1776B of .text
for GCC 11 or 1344B for Clang 14 (both -O3 x64).
Notice that inlining is_mpeg12 for is_encoder would not really
be beneficial, as the encoder codepath does mostly not depend
on is_mpeg12 at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are two types of checks for whether the current codec
is MPEG-1/2 in mpv_reconstruct_mb_internal(): Those that are
required for correctness and those that are not; an example
of the latter is "is_mpeg12 || (s->codec_id != AV_CODEC_ID_WMV2)".
The reason for the existence of such checks is that
mpv_reconstruct_mb_internal() has the av_always_inline attribute
and is_mpeg12 is usually inlined, so that in case we are dealing
with MPEG-1/2 the above check can be completely optimized away.
But is_mpeg12 is not always inlined: it is not in case
CONFIG_SMALL is true in which case is_mpeg12 is always zero,
so that the checks required for correctness need to check
out_format explicitly. This is currently done via a macro
in mpv_reconstruct_mb_internal(), so that the fact that
it is CONFIG_SMALL that determines this is encoded at two places.
This commit changes this by making is_mpeg12 a three-state:
DEFINITELY_MPEG12, MAY_BE_MPEG12 and NOT_MPEG12. In the second
case, one has to resort to check out_format, in the other cases
is_mpeg12 can be taken at face-value. This will allow to make
inlining is_mpeg12 more flexible in a future commit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Both the FFV1 decoder and encoder use a template of their own
to generate code multiple times. They also use a common template,
used by both decoder and encoder templates which is currently
instantiated in ffv1.h (and therefore also in ffv1.c, which
doesn't need it at all).
All these templates have the prerequisite that two macros
are defined, namely RENAME() and TYPE. The codec-specific
templates call the functions generated via the common template
via the RENAME() macro and therefore the macros used for
the common template must coincide with the macros used for
the codec-specific templates. But then it is better to not
instantiate the common template in ffv1.h, but in the codec
specific templates.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Some parts of mpegvideo.c behave differently depending
upon whether AVCodecContext.draw_horiz_band is set or not.
This differing behaviour makes lots of FATE tests fail
and leads to garbage output, although setting this callback
is not supposed to change the output at all.
These checks have been added in commits
3994623df2 and
b68ab2609c. The commit messages
do not contain a real reason for adding the checks and it is
indeed a mystery to me. But removing these checks fixes
the FATE tests when one adds an (empty) draw_horiz_band
when using a codec that claims to support it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
librav1e provides a function to create extradata, so use it instead of
extracting the sequence header OBU from packets.
Signed-off-by: James Almer <jamrial@gmail.com>
Up until now, ff_startcode_find_candidate_c() simply casts
an uint8_t* to uint64_t*/uint32_t* to read 64/32 bits at a time
in case HAVE_FAST_UNALIGNED is true. Yet this ignores the
alignment requirement of these types as well as effective type
rules of the C standard. This commit therefore replaces these
direct accesses with AV_RN64/32; this also improves
readability.
UBSan reported these unaligned accesses which happened in 233
FATE-tests involving H.264 and VC-1 (this has also been reported
in tickets #8138 and #8485); these tests are fixed by this commit.
The output of GCC with -O3 is unchanged for aarch64, loongarch,
ppc and x64 (as well as for arches like alpha for which
HAVE_FAST_UNALIGNED is never true in the first place).
There was only a slight difference for mips and arm.
I don't know about the speed impact of them.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Now that we have proper options for defining display matrix
overrides, this should no longer be required.
fftools does not have its own versioning, so for now the define is
just set to 1 and disables the functionality if set to zero.
This enables overriding the rotation as well as horizontal/vertical
flip state of a specific video stream on the input side.
Additionally, switch the singular test that was utilizing the rotation
metadata to instead override the input display rotation, thus leading
to the same result.
This e.g. allows compilers to bake the "+ 256" offset
used to access ff_v2_dc_(lum|chroma)_table into
the general offset; for certain arches this is also necessary
in order to avoid building suboptimal code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
