Add external encoder VVenC for H266/VVC encoding.
Register new encoder libvvenc.
Add libvvenc to wrap the vvenc interface.
libvvenc implements encoder option: preset,qp,qpa,period,
passlogfile,stats,vvenc-params,level,tier.
Enable encoder by adding --enable-libvvenc in configure step.
Co-authored-by: Christian Bartnik chris10317h5@gmail.com
Signed-off-by: Thomas Siedel <thomas.ff@spin-digital.com>
Introduced in 1992, the Alpha was a 64-bit RISC processor designed
to replace the VAX CISC machines sold by Digital Equipment Corporation.
After Digital was acquired by Compaq in 1998 -- who themselves would be
later purchased by Hewlett-Packard, the architecture was phased out over
the following decade. It became effectively defunct in 2007, the last
publicly available processor being the Alpha 21364.
FFmpeg has not added any DSP code for this architecture since lowres2
was introduced in 2012, and it is more than unlikely someone still wishes
to maintain it.
Remove the DSP and support code.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This is automatically enabled if the width/height expressions reference
any ref_* variable. This will ultimately serve as a more principled
replacement for the fundamentally broken scale2ref.
See-Also: https://trac.ffmpeg.org/ticket/10795
This allows one complex filtergraph's output to be sent as input to
another one, which is useful in certain situations (one is described in
the docs).
Chaining filtergraphs was already effectively possible by using a
wrapped_avframe encoder connected to a loopback decoder, but it is ugly,
non-obvious and inefficient.
The LC3 audio codec is the default codec of Bluetooth LE audio.
This is a wrapper over the liblc3 library (https://github.com/google/liblc3).
Signed-off-by: Antoine Soulier <asoulier@google.com>
RCWT (Raw Captions With Time) is a format native to ccextractor,
a commonly used OSS tool for processing 608/708 Closed Captions (CC).
RCWT can be used to archive the original extracted CC bitstream.
The muxer was added in January 2024. In this commit, add the demuxer.
One can now demux RCWT files for rendering in ccaption_dec or interop
with ccextractor (which produces RCWT). Using the muxer/demuxer combo,
the CC bits can be kept for processing or rendering with either tool.
This can be an effective way to backup an original CC stream, including
format extensions like EIA-708 and overall original presentation.
Signed-off-by: Marth64 <marth64@proxyid.net>
It should be available in all relevant modern compilers and will allow
us to use features like anonymous unions.
Note that stdatomic.h is still emulated on MSVC, as current versions
require the /experimental:c11atomics, and do not support
ATOMIC_VAR_INIT() anyway.
Signed-off-by: Marth64 <marth64@proxyid.net>
Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
used open source tool for processing 608/708 closed caption (CC) sources.
It can be used to archive the original, raw CC bitstream and to produce
a source file file for later CC processing or conversion. As a result,
it also allows for interopability with ccextractor for processing CC data
extracted via ffmpeg. The format is simple to parse and can be used
to retain all lines and variants of CC.
A free specification of RCWT can be found here:
https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT
This muxer implements the specification as of 01/05/2024, which has
been stable and unchanged for 10 years as of this writing.
This muxer will have some nuances from the way that ccextractor muxes RCWT.
No compatibility issues when processing the output with ccextractor
have been observed as a result of this so far, but mileage may vary
and outputs will not be a bit-exact match.
Specifically, the differences are:
(1) This muxer will identify as "FF" as the writing program identifier, so
as to be honest about the output's origin.
(2) ffmpeg's MPEG-1/2, H264, HEVC, etc. decoders extract closed captioning
data differently than ccextractor from embedded SEI/user data.
For example, DVD captioning bytes will be translated to ATSC A53 format.
This allows ffmpeg to handle 608/708 in a consistant way downstream.
This is a lossless conversion and the meaningful data is retained.
(3) This muxer will not alter the extracted data except to remove invalid
packets in between valid CC blocks. On the other hand, ccextractor
will by default remove mid-stream padding, and add padding at the end
of the stream (in order to convey the end time of the source video).
vvc decoder plug-in to avcodec.
split frames into slices/tiles and send them to vvc_thread for further decoding
reorder and wait for the frame decoding to be done and output the frame
Features:
+ Support I, P, B frames
+ Support 8/10/12 bits, chroma 400, 420, 422, and 444 and range extension
+ Support VVC new tools like MIP, CCLM, AFFINE, GPM, DMVR, PROF, BDOF, LMCS, ALF
+ 295 conformace clips passed
- Not support RPR, IBC, PALETTE, and other minor features yet
Performance:
C code FPS on an i7-12700K (x86):
BQTerrace_1920x1080_60_10_420_22_RA.vvc 93.0
Chimera_8bit_1080P_1000_frames.vvc 184.3
NovosobornayaSquare_1920x1080.bin 191.3
RitualDance_1920x1080_60_10_420_32_LD.266 150.7
RitualDance_1920x1080_60_10_420_37_RA.266 170.0
Tango2_3840x2160_60_10_420_27_LD.266 33.7
C code FPS on a M1 Mac Pro (ARM):
BQTerrace_1920x1080_60_10_420_22_RA.vvc 58.7
Chimera_8bit_1080P_1000_frames.vvc 153.3
NovosobornayaSquare_1920x1080.bin 150.3
RitualDance_1920x1080_60_10_420_32_LD.266 105.0
RitualDance_1920x1080_60_10_420_37_RA.266 133.0
Tango2_3840x2160_60_10_420_27_LD.266 21.7
Asm optimizations still working in progress. please check
https://github.com/ffvvc/FFmpeg/wiki#performance-data for the latest
Contributors (based on code merge order):
Nuo Mi <nuomi2021@gmail.com>
Xu Mu <toxumu@outlook.com>
Frank Plowman <post@frankplowman.com>
Shaun Loo <shaunloo10@gmail.com>
Wu Jianhua <toqsxw@outlook.com>
Thank you for reporting issues and providing performance reports:
Łukasz Czech <lukaszcz18@wp.pl>
Xu Fulong <839789740@qq.com>
Thank you for providing review comments:
Ronald S. Bultje <rsbultje@gmail.com>
James Almer <jamrial@gmail.com>
Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Co-authored-by: Xu Mu <toxumu@outlook.com>
Co-authored-by: Frank Plowman <post@frankplowman.com>
Co-authored-by: Shaun Loo <shaunloo10@gmail.com>
Co-authored-by: Wu Jianhua <toqsxw@outlook.com>
