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.
While deprecated, they're totally useless as long as their values
are different from the AVIO_FLAG values that are used internally.
Currently, this leads to old libav applications still compiling
correctly (since we haven't removed the fallback wrappers), but
failing since the functions internally compare to the new AVIO_FLAG
values.
These should be removed at some point, but they aren't removed yet.
The intent is to be able to recompile an old application against
the new ABI without modifying the code, and this doesn't work
currently.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, the function would lead to an infinite wait (by
returning AVERROR(EAGAIN)) on sockets indicating an error
via either of these poll flags.
Signed-off-by: Martin Storsjö <martin@martin.st>
It does not make sense (DV is interleaved by design) and
it avoids a crash when the non-interleaved code tries to
use the priv_data of streams created by the DV demuxer.
The crash could be avoided differently, but then that stream
would still lack an index and would not play correctly in
non-interleaved mode.
Fixes e.g. samples/ffmpeg-bugs/roundup/issue1514/Dennis0002_video1.avi
Official AVI specification says that stream header in case of video contains
BITMAPINFO, which is equal to BITMAPINFOHEADER and optional palette. Currently
lavf AVI demuxer thinks otherwise which produces garbage on codecs that have
both palette and extradata (luckily, there are not so many such codecs).
An example of such file is:
http://samples.multimedia.cx/V-codecs/KMVC/baseball1.avi
(IIRC, MSS1 or MSS2 also had such situation but they are still not supported
by lavc).
As a side note, passing palette in extradata as it's been done previously is
not quite correct since proper _extra_ data is surplus bytes in
BITMAPINFOHEADER, not including palette.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
This enables non interleaved AVI mode for example.
Players that are picky on strict interleaving can set this.
Patches to only switch to non intereaved AVI mode when the index is not strictly
correctly interleaved are welcome.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If there are no variants, the total bitrate of the single
stream isn't known, and exporting variant_bitrate = 0 does
look weird, since there really aren't any variants.
Signed-off-by: Martin Storsjö <martin@martin.st>
All file names should be in UTF-8 within libavformat.
This is handled by mapping the open() function to an internal one
in os_support.h for windows.
fopen() could be overridden in the same way, but if that would be
used from ffmpeg.c, it would add a dependency on an ff prefixed
internal lavf function.
Signed-off-by: Martin Storsjö <martin@martin.st>
This should hopefully fix roundup issue 2586.
This commit only implements it in the demuxer, not in the
protocol handler. If desired, some of the code could be
refactored to be shared by both implementations.
Signed-off-by: Martin Storsjö <martin@martin.st>
This can later be extended to support other AES bit sizes,
encryption, other crypto algorithms, reading the key from a URL, etc.
In order to use it, the key and initialization vector has to be
passed via AVOptions. Since such options can't be passed to
protocols from the command line, the protocol is currently
only for libavformat internal use.
Signed-off-by: Martin Storsjö <martin@martin.st>
AVERROR_NOTSUPP has been dropped with the major bump. Since the
signalled error denotes a configuration problem, AVERROR(EINVAL) looks
an adequate replacement.
Signed-off-by: Stefano Sabatini <stefano.sabatini-lala@poste.it>
In write_packet(), return AVERROR(EINVAL) rather than AVERROR(EIO) if
the provided output filename pattern is not valid. Indeed this has to
be considered a configuration error rather than an I/O error.
Allow a less confusing error report.
Signed-off-by: Stefano Sabatini <stefano.sabatini-lala@poste.it>
AVERROR_NUMEXPECTED is used only in the image muxer and demuxer, and
has a too much specific meaning, which is better explained through a
log message. Thus it can be replaced by AVERROR(EINVAL).
This breaks API.
Signed-off-by: Stefano Sabatini <stefano.sabatini-lala@poste.it>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Diego Biurrun
Anton Khirnov
Michael Niedermayer
Martin Storsjö
Carl Eugen Hoyos
Gil Pedersen
Peter Ross
Reimar Döffinger
Kostya Shishkov
ami_stuff
Clément Bœsch
Sebastian Vater
Kirill Gavrilov
Alex Converse
Stefano Sabatini
Nicolas George