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>
Decodes the LPCM variant found in DVD-Audio AOB streams. Unlike
DVD-Video LPCM it supports up to 192 kHz sample rates and splits
channels in two channel groups, which may use different quantization.
Samples are grouped in sets of 2 samples over all channels, with the
second channel group's data stored first within each set, as 16-bit
big-endian most significant parts followed by the remaining bits.
Based on information from expired US 6,580,671 patent et al.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Accept the AV1 Professional profile in the D3D12VA hwaccel and select the
matching decode profile GUID, offer D3D12 for YUV420P12 in the decoder,
map the frames context to P012, and add P016 (12-bit) support to the
d3d12va hwcontext.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Add the AV1 Professional (Profile 2) decoder GUIDs, including the
dedicated 12-bit 4:2:0 mode, so D3D11VA/DXVA2 can match a decoder for
Profile 2 streams.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Select P012 as the D3D11VA/DXVA2 frames sw_format for YUV420P12 content
and map it to DXGI_FORMAT_P016, so 12-bit 4:2:0 hardware decoding can
allocate a usable surface.
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>
This is possible after the recent MMX->XMM conversions
and preferable as it makes the test stricter.
Reviewed-by: Niklas Haas <ffmpeg@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before the switch to libcheckasm, rnd returned an unsigned value;
now it only returns a signed value in the range 0..INT_MAX,
so that the sign bit is not random at all. This means that when
rnd is used to initialize four bytes at a time, one bit is not random.
Fix this by mapping rnd to checkasm_rand_uint32().
Reviewed-by: Niklas Haas <ffmpeg@haasn.dev>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This reverts commit f3431169da, which
introduced various regressions and hangs with at least exr, as
reported by fate, and potentially other codecs that are not as
thouroughly tested.
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>
If this triggers while an asynchronous header_callback() (e.g. from a previous
seek or redirect) is still running, the seekable/content_size fields can
be written to while libcurl_seek() is still reading from them.
I'm not convinced this is an actual bug in practice, but tsan at least is
bound to complain about it.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
The documentation states this as a valid option, but the code only allows
force-disabling atm.
Sponsored-by: nxtedition AB
Signed-off-by: Niklas Haas <git@haasn.dev>
Otherwise, there will never be enough space in the FIFO to put the data
written, resulting in the write callback being stuck/paused indefinitely.
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>
Probe Accept-Ranges/Content-Range/Content-Encoding to determine
seekability and total size, issue ranged requests via CURLOPT_RANGE,
implement url_seek (including AVSEEK_SIZE) as a reconnect at the new
offset, and resume seekable transfers from the next missing byte after a
recoverable error.
Note that we prefer the compression over seekability, as servers are
unlikely to compress media files in practice, as this would be huge
performance cost for zero gain. However downloading text playlists
benefits a lot from compression. YouTube for example can serve text
files that have 30MB+ which is huge bandwidth usage when not compressed.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Add the per-AVFormatContext curl_multi worker thread, the command queue,
write/header/xferinfo callbacks and a FIFO with pause/unpause
backpressure. url_open2 probes the response on a dedicated thread.
url_read drains the FIFO and yields to the avio layer so the interrupt
callback is honoured. An explicit "libcurl:" URL prefix forces the
protocol.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
