It reduces typing: Before this patch, there were 105 codecs
whose long_name-definition exceeded the 80 char line length
limit. Now there are only nine of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
and remove FF_CODEC_CAP_INIT_THREADSAFE
All our native codecs are already init-threadsafe
(only wrappers for external libraries and hwaccels
are typically not marked as init-threadsafe yet),
so it is only natural for this to also be the default state.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible, because every given FFCodec has to implement
exactly one of these. Doing so decreases sizeof(FFCodec) and
therefore decreases the size of the binary.
Notice that in case of position-independent code the decrease
is in .data.rel.ro, so that this translates to decreased
memory consumption.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is a more fitting place for them.
Also move the definition of ff_log2_run to mathtables.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, codec.h contains both public and private parts
of AVCodec. This exposes the internals of AVCodec to users
and leads them into the temptation of actually using them
and forces us to forward-declare structures and types that
users can't use at all.
This commit changes this by adding a new structure FFCodec to
codec_internal.h that extends AVCodec, i.e. contains the public
AVCodec as first member; the private fields of AVCodec are moved
to this structure, leaving codec.h clean.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also move FF_CODEC_TAGS_END as well as struct AVCodecDefault.
This reduces the amount of files that have to include internal.h
(which comes with quite a lot of indirect inclusions), as e.g.
most encoders don't need it. It is furthemore in preparation
for moving the private part of AVCodec out of the public codec.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Most users only want to either read or write golomb codes, not both.
By splitting these headers one avoids having unnecesssary
(get|put)_hits.h inclusions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is now set generically for all those encoders whose corresponding
AVCodecDescriptor has the AV_CODEC_PROP_INTRA_ONLY.
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>
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>
Deprecated in 40cf1bbacc.
(The currently disabled filter vf_mcdeint and vf_uspp were users of
this field; they have not been changed, so that whoever wants to fix
them can see the state of these filters when they were disabled.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Several options that were too codec-specific were deprecated between
0e6c853221 and
0e9c4fe254.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This encoder has AVCodec.pix_fmts set, so ff_encode_preinit() already
checks for this.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Having only one allocation that is not automatically freed in particular
means that one does not need to free the already allocated buffers
when allocating another one fails.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This state is currently allocated and freed for every packet; but it can
just be moved to the stack instead.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ls_encode_line() encodes one line of input from left to right and
to do so it uses the values of the left, upper left, upper and upper
right pixels for prediction (i.e. the values that a decoder gets when it
decodes the already encoded part of the picture). So a simple algorithm
would use a buffer that can hold two lines, namely the current line as
well as the last line and swap the pointers to the two lines after
decoding each line. Yet if one is currently encoding the pixel with
index k of a line, one doesn't need any pixel with index < k - 1 of the
last line at all and similarly, no pixels with index >= k have been
written yet. So the overlap in the effective lifetime is pretty limited
and since the last patch (which stopped reading the upper left pixel and
instead reused the value of the upper pixel from the last iteration of
the loop) it is inexistent. Ergo one only needs one line and doesn't
need to swap the lines out.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
ls_encode_line() encodes a line of input, going from left to right. In
order to calculate a predicted value it uses the left and upper-left
value of the output picture (that is, it uses how a decoder would see
the already encoded part of the picture), unless this is the very first
pixel of this line in which case one uses the first pixel of the last
(upper) line and the line before the last line. Therefore the loop
contained a check for whether this is the beginning of a new line. This
commit moves said check out of the loop by initializing these values
before the loop and by updating these values at the end of the loop
body; already read/calculated values are reused for this (the prediction
also needs the value of the upper pixel and this can be reused for the
upper left value of the next iteration of the loop).
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The jpegls encoder uses three buffers (as well as its state) to perform
its function: A copy of the last encoded line as a decoder would decode it,
the part of the current line that has been encoded (again, as a decoder
would decode it) and the part of the current line that is not yet encoded.
The encoder solves this by modifying the input frame as it encodes the
output (it also zero-allocates a line to serve as last line for the
first line where no preceding line exists); yet this is wrong as said
frame is not owned by the encoder, so it must not be modified (and it is
given to the encoder as const AVFrame *) without making it writable.
This patch solves this bug by allocating two lines, one for the last and
one for the currently encoded line of output (as a decoder would decode it).
Notice that the frame is only modified if the encoder is in the
non-default non-lossless mode.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This function is so extremely simple that it is preferable to make it
inline rather than deal with all the complications arising from it being
an exported symbol.
Keep avpriv_align_put_bits() around until the next major bump to
preserve ABI compatibility.
If encoding fails, the AVPacket that ought to contain the encoded packet
is already unreferenced generically.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Both are codec properties and not encoder capabilities. The relevant
AVCodecDescriptor.props flags exist for this purpose.
Signed-off-by: James Almer <jamrial@gmail.com>
This options is only used by huffyuv, ffvhuv, jpegls, mjpeg,
mpegvideoenc, png, utvideo.
It is a very codec-specific options, so deprecate the global variant.
Set proper limits to the maximum allowed values, and update utvideoenc
tests to use the new option name.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
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>
The rationale is that coded_frame was only used to communicate key_frame,
pict_type and quality to the caller, as well as a few other random fields,
in a non predictable, let alone consistent way.
There was agreement that there was no use case for coded_frame, as it is
a full-sized AVFrame container used for just 2-3 int-sized properties,
which shouldn't even belong into the AVCodecContext in the first place.
The appropriate AVPacket flag can be used instead of key_frame, while
quality is exported with the new AVPacketSideData quality factor.
There is no replacement for the other fields as they were unreliable,
mishandled or just not used at all.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Allocating coded_frame is what most encoders do anyway, so it makes
sense to always allocate and free it in a single place. Moreover a lot
of encoders freed the frame with av_freep() instead of the correct API
av_frame_free().
This bring uniformity to encoder behaviour and prevents applications
from erroneusly accessing this field when not allocated. Additionally
this helps isolating encoders that export information with coded_frame,
and heavily simplifies its deprecation.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Anton Khirnov
Andreas Rheinhardt
Andreas Rheinhardt
James Almer
Diego Biurrun
Vittorio Giovara
Luca Barbato
Michael Niedermayer
Michael Niedermayer
Carl Eugen Hoyos
Paul B Mahol