So far, aviocontexts are used either in pure-read or pure-write
mode - full read/write mode doesn't work well (and implementing it
is a much larger, not totally trivial change).
This patch allows using avio_read and ffio_read_partial on
read/write aviocontexts, where the read operations are passed
through directly unbuffered, while writes are buffered as usual.
This is enough to support the operations needed by packet based
data transfer like in udp/rtp, where aviocontext is the only
public API for hooking up custom IO.
Signed-off-by: Martin Storsjö <martin@martin.st>
This check is somewhat more lenient as would be ideal because we dont
know if the input is signed or unsigned
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This seemed to assume that one never used writing avio unless
muxers or networking was enabled.
This ifdef is a remnant since 8fa641f8.
Signed-off-by: Martin Storsjö <martin@martin.st>
Allows avoiding the buffer when using avio read, write and seek functions.
When using the ffmpeg executable -avioflags direct can be used to enable
this mode for input files, but has no effect on output files.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Fixes an invalid free() with ass in avi. The sample in bug 98 passes
parts of AVPacket.data as buffer for the AVIOContext. Since the packet
is quite large fill_buffer tries to reallocate the buffer before doing
nothing. Fixes bug 98.
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>
No longer needed after martins change to the values.
Though this would have been nicer ABI wise but iam too lazy to maintain this difference
This reverts commit 183401b924.
Make AVIO_FLAG_ access constants work as flags, and in particular fix
the behavior of functions (such as avio_check()) which expect them to
be flags rather than modes.
This breaks API.
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.