Carries a raw HEVCDecoderConfigurationRecord for the Dolby Vision
enhancement layer, parsed from the hvcE box (ISOM) or the corresponding
BlockAdditionMapping (Matroska).
Fixes: out of array read
Fixes: evil.rm
Found-by: Anthropic agents; validated and reported by Ada Logics.
Signed-off-by: David Korczynski <david@adalogics.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
av_vorbis_parse_init() doesn't return an error code which is a slight
problem in libvorbisenc.c. Fix this by making the internal
initialization function behind av_vorbis_parse_init() available. This
also avoids allocations and frees.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: out of array access
Fixes: evil.apv
Found-by: Claude (Anthropic). Human-verified and reported by Omkhar Arasaratnam <omkhar@linkedin.com>. on 05-20
Found-by: Anthropic agents; validated and reported by Ada Logics. on 05-26
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This was a mess, we were using incorrect pixels outside of the image boundaries as
valid, the iteration had undefined behaviour since it was non-uniform across the workgroup.
Calculate the per-invoc iterations from the slice dimensions instead, making all of
them identical. And add a valid flag to decide whether to use them or not. And fix the
synchronization.
Sponsored-by: Sovereign Tech Fund
The issue is that SliceContext was passed as an inout, which caused all
invocs to locally copy and modify it.
When the main invoc wrote it, only the very last written value was used,
choosing the wrong coeffs.
Sponsored-by: Sovereign Tech Fund
There was a race condition where the main invocation would race ahead and use
values not yet written by other invocs.
Sponsored-by: Sovereign Tech Fund
GPUs filter out denormals when reading floats via imageLoad. Denormals shouldn't
be present in general, but if they are, this is a lossless codec, and we have to
preserve them. This allows reading the exact values.
Sponsored-by: Sovereign Tech Fund
Float pixfmts are meant to be normalized between [0, 1], but in case they
were not, and negative numbers were present, then the top bits would be
filled with garbage.
Sponsored-by: Sovereign Tech Fund
This was an oversight while microoptimizing. The outstanding_byte can
reach 0xFF in some situations, which was causing errors when encoding,
particularly with 32-bit floats.
Sponsored-by: Sovereign Tech Fund
decode_zbuf() inflates zTXt (compressed text) and iCCP (ICC profile) chunk
payloads into an AVBPrint created with AV_BPRINT_SIZE_UNLIMITED and never
checks the decompressed size. A ~100 KB zTXt chunk of compressed zeros
expands to 100 MB; larger ratios or multiple chunks can exhaust memory.
Abort with AVERROR_INVALIDDATA once the decompressed output crosses a hard
cap (16 MiB).
Verified with a crafted PNG (1 KB compressed -> 100 MB decompressed): without
the patch the chunk fully decompresses, taking >100 MB; with the patch the
inflate loop aborts and the decoder logs "Compressed PNG chunk expands
beyond 16777216 bytes" / "Broken zTXt chunk" while the rest of the image
decodes normally.
Reported by Franciszek Kalinowski (isec.pl / striga.ai) and Bartosz Smigielski.
In the >= 9 bit path, color_frame() does
`av_memcpy_backptr(dst + 2, 2, bytes - 2)`. When the effective chroma width
is 1 pixel (bytes == 1) the count becomes -1 and the underlying fill16()
loop runs roughly 2^32 times, producing a heap overflow. The original count
was also wrong in units (pixels rather than bytes); fix that at the same
time so the 2-pixel case still fills both pixels.
Confirmed via a standalone harness reproducing av_memcpy_backptr's fill16
loop with cnt = -1; reaching the call from a crafted H.264 bitstream
requires Hi10P plus a frame_num gap on a frame whose effective chroma width
is 1 pixel, which is hard to express but is reachable via mid-stream SPS
changes. Compiles cleanly; no regressions seen running existing crafted
H.264 PoCs and trivial transcodes.
Reported by Franciszek Kalinowski (isec.pl / striga.ai) and Bartosz Smigielski.
Deprecate MMX with less instruction count. Remove the SSSE3 impl. as we
no longer use palignr.
pred8x8l_top_dc_8_mmxext: 8.7 ( 2.29x)
pred8x8l_top_dc_8_ssse3: 7.9 ( 2.51x)
pred8x8l_top_dc_8_sse2: 6.7 ( 3.01x)
Signed-off-by: Zuxy Meng <zuxy.meng@gmail.com>
The CELT psychoacoustic path was effectively broken: analysis could use
the wrong queued audio and stale scratch samples, and raw band scores were
folded into the frame bit budget, where they could overflow instead of
only driving alloc_boost.
On top of that, c3aea7628c changed avctx->frame_size from fixed
120-sample steps to a configuration-derived value, while the CELT input
and psy paths still treated queue entries as 120-sample steps. That could
misalign psy analysis, read before a short overlap frame, stall silent
flushes, poison rate control with zero-bit silent frames, and overrun the
range coder on EOF or short tails.
This commit fixes these cases by using avctx->frame_size for psy step
accounting, aligning bufqueue analysis with actual audio, padding short
overlaps, and avoiding invalid bit-budget updates for silent or EOF
packets. This lets CELT produce valid packets again.
Before this change, the decoder was forcing downmixing everything to a max of
six channels.
Layouts 6.1(back), 7.1(wide), 7.1 and 5.1.2 (Channel Configurations 11, 7, 12,
and 14 respectively, as well as the equivalent PCE version) should be supported
now.
Signed-off-by: James Almer <jamrial@gmail.com>
libcelt, which it depends on, was not updated in a very long time and is
considered deprecated, as Opus exists which has a CELT mode. Therefore
remove standalone CELT decoding support.
It was already broken since b8604a9761,
11 years ago, and no one noticed and complained.
And stop writing 7.1 as 7.1(wide) (channel conf 7). Lets not create any more
non-spec compliant files that the native decoder needs to work around with now
that we can use PCE configuration for it, getting rid of the ambiguity.
Signed-off-by: James Almer <jamrial@gmail.com>
Many of the entries were downright wrong, like mistagging LFE elements as
SCE, as well as trying to match the native channel ordering in the PCE
by placing CPE elements before SCE ones in some cases (like with FRONT
elements), which is not spec compliant and results in unparseable streams.
Remove the three layouts that define top channels. It's not clear how they
should be signaled in PCE.
Signed-off-by: James Almer <jamrial@gmail.com>
The NVENC driver currently forces deltaQ_v_ac equal to deltaQ_u_ac for
AV1, so crQPIndexOffset is silently ignored. The SDK header annotates
the field as "for future use only" (nvEncodeAPI.h, NV_ENC_RC_PARAMS).
Reported in #22737
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
frames_ctx->width/height were unconditionally rounded to even, causing
odd-dimension monochrome/444 clips to be reported with incorrect
surface pool dimensions. Round only for 4:2:0 and 4:2:2; for
monochrome/444 use avctx->coded_width/coded_height unchanged,
matching the dimensions set by the software codec layer.
Patch by: Aniket Dhok <adhok@nvidia.com>
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
