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>
It is wasteful to open the subdemuxer if an error occurs while
initializing streams or reading IFO headers.
Signed-off-by: Marth64 <marth64@proxyid.net>
The "auto" mode serves no functional purpose except for logging
a message and setting the value to 1. The documentation clearly
explains what the option is for.
Signed-off-by: Marth64 <marth64@proxyid.net>
Menu 0 is the VIDEO_TS root menu, which does not appear to be used
commonly for menu segments. Instead, default to the menu of VTS 1.
Signed-off-by: Marth64 <marth64@proxyid.net>
Some discs present titles with bogus NAV packets. We apply this check
for menus and for title MPEG blocks, but we should also apply it
for NAV packets during title demuxing.
Signed-off-by: Marth64 <marth64@proxyid.net>
DVDs naturally consist of segmented MPEG-PS blobs within a VOB
(i.e. VOBs are not linear). NAV packs set the segment boundaries.
When switching between segments, discontinuities occur and thus
the subdemuxer needs to be reset. The current approach to manage
this is by invoking ff_read_frame_flush() on the subdemuxer context,
via a callback function which is invoked during the menu or dvdnav
block functions. The same subdemuxer context is used throughout
the demux, with a stretched PTS wrap bits value (64) + disabled
overflow correction, and then flushed on each segment. Eventually,
a play_end context variable is set to declare EOF.
However, this approach causes frame drops. The block read flushes the
demuxer before the frame read is complete, causing frames to drop
on discontinuity. The play_end signal likewise ends playback before
the frame read is complete, causing frames to drop at end of the title.
To compound the issue, the PTS wrap bits value of 64 is wrong;
the VOBU limit is actually 32 and the overflow correction should work.
Instead, EOF the MPEG-PS subdemuxer organically when each VOB segment
ends, and re-open it if needed with the offset after the full frame read
is complete. In doing so, correct the PTS wrap behavior to 32 bits and
remove the play_end/segment_started signals and callback pattern.
Note that the timestamps as reported by the NAV packets are known as
"PTMs", so the fields storing the time prior to adjustment are renamed
accordingly. This makes it more clear when we are offsetting the
NAV packet reported timestamps versus what we present as a demuxer.
Signed-off-by: Marth64 <marth64@proxyid.net>
