* commit '3bc2e89c76e88ae6f1fd5287e0b11abcfc3c601c':
Bump libavutil major version to account for the LLS API/ABI changes.
Conflicts:
libavutil/version.h
Bump done to stay compatible with libav, its not neccessary otherwise for ffmpeg
as we have the new ABI/API under LLS2 and the old (unused) under LLS
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Commit 41578f70cf changed the LLS API, which was
called from libavcodec. Thus using an old libavcodec with a new libavutil will
break.
All scheduled API changes are deferred to the next bump.
* qatar/master:
doxy: Define a group for libswscale documentation
Conflicts:
libavutil/avutil.h
libswscale/swscale.h
See: 18d9398143
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Originally written by James Almer <jamrial@gmail.com>
With the following contributions by Timothy Gu <timothygu99@gmail.com>
* Use descriptions of libraries from the pkg-config file generation function
* Use "FFmpeg Project" as CompanyName (suggested by Alexander Strasser)
* Use "FFmpeg" for ProductName as MSDN says "name of the product with which the
file is distributed" [1].
* Use FFmpeg's version (N-xxxxx-gxxxxxxx) for ProductVersion per MSDN [1].
* Only build the .rc files when --enable-small is not enabled.
[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa381058.aspx
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
CL_DEVICE_TYPE_DEFAULT makes duplicated device entries for each
platform using av_opencl_get_device_list()
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Reviewed-by: highgod0401 <highgod0401@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Also the libavutil/ffversion.h will be installed.
Rationale:
* Applications might want to know FFmpeg's version besides the individual
libraries'.
* Avoids file name clash between FFmpeg's ./version.h and lib*/version.h when
a library source file includes both and is compiled on an out-of-tree build.
Fixes#1769.
Signed-off-by: Timothy Gu <timothygu99@gmail.com>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes out of array read
Fixes: asan_heap-oob_19d6979_6857_mmw_deadzy.ogg
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '1eaac1d6f7bb8e52d82e1a114c88a59a9a8e5025':
mpeg12dec: Extract CC user data into frame side data
Conflicts:
doc/APIchanges
libavutil/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
All other test programs are under #ifdef TEST too
with the implementation and test code being generally in the same file
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
lls1 taken from ff130d7
This is incompatible with libavcodec version
55.18.100 to 55.43.100 except 55.39.101
This incompatibility is caused by these libavcodec versions depending on
a libavutil 52 which is ABI incompatible with the previous ABI 52
you can avoid this incompatibility by upgrading your libavcodec so it
does no longer depend on the invalid ABI
See: 502ab21af0
See: cc6714bb16
See: 41578f70cf
See: Ticket3136
Tested-by: marillat
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
XvMC has long ago been superseded by newer acceleration APIs, such as
VDPAU, and few downstreams still support it. Furthermore XvMC is not
implemented within the hwaccel framework, but requires its own specific
code in the MPEG-1/2 decoder, which is a maintenance burden.
fopen() on windows uses UTF-16, we use UTF-8 everywhere, this
function bridges the gap by using avpriv_open()
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '28096e0a806e57376541e6222d315619906e3c55':
h264: wait for initial complete frame before outputing frames
Conflicts:
doc/APIchanges
libavcodec/h264.c
libavcodec/mpegvideo.h
libavutil/frame.h
libavutil/version.h
See: a64b028aeb (as well as various later commits)
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This can be optionally disabled whith the "output_corrupt" flags
option. When in "output_corrupt" mode, incomplete frames are
signalled through AVFrame.flags FRAME_FLAG_INCOMPLETE_FRAME.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit '0b357a8095e72b092cc5c2aacc2f806db75ecae3':
AVOptions: do not range check flag options.
Conflicts:
libavutil/opt.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '529a9893d769f381b72785c500662be2020da5fe':
avframe: mark source frame const in _ref and _clone
Merged-by: Michael Niedermayer <michaelni@gmx.at>
It does not make sense in the vast majority of use cases, no currently
defined AV_OPT_TYPE_FLAGS options in Libav set the range to anything
nontrivial, and many of those get it wrong (the "correct" range is
INT_MIN to INT_MAX so that the builtin constant "all" works).
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>
The new syntax is preferred since it allows backward syntax compatibility
with libswr when switching to the new option handling code with
AV_OPT_TYPE_CHANNEL_LAYOUT.
With the new parser the string:
1234
is interpreted as a channel layout mask, rather than as a number of
channels, and thus it's compatible with the current way to set a channel
layout as an integer (e.g. for the icl and ocl options) making use of
integer option values.
ff_get_channel_layout() with compat=0 will be used in the
AV_OPT_TYPE_CHANNEL handler code.
The user is encouraged to switch to the new forward compatible syntax,
which requires to put a trailing "c" when specifying a layout as a number
of channels.
This makes sure that pointers from av_strdup are reallocable,
which is used in av_dict_set if the AV_DICT_APPEND flag is set.
Nothing should rely on pointers from av_strdup being aligned.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'c108ba0175d4fc3a3253a8b0f782fbfb96ba5098':
x86inc: Use VEX-encoded instructions in AVX functions
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This is so we can sync to x264's version of FMA4 support.
This partialy reverts commit 79687079a9.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Automatically use VEX-encoding in AVX/AVX2/XOP/FMA3/FMA4
functions for all instructions that exists in a VEX-encoded
version.
This change makes it easier to extend existing code to use AVX2.
Also add support for AVX emulation of a few instructions that
were missing before.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
