Remux two short streams from an existing sample, the second one with a
70000-byte comment header, and demux their concatenation.
Signed-off-by: Martin Mirchev <mmirchev@comp.nus.edu.sg>
Use angle 0, so the gain is exactly 1 inside dmax, and move the center
to the top left corner so that part of the frame lies beyond dmax and
must saturate. Cover the planar (yuv444p) and packed (rgb24) paths.
Signed-off-by: Martin Mirchev <mmirchev@comp.nus.edu.sg>
Probing a small fragment can reach EOF and set is_restart_needed before a
seek. dash_seek selects a new segment but leaves this flag set, so
read_data does not advance cur_seq_no at the next EOF. The selected
segment is then opened a second time.
Clear the pending restart along with the other segment read state before
reopening the component. Do this before probing the new segment, which
may legitimately set the flag again.
Add generated MP2 DASH tests comparing seek-to-zero and sequential packet
checksums and timestamps. The seek test emits 14 duplicate packets without
the reset; both tests produce the same 42 packets with it.
Fixes#25247
Assisted-by: Fairy
Previously, the uop macros were generated from the union of uops over all
backends, so each backend would also instantiate uops that only the other
one can ever use. Split off a separate "x86" backend, and generate a separate
C header for it, together with its NASM macros in a single pass.
The x86 backend only enables SWS_UOP_FLAG_FMA on CPUs with FMA3, so generate
its uops both with and without FMA.
This does not reduce the checkasm coverage: the uops removed from
uops_macros.h are all LINEAR_FMA, READ_PLANAR_FV_FMA or RW_SHUFFLE, which
checkasm does not test, since the C reference backend cannot run them. The
only tests that disappear are the SSE4 and AVX2 variants of two U8 PERMUTE
kernels, which the x86 backend no longer builds because it never uses them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Niklas Haas <git@haasn.dev>
Replaces the hack of running the C preprocessor over the C macros to produce
NASM syntax at build time. The generated file is now committed and checked by
FATE, as with uops_macros.h.
As a side effect, the DECL_* macros are now proper multi-line NASM macros,
so drop the parentheses around their arguments.
The FATE test is split up per generated file, with fate-sws-uops-macros
running all of them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Niklas Haas <git@haasn.dev>
Extend fate-id3v2chap to verify that:
- unread trailing bytes after a NUL-terminated text subframe (TPE1) are
skipped so both TPE1 ("artist") and the following embedded subframe
(TIT2) are parsed;
- a non-conforming v2.4 CHAP frame with a plain 32-bit size whose high
bit is set (0x000000b6) is not truncated even when the stripped offset
contains a fitting empty frame header;
- a valid synchsafe v2.4 CHAP frame followed by an empty TPE1 frame and
a TALB frame preserves the subsequent frames;
- an ambiguous plain 256-byte v2.4 CHAP size (0x00000100, all high bits
clear) rejects the 128-byte synchsafe candidate whose fake header
exceeds the remaining tag length.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Commit 63b7e4cefa stopped setting st->start_time on the BOS page while
shifting the priming packet's timestamp by -ts_offset. Because the priming
packet produces no PCM output, actual audio begins at the unshifted
timestamp (0). Leaving start_time unset caused ogg_get_length() to subtract
the negative pts from st->duration (inflating duration by ts_offset) and
update_initial_timestamps() to set a negative start_time.
Set st->start_time to os->lastpts on the BOS page before subtracting
priv->ts_offset.
Cover 2-, 3-, 4- and 5-bit G.726LE, bit-rate fallback when
bits_per_coded_sample is unset, and rejection of unsupported bit widths.
Compare explicit widths with bitrate fallback for two-channel streams too.
Use an initialized payload and the existing memory-backed AVIO helper for
deterministic readback without custom read/seek callbacks.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
After avformat_seek_file(), the decoder is not told what to discard
from what it decodes: the frames over the pre-roll are not reliable,
and a seek that lands inside the priming at the start of the stream
outputs the rest of it. Only some demuxers, such as mov, set the skip
for the priming themselves.
Mark the streams after a successful seek, and on the first packet of
each audio stream, add to the samples to skip, which the decoder applies
through AV_PKT_DATA_SKIP_SAMPLES:
- on the first packet of the stream, the priming, as when decoding from
the start: its exact count when it is known;
- on any other packet, the larger of the rest of the priming, which ends
at the start time of the stream, and the seek pre-roll of the codec,
as the decoder misses what came before. After the priming of a stream
whose start the seek targets, no pre-roll is added, as which packet
comes first then depends on the demuxer. Each stream compares the
target with its own start.
The first packet is only recognised when the demuxer knows the first
timestamp of the stream, such as after avformat_find_stream_info();
otherwise, the packet gets the pre-roll as after any seek. The priming
needs the timestamp of the packet and the start time of the stream, the
pre-roll does not. The skip may span several packets, as the decoder
carries it over the frames it outputs. Side data the demuxer set on the
packet is kept: the larger skip is used, and its padding at the end of
the stream is not overwritten.
The skip supplies the pre-roll the stream declares, whatever the demuxer
landed on; recovery beyond it depends on the codec and the bitstream.
The caller keeps or trims what is decoded after it as it wishes.
The decoding of the tests without accurate seek now starts one frame
later for AAC in MP4, CAF and ADTS, and two 2048 samples frames later
for HE-AAC in ADTS and with implicit SBR. A seek that lands on the last
packet of the priming of AAC in CAF, with 64 samples of it left, now
skips the 1024 samples of pre-roll instead of outputting that priming.
For Opus in Matroska, 3840 samples are skipped instead of the 312 the
decoder drops from its first frame, and the decoding with accurate seek
is cut on frames 24 samples, half a millisecond, earlier, within the
precision of the Matroska timestamps. A seek past the end of AAC in CAF
and Opus in Matroska skips the pre-roll on the last packet and keeps its
padding. A seek on the later of two streams, close to its start, adds
the pre-roll to the other stream, which is already past its own start.
A seek back to the start of Matroska now skips the exact priming on the
first packet: 312 samples for Opus and 481 for MP2.
AV_PKT_DATA_SKIP_SAMPLES gives the samples to skip at the start of a
frame and the padding to discard at its end. When both apply to the same
frame and overlap, the padding was compared with what was left after the
skip, found too large, and ignored, so the padding was output.
Check the padding against the whole frame, then discard what is left of
it after the skip.
The overlapping case of the api-skip-samples test now outputs nothing
instead of the padding.
Demuxers and decoders declare the pre-roll an audio stream needs in
AVCodecParameters.seek_preroll, but nothing used it, so a seek landed on
the frame that holds the target and the first frame decoded there was not
reliable.
Move the target back by the largest pre-roll of the audio streams that
are not discarded, whichever stream the seek is on, as they all land
near the target, without leaving the range the caller asked for or going
before the start of the stream. A finite end of the range moves back as
much as the target, and an open end stays open. The pre-roll is rounded up so that it is never shorter
than declared. The caller still discards what it decodes before the
target, as it already had to for a seek that does not land on it. Seeks
by byte or by frame number are left alone. When the start of the stream
is unknown, the earlier target may come before the first packet, so if
the seek fails, it is done again to the target the caller asked for.
The seeks of the tests now land one frame earlier for AAC, and about
80 ms earlier for Opus in Matroska. A forward seek still lands forward,
one frame earlier. A seek on the video stream just after a keyframe now
lands on the keyframe before, to leave room for the pre-roll of AAC. A
seek through concat lands earlier, as concat and the file it reads both
move the target back. A seek close to the start of ADTS, whose start is
unknown, lands at the start instead of failing.
ff_rescale_interval() rounds the bounds of the range inwards and the
target to the nearest, so a target close to a bound could fall outside
the range, which the seek then rejects. A seek through the concat
demuxer to 0.53 s in a file starting at -2112 samples fails this way:
the file it reads gets a target one tick after the end of the range.
Clamp the target to the range, and use ff_rescale_interval() for the
same conversion done for read_seek2() with a single stream.
The seek through concat now lands at the target instead of failing and
reading from the start. The rescaled targets of the interval test stay
within their range: 10 instead of 11, and 4 instead of 3.
Print each interval before and after ff_rescale_interval() and compare
them against a reference, so that a change in the rounding shows there.
The reference records the current output, where the rescaled target can
fall outside the rescaled range: 11 after an end of 10, and 3 before a
start of 4.
AAC decoding overlaps each frame with the previous one, so the first
frame decoded after a seek is only reliable once the frame before it has
been decoded. Opus declares its pre-roll in AVCodecParameters.seek_preroll,
AAC did not.
Have the decoder export its pre-roll, as it knows the frame length: 1024
or 960 samples, half of it for LD and ELD, and 1024 or 768 for USAC.
ELD needs three frames, as its low delay filterbank uses a window four
frames long. SBR keeps the state of the frame before, in its
filterbanks, its high-frequency generator and its gain smoothing, and
codes its envelopes and noise floors relative to the frame before, so
it needs one more frame, of twice as many output samples when it
doubles the sample rate. Without it, the first 256 samples decoded
after a seek into HE-AAC differ from continuous decoding by -36.6 dB
with one frame of pre-roll, and not at all with two.
Implicit SBR is only known once found in a frame, so the pre-roll is
raised then, as it is for USAC, whose frame length depends on its SBR
ratio. Demuxers get it through the stream probing, whatever the
container. A larger pre-roll declared by the container is kept, and the
documentation of AVCodecContext.seek_preroll now says a decoder may
raise it.
The output of an AAC-LC stream decoded after a seek has an error of
-9.5 dB in the first 1024 samples, against -85 dB elsewhere, which one
frame of pre-roll removes.
The pre-roll tests now show the declared value, for AAC in every
container, 4096 samples for HE-AAC, explicit or implicit, 2048 for SBR
that does not double the sample rate, and 1536 for ELD.
avcodec_parameters_to_context() copied AVCodecParameters.initial_padding
into both AVCodecContext.initial_padding and AVCodecContext.delay. Since
ff98352c3d, avcodec_open2() sets skip_samples from AVCodecContext.delay
for every decoder, so a decoder opened on a stream with container
priming, such as AAC in MP4, started out with that many samples pending
to be discarded.
The two are different things. initial_padding is the encoder priming at
the start of the stream, which the demuxer already attaches to the first
packet as skip-samples side data. delay is a property of the decoder
instance, which only decoders that know their own delay export in init.
Applying the container's value at open discards it from whatever the
first decoded packet turns out to be, so seeking before the first
decode drops real samples. For a mono 44.1 kHz AAC-LC file with 2048
priming, ffmpeg -ss 530 -t 10 -i in.m4a returned 439152 instead of
441000 samples, with the audio starting 1848 samples late.
Stop copying initial_padding into delay. Decoders that export a delay,
such as libopus, native opus, wma, lc3, ape and mpegh, set it
themselves and are unaffected, and decoding from the start of a stream
is unchanged since the side data carries the priming. The documentation
of AVCodecContext.delay now says it is discarded when the decoder is
opened, and points to seek_preroll for seeking.
The seek tests of AAC in MP4 and CAF now start at the requested time
instead of late by the container's priming.
Decode one PCM packet carrying AV_PKT_DATA_SKIP_SAMPLES and print how
many samples are output, for samples skipped at the start of the frame
and padding discarded at its end, alone, together, overlapping, and with
a padding larger than the frame.
The reference records the current behaviour.
Seek on the later of two AAC streams starting a second apart, remuxed
from one sample, close enough to its start that the seek targets it;
seek through the concat demuxer, which seeks in the file it reads; and
seek close to the start of ADTS, whose start time is unknown.
The references record the current behaviour.
Seek past the end of AAC in CAF and Opus in Matroska, so that the seek
lands on the last packet, which carries the padding to discard at the
end of the stream. Seek on the video stream of H.264 with AAC in MP4,
just after a keyframe, to show whether room is left for the pre-roll of
the audio stream.
The references record the current behaviour.
Discarding samples at the start of a stream and after a seek should work
the same way for every codec that needs it, whatever the container.
For AAC in MP4, CAF, ADTS, FLV and Matroska, Opus in Ogg, Matroska, CAF
and MPEG-TS, and MP3 with LAME and iTunes gapless info, print the
priming and pre-roll declared for the audio stream, list the first
packets read after a seek to 0.53 s, and decode 0.15 s from there. The
decoded output is silenced so that only its timing is compared, as the
decoders are not bit-exact across platforms.
The references record the current output. Only Opus in Ogg and Matroska
declares a pre-roll. MP3 declares no priming, as the demuxer applies it
on its own. The decoding of AAC from MP4 and CAF starts late, by the
container's priming applied after the seek, and the seek in Ogg lands
at the start of the stream.
Seek aac-2048-priming.mov to 2.3 s with ffprobe -read_intervals and list
the first packets read. The seek lands on the frame that holds the
target, with no earlier frame to decode first, which would be the
pre-roll a decoder needs to produce reliable output at the target.
Do the same for HE-AAC with explicit SBR, where a frame is twice as many
output samples, and for AAC-LC with 960 samples frames.
The references record the current output.
Print initial_padding and seek_preroll for aac-2048-priming.mov. The
priming is the encoder delay at the start of the stream, while the
pre-roll is how far before a seek target decoding has to start for the
output to be reliable. Nothing declares a pre-roll for AAC.
Also print it for HE-AAC with explicit SBR, where a frame is twice as
many output samples, for SBR that does not double the sample rate, for
AAC-LC with 960 samples frames, and for ELD.
The references record the current output.
Decode 0.15 s of the mono AAC-LC aac-2048-priming.mov starting at 2.3 s,
with the seek done on the input. The seek lands in the middle of a frame,
and the reference output starts at the requested time with the partial
frame. The decoder instead discards the first 1994 samples, as the
container's 2048 samples of priming are applied to the first frame
decoded after the seek, so the output starts late.
The reference records the current output.
Show AVCodecParameters.seek_preroll next to initial_padding in the
stream section, and add the attribute to the XSD. Demuxers that know
a pre-roll, such as Opus, report it there; everything else prints 0.
Add a filter that removes side data of the given types from packets and from
the stream, or keeps only the packets carrying side data of any of the given
types, as the select mode of the sidedata frame filter does for frames, but
with a list of types. The types are named by their handle, as option
constants joined with '+'.
Walk all the side data types: each one has to have a handle, which has to
find the type again and not be shared. The handles are compared with the
reference, so that a new type fails the test until it gets one and a
released handle cannot change unnoticed.
Cover ID3v2.3 and ID3v2.4 with a chapter title long enough that a plain
size and a synchsafe size differ. Print the CHAP size bytes, declared and
actual tag lengths, chapter counts, titles and timings for FATE to compare
against its reference output.
Also give the first embedded text frame an oversized length and verify
through the reference that both chapters and their timings survive.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
EXT-X-START may appear in both Master and Media Playlists (RFC 8216
4.3.5.2). Parsing it allocated a Media Playlist, so a Master Playlist
carrying it before its EXT-X-STREAM-INF entries was rejected since
0e6eef3551.
Record the offset while parsing and apply it once the playlist type is
known. A value from a Master Playlist applies to all its Media
Playlists, which then ignore their own, as RFC 8216 4.3.5 recommends.
Defer EXT-X-ENDLIST the same way, so that it is not lost when it
precedes the first tag allocating the Media Playlist.
A Master Playlist carrying EXT-X-START before its variants is rejected
with "Master Playlist tag found in a Media Playlist", as recorded in the
master-start references.
The media-start-endlist and master-media-start cases record behaviour
that must be kept: an EXT-X-ENDLIST following EXT-X-START, and a start
offset carried only by a Media Playlist.
Mux two IAMF audio elements with ids 1 and 2 and a mix presentation with
id 1 into mp4, then demux and probe the result. Without the previous
commit the mov demuxer aborts on an assertion when reading this file.
Signed-off-by: Martin Mirchev <mmirchev@comp.nus.edu.sg>
Print the child class tree of the IAMF AVClasses as returned by
av_opt_child_class_iterate() and look up options of the child classes
with av_opt_find2() and AV_OPT_SEARCH_CHILDREN | AV_OPT_SEARCH_FAKE_OBJ.
Signed-off-by: Martin Mirchev <mmirchev@comp.nus.edu.sg>
This bundles all of the following changes to the op list print format into one
up-front commit, to prove that the remaining refactors don't affect the
output themselves.
The general goal of the new print format is to print all metadata for a single
output pad as a single line, describing just that output pad's metadata,
while skipping over any invalid/unused pads.
Signed-off-by: Niklas Haas <git@haasn.dev>
The fate-filter-metadata-cropdetect1/2 references change as the scans
now stop at the edge free lines next to the box.
Fixes: s7zfKOCXo4MJ
Fixes: wrong crop area with mode=mvedges
Wrong crop area with mode=mvedges Replicated through UnModified FFmpeg with a plain output diff
Found during triage of the security report VoiiaDYyhdfz
Found again by the review of https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/24623
Compare one-thread conversion with 2, 3, 7 and 16 threads for five even
frame heights, including cases that otherwise produce odd slices. Cover
NV12, NV21, YUV420P, YUVA420P and YUV422P to packed and planar RGB,
including both byte orders of the 16-bit formats.
Exercise both dynamic and initialized legacy swscale contexts. Disable
dithering so the AArch64 selector must supply its own slice alignment
for planar inputs as well. Compare within each implementation to avoid
requiring identical color conversion rounding across architectures.
Print mismatching row counts for FATE to compare with its reference.
The test fails before the preceding fixes on native AArch64 and on
32-bit ARM NEON, and passes afterwards on both. It also passes on
native x86-64.
Assisted-by: Fairy
asf_o is a second, non-default implementation of the ASF demuxer next
to asfdec_f.c. Security issues keep being reported against it, so it
is a maintenance burden without a benefit over the default demuxer.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
A show_existing_frame packet outputs a reference to an earlier frame,
whose AV_FRAME_FLAG_DISCARD comes from the packet that coded it. If that
packet was discarded, the shown frame is dropped too. Take the flag from
the showing packet, as is already done for pts and pkt_dts.
fate-vp9-trim-preroll covers this with the trim bsf's preroll option.
Assisted-by: Claude Opus 5.5
Signed-off-by: Julius Bairaktaris <julius@bairaktaris.de>
A version 2 SoundDescription carries the sample rate as a double, so the
muxer is asked for a rate that does not fit the legacy 16.16 field and
empty_moov places the description ahead of mdat, which puts the double at
a fixed offset of the generated file. run_with_patched_temp then replaces
it, so these tests need no sample either.
Measured with libavformat/mov.c restored from the parent of 3be6c2d943,
i.e. with the double converted before being checked, and these tests kept
in place:
fate-mov-stsd-v2-sample-rate-nan fails (reports -2147483648)
fate-mov-stsd-v2-sample-rate-overflow fails (reports -2147483648)
fate-mov-stsd-v2-sample-rate-negative passes
fate-mov-stsd-v2-sample-rate-zero passes
The first two compare the diagnostic rather than only the exit status:
on this x86-64 build the conversion happens to produce INT_MIN, which the
later sample_rate check rejects as well, so the rejection alone does not
show which check fired, and the value it reports is undefined anyway.
The zero test fixes the opposite direction. Zero must stay accepted,
because mov_finalize_stsd_codec() then falls back to the media timescale;
a check rejecting it as invalid would break that fallback.
The generator decodes the lavfi input device's s16 output, which the
device describes with the native-endian PCM codec id, so the decoder
dependency follows the host endianness.
Signed-off-by: Furkan Efe Can <caglarf646@gmail.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Seven descriptions, all with the rtpmap rate at 44100 and the attribute
asking for something else, so the probed rate shows whether the attribute
was applied or ignored. sdp_flags custom_io keeps the demuxer from
opening a transport, so no socket is involved and the tests need no
sample.
Measured with libavformat/rtsp.c restored from the parent of a7b20ee103,
i.e. with atoi(), and these tests kept in place:
fate-rtsp-sdp-sample-rate passes (48000 applied)
fate-rtsp-sdp-sample-rate-leading-zero passes (048000 -> 48000)
fate-rtsp-sdp-sample-rate-int-max passes (INT_MAX applied)
fate-rtsp-sdp-sample-rate-negative fails (-1 applied)
fate-rtsp-sdp-sample-rate-zero fails (0 applied)
fate-rtsp-sdp-sample-rate-above-int-max fails (converted and applied)
fate-rtsp-sdp-sample-rate-overflow fails (atoi() overflow)
The first test is the positive control: without it the other six could
pass while the attribute was never parsed at all. The leading-zero test
passes either way; it pins the parsing base, so that replacing atoi()
with a base 0 conversion, which reads 048000 as octal, does not go
unnoticed. The two int-max tests bracket the upper bound: where long is
wider than int neither value sets ERANGE, so the bound itself is the only
thing separating them.
Signed-off-by: Furkan Efe Can <caglarf646@gmail.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fixes issue due to MXF muxer writing FFV1Version by copying byte 14 of the FFV1 codec label.
This caused incorrect version numbers, it would increase by one, so 3 became 4.
Now we save the real version in sc->version.
Exercise partial output bytes in both monochrome polarities, using same-height conversion and bilinear upscaling to cover the one-tap and two-tap output paths. Generate the input with the existing color source and compare frame checksums through FATE.
Assisted-by: Fairy
Generate 1/2/4-bit palette animations whose later frames sit on an odd
x offset, so the offset is not a byte offset in the packed row. The
fixtures are built by apnggen, so the tests do not need fate-suite samples.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Exclude IMM6 from one-in/one-out timestamp inference so AVI probing
does not assign PTS from DTS before the H.264 reordering delay is known.
Signed-off-by: Tom Needham <06needhamt@gmail.com>
Martin Mirchev