1
0
mirror of https://github.com/FFmpeg/FFmpeg.git synced 2024-12-12 19:18:44 +02:00
FFmpeg/libavformat/version.h

91 lines
3.3 KiB
C
Raw Normal View History

/*
* Version macros.
*
* 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
*/
#ifndef AVFORMAT_VERSION_H
#define AVFORMAT_VERSION_H
/**
* @file
* @ingroup libavf
* Libavformat version macros
*/
#include "libavutil/version.h"
// Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
2016-08-17 16:33:14 +02:00
// Also please add any ticket numbers that you believe might be affected here
#define LIBAVFORMAT_VERSION_MAJOR 58
#define LIBAVFORMAT_VERSION_MINOR 2
#define LIBAVFORMAT_VERSION_MICRO 100
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
LIBAVFORMAT_VERSION_MICRO)
#define LIBAVFORMAT_VERSION AV_VERSION(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
LIBAVFORMAT_VERSION_MICRO)
#define LIBAVFORMAT_BUILD LIBAVFORMAT_VERSION_INT
#define LIBAVFORMAT_IDENT "Lavf" AV_STRINGIFY(LIBAVFORMAT_VERSION)
/**
* 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.
*
*/
#ifndef FF_API_COMPUTE_PKT_FIELDS2
#define FF_API_COMPUTE_PKT_FIELDS2 (LIBAVFORMAT_VERSION_MAJOR < 59)
#endif
#ifndef FF_API_OLD_OPEN_CALLBACKS
#define FF_API_OLD_OPEN_CALLBACKS (LIBAVFORMAT_VERSION_MAJOR < 59)
#endif
lavf: replace AVStream.codec with AVStream.codecpar Currently, AVStream contains an embedded AVCodecContext instance, which is used by demuxers to export stream parameters to the caller and by muxers to receive stream parameters from the caller. It is also used internally as the codec context that is passed to parsers. In addition, it is also widely used by the callers as the decoding (when demuxer) or encoding (when muxing) context, though this has been officially discouraged since Libav 11. There are multiple important problems with this approach: - the fields in AVCodecContext are in general one of * stream parameters * codec options * codec state However, it's not clear which ones are which. It is consequently unclear which fields are a demuxer allowed to set or a muxer allowed to read. This leads to erratic behaviour depending on whether decoding or encoding is being performed or not (and whether it uses the AVStream embedded codec context). - various synchronization issues arising from the fact that the same context is used by several different APIs (muxers/demuxers, parsers, bitstream filters and encoders/decoders) simultaneously, with there being no clear rules for who can modify what and the different processes being typically delayed with respect to each other. - avformat_find_stream_info() making it necessary to support opening and closing a single codec context multiple times, thus complicating the semantics of freeing various allocated objects in the codec context. Those problems are resolved by replacing the AVStream embedded codec context with a newly added AVCodecParameters instance, which stores only the stream parameters exported by the demuxers or read by the muxers.
2014-06-18 21:42:52 +03:00
#ifndef FF_API_LAVF_AVCTX
#define FF_API_LAVF_AVCTX (LIBAVFORMAT_VERSION_MAJOR < 59)
lavf: replace AVStream.codec with AVStream.codecpar Currently, AVStream contains an embedded AVCodecContext instance, which is used by demuxers to export stream parameters to the caller and by muxers to receive stream parameters from the caller. It is also used internally as the codec context that is passed to parsers. In addition, it is also widely used by the callers as the decoding (when demuxer) or encoding (when muxing) context, though this has been officially discouraged since Libav 11. There are multiple important problems with this approach: - the fields in AVCodecContext are in general one of * stream parameters * codec options * codec state However, it's not clear which ones are which. It is consequently unclear which fields are a demuxer allowed to set or a muxer allowed to read. This leads to erratic behaviour depending on whether decoding or encoding is being performed or not (and whether it uses the AVStream embedded codec context). - various synchronization issues arising from the fact that the same context is used by several different APIs (muxers/demuxers, parsers, bitstream filters and encoders/decoders) simultaneously, with there being no clear rules for who can modify what and the different processes being typically delayed with respect to each other. - avformat_find_stream_info() making it necessary to support opening and closing a single codec context multiple times, thus complicating the semantics of freeing various allocated objects in the codec context. Those problems are resolved by replacing the AVStream embedded codec context with a newly added AVCodecParameters instance, which stores only the stream parameters exported by the demuxers or read by the muxers.
2014-06-18 21:42:52 +03:00
#endif
2016-09-16 04:42:34 +02:00
#ifndef FF_API_HTTP_USER_AGENT
#define FF_API_HTTP_USER_AGENT (LIBAVFORMAT_VERSION_MAJOR < 59)
2016-09-16 04:42:34 +02:00
#endif
#ifndef FF_API_HLS_WRAP
#define FF_API_HLS_WRAP (LIBAVFORMAT_VERSION_MAJOR < 59)
#endif
avcodec, avformat: deprecate anything related to side data merging This patch deprecates anything that has to do with merging/splitting side data. Automatic side data merging (and splitting), as well as all API symbols involved in it, are removed completely. Two FF_API_ defines are dedicated to deprecating API symbols related to this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates AVFMT_FLAG_KEEP_SIDE_DATA in libavformat. Since it was claimed that changing the default from merging side data to not doing it is an ABI change, there are two additional FF_API_ defines, which stop using the side data merging/splitting by default (and remove any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec, and FF_API_LAVF_MERGE_SD in libavformat. It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD are quickly defined to 0 in the next ABI bump, while the API symbols are retained for a longer time for the sake of compatibility. AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for most of the time it will still be defined. Keep in mind that no code exists that actually tries to unset this flag for any reason, nor does such code need to exist. Code setting this flag explicitly will work as before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once side data merging has been removed from libavformat. In order to avoid that anyone in the future does this incorrectly, here is a small guide how to update the internal code on bumps: - next ABI bump (probably soon): - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it - define FF_API_MERGE_SD to 0, and remove all code covered by it - next API bump (typically two years in the future or so): - define FF_API_LAVF_KEEPSIDE_FLAG to 0, and remove all code covered by it - define FF_API_MERGE_SD_API to 0, and remove all code covered by it This forces anyone who actually wants packet side data to temporarily use deprecated API to get it all. If you ask me, this is batshit fucked up crazy, but it's how we roll. Making AVFMT_FLAG_KEEP_SIDE_DATA to be set by default was rejected as an ABI change, so I'm going all the way to get rid of this once and for all. Reviewed-by: James Almer <jamrial@gmail.com> Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
2017-03-16 05:52:55 +02:00
#ifndef FF_API_LAVF_KEEPSIDE_FLAG
#define FF_API_LAVF_KEEPSIDE_FLAG (LIBAVFORMAT_VERSION_MAJOR < 59)
avcodec, avformat: deprecate anything related to side data merging This patch deprecates anything that has to do with merging/splitting side data. Automatic side data merging (and splitting), as well as all API symbols involved in it, are removed completely. Two FF_API_ defines are dedicated to deprecating API symbols related to this: FF_API_MERGE_SD_API removes av_packet_split/merge_side_data in libavcodec, and FF_API_LAVF_KEEPSIDE_FLAG deprecates AVFMT_FLAG_KEEP_SIDE_DATA in libavformat. Since it was claimed that changing the default from merging side data to not doing it is an ABI change, there are two additional FF_API_ defines, which stop using the side data merging/splitting by default (and remove any code in avformat/avcodec doing this): FF_API_MERGE_SD in libavcodec, and FF_API_LAVF_MERGE_SD in libavformat. It is very much intended that FF_API_MERGE_SD and FF_API_LAVF_MERGE_SD are quickly defined to 0 in the next ABI bump, while the API symbols are retained for a longer time for the sake of compatibility. AVFMT_FLAG_KEEP_SIDE_DATA will (very much intentionally) do nothing for most of the time it will still be defined. Keep in mind that no code exists that actually tries to unset this flag for any reason, nor does such code need to exist. Code setting this flag explicitly will work as before. Thus it's ok for AVFMT_FLAG_KEEP_SIDE_DATA to do nothing once side data merging has been removed from libavformat. In order to avoid that anyone in the future does this incorrectly, here is a small guide how to update the internal code on bumps: - next ABI bump (probably soon): - define FF_API_LAVF_MERGE_SD to 0, and remove all code covered by it - define FF_API_MERGE_SD to 0, and remove all code covered by it - next API bump (typically two years in the future or so): - define FF_API_LAVF_KEEPSIDE_FLAG to 0, and remove all code covered by it - define FF_API_MERGE_SD_API to 0, and remove all code covered by it This forces anyone who actually wants packet side data to temporarily use deprecated API to get it all. If you ask me, this is batshit fucked up crazy, but it's how we roll. Making AVFMT_FLAG_KEEP_SIDE_DATA to be set by default was rejected as an ABI change, so I'm going all the way to get rid of this once and for all. Reviewed-by: James Almer <jamrial@gmail.com> Reviewed-by: Rostislav Pehlivanov <atomnuker@gmail.com> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
2017-03-16 05:52:55 +02:00
#endif
avformat, ffmpeg: deprecate old rotation API The old "API" that signaled rotation as a metadata value has been replaced by DISPLAYMATRIX side data quite a while ago. There is no reason to make muxers/demuxers/API users support both. In addition, the metadata API is dangerous, as user tags could "leak" into it, creating unintended features or bugs. ffmpeg CLI has to be updated to use the new API. In particular, we must not allow to leak the "rotate" tag into the muxer. Some muxers will catch this properly (like mov), but others (like mkv) can add it as generic tag. Note applications, which use libavformat and assume the old rotate API, will interpret such "rotate" user tags as rotate metadata (which it is not), and incorrectly rotate the video. The ffmpeg/ffplay tools drop the use of the old API for muxing and demuxing, as all muxers/demuxers support the new API. This will mean that the tools will not mistakenly interpret per-track "rotate" user tags as rotate metadata. It will _not_ be treated as regression. Unfortunately, hacks have been added, that allow the user to override rotation by setting metadata explicitly, e.g. via -metadata:s:v:0 rotate=0 See references to trac #4560. fate-filter-meta-4560-rotate0 tests this. It's easier to adjust the hack for supporting it than arguing for its removal, so ffmpeg CLI now explicitly catches this case, and essentially replaces the "rotate" value with a display matrix side data. (It would be easier for both user and implementation to create an explicit option for rotation.) When the code under FF_API_OLD_ROTATE_API is disabled, one FATE reference file has to be updated (because "rotate" is not exported anymore). Tested-by: Michael Niedermayer <michael@niedermayer.cc> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
2017-03-21 09:02:58 +02:00
#ifndef FF_API_OLD_ROTATE_API
#define FF_API_OLD_ROTATE_API (LIBAVFORMAT_VERSION_MAJOR < 59)
avformat, ffmpeg: deprecate old rotation API The old "API" that signaled rotation as a metadata value has been replaced by DISPLAYMATRIX side data quite a while ago. There is no reason to make muxers/demuxers/API users support both. In addition, the metadata API is dangerous, as user tags could "leak" into it, creating unintended features or bugs. ffmpeg CLI has to be updated to use the new API. In particular, we must not allow to leak the "rotate" tag into the muxer. Some muxers will catch this properly (like mov), but others (like mkv) can add it as generic tag. Note applications, which use libavformat and assume the old rotate API, will interpret such "rotate" user tags as rotate metadata (which it is not), and incorrectly rotate the video. The ffmpeg/ffplay tools drop the use of the old API for muxing and demuxing, as all muxers/demuxers support the new API. This will mean that the tools will not mistakenly interpret per-track "rotate" user tags as rotate metadata. It will _not_ be treated as regression. Unfortunately, hacks have been added, that allow the user to override rotation by setting metadata explicitly, e.g. via -metadata:s:v:0 rotate=0 See references to trac #4560. fate-filter-meta-4560-rotate0 tests this. It's easier to adjust the hack for supporting it than arguing for its removal, so ffmpeg CLI now explicitly catches this case, and essentially replaces the "rotate" value with a display matrix side data. (It would be easier for both user and implementation to create an explicit option for rotation.) When the code under FF_API_OLD_ROTATE_API is disabled, one FATE reference file has to be updated (because "rotate" is not exported anymore). Tested-by: Michael Niedermayer <michael@niedermayer.cc> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
2017-03-21 09:02:58 +02:00
#endif
#ifndef FF_API_FORMAT_GET_SET
#define FF_API_FORMAT_GET_SET (LIBAVFORMAT_VERSION_MAJOR < 59)
#endif
#ifndef FF_API_OLD_AVIO_EOF_0
#define FF_API_OLD_AVIO_EOF_0 (LIBAVFORMAT_VERSION_MAJOR < 59)
#endif
#ifndef FF_API_R_FRAME_RATE
#define FF_API_R_FRAME_RATE 1
#endif
#endif /* AVFORMAT_VERSION_H */