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: ed5dd675624c83d9c69b406ce30e4e09f29970e3
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
6e49b8699657b808b7dc80033f2c3f2d0e029fa3.
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>
In input.c and output.c and many other places, swscale follows the rule of using
15-bit intermediate if output bpc is <= 8, and 19-bit (inside int32_t)
intermediate otherwise. See e.g. the comments on hyScale() on
swscale_internal.h. These are also the coefficients that yuv2gbrpf32_full_X_c()
is using.
In contrast to this, the plane init code in slice.c (function fill_ones) is
assuming that we use 35-bit intermediates (inside 64-bit integers) for this
case, seemingly added by commit b4967fc71c63eae8cd96f9c46cd3e1fbd705bbf9 with
no further justification.
This causes a mismatch whenever the implicitly initialized plane contents leak
out to the output, e.g. when converting from grayscale to RGB.
Fixes: ticket #10716
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
pthread_t is currently defined as a struct, which gets placed into
caller's memory and filled by pthread_create() (which accepts a
pthread_t*).
The problem with this approach is that pthread_join() accepts pthread_t
itself rather than a pointer to it, so it gets a _copy_ of this
structure. This causes non-deterministic failures of pthread_join() to
produce the correct return value - depending on whether the thread
already finished before pthread_join() is called (and thus the copy
contains the correct value), or not (then it contains 0).
Change the definition of pthread_t into a pointer to a struct, that gets
malloced by pthread_create() and freed by pthread_join().
Fixes random failures of fate-ffmpeg-error-rate-fail on Windows after
433cf391f58210432be907d817654929a66e80ba.
See also [1] for an alternative approach that does not require dynamic
allocation, but relies on an assumption that the pthread_t value
remains in a fixed memory location.
[1] 23829dd2b2
Reviewed-By: Martin Storsjö <martin@martin.st>
When subblock durations are constant, the last block may be smaller and the
value needs to be calculated.
Signed-off-by: James Almer <jamrial@gmail.com>
Section 3.6.1 of the IAMF spec states "When constant_subblock_duration is equal to 0, the summation of all
subblock_duration in this parameter block SHALL be equal to duration.".
Signed-off-by: James Almer <jamrial@gmail.com>
The queue needs to track each frame/packet's stream index, this is
achieved by maintaining a parallel AVFifo instance for that purpose.
This is simpler than implementing custom AVContainerFifo callbacks.
This can be useful in other places, e.g. it can replace objpool in
fftools.
The API is modified in the following nontrivial ways:
* opaque pointers can be passed through to all user callbacks
* read and write were previously separate callbacks in order to
accomodate the caller wishing to write a new reference to the FIFO and
keep the original one; the two callbacks are now merged into one, and
a flags argument is added that allows to request such behaviour on a
per-call basis
* new peek and drain functions
This makes the behavior of av_file_map() the same on Windows as it is on
other platforms. The file is opened as read-only, but the mapping is
copy-on-write, allowing the user to write to the memory pages returned
by av_file_map().
This commit fixes libavutil\tests\file.c test, which would crash when
trying to write to a read-only memory page.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Currently, ffprobe has two stream-level fields that do not work,
closed_captions and film_grain).
Their value is always 0 because ffprobe cannot access the internal
codec properties when it is setting up its stream contexts.
In this commit, add the new option -analyze_frames to ffprobe,
allowing the user to read frames up to the interval they have defined
and fill these fields based on what is exposed in AVPacketSideData.
Additionally, in the same commit, don't write these fields to
the output unless analyze_frames is enabled. Finally, fix the
FATE test refs accordingly and update the docs.
Signed-off-by: Marth64 <marth64@proxyid.net>
After introduction of ff_dvdclut_palette_extradata_cat() to convert
DVD subtitle palettes from YUV to RGB, a leak is introduced because
of the call to ff_alloc_extradata(). This is not necessary, instead
we should free the extradata because ff_bprint_to_codecpar_extradata()
will finalize the bprint'ed string to the codecpar and set the length.
Fixes leak introduced in 3b0e6c0eccd7d61eb089370fc5f2196c2b30336f.
Signed-off-by: Marth64 <marth64@proxyid.net>
This fixes occasional failed tests, if doing "make fate" without a
regular "make" or "make all" inbetween.
Signed-off-by: Martin Storsjö <martin@martin.st>
If running tests with "make -j<N> fate", the execution will stop
after the first failing test. To get an overview of the whole
test suite, one rather would run "make -k -j<N> fate", which then
again buries the results about what tests actually failed further
up in the console log.
Add a target so one can run "make fate-list-failing", to see a list
of all tests that failed the last time they were executed.
Also add a companion target "fate-clear-reports" which removes all
the old test reports. (When executing a subset of tests, the report
files of all tests that aren't executed stay untouched. This also
allows getting rid of reports for tests that no longer are present
in the testsuite.)
Co-authored-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Martin Storsjö <martin@martin.st>
This corresponds to commit 9278a14cf406f8edb5052c42b83750112bf5b515
in dav1d.
Omitting the C-only functions doesn't speed up benchmarking
anyway (as those has to be benchmarked before we know if we have
any corresponding assembly functions), and being able to benchmark
those functions without corresponding assembly can be valuable in
a number of cases.
Signed-off-by: Martin Storsjö <martin@martin.st>
We only parse 12 values, so this check always failed. Regression caused by
a change to the print format.
Fixes: 59c39a79cafdcb46972380aac5644f84059cd2a8
Signed-off-by: Niklas Haas <git@haasn.dev>
Sponsored-by: Sovereign Tech Fund
