We have already calculated the size of the packet
and therefore don't need to rely on these implicit checks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This can be easily done because we have a count of the number of
values and the length of the associated codes. This allows
to switch to ff_get_encode_buffer() and thereby avoids an implicit
intermediate buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that we can calculate the size of each slice in advance,
we can determine the position in the output packet where it
needs to be put and can therefore avoid the intermediate buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The earlier code only used the counts from the last slice.
The two FATE tests using slices show compression improvements
due to this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Every frame contains an array of uint8_t with values
0..(s->planes * s->nb_slices - 1), so this needs to fit
into an uint8_t.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do not derive it via av_cpu_count() in case AVCodecContext.slices
is unset. Instead default to AVCodecContext.thread_num instead
(which is one in case frame-threading is used and gives the actual
number of slice threads for slice threading).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The previous code expected a segment of type CLUT definition to exist
in order to accept a set of segments to be complete.
This was an incorrect assumption as the presence of a CLUT segment
is not mandatory.
(version 1.6.1 of the spec is probably a bit more clear about this
than earlier versions: https://www.etsi.org/deliver/etsi_en/
300700_300799/300743/01.06.01_20/en_300743v010601a.pdf)
The incorrect condition prevented proper fallback to using the default
resolution for the decoding context.
This also adds variables and moves the fallback check to the outside
for better clarity.
Signed-off-by: softworkz <softworkz@hotmail.com>
In filtering, and SDR encoding, we use storage images.
This fixes using Vulkan filters on Intel.
Tested not to break anything on the three major vendors.
It is unnecessary, as we already have the entries sorted by
probability and therefore implicitly by length. All we need
on top of that to build the tree is the number of entries
of a given length.
Doing so gives a 3.6% speedup of ff_mjpeg_encode_huffman_close()
here; it also saves about 640B of .text here.
The new code puts values with higher probability to the left
of the tree. The old code did not and therefore
the FATE checksums needed to be updated. Due to MJPEG's
0xFF unescaping file sizes as well as file checksums
needed to be updated; the decoded picture hashes stayed
the same. Given that codes on the left of the tree have
on average fewer bits set than codes on the right, the
file sizes mostly improve (all except vsynth3-mjpeg-444).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We currently populate the color encoding bundle and then check to see
if there's an ICC profile to attach, and set the color encoding bundle
in either case. The ICC profile overrides the color encoding bundle, so
we should not calculate enum-based color encoding if we have an ICC
profile present. Fixes several unnecessary warnings from being emitted.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
All users (namely HEVC) that use ff_progress_frame_alloc()
should just use ff_thread_get_buffer(). Using
ff_progress_frame_get_buffer() is not a must; it is merely
a convenience wrapper.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit adds support for compiler hints.
While on AMD these are not used/needed, Nvidia benefits from them, and gives
a sizeable 10% speedup on 4k.
This commit also makes it possible for the encoder to choose a different
quantization table on a per-slice basis, as well as adding this capability
to the decoder.
Also, this commit fully fixes decoding of context=1 encoded files.
This reduces the intermediate VRAM used for RGB decoding by a
factor of 100x for 6k video.
This also speeds the decoder up by 16% for 4k RGB24 and 31% for 6k video.
This is equivalent to what the software decoder does, but with less pointers.
We know the final size before encoding, so we can switch to
ff_get_encode_buffer() which avoids an implicit memcpy().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Most of the encoders is the same. So deduplicate them.
This reduces code size from 22410B to 12637B here.
The data in mpegaudiotab.h is also automatically deduplicated.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The sample rates here have already been checked generically
via CODEC_SAMPLERATES().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
