When the packet size is known in advance like here, one can avoid
an intermediate buffer for the packet data; also, there is no reason
to add AV_INPUT_BUFFER_MIN_SIZE to the packet size any more, as the
actually needed packet size can be easily calculated: It is three bytes
more than the raw nal size per NALU.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Here the packet size is known before allocating the packet,
so that supporting user-supplied buffers is trivial.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Here the packet size is known before allocating the packet because
the encoder provides said information (and works with internal buffers
itself), so one can use this information to avoid the implicit use of
another intermediate buffer for the packet data; and by switching to
ff_get_encode_buffer() one can also allow user-supplied buffers.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Here the packet size is known before allocating the packet,
so that supporting user-supplied buffers is trivial.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Here the packet size is known before allocating the packet,
so that supporting user-supplied buffers is trivial.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: James Zern <jzern@google.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Here the packet size is known before allocating the packet because
the encoder provides said information (and works with internal buffers
itself), so one can use this information to avoid the implicit use of
another intermediate buffer for the packet data; and by switching to
ff_get_encode_buffer() one can also allow user-supplied buffers.
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: James Zern <jzern@google.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Here the packet size is known before allocating the packet because
the encoder provides said information (and works with internal buffers
itself), so one can use this information to avoid the implicit use of
another intermediate buffer for the packet data; and by switching to
ff_get_encode_buffer() one can also allow user-supplied buffers.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Here the packet size is known before allocating the packet because
the encoder provides said information (and works with internal buffers
itself), so one can use this information to avoid the implicit use of
another intermediate buffer for the packet data; and by switching to
ff_get_encode_buffer() one can also allow user-supplied buffers.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The libshine encoder already uses an internal buffer, so that the
packet size is already known before allocating the packet; therefore
one can avoid another (implicit) intermediate buffer by switching
to ff_get_encode_buffer(), thereby also supporting user-supplied
buffers.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Here the packet size is known before allocating the packet,
so that supporting user-supplied buffers is trivial.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The libmp3lame encoder already uses an internal buffer, so that the
packet size is already known before allocating the packet; therefore
one can avoid another (implicit) intermediate buffer by switching
to ff_get_encode_buffer(), thereby also supporting user-supplied
buffers.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Here the packet size is known before allocating the packet,
so that supporting user-supplied buffers is trivial.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the packet size is known in advance like here, one can avoid
an intermediate buffer for the packet data by using
ff_get_encode_buffer() and also set AV_CODEC_CAP_DR1 at the same time.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the packet size is known in advance like here, one can avoid
an intermediate buffer for the packet data by using
ff_get_encode_buffer() and also set AV_CODEC_CAP_DR1 at the same time.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Here the packet size is known before allocating the packet because
the encoder provides said information (and works with internal buffers
itself), so one can use this information to avoid the implicit use of
another intermediate buffer for the packet data; and by switching to
ff_get_encode_buffer() one can also allow user-supplied buffers.
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: James Zern <jzern@google.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It has been added in 2016 when this flag made no sense for encoders at
all; now that it makes sense, audiotoolboxenc doesn't support it,
despite claiming to do so.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is marginally slower, but correct for all input values.
The previous implementation failed with certain input seeds, e.g.
"checkasm --test=hevc_idct 98".
Signed-off-by: Martin Storsjö <martin@martin.st>
This used to be the default, but was reverted as it was slower than
the 'fast' coder by around 25%.
Since our encoder is still not very good, change back to the twoloop
coder by default. It has much better rate control management as well,
making it closer to CBR, and it sounds much better.
Previously, only the size of a given tile was passed, making the
offset and size marked in VASliceParameterBufferAV1 invalid with
multiple tiles.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Trivial for an encoder that has a good estimate of the size of
the output packet in advance.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Trivial for an encoder that has a very good estimate of the size
of the output packet in advance.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Now that the proper buffer size is calculated (and checked) before
allocating the buffer, it is known that the buffer always suffices.
So use the unchecked PutBit-API; and also use an unchecked bitstream
reader as we check ourselves.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the JPEG-LS encoder allocated a worst-case-sized packet
at the beginning of each encode2 call; then it wrote the packet header
into its destination buffer and encoded the actual packet data;
said data is written into another worst-case-sized buffer, because it
needs to be escaped before being written into the packet buffer.
Finally, because the packet buffer is worst-case-sized, the generic
code copies the actually used part into a fresh buffer.
This commit changes this: Allocating the packet and writing the header
into it is deferred until the actual data has been encoded and its size
is known. This gives a good upper bound for the needed size of the packet
buffer (the upper bound might be 1/15 too large) and so one can avoid the
implicit intermediate buffer and support user-supplied buffers by using
ff_get_encode_buffer().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Exists since 8a129077cc.
Fixes a -Winitializer-overrides warning when building with Clang.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since a247ac640d, allcodecs.c contained
two lines that matched the regex used by find_filters_extern in
configure; as a result, libx264 appeared twice the list of codecs
(if enabled).
Fix this by using only one matching line by adding a preprocessor define
for the part that differed in the two old lines: The const qualifier.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Even though all samples are meant to be zero (if flag == 0x07),
doesn't mean that they aren't there. See No$PSX docs [1].
[1]: https://problemkaputt.de/psx-spx.htm#spuadpcmsamples
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
The JPEG-2000 decoder and encoder share common luts; the decoder
initializes them once, guarded by a dedicated AVOnce, whereas
the encoder initializes them always during init. This means that
the decoder is not init-threadsafe; in fact there is a potential
data race because these luts can be initialized while an active
decoder/encoder is using them.
Fix this and make the decoder init-threadsafe by making the
initialization function guard initialization itself with a dedicated
AVOnce.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
mqc currently initializes three arrays at runtime; each of them
has 2 * 47 elements, one is uint16_t, two are uint8_t, so that their
combined size is 8 * 47. The source data for these initializations
is contained in an array of 47 elements of size six. Said array is
only used in order to initialize the other arrays, so the savings
are just 2 * 47B. Yet this is dwarfed by the size of the code for
performing the initializations: It is 109B (GCC 10.2, x64, -O3 albeit
in an av_cold function); this does not even include the size of the
code in the callers. So just hardcode these tables.
This also fixes a data race, because the encoder always initialized
these tables during init, although they might already be used at the
same time by already running encoder/decoder instances.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The Vorbis encoder has an array of a structure containing all
the ingredients for a codebook; this includes a pointer to
the actual codebook and some even have a pointer to an array
containing quant values. Each of these real codebooks is
an array of its own.
These pointers lead to relocations and therefore the array will
be placed in .data.rel.ro and not in .rodata.
This commit avoids the pointers altogether by combining all the actual
codebooks into one big array; the actual codebooks are now accessed
consecutively by incrementing the pointer used to access them by the
length of the actual codebook that has just been dealt with (said length
is contained in the structure describing the codebook). There is
no downside to this given that these codebooks are already only used
once during init.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The Vorbis encoder allocates several arrays destined to contain pointers
to separately allocated arrays; yet these arrays are allocated without
initializing them: They are uninitialized until their final values
are stored in them; so if allocating one of the earlier subarrays fails,
all of the remaining pointers to subarrays are still uninitialized.
But they are used for freeing, resulting in crashes.
Fix this by zero-initializing the arrays with subarrays.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
