On Mon, Feb 24, 2020 at 5:07 PM Thilo Borgmann <thilo.borgm...@mail.de>
wrote:
> Am 24.02.20 um 22:41 schrieb Lou Logan:
> > On Mon, Feb 24, 2020, at 3:37 AM, Anton Khirnov wrote:
> >> It fundamentally depends on an API that has been deprecated for five
> >> years, has seen no commits since that time and is of highly dubious
> >> usefulness.
> >> ---
> >> doc/filters.texi | 32 -------
> >> libavfilter/Makefile | 1 -
> >> libavfilter/allfilters.c | 1 -
> >> libavfilter/vf_qp.c | 183 ------------------------------------
> >> tests/fate/filter-video.mak | 7 +-
> >> tests/ref/fate/filter-pp2 | 1 -
> >> tests/ref/fate/filter-pp3 | 1 -
> >> 7 files changed, 1 insertion(+), 225 deletions(-)
> >> delete mode 100644 libavfilter/vf_qp.c
> >> delete mode 100644 tests/ref/fate/filter-pp2
> >> delete mode 100644 tests/ref/fate/filter-pp3
> >
> > Fine with me. I've never seen it used by anyone.
>
> I'm not fine with it. Declaring it's {use | use case} not existent is no
> arguments whatsoever in reality.
>
> Also, removing some functionality needs an argument - it is not keeping
> some functionality needs an argument.
>
> Nobody technically elaborates Paul's statement that it should go into side
> data. WTF? The compromise isn't even considered?
>
> Let's dig some trenches, shall we?
>
> And how come some obvious "use cases" / "needs" like [1] come into play?
> Or do we declare not continued discussions non-existent now, too?
>
> And how comes, if Michael's investigation, that all of this is based on
> use of _a function_ that is deprecated instead of direct access of
> AVFrame's fields is the cause of all of this?
>
> Shame on all of us.
>
If I may add my two cents, I feel like we are overreacting a bit and we
should take a step back.
It comes to no surprise that I do not agree that being so user-complacent
is beneficial to the overall health of the project, and that sometimes the
need to drop antiquate technologies arises. First of all this does not mean
that we're backward-removing this feature from older applications, old
ffmpeg installs will keep working. Secondly we have to accept that making
every user always happy is 100% not achievable. In general we should treat
this as an engineering problem and accept its trade-offs: how many users
will get angry that any given functionality is removed, how many will even
notice, and how beneficial it is that a feature is actually removed. And
let's not forget each functionality has a cost, not much for code overhead
but maintenance and review too: most people in this thread had to spend
time (the most precious resource of all!) to analyze the problem, find
alternatives and argue about this topic, while it could probably have been
spent doing better things.
For the case at hand, removing a filter that is using a deprecated
functionality seems perfectly fine, it's has happened in the past and will
definitely happen in the future. If the definitive need arises that a
filter is absolutely needed for these very old files, and users can't just
use an older ffmpeg install, then I'm sure some version a
correctly-implemented filter will magically appear on the mailing list.
For a more general picture, I hope the project will not take such a
conservative stance against removal and deprecation.
After all, we're in 2020 and not using floppy disks just fine :)
--
Vittorio
_______________________________________________
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".
