Previously ffio_ensure_seekback never flushed the buffer, so successive
ffio_ensure_seekback calls were all respected. This could eventually cause
unlimited memory and CPU usage if a demuxer called ffio_ensure_seekback on all
it's read data.
Most demuxers however only rely on being able to seek back till the position of
the last ffio_ensure_seekback call, therefore we change the semantics of
ffio_ensure_seekback so that a new call can invalidate seek guarantees of the
old. In order to support some level of "nested" ffio_ensure_seekback calls, we
document that the function only invalidates the old window (and potentially
discards the already read data from the IO buffer), if the newly requested
window does not fit into the old one.
This way we limit the memory usage for ffio_ensure_seekback calls requesting
consecutive data windows.
Signed-off-by: Marton Balint <cus@passwd.hu>
It was possible for the old code to seek back before the most recently read
data if start of a new multipart was across read boundaries. Now we read some
small sections multiple times to avoid this, but that is OK.
Signed-off-by: Marton Balint <cus@passwd.hu>
The new buf_size was detemined too conservatively, maybe because of the
off-by-one issue which was fixed recently in fill_buffer. We can safely
substract 1 more from the new buffer size, because max_buffer_size space must
only be guaranteed when we are reading the last byte of the requested window.
Comparing the new buf_size against filled did not make a lot of sense, what
makes sense is that we want to reallocate the buffer if the new buf_size is
bigger than the old, therefore the change in the check.
Signed-off-by: Marton Balint <cus@passwd.hu>
Existing code did not check if the requested seekback buffer is
already read entirely. In this case, nothing has to be done to guarantee
seekback.
Signed-off-by: Marton Balint <cus@passwd.hu>
There was an off-by-one error when checking if the IO buffer still has enough
space till the end. One more byte can be safely written.
Signed-off-by: Marton Balint <cus@passwd.hu>
ad73b32d29 added some code for freeing in
the input's config_props function, yet this is unnecessary as uninit is
called anyway if config_props fails.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This has happened when initializing the motion estimation context if
width or height of the video was smaller than the block size used
for motion estimation and if the motion interpolation mode indicates
not to use motion estimation.
The solution is of course to only initialize the motion estimation
context if the interpolation mode uses motion estimation.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The latter code relies upon the dimensions to be not too small;
otherwise one will call av_clip() with min > max lateron which aborts
in case ASSERT_LEVEL is >= 2 or one will get a nonsense result that may
lead to a heap-buffer-overflow/underflow. The latter has happened in
ticket #8248 which this commit fixes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
There is one general rtsp connection plus two connections per stream (rtp/rtcp).
Reviewed-by: Zhao Zhili <zhilizhao@tencent.com>
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
There is no need to cast const away (even if it was harmless) and to
copy the object at all.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Now that the correct number of codes is used, it is no longer necessary
to initialize the lengths of the codes at all any more as the length of
the actually used codes is set later anyway.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It is always zero; it referred to the INIT_VLC_USE_STATIC flag which has
been removed in 595324e143.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit bbc0d0c1fe made the mjpeg decoder
use default Huffman tables when none are given, yet when initializing
the default Huffman tables, it did not use the correct number of entries
of the arrays used to initialize the tables, but instead it used the
biggest entry + 1 (as if it were a continuous array 0..biggest entry).
This worked because the ff_init_vlc_sparse() (and its predecessors)
always skipped entries with a length of zero and the length of the
corresponding elements was always initialized to zero with only the
sizes of the actually existing elements being set to a size > 0 lateron.
Yet since commit 1249698e1b this is no
longer so, as build_vlc() actually read the array containing the values
itself. This implies that the wrong length now leads to a read beyond
the end of the given array; this could lead to crashs (but usually
doesn't); it is detectable by ASAN* and this commit fixes it.
*: AddressSanitizer: global-buffer-overflow on address xy
...
xy is located 0 bytes to the right of global variable 'avpriv_mjpeg_val_ac_luminance'
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Commit 1249698e1b made
ff_mjpeg_decode_dht() call build_vlc() with a wrong (too hight)
number of codes. The reason it worked is that the lengths of the extraneous
entries is initialized to zero and ff_init_vlc_sparse() ignores codes
with a length of zero. But using a too high number of codes was
nevertheless bad, because a) the assert in build_vlc() could have been
triggered (namely if the real amount of codes is 256) and b) the loop in
build_vlc() uses initialized data (leading to Valgrind errors [1]).
Furthermore, the old code spend CPU cycles in said loop although the
result won't be used anyway.
[1]: http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-valgrind&time=20201008025137
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Added VDPAU to list of supported formats for VP9 420 10 and 12 bit
formats. Add VP9 10/12 Bit support for VDPAU
Signed-off-by: Philip Langdale <philipl@overt.org>
This is currently safe here, because the effective lifetime of
adaptionset_lang is parse_manifest_adaptationset() (i.e. the pointer
gets overwritten each time on entry to the function and gets freed
before exiting the function), but it is nevertheless safer to reset the
pointer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Use xmlFree instead of av_freep
snip from libxml2:
* xmlGetProp:
...
* Returns the attribute value or NULL if not found.
* It's up to the caller to free the memory with xmlFree().
According to libxml2, you are supposed to use xmlFree instead of free
on the pointer returned by it, and also using av_freep on Windows will
call _aligned_free instead of normal free, causing _aligned_free to raise
SIGTRAP and crashing ffmpeg and ffplay.
Signed-off-by: Christopher Degawa <ccom@randomderp.com>
Even if such files are invalid, they can be decoded just fine.
Also stored tiles may have bigger dimensions than displayed ones,
so do not abort decoding in such cases.
These conversion appears to be exhibiting the same rounding error as the rgbf32 formats where.
I seperated the rounding value from the 16 and 128 offsets, I think it makes it a little more clear.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
av1dec should no longer attempt to output empty frames if another decoder
was used for probing and it sucessfully set a pix_fmt ever since 05872c67a4,
so we can re-add the AV_CODEC_CAP_AVOID_PROBING cap.
Signed-off-by: James Almer <jamrial@gmail.com>
The buffers used when fragmented output is enabled have up until now not
been freed in the deinit function; they leak e.g. if one errors out of
mov_write_trailer() before one reaches the point where they are normally
written out and freed. This can e.g. happen if allocating new vos_data
fails at the beginning of mov_write_trailer().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Otherwise the old data leaks whenever extradata needs to be rewritten
(e.g. when encoding FLAC with our encoder that sends an updated
extradata packet at the end).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When remuxing an rtp hint stream (or any stream with the tag "rtp "),
the mov muxer treats this as one of the rtp hint tracks it creates
internally when ordered to do so; yet this track lacks the
AVFormatContext for the hinting rtp muxer, leading to segfaults in
mov_write_udta_sdp() if a "trak" atom is written for this stream; if not,
the stream's codecpar is freed by mov_free() as if the mov muxer owned
it (it does for the internally created "rtp " tracks), but without
resetting st->codecpar, leading to double-frees lateron. This commit
therefore ignores said tag which makes rtp hint streams unremuxable.
This fixes tickets #8181 and #8186.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The earlier code was based on the assumption that AVFrame.linesize can
not be negative.
Fixes ticket #8280.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
