The current parser does things which a parser should not, like skipping parts
of the packet header, but it does not actually able to packetize a raw DNXUC
bitstream.
Rework the parser logic to work similar to other parsers and be able to
correctly packetize raw DNXUC bitstreams.
Bump minor version because the DNXUC codec packet format changes with this.
Normally this would be a breaking change, but in this particular case it should
not cause any issues in practice because the DNXUC codec is relatively new and
we never added a decoder for it.
Signed-off-by: Marton Balint <cus@passwd.hu>
This is an experimental and research codec of which ffmpeg is the only
encoder and decoder, development has stalled since 2013 and these files
don't exist in the wild.
Deprecate the encoders to be removed next major bump, decoders to be
removed one bump afterwards. We also disable the the encoders by default
in configure, the decoders should be disabled by default next bump.
Signed-off-by: J. Dekker <jdek@itanimul.li>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Ensure downmixed is only set once during init, as it used to be.
Fixes a regression since acbb2777e2.
Fixes ticket #11321
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: Null pointer dereference
Fixes: sample1.dng
Found-by: South East <8billion.people@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
xHE-AAC is a profile where some frames depend on other key frames, named IPF.
By setting the codec as Intra Only, all frames output by decoders and all
packets output by encoders/demuxers will be unconditionally flaged as
keyframes, which is incorrect.
Should fix ticket #11272.
Signed-off-by: James Almer <jamrial@gmail.com>
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>
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.
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.
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.
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).
