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>
Fixes FATE on a variety of configurations due to accuracy problems in
floating point math. Most constants tested against here are not even
specified with 7 decimal digits.
Reviewed-by: Niklas Haas <git@haasn.dev>
The existing av_csp_trc_func_from_id() mostly implements the OETF, except for
PQ. As such, we are currently missing a precise definition of an ITU-R EOTF.
Introduce the new functions av_csp_itu_eotf() and av_csp_itu_eotf_inv(), to fill
this void. Note that this is not possible in all cases, e.g. AVCOL_TRC_LOG which
has no corresponding EOTF definition in any ITU-R standard.
Note that we cannot implement the proper HLG and SMPTE 428 OOTFs without access
to all three color channels, because they are not independent per channel. As a
result, we need to define them on double[3] instead of double (*func)(double).
This explanation was inaccurate and highly misleading. The new wording is taken
more or less directly from ITU-T H.273, and also matches my understanding of
these functions.
And add wasm simd128 flag, so we can add simd128 optimizations.
It can be enabled by put -msimd128 to extra cflags. There is
no runtime detection on simd128 support yet. I think that needs to
be done with JavaScript.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
alignas is portable than compiler's specific __attribute__. It do
have a limitation, that alignas don't support specify aligment on
the declarations of struct (it works for specify alignment on struct
fields), which only used by avcodec/cavs, and is removed now.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The code used to use atomic, but over time, this got broken.
This commit also remmoves the is-the-last-submission-ready
shortcut, which rarely did anything.
There's also value in relying on the fact that contexts
always carry their frames in a strictly incremental order
with no gaps.
This allows the encoder to fully saturate all queues the GPU
has, giving a good 10% in certain cases and resolutions.
This also improves error resilience if an allocation fails,
and properly cleans up after itself if it does.
This function dates back a long time ago, before vkfmt_from_pixfmt2.
When it was converted over, the thought was that this was far too
restrictive to demand storage images for each format.
With the new clever function, it makes sure to check that the compatible
subformats a format can be used as support storage capabilities.
This gets rid of fake support for RGB48/RGB96 which some implementations
offer but don't support using as storage images.
This avoids unpleasant surprises to av_frame_get_buffer callers
that explicitly specified 64-byte alignment and didn't get
AVFrame.data pointers that are 64-byte aligned.
For example, see https://github.com/sekrit-twc/zimg/issues/212
Although the zscale issue has already been resolved by other means
it would still be prudent to improve the behavior of av_frame_get_buffer
to fix any unknown and future instances of similar issues.
Co-authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
STRIDE_ALIGN is a lavc define and is not necessarely 32. And align may be <= 0 at the
point plane_padding is being set.
Signed-off-by: James Almer <jamrial@gmail.com>
The code used as a basis was the buffer dependency code, where the
counter was incremented after each buffer, but for the sw_frame dep
API, we only support adding individual frames at a time.
libavutil/riscv: Make use of elf_aux_info() on FreeBSD / OpenBSD riscv
FreeBSD/OpenBSD riscv have elf_aux_info().
Signed-off-by: Brad Smith <brad@comstyle.com>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
The half-baked assembler in Clang 16 and earlier can't process our
RISC-V assembler. This adds yet another work around that.
If you must use Clang, please use version 17 or later.
We do uploads asynchronously, and we map the software frames in
order to avoid 2-stage copying. However, whilst we added a dependency
upon the mapped buffers, we did not add the original frame backing
those buffers as a dependency.
This caused issues on RADV, particularly with RGB images.
This reverts 887d74c47e, because it ignores the
maximum allowed numerator/denominator. Even if the result was rounded to zero
or infinity, it should not be cause to ignore the maximum allowed number, this
"feature" is unintuitive and undocumented.
Signed-off-by: Marton Balint <cus@passwd.hu>
Use DXGI/D3DFMT 16bit pixel format to compatible with 12bit Y212/XV36
since there is no 12bit pixel defined in D3D11/D3D9.
Fix cmdline on Windows:
$ ffmpeg.exe -hwaccel qsv -init_hw_device qsv:hw,child_device_type=
{d3d11, dxva2} -i input_12bit.bin -f null -
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Also include the hardware feature flags like the other archs do and
clean up the code a bit.
Tested on Linux POWER9.
Signed-off-by: Brad Smith <brad@comstyle.com>
Anton Khirnov
Kacper Michajłow
James Almer
Hendrik Leppkes
Niklas Haas
Zhao Zhili
Lynne
Rémi Denis-Courmont
Pavel Koshevoy
Brad Smith
tangsha
Marton Balint
Fei Wang
Sean McGovern
Brad Smith