Similar to CVE-2013-0868, here return value check for 'init_vlc' is needed.
crafted DNxHD data can cause unspecified impact.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 7150f95756)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
All callers only use the index into ff_dnxhd_cid_table to get a pointer
to the desired entry.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The current design, where
- proper init is called for the first per-thread context
- first thread's private data is copied into private data for all the
other threads
- a "fixup" function is called for all the other threads to e.g.
allocate dynamically allocated data
is very fragile and hard to follow, so it is abandoned. Instead, the
same init function is used to init each per-thread context. Where
necessary, AVCodecInternal.is_copy can be used to differentiate between
the first thread and the other ones (e.g. for decoding the extradata
just once).
as well as includes of libavutil/timer.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 1024 + 2147483640 cannot be represented in type 'int'
Fixes: 4671/clusterfuzz-testcase-minimized-6027464343027712
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The existing logic overrides container metadata even in cases where the
container metadata must be trusted (e.g. HDR). The original spec had no
provision for specifying color volume, so many files rely on the
assumption of Rec. 709.
An update to the spec included a 'clv' field for explicitly signaling
that the container should be trusted in an existing bitfield in the
frame header, but the default of 0 from old encoders forces Rec. 709,
which would break any HDR stream. Because there is no place in DNxHR for
specifying a transfer function, DNxHR HDR files must include
container-level color information.
This patch maintains the existing behavior of choosing the 709 over the
601 matrix when container-level information is missing, and allows
container-level information to win if present.
Signed-off-by: Steven Robertson <steven@strobe.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Otherwise all thread's private contexts have the avctx pointer set to
the AVCodecContext of the first thread, which means all writes to
ctx->avctx->* (in e.g. read_header) are effectively race conditions.
Fixes fate-dnxhd under tsan.
10- and 12-bit DNxHR use the same DC coefficient decoding process and
VLC table, just with a different shift value. From SMPTE 2019-1:2016,
8.2.4 DC Coefficient Decoding:
"For 8-bit video sampling, the maximum value of η=11 and for
10-/12-bit video sampling, the maximum value of η=13."
A sample file will be uploaded to show that with this patch, things
decode correctly:
dnxhr_hqx_12bit_1080p_smpte_colorbars_davinci_resolve.mov
Signed-off-by: Steven Robertson <steven@strobe.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It's a small and simple function that can be inlined.
This removes one private symbol and should reduce object dependencies with the next
major bump
Signed-off-by: James Almer <jamrial@gmail.com>
The DC VLC table used is too small, fixing this requires a sample,
thus request a sample.
Some samples are said to work even though the table has the wrong size, thus
this is left enabled if the user enables experimental features.
Fixes: 2abd25478c62a675f335fac00b467023/asan_static-oob_10aff98_1227_8811480c6ef1e970a7977ceb7e5a9958.mxf
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Approved-by: kurosu
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This allows more efficient access to the array as the level and flags
are contiguous. Around 4% faster coefficient decoding.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Profiles 1256 & 1270 (currently) signal at the frame header and MB
levels the colorspace used, either RGB or YUV. While a MB-level
varying colorspace is not supported, whether it is constant can be
tracked so as to determine the exact colorspace.
This requires having bitdepth and the ACT and 4:4:4 flags, in turn
needing the CID. Because setting those before having validated
enough things may result in invalid/unset DSP fucntions, setting
the bitdepth in the context is delayed.
It is not tested against a true RGB sequence, though.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These are DNxHR profiles with the following properties:
- Variable size in a profile (property added in a previous commit),
requiring variable-sized macroblock table;
- Variable bitdepth, up to 12 bits.
- Better validation of buffer sizes and positions
Signed-off-by: Christophe Gisquet <christophe.gisquet@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This a 4:4:4 10 bits profile, where image size is not fixed by the
profile, and which strays a bit outside the old frame header parsing
code.
Fixes ticket #4581 (DNxHR is not stricly supported, but that sequence is).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently not used, but will be used to indicate that a CIDEntry field
is not set, because it is variable, and that checks should be adapted.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The current one, while correct, does not yield the best possible
results. The specificiations suggest another formula, which results
in quality gains in the decoded output from fate tests. This
justifies changing said formula.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This bit is 1 in some samples, and seems to coincide with interlaced
mbs and CID1260. 2008 specs do not know about it, and maintain qscale
is 11 bits. This looks oversized, but may help larger bitdepths.
Currently, it leads to an obviously incorrect qscale value, meaning
its syntax is shifted by 1. However, reading 11 bits also leads to
obviously incorrect decoding: qscale seems to be 10 bits.
However, as most profiles still have 11bits qscale, the feature is
restricted to the CID1260 profile (this flag is dependent on
a higher-level flag located in the header).
The encoder writes 12 bits of syntax, last and first bits always 0,
which is now somewhat inconsistent with the decoder, but ends up with
the same effect (progressive + reserved bit).
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Each line is padded by the format, and errors are now reported and
stop the decoding. Around 5% speedup.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Around 3x speedup with 4 threads. Maybe more mb lines should be
batched per thread, but that's good enough for a first try.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Indicates a YCbCr->RGB transform at the block level. Although nothing
explicitly states it, this would assume the actual content is planar
RGB.
Currently unsupported, but the one sequence I found using it flagged
every mb that way, actually meaning the content was YCbCr, and thus
best left to the output format to decide what to do of it.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It currently only applies to CID 1260, but this flag is dependent on
a higher-level flag located in the header.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
