Logic is loosely on equivalent decisions in libplacebo. The basic idea is to try
and be a bit conservative by treating AVCOL_*_UNSPECIFIED as a no-op, unless the
other primaries set are non-standard / wide-gamut or HDR. This helps avoid
unintended or unexpected colorspace conversions, while forcing it in cases where
we are almost certain it is needed. The major departure from libplacebo semantics
is that we no default to a 1000:1 contrast ration for SDR displays, instead modelling
them as idealized devices with an infinite contrast ratio.
In either case, setting SWS_STRICT overrides this behavior in favor of always
requiring explicit colorspace metadata.
Logic ported from libplacebo's AVFrame helpers. The basic idea is to use the
provided MaxRGB/MaxSCL values to infer what the actual luminance would have
been, which HDR10+ metadata does not provide directly. It's worth pointing out
that this gives us an *upper* bound on the true maximum luminance, so any
error in the estimation cannot result in clipping.
Only add the condensed values that we actually care about. Group them into
a new struct to make it easier to discard or replace this metadata.
Define a special comparison function that does not choke on undefined/unknown
metadata.
As fixed in the previous commit, this enables semipacked range and
bit depth conversions. Previously these would go through the general
purpose path.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
This fixes multiple bugs with semiplanar formats like NV12. Not only do these
false positive the grayscale format checks (because dst[2] in NULL), but they
also copied an incorrect number of pixels.
Fixes conversions such as nv12 -> nv12, gray8 -> nv12, nv20le -> nv20be, etc.
Fixes: #11239
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
We should at least bias towards the nearest integer, instead of always
rounding down, when not dithering. This is a bit more correct.
The FATE changes are only in the cases where sws_dither was explicitly set
to "none", which is exactly as expected.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
This code only checks hcScale. In practice this is not an issue because
the function pointers should always be identical to hyScale for the same
filter size.
Add an assertion just to make sure this assumption never regresses.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
We recently introduced a public field which was a superset
of the queue context we used to have.
Switch to using it entirely.
This also allows us to get rid of the NIH function which was
valid only for video queues.
This code was simply incorrect through and through. It did not
protect what actually has to be protected in a multi-threaded setup.
Perhaps it was used to silence threading errors?
Either way, remove it, and document the correct way to use execution
pools in a threaded environment.
Originally, the decoder had a single execution pool, with one
execution context per thread. Execution pools were always intended
to be thread-safe, as long as there were enough execution contexts
in the pool to satisfy all threads.
Due to synchronization issues, the threading part was removed at some
point, and, for decoding, each thread had its own execution pool.
Having a single execution pool per context is hacky, not to mention
wasteful.
Most importantly, we *cannot* associate single shaders across multiple
execution pools for a single application. This means that we cannot
use shaders to either apply film grain, or use this framework for
software-defined decoders.
The recent commits added threading capabilities back to the execution
pool, and the number of contexts in each pool was increased. This was
done with the assumption that the execution pool was singular, which
it was not. This led to increased parallelism and number of frames
in flight, which is taxing on memory.
This commit finally restores proper threading behaviour.
The validation layer has isses that are reported and addressed in the
earlier commit.
Some drivers are more strict about the size of the reference lists given
(i.e. VAOn12 [1]). The next_prev list is used to handle multiple "L0"
references in AV1 encode. Restrict the size of next_prev based on the
value of ref_l0 when the GOP structure is initialized.
[1] https://github.com/intel/cartwheel-ffmpeg/issues/278
v2: fix indentation issues
These functions were divided into two special cases; one assuming that
uvalpha == 0, and the other assuming that uvalpha == 2048. This worked fine
for simple 2x chroma upscaling but broke for e.g. yuv410p, non-centered chroma,
or other special cases that involved non-aligned chroma filters.
Fix it by instead dividing this check into two cases, a uvalpha==0 fast path
and a uvalpha>0 general path. Instead of (A+B)/2 the general path now multiplies
in the true uvalpha weight.
I tried preserving the old fast path for the case of uvalpha == 2048, but this
was significantly slower in practise versus having just one general path.
However, we still need a uvalpha == 0 path for the unscaled case.
Fixes: ticket #5083
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
As per section 3.11.1 of the IAMF spec, the sample rate used in Codec Config
for Opus shall be 48kHz, regardless of the original sample rate used during
encoding.
Signed-off-by: James Almer <jamrial@gmail.com>
This option, which is also available on other FFmpeg hardware encoders,
allows the user to trade throughput for reduced output latency. This is
useful for ultra low latency applications like game streaming.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Since its introduction, this function has claimed to return 0 on success, yet
never actually did so (until the introduction of the new graph based API). It
always returned the number of scaled lines, and continues to do so.
To avoid confusion, but also avoid regressing possible clients that relied on
the existing semantics, simply update the documentation to reflect the actual
behavior. Remain ambiguous about the exact interpretation of the return value
on account of the unfortunate difference in behavior between the legacy and
new scaling APIs.
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
This logic was inverted, but || was not replaced by &&.
Fixes: ed5dd67562
Fixes: ticket #11353
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
It's currently actually not used in MSVC builds, since
6e49b86996.
Older versions of MSVC (or, in particular, older versions of UCRT)
don't have stdalign.h; it's available since WinSDK 10.0.20348.0;
such a new enough version has been installed by default only since
MSVC 2022 17.4 and newer.
With this change, ffmpeg can still be built with MSVC 2019 16.8
(v19.28).
Signed-off-by: Martin Storsjö <martin@martin.st>
Explicitly use ldur for unaligned offsets; newer versions of
armasm64 implicitly convert ldr to ldur as necessary, but older
versions require it explicitly written out.
This fixes these build errors:
ffmpeg\libavcodec\aarch64\vvc\inter.o.asm(2039) :
error A2518: operand 2: Memory offset must be aligned
ldr s5, [x1, #1]
ffmpeg\libavcodec\aarch64\vvc\inter.o.asm(2250) :
error A2518: operand 2: Memory offset must be aligned
ldr d7, [x1, #2]
Signed-off-by: Martin Storsjö <martin@martin.st>
Fix test failure on aarch64:
./tests/checkasm/checkasm --test=h264pred 367840
Signed-off-by: Peng Bin <pengbin@visionular.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
Fix test failure on aarch64:
./tests/checkasm/checkasm --test=h264pred 479612
The mismatch between neon and C functions can also be reproduced using the following bitstream and command line.
wget https://streams.videolan.org/ffmpeg/incoming/intra8x8pred_10bit.264
./ffmpeg -cpuflags 0 -threads 1 -i intra8x8pred_10bit.264 -f framemd5 -y md5_ref
./ffmpeg -threads 1 -i intra8x8pred_10bit.264 -f framemd5 -y md5_neon
Signed-off-by: Bin Peng <pengbin@visionular.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
