fbw_channels must be > 0 as teh code is only run if cpl_enabled is set and that requires mode >= AC3_CHMODE_STEREO
CID 718138 Uninitialized scalar variable
assumes this assert to be false
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For a corrupted stream, the value of nalu_len read from the extradata is not reliable.
We need to perform additional checks
Fixes: fuzzer timeout
Fixes: 65253/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_MP4TOANNEXB_fuzzer-4972412487467008
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These chunks contain the Content Light Level Information and the
Mastering Display Color Volume information that FFmpeg already supports
as AVFrameSideData. This patch adds support for the png encoder to save
this metadata as the corresponding chunks in the PNG stream.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
These chunks contain the Content Light Level Information and the
Mastering Display Color Volume information that FFmpeg already supports
as AVFrameSideData. This patch adds support for the png decoder to read
these chunks if present and attach the corresponding side data to the
decoded frame.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
The function signature for bytestream2_seek is (gb, offset, whence);
Before this patch, the code passed (gb, SEEK_SET, offset), which is
incorrect.
Siged-off-by: Leo Izen <leo.izen@gmail.com>
vc1_hwaccel_pixfmt_list_420 is referenced even if
!(CONFIG_WMV3IMAGE_DECODER || CONFIG_VC1IMAGE_DECODER) so move it out
of the #if block.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The new API requires an extra array member at the very end,
which old API users did not do.
This disables in-place RDFT transforms and instead
does the transform out of place by copying once, there shouldn't
be a significant loss of speed as our in-place FFT requires a reorder
which is likely more expensive in the majority of cases to do.
These inline implementations of AV_COPY64, AV_SWAP64 and AV_ZERO64
are known to clobber the FPU state - which has to be restored
with the 'emms' instruction afterwards.
This was known and signaled with the FF_COPY_SWAP_ZERO_USES_MMX
define, which calling code seems to have been supposed to check,
in order to call emms_c() after using them. See
0b1972d409,
29c4c0886d and
df215e5758 for history on earlier
fixes in the same area.
However, new code can use these AV_*64() macros without knowing
about the need to call emms_c().
Just get rid of these dangerous inline assembly snippets; this
doesn't make any difference for 64 bit architectures anyway.
Signed-off-by: Martin Storsjö <martin@martin.st>
The previous assumption that DXV needs to be aligned to 16x16 was
erroneous. 4x4 works just as well, and FATE decoder tests pass for all
texture formats.
On the encoder side, we should reject input that isn't 4x4 aligned,
like the HAP encoder does, and stop aligning to 16x16. This both solves
the uninitialized reads causing current FATE tests to fail and produces
smaller encoded outputs.
With regard to correctness, I've checked the decoding path by encoding a
real-world sample with git master, and decoding it with
ffmpeg -i dxt1-master.mov -c:v rawvideo -f framecrc -
The results are exactly the same between master and this patch.
On the encoding side, I've encoded a real-world sample with both master
and this patch, and decoded both versions with
ffmpeg -i dxt1-{master,patch}.mov -c:v rawvideo -f framecrc -
Under this patch, results for both inputs are exactly the same.
In other words, the extra padding gained by 16x16 alignment over 4x4
alignment has no impact on decoded video.
Signed-off-by: Connor Worley <connorbworley@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
They are not intended for decoders (for which there is the get_format
callback in case the user has a choice).
Also note that the list was wrong for MPEG4, because it did not contain
the high bit depth pixel formats used for studio profiles.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They are not intended for decoders (for which there is the get_format
callback in case the user has a choice).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is currently called once in the codecs' init function
and once when (re)initializing the VC-1 decode context
(which happens upon frame size changes as well as before
decoding the first frame). The first one is unnecessary
now that vc1_decode_frame() no longer requires avctx->hwaccel
to be already set for hwaccel to work properly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
VC-1 uses a 0x03 escaping scheme like H.26x and our decoder
unescapes data for this purpose, but hardware accelerations
just want the data as-is and therefore get fed the original
data. The pointers to the actual data are only setcorrectly
if avctx->hwaccel is set (after all, they are only used in
this case).
There are two problems with this: The first is that the branch
is pointless; the second is that it is harmful, because
a hardware acceleration may be added after the packet has been
parsed (in case there is a reconfiguration e.g. due to frame
size changes) in which case decoding the first few frames
won't work.
So delete these branches.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is entirely unnecessary to use it given that all decoders
here share the same set of supported pixel formats. So just
hardcode this list.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AVCodec.pix_fmts is only intended for encoders (decoders use
the get_format callback to let the user choose a pix fmt).
So remove them for the decoders for which this is possible
without further complications; keep them for now in the codecs
that actually use them (by passing avctx->codec->pix_fmts to
ff_get_formatt()).
Also notice that some of these lists were wrong; e.g.
317b7b06fd added support for YUV444P16
for cuviddec, but forgot to add it to pix_fmts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This bug causes the DXT5 decoder to produce incorrect block texture data.
After the fix, textures are visually correct and match data decoded by
Resolume Alley (extracted with Nvida Nsight for comparison). Current FATE DXT5
samples did not cover this case.
Signed-off-by: Connor Worley <connorbworley@gmail.com>
DXV files seem to misnomer DXT5 and really encode DXT4 with
premultiplied alpha. At least, this is what Resolume alley does.
To check, encode some input with alpha as "Normal Quality, With Alpha"
in Alley, then decode the output with this change -- results are true
to the original input compared to git-master.
Signed-off-by: Connor Worley <connorbworley@gmail.com>
The runtime doesn't set the frame type to MFX_FRAMETYPE_IDR on the
returned mfx bitstream for a keyframe, it set the frame type to
MFX_FRAMETYPE_I only. This patch added workaround for VP9 keyframe to
make the coded stream seekable.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
The VC1_D2010 profile, also known as VC1_VLD2010, has the same functionality
and specification as the VC1_D profile. Support for this profile serves only
as a positive indication that the accelerator has been designed with awareness
of the modifications specified in the August 2010 version of this specification.
Hardware accelerator drivers that expose support for this profile must not
also expose the previously specified VC1_D GUID, unless the accelerator works
properly with existing software decoders that use VC1_D and that do not incorporate
the corrections added to the August 2010 version of this specification.
As a result, we could give VC1_VLD2010 a higher priority and initialize
it first.
Signed-off-by: Aleksoid <Aleksoid1978@mail.ru>
Signed-off-by: Tong Wu <tong1.wu@intel.com>
Ensure all hwaccels that allocate a buffer use NVDECContext->bitstream_internal
instead. Otherwise, if FFHWAccel->end_frame() isn't called before
FFHWAccel->uninit(), an attempt to free a stale pointer to memory not owned by
the hwaccel could take place.
Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>
Signed-off-by: James Almer <jamrial@gmail.com>
info level will be too noisy if several instances of the decoder are fired
at the same time, as will be the case with tiled AVIF.
Signed-off-by: James Almer <jamrial@gmail.com>
info level will be too noisy if several instances of the decoder are fired
at the same time, as will be the case with tiled AVIF.
Signed-off-by: James Almer <jamrial@gmail.com>
If the number of CTUs reduces between one picture and the next, the
slice_idx table is reduced in size in the frame_context_for_each_tl call
on vvcdec.c:321. When initialising the slice_idx table on vvcdec.c:325,
the old code uses fc->tab.sz.ctu_count when calculating the table size.
fc->tab.sz.ctu_count holds the old ctu count at this point however, not
being updated to hold the new ctu count until vvcdec.c:342. This causes
an out-of-bounds write.
Patch fixes the problem by using pps->ctb_count, which was just used
when allocating the table, in place of fc->tab.sz.ctu_count when
initialising the table.
Signed-off-by: Frank Plowman <post@frankplowman.com>
libjxl doesn't support negative strides, but JPEG XL has an orientation
flag inside the codestream. We can use this to work around the library
limitation, by taking the absolute value of the negative row stride,
sending the image up-side-down, and telling the library that the image
has a vertical-flip orientation.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Distinguish between a decoder being entirely missing and a decoder which
requires features which are not present in the incomplete implementation
in libavcodec and therefore can't be used.
The current criterion is to check for the existence of
update_thread_context. Change this to check for whether
we are actually decoding VP8 (and not VP7 or VP8-in-WebP).
This is equivalent to the current criterion, but allows
the WebP decoder to evolve and to get its own update_thread_context.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
VP8-in-WebP only uses key frame encoding (see [1]), yet this
is currently not enforced. This commit does so in order to
make output reproducible with frame-threading as the VP8 decoder's
update_thread_context is not called at all when using decoding
VP8-in-WebP (as this is unnecessary for key frame-only streams).
[1]: https://developers.google.com/speed/webp/docs/riff_container
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
"When aps_params_type is equal to ALF_APS or SCALING_APS, the value of aps_adaptation_parameter_set_id shall be
in the range of 0 to 7, inclusive.
When aps_params_type is equal to LMCS_APS, the value of aps_adaptation_parameter_set_id shall be in the range of 0
to 3, inclusive."
Fixes: out of array accesses
Fixes: 65932/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-4563412340244480
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Check that vps_each_layer_is_an_ols_flag, which indicates that "at
least one OLS specified by the VPS contains more than one layer," is
set if num_multi_layer_olss is non-zero.
Fixes: 65160/clusterfuzz-testcase-minimized-ffmpeg_BSF_VVC_METADATA_fuzzer-4665241535119360
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The old code did not follow the syntax from the spec.
Reviewed-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
It presumably exists because HapContext contains an AVClass*.
Yet AVClass is actually defined in log.h and even this inclusion
can be avoided by struct AVClass*. This avoids opt.h inclusions
in hap.c and hapdec.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_texturedspenc_init() doesn't support most of the function types
supported for decoding; add a separate context containing only pointers
for the actually supported types.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The old code set a common struct from each thread;
this only "worked" (but is still UB) because the values
written are the same for each thread.
Fix this by moving the assignments to the main thread.
(This also avoids casting const away from a const AVFrame*.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
nal->skipped_bytes_pos contains the positions of errors relative to the
start of the slice header, whereas the position they were tested against
is relative to the start of the slice data, i.e. one byte after the end
of the slice header.
Patch fixes this by storing the size of the slice header in H266RawSlice
and adding it to the position given by the GetBitContext before
comparing to skipped_bytes_pos. This fixes AVERROR_INVALIDDATAs for
various valid bitstreams, such as the LMCS_B_Dolby_2 conformance
bitstream.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Resolves the following undefined behavior sanitiser error:
runtime error: shift exponent 32 is too large for 32-bit type 'int'
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes#10759.
It can happen in H.264, MPEG2, VC1 that the current frame resource
memory is already in ref_resource. For example, for a interlaced frame,
the same curr memory is passed twice. For the second time it could possibly
reference itself. When this happens the curr is already given an index and
in ref_resources. When the reference frame index is required, we should check
the existance in the ref_resources first before assigning a new index for it.
Signed-off-by: Tong Wu <tong1.wu@intel.com>
This file has been exported since our minimum required version (0.7.0),
but it wasn't documented. Instead it was transitively included by
<jxl/decode.h> (but not jxl/encode.h), which ffmpeg relied on.
libjxl broke its API in libjxl/libjxl@66b9592393 by removing
the transitive include of version.h, and they do not plan on adding
it back. Instead they are choosing to leave the API backwards-
incompatible with downstream callers written for some fairly recent
versions of their API.
As a result, we include <jxl/version.h> to continue to build against
more recent versions of libjxl. The version macros removed are also
present in that file, so we no longer need to redefine them.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Should fix "member access within misaligned address 0xf00 for type 'const union
av_alias64', which requires 8 byte alignment" errors as reported by GCC ubsan.
Signed-off-by: James Almer <jamrial@gmail.com>
Should fix "member access within misaligned address 0xf00 for type 'const union
av_alias64', which requires 8 byte alignment" errors as reported by GCC ubsan.
Signed-off-by: James Almer <jamrial@gmail.com>
Should fix "member access within misaligned address 0xf00 for type 'const union
av_alias64', which requires 8 byte alignment" errors as reported by GCC ubsan.
Signed-off-by: James Almer <jamrial@gmail.com>
VVC specifies << as arithmetic left shift, i.e. x << y is equivalent to
x * pow2(y). C's << on the other hand has UB if x is negative. This
patch removes all UB resulting from this, mostly by replacing x << y
with x * (1 << y), but there are also a couple places where the OOP was
changed instead.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Finishes fixing vp5/potter512-400-partial.avi
The fate-matroska-ms-mode test ref is updated to reflect that the Speex decoder
can now read the stream.
Signed-off-by: James Almer <jamrial@gmail.com>
There could be bogus bytes at the start, as is the case of
vp5/potter512-400-partial.avi from the FATE suite, which could be a case of bad
remuxing from an OGG source.
Partially fixes decoding of vp5/potter512-400-partial.avi
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes "runtime error: member access within misaligned address 0xf00 for type
'struct bar', which requires # byte alignment" errors under GCC ubsan.
Reviewed-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
As I understand, support for .STR files is broken for almost 10 years now (since 161442ff2c it seems).
Currently, ffmpeg fails with tons of errors like this on version 1 STRs, e.g. Wipeout 1:
[mdec @ 00000000027c72c0] ac-tex damaged at 1 9
What happens is that only the audio is present in the video file.
Anyway, that one character patch fixes the problem, video is now rendered.
Signed-off-by: aybe <aybe@users.noreply.github.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
tests/checkasm/checkasm:
C LSX LASX
hevc_idct_32x32_8_c: 1243.0 211.7 101.7
Speedup of decoding H265 4K 30FPS 30Mbps on
3A6000 with 8 threads is 1fps(56fps-->57fps).
Reviewed-by: yinshiyou-hf@loongson.cn
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
After this patch, the peformance of decoding H265 4K 30FPS 30Mbps
on 3A6000 with 8 threads improves 2fps (45fps-->47fsp).
Reviewed-by: yinshiyou-hf@loongson.cn
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The layout for the frame flags is as follow:
chroma_format u(2)
reserved u(2)
interlace_mode u(2)
reserved u(2)
chroma_format has 2 allowed values:
0: reserved
1: reserved
2: 4:2:2
3: 4:4:4
interlace_mode has 3 allowed values:
0: progressive
1: tff
2: bff
3: reserved
0x80 is what we expect for "422 not interlaced", and the extra 0x2 from
0x82 is actually writing into the reserved bits.
This byte represents 4 reserved bits followed by 4 alpha_channel_type bits.
alpha_channel_type currently has 3 differents defined values: 0 (no
alpha), 1 (8b alpha), and 2 (16b alpha), all the other values are
reserved. The 4 initial reserved bits are expected to be 0.
This byte represents 4 reserved bits followed by 4 alpha_channel_type bits.
alpha_channel_type currently has 3 differents defined values: 0 (no
alpha), 1 (8b alpha), and 2 (16b alpha), all the other values are
reserved. This part is correctly written (alpha_bits>>3 does the correct
thing), but the 4 initial bits are reserved.
Quoting SMPTE RDD 36:2015:
A decoder shall abort if it encounters a bitstream with an unsupported
bitstream_version value. If 0, the value of the chroma_format syntax
element shall be 2 (4:2:2 sampling) and the value of the
alpha_channel_type element shall be 0 (no encoded alpha); if 1, any
permissible value may be used for those syntax elements.
So if we're not in 4:2:2 or if there is alpha, we are not allowed to use
version 0.
Quoting SMPTE RDD 36:2015:
A decoder shall abort if it encounters a bitstream with an unsupported
bitstream_version value. If 0, the value of the chroma_format syntax
element shall be 2 (4:2:2 sampling) and the value of the
alpha_channel_type element shall be 0 (no encoded alpha); if 1, any
permissible value may be used for those syntax elements.
So if we're not in 4:2:2 or if there is alpha, we are not allowed to use
version 0.
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>
