On Sat, Mar 9, 2024 at 6:59 PM Andreas Rheinhardt < andreas.rheinha...@outlook.com> wrote:
> Muhammad Faiz: > > On Fri, Mar 8, 2024 at 10:46 PM Andreas Rheinhardt < > > andreas.rheinha...@outlook.com> wrote: > > > >> Muhammad Faiz: > >>> On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt < > >>> andreas.rheinha...@outlook.com> wrote: > >>> > >>>> Muhammad Faiz: > >>>>> On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt < > >>>>> andreas.rheinha...@outlook.com> wrote: > >>>>> > >>>>>> Andreas Rheinhardt: > >>>>>>> Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f. > >>>>>>> > >>>>>>> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@outlook.com> > >>>>>>> --- > >>>>>>> doc/filters.texi | 9 --- > >>>>>>> libavfilter/Makefile | 1 - > >>>>>>> libavfilter/allfilters.c | 2 - > >>>>>>> libavfilter/fifo.c | 165 > >> --------------------------------------- > >>>>>>> 4 files changed, 177 deletions(-) > >>>>>>> delete mode 100644 libavfilter/fifo.c > >>>>>>> > >>>>>> > >>>>>> Will apply in a few days unless there are objections. > >>>>>> > >>>>>> - Andreas > >>>>>> > >>>>>> > >>>>> This breaks backward compatibility. > >>>>> > >>>>> Please revert. > >>>>> > >>>>> Thank's. > >>>> > >>>> What breaks that can't simply be fixed by removing the (a)fifo filter > >>>> from the filterchain? > >>>> > >>>> - Andreas > >>>> > >>>> > >>> I use afifo to optimize memory usage. > >>> And backward incompatible change should only be allowed with > deprecation > >>> periods and major version bump. > >>> > >> > >> Deprecation periods etc. are only common for API breaks; we do not > >> guarantee that any particular filter etc. stays available and therefore > >> occasionally remove them without deprecation. Examples of this are the > >> removal of libopenjpeg in 60ccb3fe787, the removal of libwavpackenc in > >> 45070eec4c or the removal of the XvMC hardware acceleration in > >> be95df12bb06 (the last commit was accompanied by cefa595361db9 and > >> b648ece34b6f which deprecated the parts of XvMC that were part of the > >> public API and therefore subject to the API stability contract). > >> > >> - Andreas > >> > >> > > It seems that all of them are external dependent components. So, I think > > that non external dependent components should be treated differently. > > Also, what is the urgency of (a)fifo removal? > > > > The reason for removing these features is that they have outlived their > usefulness; so have the (a)fifo filters. > > - Andreas > OK Thank's _______________________________________________ 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".