The hls-start demux tests cover the cases of the hls-parse tests
through the demuxer. There is no need for hls.c API test code.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
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>
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>
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.
The first seek done with -seekforw asks for a range that starts at the
target, so it can never land before it. Add -seekmin to start the range
earlier, as ffplay does for its forward seeks, so that tests can show
how such a seek lands.
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>
Parse a playlist, then optionally a Media Playlist into the first
playlist it declared, as hls_read_header() does, and print the parsed
playlists with their finished state and EXT-X-START offset.
ff_rtp_parse_packet() drains a depacketizer's internally buffered data on
the follow-up buf==NULL call only while s->prev_ret > 0. The
"while (rv < 0 && has_next_packet(s))" reordering loop delivered queued
packets without updating s->prev_ret, so when a packet was returned from that
loop, prev_ret kept its stale negative value and the next buf==NULL call was
routed into the (now empty) reordering queue instead of back into the
depacketizer.
For MPEG-2 TS this drops data: when an RTP payload carries a payload unit
start indicator (PUSI) on a TS packet other than the first, the depacketizer
returns the finished PES, buffers the rest of the payload and returns 1,
expecting a buf==NULL call to fetch the remainder. A plain continuation
payload (no PUSI, the common case) completes no PES and returns < 0, which is
enough to enter the loop above; if the next queued packet carries a
mid-payload PUSI, its buffered tail (the TS packets from the PUSI onwards) is
never drained and is lost. A single reordered pair of packets triggers this,
so the loss occurs rather frequently, not only under heavy reordering.
Update s->prev_ret inside the loop and add libavformat/tests/rtpdec.c, which
drives the real MPEG-TS depacketizer with full 7x188-byte RTP packets and
checks that an in-order and a reordered delivery of the same packets yield
identical PES data. The test is registered as fate-rtpdec with a checked-in
reference output; its two 64 KiB Output buffers are static to avoid a large
stack allocation in main().
Signed-off-by: Torbjörn Einarsson <torbjorn@einarssons.se>
Reset the length accumulator when starting a new tag, so the encoding
context need not be zeroed by the caller and can be reused after finish.
Existing callers already supply zeroed contexts, so their output is
unchanged. Clarify that start initializes the encoding context.
Add a sample-free FATE test for ID3v2.3 and ID3v2.4 with zeroed, reused,
and explicitly nonzero length accumulators. Compare the declared tag
length with the bytes written using a reference file.
Addresses the internal initialization improvement requested in #24035;
this does not change the public muxer lifecycle contract.
Assisted-by: Fairy
Covers well formed status lines, a missing or non numeric status code, lines
that do not start with an HTTP version, and status lines whose version or code
does not respect the grammar of RFC 9112.
The reference output records the current behavior: every one of those malformed
lines is accepted, most of them as a 2xx success.
This is possible because it only uses the public API;
and beneficial when using shared builds (as not all
the internals of lavf are linked statically in the binary).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The return value of MoveFileExW was not being correctly interpreted,
see https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-movefileexw.
On Windows a failed rename over the file: protocol now surfaces as failed to rename file %s to %s:
Operation not permitted (ff_rename, libavformat/avio.c:867) plus an AVERROR(EPERM) return, where previously the muxer
reported success and the user was left with a missing or stale output file and no diagnostic. This affects the
write-to-temp-then-rename paths in hlsenc, dashenc, hdsenc, smoothstreamingenc, segment, and img2enc (e.g. HLS/DASH
playlist updates, -write_temp_file, segment list finalization).
Also, added unit tests to exercise the rename function.
Signed-off-by: Christopher Decker <chris.decker08@gmail.com>
When creating nested directories (e.g. /a/b/c), a genuine mkdir()
failure for an intermediate component was overwritten by later
attempts, making the original failure harder to diagnose.
Stop immediately on intermediate errors other than EEXIST, preserving
errno for the caller. Existing path components remain non-fatal, as
required by mkdir -p semantics. Add a regression test for creating a
child below an existing parent directory.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
(This also fixes a symbol name collision with libssh,
which has a nonstatic function called md5.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We have test to make sure that certain configurations do print
warnings. However, the normal operation of the muxer within this
test always printed a warning, so those tests to check for
extra warnings didn't essentially guard anything.
The warning that always was printed, "track 1: codec frame size is
not set" was not present in the libav fork where this testcase
originated, it was removed in f234e8a32e.
Set the frame size for the audio stream to silence the warning,
and use this frame size in a couple later calculations, and check
that one test configuration doesn't print warnings.
Setting the frame size apparently changes the rounding of a timestamp
in the ismv muxing testcase.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is based on a spec at https://aomediacodec.github.io/id3-emsg/,
further based on ISO/IEC 23009-1:2019.
Within libavformat, timed ID3 metadata (already supported by the
mpegts demuxer and muxer) is handled as a separate data AVStream
with codec type AV_CODEC_ID_TIMED_ID3. However, it doesn't
have a corresponding track in the mov file - instead, these events
are written as separate toplevel 'emsg' boxes.
Signed-off-by: Martin Storsjö <martin@martin.st>
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This muxer solely exists to test the fifo muxer via a dedicated
test tool in libavformat/tests/fifo_muxer.c. It fulfills no
other role and it is only designed with this role in mind.
The latter can be seen in two facts: The muxer uses printf
for logging and it simply presumes the packets' data to contain
a FailingMuxerPacketData (a struct duplicated in fifo_test.c
and tests/fifo_muxer.c.); in particular, it presumes packets
to have data at all, but this need not be true with side-data
only packets and a segfault can easily be triggered by e.g.
encoding flac (our native encoder sends a side-data only packet
with updated extradata at the end of encoding).
This patch fixes this by moving the test muxer into the fifo
test tool, making it inaccessible via the API (and actually
removing it from libavformat.so and libavformat.a).
While this muxer was accessible via e.g. av_guess_format(),
it was not really usable for an API user as FailingMuxerPacketData
was not public. Therefore this is not considered a breaking change.
In order to continue to use the test muxer in the test tool,
the ordinary fifo muxer had to be overridden: fifo_muxer.c
includes lavf/fifo.c but with FIFO_TEST defined which makes
it support the fifo_test muxer. This is possible because
test tools are always linked statically to their respective
library.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The documentation states that here 0 should be used for read-only and
1 for a writable buffer. AVIO_FLAG_WRITE however is 2, while it works
due to the way the flag is handled internally, it is still wrong
according to the documentation.
Additionally it makes it seem as if the AVIO_FLAG_* values could be used
here, which is actually not true, as when AVIO_FLAG_READ would be used
here it would create a writable buffer as AVIO_FLAG_READ is defined as 1.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The test program for the FIFO muxer allocates a buffer without padding
and wraps it into a packet via av_packet_from_data(). This is an API
violation. Furthermore, said buffer leaks in case av_packet_from_data()
fails. Fix both of these issues by using av_new_packet() instead.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Kacper Michajłow