Hendrik Leppkes:
> On Tue, Mar 2, 2021 at 6:14 AM Andreas Rheinhardt
> <andreas.rheinha...@gmail.com> wrote:
>>
>> James Almer:
>>> On 3/1/2021 12:36 PM, Andreas Rheinhardt wrote:
>>>> James Almer:
>>>>> On 2/26/2021 10:18 AM, Andreas Rheinhardt wrote:
>>>>>> Originally deprecated in 748c2fca7e4d99357c234936aa71212a6282be36,
>>>>>> publically deprecated in 9a07c1332cfe092b57b5758f22b686ca58806c60
>>>>>> (merged into FFmpeg in 1885ffb03d0af28e6bac2bcc8725fa15b93f6ac9).
>>>>>>
>>>>>> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@gmail.com>
>>>>>> ---
>>>>>> libavcodec/avcodec.h | 6 +++++-
>>>>>> libavcodec/parser.c | 3 ++-
>>>>>> libavcodec/version.h | 3 +++
>>>>>> 3 files changed, 10 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>>>>>> index 3178c163b9..a8741df04b 100644
>>>>>> --- a/libavcodec/avcodec.h
>>>>>> +++ b/libavcodec/avcodec.h
>>>>>> @@ -3576,14 +3576,18 @@ int av_parser_parse2(AVCodecParserContext *s,
>>>>>> int64_t pts, int64_t dts,
>>>>>> int64_t pos);
>>>>>> +#if FF_API_PARSER_CHANGE
>>>>>> /**
>>>>>> * @return 0 if the output buffer is a subset of the input, 1 if it
>>>>>> is allocated and must be freed
>>>>>> - * @deprecated use AVBitStreamFilter
>>>>>> + * @deprecated Use dump_extradata, remove_extra or extract_extradata
>>>>>> + * bitstream filters instead.
>>>>>> */
>>>>>> +attribute_deprecated
>>>>>> int av_parser_change(AVCodecParserContext *s,
>>>>>> AVCodecContext *avctx,
>>>>>> uint8_t **poutbuf, int *poutbuf_size,
>>>>>> const uint8_t *buf, int buf_size, int
>>>>>> keyframe);
>>>>>> +#endif
>>>>>> void av_parser_close(AVCodecParserContext *s);
>>>>>> /**
>>>>>> diff --git a/libavcodec/parser.c b/libavcodec/parser.c
>>>>>> index a63f532c48..f4bc00da7d 100644
>>>>>> --- a/libavcodec/parser.c
>>>>>> +++ b/libavcodec/parser.c
>>>>>> @@ -186,6 +186,7 @@ int av_parser_parse2(AVCodecParserContext *s,
>>>>>> AVCodecContext *avctx,
>>>>>> return index;
>>>>>> }
>>>>>> +#if FF_API_PARSER_CHANGE
>>>>>> int av_parser_change(AVCodecParserContext *s, AVCodecContext *avctx,
>>>>>> uint8_t **poutbuf, int *poutbuf_size,
>>>>>> const uint8_t *buf, int buf_size, int keyframe)
>>>>>> @@ -220,7 +221,7 @@ int av_parser_change(AVCodecParserContext *s,
>>>>>> AVCodecContext *avctx,
>>>>>> return 0;
>>>>>> }
>>>>>> -
>>>>>> +#endif
>>>>>> void av_parser_close(AVCodecParserContext *s)
>>>>>> {
>>>>>> if (s) {
>>>>>> diff --git a/libavcodec/version.h b/libavcodec/version.h
>>>>>> index 488def4c23..815df15628 100644
>>>>>> --- a/libavcodec/version.h
>>>>>> +++ b/libavcodec/version.h
>>>>>> @@ -150,6 +150,9 @@
>>>>>> #ifndef FF_API_MPV_RC_STRATEGY
>>>>>> #define FF_API_MPV_RC_STRATEGY (LIBAVCODEC_VERSION_MAJOR < 59)
>>>>>> #endif
>>>>>> +#ifndef FF_API_PARSER_CHANGE
>>>>>> +#define FF_API_PARSER_CHANGE (LIBAVCODEC_VERSION_MAJOR < 59)
>>>>>
>>>>> A doxygen deprecation notice is not enough to consider the function
>>>>> deprecated. There was no APIChanges entry and no attribute added to the
>>>>> function prototype.
>>>>> So this needs the APIChanges entry, and therefore be scheduled as < 60.
>>>>
>>>> I disagree. Of course Doxygen deprecations count and being on the list
>>>> of deprecated things [1] for more than eight years is enough.
>>>
>>> If there was no APIChanges entry that references a library version, then
>>> this can not be considered deprecated and can not be removed until a
>>> bump at least 2 years from now. Even more so when there was no
>>> deprecation attribute on the function to warn its users.
>>>
>>
>> I disagree; I just don't see why a doxygen deprecation should count for
>> nothing.
>>
>
> Because its hard to get notified about changes there, and thus people
> don't notice. I might read doxygen when I write new code, but for
> existing code I wouldn't go around reading docs for functions that I
> am already using checking for changes.
> The entire point of the deprecation period is to inform users of an
> upcoming change, but putting it only in doxygen is just not effective
> at that task at all. Users can be assumed to be reading APIchanges, a
> central place for all relevant changes (even if most probably don't),
> or even better get compiler deprecation warnings. Either of those
> would be good, both even better.
I don't see a reason why
https://ffmpeg.org/doxygen/trunk/deprecated.html should not count; if
both APIchanges as well as doxygen were to be properly curated, the
former would be even better to know about the current state of deprecations.
There is currently no requirement anywhere (that I could find) that says
that deprecations should be put into APIchanges or that API users should
search in APIchanges for deprecations. The only place mentioning
doc/APIchanges is libavutil/avutil.h:
"However, new public symbols may be added and new members may be
appended to public structs whose size is not part of public ABI (most
public structs in FFmpeg). New macros and enum values may be added.
Behavior in undocumented situations may change slightly (and be
documented). All those are accompanied by an entry in doc/APIchanges and
incrementing either the minor or micro version number."
As you can see, there is no mention of deprecations. This is
intentional: It was written by Anton who thinks that deprecations are no
API changes at all (a view I don't share).
On the other hand, API users are explicitly encouraged to read the
doxygen documentation. From doc/developer.texi:
"This document is mostly useful for internal FFmpeg developers.
External developers who need to use the API in their application should
refer to the API doxygen documentation in the public headers, and
check the examples in @file{doc/examples} and in the source code to
see how the public API is employed."
In particular, in case of av_parser_change there was no documentation
for this function in avcodec.h before
9a07c1332cfe092b57b5758f22b686ca58806c60. Anyone who wanted to use this
function therefore had to either use doxygen (which picks up
documentation outside of headers, too) or look at the source directly.
In both of these instances, such a user would see the deprecation since
748c2fca7e4d99357c234936aa71212a6282be36. I therefore consider the
actual deprecation to have happened in 2006, before APIchanges was
introduced at all. In this time the doxygen deprecation list was
undoubtedly the list to look at for deprecations.
- Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
