Marton Balint [Sat, 6 Mar 2021 21:26:13 +0000 (22:26 +0100)]
avformat/librist: make packet size adjustable for writing, fix it for reading
Maximum packet size is 10000 (RIST_MAX_PACKET_SIZE, which is unfortunately
private) minus the RIST protocol overhead which is 28 bytes for the unencrypted
case, 36 for the encrypted case.
Marton Balint [Sat, 6 Mar 2021 20:48:57 +0000 (21:48 +0100)]
avformat/librist: rework librist_read
Queue tracking makes no difference so remove it, return EAGAIN of no data is
available and rist data block needs to be freed even for zero sized packets.
Marton Balint [Sat, 6 Feb 2021 18:48:51 +0000 (19:48 +0100)]
avdevice/pulse_audio_dec: do not read undersized frames
Keep on reading fragments until we got fragment_size amount of data, otherwise
we might get frames with 1-2 samples only if pa_stream_peek is called slightly
less frequently than sample rate.
Note that fragments might contain a lot less data than fragment_size, so
reading multiple fragments to get fragment_size amount of data is intentional.
James Almer [Sat, 20 Feb 2021 19:01:52 +0000 (16:01 -0300)]
avcodec: add a get_encode_buffer() callback to AVCodecContext
This callback is functionally the same as get_buffer2() is for decoders, and
implements for the new encode API the functionality of the old encode API had
where the user could provide their own buffers.
Reviewed-by: Lynne <dev@lynne.ee> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Reviewed-by: Mark Thompson <sw@jkqxz.net> Signed-off-by: James Almer <jamrial@gmail.com>
Mark Thompson [Tue, 2 Feb 2021 20:58:11 +0000 (20:58 +0000)]
cbs_sei: Detect payload overflows when reading SEI messages
The top-level GetBitContext is sized for the whole NAL unit, so it fails
to detect overflows where a payload continues into the following message.
To fix that, we make a new context on the stack for reading each payload.
Fixes: 29892/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_REDUNDANT_PPS_fuzzer-6310830956216320 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Mark Thompson [Wed, 3 Feb 2021 21:34:07 +0000 (21:34 +0000)]
cbs_h265: Detect more reference combinations which would overflow the DPB
In total, the number of short term references (from the selected short
term ref pic set), the number of long term references (combining both the
used candidates from the SPS and those defined in the slice header) and
the number of instances of the current picture (usually one, but can be
two if current picture reference is enabled) must never exceed the size
of the DPB. This is a generalisation of the condition associated with
num_long_term_pics in 7.4.7.1.
We use this to apply tighter bounds to the number of long term pictures
referred to in the slice header, and also to detect the invalid case where
the second reference to the current picture would not fit in the DPB (this
case can't be detected earlier because an STRPS with 15 pictures can still
be valid in the same stream when used with a different PPS which does not
require two DPB slots for the current picture).
Fixes: 24913/clusterfuzz-testcase-minimized-ffmpeg_BSF_HEVC_METADATA_fuzzer-6261760693370880 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Tested-by: Michael Niedermayer <michael@niedermayer.cc>
An AVBufferRef (and the corresponding AVBuffer and the underlying actual
buffer) would leak in ff_cbs_sei_add_message() on error in case an error
happened after its creation and before it has been attached to more
permanent storage. Fix this by only creating the AVBufferRef immediately
before attaching it to its intended target position.
(Given that no SEI message currently created is refcounted, the above
can't happen at the moment. But Coverity already nevertheless noticed:
This commit fixes Coverity issue #1473521.)
Reviewed-by: Mark Thompson <sw@jkqxz.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
avcodec/cbs: Remove redundant checks for CodedBitstreamContext.codec
Setting this field happens immediately after the allocation in
ff_cbs_init(), so the whole CBS code may presume that any
CodedBitstreamContext has this set. Lots of code already presumed this,
yet ff_cbs_close() did it inconsistently: It checked before checking
whether the CodedBitstreamType has a close function; yet it simply
unconditionally read ctx->codec->priv_class. Coverity complained about
this in issue #1473564, which this commit fixes.
Reviewed-by: Mark Thompson <sw@jkqxz.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Martin Storsjö [Fri, 12 Mar 2021 20:42:02 +0000 (22:42 +0200)]
avcodec/nvenc: base timestamps on frameIntervalP
If b-frames were enabled implicitly (if max_b_frames wasn't set by
the caller at all, since a0949d0bcb0eee2f3fffcf9a4810c0295d14c0dc),
we wouldn't offset dts at all, producing invalid pts/dts combinations
(causing loud warnings by ffmpeg, or muxer errors if passed without
an extra cleanup pass).
Instead use frameIntervalP for offsetting, which should always be
accurate.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
The uspp filter uses a special option ("no_bitstream") of
the Snow encoder to suppress it from generating output.
The filter therefore did not unref the packet after usage,
believing it to be blank. But this is wrong, as the Snow encoder
attaches quality stats side data to the packet.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
av_get_packet() already makes sure that the packet size is accurate
and that the packet data is zero-padded even when one could not read as
much as desired.
Reviewed-by: James Almer <jamrial@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
parazyd [Sun, 28 Feb 2021 22:47:05 +0000 (23:47 +0100)]
avformat/gopher: Add support for Gopher over TLS
This commit adds a "gophers" handler to the gopher protocol. gophers
is a community-adopted protocol that acts the same way like normal
gopher with the added TLS encapsulation.
The gophers protocol is supported by gopher servers like geomydae(8),
and clients like curl(1), clic(1), and hurl(1).
This commit also adds compilation guards to both gopher and gophers,
since now there are two protocols in the file it makes sense to
have this addition.
avs_is_color_space provides a generic way of checking whether the
video is RGB, and has been available through AVSC_API since 2.6.
This means that GetProcAddress doesn't have to run on every frame.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
dnn/dnn_backend_native: Don't use asserts for checks
asserts should not be used instead of ordinary input checks.
Yet the native DNN backend did it: get_input_native() asserted that
the first dimension was one, despite this value coming directly from
the input file without having been sanitized.
Reviewed-by: Guo, Yejun <yejun.guo@intel.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
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>
Marton Balint [Wed, 3 Mar 2021 22:23:10 +0000 (23:23 +0100)]
fftools/ffplay: do not write out of rdft visualization texture
If the window is resized it was possible that xpos pointed outside the
visualization texture. By rearranging the overflow check we make sure this (and
a crash) does not happen.
We also don't have to use xleft for start position, as that is 0 anyways, and
if we ever want to take into account xleft then the texture should be
positioned accordingly when rendering.
avcodec/decode: Avoid stack packets when decoding subtitles
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>
avcodec/dcadsp: Fix integer overflow in dmix_add_c()
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>
avformat/flvdec: Check double before cast in parse_keyframes_index()
Fixes: -2.21166e+304 is outside the range of representable values of type 'long' Fixes: 29169/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5725452796821504 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avcodec/aacdec_template: Avoid undefined negation in imdct_and_windowing_eld()
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>
Fixes: Timeout (too long -> 241ms) Fixes: 29083/clusterfuzz-testcase-minimized-ffmpeg_dem_SWF_fuzzer-6273684478230528
The source of the magic number is
A very quick simulation of the best case compression for "compress"
below is not nice written code as i did not expect I or anyone else
would ever see it again
I would have preferred some nicer expression or course, but thats
what it seems to be asymptotically. For smaller amounts of data a
tighter bound is possible but i saw no nice way to consider that
and it seems also overkill to try to do it more fine grained for
just this
main(){
int64_t bits = 0;
int bank = 256;
int bitbank = 8;
for(unsigned i = 0; i<1024*1024*1024*4U-100000;) {
int word_size = bank-255;
i += word_size;
bits += bitbank;
if (!(bank & (bank-1)))
bitbank ++;
bank++;
if (bitbank > 16) {
printf("BEST %f \n", 8.0 * i / bits );
bank = 256;
bitbank = 8;
}
}
}
above assumes i remembered correctly how the algorithm works but the
value was close to what actual compession of zeros gave
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Florian Nouwt [Mon, 8 Mar 2021 10:54:04 +0000 (11:54 +0100)]
mobiclip: fix copyright headers
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.
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>
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>
avcodec/jpeglsenc: Only use one line at a time as spare buffer
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>
avcodec/jpeglsenc: Don't modify frame we don't own
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>