It is not necessary at all. So remove it.
This also breaks an inclusion cycle mem.h->avutil.h->common.h->mem.h.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the fifo is grown by exactly the current write offset, it would end
up with offset_w = nb_elems. If av_fifo_write_from_cb() is called in
such a state, the user callback would get callled with *nb_elems=0,
which will then cause the write to return without writing anything.
Users should switch to the superior AVFifo API.
Unfortunately AVFifoBuffer fields cannot be marked as deprecated because
it would trigger a warning wherever fifo.h is #included, due to
inlined av_fifo_peek2().
Many AVFifoBuffer users operate on fixed-size elements (e.g. pointers),
but the current FIFO API deals exclusively in bytes, requiring extra
complexity in all these callers.
Add a new AVFifo API creating a FIFO with an element size
that may be larger than a byte. All operations on such a FIFO then
operate on complete elements.
This API does not reuse AVFifoBuffer and its API at all, but instead uses
an opaque struct called AVFifo. The AVFifoBuffer API will be deprecated
in a future commit once all of its users have been switched to the new
API.
Not reusing AVFifoBuffer also allowed to use the full range of size_t
from the beginning.
The API currently allows creating FIFOs up to
- UINT_MAX: av_fifo_alloc(), av_fifo_realloc(), av_fifo_grow()
- SIZE_MAX: av_fifo_alloc_array()
However the usable limit is determined by
- rndx/wndx being uint32_t
- av_fifo_[size,space] returning int
so no FIFO should be larger than the smallest of
- INT_MAX
- UINT32_MAX
- SIZE_MAX
(which should be INT_MAX an all commonly used platforms).
Return an error on trying to allocate FIFOs larger than this limit.
Avoids code duplication. It furthermore properly checks
for buf_size to be > 0 before doing anything.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Trying to write too much will currently overwrite previous data. Trying
to read too much will either av_assert2() in av_fifo_drain() or return
old data. Trying to peek too much will either av_assert2() in
av_fifo_generic_peek_at() or return old data.
Return an error code in all these cases, which is safer and more
consistent.
Fifo was reallocating always to twice of the requested size.
This fixes it to reallocate to requested size, or twice of the
original size - whichever is greater.
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
changing the context state and restoring it is not safe if another
thread writes data into the fifo
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Prior to this a X bytes write could be seen as less than X bytes being
available if the check was done at an unfortunate moment.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
With this change libavutil uses av_freep() everywhere where it makes sense.
Remaining av_free() use in it has the used pointer become inaccessible quickly
soo zeroing makes no sense.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Yes this breaks ABI/API but ive already broken it and will bump avutil major
soon.
Originally committed as revision 17869 to svn://svn.ffmpeg.org/ffmpeg/trunk
Andreas Rheinhardt
Anton Khirnov
Haihao Xiang
Luca Barbato
Jan Sebechlebsky
Diego Biurrun
Zhang Rui
Michael Niedermayer
Paul B Mahol
Michael Niedermayer
Lukasz Marek
Stefano Sabatini
Mans Rullgard
Olivier Guilyardi
Reimar Döffinger