Documenting that the directories must not be writable by untrusted users
was suggested in the report.
Documentation for umsIH5gcyBXl (AISLE-2026-0111-00168)
Found-by: Joshua Rogers <joshua.rogers@aisle.com>
The rx and tx threads no longer use pthread_cancel(), so gate the
circular buffer on HAVE_THREADS instead of HAVE_PTHREAD_CANCEL. This
also drops the w32threads override.
On targets that have threads but no pthread_cancel(), such as Android,
udp inputs now start a receive thread and allocate the default 7*4096
by 188 byte fifo, as on other platforms. Set fifo_size=0 to get the
previous behavior.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
"bytes A-B/*" means the complete length is unknown (RFC 9110 14.4), so
don't read it as a size of 0, and never derive the complete size from a
partial reply. Remember it once learned from a 200 Content-Length or a
"bytes A-B/N" total and reuse it for later "*" replies. If the complete
size was never learned, or the total is not a number, it stays unknown.
A 416 to a read or a seek past the end of a resource of unknown size
ends it with EOF and gives its complete length ("bytes */N"), unless it
states a length past the requested offset. That 416 is retried first
only if reconnect_on_http_error lists 416 by number, reconnect_at_eof
does not retry the end it marks, and an open past the end is retried as
configured. Keep the file size and the complete size when a request
fails. A seek that fails or is refused keeps the offset and the end of
the resource, and when reading goes on over the old connection, also
the range end, chunk state, connection mode and compression of the old
reply. A seek to the current offset makes a new request when there is
no connection.
Fixes#24210
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Like the fd protocol, but takes a raw Windows HANDLE instead of a CRT file descriptor.
On Windows, CRT file descriptors cannot be reliably passed to child processes, so
HANDLEs need to be used instead.
Signed-off-by: Felipe Araújo <felipdsa21@outlook.com>
This allows storing metadata in a separate directory, e.g. on a faster
drive, a tmpfs, or in a volume without quota limits.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
This allows users to limit the amount of cached data. Note that this is
*not* a limit on the size of the file cached. For example, a 10 GB file can
work with a 1 GB cache size limit if the user only ever plays some parts of
the file (e.g. 1 minute from a 100 minute stream).
After this point, s->read_only is simply turned on, giving us the expected
fallback behavior for uncached blocks.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
This allows the shared: cache protocol to ignore errors in the underlying
URL (e.g. HTTP server went down) and continue serving the cached data
purely from the cache file. I'm not sure what a good name would be here,
since -ignore_errors overlaps somewhat with -retry_errors, but I think the
distinction is clear enough. (-ignore_errors keeps going after the inner
protocol fails, -retry_errors will retry blocks that previously failed in
the inner protocol)
One slight change is that we now call ffurl_size() on ourself during
init. This is safe, because the spacamap is already initialized by this
point in time, and it also embeds the correct error handling and spacemap
update logic.
Default off because it's a possibly surprising change in behavior.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
The sftp protocol connected and authenticated without checking the server
host key, so credentials were sent to any or spoofed server. Verify against
known_hosts (ssh_session_is_known_server, with a pre-0.8 fallback) before
authenticating; add a 'verify' option (default on) to opt out.
Strict checking is forced on for the check: libssh otherwise reports an
unknown server, and since 0.8 even a changed key, as known when the parsed
ssh config says StrictHostKeyChecking no.
This changes the default behaviour: like OpenSSH with
StrictHostKeyChecking=yes, sftp:// now refuses servers that are not in the
known_hosts file or whose key differs from the recorded one.
Fixes: credentials sent to unverified SSH servers (CWE-295)
Fixes: ZmW0mOvhU0qN
Found-by: Joshua Rogers <joshua.rogers@aisle.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Since libcurl.c doesn't have to care about the exact number of bytes read,
we just perform the seek but defer the actual `start_request()` call until
the next on_done() callback, while simply discarding all data read in the
meantime.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Makes this debug option way more useful. Also matches the existing behavior
on CRC mismatches.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Register a prefer_libcurl IO option that, when set, opens http(s) URLs
with the libcurl protocol instead of the native one. The native http
protocol stays the default.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Add the AVOption table and map it onto libcurl. Verbose curl output is
routed to av_log at debug level. This mirrors subset of http.c options.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Similar to -retry_errors, this retries blocks whose only crime is failing
the CRC self-check.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
By turning it into a tristate that defaults to -1 (auto). Users can still
force a particular value for debugging.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
The decision to switch to checking peer certificates by default
at the next major version bump was announced on 2025-08-09
in commit 5621eee672.
Thanks to Michael Niedermayer for pointing out that the documentation
needs to be updated, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This value is matched to the typical seek latency in a reasonably capable
7200 rpm disk device, as well as the typical latency of an on-premise HTTP
request.
Note that this change should rarely have a significant effect, because
it only matters when using multiple concurrent processes, and one process
is somehow stuck in I/O (or died). Since we sleep in a loop for 1/16th of
the requested timeout value, this should only increase the effective read
latency by up to ~500 us on top of the actual underlying latency.
The alternative is hammering the same underlying resource with the exact
same requests at the exact same time (e.g. during init).
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
This will effectively disable the cache but allows the cache layer to verify
cached files against the original input file. Useful only for debugging
the shared cache protocol itself, as file corruption can already be caught by
the CRC check.
This adds a new protocol shared:URI which is distinct from the existing
`cache:` in that it is explicity designed to be thread-safe and cross-process,
enabling multiple ffmpeg processes (or multiple ffmpeg decoders within the same
process) to share a single cache file, for e.g. a remote HTTP stream. As such,
it uses a radically different internal design.
To facilitate zero-knowledge cross-process interoperability, the cache file
itself is just a memory-mapped representation of the underlying file data,
which has the side benefit that the resulting cache file will contain a
working copy of the streamed file (assuming the stream was read to
completion).
To keep track of which regions are cached and which are not, we use a
secondary file that contains a minimal header along with a static bytemap of
blocks within the file. This secondary file is also used to store metadata
such as the filesize, if known, as well as marking "failed" blocks.
Both files can grow dynamically in order to accommodate larger/growing files,
and can be atomically updated (through the use of shared space maps). I have
extensively checked the space map initalization and update code for race
conditions, and I believe the current design to be solid.
That said, it is the user's responsibility to some extent to ensure that the
same URI is not used for different streams, as we rely on the URI to uniquely
identify the cache files. That said, we use a cryptographic hash with
sufficient collision resistance to protect against possible abuse. The lack of
any implicit default on `-cache_dir` also means that `shared:` can't be enabled
via URL injection to possibly access random files on the disk (or intentionally
leak content from other streams with similar URIs, even if the cryptograhic
hash function is broken).
If the input is expected to grow, we shouldn't make any assumptions about
the file size. This matches e.g. the behavior of streamed protocols like
chunked HTTP, which similarly return ENOSYS for streams of unknown size.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
It has come to my attention that a way to limit the request range size
would be useful in general, for reasons beyond just speeding up initial
header parsing.
This patch generalizez -initial_request_size to -request_size. I decided
to continue allowing both options to be used simultaneously, so users can
e.g. set -request_size to something large like 10 MiB, but still use a smaller
size for initial header parsing (e.g. 256 KiB).
Fixes: https://github.com/mpv-player/mpv/issues/8655
Sometimes, HTTP sources require a lot of seeking during probing / header
parsing (especially for formats like MXF). Currently, we need to completely
tear down and re-establish the connection most times this happens, which puts
a lot of stress on the network stack and also results in transmission of
possibly many unnecessary bytes.
This patch adds an option to allow FFmpeg to request partial ranges during
the initialization stage. This is done until the initial request size is fully
read, after which we fall back to the normal behavior (i.e. infinite streaming
via an unbounded request).
The usefulness of this is limited without also specifying -multiple_requests 1,
since otherwise there is little point to requesting partial ranges to begin
with. (However, it is semantically independent, so we keep it that way.)
Previously, the pkt_size option only affected write buffering in the file
protocol. This change extends its effect to read mode as well.
On embedded systems with limited RAM, users can now reduce I/O buffer
memory by setting a smaller pkt_size.
Signed-off-by: caifan3 <caifan3@xiaomi.com>
Add a "pkt_size" AVOption to the Unix domain socket protocol. This option
allows the user to specify the maximum packet size for packet-oriented
sockets (SOCK_DGRAM and SOCK_SEQPACKET).
Signed-off-by: caifan3 <caifan3@xiaomi.com>
Note that this changes the code to work the same way as other protocols where
an URL parameter can override an AVOption.
Signed-off-by: Marton Balint <cus@passwd.hu>
429 and 503 codes can, and often do (e.g. all Google Cloud
Storage URLs can), return a Retry-After header with the error,
indicating how long to wait, asd either a date, or in seconds,
before retrying again. If it is not respected by, for example,
using our default backoff stratetgy instead, chances of success
are very unlikely.
Some references:
* https://datatracker.ietf.org/doc/html/rfc6585
* https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.3
This adds an AVOption to respect that header.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
add option named rtmp_enhanced_codec,
it would support hvc1,av01,vp09 now,
the fourcc is using Array of strings.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Niklas Haas