FIx warnings (soon to be errors in GCC 14, already so in Clang 15):
```
src/libavcodec/vulkan_av1.c: In function ‘vk_av1_create_params’:
src/libavcodec/vulkan_av1.c:183:43: error: initialization of ‘long long unsigned int’ from ‘void *’ makes integer from pointer without a cast [-Wint-conversion]
183 | .videoSessionParametersTemplate = NULL,
| ^~~~
src/libavcodec/vulkan_av1.c:183:43: note: (near initialization for ‘(anonymous).videoSessionParametersTemplate’)
```
Use Vulkan's VK_NULL_HANDLE instead of bare NULL.
Fix Trac ticket #10724.
Was reported downstream in Gentoo at https://bugs.gentoo.org/919067.
Signed-off-by: Sam James <sam@gentoo.org>
These functions encode a slice of alpha (1 to 8 macroblocks) which are
expected to be encoded as a repeated sequence of "[diff][run-1]", where
diff is the running difference of the alpha value and run is how many
times that value is expected to be duplicated (within the limit of a
grand total of 2048 unpacked samples, corresponding to a slice of 8 MB).
Even when run==0 (the run variable semantic is actually "run minus 1"),
there is always a diff previously encoded that needs a counter of at
least 1. This means we need to call put_alpha_run() unconditionally at
the end of the bitstream to account for the last running diff.
This commit fixes glitchy playbacks on QuickTime with M2 and M3 hardware
(but not M1 for some mysterious reason) with files generated with
commands such as:
ffmpeg -f lavfi -i testsrc2=d=5:s=912x320,chromakey -c:v prores_aw -profile:v 4 -y aw.mov
ffmpeg -f lavfi -i testsrc2=d=5:s=912x320,chromakey -c:v prores_ks -profile:v 4444 -y ks.mov
The glitch expresses itself deterministically as blinking black
rectangles on random frames (for example on frame 21, 54, 71, 79, ...).
Even with the proresdec from FFmpeg, overreads actually happens while
reading the run-minus-1 value (around val = get_bits(gb, 4) in
unpack_alpha()). This doesn't seem to cause any particular issue because
it simply overreads into the next slice, and because the decoder is
resilient, but it's still a problem.
The investigation leading to this fix was made possible because of paid
work for Jitter (https://jitter.video).
Fixes ticket #10255.
In the mov muxer (in mov_write_video_tag()), bits_per_coded_sample will
be written under certain conditions and is required to be 32 for the
transparency to be honored in QuickTime.
prores_kostya already has this setting but prores_anatoliy and
prores_videotoolbox didn't.
This commit removes the follow warning and error:
D3D12 WARNING: ID3D12CommandList::ResourceBarrier: Called on the same subresource(s) of
Resource(0x000002236E0E00D0:'Unnamed ID3D12Resource Object') in separate Barrier Descs
which is inefficient and likely unintentional. Desc[0] and Desc[1] on (subresource :
4294967295). [RESOURCE_MANIPULATION WARNING #1008: RESOURCE_BARRIER_DUPLICATE_SUBRESOURCE_TRANSITIONS]
D3D12 ERROR: ID3D12CommandList::ResourceBarrier: Before state (0x0: D3D12_RESOURCE_STATE_[COMMON|PRESENT])
of resource (0x000002236E0E00D0:'Unnamed ID3D12Resource Object') (subresource: 0) specified
by transition barrier does not match with the state (0x20000: D3D12_RESOURCE_STATE_VIDEO_DECODE_WRITE)
specified in the previous call to ResourceBarrier [RESOURCE_MANIPULATION ERROR #527:
RESOURCE_BARRIER_BEFORE_AFTER_MISMATCH]
Tested-by: Tong Wu <tong1.wu@intel.com>
Signed-off-by: Wu Jianhua <toqsxw@outlook.com>
Previous assertion was not useful. Now a warning is added to replace it.
For get_surface_index, we should return a zero index in case the index is not found.
But a warning is necessary to notify.
Signed-off-by: Tong Wu <tong1.wu@intel.com>
Previous max_num_refs was based on pp.frame_refs plus 1 and it could possibly
reaches the size limit. Actually it should be the size of pp.ref_frame_map
plus 1.
Signed-off-by: Tong Wu <tong1.wu@intel.com>
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>
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>
Fixes: out of array access
Fixes: 64081/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6151006496620544
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 2147478526 + 33924 cannot be represented in type 'int'
Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
Fixes: 64243/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEGLS_fuzzer-5195717848989696
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Forgot to init c->sao_edge_filter[idx] when idx=0/1/2/3.
After this patch, the speedup of decoding H265 4K 30FPS
30Mbps on 3A6000 is about 7% (42fps==>45fps).
Change-Id: I521999b397fa72b931a23c165cf45f276440cdfb
Reviewed-by: yinshiyou-hf@loongson.cn
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Rework the code a bit to speed up the 10-bit bitpacked decoding
routine. This is probably about as fast as I can get it without
switching to assembly language.
Demonstratable with:
./ffmpeg -f lavfi -i "smptehdbars=size=3840x2160" -c bitpacked -f image2 -frames:v 1 source.yuv
./ffmpeg -f bitpacked -pix_fmt yuv422p10le -s 3840x2160 -c:v bitpacked -i source.yuv -pix_fmt yuv422p10le out.yuv
On my development system, it went from 80ms for a 2160p frame
down to 20ms (i.e. a 4X speedup). Good enough for now, I hope...
Comments from Marton:
Originally on my system better performance could be achieved by simply
switching to the cached bitstream reader, but for Devin it was slower than
his direct byte operations.
I changed the order of writing output from u/y/v/y to u/v/y/y, and that made
the code faster than the cached bitstream reader on my system as well.
TIMER measurement of the decode loop on Ryzen 5 3600 with command line:
./ffmpeg -stream_loop 256 -threads 1 -f bitpacked -pix_fmt yuv422p10le -s 3840x2160 -c:v bitpacked -i source.yuv -pix_fmt yuv422p10le -f null none -loglevel error
Before: 823204127 decicycles in YUV, 256 runs, 0 skips
After: 315070524 decicycles in YUV, 256 runs, 0 skips
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
The specification doesn't mention that clusters cannot have alphabet
sizes greater than 1 << bundle->log_alphabet_size, but the reference
implementation rejects these entropy streams as invalid, so we should
too. Refusing to do so can overflow a stack variable that should be
large enough otherwise.
Fixes#10738.
Found-by: Zeng Yunxiang and Li Zeyuan
Signed-off-by: Leo Izen <leo.izen@gmail.com>
If a sequence of JXL images is encapsulated in a container that has PTS
information, we should use the PTS information from the container. At
this time there is no container that does this, but if JPEG XL support
is ever added to NUT, AVTransport, or some other container, this commit
should allow the PTS information those containers provide to work as
expected.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
These pixel formats have always been supported by libjxl, but at the
time this plugin was written, they were not in FFmpeg yet. Now that
they are in FFmpeg, we should support them.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
These pixel formats have always been supported by libjxl, but at the
time this plugin was written, they were not in FFmpeg yet. Now that
they are in FFmpeg, we should support them.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
FFmpeg doesn't support tv-range RGB throughout most of its pipeline, so
we should keep the warning. However, in case something does support it
we should at least keep it tagged properly. Additionally, the encoder
writes this tag if the space is tagged as such so this makes a round
trip work as it should.
Also, PNG doesn't support nonzero matrices but we only warn and ignore
in that case, so we have no reason to error out for illegal cICP ranges
either (i.e. greater than 1).
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reported-by: Kacper Michajłow <kasper93@gmail.com>
Sam James
Clément Bœsch
Wu Jianhua
Tong Wu
Zhao Zhili
Nuo Mi
James Almer
Michael Niedermayer
jinbo
Devin Heitmueller
Marton Balint
Leo Izen
Andreas Rheinhardt