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 459a1512f1,
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.
After the branch, the expected SEW/LMUL ratio is 1 byte/vector.
So we have to set the same ratio before branching (QEMU does not care,
but real hardware does).
Some DVD muxers signal segments to start with duplicate audio samples
when starting extraction from a chapter marker or terminate seamless PGs
on partial audio samples (causing corrupt AC3 frames). Clean up after
these muxers by tracking frames with duplicate PTS and eliminating
partial AC3 frames.
This results in smoother chapter extraction and overall seeking experience,
with linear PTS and AC3 delay within 32ms (1 frame) away from the video.
The issue was not apparent until the flushing pattern was replaced with
a full subdemux reset, as the flushing dropped the frames prematurely,
along side others, as such they were never present to begin with.
The packets effectively serve no purpose and we are already
dropping packets with PTS less than 0. This also creates
for a smoother seeking experience after the subdemuxer
reset fix.
Signed-off-by: Marth64 <marth64@proxyid.net>
Peter Ross
Marth64
Scott Theisen
Michael Niedermayer
Richard Mitic
Zhao Zhili
Lynne
Leandro Santiago
James Almer
Eugene Zemtsov
Brad Smith
Rémi Denis-Courmont
tangsha