Re: [FFmpeg-devel] [PATCH 23/25] fftools/ffmpeg_filter: add filtergraph private data

From: Paul B Mahol <onemda@gmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 23/25] fftools/ffmpeg_filter: add filtergraph private data
Date: Mon, 24 Apr 2023 20:41:35 +0200
Message-ID: <CAPYw7P78WxJpLjctDyXcgd0WWk_xSyhj3ZfGAW8hyP_gg6gZTw@mail.gmail.com> (raw)
In-Reply-To: <11c2cc80-907b-0e2d-328c-718c26690098@gmail.com>

On Mon, Apr 24, 2023 at 8:37 PM James Almer <jamrial@gmail.com> wrote:

> On 4/24/2023 3:33 PM, Paul B Mahol wrote:
> > On Mon, Apr 24, 2023 at 8:32 PM Nicolas George <george@nsup.org> wrote:
> >
> >> Anton Khirnov (12023-04-24):
> >>> So when I wanted to make changes to libavfilter recently, you claimed
> >>> your familiarity with the code makes you more qualified to judge
> >>> readability. Now my familiarity with the code makes me LESS qualified.
> >>> Curious.
> >>
> >> There is a difference between long-term knowledge of a large part of the
> >> code and a short-term acquaintance with a limited slice of the code, I
> >> hope you realize.
> >>
> >>> We've also been moving private state to private data for many years now
> >>> and none of your conjectured concerns materialized, to the contrary
> code
> >>> became easier to maintain.
> >>
> >> Untrue. For example, every instance of FFFormatContext in the code gives
> >> places where the code has become that much more annoying to maintain.
> >> Maybe the same code has become more maintainable at the same time due to
> >> other changes, but the fact remains that these changes make it harder to
> >> work on the code.
> >>
> >>> Now that would be pure noise.
> >>
> >> The only noise here is all the fgp_from_fg() you want to liter over the
> >> code and the extra variables it requires.
> >>
> >>> I have no idea what are you even objecting to. What is even
> >>> controversial about not exposing state that does not need to be
> exposed?
> >>
> >> I have explained time and again: I oppose to any change that requires us
> >> to remember or check which structure a given field belongs to when it is
> >> not already obvious by its semantic.
> >>
> >> And again, there is nothing exposed to hide here.
> >>
> >
> > Why should anybody here listen to your entries here?
> > When was last time you contributed anything marginally useful?
>
> Lets limit things to technical arguments, please.
>

Nicolas want one monumental structure like old AVCodecContext and still
current MPV structure.
There is nothing technical in this discussion, from start, at all.

> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".