avgBitrate == 0 is used to signal a VBR track, so if that value is propagated by an
encoder, don't overwrite it with a calculated value based on track size.
Part of a fix for ticket #11303.
Signed-off-by: James Almer <jamrial@gmail.com>
Don't reject extradata with missing PS NALUs if array_completeness is not
requested.
Fixes a regression since a696b28886.
Signed-off-by: James Almer <jamrial@gmail.com>
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>
This is a preliminary step to separating these into a new struct. This
commit contains no functional changes, it is a pure search-and-replace.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
Reorganize the list, fix whitespace, make indentation consistent, and
rename some descriptions for clarity, consistency or informativeness.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas <git@haasn.dev>
ATSC A/52:2018 Digital Audio Compression (AC-3, E-AC-3), Annex G
defines stream_type 0x87 for E-AC-3 bit streams.
Signed-off-by: Marton Balint <cus@passwd.hu>
Some mp3 files look surprisingly like mpeg PS streams. In order for us
to hint to ffmpeg that the file really is mp3, we can deliver it with a
mime type. The mp3 probe therefore needs to have a mime type registered,
(which is previously did not).
For example, with
./ffmpeg -operating_rate 400 -hwaccel mediacodec -i test.mp4 -an \
-c:v h264_mediacodec -operating_rate 400 -b:v 5M -f null -
The transcoding speed is 254 FPS.
Without -operating_rate on dec/enc, the speed is 148 FPS.
With -operating_rate on decoder only, the speed is 239 FPS.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The codec wants to know whether the usecase is realtime playback
or full-speed transcoding, or playback at a higher speed. The codec
runs faster when operating_rate higher than framerate.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
The typo has no real effect except confusing.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Reported-by: Chen Haibo
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
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.
Unlike the software FFv1 encoder, none of our buffers are allocated by
FFmpeg, which supports at most 4GiB large allocations.
For really large sizes, the maximum size of the buffer can exceed 4GiB,
which the software encoder optimistically tries to allocate as 4GiB
in the hopes that the encoder will compress to under that amount.
We can just let Vulkan allocate us a larger buffer, and switch to
64-bit offsets.
Ref https://trac.ffmpeg.org/ticket/11152
According to harfbuzz docs, hb_ft_font_set_funcs() does not need to be
called, as, quoted:
```
An #hb_font_t object created with hb_ft_font_create()
is preconfigured for FreeType font functions and does not
require this function to be used.
```
Using this function seems to cause memory management issues between
harfbuzz and freetype, and could be eliminated.
This commit also call hb_ft_font_changed() when the underlying FC_Face
changes size, as stated on hardbuzz:
```
HarfBuzz also provides a utility function called hb_ft_font_changed() that you should call
whenever you have altered the properties of your underlying FT_Face, as well as a hb_ft_get_face()
that you can call on an hb_font_t font object to fetch its underlying FT_Face.
```
Finally, the execution order between hb_font_destroy() and
hb_buffer_destroy() is flipped to match the order of creation of
the respective objects.
Signed-off-by: Leandro Santiago <leandrosansilva@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
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>
As of 459a1512f13ae1fdd404ff9281b02d225ac70a09,
the code is unrolled to process two rows per iteration.
The output cursor thus needs to be incremented by twice the
stride, which is taken care of with SH1ADD. However the original
ADD from the original implemetation was incorrectly left over.
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.
This commit implements a standard, compliant, version 3 and version 4
FFv1 encoder, entirely in Vulkan. The encoder is written in standard
GLSL and requires a Vulkan 1.3 supporting GPU with the BDA extension.
The encoder can use any amount of slices, but nominally, should use
32x32 slices (1024 in total) to maximize parallelism.
All features are supported, as well as all pixel formats.
This includes:
- Rice
- Range coding with a custom quantization table
- PCM encoding
CRC calculation is also massively parallelized on the GPU.
Encoding of unaligned dimensions on subsampled data requires
version 4, or requires oversizing the image to 64-pixel alignment
and cropping out the padding via container flags.
Performance-wise, this makes 1080p real-time screen capture possible
at 60fps on even modest GPUs.
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.
