The start code is matched against 0x000001, zero_byte was treated
as last byte of last frame rather than the beginning of next frame.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This patch populates the third entry for HLS codec attribute using the
AAC profile.
The HLS specifications[1] require this value to be the Object Type ID as
referred to in table 1.3 of ISO/IEC 14496-3:2009[2].
The numerical constants in the code refer to these OTIs minus one, as
documented in commit 372597e[3], confirmed by comparing the values in the
code with the values in the table mentioned above.
Links:
1: https://datatracker.ietf.org/doc/html/rfc6381#section-3.3
2: https://csclub.uwaterloo.ca/~ehashman/ISO14496-3-2009.pdf
3: 372597e538
Changes in this version:
- Default value set to "mp4a.40.2" when profile is unknown for backward
compatibility.
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
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>
This is the main entry point for the CTU (Coding Tree Unit) decoder.
The code will divide the CTU decoder into several stages.
It will check the stage dependencies and run the stage decoder.
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>
Generalize drawtext utilities to make them usable in other filters.
This will be needed to introduce the QR code source and filter without
duplicating functionality.
The function lf_db_new was deprecated in lensfun 09dcd3e7ad in 2017
in favour of lf_db_create. The AVfilter was adjusted in 8b78eb312d
but the configure check wasn't changed.
lensfun removed lf_db_new declaration in lf 35c0017593 so configure
fails to find lensfun.
Rewrite the format parsing code to make it more easily generalizable. In
particular, `invert_formats` does not depend on the type of format list
passed to it, which allows me to re-use this helper in an upcoming
commit.
Slightly shortens the code, at the sole cost of doing several malloc
(ff_add_format) instead of a single malloc.
This is at odds with the YUV matrix negotiation API, in which such
dynamic changes in YUV encoding are no longer easily possible. There is
also no really strong motivating reason to do this, since the choice of
YUV matrix is essentially arbitrary and not actually related to the
Dolby Vision decoding process.
This filter will always accept any input format, even if the user sets
a specific in_range/in_color_matrix. This is to preserve status quo with
current behavior, where passing a specific in_color_matrix merely
overrides the incoming frames' attributes. (Use `vf_format` to force
a specific input range)
Because changing colorspace and color_range now requires reconfiguring
the link, we can lift sws_setColorspaceDetails out of scale_frame and
into config_props. (This will also get re-called if the input frame
properties change)
To allow adding proper negotiation, in particular, to fftools.
These values will simply be negotiated downstream for YUV formats, and
ignored otherwise.