It might be passed to code requiring padding, such as lzo decompression.
Fixes invalid reads.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
Also add an error message an return a more suitable error code
(INVALIDDATA, not EINVAL);
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
* commit 'd28fc7b29a728bd2f88c10121abbd0442c341746':
avconv_filter: add new line after error message
See: c790ae0265
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '874838dc6589d978611c89a40694a5074f892a76':
fate: add one select filter test
Conflicts:
tests/fate/filter-video.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '305d3d9f1f7f0bdc18744f376a0ff5b012e4e6cf':
mpeg4videoenc: restore macro parentheses
No change, as the bug was spoted by ubitux and not merged
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
configure: Avoid requiring c99wrap for working around msys path issues
Conflicts:
configure
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a7b87ca9111bafb220ab94d53ab4e4ed48111800':
libxavs: rename and fix a variable name
Conflicts:
libavcodec/libxavs.c
See: 260fc0d95b
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Msys is unable to convert unix style absolute paths to windows style
paths when combined with certain multichar MSVC options such as
-Fo<file>. We used to work around this issue by passing them as two
separate parameters separated by a space to c99wrap, which then mapped
them back to the actual parameter format that MSVC uses.
The only paths that actually are an issue are absolute unix style
paths, and the only place such absolute paths are used with the output
arguments (-Fo, -Fe, -Fi, -out:) are for the temp files within configure.
By setting TMPDIR to . for msvc/icl builds, we never need to use
absolute unix style paths for the file output, and we can use the
actual proper form of the file output parameters. This avoids requiring
the c99wrap wrapper for remapping the parameters for cases where the
c99 converter isn't invoked at all (MSVC2013 and ICL).
Signed-off-by: Martin Storsjö <martin@martin.st>
This code changes the input packet, which is read only and can in
rare circumstances lead to decoder errors. (i run into one of these in
the audio decoder, which corrupted the packet during av_find_stream_info()
so that actual decoding that single packet failed later)
Until a better fix is implemented, this commit limits the problem.
A better fix might be to make the subtitle decoders not depend on
data[size] = 0 or to copy their input when this is not the case.
merging before the parser can conflict with the parser, also
future changes depend on it being done later
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
These functions are intended for use with side_data which comes in an
AVPacket.
Signed-off-by: Ben Boeckel <mathstuf@gmail.com>
Reviewed-by: wm4
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This type is intended to be used to allow codecs to pass updated
metadata to applications.
Signed-off-by: Ben Boeckel <mathstuf@gmail.com>
Reviewed-by: wm4
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Some of context fields which must be overrided by this wrapper decoder
may be set and used by user, so we have to save and restore them before
and after invoking the inner decoder to secure user.
ICL doesn't return an error on unknown parameters, and will
always pass the symver_gnu_asm test, and since Windows
never has symbol versioning, just always disable it.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Anton Khirnov
Aurelien Jacobs
Michael Niedermayer
Diego Biurrun
Vittorio Giovara
Clément Bœsch
Martin Storsjö
Sean McGovern
Ben Boeckel
Xidorn Quan
Stefano Sabatini
Derek Buitenhuis