The APNG encoder already uses internal buffers, 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>
The FLAC encoder calculates the size in advance, so 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>
For all p*m encoders a very sharp upper bound for the size of the
output packets is available before the packet is allocated. This can
be used to avoid an intermediate buffer when encoding by using
ff_get_encode_buffer() instead of ff_alloc_packet2() (without min_size);
this also adds support for user-supplied buffers.
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; 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>
