From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] SDR lib comments
Date: Fri, 29 Sep 2023 00:18:03 +0200
Message-ID: <20230928221803.GA3543730@pb2> (raw)
In-Reply-To: <A5342223-2251-434C-891B-2D5A88E8845B@remlab.net>
[-- Attachment #1.1: Type: text/plain, Size: 2402 bytes --]
On Fri, Sep 29, 2023 at 12:05:56AM +0300, Rémi Denis-Courmont wrote:
>
>
> Le 28 septembre 2023 22:28:35 GMT+03:00, Michael Niedermayer <michael@niedermayer.cc> a écrit :
> >On Thu, Sep 28, 2023 at 12:28:22PM +0200, Anton Khirnov wrote:
> >> Quoting Michael Niedermayer (2023-09-23 18:43:44)
> >> > Is a seperate library really the right choice for SDR in FFmpeg at this stage ?
> >> >
> >> > Also code can always be moved into an seperate library
> >>
> >> we've had postproc in the tree for ages, nobody maintains it or
> >> cares about it, yet it seems impossible to get rid of it.
> >
> >what maintaince does it need ?
> >i mean i know the code is ugly but what _needs_ to be changed?
>
> This is rather disingenous, TBH. All non-trivial code needs maintenance.
>
> If there is no formal proof that the code is perfect, then it's probably bugged. And for the sake of the argument, if there were such a proof, it would need to be maintained as the code around changes, so either wayw that's maintenance.
>
> Then you also can't really ascertain that the code won't need fixes for future build environments and code auditing tools.
>
> And then you have all the more or less hidden costs of keeping code around, especially if it's unmaintained : people will enable it (if it's even disabled by default), hit problems and look for support.
>
> And as a downstream OSS application developer, I'd really rather postproc be officially and properly dropped, so I can justify dropping it downstream as well.
>
>
> But at least, postproc doesn't engender extra traffic on this mailing list much at all. More or less nobody here can or wants to review or test your SDR code. I think, more so than ffmpeg.git being ill-suited a source code repository for SDR because it is so niche and loosely related, ffmpeg-devel is simply not suited for SDR. The skills are not here, the time and motivation are not here, not to speak of the good will.
My reply was only about libpostproc, I was intending to just ask what exactly
needs to be done in libpostproc (aka maintaince)
i had not intended to somehow refer to anything else. I should have snipped
the other bits of the quoted thread probably
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed without some touch of madness. -- Aristotle
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
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".
next prev parent reply other threads:[~2023-09-28 22:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-23 16:43 Michael Niedermayer
2023-09-28 10:28 ` Anton Khirnov
2023-09-28 19:28 ` Michael Niedermayer
2023-09-28 21:05 ` Rémi Denis-Courmont
2023-09-28 22:18 ` Michael Niedermayer [this message]
2023-09-29 7:03 ` Nicolas George
2023-09-29 8:23 ` Rémi Denis-Courmont
2023-10-02 10:08 ` Nicolas George
2023-09-29 8:34 ` Rémi Denis-Courmont
2023-10-02 10:06 ` Nicolas George
2023-09-29 12:59 ` Vittorio Giovara
2023-10-02 10:05 ` Nicolas George
2023-09-28 21:07 ` Vittorio Giovara
2023-09-28 22:58 ` Michael Niedermayer
2023-09-29 9:43 ` Anton Khirnov
2023-09-29 11:43 ` Nicolas George
2023-09-29 13:29 ` Rémi Denis-Courmont
2023-09-29 13:53 ` Nicolas George
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230928221803.GA3543730@pb2 \
--to=michael@niedermayer.cc \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git