Up until now, ff_alloc_packet2() has a min_size parameter:
It is supposed to be a lower bound on the final size of the packet
to allocate. If it is not too far from the upper bound (namely,
if it is at least half the upper bound), then ff_alloc_packet2()
already allocates the final, already refcounted packet; if it is
not, then the packet is not refcounted and its data only points to
a buffer owned by the AVCodecContext (in this case, the packet will
be made refcounted in encode_simple_internal() in libavcodec/encode.c).
The goal of this was to avoid data copies and intermediate buffers
if one has a precise lower bound.
Yet those encoders for which precise lower bounds exist have recently
been switched to ff_get_encode_buffer() (which automatically allocates
final buffers), leaving only two encoders to actually set the min_size
to something else than zero (namely aliaspixenc and hapenc). Both of
these encoders use a very low lower bound that is not helpful in any
nontrivial case.
This commit therefore removes the min_size parameter as well as the
codepath in ff_alloc_packet2() for the allocation of final buffers.
Furthermore, the function has been renamed to ff_alloc_packet() and
moved to encode.h alongside ff_get_encode_buffer().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that the AVCodec.next pointer has now been removed, most of the
AVCodecs are not modified at all any more and can therefore be made
const (as this patch does); the only exceptions are the very few codecs
for external libraries that have a init_static_data callback.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Before 257a83b969, certain buffers were
zero-allocated in the init function and only reallocated lateron if they
turned out to be too small; now they are only allocated during init,
leading to use-of-uninitialized values lateron. The same could happen
before if the dimensions are big enough so that the buffers would be
reallocated, as the new part of the reallocated buffer would not be
zeroed (happened for 960x960). So always zero the buffers in the
function designed to init them.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The patch changes the init function to initialize block dimensions to fixed
64x64 instead of the previously used image width/height based value.
This should not cause any actual change in behaviour because block dimensions
are recalculated on every keyframe in optimum_block_width() and
optimum_block_height() functions and in the current code the result is always
64x64 regardless of the image dimensions used.
Signed-off-by: Marton Balint <cus@passwd.hu>
This resolves implementation defined behavior, and also silences -Wabsolute-value in clang 3.5+.
Moreover, the generated asm is identical to before modulo nop padding.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This parameter can be used to inform the allocation code about how much
downsizing might occur, and can be used to optimize how to allocate the
packet
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Several encoders were multiplying the buffer size by 8, in order to get
a bit size. However, the buffer_size argument is for the byte size of
the buffer. We had experienced crashes encoding prores (Anatoliy) at
size 4096x4096.
A flashsv2 block may have a "diff block" to indicate which scan lines of
the block are actually encoded. However, this diff block need not be
used when the entire block is coded.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Andreas Rheinhardt
Andreas Rheinhardt
Marton Balint
Ganesh Ajjanagadde
Michael Niedermayer
Dyami Caliri
Michael Niedermayer
Carl Eugen Hoyos
Clément Bœsch
Daniel Verkamp
Derek Buitenhuis
Paul B Mahol
Clément Bœsch
Joshua Warner