Such fields can be seen as generally useful in cases where the
API user is not implementing custom AVIO callbacks, but still would
like to know if data is being read or written out, such as in case
data is being read from input but no AVPacket has been received yet.
Looking at 3f75e5116b, the field
was supposed to be private, but during merging the field and the
group that had the comment about it got separated.
Thus, move the actual privately utilized state of this variable
into the private FFIOContext. Additionally, name the private field
somewhat better, so that it does not get confused with the amount
of bytes written out.
This is especially useful when reading things such as null-terminated
strings from MOV/MP4-likes, where the size of the box is known, but
not the exact size of the string.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
For now, same as ff_read_line_to_bprint_overwrite, but reads until
the end of a null-terminated string.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
Currently AVIOContext's private fields are all over AVIOContext.
This commit moves them into a new structure in avio_internal.h instead.
Said structure contains the public AVIOContext as its first element
in order to avoid having to allocate a separate AVIOContextInternal
which is costly for those use cases where one just wants to access
an already existing buffer via the AVIOContext-API.
For these cases ffio_init_context() can't fail and always returned zero,
which was typically not checked. Therefore it has been made to not
return anything.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It only uses an AVIOContext and an AVBPrint.
When doing so, it turned out that several non-users of
ff_read_line_to_bprint_overwrite() and ff_bprint_to_codecpar_extradata()
relied on libavformat/internal.h to include bprint.h or avstring.h
for them. In order to avoid a repeat of this and in order to reduce
unnecessary dependencies, a forward declaration of struct AVBPrint is
used instead of including bprint.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
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>
Resetting a dynamic buffer means to keep the AVIOContext and the
internal buffer used by the dynamic buffer. This is done in order to
save (re)allocations when one has a workflow where one opens and closes
dynamic buffers in sequence.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Main use-case is proxying avio through a foreign I/O layer and a custom
AVIO context, without losing latency and performance characteristics.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Merged from Libav commit 173b56218f.
Main use-case is proxying avio through a foreign I/O layer and a custom
AVIO context, without losing latency and performance characteristics.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This reverts commit 9f9ed79d4c.
The hlsopts member was never set anywhere and always NULL, furthermore
the HLS demuxer needs to retrieve the proper options from the underlying
http protocol (cookies, user-agent, etc), so a dummy context won't help.
Instead, use the AVIOContext directly to access the options.
Note to maintainers: update tools
Note to maintainers: set a default whitelist for your protocol
If that makes no sense then consider to set "none" and thus require the user to specify a white-list
for sub-protocols to be opened
Note, testing and checking for missing changes is needed
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Don't prefix them ffio_url, which is misleading, sounding too
much like the urlprotocol layer (like ffurl_*).
Signed-off-by: Martin Storsjö <martin@martin.st>
Define positive return values as non errors and leave further meaning undefined
This allows future extensions to use these values
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Null buffers are useful for simulating writing to a real buffer
for the sake of measuring how many bytes are written.
Signed-off-by: Martin Storsjö <martin@martin.st>
This provides at least some protection against potential accidental
corruption of AVIO buffer workspace.
Signed-off-by: Martin Storsjö <martin@martin.st>
As long as there is enough contiguous data in the avio buffer,
just return a pointer to it instead of copying it to the caller
provided buffer.
Signed-off-by: Martin Storsjö <martin@martin.st>
The interrupt callback has to be passed in during opening (setting it
after opening isn't enough), since a blocking open couldn't be
interrupted otherwise.
Options are passed down to procotols and also need to be available
during open() in most cases.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
It doesn't look fit to be a part of the public API.
Adding a temporary hack to ffserver to be able to use it, should be
cleaned up when somebody is up for it.
Pierre-Anthony Lemieux
Jan Ekström
Jan Ekström
Andreas Rheinhardt
Marton Balint
Andreas Rheinhardt
tomajsjiang
Jeyapal, Karthick
wm4
James Almer
Hendrik Leppkes
Derek Buitenhuis
Diego Biurrun
Michael Niedermayer
Vittorio Giovara
Michael Niedermayer
Martin Storsjö
Carl Eugen Hoyos
Lou Logan
Alessandro Ghedini
Ben Avison
Anton Khirnov