You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

125 lines
4.4 KiB

/*
* copyright (c) 2003 Fabrice Bellard
*
* This file is part of FFmpeg.
*
* FFmpeg is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* FFmpeg is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with FFmpeg; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
/**
* @file
* @ingroup lavu
* Libavutil version macros
*/
#ifndef AVUTIL_VERSION_H
#define AVUTIL_VERSION_H
#include "macros.h"
/**
* @addtogroup version_utils
*
* Useful to check and match library version in order to maintain
* backward compatibility.
*
* The FFmpeg libraries follow a versioning sheme very similar to
* Semantic Versioning (http://semver.org/)
* The difference is that the component called PATCH is called MICRO in FFmpeg
* and its value is reset to 100 instead of 0 to keep it above or equal to 100.
* Also we do not increase MICRO for every bugfix or change in git master.
*
* Prior to FFmpeg 3.2 point releases did not change any lib version number to
* avoid aliassing different git master checkouts.
* Starting with FFmpeg 3.2, the released library versions will occupy
* a separate MAJOR.MINOR that is not used on the master development branch.
* That is if we branch a release of master 55.10.123 we will bump to 55.11.100
* for the release and master will continue at 55.12.100 after it. Each new
* point release will then bump the MICRO improving the usefulness of the lib
* versions.
*
* @{
*/
#define AV_VERSION_INT(a, b, c) ((a)<<16 | (b)<<8 | (c))
#define AV_VERSION_DOT(a, b, c) a ##.## b ##.## c
#define AV_VERSION(a, b, c) AV_VERSION_DOT(a, b, c)
/**
* Extract version components from the full ::AV_VERSION_INT int as returned
* by functions like ::avformat_version() and ::avcodec_version()
*/
#define AV_VERSION_MAJOR(a) ((a) >> 16)
#define AV_VERSION_MINOR(a) (((a) & 0x00FF00) >> 8)
#define AV_VERSION_MICRO(a) ((a) & 0xFF)
/**
* @}
*/
/**
* @defgroup lavu_ver Version and Build diagnostics
*
* Macros and function useful to check at compiletime and at runtime
* which version of libavutil is in use.
*
* @{
*/
#define LIBAVUTIL_VERSION_MAJOR 57
#define LIBAVUTIL_VERSION_MINOR 36
lavu/pixdesc: favour formats where depth and subsampling exactly match Since introducing the various packed formats used by VAAPI (and p012), we've noticed that there's actually a gap in how av_find_best_pix_fmt_of_2 works. It doesn't actually assign any value to having the same bit depth as the source format, when comparing against formats with a higher bit depth. This usually doesn't matter, because av_get_padded_bits_per_pixel() will account for it. However, as many of these formats use padding internally, we find that av_get_padded_bits_per_pixel() actually returns the same value for the 10 bit, 12 bit, 16 bit flavours, etc. In these tied situations, we end up just picking the first of the two provided formats, even if the second one should be preferred because it matches the actual bit depth. This bug already existed if you tried to compare yuv420p10 against p016 and p010, for example, but it simply hadn't come up before so we never noticed. But now, we actually got a situation in the VAAPI VP9 decoder where it offers both p010 and p012 because Profile 3 could be either depth and ends up picking p012 for 10 bit content due to the ordering of the testing. In addition, in the process of testing the fix, I realised we have the same gap when it comes to chroma subsampling - we do not favour a format that has exactly the same subsampling vs one with less subsampling when all else is equal. To fix this, I'm introducing a small score penalty if the bit depth or subsampling doesn't exactly match the source format. This will break the tie in favour of the format with the exact match, but not offset any of the other scoring penalties we already have. I have added a set of tests around these formats which will fail without this fix.
2 years ago
#define LIBAVUTIL_VERSION_MICRO 102
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
LIBAVUTIL_VERSION_MINOR, \
LIBAVUTIL_VERSION_MICRO)
#define LIBAVUTIL_VERSION AV_VERSION(LIBAVUTIL_VERSION_MAJOR, \
LIBAVUTIL_VERSION_MINOR, \
LIBAVUTIL_VERSION_MICRO)
#define LIBAVUTIL_BUILD LIBAVUTIL_VERSION_INT
#define LIBAVUTIL_IDENT "Lavu" AV_STRINGIFY(LIBAVUTIL_VERSION)
/**
* @defgroup lavu_depr_guards Deprecation Guards
* FF_API_* defines may be placed below to indicate public API that will be
* dropped at a future version bump. The defines themselves are not part of
* the public API and may change, break or disappear at any time.
*
* @note, when bumping the major version it is recommended to manually
* disable each FF_API_* in its own commit instead of disabling them all
* at once through the bump. This improves the git bisect-ability of the change.
*
* @{
*/
#define FF_API_D2STR (LIBAVUTIL_VERSION_MAJOR < 58)
#define FF_API_DECLARE_ALIGNED (LIBAVUTIL_VERSION_MAJOR < 58)
#define FF_API_COLORSPACE_NAME (LIBAVUTIL_VERSION_MAJOR < 58)
#define FF_API_AV_MALLOCZ_ARRAY (LIBAVUTIL_VERSION_MAJOR < 58)
#define FF_API_FIFO_PEEK2 (LIBAVUTIL_VERSION_MAJOR < 58)
#define FF_API_FIFO_OLD_API (LIBAVUTIL_VERSION_MAJOR < 58)
#define FF_API_XVMC (LIBAVUTIL_VERSION_MAJOR < 58)
#define FF_API_OLD_CHANNEL_LAYOUT (LIBAVUTIL_VERSION_MAJOR < 58)
#define FF_API_AV_FOPEN_UTF8 (LIBAVUTIL_VERSION_MAJOR < 58)
#define FF_API_PKT_DURATION (LIBAVUTIL_VERSION_MAJOR < 58)
/**
* @}
* @}
*/
#endif /* AVUTIL_VERSION_H */