As the names imply, they are structs meant to be internal and private to the
filter handling code. If a field is required in other modules, then it can
be moved to the public facing structs, which is done in this commit.
Signed-off-by: James Almer <jamrial@gmail.com>
As the name implies, it's a struct meant to be internal and private to the
filter handling code. If a field is required in other modules, then it can
be moved to the public facing struct, which is done in this commit.
Signed-off-by: James Almer <jamrial@gmail.com>
The follow cmd output corrupted file before the patch:
ffmpeg -f lavfi -i color=blue,trim=duration=0.04 \
-f lavfi -i anullsrc,atrim=duration=2 \
-movflags +empty_moov+hybrid_fragmented \
-frag_duration 1000000 \
-frag_interleave 1 \
output.mp4
1. first_track is the first track with track->entry != 0. As in the
command above, video track (track index 0) has a single frame. When
flush the second fragment, first_track is 1, the audio track.
2. write_moof = i == first_track, so write_moof is false for i = 0.
3. When mov->frag_interleave != 0, mov->mdat_buf != NULL, because
it contains audio data. So avio_write is called before write_moof,
that is, the data write before moof, and mov_finish_fragment
executed with wrong mdat_start.
4. With normal fmp4 output, the error isn't obvious. With
hybrid_fragmented, ffplay output.mp4 shows a lot of error messages.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The default behavior for VVenC (since v1.10.0) is to create an IDR with
leading pictures for the first picture in decoding order (POC 32). This
leads to FFmpeg generating an edit list with an empty entry, skipping
the leading pictures.
This patch fixes the calculation for the start_pts, while the DTS is
negative (as produced by vvenc).
Signed-off-by: Gabriel Hege <g+ffmpeg@hege.cc>
The MMX requantize functions have the MMX permutation
(i.e. FF_IDCT_PERM_SIMPLE) hardcoded and therefore
check for the used permutation (namely via a CRC).
Yet this is very ugly and could even lead to misdetection;
furthermore, since d7246ea9f2
the permutation used here is de-facto and since
bfb28b5ce8 definitely
impossible on x64, making this code dead on x64.
So remove it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For certain arches (AARCH64, x86, generic) get_pixels and
get_pixels_unaligned always coincide for 8 bit input.
In these cases it is possible to avoid checks for unaligned
input in asvenc, dvenc.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before this commit, the input in get_pixels and get_pixels_unaligned
has been treated inconsistenly:
- The generic code treated 9, 10, 12 and 14 bits as 16bit input
(these bits correspond to what FFmpeg's dsputils supported),
everything with <= 8 bits as 8 bit and everything else as 8 bit
when used via AVDCT (which exposes these functions and purports
to support up to 14 bits).
- AARCH64, ARM, PPC and RISC-V, x86 ignore this AVDCT special case.
- RISC-V also ignored the restriction to 9, 10, 12 and 14 for its
16bit check and treated everything > 8 bits as 16bit.
- The mmi MIPS code treats everything as 8 bit when used via
AVDCT (this is certainly broken); otherwise it checks for <= 8 bits.
The msa MIPS code behaves like the generic code.
This commit changes this to treat 9..16 bits as 16 bit input,
everything else as 8 bit (the former because it makes sense,
the latter to preserve the behaviour for external users*).
*: The only internal user of AVDCT (the spp filter) always
uses 8, 9 or 10 bits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes segfaults on systems where PixblockDSPContext.get_pixels
really requires to be properly aligned (e.g. ARMv7).
Before this commit input created by
-filter_complex nullsrc=s=740x576:r=25,format=yuv420p,crop=w=720:x=2
led to crashes.
(The unaligned strides are in violation of the AVFrame.linesize
documentation, unaligned pointers itself do not seem to be
prohibited for encoders.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It's not valid to call avio_close() on context that has not been open
with avio_open().
This fixes use of custom IO. (io_open / io_close2 callbacks)
Note that by default io_close2 is set to io_close2_default() which calls
avio_close(), so default case will work the same as before.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The code uses int, unsigned int and uint16_t to store num_entry_point_offsets
This limits it to the smallest of the 3.
Alternatively uint16_t can be changed and then a larger limit used.
A Check will still be needed.
Fixes: 391974932/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5966648879677440
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It invalidates (removes by duplicates) AVCodecContext.extradata
and AVCodecContext.coded_side_data which is quite surprising
and leads to bugs like #11617 where an AVCPBProperties
is used after it has been freed in ff_dovi_configure().
Reported-by: Ayose
Reviewed-by: Niklas Haas <ffmpeg@haasn.xyz>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This happens on systems where get_pixels really needs
to be properly aligned, like ARMV7 or RISC-V. For these
systems, 0401ca714a caused
a bus error for the vsynth3-asv[12] tests, because
the stride in these tests is unaligned. See e.g.
https://fate.ffmpeg.org/report.cgi?slot=armv7-linux-gcc-13&time=20250527020548https://fate.ffmpeg.org/report.cgi?slot=rv64gcvb-linux-gnu-gcc&time=20250527001827
It can also happen (even before said commit) if the pointers
itself are unaligned, e.g. by using the crop filter:
ffmpeg -filter_complex nullsrc=s=740x576:r=25,format=yuv420p,crop=w=720:x=2 \
-c:v asv2 -f null -
The alignment requirements for the frames passed to encoders are
mostly undocumented; the only thing I could find is the documentation
of AVFrame.linesize: "For video the linesizes should be multiples
of the CPUs alignment preference". This means that the FFmpeg cli
violates our API.
Yet as the above command line shows, it can also happen with
unaligned pointers and there does not seem to be a prohibition
of this, so we need to handle this case. This commit does so
by using get_pixels_unaligned when needed.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
