The trailing padding is read from the AV_PKT_DATA_SKIP_SAMPLES side data of
every packet, overwriting the previous value, so only the last packet was
ever accounted for. A single packet holds at most one frame, which caps the
padding that can be written at 1152 + 528 + 1 samples.
LAME regularly reports more than that: gapless/gapless.mp3 carries 1984 and
comes out of a stream copy with 1681, decoding to 303 samples more than the
file it was copied from.
Accumulate instead, and add the decoder delay once the total is known.
Fixes: https://trac.ffmpeg.org/ticket/9755
The current logic would stop demuxing the entire manifest once the first Representation
returned EOF, which could result in plenty of packets from other Representations being
lost.
Signed-off-by: James Almer <jamrial@gmail.com>
Based on a patch by Michael Niedermayer
Fixes: unbounded allocation
Fixes: poc_output_mix_config_dos.iamf
Fixes: 387qWpjUgeKH
Found-by: Duong Tran Thai (CyStack)
Signed-off-by: James Almer <jamrial@gmail.com>
Add a new muxer option mpegts_pcr_pid that generates PCR on a dedicated
adaptation-field-only PID, separate from any elementary stream.
ISDB-T 1seg receivers require PCR on a standalone PID. When PCR shares
the video PID, these receivers acquire the service but refuse to decode
video and audio. This is standard practice in Japanese digital
terrestrial broadcasting per ARIB TR-B14.
When mpegts_pcr_pid is set to a valid PID value:
- PCR packets are generated as adaptation-field-only packets on the
specified PID at the interval set by pcr_period
- The video stream adaptation fields do not carry PCR flags
- The PMT PCR_PID field is set to the specified PID
When mpegts_pcr_pid is -1 (default): existing behavior is unchanged.
The existing mpegts_insert_pcr_only function is refactored into a
parameterized mpegts_insert_pcr_only_pid(s, pid, cc, discontinuity)
to avoid code duplication.
Fixes: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/23649
Signed-off-by: shadowcaster3 <vasyl.samoilov@gmail.com>
RTSP redirects retain URL credentials and authentication state when a
Location URI changes to another origin. This can forward reusable
credentials to a server with a different scheme, host, or port.
Clear the stored credentials and authentication state when the redirect
crosses an origin boundary. Preserve them for same-origin redirects.
Fixes: cross-origin credential disclosure
Fixes: rtsp_redirect_auth_leak_poc.py
Fixes: VaKaPOnfN02z
STTS sample deltas follow decode order, while AVPacket.duration is
defined as the interval to the next PTS in presentation order. Assigning
the deltas directly therefore produces incorrect packet durations for
VFR video with reordered frames.
After index construction and edit-list processing, sort samples by PTS
and set every duration with a following PTS from adjacent presentation
timestamps. This reorders STTS durations where possible and derives
intervals produced by the STTS/CTTS combination when necessary. Keep the
original timing table if allocation fails or timestamps are invalid.
Add FATE coverage for the official VFR H.264 sample and for a generated
MPEG-4 case whose presentation intervals are not a permutation of its
STTS deltas. Update the HEVC dts2pts CRA reference for the corrected
presentation-order durations.
Signed-off-by: panboxiaosa <panboxiaosa@gmail.com>
The check on variable subblock durations had an inverted comparison, rejecting valid multi-subblock parameters and failing to catch subblock durations exceeding the remaining time.
tls_open() installed a peer-identity target only when the URL host was
non-numeric. For a numeric-IP target the whole block was skipped, so
with verify=1 OpenSSL validated the chain to a trusted CA but bound no
identity, and any publicly-trusted certificate for any name was accepted
(e.g. tls://203.0.113.10?verify=1).
Run the identity block for every non-listening connection. Classify
s->host with the same getaddrinfo(AI_NUMERICHOST) rule tls.c uses. A
numeric host is pinned to the certificate's iPAddress SAN by handing
OpenSSL the parsed binary address via X509_VERIFY_PARAM_set1_ip();
everything else, including a verifyhost=<name> override, binds by name
via SSL_set1_host(). Passing the binary address rather than re-probing
the ASCII form pins legacy numeric spellings such as 2130706433 as IPs
instead of letting them fall back to hostname matching. SNI is still
suppressed for numeric transport hosts (RFC 6066 sec. 3) via
s->numerichost.
The identity target is installed unconditionally for non-listening
connections; whether the certificate is actually verified stays
controlled separately by SSL_CTX_set_verify() under s->verify, so
disabling verification keeps the prior behaviour. Sets AVERROR_EXTERNAL
with an explicit log line on failure.
dtls_open() sets s->is_dtls and then calls tls_open(), so DTLS client
connections run through the same identity block and are covered here.
Found-by: Claude (Anthropic). Human-verified and reported by
Omkhar Arasaratnam <omkhar@linkedin.com>.
Signed-off-by: Omkhar Arasaratnam <omkhar@linkedin.com>
first_timestamp is taken from the first packet in mux order, which is
not necessarily the earliest timestamp in the segment. Lower it while
packets of that segment are still arriving, so the seek timeline is
anchored at the true segment start.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Segment starts on the seek timeline are derived from EXTINF durations,
so the first keyframe of the target segment can have a slightly lower
DTS than the snapped seek position, in which case the packet discard
loop would skip it and resume playback one segment late. Make sure we
start at the very beginning of the stream in this case.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Rebase the first packet's timestamp onto the start of the segment list
regardless of playlist type, and report it as start_time. Previously
only EVENT playlists did this and live streams took start_time from the
first loaded segment at the live edge. Which is not correct as some
servers provide very deep (hours even) time shift in live playlist. The
evicted segments are already tracked by EXT-X-MEDIA-SEQUENCE. This
allows us to use all available segments, not only the future ones on
live playlist.
Also prefer PTS over DTS, as EXTINF durations and start_time are
presentation time.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Live (and EVENT) playlists are seekable within the currently known
segment list. Seeks before the list start clamp to the oldest segment,
past the end to the live edge. Live playlist can evict old segments, we
track that by reading EXT-X-MEDIA-SEQUENCE. Previusly the code assumed
that the live playlist, don't have past segments, however some servers
has very deep usable timeshift.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Substream 0xa0 packets without the DVD-Video dynamic range control
marker byte were assumed to be MLP, while in DVD-Audio AOBs substream
0xa0 always carries LPCM (MLP uses 0xa1), so hi-res LPCM streams were
misdetected and decoded as garbage. Classify them as PCM_DVDA and keep
the private stream header in the packet for the decoder to parse, as
its length is variable and it carries the audio format.
Signed-off-by: Kacper Michajłow <kasper93@gmail.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>
Larger values silently truncate on 32-bit, which can make the resulting
FIFO too small to ever satisfy the unpause threshold.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
The API is not clear to me if AVBPrint has to be finalized on errors,
but there is nothing wrong to be defensive here
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
It was applied once after the probe, from the wrong thread, and any
follow-up reply re-evaluating seekability discarded it.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Track the size for non-seekable replies too, don't reset a known size when
a reply omits it, and don't store the encoded length of a compressed body.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
In theory a client could be coaxed by a malicious server to seek to a
large 64-bit offset, which would then trigger an overflow of the position.
Better safe than sorry and just error out with EIO in such cases.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
The failure mode here is to just request the rest of the file, which is
explicitly safe.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
If the server sends a value of INT64_MIN here, we would correctly parse
it and then subtract off -1, underflowing to a huge positive value
(and triggering undefined behavior in the process).
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of randomly mixing in uint64_t. As far as I can tell, we don't
depend on defined overflow behavior anywhere, except where such would be a
bug anyways, and I'm also pretty sure we won't exhaust the 63-bit file size
limit of int64_t any time soon, so this is just a footgun prevention
mechanism.
We already have a few dodgy places of mixing int64_t and uint64_t values
in the code haphazardly.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
This is multiplied by 1000, which can overflow on systems with 32-bit
long (i.e. most of them).
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Instead of trying to statically guess whether or not we expect more data
to be available by exactly recreating the logic, we can consult the parsed
content-range header directly to determine if there are more bytes in the
file.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Since this is consumed by e.g. protocols which open inner protocols.
This would normally be propagated by the `av_opt_copy` call, but as this
check happens *before* the inner URLContext is even allocated, we're
forced to propagate the options manually.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
In theory, we could expand this a lot more, by adding more verbose
statistics about individual request latency etc, but I don't think that's
as helpful (to me) as at least tracking the number of requests made.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
When using -prefer_libcurl, http might be served by libcurl instead of the
native HTTP backend; in this case we shouldn't use `ff_http_do_new_request2`
and instead create a new request.
I added a few assertions to safeguard some of the assumptions this code
clearly relies on.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Otherwise, this fails to parse values like "true" or "yes". This does
require stack-allocating a dummy object, but that's not a big deal, as
we only ever set this single option on it, so nothing should ever
get allocated.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
And also set a reasonable default whitelist. This is especially important
because libcurl supports a much wider range of protocols than FFmpeg,
including e.g. smtps, telnet, gopher, etc.
We have to include "libcurl" in libcurl's own default whitelist, otherwise
it will refuse te recursively open itself for e.g. HLS.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
This allows sharing cookies, HSTS state etc. between requests inside a single
AVFormatContext. This is analogous to the status quo of http.c, which also
re-uses cookies across all requests.
Note that the connection state, DNS cache, SSL session etc. are shared by
default when using a multi handle, so we only need to explicitly share the
rest.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Romain Beauxis
Michael Niedermayer
James Almer
shadowcaster3
Abdessamie
panboxiaosa
almogyalin
Omkhar Arasaratnam
Kacper Michajłow
Christopher Decker
Niklas Haas