Beginning with version 3.0, libiLBC switched the types of some parts
of their public API to size_t and renamed some types; the old names
continue to work as typedefs, but are deprecated. It furthermore
added version macros.
This commit uses said version macro to use the new types when using
newer libiLBC versions.
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
av_packet_add_side_data() already defines size as a size_t, so this makes it
consistent across all side data functions
Signed-off-by: James Almer <jamrial@gmail.com>
AVCodecInternal.last_pkt_props is not used when decoding subtitles;
ergo it makes no sense to set it at all.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Use AVCodecInternal.buffer_pkt (previously only used in
avcodec_send_packet) instead of stack packets when decoding subtitles.
Also stop sharing side-data between packets and use the user-supplied
packet directly for decoding when possible (no subtitle decoder ever
modifies the packet it is given).
Reusing AVCodecInternal.buffer_pkt is based upon an idea from James
Almer.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Forgotten after d78ecf10bd.
(Also mark some AVPackets as const.)
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 1515225320 + 759416059 cannot be represented in type 'int'
Fixes: 29256/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DCA_fuzzer-5719088561258496
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: negation of -2147483648 cannot be represented in type 'INTFLOAT' (aka 'int'); cast to an unsigned type to negate this value to itself
Fixes: 29057/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5642758933053440
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The Mobiclip related code was based on Mobius (https://github.com/adibsurani/Mobius),
which was based on my original reverse engineering efforts (https://github.com/Gericom/MobiclipDecoder).
This commit adds the appropriate copyright headers on the related files.
Signed-off-by: Florian Nouwt <fnouwt2@gmail.com>
The effective lifetime of the buffer used to build the VLCs and
the buffer containing the bitstream is disjoint, so that one can use
a common buffer for both.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The H.261 decoder doesn't use the ParseContext of its
MpegEncContext since e731697665.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.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>
Despite avcodec_register and avcodec_register_all being deprecated,
their documentation still said that one of them has to be called
before doing anything else. Clarify this confusing situation.
Furthermore, don't use avcodec_register_all in sample code for
a non-deprecated function.
Reviewed-by: mypopy@gmail.com <mypopy@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This field hasn't been used to return the output frame size since
avcodec_decode_audio4() was introduced.
Signed-off-by: James Almer <jamrial@gmail.com>
The packet passed as argument to this function hasn't contained
a user-provided buffer since 93016f5d1d.
Signed-off-by: James Almer <jamrial@gmail.com>
Originally deprecated in 748c2fca7e,
publically deprecated in 9a07c1332c
(merged into FFmpeg in 1885ffb03d).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Enables the usage of such values as AV_EF_EXPLODE in encoders, which
can be useful in cases such as subtitle encoders where they have the
responsibility to validate the correctness of an incoming ASS dialog line.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
Avoids closing iconv when the size check fails.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Allows to remove one level of indentation.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 1 + 2147483647 cannot be represented in type 'int'
Fixes: 30877/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-4775601145774080
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
