The cuda hwcontext has listed AV_PIX_FMT_VULKAN among its supported
formats since Vulkan interop was first added, so a device's frame
constraints advertise Vulkan as a transfer-compatible ("sw") format.
This is what allows an hwupload targeting a cuda device to accept a
Vulkan frame as input during format negotiation.
The Vulkan hwcontext never made the reciprocal declaration, so an
hwupload targeting a Vulkan device would not accept a cuda frame, and a
cuda -> Vulkan upload could not be configured even though the transfer
itself is supported. Advertise AV_PIX_FMT_CUDA in the Vulkan frame
constraints to ensure we have consistent behaviour in both directions.
(cherry picked from commit d09d5afc3a)
The reduction accumulated into the zero-initialized context field
instead of the local variable, so the detected VRAM was whatever
device-local heap the implementation listed last, usually the
256MiB BAR heap rather than the multi-GiB VRAM heap.
This made the encoder take the host-memory fallback (or fail the
allocation outright at 12K and above) on hardware with plenty of VRAM.
(cherry picked from commit 43d0d365f3)
GetPhysicalDeviceImageFormatProperties2() must be queried with the format
that will actually be used to create the image, otherwise the external
memory export capability check answers for a different format than the one
being allocated.
When AV_VK_FRAME_FLAG_DISABLE_MULTIPLANE is set (e.g. by ffplay for CUDA
interop), vulkan_frames_init selects the per-plane fallback format via
vkfmt_from_pixfmt2(disable_multiplane=1) and stores it in hwctx->format[].
The image is then created with that fallback format. Querying the
multiplane vkf instead returns capability for a format that is never
instantiated, and on NVIDIA GPUs with OPTIMAL tiling the answer differs
between the two formats, producing broken CUDA hwaccel output.
Read hwctx->format[0], which is populated by vulkan_frames_init before
vulkan_pool_alloc runs, so the query matches the image regardless of
whether the multiplane or fallback path was taken.
Fix artifacts with `ffplay -hwaccel cuda foo.mp4`.
(cherry picked from commit 0baa71b53c)
Cuda currently only supports packed and single-component planar formats, but
fails to import semi-planer (eg: NV12, P010). Even though there are now
semi-planar cuda array formats, which the latest nvdec can use, these formats
are not used when mapping Vulkan imports. Maybe they'll fix that some day.
But until then, let's explicitly detect the case and return a clear error
message for the user.
Exercising this error path revealed that vulkan_free_internal() frees
f->internal on a transfer error and then runs again when the frame is
destroyed, dereferencing the freed pointer; let's make it idempotent.
(cherry picked from commit c29d710cd5)
The current semaphore logic dates back to a time where we did not have any
multiplane images, and it has not kept up. As a result, we currently try and
manipulate too many semaphores when dealing with multiplane images, leading to
errors and crashes. Let's fix it.
(cherry picked from commit 30ba440386)
The current export_to_cuda logic only works for planar and semi-planar formats.
When presented with a single plane packed format, it will incorrectly
calculate the number of channels, resulting in failures later on when cuda
code tries to access the frame. Let's fix it.
(cherry picked from commit 927f205eb8)
DCs can go over int16_t, and when it does, dc_add wraps, so the wrong sign
is reported, which causes errors when decoding more DCs.
Do the prediction in int and narrow to int16 only at store time. The
read_ac_vals() sign change is cosmetic (the value is only ever 0/-1, and
the old code already widened it).
(cherry picked from commit 5784a775df)
Fix build warning on macOS:
> format specifies type 'size_t' (aka 'unsigned long') but the
> argument has type 'VkDeviceSize' (aka 'unsigned long long')
VkDeviceSize is typedef as uint64_t.
(cherry picked from commit 97ba3c4a9a)
"[...] decoders with update_thread_context callback have to call
ff_thread_finish_setup() themselves; it is not done implicitly in
ff_thread_get_buffer() any more.
Not doing so makes the decoder effectively single-threaded."
(cherry picked from commit 300cac3078)
Fix DTLS failure since 9549c9ad79
WebRTC does not verify CA because it allows self-signed cerificate.
Signed-off-by: Jack Lau <jacklau1222gm@gmail.com>
(cherry picked from commit 6f2f3755a0)
Fixes: error: no type named 'system_error' in namespace 'std'
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
(cherry picked from commit c6498178bb)
This fixes generating shared libraries with a toolchain that requires
makedef (MSVC, or mingw toolchains with LLD, that lacks support for
--version-script).
This uses the existing response file generated for linking, by
splitting out the choice of input parameter to makedef to a variable
expanded by make.
This avoids relying on "echo" within makedef supporting long command
lines; msys2/cygwin shells handle it fine, while busybox doesn't.
(cherry picked from commit 8512161c81)
Don't use /dev/null as test input file for the test for response
file support.
Busybox on Windows does provide POSIX utilities to the point of
being able to build and test ffmpeg, but it doesn't provide full
POSIX emulation like msys2 and cygwin do.
Busybox utils do handle paths like /dev/null themselves. But when
busybox invokes a native Windows executable (like the "$ar" tool
in this test), it passes such a path as-is. Msys2 on the other hand
rewrites unixy paths in command line parameters - even when prefixed;
e.g. "@/dev/null" gets rewritten into "@nul".
Instead of testing with a /dev/null input, test with a real temp
file instead.
(cherry picked from commit 32d7e9d71e)
Odd-height yuv420p result in incorrect calculations of the U-plane
address offset. The last row of the V-plane overlapped with and was
overwritten by the first row of the U-plane, leading to chroma artifacts.
```
ffmpeg -init_hw_device cuda=cu -filter_hw_device cu -f lavfi -i \
testsrc=s=1920x1081,format=yuv420p -vf hwupload -c:v hevc_nvenc \
-vframes 1 -y <OUTPUT>
```
Signed-off-by: nyanmisaka <nst799610810@gmail.com>
(cherry picked from commit 3f6bf150cb)
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
Since the input and output format can differ (e.g. 444 -> 420), we need to
reference the correct subsampling for the partially applied filter.
Keep track of this in the CUDATex itself.
Signed-off-by: Niklas Haas <git@haasn.dev>
(cherry picked from commit 01972b4f85)
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
Instead of going via an AVFrame at all. This will allow us to fix the
intermediate chroma plane size for split downscaling.
Signed-off-by: Niklas Haas <git@haasn.dev>
(cherry picked from commit 420a9e90b8)
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
Instead of re-creating this object every frame.
Signed-off-by: Niklas Haas <git@haasn.dev>
(cherry picked from commit e79e9f06ba)
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
At this point, s->hwctx and CudaFunctions * are available.
Signed-off-by: Niklas Haas <git@haasn.dev>
(cherry picked from commit 4289a29bb0)
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
I want to disentangle the internal logic from AVFrame, because some
intermediate states (e.g. for partially subsampled chroma with simultaneous
scaling) may not directly map to a valid AVPixelFormat.
Signed-off-by: Niklas Haas <git@haasn.dev>
(cherry picked from commit fef976b197)
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
Make the next commit a bit easier to review.
Signed-off-by: Niklas Haas <git@haasn.dev>
(cherry picked from commit 61750318db)
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
This is already done by cudascale_filter_frame().
Signed-off-by: Niklas Haas <git@haasn.dev>
(cherry picked from commit 0c3f04a97c)
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
If streams are badly interleaved, then the readrate logic can end up
accumulating an ever-growing lag. Rather than looping over each stream
and sleeping for each stream individually based on the local DTS and lag
logic, pull the sleep out of the loop and only sleep once based on the
furthest-behind stream (i.e. the stream contributing the lowest sleep
duration).
To reproduce:
$ ./ffmpeg -re -i fallbeatcaptiontest.mp4 -c copy -f null -t 10 -
Before this commit, this would run at ~0.7x and accumulate an infinitely
growing lag in one stream. After this commit, both streams run at ~1x as
expected, after an initial burst period due to the bad (1s granularity)
interleaving.
Signed-off-by: Niklas Haas <git@haasn.dev>
(cherry picked from commit de6bcf5c05)
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
This is a dead assignment except on a single branch, so just define it
locally.
Signed-off-by: Niklas Haas <git@haasn.dev>
(cherry picked from commit e7be06c8bd)
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
This shouldn't affect the actual behavior, as the initialization of ds->dts
(implicitly zero'd) and the previous calculation of stream_ts_offset
guarantees that the `if (pts <= stream_ts_offset) continue;` branch fires.
Mainly a minor clarification of the code for the upcoming refactor.
Signed-off-by: Niklas Haas <git@haasn.dev>
(cherry picked from commit 5c877416a5)
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
NVDEC and CUVID now output AV_PIX_FMT_P012 (12-bit 4:2:0),
AV_PIX_FMT_P212 (12-bit 4:2:2) and AV_PIX_FMT_YUV444P12MSB (12-bit 4:4:4)
for high-bit-depth content, but nvenc rejected them: nvenc_map_buffer_format()
returned NV_ENC_BUFFER_FORMAT_UNDEFINED, so a pipeline such as
"-hwaccel cuda -i 12bit.mp4 -c:v hevc_nvenc" failed with EINVAL.
NVENC has no native 12-bit encode format. As is already done for the
16-bit inputs (P016, YUV444P16, GBRP16), accept the 12-bit formats and
map them to the 10-bit NVENC buffer formats, truncating the two least
significant bits: P012 -> YUV420_10BIT, P212 -> P210, YUV444P12MSB ->
YUV444_10BIT. They are added to the supported input format list and to
the IS_10BIT / IS_YUV444 / IS_YUV422 helpers accordingly.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
fate-filter-mcdeint-slow and -slow-edge feed testsrc (RGB24 only) into
mcdeint (YUV420P/YUV444P only), so ffmpeg auto-inserts a scale filter to
convert the pixel format. That conversion needs swscale, so both tests
fail to configure the filter graph under --disable-swscale:
Error configuring filter graph: Invalid argument
Conversion failed!
Reported by the x86_64-archlinux-gcc-disableswscale FATE slot. Add
SCALE_FILTER to their dependency list so they are skipped when the scale
filter (and thus swscale) is unavailable, matching the existing
convention for conversion-dependent FATE tests.
Signed-off-by: Bogdan Lisman <bogdan@pydevsolutions.com>
If we send `Connection: close` but don't get any response Connection header
back from the HTTP server, we should still assume the server will close our
connection.
There is a minor bit of ambiguity about what state to assume if the user
overrode the "Connection:" header, but I'm optimistically leaning in
favor of keep-alive as the more likely value for a user to set.
Not updating our internal state tracking as a result of user-provided
headers overriding our own headers is a prior problem with http.c that is
outside the scope of this PR to fix.
Signed-off-by: Niklas Haas <git@haasn.dev>
This is needed when building with OpenSSL enabled on macOS after
c32a719cb2.
The tls_openssl.c contains a number of explicit calls to strlen(),
which require including <string.h>.
This fixes detection on toolchains where the compiler is able to
compile code with __int128, but the toolchain doesn't automatically
link in suitable helper functions needed for handling division.
(In practice, clang targeting MSVC environments.)
Trim out any files we don't need downstream.
Automate doing the subtree merges, and automate resolving the
conflicts for updates for files that we want to have removed.
If updates end up with other conflicts, the script (or in practice,
git) exits without creating the intended merge commit - but
regular updates should run automatically.
This is very slow otherwise (10x slower than with native int128). Developers
can still manually run it if they need to, but we should exclude it from
the default FATE target.
Signed-off-by: Niklas Haas <git@haasn.dev>
No longer needed with AVRational64. Now we can just apply_op_q(), on
everything except floating point types (which are still not representable
in AVRational64 and likely never will be, though this is mostly a moot
point as the uops layer can still optimize this further).
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
1. This is currently impossible to trigger
2. We're about to switch to AVRational64, eliminating this concern
3. The AVRational64 API intentionally doesn't expose av_reduce64()
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This formulation is generally preferred as it avoids the risk of (1 << depth)
overflowing when depth is 32/64/etc.
I also wanted to have these in a common place to make the upcoming changes
easier.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
These come with some challenging ambiguity in the following patch to switch
from AVRational to AVRational64, so best just avoid them and have individual
usage sites define them locally with the correct type.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
This is needed by the ops code, to represent intermediate values for 32-bit
formats, which can exceed the value range of int32_t (especially for
intermediate products).
I copied the math almost 1:1 from rational.c, but adapted to use the 128-bit
integer wrappers defined by int128.h. I added a generous amount of tests in
any case.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
