This fixes usage of AV_TIME_BASE_Q in C++ applications, which
cannot use compound literals directly in their code.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This fixes usage of AV_TIME_BASE_Q in C++ applications, which
cannot use compound literals directly in their code.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
According to the ReplayGain spec, the peak amplitude may overflow and may result
in peak amplitude values greater than 1.0 with psychoacoustically coded audio,
such as MP3. Fully compliant decoders must allow peak overflows.
Additionally, having peak values in the 0<->UINT32_MAX scale makes it more
difficult for applications to actually use the peak values (e.g. when
implementing clipping prevention) since values have to be rescaled down.
This patch corrects the peak parsing by removing the rescaling of the decoded
values between 0 and UINT32_MAX and the 1.0 upper limit.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
And provide extended coloring capabilities for debugging.
The default colors do not change in 256 more to keep
supporting people using Black on White, White on Black and
Solarized terminals.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
AVOptionRange is not flexible enough to store AV_OPT_TYPE_IMAGE_SIZE
ranges. Current implementation can only store pixel count.
This patch aims to keep backward compatibility and extend
AVOptionRange with possibility to store width/height ranges.
Signed-off-by: Lukasz Marek <lukasz.m.luki@gmail.com>
av_dynarray_add_nofree function have similar functionality
as existing av_dynarray_add, but it doesn't deallocate memory
on fails.
Signed-off-by: Lukasz Marek <lukasz.m.luki@gmail.com>
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
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.
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>
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>
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>
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.
tue46wsdgxfjrt
Derek Buitenhuis
Alessandro Ghedini
Michael Niedermayer
Vittorio Giovara
Luca Barbato
Lukasz Marek
Nedeljko Babic
Anton Khirnov
Jean First
Tim Walker
James Almer
Nicolas George
Diego Biurrun
Reinhard Tartler
Lenny Wang
Timothy Gu
John Stebbins
Stefano Sabatini
Lenny Wang
Niv Sardi
Kieran Kunhya