[FFmpeg-devel] [PATCH] Bump major versions of all libraries

[James Almer]

On 9/2/2017 1:23 PM, James Almer wrote:
> From: Vittorio Giovara <vittorio.giovara at gmail.com>
> 
> This disables almost everything that was deprecated at least two years ago
> 
> Readjust the minimum API version as needed, postponing any
> API-incompatible changes until the next bump.
> 
> (cherry picked from commit 07a2b155949eb267cdfc7805f42c7b3375f9c7c5)
> Signed-off-by: Vittorio Giovara <vittorio.giovara at gmail.com>
> Signed-off-by: James Almer <jamrial at gmail.com>
> ---
> This depends on "[RFC] avcodec: add AV_HWACCEL_CODEC_CAP_EXPERIMENTAL flag"
> and is meant to be applied after release 3.4 is branched off from master,
> as requested by both Michael and Marton.
> This patch does not include the cleaning that will come afterwards, like
> removing all the dead code inside the disabled FF_API_ wrappers. Those
> commits will be cherry-picked or authored as needed later.
> 
> Three API deprecated ~2 years ago or more are also postponed here for
> varying reasons.
> 
> FF_API_LOWRES:
> Since this functionality depends on AVStream->codec, i figure the two can
> be removed at the same time in the next bump or so.
> 
> FF_API_AVCTX_TIMEBASE:
> Couldn't get this one to work. Not just libavcodec but apparently also
> libavformat and ffmpeg.c expect AVCodecContext->time_base to be set for
> decoding. Upon removal some tests report a different generic stream time
> base (like 1/25), and others lose packet duration values. I guess it's
> somehow tied to the AVStream->codec clusterfuck.
> Help would be very welcome on removing this one. Otherwise it can be dealt
> with alongside AVStream->codec in the next bump.
> 
> FF_API_OLD_FILTER_OPTS_ERROR:
> This one is meant to remain after FF_API_OLD_FILTER_OPTS is removed.
> Its purpose is displaying the corrected command line using the new syntax
> as a suggestion as part of the error message.
> Please, do not report command lines using the old syntax suddenly not
> working.
> 
> 
> Notes:
> I have no way to test what effect the removal of XVMC truly has.
> The decoders are removed but unlike libav we have hwaccels that are not
> removed by this. Similarly, the pixfmt is also not removed in our case.
> Commit dcc39ee10e82833ce24aa57926c00ffeb1948198 does a thorough removal
> of the remnants of this functionality, but given the above i don't know
> if that applies to us the same way.
> I assume the hwaccels are meant to stay and work after this, so someone
> that knows this code and functionality and has a system where it can be
> tested should ideally look at this.
> 
> After the bump there's a grace period of a month or so up to at most when
> the first post-bump release is tagged, to do the general ABI cleaning this
> allows us to. This includes but is not limited to:
> 
> - Fixing field offsets of private fields in public structs by moving them
>   to the end fo the struct (properly drawing the line where fields stop
>   being public), or directly to internal structs.
> - Deprecating get/setters created because said offsets were out of whack,
>   and removing their usage within the libraries.
> - Removing public enum value gaps that were missed during the last bump.
> - Removing usage of internal API in avpriv_ functions (GetBitContext
>   especially), or altering said functions in whatever way may be needed.
> - Stop exposing internal API from libavformat.
> 
> The latter includes the scheduled removal of ffserver, as resolved in last
> November's vote. A fixed version or even a full replacement working
> exclusively with public API can be introduced at any point afterwards, so
> please, lets not start a new fight like we had last November.
> Of course, if someone goes and fixes it inside the grace period then there
> will be no need to remove it at all. But that sounds kinda unfeasible
> considering nine months have passed since the vote and nobody even gave it
> a try.

Ok, I've reached this commit in the merge queue and applied it. Now
starts a month or two long period where we can do a general ABI cleaning
like i listed above.
As usual, and like APIChanges mentions, the API/ABI should be considered
unstable during the aforementioned period.

Help cleaning public structs and similar tasks very much welcome.