On 9/2/2017 1:23 PM, James Almer wrote: > From: Vittorio Giovara <vittorio.giov...@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.giov...@gmail.com> > Signed-off-by: James Almer <jamr...@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel