* qatar/master:
lavu: Move preprocessor macros in a separate file
Conflicts:
libavutil/avutil.h
libavutil/utils.c
libavutil/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The constant may change in libavutil but the library may be compiled
against an older version, thus rejecting a value which is otherwise
supported by the new libavutil.
INT_MAX is used here to denote the max allowed value for a sample format.
The opt-test code is changed to provide a valid reference example.
The constant may change in libavutil but the library may be compiled
against an older version, thus rejecting a value which is otherwise
supported by the new libavutil.
INT_MAX is used here to denote the max allowed value for a pixel format.
The opt-test code is changed to provide a valid reference example.
Previously when setting a pixel/sample format as a string range checks
were not performed. This is consistent with the
av_opt_set_pixel/sample_fmt() interface.
This reverts commit 792845e436, reversing
changes made to 1d6666a6b8.
Bumping libavutil requires all libraries that use libavutil to have their
major version bumped (yes breakage has been confirmed this is not a hypotheses)
One case of breakage is due to new types being added to AVOptions and
applications that linked to old libavutil and libswresample
then trying to use old libavutil (its soname changed so the old isnt updated)
and new swresample (its soame didnt change so it is updated)
the new swresample contains AVOption types that the old libavutil doesnt
know of thus the application attempting to access these avoptions
fails
AVOptions are used by all libs so the issue can potentially happen with
any other lib, libswresample was just the first that showed the problem
ive not checked if the other libs are affected currently by the same issue
or not
Also in addition to AVOptions, AVFrames are also defined in
libavutil, bumping it without all libs that use AVFrames could lead to
serious inconsistencies when 2 libs/app end up using 2 different libavutils
The alternative of bumping all is still possible after this revert, if it
turns out to be the preferred solution
* qatar/master:
avutil: Remove deprecated intfloat_readwrite code
Conflicts:
libavutil/intfloat_readwrite.c
libavutil/intfloat_readwrite.h
The files are left in place as they are still used by some projects
mplayer is one.
Theres no hurry in removing the code, it can as well be removed once
no projects use it anymore
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* 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>
